Best practices for managing the IP addresses you own in DNS and their PTRs?

Question

I was wondering how exactly the big companies go about managing all the IP addresses that their public servers use, especially in respect to setting up correct PTR-records.

This is very important, for example, when sending lots of email from production environments, as the receiving mail servers will most likely perform a FCrDNS check to see if PTR and HELO/EHLO match. If it doesn't, you're pretty much guaranteed to be flagged as spam.

What I've found out myself is that facebook and Google do this by assigning third-level A-records for (as it seems) every IP address that they own and then using that in the respective PTR-record. An example would be Google's famous 8.8.8.8 address, which is mapped to google-public-dns-a.google.com. Another Google IP, 173.194.113.127, is mapped to fra02s22-in-f31.1e100.net (nice domain there, Google admins).

Using a third-level subdomain seems to be the most logical, as you can then use a wildcard certificate for your domain in SSL/TLS applications.

In my case, I was thinking about assigning subdomain with a scheme like _srv_foobar.mydomain.tld to our servers. Starting with an underscore would indicate that this subdomain is used for managing purposes, like _spf.microsoft.com or _netblocks.google.com. Is this a valid and sound approach? As mentioned in the comments, underscores are not allowed in hostnames, which makes this approach impossible.

Is it the common practice to create an A-record for every IP-address you use? Are there naming schemes that are preferred or should be avoided? I would love to hear about this topic from somebody who has been managing many dozens, hundreds or even thousands of IP addresses. Thanks!

Answer 1

Flagging this as primarily opinion based, but here's a few notes anyway. The opinions below are reflective of DNS operating practices at the MSO scale.

I would love to hear about this topic from somebody who has been managing many dozens, hundreds or even thousands of IP addresses.

'Sup.

Is it the common practice to create an A-record for every IP-address you use?

Some companies may, but that's overkill. Typically what happens is that a very large block of IP space is assigned to a region for allocation to customers (we're talking way more than a /24 here), and as part of preparing that network for use the forward and reverse records are pre-generated. From that point onward it doesn't matter how many times the segments of that IP space are shuffled between customers, it's there and ready to go.

Outside of that we typically do not pre-allocate IP space in DNS. It's messy, and it needlessly bloats your resource consumption. To put things into perspective, our BIND secondaries take slightly more than ten minutes to finish loading all of the records into memory and begin serving queries. If we were to have forward and reverse records for all of our IP space, not just customer stuff, I don't even want to imagine how bad that would get.

As a side note, if your DNS software supports synthesized forward and reverse records for ranges of IPs, you may want to explore that. BIND does not implement this.

Are there naming schemes that are preferred or should be avoided?

Use what works best for your needs, but typically it's a good idea to use a naming convention that indicates the physical region that IP address is assigned to. At-a-glance identification makes it easier for your employees to know where that traffic is coming from, whether they're a field engineer or someone in the abuse department. The larger your company is, and the more business units it has, the more value you get out of this.