Subject: [dnsext] [Technical Errata Reported] RFC4592 (5119)

From: RFC Errata System <[email-masked]>
Date: Thu, 21 Sep 2017 03:54:06 -0700 (PDT)

The following errata report has been submitted for RFC4592,
"The Role of Wildcards in the Domain Name System".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5119

--------------------------------------
Type: Technical
Reported by: Karst Koymans <[email-masked]>

Section: 4.7

Original Text
-------------
4.7.  NSEC RRSet at a Wildcard Domain Name

   Wildcard domain names in DNSSEC signed zones will have an NSEC RRSet.
   Synthesis of these records will only occur when the query exactly
   matches the record.  Synthesized NSEC RRs will not be harmful as they
   will never be used in negative caching or to generate a negative
   response [RFC2308].

Corrected Text
--------------
4.7.  NSEC RRSet at a Wildcard Domain Name

   Wildcard domain names in DNSSEC signed zones will have an NSEC RRSet.
   NSEC RRSets must not be synthesized from this wildcard NSEC.

Notes
-----
Synthesizing these records would destroy the semantics of the NSEC chain and could be very harmful if implementations would cache them and use them for "Aggressive Use of DNSSEC-Validated Cache" (RFC 8198).

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4592 (draft-ietf-dnsext-wcard-clarify-11)
--------------------------------------
Title               : The Role of Wildcards in the Domain Name System
Publication Date    : July 2006
Author(s)           : E. Lewis
Category            : PROPOSED STANDARD
Source              : DNS Extensions
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Sep 2017 12:00:42 +0000

