I am a researcher at Colgate University, working with colleagues at the University of Wisconsin and Boston University on studying aspects of the DNS.
We are wondering what insights anyone here may be willing to share about naming convention patterns that we’ve observed. There are many FQDNs with (full or partial) embedded IPv4 addresses in A records, with many variations on padding, order, whether decimal or hex, etc. There are also a number of providers that use some alphanumeric sequence (seemingly unrelated to IP address) embedded in names. We assume that these names are generated either from a commercial IPAM system or some other set of management tools or scripts. Some of our questions are:
What kinds of knobs are available in commercial IPAM systems for crafting hostname patterns?
What are some of the key use cases for having an A record (or AAAA for that matter) in which part or all of the address is embedded in the name?
Thanks so much for any thoughts you’re willing to share – please feel free to respond off-list.
server = real DNS name
random end user = DNS name which embeds the IP address
The A record is meant to match the PTR record. The PTR record embeds
the address typically as a signal that the address is not statically
assigned to a particular use or user. This is useful for filtering
systems such as email spam filters where email servers know they
should only receive unauthenticated email from other email servers
which have been statically assigned an IP address and thus given a
real name.
It appears that William Herrin <bill@herrin.us> said:
What are some of the key use cases for having an A record (or AAAA for that matter) in which part or all of the address is embedded
in the name?
server = real DNS name
random end user = DNS name which embeds the IP address
The A record is meant to match the PTR record. The PTR record embeds
the address typically as a signal that the address is not statically
assigned to a particular use or user. ...
Right. The names are usually created with BIND's $GENERATE extension or the
equivalent in other DNS software.
There is a great deal of variation in the details of the names beyond the fact
that they embed all or part of the IP address. I know a guy who has collected
a lot of regular expressions to match them. See http://enemieslist.com
To the best of my knowledge there are two types of PTR/A Records.
For dailup prefixes, IPs used for DSL,Cable, etc PTR should be generated
and contain the IP to make it easier to block emails from that ranges.
For v6 prefixes you will probably want to do this programmatically with
e.g. powerdns (see createReverse in Preset variables — PowerDNS Authoritative Server documentation)…
Doing 2**96 PTR records in Textfile is "impractical"
dig -x 2003:d6:cf31:8c00:b67a:f1ff:fedd:1d12
86400 IN PTR p200300d6cf318c00b67af1fffedd1d12.dip0.t-ipconnect.de.
For hosts I prefer nameing conventions which contain exact enough
locations which helps debugging. Just try mtr ns-com.ui-dns.com to see
which locations and routers it passes inside AS8560. So for an accepoint
the nameing convention should at least identify the building and floor
where it is installed, for switches the exact rack and for routers the
exact datacenter.
"Just" using IATA 3 letter airport codes is not good enough in my
opinion because you usally have multiple datacenters/CoLos/PoPs around a
bigger airport like MCI or FRA
We use the IATA 3-letter city codes, but then also create a 3-letter abbreviation for the data centre hosting the kit (adding a 1, 2, 3, e.t.c., alongside that since some data centres have multiple facilities in the same city) or building.
Having had devices with txl (Airport Berlin Tegel, now closed, new
Airport BER) in their DNS Name and devices in a CoLO in Weismüller
Strasse Frankfurt which got first renamed and then sold and again
renamed (afaikr) (now fra28)... I think that a convention like
<street>.<un-loc>.<tld> is worth to keep in mind.
Feel free to reach out offlist, always happy to help.
For the record, since 2003 I've been collecting and classifying PTR
naming conventions and as of the latest build we have pats for around
97.6% of IPv4's PTR space (roughly 30% of IPv4 has PTR records). We
license the data to social networks, antispam appliance vendors, security
research firms and the like, mostly for antispam applications but not always.
Here's a fun coverage map to give you an idea (h/t XKCD):