This is the 2nd post in a two-part blog series with 6connect’s partner, Secure64, written by its Chief Operating Officer Joe Gersch. See the first post in the series, “6connect and Secure64: Secure, World-Class DNS and Network Provisioning,” here.
Reverse DNS (aka “PTR records”) is a method in which a computer’s IP address can be used to look up its assigned host name. Various RFCs encourage ISPs to populate names within the reverse lookup, stating that “every Internet-reachable host should have a name” and that such names match with a reverse pointer record. Although it is not mandatory, a number of benefits are made possible when PTR records are present in the DNS. Examples include network troubleshooting, anti-spam systems that use PTR records to verify existence of servers, and creation of whitelists for validated machines.
Reverse DNS in the IPv4 address space has been relatively standard for a long time. But what happens when someone wants to build a zone for a very large IPv6 address block? A /64 or /96 address block contains many billions of host addresses. Building a zone file with a PTR record for each possible address is, to put it simply, “out of the question”. The DNS server is not likely to have sufficient disk space or memory to store that many records.
Lee Howard documented this problem, along with several ideas for solving it, at the IETF in 2013 in “draft-howard-isp-ip6rdns”.
The first commercial DNS server to solve this problem is the Secure64 DNS Authority product. Several clients of Secure64 encountered difficulties when they could not populate reverse zones for IPv6. They had tried using $GENERATE, but unfortunately created too many records to fit into available memory. This motivated Secure64 to create the SYNTH record – a method to reply to PTR queries using a dynamically generated DNS response based on simple parsing and construction rules.
Most, but not all, PTR records are very regular in their naming convention. As an IPv4 example, IP address 1.2.3.4 in a /16 address block might return a simple hostname such as 4-3-myISP.com. Similar names would exist for all devices in that address block. Because there is a simple pattern, there is no need to generate a static record for each address. A single SYNTH record within the zone file is sufficient for the DNS servers to generate a dynamic response for any of the 65,536 addresses within this block. The same thing applies for IPv6, but for much larger address spaces.
There are other advantages to using the SYNTH record besides saving disk space and system memory. DNS can be started much more quickly because there are fewer records to load. A zone can contain a set of real PTR records for known host names that do not follow the pattern. These would override the SYNTH record to send the more specific known host name. Also, a zone transfer maintains DNS integrity by transferring the SYNTH record along with all other records to the slave DNS servers. These slave servers dish up the same response as the original master DNS server.
Response by Pete Sclafani, COO and Co-Founder, of 6connect:
“This approach by Secure64 is a great feature for IPv6 deployments and an elegant solution different from the typical ‘wildcard’ approach to IPv6 PTR zone records. Having these features enabled directly on the Secure64 architecture allows for simple administration from ProVision and also means simple training for end users due to the automation built into our combined solution.
We like working with forward thinking partners like Secure64 since these are the use cases that help our customers, and also address some of the larger scalability questions when it comes to IPv6.”
If you are looking for a turnkey solution for robust DNS management and automated network resource allocation, contact us at 6connect to speak directly with an engineer. info@6connect.com or +1 (650) 646-2206