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

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 28 Nov 2007 13:05:29 +0100

Hi,

While writing a validator, I encountered the following issue. I would
like to propose adding some small text to the dnssec-updates document to
clean this up.

[proposed text]

Include SOA in negative answers.

Servers that serve DNSSEC signed zones SHOULD include SOA records in the
authority section for negative answers (name error, no data). This
enables clients to distinguish referrals from negative answers when the
query did not set the RD bit, and validate accordingly.

For example, a client makes a query without RD bit to its upstream
caching server, and receives a reply from that cache with empty answer
section, NS record present, no SOA record, no DS record in the authority
section and maybe NSEC or NSEC3 records present in the authority
section, and possibly A records in the additional section. The presence
of the SOA record signals nodata instead of a referral. Trying to
determine the message status by attempting to use (any present) NSEC
records is error prone. The reason for the NSEC proof to fail may be a
security failure, and using that to determine message status conflates
security and message content.

[/proposed text]

You can leave out the 'For example' paragraph if you want, Sam; the
issue may be clear from the first.

I believe that current servers that serve DNSSEC all include SOA records
in the authority section; and therefore implementation is already
widespread. Simply trying to clean up the DNSSEC protocol by saying that
leaving out SOA records is not a good idea. (rfc 4034 and 4035 are
silent about including SOA records in negative answers, although the
examples show SOA records in the authority section).

Best regards,
   Wouter

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Nov 2007 08:49:06 -0500

>query did not set the RD bit, and validate accordingly.

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.)

>security and message content.

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.)

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?

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.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 28 Nov 2007 15:49:26 +0100

Edward Lewis wrote:
> 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.

> 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.

> 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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Nov 2007 10:28:50 -0500

>record), or NS record for the zone after a CNAME and nxdomain.

The problem with RFC 2308 is that it doesn't document the header bits.

There's one example of a negative answer with NS records in the 
authority section and no SOA accompanying them.  That's for an 
NXDOMAIN only, and as section 2.2. starts:

"NODATA is indicated by an answer with the RCODE set to NOERROR and no
relevant answers in the answer section.  The authority section will
contain an SOA record, or there will be no NS records there."

So we are back to NXDOMAIN situation.  An NXDOMAIN can come from a 
cached answer (no AA).  There are four examples given.  Type 1 has 
SOA and NS, Type 2 has none of that.  There is this quote in 2.1.1:

"Some resolvers treat a TYPE 1 NXDOMAIN response as a referral.  To
alleviate this problem it is recommended that servers that are
authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN
responses, that is the authority section contains a SOA record and no
NS records.  If a non- authoritative server sends a type 1 NXDOMAIN
response to one of these old resolvers, the result will be an
unnecessary query to an authoritative server."

Type 3 has an empty Authority section.

Type 4 looks just like the NOERROR referral.  What is said there? 
Hmmmm.  In this case I don't find explanatory text.  But I would 
conclude that an NXDOMAIN is not a referral - the message is saying 
"your destination does not exist, but here are some NS records." 
You'd be foolish to take these NS records as a referral "on the road 
to nowhere."

(Let me say my motivation is to resist the recommendation to add 
anything to the response, so I am looking hard to see if the addition 
of the SOA is a necessary evil.)

It would seem to me that instead of adding the SOA to the NS records 
there, we follow the Type 1 - Type 2 recommendation text and urge 
folks to just not include the NS set for the same reason cited there 
and in your problem statement.

So - would you consider instead a recommendation to not include NS 
records in a negative answer (as opposed to adding the SOA)?

>on what you are trying to prove.

I don't agree - if the signature fails, the record (set) is garbage 
if you care about security.  Well, I mean, if you get an NSEC* with a 
bad sig it is useless.  If you get one with a good sig but then the 
bit map doesn't make sense, then I'd still guess it is garbage, 
spindulated (I made that word up) in some botched zone update/cache 
issue or maybe a calculated to confuse attack.

(Maybe I am missing the point here.)

>answer you, not saying this is likely to be useful.

I see your paranoia medication isn't working. ;)

DNSSEC doesn't guarantee that the data is correct, just that it came 
cleanly.  So there will be many times you validate the wrong IP 
address.  All DNSSEC does is make it possible to place blame on the 
poor zone admin who will probably be busy preparing a resume, in the 
old days, he would have been pointing a finger to the host admin. ;)

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 28 Nov 2007 17:09:07 +0100

> records in a negative answer (as opposed to adding the SOA)?

Yes that would be fine. And I agree that less bits is better.

Since that SOA record was only used to give a TTL for the negative
caching, and the NSEC/NSEC3 records also have this TTL anyways; I see
the opportunity to remove that SOA+signature from many more messages ;)
But that digresses from the topic of this thread.

