Re: Additional filtering of responses

[Peter Koch <[e-mail]>]

On Thu, Aug 07, 2008 at 06:32:35PM +0200, Roy Arends wrote:

> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37612
> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

note: neither RD nor RA, so this is a response from an authoritative
server.

> ;; QUESTION SECTION:
> ;010a.example.          IN      A
> 
> ;; ANSWER SECTION:
> 010a.example.           86400   IN      A       192.0.2.9
> 
> ;; AUTHORITY SECTION:
> example.                86400   IN      NS      010a.example.
> 
> ;; Query time: 3 msec
> ;; SERVER: 192.0.2.10#53(192.0.2.10)
> 
> No glue. No additional section. 

There's nothing to glue here anyway.

> Is the address record in the answer section cached? 
> When cached, is 192.0.2.9 considered authoritative now for future lookups 
> under example? 

The question is whether "recursive servers" should continue to believe
the NS RRSet in the authority section more than what they had learned
by referral.  Insofar your question has two parts:
1) should the NS RR in the authority section be used for further lookups
   within the example domain?
2) If "yes" or the referral already had the same data, should "192.0.2.9"
   be used as an address no matter what the referral had provided as
   additional information (and, this time, originating from glue)?

If you say "no" to the first question, given all the parent/child
inconsistencies, I'd be scared by the operational effects of such a paradigm
shift.

> Will that NS record ever expire if a query is send once a day ?

This question of "auth server lock in" has been brought up by Antoin a
couple of times and is probably independent of the current discussion.
We know it "should not happen".

-Peter

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>