North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: lame delegations

  • From: Karyn Ulriksen
  • Date: Fri Aug 18 17:11:56 2000

With this in mind, then is it just a failing of BIND that it only recognizes
the first PTR record and disregards the rest (unlike the typical A record
format  used for round-robin) ?  << Yes, I know what kind of flack that this
will lead to, but the logic isn't that wierd...

Karyn

> 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.
> 
> -- 
> 							Greg A. Woods
> 
> +1 416 218-0098      VE3TCP      <[email protected]>      
> <robohack!woods>
> Planix, Inc. <[email protected]>; Secrets of the Weird 
> <[email protected]>
>