> I don't agree - if the signature fails, the record (set) is garbage if
> you care about security.  Well, I mean, if you get an NSEC* with a bad
> sig it is useless.  If you get one with a good sig but then the bit map
> doesn't make sense, then I'd still guess it is garbage, spindulated (I
> made that word up) in some botched zone update/cache issue or maybe a
> calculated to confuse attack.
> 

I agree that a bad sig makes the rrset bogus. I meant to say that part
of proving certain statements with NSECs consists of checking if the
proper NSECs are present, checking if the NSECs indicate the presence of
particular types, and so on. The outcome of these checks, taken together
with the proof question, result in a security status. The security
status is not determinable without determining as well whether the
message is a referral or a negative (or something else).

> address.  All DNSSEC does is make it possible to place blame on the poor
> zone admin who will probably be busy preparing a resume, in the old
> days, he would have been pointing a finger to the host admin. ;)

:-)

Best regards,
   Wouter

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 28 Nov 2007 19:00:23 +0200

> query did not set the RD bit, and validate accordingly.

Isn't this already required by RFC2308 section 3?

  3 - Negative Answers from Authoritative Servers

     Name servers authoritative for a zone MUST include the SOA record of
     the zone in the authority section of the response when reporting an
     NXDOMAIN or indicating that no data of the requested type exists.

-- 
Andreas Gustafsson, [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Nov 2007 13:48:32 -0500

>message is a referral or a negative (or something else).

Okay, I thought you meant something else.

It's necessary to understand the unchecked message before knowing 
"what to solve for."  So, it's plain to say that a message has to be 
unambiguous in meaning.

So returning to the original suggestion to include the SOA, I think 
(as already stated) that would be the wrong step.  We should stick 
with the suggestion in RFC 2308 to only send Type 2 negative 
responses (see the RFC for what Type 2 means) and just amplify that 
under DNSSEC.

I would think that we should recommend that a NXDOMAIN never include 
NS records.  That goes for caches that are not required to include 
the SOA as well as authoritative servers.  But - perhaps it is needed 
to help decide the RFC 2181 trustworthiness of the data?  Maybe not, 
if we can trust the AA bit.

 From RFC 2181:

# Trustworthiness shall be, in order from most to least:
#
#     + Data from a primary zone file, other than glue data,
#     + Data from a zone transfer, other than glue,
#     + The authoritative data included in the answer section of an
#       authoritative reply.
#     + Data from the authority section of an authoritative answer,
#     + Glue from a primary zone, or glue from a zone transfer,
#     + Data from the answer section of a non-authoritative answer, and
#       non-authoritative data from the answer section of authoritative
#       answers,
#     + Additional information from an authoritative answer,
#       Data from the authority section of a non-authoritative answer,
#       Additional information from non-authoritative answers.

Then again, under DNSSEC, trustworthiness has less impact.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Nov 2007 13:42:17 -0500

>Isn't this already required by RFC2308 section 3?

I don't think so.  That only covers authoritative servers.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 28 Nov 2007 21:20:38 +0200

> I don't think so.  That only covers authoritative servers.

For caching servers, there is section 6:

  6 - Negative answers from the cache

     When a server, in answering a query, encounters a cached negative
     response it MUST add the cached SOA record to the authority section
     of the response with the TTL decremented by the amount of time it was
     stored in the cache.  This allows the NXDOMAIN / NODATA response to
     time out correctly.

I find it somewhat confusing that Wouter's original proposed text
talks about "servers that serve DNSSEC signed zones", which I would
interpret as referring to authoritative servers, and then presents an
example involving a response from a caching server.  But in any case,
RFC2308 does seem to already cover both cases.
-- 
Andreas Gustafsson, [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Nov 2007 14:31:16 -0500

>RFC2308 does seem to already cover both cases.

Ok, but I still think we ought to reinforce the "don't include the NS 
set" in negative answers.

Other than the legacy requirement, is there a need to have the SOA? 
I mean, does it contain some information that is needed?  (Do we also 
need to prove it is the right SOA?)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Nov 2007 05:18:28 +1100

We need to support NXRRSET in responses to QUERY.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Nov 2007 04:49:21 +1100

See RFC 2308

---

From: Paul Vixie <[email-masked]>
Date: Thu, 29 Nov 2007 00:57:42 +0000

> Ok, but I still think we ought to reinforce the "don't include the NS set"
> in negative answers.

i don't think that's useful.  if the ns set is owned by a subdomain of the
qname or final cname, you know it's a referral, which you shouldn't believe
if it came from a full resolver (caching server) rather than from an authority.