On Tue, Jun 26, 2007 at 02:44:41PM +1000, Mark Andrews wrote:

> >            [RFC1912] suggests that it is an operational or
> >            configuration error not to have matching PTR and A records.

>       Every address should have a PTR which gives the cannonical name
>       of the host which in turn has a matching address record.
> 
>       It is a bad idea to say for the to be a PTR for every ownername
>       of a address record.  It doesn't take too many A records, which
>       all have the same address, before you exceed the DNS protocol
>       limits with multiple PTR records.

The proposed text is intended to go in section 2, which is background
for the document.  I believe that the draft is actually a softening of
the language in RFC1912, partly for the reasons you state.  There is
text consitent with what you are saying in section 3.3:

   It is possible for there to be multiple PTRs at a single reverse tree
   node.  In extreme cases, these multiple PTRs could cause a DNS
   response to exceed the UDP limit, and fall back to TCP.  Such a case
   could be one where the advantages of reverse mapping are exceeded by
   the disadvantages of the additional burden.  This may be of
   particular significance for "mass virtual hosting" systems, where
   many hostnames are associated with a single IP.

Now that I look at this, however, it's not really correct, given
EDNS0.  So, I have two questions: 

1. Does the text from section 3.3 address your concerns about the
   proposed additional text in section 2 ("Background")?

2. Can you (or anyone else) suggest a better way of phrasing the
   "multiple PTR" paragraph to account for EDNS0 as well?

Thanks,
A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[EMAIL PROTECTED]>                              M2P 2A8
jabber: [EMAIL PROTECTED]                 +1 416 646 3304 x4110

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop

Reply via email to