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

Mark Andrews <marka@isc.org> Thu, 18 August 2016 14:59 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6156B12DF55 for <dnsop@ietfa.amsl.com>; Thu, 18 Aug 2016 07:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.148
X-Spam-Level:
X-Spam-Status: No, score=-8.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQCjqctUeJSX for <dnsop@ietfa.amsl.com>; Thu, 18 Aug 2016 07:59:31 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E82E12DCE3 for <dnsop@ietf.org>; Thu, 18 Aug 2016 07:59:31 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 5F3AA3493BB; Thu, 18 Aug 2016 14:59:28 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 49FE016003F; Thu, 18 Aug 2016 14:58:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 35481160072; Thu, 18 Aug 2016 14:58:58 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2v2kHyelj__a; Thu, 18 Aug 2016 14:58:58 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B5F7416003F; Thu, 18 Aug 2016 14:58:57 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DF592517EF2C; Fri, 19 Aug 2016 00:58:54 +1000 (EST)
To: Edward Lewis <edward.lewis@icann.org>
From: Mark Andrews <marka@isc.org>
References: <BC3FCB73-3ECA-4374-8AD5-845A452B6835@icann.org>
In-reply-to: Your message of "Thu, 18 Aug 2016 14:34:54 +0000." <BC3FCB73-3ECA-4374-8AD5-845A452B6835@icann.org>
Date: Fri, 19 Aug 2016 00:58:54 +1000
Message-Id: <20160818145854.DF592517EF2C@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UmTnGzmjijKY4mGuwfuxor6WvoY>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] draft-ietf-dnsop-no-response-issue-03
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2016 14:59:33 -0000

In message <BC3FCB73-3ECA-4374-8AD5-845A452B6835@icann.org>rg>, 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: marka@isc.org