Re: [dnsext] [Ext] [Technical Errata Reported] RFC4592 (5119)

Edward Lewis <> Thu, 21 September 2017 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9EF813214D for <>; Thu, 21 Sep 2017 08:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CY69ytvyNpQ1 for <>; Thu, 21 Sep 2017 08:57:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58619124F57 for <>; Thu, 21 Sep 2017 08:57:09 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 21 Sep 2017 08:57:06 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1178.000; Thu, 21 Sep 2017 08:57:06 -0700
From: Edward Lewis <>
To: RFC Errata System <>, "" <>, Terry Manderson <>, "" <>, "" <>
CC: "" <>, "" <>
Thread-Topic: [Ext] [dnsext] [Technical Errata Reported] RFC4592 (5119)
Thread-Index: AQHTMsgETTnbasncMkKOPIRs+ZkkYaK/skcAgABCDIA=
Date: Thu, 21 Sep 2017 15:57:06 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/f.26.0.170902
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3588839825_1886476913"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [dnsext] [Ext] [Technical Errata Reported] RFC4592 (5119)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Sep 2017 15:57:12 -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

; EDNS: version: 0, flags: do; udp: 4096
;example.example.			IN	NSEC

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=

*.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
;; 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" <> wrote:

    On 9/21/17, 06:54, "dnsext on behalf of RFC Errata System" < on behalf of> wrote:
    >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).
    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.