Thoughts on best practice for naming router infrastructure in DNS

I've found myself with a few spare cycles and have decided
to put them
towards addressing a pet peeve I frequently encounter here:
the complete
state of chaois that is the naming in DNS for our network
infrastructure.  There are mismatched forward and reverse
entries, no
designated subdomain for WAN or LAN gear, there are records
that
remained after equipment was retired, etc.  The single
biggest area of
offense is in the naming for our routing gear.  I attribute
this to the
fact that routers commonly have a greater number of IP
addresses
associated with them than, say, your average edge switch. 

I'm still doing some digging around the 'net as well as the
NANOG
archives (the document from Rutger's at
http://www-td.rutgers.edu/documentation/
Reference/RUNet_Network_Device_N
aming_Convention/ provided a great example that I'm
considering
following) but I thought I'd toss it out on the list for a
bit of
insight into what's being done today as opposed to five
years ago. There
seems to be two general practices that are used when naming
routers in
DNS.  The first is to describe the location, equipment,
interface and
interface number on the equipment in the hostname, matching
that to a
designated subdomain that describes the function (WAN
routing, LAN
switching, etc).  Something like
"corp-wan1-gige0-0.wan.example.com"
would be used to describe interface Gi0/0 on WAN router #1
at the
corporate office and "dpg-mu1.wan.example.com"
would describe the
Multilink1 interface on the DuPage location's only WAN
router.  The
upside to this methodology is that techs and users alike can
see useful
information when doing a traceroute, etc.  The downside is
that if your
router has a dozen interfaces you end up with two dozen
records (12
forward, 12 reverse) associated with the device that must be
maintained.
Additionally, the moment you upgrade an interface you have
to change the
two corresponding records to reflect the new IP or interface
type (FastE
to GigE, for example).

The other style I've seen is to use one generic name, such
as
"corp-wan1.wan.example.com" for the first WAN
router and
"corp-core1.lan.example.com" for the first core
router, make the FQDN
resolve to a loopback or similarly unchanging IP and for
every interface
that carries an IP address just have the address reverse to
that single
generic FQDN.  This is generally simpler to maintain and is
given praise
because it's less likely to confuse NMS applications like
OpenView
Network Node Manager -- on the downside you lose a lot of
potentially
useful information.

Neither one of these seems well-equipped to deal with
"virtual"
interfaces such as an ethernet interface that is VRRP or
HSRP'd between
two routers (eg x.x.x.10 is your "virtual" IP for
the subnet's gateway,
router 1 has physical interface IP of x.x.x.8 and router 2
has x.x.x.9).


So, what practices do you folks follow?  What are the up and
downsides
you encounter?

-JFO
Jason "Feren" Olsen
DeVry University

On 6/14/07, randal k <nanogdata102.com> wrote:
> This particular issue has been confounding to work
around as well. The issue
> of constantly updating DNS to match the current
topology is a pain, but in
> my opinion, very necessary.

I'm not entirely convinced DNS records for every possible
interface
address are needed, in part because it's so difficult to
keep them
updated with topology changes over time.

I think the first step is to choose a standard subdomain
for
infrastructure, like "wan.example.net".  The next
step (the last step
in many companies) is to populate forward and reverse DNS
for the
"source interface" and managed IP of each device,
so you can at least
resolve the IP which the router will use when sending traps,
NTP,
TACACS+ and other  requests, and to keep the NMS sane.

Kevin

On 14-Jun-2007, at 16:25, K K wrote:

> On 6/14/07, randal k <nanogdata102.com> wrote:
>> This particular issue has been confounding to work
around as well.  
>> The issue
>> of constantly updating DNS to match the current
topology is a  
>> pain, but in
>> my opinion, very necessary.
>
> I'm not entirely convinced DNS records for every
possible interface
> address are needed, in part because it's so difficult
to keep them
> updated with topology changes over time.

I once wrote a couple of scripts to parse a repository of  
configurations stored by rancid, and to produce zone file
fragments  
which could be INCLUDEd into zones and published in the DNS 

automagically. It wasn't hard. There is some text about it
in the  
tutorial I wrote for NANOG 26, which Stephen Stuart
presented after I  
accidentally went to an ICANN meeting in Shanghai instead of
going to  
Eugene:

   http://
www.nanog.org/mtg-0210/ppt/stephen.pdf

Check pages 37-41. You'll find example scripts here:

   ftp://ftp.isc.org/isc/toolmakers/

I can't pretend I have used it since 2002, so some hacking
may be  
required. Also, unless you have a particular reason to
generate a  
topology map of a network for other reasons, and unless your
naming  
scheme is based on something that looks like an undirected
graph, you  
may find it easier to write something a little more
focussed. For  
example, the trivial awk script

/^interface / {
   ifname = $2;
   gsub(///, "-", ifname);
   gsub(/./, "-", ifname);
}

/^ ip address / {
   print $3, ifname ".someisp.net";
}

will digest cisco-style configs like

interface FastEthernet3/1/0.214
  ip address 203.97.1.241 255.255.255.240
  ...
!
interface POS3/2
  ip address 199.212.93.1 255.255.255.252
  ...

and excrete the following, for example:

203.97.1.241 FastEthernet3-1-0-214.someisp.net
199.212.93.1 POS3-2.someisp.net

Building IN-ADDR.ARPA zones from data like that is not at
all  
difficult. Dealing with JUNOS configs is marginally more
difficult  
with line-based tools like awk, but still entirely possible
(see  
those example scripts I mentioned for examples).

Package up some of this stuff so it will run unattended, and
run it  
out of cron every $interval, and suddenly reverse DNS takes
no effort  
at all.

The hard bit is back at the beginning, working out what the
mapping  
of router configuration -> DNS name should be (i.e. what
your naming  
scheme is).


Joe