Andrew Sullivan wrote:
> Dear colleagues,
>
> I received some time ago some comments off-list on the reverse-mapping
> considerations document. I attempted unsuccessfully to convince the
> reviewer to send his substantive comments to the WG list, but he did
> not feel comfortable with that. (He also provided a number of helpful
> editorial comments, which we incorporated in the most recent version
> of the draft.)
>
> I here will attempt to summarize my understanding of his comments.
>
>
> The reviewer takes exception to the suggestion that delegations in the
> forward zone should ideally have an entry in the reverse zone too.
> Instead, he suggests, that there be _at least one_ matching reverse;
> e.g.,
>
> A (PTR (ipaddr)) == ipaddr
>
> or A (PTR (A (fqdn))) == A (fqdn)
>
> but not many more. The reviewer argues that the draft should in fact
> argue against adding multiple ("more than a handful") PTR(s) for a
> given address.
>
>
Ah. I think the issue that (presumably) the original review had was,
that if you have, say, 100 FQDNs,
all of which have:
A ( fqdnXX ) == A.B.C.D
(for all values of XX ranging from 00 to 99)
then the issue is, does there need to be 100 PTR records, where
PTR ( A.B.C.D ) == fqdnXX
(for all values of XX ranging from 00 to 99).
I would suggest that the forward/reverse validation embodied in this,
could better be handled
from an operational perspective, with the following alternative solution:
CNAME ( fqdnXX ) == fqdn00
(for all values of XX ranging from 01 to 99)
and then only the one PTR record is needed to validate the
forward/reverse universe:
PTR ( A.B.C.D ) == fqdn00.
It's not perfect, but may be adequate for many of the uses of
forward/reverse matching.
It also does a better job of embodying the *intent* of both PTR and
CNAME, when there are many
domains served/hosted on a single IP address.
(I would suggest that anyone considering doing the CNAME exercise, do so
with sub-domain entries
rather than with the entire domain, so that SOA information can be kept
separate for each domain.
E.g. have a real SOA for subdomain25.example.com, and a CNAME for
www.subdomain25.example.com
which points to www.example.com, rather than having
subdomain25.example.com be a CNAME pointing
to example.com.)
> It was our (the editors') impression that the above is consistebt with
> what the draft actually says, but that it has a different emphasis.
> That is, we think the draft says that existing reverse data is
> generally good, and matching reverse is nice to have, but that you
> shouldn't take this too far. We decided not to try to change this in
> the draft on the grounds of the support we had so far, but we're
> certainly open to changes if others think this message is garbled in
> the existing version of the draft.
>
I think the language in the current draft does a good job of describing
the general use and intent
behind its own recommendation, without delving into the minutia that
having examples iterating
over many use cases would require.
I think in all cases, it is imperative that a solid understanding of the
implications of design choices
exists, prior to embarking on implementing a given design. It is highly
unlikely that a BCP can
do more than guide readers on the high-level issues, and the deeper
understanding is the
responsibility of the reader, not the authors.
Brian Dickson
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
