Difference between revisions of "Reverse DNS"
m |
|||
| Line 140: | Line 140: | ||
your rDNS zone is named: | your rDNS zone is named: | ||
| − | + | 7.3.e.0.9.a.3.d.8.b.d.0.1.0.0.2.ip6.arpa. | |
The record for the first IP of that zone: | The record for the first IP of that zone: | ||
Latest revision as of 04:42, 22 December 2011
The purpose of this document is to outline the methods of reverse DNS delegation Hurricane Electric supports. For IPv4 addresses, 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.
Contents
IPv4 rDNS
/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).
/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:
- 172.31.15.144 is the network IP.
- 172.31.15.159 is the broadcast IP
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).
/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:
- 172.31.15.144 is the network IP.
- And /28 is the netmask bit number designating the size of your network.
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).
/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:
- You must allow our nameservers to do zone transfers from your nameservers (nameserver config file)
- You must have our nameservers as NS records for your rDNS zone (zone file).
Our nameservers are:
- ns1.he.net
- ns2.he.net
- ns3.he.net
- ns4.he.net
- ns5.he.net
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.
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).
IPv6 rDNS
IPv6 zones and records have straightforward names, but can be tedious to enter manually. Every digit of the IPv6 address is specified and separated by a period. This is followed by:
ip6.arpa.
So, for example, if you had the following netblock:
2001:db8:d3a9:e37::/64
your rDNS zone is named:
7.3.e.0.9.a.3.d.8.b.d.0.1.0.0.2.ip6.arpa.
The record for the first IP of that zone:
2001:db8:d3a9:e37::1
is even longer:
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.3.e.0.9.a.3.d.8.b.d.0.1.0.0.2.ip6.arpa.
When setting up your rDNS records, it's recommended you use 'dig -x' or some other utility that will automatically convert the IP to the rDNS record.
If you are using our free DNS service, your zone file is automatically created when you input the block; full address records are also automatically formatted when created.
Alternate IPv6 Naming Conventions
Since IPv6 addresses are natively classless, there are no CNAME based naming conventions when setting up delegated reverse DNS for your netblock. Thus, there is only one method of IPv6 rDNS naming.
