In message <bc3fcb73-3eca-4374-8ad5-845a452b6...@icann.org>, 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 > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --===============6037154100842559261==-- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
