Thoughts on best practice for naming router infrastructure in DNS

Olsen, Jason jolsen at devry.com
Thu Jun 14 16:27:33 UTC 2007


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




More information about the NANOG mailing list