Redundant PTR records

[Kevin Darcy]

Martin McCormick wrote:

>         We have a Class B network and support several domains besides
> okstate.edu.  Is there any way to include multiple reverse maps in our
> 78.139.IN-ADDR.ARPA  file?
>
>         At present, I simply grep all the reverse maps for PTR records
> and cat them on to the okstate.rev.139.78 file.  It would be much
> better for named to include those extra records automatically.
>
>         Briefly, I use Philip Hazel's makezones script to help police
> the forward and reverse maps.  Each domain produces a few more PTR
> records in another reverse map which also belongs in 139.78.  I simply
> want to have all the reverse maps together so that every PTR record
> there will be accessible.
>
>         I thought I had sent this yesterday, but I may have gotten
> side-tracked as I have not seen it or any replies so my apologies if I
> did send it yesterday.

I don't know whether the commercial products are capable of this, or
"makezones", but our homegrown DNS maintenance system maintains reverse
records automatically. You say that it would be nice for named to do this
itself, but there are at least a couple obstacles to that, that I'm aware
of:

    1. What do you do about multiple names pointing to the same
IP address? To which one of those names should the corresponding
PTR point? If you just blindly add PTR records for every forward record,
then under the default round-robin behavior, most clients will appear to
get different answers for the same PTR query at different times (since
most clients tend to only look at the first PTR in the set), thus
resulting in "inconsistent" behavior and mostly defeating the purpose of
maintaining PTRs at all. (This effect could be mitigated by using rrset
ordering rules, but you'd have to propagate those rules to *every* server
in your network, which is hard to arrange). We have a couple of
conventions around here to avoid the multiple-names-to-one-IP problem: a
general rule against having multiple names point to the same IP address,
with an exception for round-robin names, and then a special rule that
says PTRs never point to round-robin names. But these are local
conventions, how is named supposed to know whether to use this logic or
something else entirely?

    2. What do you do if you're adding a forward record, but are not
master for the reverse domain? Just skip adding the PTR? This is what we
have been doing up until now, but I'm trying to migrate towards some sort
of RFC 2317-inspired scheme whereby reverse domains will be parceled up
via CNAMEs to separate zones which can be maintained by different
organizations. But again, this is very subject to local conventions and
preferences; how is named supposed to know how you have this all set up?

The bottom line is that automatic forward/reverse synchronization tends
to get mired in conventions and rules which vary from site to site,
organization to organization. So it would be very difficult to implement
directly in named.


- Kevin