Re: [DNSOP] draft-ietf-dnsop-no-response-issue-03

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Edward Lewis writes:
> 
> ##   A Common Operational Problem in DNS Servers - Failure To Respond.
> ##                 draft-ietf-dnsop-no-response-issue-03
> 
> I have a lot of high-level concerns with this document.
> 
> ##1.  Introduction
> ##
> ##   The DNS [RFC1034], [RFC1035] is a query / response protocol.  Failure
> ##   to respond to queries or to respond incorrectly causes both immediate
> ##   operational problems and long term problems with protocol
> ##   development.
> 
> While the latter is true, operationally the DNS is not strictly query -
> response.  It's more like "query - if I want to respond".  I was
> "enlightened" during a project 10-15 years ago when I realized that some
> DNS implementations choose silence when deciding how to respond.
> 
> Based on this premise, the prescriptive language in sections 3 and 10
> are very problematic in my opinion.
> 
> ##2.  Common queries kinds that result in non-responses.
> 
> This section is not built on data or a document study, making it seem
> flimsy, to wit:

There is plenty of data.  It's just not cited.

There is years of data at https://ednscomp.isc.org/compliance/summary.html
 
> ##   Some servers fail to respond to ...
> 
> This doesn't establish a need to react to the situation.  "Some" might be
> one operator's code, etc.
> 
> ##3.  Remediating
> 
> This section steers far from the purpose of defining interoperability of the
> protocol.  This section gets too specific regarding the current business
> of DNS registration (registry and registrars) for technical needs.  I don't
> think this section belongs in an IETF document.
> 
> ##7.  Response Code Selection
> ##
> ##   NOERROR (no data) are the expected response codes.  A server is not
> ##   supposed to serve a zone which contains unsupported types ([RFC1034])
> ##   so the only thing left is return if the QNAME exists or not.  NOTIMP
> 
> But we have "Handling of Unknown DNS Resource Record (RR) Types" which
> contradicts that "not supposed to".  This is the closest I'll come to a "nit."

Go and read that RFC carefully.  It does not apply to meta queries.
Meta queries had reserved ranges when it was published.

> ##10.  IANA Considerations
> ##
> ##   IANA / ICANN needs to consider what tests, if any, from above that it
> ##   should add to the zone maintenance procedures for zones under its
> ##   control including pre-delegation checks.  Otherwise this document has
> ##   no actions for IANA.
> 
> There is a lot wrong with that paragraph.  (As in, I'm not sure where to
> start.)  The IANA functions operator manages according to community defined
> processes, there is no internal consideration of what to test.  Further,
> only delegations from the root zone are considered, not anything lower in
> the tree.  (I.e., most of the issues observed wouldn't be touched.)
> 
> This document would be more useful if it clarified the use of RCODEs in the
> face of queries described here, in the vein of "Negative Caching of DNS
> Queries (DNS NCACHE)".  We lack any document describing the circumstances
> in which RCODE values are returned and what the appropriate reaction to them
> is.  As the document stands, it is unspecific regarding issues, particularly
> the operational scale, and ventures into policy instead of technical
> directions regarding operations.
> 
> As an afterthought - Perhaps a whitepaper (non-IETF) can be produced to describe testing methodology and results observed would be an avenue to public
> ize the situation seen here.
> 
> --B_3554361294_203519420
> Content-Type: application/pkcs7-signature; name="smime.p7s"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="smime.p7s"
> 
> MIIH2QYJKoZIhvcNAQcCoIIHyjCCB8YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
> BaIwggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ
> 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+q4vwKnFZjGCAf8wggH7AgEBMHkw
> ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRp
> Z2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAE64fx
> tFjS2DdV8JfouoFSMAkGBSsOAwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQU9we5Ko7uvDTaAky6
> aRtnlxHIYIMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYw
> ODE4MTQzNDU0WjANBgkqhkiG9w0BAQEFAASCAQC49M9tdiQy66uHxpY8/4HF2UmggY9a7nl/
> qLAYkr8XRp0PBuEo8In6zmjavFWEoEaDIzVAVnXFv3BIkKADU/LAgvL8pf69MxZKGoclJwzy
> /ySVhTo3H9mKEPDvYg26Lfva2YNY5YliY77rfL26EXLdm0k6sv+zmq/bFb21ILgOZ+NUt036
> NNHkn4e5z2Dc2SwqVZyQXodLDVHvMhFZapswm6FBipH29YRCNpnrNyw/QWUFrGGK67e0pPvd
> IEU8Go40Wvq86F+tezMapUu8F4xuUZ1vbE7MHMsfPyqzRtkLZHLruCY7n7+6jO5gzfaauRkp
> jA8QN1zvZppw4xLqrYTB
> 
> --B_3554361294_203519420--
> 
> 
> --===============6037154100842559261==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> --===============6037154100842559261==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]