> At 16:15 +0900 11/22/05, JINMEI Tatuya /
> =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
> >Hmm, so the gtld server returns a glue record for which it does not
> >have the authority in the answer section. While it does not
> >necessarily seem invalid according to RFC2181 (which prohibits an
> >authoritative server from returning an authoritative answer as
> >non-authoritative data, but doesn't say anything about the content of
> >the answer section), it's still annoying as we see now...
>
> This is something I've personally labelled a "hybrid answer" on the
> namedroppers list. (Meaning it's my term, no group has vetted it.)
> The expected response in the situation is a referral - everything in
> the response you see but with a ANCOUNT=0 and no records in the
> ANSWER section. The message is a hybrid referral-cache response.
>
> There is a historical reason for this hybrid. Smoothing over a ton
> of details, older resolvers were not capable of handling the number
> of "restarts" needed to look up a reverse map (for instance). By
> slipping in the A record in the hybrid answer, these resolvers were
> able to do reverse map lookups.
The reason was much simpler than that. Named (4 and 8)
only has one database internally to store rdata (both zone
and cache). If you had glue it was stored and returned in
the answer section. Originally this was with AA set later
glue was returned with AA cleared. Named (8) still does
this if RD is set in the query.
Atlas followed this model.
> There's nothing syntactically wrong with the response. It is
> possible to see an answer that not authoritative (no AA) without the
> recursion available bit on (no RA). The semantic is "I've learned
> this for some other reason and I'll tell you, but don't expect me to
> look it up for you otherwise." In this case, the answer was obtained
> through the registration process.
>
> I'm not surprised that this hybrid isn't covered by specifications,
> it came from an operational observation. The situation spurring this
> kind of message was a weakness in a software design (not a bug per
> se). The design weakness has been corrected in later versions of
> software, but, as usual, there's no accounting for some folks'
> failure to upgrade.
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis +1-571-434-5468
> NeuStar
>
> 3 months to the next trip. I guess it's finally time to settle down and
> find a grocery store.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
