Subject: [dnsext] type NSEC query at a parent's zone cut

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 04 Oct 2012 11:32:44 -0700

I have a quick and simple question: what should an authoritative
server return to a query for an NSEC RR(set) at the parent side of a zone
cut?  For example, what should a root server return to the query
"com/NSEC"?

I'm asking this because different root servers actually return
different answers (and based on initial offlist communication this
didn't seem to be a very known topic).  It may depend on from where
you query, but from the location I'm writing this message, the E, H, K
and L root servers return a referral to .com (just like when asking
for com/AAAA).  Others return an authoritative answer that has the
com/NSEC RR in the answer section (just like when asking for com/DS).

According to Section 2.6 of RFC4035, the latter behavior seems to be
correct:

   This specification updates the original DNS specification to allow
   NSEC and DS RR types at the parent side of a zone cut.  These RRsets
   are authoritative for the parent when they appear at the parent side
   of a zone cut.

Also, Section 4.2 of the RFC even seems to suggest the difference
could lead to interoperability problems:

   When attempting to retrieve missing NSEC RRs that reside on the
   parental side at a zone cut, a security-aware iterative-mode resolver
   MUST query the name servers for the parent zone, not the child zone.

because if the parent zone's authoritative server returns a referral,
the resolver cannot get what it tries to retrieve - although this may
not be a serious problem due to the note in the preceding paragraph:

   Security-aware resolvers MAY query for missing security RRs in an
   attempt to perform validation; implementations that choose to do so
   must be aware that the answers received may not be sufficient to
   validate the original response.  For example, a zone update may have
   changed (or deleted) the desired information between the original and
   follow-up queries.

In any case, it's not clear to me whether the RFC specifies what the
authoritative server should do at the parent side.  It's very specific
about the case for DS (Section 3.1.4.1), but it seems to be mostly
silent about the NSEC case.

Is this described somewhere (if so, which behavior is correct)?  Or
was there a consensus it can be an implementation dependent behavior?

Any clarification is appreciated.  Thanks,

---
JINMEI, Tatuya

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 04 Oct 2012 21:02:30 -0400

> com/NSEC RR in the answer section (just like when asking for com/DS).
If the server is only authoritative for the parent then:
As the type NSEC exists in the zone you are asking for at the name you 
are asking for the servers should return it.
Just like if the query was for RRSIG or NS  or DS at that point.
For type ANY the servers should return NS + [DS] + NSEC + RRSIG

If the server is authoritative for both parent and child it gets much 
grayer to answer the question.

Based on the different behavior of nameservers that I have seen I use 
RFC4471 names to probe for NSEC records at delegations.

	Olafur

> ---
> JINMEI, Tatuya
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Tony Finch <[email-masked]>
Date: Fri, 5 Oct 2012 11:18:54 +0100

> For type ANY the servers should return NS + [DS] + NSEC + RRSIG

If you query the root servers for com IN ANY you get NS DS RRSIG(DS) but
not NSEC RRSIG(NSEC). All the servers behave the same.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 05 Oct 2012 21:57:39 +1000

In message <[email-masked]>, Tony Fi
> not NSEC RRSIG(NSEC). All the servers behave the same.

You get a referral which what Olafur was trying to say.

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 05 Oct 2012 10:38:18 -0700

Hello,

Thanks for the comments.

At Thu, 04 Oct 2012 21:02:30 -0400,

> If the server is only authoritative for the parent then:

I should have been clearer, but I meant this simple case.

> Just like if the query was for RRSIG or NS  or DS at that point.

That was my interpretation of RFC4035 too, but does the RFC clearly
specify so (or at least is that the community's consensus even if not
explicitly documented)?  And, should we send a report to developers of
the authoritative servers that behave differently (like the E/H/K/L
root servers that are reachable from my place)?  What should new
implementors do?

> grayer to answer the question.

Probably, but I didn't even think about the trickier case because I
saw different behaviors even in the simpler case:-)  Talking about
grayer cases, one other subtle case is what the server should do if it
receives a type NSEC query at a parent's zone cut but there's no NSEC
at that point, like the case of example.com/NSEC at the .com zone.
Considering it would be treated as authoritative if it were exist, it
might have to be an authoritative negative answer.  But based on my
experiments all deployed servers return a referral in this case.

> RFC4471 names to probe for NSEC records at delegations.

Sorry, I'm afraid I don't understand this part...is it related to my
question?

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 05 Oct 2012 15:24:10 -0400

1
> Sorry, I'm afraid I don't understand this part...is it related to my

If you want the NSEC record for foo.bar. asking for
foo!!!!!!!!!!!!!!!!!!!!.bar is likely to give you what you want :-)

(! is the first displayable character in the ascii table but not a valid 
hostname character)

     Olafur

---

From: Mark Andrews <[email-masked]>
Date: Sat, 06 Oct 2012 09:31:35 +1000

In message <[email-masked]>, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP
> root servers that are reachable from my place)?  What should new

Nameservers and validators have no need to query for NSEC records
directly.

I'm tempted to say, just let both behaviours exist.  Unless you are
talking directly to the server you can't be sure about which set
of NSEC records will be returned and if both are returned to a NSEC
query you need split them in two and also split the RRSIG sets.

---

From: Tony Finch <[email-masked]>
Date: Mon, 8 Oct 2012 14:46:23 +0100

> query you need split them in two and also split the RRSIG sets.

I find it odd that none of the root servers respond to an ANY query at a
delegation point in a way I would consider correct, i.e. by returning all
the records held by the server at that owner name.

Tony.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 08 Oct 2012 22:30:53 -0700

At Fri, 05 Oct 2012 15:24:10 -0400,

> (! is the first displayable character in the ascii table but not a valid 

Ah, so this is about how a resolver (or any client in general) can get
such an NSEC from an arbitrary implementation of authoritative server.

This is a different topic from my original question (which is what the
authoritative server should do), but thanks for the tip.  Regarding my
original question, based on the few responses I've seen, people seem
to don't care and do accept the current inconsistent authoritative
server behaviors as "de facto".

---
JINMEI, Tatuya