North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: lame delegations
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]> >
|