Hurricane Electric

Reverse DNS

Once more, with feeling!

Introduction

The purpose of this document is to outline the methods of reverse DNS delegation Hurricane Electric supports. You may request any of these that you favor or are most comfortable configuring, with the caveat that they must fit your actual delegation (you can't DeGroot a /24, for example).

This document assumes the reader has some understanding of how forward DNS works, including the makings of a zone file and nameserver configuration, as well as familiarity with the "slash notation" of netblocks..

You should note that you can further sub-delegate your IPs by whatever means you wish, assuming you wish to do so at all. This page is meant only to explain how our delegation works with you, our direct customer.

If, after reading this document top to bottom several times and testing your configuration, you find you have any questions, send them to Hurricane Electric technical support.

Categories

Depending on the size of your allocation, reverse DNS can be handled several ways. The methods Hurricane Electric supports are:

/30 to /25 using original DeGroot notation

The original DeGroot notation (sometimes called the DeGroot hack) specifies a subnet of a CIDR netblock, typically a /24, and delegates the rDNS for that subnet. If you were allocated 172.31.15.144/28 you would name your zone file:

subnet144.15.31.172.in-addr.arpa

Then you would have your PTR records like you would normally:

145 IN PTR somename.com.

and so on.

In this case we need the hostnames of your nameservers. We delegate the subnet in-addr.arpa zone to your nameservers using NS records.

Debugging Your Subnet Reverse DNS

If you were allocated 172.31.15.144/28 (this is a nonworking theoretical example), you would use the following commands to make sure we were pointing reverse to you:

# dig 144.15.31.172.in-addr.arpa. @ns1.he.net. CNAME

Check to see if there is a CNAME record for the IP, using the zone subnet144.15.31.172.in-addr.arpa.

# dig subnet144.15.31.172.in-addr.arpa. @ns1.he.net. NS

Check the name servers listed.

The first command checks to see what subnet we are pointing an IP in your range to (via a CNAME record) and the second checks where we say the DNS for that subnet is (via a NS record).

/24 using slave statements

Reverse DNS for /24s is normally provided by having Hurricane Electric's name servers act as slave name servers for the zone. The use of slave statements to pull zone files for in-addr.arpa records provides our customers with the benefits of higher peformance (fewer queries till an answer) and automatic redundancy (since Hurricane Electric runs five nameservers).

In this case we need your nameservers to pull the in-addr.arpa zone of the /24. We pull the zone using a slave statement in our named.conf on all of our nameservers.

Two conditions need to be met to ensure this happens:

Our nameservers are: Commentary for DNS experts regarding /24 reverse DNS
     Sometimes people ask why we don't simply redelegate /24s using NS records. /24s that are part of prefix that is smaller than a /16 have their reverse DNS delegated to Hurricane by ARIN using specific NS records for each /24. A /24 in-addr.arpa which has been specifically delegated to Hurricane Electric by ARIN can't use NS records to redelegate because a zone may only be delegated once.

/30 to /24 using RFC4183 notation

RFC4183, much like the DeGroot method, specifies rDNS for subnets. However, it is a more specific notation and allows for a wide range of delegation. The naming scheme starts with the last octet of your network IP, followed by a hyphen, followed by the netmask bits of your subnet, and ends with the usual three-octets.in-addr.arpa notation.

If you were allocated 172.31.15.144/28:

You would therefore name your zone file:

144-28.15.31.172.in-addr.arpa.

Then you would have your PTR records like you would normally:

145 IN PTR somename.com.

and so on.

In this case we need the hostnames of your nameservers. We delegate the subnet in-addr.arpa zone to your nameservers using NS records.

Debugging Your Subnet Reverse DNS

If you were allocated 172.31.15.144/28 (this is a nonworking theoretical example), you would use the following commands to make sure we were pointing reverse to you:

# dig 144.15.31.172.in-addr.arpa. @ns1.he.net. CNAME

Check to see if there is a CNAME record for the IP, using the zone 144-28.15.31.172.in-addr.arpa.

# dig 144-28.15.31.172.in-addr.arpa. @ns1.he.net. NS

Check the name servers listed.

The first command checks to see what subnet we are pointing an IP in your range to (via a CNAME record) and the second checks where we say the DNS for that subnet is (via a NS record).

/30 to /24 using RFC2317 notation

RFC2317 uses a similar looking naming scheme to RFC4183, but an important difference exists. Your zone name starts with the last octet of your network IP address, followed by a hyphen, then the last octet of your broadcast address, then the rest of the usual three-octets.in-addr.arpa notation.

This method is covered in section 9.5.2.2 of O'Reilly's "DNS & Bind", 3rd Edition.

If you were allocated 172.31.15.144/28:

You would therefore name your zone file:

144-159.15.31.172.in-addr.arpa.

Your PTR records would look the same as the previous examples:

145 IN PTR somename.com.

and so on.

In this case we need the hostnames of your nameservers. We delegate the subnet in-addr.arpa zone to your nameservers using NS records.

Debugging Your Subnet Reverse DNS

If you were allocated 172.31.15.144/28 (this is a nonworking theoretical example), you would use the following commands to make sure we were pointing reverse to you:

# dig 144.15.31.172.in-addr.arpa. @ns1.he.net. CNAME

Check to see if there is a CNAME record for the IP, using the zone 144-159.15.31.172.in-addr.arpa.

# dig 144-159.15.31.172.in-addr.arpa. @ns1.he.net. NS

Check the name servers listed.

The first command checks to see what subnet we are pointing an IP in your range to (via a CNAME record) and the second checks where we say the DNS for that subnet is (via a NS record).

Larger than a /24

Since IPv4 reverse DNS is based on octet (byte) boundaries, allocations larger than a /24 are handled as a set of individual /24s (class C's).

Back To Hurricane Electric's Home Page.