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