[AusNOG] Reverse DNS Recommendations

Paul Wilkins paulwilkins369 at gmail.com
Thu Dec 4 17:39:48 EST 2014


Don't just think about your naming scheme. Consider how it aligns with, and
can support, your business processes. Keep it as simple as possible, but no
simpler. Ideally a traceroute would be sufficient for help desk to escalate
to the right team.

Use semantically meaningful names, where possible, that match function,
rather than simply mapping the name from the IP space (which has been
suggested). If you do this, your traceroutes don't add anything you won't
see with traceroute -n.

Do you want separation of naming schemes, and shared management, for
network vs servers? If there's separate teams for network and servers, the
answer probably is yes. Best practice would be where IP and name allocation
are the one process, with PTR records autogenerated. You can do things with
SNMP to further reduce manual process.

Map infrastructure to physical locations. But services, no. A VM that moves
between DCs can be misleading if it's migrated from the DC where it's
resident, while its DNS claims it's still in the primary DC.

Plan for future growth. The name that's meaningful today, might not make
sense in 5 years time. For instance, don't include hardware names (eg.
N7K-1). When the hardware changes on upgrade, there will be confusion.
Better something that reflects function (eg. pce - for primary CE). Also,
just because your naming convention produces a canonical name today that is
unique, doesn't mean you won't have name collisions after the environment
scales up.

Paul Wilkins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20141204/89765d1f/attachment.html>


More information about the AusNOG mailing list