Re: dnssec-updates text, include SOA in negative answers

["W.C.A. Wijngaards" <wouter@nlnetlabs.nl>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Edward Lewis wrote:
> Is that necessary?
> 
> If the negative answer is coming from an authoritative server, the AA
> bit will be on for a negative answer and off for a referral.  OTOH, the
> AA bit is not covered by a DNSSEC [rfc 4034etal] protection.
> 
> But I am less certain about this in responses from cache (in which the
> AA bit is never set).
> 
> (Ergo, I think the "for example" is needed to remind folks that this is
> a cache issue.)

OK.

> Why would there be NS records in the authority section of a negative
> answer?  (It's been a while for me, I am trying to recall negative
> answers in the DNSSEC era.)

Rfc2308 shows a collection of negative answers, and NS records can be
present and absent in the authority section of negative answers.
Basically, NS record for the zone you query (with or without SOA
record), or NS record for the zone after a CNAME and nxdomain.

> If the NSEC records don't validate, what use is the response anyway? I
> mean, if their is a security failure, why then use the response to see
> if this is a referral or a negative answer?

For RRSIG validation yes, but other NSEC checks depend on what you are
trying to prove; wildcards, type missing, domain name error, DS types,
child-vs-parent-side NSEC, and so on. These checks failing are not
security failures in themselves, but become security failures depending
on what you are trying to prove.

> I'm also trying to figure out the normal use case of asking a cache a
> non-RD bit query.  I do it only for debugging, so see why a SERVFAIL was
> returned.  I can't really imagine any other reason to ask a cache in a
> non-RD manner.

I don't know, but I want to validate it :-)

You can have a resolver send its non-RD queries to a validating-cache,
to make sure it is not led astray by bogus data? Now, I'm only trying to
answer you, not saying this is likely to be useful.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHTX/2kDLqNwOhpPgRAo36AKCnuqUQ9mvV+nf8P4dFXeI91y8kLQCglFkD
DZ/WFm9hek4WZptjzUvh9Bw=
=okeC
-----END PGP SIGNATURE-----

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