Re: TKEY compatibility problems

[Andrew Brown <[e-mail]>]

>Andrew Brown asks why my cache ``promotes'' additional records to answer
>records. (Apparently his message was discarded by Randy Bush.)

randy didn't.  his list server did.  but no matter.

>Answer: This is how caches have always worked. The additional A record
>that comes with an MX record, for example, is returned as an answer in
>response to subsequent A queries. RFC 2181 is simply wrong.

additional records are glue data.  they are there to assist the
recursing name server in looking up the answer.  they are *not* an
answer.  i would perhaps argue that an application using a resolver
should be able to use additional records as answers, but not a name
server.

>Are there any further questions about my TKEY example? The failure of
>TKEY to work with AXFR clients is just like the failure of TKEY to work
>with caches. Does everyone agree that the cache is behaving properly?
>Obviously the TKEY specification needs to be corrected.

if you receive a tkey record in response to a simple query, there's no
conceivable reason you should be able to answer an axfr query that
might contain the tkey.  if a server returns a tkey to your axfr
query, it should not be appended to the zone since it's not in the
answer section.  they question (axfr) asks for all records in the
zone.  the zone itself is the answer, the tkey is additional and not
an answer per se.

my understanding was that additional (or glue) records are supposed to
be helpful hints, not answers for servers.

-- 
|-----< "CODE WARRIOR" >-----|
[e-mail]             * "ah!  i see you have the internet
[e-mail] (Andrew Brown)                that goes *ping*!"
[e-mail]       * "information is power -- share the wealth."


to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.