What is the in-addrarpa zone used for?

Answer 1

When creating DNS records for your hosts, A records make sense. After all, how can the world find your mail server unless the IP address of that server is associated with its hostname within a DNS database? However, PTR records aren't as easily understood. If you already have a zone file, why does there have to be a separate in-addr.arpa zone containing PTR records matching your A records? And who should be making those PTR records--you or your provider? Let's start by defining in-addr.arpa. .arpa is actually a TLD like .com or .org. The name of the TLD comes from Address and Routing Parameter Area and it has been designated by the IANA to be used exclusively for internet infrastructure purposes. In other words, it is an important zone and an integral part of the inner workings of DNS. The RFC for DNS (RFC 1035) has an entire section on the in-addr.arpa domain. The first two paragraphs in that section state the purpose of the domain: "The Internet uses a special domain to support gateway location and Internet address to host mapping. Other classes may employ a similar strategy in other domains. The intent of this domain is to provide a guaranteed method to perform host address to host name mapping, and to facilitate queries to locate all gateways on a particular network in the Internet. Note that both of these services are similar to functions that could be performed by inverse queries; the difference is that this part of the domain name space is structured according to address, and hence can guarantee that the appropriate data can be located without an exhaustive search of the domain space." In other words, this zone provides a database of all allocated networks and the DNS reachable hosts within those networks. If your assigned network does not appear in this zone, it appears to be unallocated. And if your hosts don't have a PTR record in this database, they appear to be unreachable through DNS. Assuming an A record exists for a host, a missing PTR record may or may not impact on the DNS reachability of that host, depending upon the applications running on that host. For example, a mail server will definitely be impacted as PTR records are used in mail header checks and by most anti-SPAM mechanisms. Depending upon your web server configuration, it may also depend upon an existing PTR record. This is why the DNS RFCs recommend that every A record has an associated PTR record. But who should make and host those PTR records? Twenty years ago when you could buy a full Class C network address (i.e. 254 host addresses) the answer was easy: you. Remember, the in-addr.arpa zone is concerned with delegated network addresses. In other words, the owner of the network address is authoritative (i.e. responsible) for the host PTR records associated with that network address space. If you only own one or two host addresses within a network address space, the provider you purchased those addresses from needs to host your PTR records as the provider is the owner of (i.e. authoritative for) the network address. Things are a bit more interesting if you have been delegated a CIDR block of addresses. The in-addr.arpa zone assumes a classful addressing scheme where a Class A address is one octet (or /8), a Class B is 2 octets (or /16) and a Class C is 3 octets (or /24). CIDR allows for delegating address space outside of these boundaries--say a /19 or a /28. RFC 2317 provides a best current practice for maintaining in-addr.arpa with these types of network allocations. Here is a summary regarding PTR records: • Don't wait until users complain about DNS unreachability--be proactive and ensure there is an associated PTR record for every A record. • If your provider hosts your A records, they should also host your PTR records. • If you only have one or two assigned IP addresses, your provider should host your PTR records as they are authoritative for the network those hosts belong to. • If you own an entire network address (e.g. a Class C address ending in 0), you are responsible for hosting your PTR records. • If you are configuring an internal DNS server within the private address ranges (e.g. 10.0.0.0 or 192.168.0.0), you are responsible for your own internal PTR records. • Remember: the key to PTR hosting is knowing who is authoritative for the network address for your domain. When in doubt, it probably is not you.