>Synthesizing these records would destroy the semantics of the NSEC chain and could be very harmful if implementations would cache them and use them for "Aggressive Use of DNSSEC-Validated Cache" (RF…

When "The Role of Wildcards in the DNS" was written, "Aggressive Use of DNSSEC-Validated Cache" hadn't been.  Until now I wasn't completely aware of that latter document (as I've not followed DNSOP for some time now), although I heard rumors about the idea.  (Meaning: I'd have to read the newer document before understanding the errata.)  Take this reply as the beginning of a discussion, not a final response, I certainly don't have all the data.

Nevertheless, some explanation of the history of the subject passage is in order.

The DNS of 10-15 years ago had the concept of a positive cache and a negative cache, the latter from "Negative Caching of DNS Queries (DNS NCACHE)".  Entries in the latter cache only happened with a negative answer (i.e., NSEC or NSEC3 in the authority section of a DNS response if DNSSEC was "running").  Data from the answer section in a DNS response would not go there, hence the comment that synthesized answers would do no harm.

The distinction of the section in which the NSEC record is received matters.  There are two ways an NSEC record can appear in an answer section and one way an NSEC3 record can appear in an Answer section.  The protocol will answer for queries with a QTYPE of NSEC (one way for NSEC) but not for NSEC3 (which the count of "ways" is different).  The one way each can appear in an answer section is in a zone transfer (AXFR) [and I suppose incremental transfer (IXFR).  AXFR and IXFR handling are a whole'nuther topic (see "DNS Zone Transfer Protocol (AXFR)").  I haven't read the "Aggressive Use of DNSSEC-Validated Cache" to know if it overlooked this important distinction, that is, NSEC records in the answer section (of a query-response) are not necessarily qualified to be used for "aggressive use" if because they may be synthesized.

The assumption behind the statement in "The Role of Wildcards in the Domain Name System" is that we wanted minimal disruption to existing code bases, hence there was no new restriction added for a query whose type was NSEC.

Another element of the historical context, while "The Role of Wildcards in the Domain Name System" was developed, there was uncertainty about whether a cache should be allowed to "usurp" the role of an authority (server) when it came to RCODE Name Error responses.  I don't recall my opinion on this at the time, so I'm not arguing one way or the other, but there was reluctance to permit the caches to take this on.  There was no consensus then, as there is now, that caches out to be "aggressive."  This is why the document assumed that the only use of negative answer records would be to answer specific queries (QNAME, QTYPE, QCLASS), modulo other factors such as "Client Subnet in DNS Queries".  This shift in consensus is what makes the subject passive "historically confusing." 

My take.  I'm naturally against adopting errata unless it is clear a change is needed.  I do see that the statement is historically confusing, but am not yet certain it is incorrect.  I would suggest examining the "Aggressive Use of DNSSEC Validated Cache" to see if it takes into consideration the response message section of the NSEC records.

Altering the older document would mean needing to address older code paths, this is why I suggest examining the newer document to see if it has the same assumptions as the older document - specifically the message section.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Sep 2017 15:57:06 +0000

A top-posted reply...

I was urged to read "Aggressive Use of DNSSEC-Validated Cache" and comment on it.

Looking at that document, it is consistent with the idea that records in the negative cache are used (for "aggressive use").  In section 5:

"If the negative cache of the validating resolver has" ...

To drive home how confusing this is, I have this live example of a zone with a wildcard owning an NSEC set (I sed'd the real name to example):

; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7_3.1 <<>> example.example nsec +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14104
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;example.example.			IN	NSEC

;; ANSWER SECTION:
example.example.		241	IN	NSEC	nic.example. A MX TXT SRV RRSIG NSEC
example.example.		241	IN	RRSIG	NSEC 8 1 300 20171021044514 20170921044514 64884 example. geZpt40NNNE6kTTiMZ8+ubdGWc0k9/MU4VgryRltfn5nTziVbhrNMIkQ 65poyfWL+jtXNZoCOm8GpOzB1c+x+qusA2y3O9AODru/P6LM17e9xTkW t5WvEyvjt2/GiVG2ugjdGZmUZGjX4AKlG0qYz3CBk+a3X215SwsYioN/ sqQ=

;; AUTHORITY SECTION:
*.example.		241	IN	NSEC	nic.example. A MX TXT SRV RRSIG NSEC
*.example.		241	IN	RRSIG	NSEC 8 1 300 20171021044514 20170921044514 64884 example. geZpt40NNNE6kTTiMZ8+ubdGWc0k9/MU4VgryRltfn5nTziVbhrNMIkQ 65poyfWL+jtXNZoCOm8GpOzB1c+x+qusA2y3O9AODru/P6LM17e9xTkW t5WvEyvjt2/GiVG2ugjdGZmUZGjX4AKlG0qYz3CBk+a3X215SwsYioN/ sqQ=

;; Query time: 0 msec
;; SERVER: 10.32.11.34#53(10.32.11.34)
;; WHEN: Thu Sep 21 15:51:16 UTC 2017
;; MSG SIZE  rcvd: 441

In the answer section, the result of the synthesis appears and this would be in the positive cache.  In the authority section, the original record appears and this would go in the negative cache.  "Aggressive use" mentions the use of the negative cache, so I'd say this is consistent.

The begging question: can the cache use the *.example. NSEC to synthesize where the negative cache indicates it would be appropriate to do so?  Sure.  Same as the authority, synthesized in the answer, proving the non-existence of the QNAME in the authority.

On 9/21/17, 08:00, "Edward Lewis" <[email-masked]> wrote:

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Sep 2017 13:56:00 +1000

Such NSEC records are identifiable as part of the validation processs
and can be flagged to be ignored as part of the synthesis process
and/or be stored with the original wildcard name.  As a aside named
saves validated wild card answers with their original wildcard name
so they can be found for data synthesis purposes.

I agree with Ed Lewis that this is not a problem with this RFC4592.

Mark

In message <[email-masked]>, RFC Errata System writes
:
> Synthesizing these records would destroy the semantics of the NSEC chain and c
> ould be very harmful if implementations would cache them and use them for "Agg
> ressive Use of DNSSEC-Validated Cache" (RFC 8198).
> 
> Instructions:
> -------------
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 24 Sep 2017 20:47:02 -0400

This errata report is based on a misunderstanding and should be rejected 
There is no harm in synthesizing NSEC records as long as the owner name of the NSEC record sorts before the target name. 

Olafur

> On Sep 21, 2017, at 6:54 AM, RFC Errata System <[email-masked]> wrote:
>