Re: [dnsext] [dnsdir] [EXT] Asking for review on this errata by DNSSEC experts Re: [Errata Verified] RFC4035 (5226)

[Dave Lawrence <[e-mail]>]

Peter van Dijk via dnsdir writes:
> Before I posted the erratum, this was discussed on DNSOP:
> https://mailarchive.ietf.org/arch/browse/dnsop/?gbt=1&index=zlZRR37eirlOz5Rt55xU3tMzngo
> 

I am highly confident in your skills as an implementer, and I trust
that you encountered a real problem here that arose from your approach
to DNSSEC validation, but I'm not readily grokking what your approach
was that would have led to it.

In the mailing list examples, you asked authoritative nameservers
authoritative for root-servers.net for the DS for root-servers.net.
They both gave reasonable* answers, with d.root-servers.net giving an
auth nodata for DS at its apex, and e.root-servers.net giving an
upward referral to ask the .net servers.

* [ignoring, for the moment, the general "upward referrals considered
  harmful" sentiment that is no doubt part of Mark's reaction]

It is also my understanding that you preferred the referral
response and had to implement a workaround for the auth nodata
response.  

I'm guessing this isn't a qname minimisation problem, because with
that you'd learn where the .net authorities are and would have asked
them for the DS for root-servers.net, right?  (Maybe I'm not right.)

So if it's a full-name resolution issue, where you got data for
whatever.root-servers.net that you're trying to build the validation
chain for, and ... targeted the DS query at the root zone, and were
unhappy when it answered from the point of view of root-servers.net
zone?  Because you were hoping that the query would return a
delegation to the real authorities for it?  Oh hey my debugging duck
worked, I think.

That doesn't seem to have been an unreasonable expectation on your
part, yet I'm not sure that this exposes a specification fault.  The
workaround, I'm guessing, is the usual kind of "figure out who is
really authoritative" stuff that we've needed since we came up with 
the DS being authoritative on the parent side.

If the errata is accepted then it should probably then come with a
side of "so this means upward referrals" and some kind of
corresponding update to BCP 219's "In normal DNS operation, this kind
of [upward referral] response is not required for resolution or for
correctly answering any query."  I don't think the errata as-is helps
clarify the potential pitfall and how to avoid it.

Personally I'm somewhere more inclined to patch up the language around
"showing that the DS RRset does not exist in the child zone's apex"
because in this specific case we're not really talking about "the
child zone's apex"; the zone is answering for it's own apex.