[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

Home | Date list | Subject list