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

--===============8724205020448902432==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
 micalg=sha1; boundary="B_3588839825_1886476913"

--B_3588839825_1886476913
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: 7bit

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 protected]> wrote:

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

--B_3588839825_1886476913
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIR5gYJKoZIhvcNAQcCoIIR1zCCEdMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D68wggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw
MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv
cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0
aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl
d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws
GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE
wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH
1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H
BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD
LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ
P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw
IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw
fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ
RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB
MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6
Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl
cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA
zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK
7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7
xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K
EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI
dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjCCBk4wggU2oAMCAQIC
EASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV
BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb
RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAwMFoXDTI4MTEwNTEy
MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ
d3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENB
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/AJ3kbLQWHohBDMd8O
1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+yTU7VvEffEJ+
JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo8Ymvzf9e
/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYhrTg8
E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy
czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAO
BgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz
cC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0
LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRp
Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYB
BQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAo
BggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwIC
MIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBp
AGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBl
ACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBk
ACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBu
AHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBk
ACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5
ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8lAvZP3Q5STI8inkw
HwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQELBQADggEBAE7U
iSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZpgeafBMn2+UC
ooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxIEM4zaHvN
k6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaBVUCO
Zu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG
QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3MIICn6ADAgECAhAM
5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQK
EwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp
Z2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAw
MDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3
dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq
9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii
72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PW
w25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqi
uhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn
8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0
ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy
5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU
5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58B
BZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJG
YIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD
+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMG
A1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQD
ExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEATrh/G0WNLYN1Xwl+i6gVIwCQYFKw4D
AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTQKHohCDleeLFFRamIXfeVejJgPzAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA5MjExNTU3MDVaMA0GCSqGSIb3
DQEBAQUABIIBAEBpM3hzziWpc4ElfSfSm0fFDKFsmN86Zi+QsuFn7H6gdTi1PIEZV/aGdRkT
kaOQiCxp/8iHF9vZoWXfpAbIRfd4EvGGw7QgNWyetE0YCVQ9bOvfltW+RmGmX1nNrxwWGWWf
35klC+YFq4aZs2+db77nBa9pcXgrCDz3B0kN+HckaON+emPaBdN0yKXSq7LZ9lXFNhqIO3fM
cSgrSz5R+dYBEe1qz4ZPIP0ebJf3l0UuyD6IElp41Q0/oz4tNmnNjZN8fuOoDHlN4LyrCujd
vdFYtvyMFmpS/MIBmjuqPz2Dz7+5I09i+ZJbTrKXokwrf8haQkovZA6QNLiiOjWoPVI=

--B_3588839825_1886476913--


--===============8724205020448902432==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext

--===============8724205020448902432==--