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

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

(that thread also has the corner case description that Scott asked for)

That thread did not manage to reach consensus, and PowerDNS now contains
a workaround for what -we- considered the broken behaviour.

I do not understand Mark's comment about NS queries. Perhaps "DNSSEC
aware resolvers" means "BIND" in his comment?

Peter

On Sat, 2023-08-05 at 07:11 +0000, Eric Vyncke (evyncke) wrote:
> Mark, thanks for your review. Happy to correct the errata after verification.
> 
> What is the view of the DNS directorate members on this errata (see below or at https://www.rfc-editor.org/errata/eid5226) ? I.e., I would appreciate a quick look by several DNS directorate members + original authors.
> 
> Thanks, in advance.
> 
> -éric
> 
> 
> On 05/08/2023, 03:46, "Mark Andrews" <marka@isc.org <mailto:marka@isc.org>> wrote:
> 
> 
> This is incorrect. DNSSEC aware resolvers make NS queries to determine the parent nameservers. Non DNSSEC resolvers accept the response from the child zone. 
> 
> 
> -- 
> Mark Andrews
> 
> 
> > On 5 Aug 2023, at 01:52, RFC Errata System <rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>> wrote:
> > 
> > The following errata report has been verified for RFC4035,
> > "Protocol Modifications for the DNS Security Extensions". 
> > 
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid5226 <https://www.rfc-editor.org/errata/eid5226>
> > 
> > --------------------------------------
> > Status: Verified
> > Type: Technical
> > 
> > Reported by: Peter van Dijk <peter.van.dijk@powerdns.com <mailto:peter.van.dijk@powerdns.com>>
> > Date Reported: 2018-01-04
> > Verified by: Eric Vyncke (IESG)
> > 
> > Section: 3.1.4.1
> > 
> > Original Text
> > -------------
> > The need for special processing by a security-aware name server only
> > arises when all the following conditions are met:
> > 
> > o The name server has received a query for the DS RRset at a zone
> > cut.
> > 
> > o The name server is authoritative for the child zone.
> > 
> > o The name server is not authoritative for the parent zone.
> > 
> > o The name server does not offer recursion.
> > 
> > Corrected Text
> > --------------
> > The need for special processing by a security-aware name server only
> > arises when all the following conditions are met:
> > 
> > o The name server has received a query for the DS RRset at a zone
> > cut.
> > 
> > o The name server is authoritative for the child zone.
> > 
> > o The name server is not authoritative for any zone above the
> > child's apex.
> > 
> > o The name server does not offer recursion.
> > 
> > Notes
> > -----
> > The original text is ambiguous in the face of an authoritative server having zones C.B.A. and A. but not B.A., and could cause DS queries for C to return a NODATA at C's apex, instead of the desired referral to B. which would allow resolution to continue correctly.
> > 
> > --------------------------------------
> > RFC4035 (draft-ietf-dnsext-dnssec-protocol-09)
> > --------------------------------------
> > Title : Protocol Modifications for the DNS Security Extensions
> > Publication Date : March 2005
> > Author(s) : R. Arends, R. Austein, M. Larson, D. Massey, S. Rose
> > Category : PROPOSED STANDARD
> > Source : DNS Extensions
> > Area : Internet
> > Stream : IETF
> > Verifying Party : IESG
> > 
> > _______________________________________________
> > dnsext mailing list
> > dnsext@ietf.org <mailto:dnsext@ietf.org>
> > https://www.ietf.org/mailman/listinfo/dnsext <https://www.ietf.org/mailman/listinfo/dnsext>
> 
> 
> 