Thoughts on best practice for naming router infrastructure in DNS

Mailman List Mirror (Read Only)
1

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

2

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.

randal

3

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

4

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

5

At my previous employer, we came up with a formula that we
were happy with. For reverse DNS, it involves:

* defining the interface
* defining the device function
* defining the local location
* defining the international location

o device interface could be:

  fa-0-0-0
  gi-1-0-0
  s0-0-0
  pos-1-0
  tun0

  this also takes subinterfaces into account; for cases where
  we've had to classify a switch VI the "routes" IP traffic:

  vlan100

o device function could be:

  br-gw (border router)
  cr-gw (core router)
  cr-sw (core switch)
  edge-gw (edge router)
  edge-sw (edge switch)

o device local location; we normally define this using the
  IATA 3-letter international city/airport code:

  LAX (Los Angeles
  ABV (Abuja)
  DXB (Dubai)
  CPH (Copenhagen)
  MEL (Melbourne)
  HKG (Hong Kong)
  
  it is not uncommon to have towns or cities being
  abbreviated by the locals in some other way, either
  because they do not care for the IATA code :-), or if
  they do, are not included in the IATA database; in this
  case, you may use your imagination; for us, depending on
  the length of the name, we spell out the full town's name.

o device international location is easily defined if your TLD
  is based on a country, e.g., .uk, .ae, .ke, .za, .na, e.t.c.
  for situations where your domain name would end in a
  non-region specific TLD, e.g., .com, .net, .org, e.t.c., one
  would prefix a state or country (in the case of a global
  network) to the domain name, e.g.:

  .uk.somelargenetwork.com
  .za.somelargenetwork.com

  things could get interesting if you setup multiple PoP's in
  another location that would still fall under your .com or
  other such TLD, but there are ways to fix that :-).

So, a final example of, say, core router number 5 and edge
switch number 3 located in a datacentre of a local Australian
ISP in Melbourne:

gi-0-0-1.cr-gw-5-mel.somenetworknetwork.com.au
vlan876.edge-sw-3-mel.somenetwork.com.au

Say a large network, whose home network was the US, decided to
setup a single PoP in Johannesburg that included one core
router and one border router, but whose domain name ended
in .net, it would look something like this:

pos-3-0.cr-gw-1-jnb.za.somelargenetwork.net
gi-0-0-1.br-gw-1-jnb.za.somelargenetwork.net

You could then use the script Joe Abley kindly posted earlier
to automatically generate your entries.

Of course, this was our own approach. Different folks have
different strokes.

Hope this helps.

Cheers,

Mark.

6

Then you get some networks who name all the routers after cheeses or characters from bill and ben the flowerpot men.

7

Mythic Beasts Ltd, IIRC, names their machines after, uh, mythic
beasts. Which is consistent, but not especially useful..

8

Mythic Beasts Ltd, IIRC, names their machines after, uh, mythic
beasts. Which is consistent, but not especially useful..

perhaps a decent other question is: Do I want to let the whole world know
that router X with interfaces of type Y/Z/Q is located in 1-wilshire.

I suppose on the one hand it's helpful to know that Network-A has a device
with the right sorts of interfaces/capacity in a location I care about,
but it's also nice to know that for other reasons :frowning: so naming things
about mythic beasts or cheese or movies is not so bad, provided your
NOC/OPS folks have a key that shows: optimus-prime.my.network.net ==
1-wilshire, m160, t1-customers-only.

9

At 3am, I'd rather have the NOC/OPS folk be able to figure things out
from the name directly, than have to have access to the magic key that
lets them know what the weird name translates into.

Ditto if I'm nowhere near my translation key, having a life, for example.

At any rate - it's possible to have informative names without going into
"too much" detail - knowing where the device is, what it does (border, core,
switch), and what it's connecting (customerA) is pretty darn'd useful
all around, and avoids getting into the device type and interface specifics.

cheers!

10

> perhaps a decent other question is: Do I want to let the whole world know
> that router X with interfaces of type Y/Z/Q is located in 1-wilshire.
>
> I suppose on the one hand it's helpful to know that Network-A has a device
> with the right sorts of interfaces/capacity in a location I care about,
> but it's also nice to know that for other reasons :frowning: so naming things
> about mythic beasts or cheese or movies is not so bad, provided your
> NOC/OPS folks have a key that shows: optimus-prime.my.network.net ==
> 1-wilshire, m160, t1-customers-only.

At 3am, I'd rather have the NOC/OPS folk be able to figure things out
from the name directly, than have to have access to the magic key that
lets them know what the weird name translates into.

agreed, there's a benefit, does it outweigh the 'risk'? I was only asking
a question and providing 2 examples.

Ditto if I'm nowhere near my translation key, having a life, for example.

stop joking, you don't have one of those :slight_smile:

At any rate - it's possible to have informative names without going into
"too much" detail - knowing where the device is, what it does (border, core,
switch), and what it's connecting (customerA) is pretty darn'd useful
all around, and avoids getting into the device type and interface specifics.

sure thing.