rDNS Round-Robin

Bryan Irvine sparctacus at gmail.com
Tue Jul 14 21:02:52 UTC 2009


On Wed, Jul 8, 2009 at 5:08 PM, Mark Andrews<marka at isc.org> wrote:
>
> In message <53d706300907081412r191946eeo5c9a66657bf8ef26 at mail.gmail.com>, Bryan
>  Irvine writes:
>> On Mon, Jul 6, 2009 at 4:08 PM, Kevin Darcy<kcd at chrysler.com> wrote:
>> > Bryan Irvine wrote:
>> >>
>> >> Other than to really annoy me; =A0is there a valid reason for rr rDNS?
>> >>
>> >>
>> >
>> > Once upon a time, BIND specifically *disabled* round-robin behavior for
>> > non-address (A/AAAA) record types. PTR RRsets, among other types, were
>> > always given in a "fixed" order.
>> >
>> > But, I just tried a quick test, and it appears that round-robin has been
>> > re-enabled for PTRs. Accident? I have no idea why anyone would want this
>> > behavior, except perhaps to deliberately make things annoying and the que=
>> ry
>> > results inconsistent, in the hopes that people will prevent the creation =
>> of
>> > round-robin PTRs in the first place.
>>
>> Yes but is it explicitely forbidden anywhere?  RFC's maybe?  I can't
>> find anything that says you shouldn't other than the majority of
>> people say it's dumb.  (Sometimes you need an RFC to point to in order
>> to get someone to fix something that is clearly not working
>> correctly).
>> _______________________________________________
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
>        RRsets are unordered.  Software and configurations should
>        be prepared for this.  Where ordering is required it is
>        built into the RR type.
>
>        Mark

I've think I've found the confirmation I was looking for in RFC 2181
section 10.2.

Does this seem to confirm that round-robin PTR's are perfectly legal?

10.2. PTR records

   Confusion about canonical names has lead to a belief that a PTR
   record should have exactly one RR in its RRSet.  This is incorrect,
   the relevant section of RFC1034 (section 3.6.2) indicates that the
   value of a PTR record should be a canonical name.  That is, it should
   not be an alias.  There is no implication in that section that only
   one PTR record is permitted for a name.  No such restriction should
   be inferred.

   Note that while the value of a PTR record must not be an alias, there
   is no requirement that the process of resolving a PTR record not
   encounter any aliases.  The label that is being looked up for a PTR
   value might have a CNAME record.  That is, it might be an alias.  The
   value of that CNAME RR, if not another alias, which it should not be,
   will give the location where the PTR record is found.  That record
   gives the result of the PTR type lookup.  This final result, the
   value of the PTR RR, is the label which must not be an alias.



More information about the bind-users mailing list