Re: [tlug] Reverse DNS Delegatation

[Curt Sampson <cjs@example.com>]

One suggestion to start with: refer to this as "in-addr.arpa"
delegation, since reverse DNS does actually exist, and is an entirely
different thing (albeit probably entirely unused for many years now).

(in-addr.arpa lookups are done as forward, not reverse, lookups, BTW.)

On 2013-07-13 14:00 +0900 (Sat), Shaun Hughes wrote:

> I've been tearing my hair out trying to get an ISP to understand that I
> would like to buy their product and have them delegate the DNS reverse zone
> to my DNS Servers.

Unless there's a trick I don't remember, they can't do this unless
you've contracted for an entire /24 from them, since the zones for
in-addr.arpa. records are based on octets within the IP address.

So first, if you don't have a /24, and you also don't have
a good explanation of how you'd have the ISP delegate
1.220.73.198.in-addr.arpa. to your DNS servers without delegating
255.220.73.198.in-addr.arpa. as well, you need to find that explanation
or you should probably give up your quest for delegation. (I would be
extremely nervous about running systems with a DNS configuration that I
didn't thoroughly understand.)

The more common way of changing the PTR records for your in-addr.arpa
names is simply to ask the ISP to use PTR records you specify for these.
(In this case, their name servers, not yours, are authoratative for
these records.) Some ISPs might do this, some might not.

In general, my recommendation is that you use the ISP-supplied records
for these names, because the ISP, unless they're utterly incompetent,
will ensure that the PTR records point to valid A records with matching
IP addresses.

Note that under normal circumstances where people are checking PTR
records according to IETF recommendations, the actual name of the PTR
record isn't relevant, and need not have anything to do with the host
using that IP address. All that's checked is that there is a PTR record,
and following it produces an A record with an IP address that matched
the one used to generate the in-addr.arpa name used to look up the PTR
record.

So, for example, when you receive an SMTP connection from a
particular one of my mail servers, you'll recieve a connection from
219.117.251.194. Looking up 194.251.117.219.in-addr.arpa, you'll find
that you get a PTR record with name 219.117.251.194.static.zoot.jp,
and looking up that you'll find you get an A record with address
219.117.251.194. Since the loop checks out, you can then safely record
"219.117.251.194.static.zoot.jp" as a name of the host that connected
to you. (This may be just one of many names assigned to that host, of
course, and you should also always record the IP address in case the
name to IP address mapping changes later.)

That you soon get a "HELO priv.dyadic.cynic.net" message on that SMTP
connection later on is perfectly fine; you're simply learning another
name that the host believes is assigned to it, which may or may not be
the name for the address from which you received the connection. (In a
correctly configured system, it might also be a name assigned to another
address used by the same host.)

cjs
-- 
Curt Sampson         <cjs@example.com>         +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch