To:
Scott Rose <scottr@nist.gov>
cc:
dnssec@cafax.se
From:
Slawomir Gruca <slawekgr@nask.pl>
Date:
Thu, 15 May 2003 18:21:02 +0200 (MET DST)
In-Reply-To:
<002301c31adc$d6ef7350$b9370681@barnacle>
Sender:
owner-dnssec@cafax.se
Subject:
Re: NXT issues
> ----- Original Message ----- > From: "Slawomir Gruca" <slawekgr@nask.pl> > > Hi all, > > There are a few things that bother me regarding the NTX record. Firstly, > > does anyone need to know what is in the 'next domain field' of the RDATA > > section of NXT for authentication of non-existent name? Am I wrong saying > > that it's not necessary? Just the name of the record should be enough for > > verification of the name. > I'm not sure I understand the question. The NXT RDATA contains the "next > canonical name" and the bitmap of the RR's present for the owner's name. > The owner's name and next canonical name are used to prove a "gap" of > existing names in the namespace. Is that what your are asking about, or did > I not fully understand? in a nutshell - would the NXT without the 'next canonical name' field be sufficient for a resolver to get the message that there is no domain? (I presume that such skimmed NXT is properly signed. And, for a while, let us don't care, that NXT without 'next canonical name' does not make sense :>) > > The next question I'm gonna ask you is related to cache servers. [...] > As the protocol document is written now, all cached responses should be > indexed by <qname, qclass, qtype>. So a query for "c.com" would come up > with no cached responses, and must be processed. This prevents a false > negative answer: "c.com" may be added to the zone while the "a.com NXT > d.com" is still in cache. To maintain consistancy, the caching server must > get the athoritative answer, which may be the same as the response for > "b.com", or may be a newly added RRset. [...] > Hope this helps, > Scott thanks a lot! Slawek