[30606] in North American Network Operators' Group
RE: lame delegations
daemon@ATHENA.MIT.EDU (Karyn Ulriksen)
Fri Aug 18 17:10:44 2000
Message-ID: <0127E258EE29D3118A0F00609765B44847CB2C@dhcp-gateway.sitestream.net>
From: Karyn Ulriksen <kulriksen@publichost.com>
To: "'woods@weird.com'" <woods@weird.com>
Cc: "'nanog@merit.edu'" <nanog@merit.edu>
Date: Fri, 18 Aug 2000 14:08:49 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="windows-1252"
Errors-To: owner-nanog-outgoing@merit.edu
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 <gwoods@acm.org>
> <robohack!woods>
> Planix, Inc. <woods@planix.com>; Secrets of the Weird
> <woods@weird.com>
>
