From nobody Wed Nov 1 04:07:55 2017 Return-Path: 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 344E413F6DE for ; Wed, 1 Nov 2017 04:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YOF6cLY-PEp for ; Wed, 1 Nov 2017 04:07:51 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997DD13F66C for ; Wed, 1 Nov 2017 04:07:51 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 1 Nov 2017 04:07:49 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 1 Nov 2017 04:07:49 -0700 From: Edward Lewis To: Paul Wouters CC: Moritz Muller , =?utf-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , "dnsop@ietf.org" Thread-Topic: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors Thread-Index: AQHTUoHMo0gQ4Vv3GkS3sSxF5cUXoaL/06IA Date: Wed, 1 Nov 2017 11:07:49 +0000 Message-ID: <36701057-FB2C-46DE-BC7B-23CA53D8ECB1@icann.org> References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3592364868_918416071" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 11:07:53 -0000 --B_3592364868_918416071 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 10/31/17, 15:52, "DNSOP on behalf of Paul Wouters" wrote: >this zone can never be stolen from me by a parent. Can you elaborate on this, what do you mean "stolen" by a parent? The reason I am asking - choosing one strategy (any key, configured key rules, DS rules) is based on what one most wants to solve. For "robustness" in the sense of most aggressively getting an answer, opting to accept any (and I'll use the word:) approved key is going to lead to more answers being validated. "More answers" may or may not be a good thing, but the fact is that numerically, having more trusted points from which to build chains will lead to more validated answer sets. By "approved" I mean any key that has passed muster to be a trusted key in the resolver and/or there is a chain of trust from the key set back to another trusted key. Please don't take this as a general definition, I'm using it only within the context of this mail message and only within the confines of the protocol's technical work, not any judgement regarding legitimacy in operations. Back to the question above, to help enumerate the scenarios in which one would opt to not trust a key that has been learned via a chain of trust in the face of a trusted key, it would help to understand what is meant by a parent "stealing" a zone. What I am thinking is: (Un- cut point/DS set is removed, re- cut point/DS set is changed.) 01 A child may be un-delegated by operational error at the parent. 02 A child may be un-delegated in accordance with the registration agreement. 03 A child may be un-delegated outside of the registration agreement. 04 A child may be re-delegated by operational error at the parent. 05 A child may be re-delegated in accordance with the registration agreement. 06 A child may be re-delegated outside of the registration agreement. 07 A child may be un-DSd by operational error at the parent. 08 A child may be un-DSd in accordance with the registration agreement. 09 A child may be un-DSd outside of the registration agreement. 10 A child may be re-DSd by operational error at the parent. 11 A child may be re-DSd in accordance with the registration agreement. 12 A child may be re-DSd outside of the registration agreement. Before getting into the "why's", the impacts of cases: 01-03: Answers for the zone's data will be NXDOMAIN (once TTLs expire) 04-06: Answers will come from a different administrative authority 05-09: Answers will be accepted as Insecure unless the trust anchor is configured 10-12: Answers signed by other keys may be received Cutting along the why's: 01,04,07,10 (Operator error) - The underlying DNS service error must be fixed, in the meantime, flexibility is desired to prevent service disruption. 02,05,08,11 (Justified change) - The issue lies above the level of DNSSEC. By "justified change", this includes term expiration, lack of payment, failing to abide by acceptable use policy, etc. Beyond the scope of the technology, this might even come as a result of a court order, to name a reason for this category. In this case, the parent exerts the protocol prerogative of where it delegates names to enforce whatever policy governs. 03,06,09,12 (Unjustified change) - This would include any reason that could be seen as "corruption" of the registry operator role. I would include all cases of "stolen" to be here, lacking a better definition of "stolen." A dimension I haven't included is whether a validator has a trust anchor for the name in question or not. (If not, then the issue of the conflict doesn't matter.) The next step here is to look at the relative frequency of each case. Mind, I'm not including child operator error in any of this (which would expand the cases). The reason for drilling into this is the assertion that trusting configured trusted keys over the DS record is "the only workable solution". I'm not convinced, I think that the cases in which that is the preferred option is in the minority of the failure modes. What's in the back of my mind is that ultimately, there's still the DNS problem - the parent unilaterally controls the existence and direction of the delegation. DNSSEC can't overcome that. DNSSEC can only choose to be more restrictive (and thus brittle in some sense) or be as lenient as possible (for robustness in the sense of getting an answer to the query). --B_3592364868_918416071 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRumLdBxeRVuIihntuvwM3bJ0UVyDAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMDExMTA3NDhaMA0GCSqGSIb3 DQEBAQUABIIBAAX5IjCt+TLVEot0H3uu2KTAtLv/JlEMa4yjBeUWUeXli3ZGa0SOXr/uUJA3 GZYEmWPCy8vZV5gO9O1wzPenko3ixoReLXxaCqAZ76apqeOX/uzy1BgK/Rmj+1R+xbWEESMO 3ZSfTNQJF5LNlVduzezUNYBgHad3zpV0dlVIGJ9hoK/koAimtBw92MjCezBtQOBXhIdqRb81 TkYjksWiLltiT1lYkkiEqdCiP/tVbFR0qxQO6Mt1I9CUZxdQ2pv4AFz34JP8H55z6ij2DwC/ Can7nf0SxXsNUuPvA781+3fBdkqPhIi8JvdDXAN4AXDMKcwGL1HUftO4Cn6OMrtRzLg= --B_3592364868_918416071-- From nobody Wed Nov 1 04:12:01 2017 Return-Path: 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 9292D13F5FB for ; Wed, 1 Nov 2017 04:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b31dVtTzFNKj for ; Wed, 1 Nov 2017 04:11:59 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AEE9139B9F for ; Wed, 1 Nov 2017 04:11:59 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 1 Nov 2017 04:11:57 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 1 Nov 2017 04:11:57 -0700 From: Edward Lewis To: Mark Andrews , Moritz Muller CC: "dnsop@ietf.org" Thread-Topic: [Ext] Re: [DNSOP] Resolver behaviour with multiple trust anchors Thread-Index: AQHTUiwiqVxvIHBV0Uun1GqDhxVA26L+sniqgAEi/QA= Date: Wed, 1 Nov 2017 11:11:57 +0000 Message-ID: <49FB4D49-C7C7-44E3-B1A6-BA97A9535D83@icann.org> References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <20171101005014.0A2E38DCF888@rock.dv.isc.org> In-Reply-To: <20171101005014.0A2E38DCF888@rock.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3592365116_1740693679" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 11:12:00 -0000 --B_3592365116_1740693679 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 10/31/17, 20:50, "DNSOP on behalf of Mark Andrews" wrote: >Secondly doing deepest match on trust anchors is the only secure way to prevent a parent overriding the child zone's security policy. By this, do you mean choice of cryptographic algorithm and/or length? To achieve "independence" in this way, the child can simply refuse to have a DS record at the parent and then lean on managing trust anchors at all relying resolvers. --B_3592365116_1740693679 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQlb17pY5WUXk9C/cgnrUI9dcqInDAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMDExMTExNTZaMA0GCSqGSIb3 DQEBAQUABIIBABI+uQ01yKudhBWidEuLNVpjUNQgT8dMQwrXk3QRuJJerWg3GEmTaTY0nbLH AKzRBUq80EgsBcE4mIsjKwJZZ2ON+coNP1KQkhnStWcLWL/HIOwIeUHS4B7vugv9AtCVtrGo m+hn+5aPTFgTkzkpVQQb0GzKQOKe2lKw2jwYFckZOoVIYZS3oUQFDUkPqwiVA/8yk695OzC8 edBvzZmcNcA+rz47bqvrB9blRE+QuQLYbjOJBd+iB629nDm5dmkNgKeLOgBEYwjV9JeZJrGN Agn1tDyywm5Riw0CrHwarxPX1W1mHbfk6xktV9Vn5KhcccfWaW6Pcr9r0VbxMwAxEYg= --B_3592365116_1740693679-- From nobody Wed Nov 1 05:17:38 2017 Return-Path: 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 D534313F63A for ; Wed, 1 Nov 2017 05:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 3WR0So-Gii1a for ; Wed, 1 Nov 2017 05:17:35 -0700 (PDT) Received: from vic20.blipp.com (vic20.blipp.com [192.195.142.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB8E13F45D for ; Wed, 1 Nov 2017 05:17:35 -0700 (PDT) Received: by vic20.blipp.com (Postfix, from userid 1000) id 161A93821C; Wed, 1 Nov 2017 13:17:31 +0100 (CET) Date: Wed, 1 Nov 2017 13:17:31 +0100 From: Patrik Wallstrom To: =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= Cc: Moritz Muller , "dnsop@ietf.org" Message-ID: <20171101121730.esajuad5cefebtgg@vic20.blipp.com> Mail-Followup-To: =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= , Moritz Muller , "dnsop@ietf.org" References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 12:17:38 -0000 If I remember the discussions correctly, there was a sense that the resolver decides the local policy. And that yes, those are the three options. Perhaps the options should be made more clear in a text somewhere. On Tue, 31 Oct 2017, Ólafur Guðmundsson wrote: >There are three ways to treat this case: >Any-TruestedKey-works >ConfiguredKey-trumps-DS >DS-trumps-configuredKey > >I think the Last one is the "most" correct from an operational expectation, >but the first one is least likely to run into errors, >But I suspect the middle one is implemented > >Olafur > > >On Tue, Oct 31, 2017 at 2:39 AM, Moritz Muller >wrote: > >> Hi, >> >> Together with my colleagues I have been stumbling upon a, for me, unclear >> case when validating trust anchors. >> >> Assuming that a resolver has enabled DNSSEC validation and has the root >> keys configured. >> Additionally, it has configured manually a trust anchor for a TLD (that >> has also published its DS in the root zone). >> Now, for example due to a key rollover at the TLD, the manually configured >> trust anchor of the TLD does not match the DS in the root anymore. >> >> How should a resolver treat the signatures of this TLD? >> The resolvers of BIND, Unbound, and PowerDNS seem to treat the signatures >> of the TLD as bogus, but we didn't find any specifics in RFC 4034 and 4035 >> that describe how resolvers should behave in this case. >> Knot resolver treats them as NOERROR (according to the developers). >> If we interpret section 4.3 of RFC 4035 then we would have assumed that >> the signature must be treated as secure. >> >> Did we miss something, or is there indeed clarification needed? >> >> — Moritz >> >> >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop From nobody Wed Nov 1 06:48:08 2017 Return-Path: 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 2179B13F90F for ; Wed, 1 Nov 2017 06:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxOcf4k1CfxQ for ; Wed, 1 Nov 2017 06:48:05 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4BF13F4FC for ; Wed, 1 Nov 2017 06:48:05 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 1 Nov 2017 06:48:03 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 1 Nov 2017 06:48:03 -0700 From: Edward Lewis To: Patrik Wallstrom , =?utf-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= CC: Moritz Muller , "dnsop@ietf.org" Thread-Topic: [Ext] Re: [DNSOP] Resolver behaviour with multiple trust anchors Thread-Index: AQHTUiwiqVxvIHBV0Uun1GqDhxVA26L+vEmAgAErf4CAABlJgA== Date: Wed, 1 Nov 2017 13:48:02 +0000 Message-ID: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <20171101121730.esajuad5cefebtgg@vic20.blipp.com> In-Reply-To: <20171101121730.esajuad5cefebtgg@vic20.blipp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3592374482_1189918501" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 13:48:07 -0000 --B_3592374482_1189918501 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 11/1/17, 08:17, "DNSOP on behalf of Patrik Wallstrom" wrote: > If I remember the discussions correctly, there was a sense that the > resolver decides the local policy. And that yes, those are the three > options. Perhaps the options should be made more clear in a text somewhere. The reason why I'm digging into this is that "things change." Back about 15-20 years ago, when the design work was done, the original workshopping, documentation and re-documentation that led to the current RFCs on DNSSEC (numbering 4033-4035), the concerns were a bit different than perhaps they are now that we have operational experience. Local policy is and remains the overriding philosophy of validation. It is purely up to the receiver to determine what they trust. But there's also the operational reality that most users will unbox a tool and rely on default settings until they realize they are unhappy with it and realize how to tweak it. Besides local policy, the principle that plays a role here is maintaining as much robustness as possible. Robustness means - getting answers to user's questions if at all possible. DNSSEC, as an example of "slapped on security" (over an existing system, will inherently cause some once valid states to be invalid, for reasons based on "security." To counter act that (not eliminate it), being conservative on what to block (SERVFAIL) was thought to be a design goal. The desire to maximize robustness is something that might be subject to "things change." During the time of design, there wasn't a mature registration economy (registries, DNS hosting, registrars, etc.), little thought was given to malicious mis-dealings in delegations. I'm thinking in this direction based on a statement that "perfering a local trusted key over the DS record" is "the only way to go" because a "parent could steal a zone." Perhaps what is needed is to examine the situation when it is found that there is a conflict between a trust anchor rooted-chain and a chain that passes up through a DS record on to an upper trust anchor. (Keeping in the back of the mind that a resolver is allowed, via local policy, to build any kind of chain it wants, not just a chain that matches the delegation tree.) 1 - What if a higher-level trust anchor and chain validates an RR set but no trust anchor and chain is possible? I.e., TA(example)->DS(delegation.example)->KEY (delegation.example)->www.delegation.example/IN/NULL validates but TA (delegation.example)->nothing->www.delegation.example/IN/NULL By "nothing" I mean there's no key matching that cited in any RRSIG(NULL) over www.delegation.example/IN/NULL. In a benign world, this should work as it is possible that the trust anchor base is outdated. Perhaps there was a re-delegation, perhaps a misconfiguration. In a malignant world, this would result from a "corrupted" registry. (Where corrupted means, not playing by the rules whether intentionally or not.) 2 - The opposite, the trust anchor validates, not the DS chain This could happen with a child forgetting to tell the parent that they've changed secure entry points, (been there, got a t-shirt and had a cool packet dump to analyze) but also had some population of trust anchor managers playing along. The latter group didn't have errors, the non-players did experience SERVFAILs. 3 - they both work or both fail I don't see an issue. What I'm coming to is ... if there's a choice between being afraid of a malicious registry or being afraid of operational errors, for reasons I don't think are made in this email, I'm still opting to be afraid of operational errors because, well, them I've seen. Are there cases of "corrupted" registries make the threat of "stolen zones" a real thing? --B_3592374482_1189918501 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQLF60huc0oSbt/gdzlwF67CWQdyDAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMDExMzQ4MDFaMA0GCSqGSIb3 DQEBAQUABIIBAK87p2QGxOqRW1VKtm+KqXfGo9qM0vOzqoAsv7kTsXM3ouqTXa7XepkFSniI 9JMmX0Zud5UFwmGbufmj/PiORFfQlYNJ9yEe8dDLNhRg81AWYczg6bCwtLmR/evyfPZyWrXR AECEe49UuVYEkOp24DdvKzWZzOewhTSCFTro2jAhDcaRyhd9CeE8sgdvddej+r6ywEDPxlrC lssnL7bZY0EnGv9miWWfMFx8Y2hOXZsKCQ1yeEhrDF1WmHvyW+JEvvcBzyLjp/Zng4kR9+4i lPVzd9MCZVtSr8/2vTzNjZpXiPB7cNUkhyKiJKaY0vncxETHYxnIv/IzMakH9T6iloQ= --B_3592374482_1189918501-- From nobody Wed Nov 1 07:49:37 2017 Return-Path: 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 090BD13FCA8 for ; Wed, 1 Nov 2017 07:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 PD-vECUapD4J for ; Wed, 1 Nov 2017 07:49:35 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 12F5213F588 for ; Wed, 1 Nov 2017 07:49:35 -0700 (PDT) Received: from [10.32.60.145] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vA1Em9iu057962 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 1 Nov 2017 07:48:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.145] From: "Paul Hoffman" To: "dnsop@ietf.org" Date: Wed, 01 Nov 2017 07:49:32 -0700 Message-ID: <07D1AE36-25CD-46E5-8550-FF99C0BDEC9F@vpnc.org> In-Reply-To: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <20171101121730.esajuad5cefebtgg@vic20.blipp.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 14:49:36 -0000 On 1 Nov 2017, at 6:48, Edward Lewis wrote: > The reason why I'm digging into this is that "things change." As a recap: this thread started with Moritz quoting from RFC 4035 and asking: > Did we miss something, or is there indeed clarification needed? I believe that RFC 4035 indicates success in any chain means that the validator should mark it as Secure. Mike StJohns pointed out that RFC 6840 gave different guidance. That guidance suggests a default scheme and says that it should be up to validator configuration. RFC 6840, which as the the latest standards-track text on the topic, was published in 2013. If things have changed since 2013, an update to RFC 6840 should be started. --Paul Hoffman From nobody Wed Nov 1 08:17:14 2017 Return-Path: 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 8C53B13FD45 for ; Wed, 1 Nov 2017 08:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com 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 NfeI2ionxlzr for ; Wed, 1 Nov 2017 08:17:11 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61FE13FCAD for ; Wed, 1 Nov 2017 08:17:10 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id y39so2224222wrd.4 for ; Wed, 01 Nov 2017 08:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/qQllioozdZbMb9gkGMIrnUf0toEQDFmWdhBQXyrFhY=; b=jRCVA+xUhZR+sPvHjXwY3eYFVUwleWzE2iYMD8n/Oas8bHimhcuBY4b7k5102vFLf4 LPM+QlVpmRA6N7UraIBS/iHWUNzfyW0ahYoC+BxBOpWnF698Uc4nuWEsPNljhtt9gdMc hUwnuj+4f6CplEBD27uOXNvY5Ni8SsA8mc2xw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/qQllioozdZbMb9gkGMIrnUf0toEQDFmWdhBQXyrFhY=; b=Q4nL7Ge05kMHdi3x5Z7HNC5S38rqmjYhYw3R8OsO7w35IyZvfv0skA8q5a0F2kHaZy ILU5imHFURs2fJz0StvYcndx88PqgsKMqu36frsjyLVscH4RyCWemgppK485FwI4tm75 k2tH3NmY7HZtENc+MrcieVz8OxBQ42kIH70vSqCrNUXrchBDw9bOBIILz+lBkO7qvtjW ZsxQde5UTn9Gj0RtOBYM0xj+Fqc+NXv4CM7DE2/zEMXRgQGPUZQqHJy7YQVeg8uNLLxM m6VOO7Bip/oT1DJVi3aDjaRr738kUyY6AFc3P49hIHz3Z0c1Vtgd8apxqLafVG+qym/R Uw/Q== X-Gm-Message-State: AMCzsaUHN6mV/+WAyaDHlG0pmPvG8SOtcieqoQc2OMrzAd/zQRpeOIXu nh/Yz4KW8AcPl1SSV2G7N/PdnwzPj/aiG0DLnInrvUw2 X-Google-Smtp-Source: ABhQp+SstaNejAXxGfV/GTnbkoN8YsGod615nDXczDIIq0UizrPV8s4qkQF+afkSX1y6SOfWtyK++2C6B5ZuwMnOyKc= X-Received: by 10.223.139.85 with SMTP id v21mr163067wra.70.1509549429197; Wed, 01 Nov 2017 08:17:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.201.10 with HTTP; Wed, 1 Nov 2017 08:17:08 -0700 (PDT) In-Reply-To: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Wed, 1 Nov 2017 08:17:08 -0700 Message-ID: To: Paul Wouters Cc: Moritz Muller , "dnsop@ietf.org" Content-Type: multipart/alternative; boundary="f403045e9c927fa60a055ced5da8" Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 15:17:12 -0000 --f403045e9c927fa60a055ced5da8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 31, 2017 at 11:30 AM, Paul Wouters wrote: > > > > On Oct 31, 2017, at 22:25, =C3=93lafur Gu=C3=B0mundsson > wrote: > > > > > > There are three ways to treat this case: > > Any-TruestedKey-works > > ConfiguredKey-trumps-DS > > DS-trumps-configuredKey > > > > I think the Last one is the "most" correct from an operational > expectation, > > Not really, as that would mean you cannot have internal only zones in > split-dns view, unless you are > building in weird assumptions like ConfiguredKeyTrumpsNSECbutNotDS > > > But I suspect the middle one is implemented > > It better, it is the only working solution :) > > The question is that what the "users" expect? I agree that first two have the best operational behaviors, and the third one blocks "split-DNS with different KEY" if Internal domains use the same key as External "equivalent" ones then there is no issue Thus the question is twofold a) is there need for clarification in how protocol works possibly with recommendation for resolver "tunable" settings. b) is there need for operational guidance for "split DNS" DNSSEC I think the answer on both is yes. Olafur --f403045e9c927fa60a055ced5da8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Oct 31, 2017 at 11:30 AM, Paul Wouters <paul@nohats.ca> wrote:


> On Oct 31, 2017, at 22:25, =C3=93lafur Gu=C3=B0mundsson <olafur@cloudflare.com> wrote:
>
>
> There are three ways to treat this case:
> Any-TruestedKey-works
> ConfiguredKey-trumps-DS
> DS-trumps-configuredKey
>
> I think the Last one is the "most" correct from an operation= al expectation,

Not really, as that would mean you cannot have internal only zones i= n split-dns view, unless you are
building in weird assumptions like ConfiguredKeyTrumpsNSECbutNotDS

> But I suspect the middle one is implemented

It better, it is the only working solution :)

The question is that what the "users" expect?
I=C2= =A0 agree that first two have the best operational behaviors, and the third= one blocks "split-DNS with different KEY"=C2=A0
if Int= ernal domains use the same key as External "equivalent" ones then= there is no issue=C2=A0
Thus the question is twofold=C2=A0
=
a) is there need for clarification in how protocol works possibly with= recommendation for resolver "tunable" settings.=C2=A0
= b) is there need for operational guidance for "split DNS" DNSSEC<= /div>

I think the answer on both is yes.=C2=A0

Olafur



<= /div> --f403045e9c927fa60a055ced5da8-- From nobody Wed Nov 1 09:48:13 2017 Return-Path: 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 AD44213F7CD for ; Wed, 1 Nov 2017 09:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 Lj7A57FOow9f for ; Wed, 1 Nov 2017 09:48:09 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD89A13F474 for ; Wed, 1 Nov 2017 09:48:09 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 1 Nov 2017 09:48:07 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 1 Nov 2017 09:48:07 -0700 From: Edward Lewis To: =?utf-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , "Paul Wouters" CC: Moritz Muller , "dnsop@ietf.org" Thread-Topic: [Ext] Re: [DNSOP] Resolver behaviour with multiple trust anchors Thread-Index: AQHTUiwiqVxvIHBV0Uun1GqDhxVA26L+vEmAgAABTICAAVxiAIAAGWoA Date: Wed, 1 Nov 2017 16:48:07 +0000 Message-ID: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3592385286_960282567" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 16:48:12 -0000 --B_3592385286_960282567 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 11/1/17, 11:17, "DNSOP on behalf of =C3=93lafur Gu=C3=B0mundsson" wrote: >Thus the question is twofold=C2=A0 > >a) is there need for clarification in how protocol works possibly with rec= ommendation for resolver "tunable" settings.=C2=A0 > This is something that might be fit into -validator-requirements-. (Which = is perhaps another motivation of mine to dig into this.) But the idea of more knobs to turn and switches to flip runs counter to my = perceived need to simplify the operation of the DNS. The battlefield is def= ined by software developers, who are pushed to add more functionality into s= impler to run packages. Many operators use "off-the-shelf" components and do not write their own co= de, which is what shifts this on to the shoulders of the software developers= . >b) is there need for operational guidance for "split DNS" DNSSEC There was an attempt to document split DNS more than 10 years ago, which di= ed a death of disinterest. (Last version expired 10 years, 1 month, 25 days= ago. ;) Lucky guess.) https://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view-04 Perhaps start there. (Last time I saw the author was in a children's swimm= ing school lobby just last year. Odd.) --B_3592385286_960282567 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTCUcv6Kx/ZPMuGyV5Hih5BpGzRVzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMDExNjQ4MDZaMA0GCSqGSIb3 DQEBAQUABIIBAHodXQat9gX9Ln7hfSlg8BYtFByMYxTKNzt6447qW3IXi64gnFxygrXQzQFu RkJkKQDrw1J0gesNYehM/ynobBECg2pvz8CtA7Nnpfw0LQareBmSWlG4NrMIo+oK2B/EkQsz QjFG+yYfP522EizozYVFAQhAAhrn+jiSCjV0LUgPOd/nNvT/imydzLJpqI0LD3tjzTnio8+N KUyVgIZvqTJ2wHQ/32JXRvo6jNjAph5wXzXBPISPQx1LgONmGGIX+0rDpJtOoSAyUVO6i6/Q r1kG396lSOwPvE4SYU0v9pYpJcdMPqHOOoRhzS3zncBqupUZ2Kr/2dgDmqjYSiI/MjY= --B_3592385286_960282567-- From nobody Wed Nov 1 12:39:53 2017 Return-Path: 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 D53DD13F9C1 for ; Wed, 1 Nov 2017 12:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 FGAEggL04n3B for ; Wed, 1 Nov 2017 12:39:49 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F21613FE71 for ; Wed, 1 Nov 2017 12:39:49 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 425813F44E; Wed, 1 Nov 2017 15:39:48 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23034.8964.229814.270892@gro.dd.org> Date: Wed, 1 Nov 2017 15:39:48 -0400 From: Dave Lawrence To: IETF DNSOP WG , "."@dd.org In-Reply-To: References: <150940619490.28403.7485909732104218964@ietfa.amsl.com> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 19:39:52 -0000 Bob Harold writes: > I don't understand this section: > > 5.1.1. On-the-fly Signatures > ... > One possibly mitigation for addressing the risk of keeping the zone > signing key online would be to continue to keep the key for signing > positive answers offline and introduce a second key for online > signing of negative answers. How dreadfully embarrassing. I'm responsible for that. It was an underdeveloped thought about how multiple keys can possibly be used in a zone to sign different answers. Clearly in the form it made it into the draft it's a bit nonsense. My apologies. It's kind of orthogonal to the main thrust of the BULK proposal though so I expect this bit will just disappear in the next version. From nobody Thu Nov 2 00:02:01 2017 Return-Path: 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 858B513F86B for ; Thu, 2 Nov 2017 00:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 9ImEf35G3VY9 for ; Thu, 2 Nov 2017 00:01:59 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD66513F9A5 for ; Thu, 2 Nov 2017 00:01:57 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id v3so2943829vkb.8 for ; Thu, 02 Nov 2017 00:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DjH5SU67ASIEvL5/fQQWk3O9d+QXXWo7n02dIGmi2Ko=; b=rFDPY+36amXkZrP7940jBncFdGk74UeFDrox5NGNJzrklvqQ5GFpzGzkVDdR3kZ3FH gTLdVcq5OZ3XgbNqqmEd1E8oEbi0d/b0jR2V4A9scxaLL0c/JEJP1UlqLw+IkLj4D4xJ Mn1hFb4jtsr+39u/LjcUOqnBBDAj9113tc7vMVn2Z7VZH4ZoDc4n+XUP9+mIkT5H9pnD yjyB3q5ns2YpzICcdNlzp5s+TV+17mgO6r+oX9OswJMK5tU1/rXs3D+IpetyZG/kh09w Dv/PrMGvOVJ3/JdxuqAjeGe0NvwIZD2UVOykv3krPXfDYsNq5l21gwpSX3Dh9JfhbSgV Lbmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DjH5SU67ASIEvL5/fQQWk3O9d+QXXWo7n02dIGmi2Ko=; b=LX8Te5y2ldbF8vNQf7sei577/dAn6nvVI7TzZuH+wGCnyM21nbo/cwZOtYaXesd1PI lq44zqcRqYb9sHuI6dsg492WnLtrzh99LTuWcu9WKf3zwzxX3Mv7mMxWV6eftf+K6pSD dmlhuBKY/FDSoOtyt+UT0sDBTq1IYD4x+2/VW6h5V0LCR4IuLZB3tgm6WEIQw0VZnJtF /E9L9y2tN3tq7l1mUzu6ls/sCMnRWMkxgU+F6TTxm8SF93/vSzhVlvx37ISrKBFXohhZ sf800C0HpYA3Uno+YoV9kLZCHZw+qmBMfoB6aVPZYbFbHUDd8Vk+G4ichGMvQBCBGTrf hQVg== X-Gm-Message-State: AMCzsaXPQZwcmqdMiPfSTadaP65NGUma3o1e4kFtJvgivxtiuoD9YlCe n97N0YjdBEHvgTBPORUNR75HIq463mIowWmmQ0IMQj+t X-Google-Smtp-Source: ABhQp+TA49ZyhoiB7QMK+9QLQ0Lq9VrHitPscDWOwTSQolObobHY4NHJ4GkUM92QA+zn8Ms72JoSvmBmADJO+M2xPfI= X-Received: by 10.31.0.2 with SMTP id 2mr2040727vka.52.1509606116505; Thu, 02 Nov 2017 00:01:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mike West Date: Thu, 02 Nov 2017 07:01:45 +0000 Message-ID: To: dnsop , tjw ietf Cc: Richard Barnes , "dnsop-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a113da3b053dac7055cfa90b8" Archived-At: Subject: Re: [DNSOP] Agenda topics for IETF100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 07:02:00 -0000 --001a113da3b053dac7055cfa90b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It might be useful to spend a few minutes on the localhost draft to resolve any loose threads from the -01 draft. I won=E2=80=99t be there in person, b= ut I=E2=80=99m happy to either dial in, or lean on folks who will be there to discuss on my behalf. Thanks! -mike On Mon 30. Oct 2017 at 18:59, tjw ietf wrote: > > All > > Please submit any request for presenting at IETF100 to the chairs. We'll > be working on a draft agenda in the interim. > > thanks > tim > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 -mike --001a113da3b053dac7055cfa90b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It might be useful to spend a few minutes on the loc= alhost draft to resolve any loose threads from the -01 draft. I won=E2=80= =99t be there in person, but I=E2=80=99m happy to either dial in, or lean o= n folks who will be there to discuss on my behalf.
<= br>
Thanks!

-mike

On Mon 30. Oct 20= 17 at 18:59, tjw ietf <tjw.ietf@gm= ail.com> wrote:

All

Please submit any request for presenting at = IETF100 to the chairs.=C2=A0 We'll be working on a draft agenda in the = interim.=C2=A0

thanks
tim

=
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
-mike
--001a113da3b053dac7055cfa90b8-- From nobody Thu Nov 2 03:15:23 2017 Return-Path: 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 90B6913F642 for ; Thu, 2 Nov 2017 03:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 5FlwSjCur8xQ for ; Thu, 2 Nov 2017 03:15:19 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 843F113F567 for ; Thu, 2 Nov 2017 03:15:18 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eACWS-0000ElC; Thu, 2 Nov 2017 11:14:52 +0100 Message-Id: To: dnsop@ietf.org Cc: Edward Lewis From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <20171101121730.esajuad5cefebtgg@vic20.blipp.com> In-reply-to: Your message of "Wed, 1 Nov 2017 13:48:02 +0000 ." Date: Thu, 02 Nov 2017 11:14:49 +0100 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 10:15:21 -0000 >Are there cases of "corrupted" registries make the threat of "stolen zones" a >real thing? I think the most well known example is the US government taking the .org domain of Rojadirecta. https://torrentfreak.com/u-s-returns-seized-domains-to-streaming-links-site-after-18-months-120830/ There were two issues in this case: for any organisation outside the US, using a domain with a registry in the US is risky, because the US government assumes jurisdiction, even if the company itself doesn't do any business in the US. The second issue is that the domain was seized by the executive branch. And not just blocked, but actually redirected to servers of the US government. From nobody Thu Nov 2 07:41:42 2017 Return-Path: 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 8B51013F9BD for ; Thu, 2 Nov 2017 07:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NEUTRAL=0.779] autolearn=no 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 TOpRmK9VbnIi for ; Thu, 2 Nov 2017 07:41:38 -0700 (PDT) Received: from smtp85.ord1d.emailsrvr.com (smtp85.ord1d.emailsrvr.com [184.106.54.85]) (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 9FCA013F9B3 for ; Thu, 2 Nov 2017 07:41:38 -0700 (PDT) Received: from smtp19.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id B81E560088; Thu, 2 Nov 2017 10:41:37 -0400 (EDT) X-Auth-ID: matt@kahlerlarson.org Received: by smtp19.relay.ord1d.emailsrvr.com (Authenticated sender: matt-AT-kahlerlarson.org) with ESMTPSA id 72EC760072; Thu, 2 Nov 2017 10:41:37 -0400 (EDT) X-Sender-Id: matt@kahlerlarson.org Received: from [10.96.9.25] (44-2.dc.icann.org [192.0.44.2]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:465 (trex/5.7.12); Thu, 02 Nov 2017 10:41:37 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Matt Larson In-Reply-To: Date: Thu, 2 Nov 2017 10:41:35 -0400 X-Mao-Original-Outgoing-Id: 531326495.305648-488b616488d48c0bfecafdc47f8b37dd Content-Transfer-Encoding: quoted-printable Message-Id: <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> To: Paul Wouters , Ed Lewis , Moritz Muller , =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= , "dnsop@ietf.org" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 14:41:39 -0000 The root KSK rollover project has given me a real appreciation for the = brittleness of trust anchor configuration, even with RFC 5011. = (Automated update support should get better over time, especially after = the first KSK roll exposes problems, but right now it's pretty shaky, = which is my informed opinion based on observation from the operational = trenches.) In the real world, where trust anchors are going to go stale, = an "Accept Any Success" (in the language of Appendix C) trust anchor = policy is the safest operationally. I agree with Ed's observation that operators are, by and large, going to = use the defaults in whatever implementation they're running, so defaults = are important. Trust is always going to be a matter of local policy, so with DNSSEC = there's never going to be a consistent output given a consistent input. = The best we can do is give good guidance to implementors, ideally based = on operational experience, to inform their choices for the default = settings that operators will end up using. I think RFC 6840 gets it right: it acknowledges that trust anchor = preference is a matter of local policy, but recommends an operationally = safe default of "Accept Any Success". Why would one want a "Closest Encloser" trust anchor preference policy? = I've heard two reasons in this thread: 1. The untrusted parent scenario: I submit there's no practical = implication of distinguishing between the parent's control of the = delegation and its control of the DS: the child zone is completely at = the will of the parent zone, so if your parent has it in for you, you = lose. This scenario is not sufficient motivation, in my opinion, to = suggest "Closest Encloser" as a default policy. 2. In a split DNS context, reject answers that leak into the wrong view: = I think using DNSSEC as a backstop to enforce split DNS policy is a = dubious operational practice and likewise not sufficient motivation to = suggest "Closest Encloser" as a default policy. In my perfect world, implementations would offer a knob to set "Closest = Encloser" for consenting adults but default to "Accept Any Success". Matt From nobody Thu Nov 2 08:04:57 2017 Return-Path: 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 B674813FA5A for ; Thu, 2 Nov 2017 08:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 l9KHAcD6-nEf for ; Thu, 2 Nov 2017 08:04:53 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8117D13F92E for ; Thu, 2 Nov 2017 08:04:53 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id a192so5364897pge.9 for ; Thu, 02 Nov 2017 08:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0BCqiF+91mxqdKUcQdRF8h4nLA/AWiw+g8aiKdWQbzc=; b=GL9jJtAZDc5BMapa2nljfyOK2QWpA6lBGlt7MOnVOI+riEoN+Cq33/Q2+nyR8zWhyU MoFNfCL0OX/z+iSXhWa7qlC3GR4xUYz9sxurHOUbakBt2V51NAzcQ25dd4jy7vV4Cq3W ZOEVezR2jksIOHBPk7bynQZ6BToPngcZ/eV7TfcrXdGNFsM+iKq9kd4NgbfT+HpvzTUM APvaYYUQt0BuaHm/8kgNBeCLHGxOQijC/y8jpiPC4mAl8aMz12qh1AF6m43S/7AwUC0h nv1Z0mSZQgde7uXwpEtYyLHOlkzja2pyqfxlEQ/KPq9nM9zjOs3tqgxYawe9fi6jSku4 XoKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0BCqiF+91mxqdKUcQdRF8h4nLA/AWiw+g8aiKdWQbzc=; b=gw+3ohyjx1sGkHySqZG0YZxDA+Ffx9VrJKeTk3S0YO/3J5TSZFWDEguugnCKlVC/w6 J3SDm/5cxRMIjZg5r0iL7UZsUHZK6EY1Z2s30HiQUz26ythB7KOP3pbd//txDBnVYRfC q5lJcsLQ0blsEhNrI45wp3Uk1K7jRQ5pQwiIyUbHFgF7ihzgNSf3hgOgAeYjqJdzvh1c SjQfTneig5qCVo7NK7zbYHQSIxwlJftxTndVcx2p7rALdJZ/WBlQnHUuqrBG26ePQyVU naCp/o85ds5tr0h5eBWl4jwDP6jYTjBxoAMRYZA7JU3cDUo9sbot3CE/r/UgmqCIYo7p miwQ== X-Gm-Message-State: AMCzsaXP1yeaHM64dRULvj1F5zdbWcy5hI5Vl5ataVxm/LKEGSjZwkEY TvdmGxsKk3fL9vQ7oZz8wzarExZS4AvmeGm9ZBCM7w== X-Google-Smtp-Source: ABhQp+Sz74+sgTQ3R/vo8E2tf6J1Sz50ek1T23de1l2xJfkVgwsaB5fdys/icNX3f6fE+CJEVhgAF0c15XGOYJcrKlw= X-Received: by 10.99.112.29 with SMTP id l29mr3895374pgc.2.1509635092970; Thu, 02 Nov 2017 08:04:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.4 with HTTP; Thu, 2 Nov 2017 08:04:52 -0700 (PDT) In-Reply-To: <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> From: Bob Harold Date: Thu, 2 Nov 2017 11:04:52 -0400 Message-ID: To: Matt Larson Cc: Paul Wouters , Ed Lewis , Moritz Muller , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , "dnsop@ietf.org" Content-Type: multipart/alternative; boundary="f403045c749c751387055d014f80" Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 15:04:56 -0000 --f403045c749c751387055d014f80 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson wrote: > The root KSK rollover project has given me a real appreciation for the > brittleness of trust anchor configuration, even with RFC 5011. (Automated > update support should get better over time, especially after the first KSK > roll exposes problems, but right now it's pretty shaky, which is my > informed opinion based on observation from the operational trenches.) In > the real world, where trust anchors are going to go stale, an "Accept Any > Success" (in the language of Appendix C) trust anchor policy is the safest > operationally. > > I agree with Ed's observation that operators are, by and large, going to > use the defaults in whatever implementation they're running, so defaults > are important. > > Trust is always going to be a matter of local policy, so with DNSSEC > there's never going to be a consistent output given a consistent input. The > best we can do is give good guidance to implementors, ideally based on > operational experience, to inform their choices for the default settings > that operators will end up using. > > I think RFC 6840 gets it right: it acknowledges that trust anchor > preference is a matter of local policy, but recommends an operationally > safe default of "Accept Any Success". > > Why would one want a "Closest Encloser" trust anchor preference policy? > I've heard two reasons in this thread: > > 1. The untrusted parent scenario: I submit there's no practical > implication of distinguishing between the parent's control of the > delegation and its control of the DS: the child zone is completely at the > will of the parent zone, so if your parent has it in for you, you lose. > This scenario is not sufficient motivation, in my opinion, to suggest > "Closest Encloser" as a default policy. > > 2. In a split DNS context, reject answers that leak into the wrong view: I > think using DNSSEC as a backstop to enforce split DNS policy is a dubious > operational practice and likewise not sufficient motivation to suggest > "Closest Encloser" as a default policy. > > In my perfect world, implementations would offer a knob to set "Closest > Encloser" for consenting adults but default to "Accept Any Success". > > Matt > I generally agree with you, but wonder if there is a performance penalty to searching every possible path before failing. Is that a reasonable concern? How many paths are there? I can think of: 1. To the root 2. To a local trust anchor 3. To a DLV provider (gone as of Sept 30?) If local trust anchors are checked before the root, and they are under operator control, then maybe "Closest Encloser" is a reasonable default. I don't know where to fit DLV into that plan. Also, if an operator does not configure DLV or local trust anchors, then is root the only path? So "Closest Encloser" and "Accept Any Success" are the same? Or am I not understanding something (no experience with this yet)? -- Bob Harold --f403045c749c751387055d014f80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson <matt@kahlerlarson.org> wrote:
T= he root KSK rollover project has given me a real appreciation for the britt= leness of trust anchor configuration, even with RFC 5011. (Automated update= support should get better over time, especially after the first KSK roll e= xposes problems, but right now it's pretty shaky, which is my informed = opinion based on observation from the operational trenches.) In the real wo= rld, where trust anchors are going to go stale, an "Accept Any Success= " (in the language of Appendix C) trust anchor policy is the safest op= erationally.

I agree with Ed's observation that operators are, by and large, going t= o use the defaults in whatever implementation they're running, so defau= lts are important.

Trust is always going to be a matter of local policy, so with DNSSEC there&= #39;s never going to be a consistent output given a consistent input. The b= est we can do is give good guidance to implementors, ideally based on opera= tional experience, to inform their choices for the default settings that op= erators will end up using.

I think RFC 6840 gets it right: it acknowledges that trust anchor preferenc= e is a matter of local policy, but recommends an operationally safe default= of "Accept Any Success".

Why would one want a "Closest Encloser" trust anchor preference p= olicy? I've heard two reasons in this thread:

1. The untrusted parent scenario: I submit there's no practical implica= tion of distinguishing between the parent's control of the delegation a= nd its control of the DS: the child zone is completely at the will of the p= arent zone, so if your parent has it in for you, you lose. This scenario is= not sufficient motivation, in my opinion, to suggest "Closest Enclose= r" as a default policy.

2. In a split DNS context, reject answers that leak into the wrong view: I = think using DNSSEC as a backstop to enforce split DNS policy is a dubious o= perational practice and likewise not sufficient motivation to suggest "= ;Closest Encloser" as a default policy.

In my perfect world, implementations would offer a knob to set "Closes= t Encloser" for consenting adults but default to "Accept Any Succ= ess".

Matt

I generally agre= e with you, but wonder if there is a performance penalty to searching every= possible path before failing.=C2=A0 Is that a reasonable concern?

How many paths= are there?=C2=A0 I can think of:
1. To the= root
2. To a local trust anchor
3. To a DLV provider (gone as of Sept 30?)

If local trust a= nchors are checked before the root, and they are under operator control, th= en maybe "Closest Encloser" is a reasonable default.=C2=A0 I don&= #39;t know where to fit DLV into that plan.

Also, if an operator does not configu= re DLV or local trust anchors, then is root the only path?=C2=A0 So "C= losest Encloser" and=C2=A0"Accept Any Success" are the same?=
Or am I not understanding something (no ex= perience with this yet)?

Bob Harold

--f403045c749c751387055d014f80-- From nobody Thu Nov 2 08:11:09 2017 Return-Path: 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 D85AE13F996 for ; Thu, 2 Nov 2017 08:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Z-UJcQypVLTM for ; Thu, 2 Nov 2017 08:11:07 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 10B3D13F92E for ; Thu, 2 Nov 2017 08:11:07 -0700 (PDT) Received: from [10.32.60.113] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vA2F9faK039806 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Nov 2017 08:09:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.113] From: "Paul Hoffman" To: "Bob Harold" Cc: "dnsop@ietf.org" Date: Thu, 02 Nov 2017 08:11:04 -0700 Message-ID: In-Reply-To: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 15:11:08 -0000 On 2 Nov 2017, at 8:04, Bob Harold wrote: > I generally agree with you, but wonder if there is a performance > penalty to > searching every possible path before failing. Is that a reasonable > concern? These are reasonable questions, ones that were actively discussed in the PKIX world 20+ years ago. The consensus conclusion was that any performance penalty was worth the consistency of answers, since the relying part (the stub resolver in our case) had no control over the order of evaluation. > Also, if an operator does not configure DLV or local trust anchors, > then is > root the only path? All trust anchors are "local", so the question becomes "if an operator does not configure DLV or any trust anchors". The former is now moot, and the latter goes against a bunch of MUST statements in the standard. --Paul Hoffman From nobody Thu Nov 2 08:27:40 2017 Return-Path: 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 58007139680 for ; Thu, 2 Nov 2017 08:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 3Y3uOZq2c95F for ; Thu, 2 Nov 2017 08:27:37 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09AD313FA9F for ; Thu, 2 Nov 2017 08:27:37 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id p96so5373956wrb.7 for ; Thu, 02 Nov 2017 08:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vlDJyD4Kog8LnHHbdikxMdrZglmI9dHQ1hEN7Xavwho=; b=z7S0uK4xlrza982pWXCYZ/9N+scFpEeZ51VEnJMdjGtSPHGENPdTMfY9hgG+4BI/Jg 41IZN/dA4occr9+ckg1ckkoP4ErDeF51mMR0V33U5hPI3Zx8avbyQn1hG1dmYFAp39ir FoM2lZGhx+2F0CP6clRMRX81vKpJhXe7epyVGOHj9r24IbqvnlQ6p7kNYpMGmNWQvJe4 FokZaJZ67yoc0HZjbCmQNfIDndzobyh+4obABmKLDzDxyctBYck/3LnpoMvjVnPKe6V+ KjFKSJhvfhy4TVWuca0lPbKeZQEfklRTXx13jK2toiCzgjOMx3HBFV6JZRaKm7L1kNAa t82A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vlDJyD4Kog8LnHHbdikxMdrZglmI9dHQ1hEN7Xavwho=; b=cX0lp7RIUpAAUvkycnJfwLFBlE5MvrtQKqRhVpmh+B1aclKfa7YPpItb3EBZzcHW/Q RgIH3nbqOBKO5Qkc98+pDQTcb/aRMwHdEWrfayQir2boiyQgdbGk4GdaQW+/pHGfiuud ng6ilnyEbz+gd7LZEDr/kw7ds6njSACGdsStKs3YvhudUig8FazKuNnTajf+iON/91/0 v8+CQKl+ffyE1p9oleXRrs42dll1X1mu0/1hPZMJJhIvTBOwyqAGPPY2W6r6/FIXhNKO mL62H5R9ZmhZSNcVw+iT1yca/pLCLJz/5XAuWc0tBPTKyRUrBvrzR9evwigprgehy+fN 5VtQ== X-Gm-Message-State: AMCzsaUtY3d+Ft989MhzRsLOU4jM2tIl7cp1F9nFxsba/gspWisKw0ni 9rJiLPE9Pa29Mnef0X8Sy64QqHOb59cXqM0Si8Iziw== X-Google-Smtp-Source: ABhQp+SaNctSvvm61wOZDw8/74XNAXJuJbQgOA2fKEgbaVx7t/iHbS2h0za0b7b4shuosjs2VE/5lewfDTRQi+EkrL8= X-Received: by 10.223.187.143 with SMTP id q15mr3111324wrg.184.1509636455213; Thu, 02 Nov 2017 08:27:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.187.12 with HTTP; Thu, 2 Nov 2017 08:26:54 -0700 (PDT) In-Reply-To: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> From: Warren Kumari Date: Thu, 2 Nov 2017 11:26:54 -0400 Message-ID: To: Bob Harold Cc: Matt Larson , Ed Lewis , Moritz Muller , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , Paul Wouters , "dnsop@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 15:27:39 -0000 On Thu, Nov 2, 2017 at 11:04 AM, Bob Harold wrote: > > On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson wrote: >> >> The root KSK rollover project has given me a real appreciation for the >> brittleness of trust anchor configuration, even with RFC 5011. (Automated >> update support should get better over time, especially after the first KSK >> roll exposes problems, but right now it's pretty shaky, which is my informed >> opinion based on observation from the operational trenches.) In the real >> world, where trust anchors are going to go stale, an "Accept Any Success" >> (in the language of Appendix C) trust anchor policy is the safest >> operationally. >> >> I agree with Ed's observation that operators are, by and large, going to >> use the defaults in whatever implementation they're running, so defaults are >> important. >> >> Trust is always going to be a matter of local policy, so with DNSSEC >> there's never going to be a consistent output given a consistent input. The >> best we can do is give good guidance to implementors, ideally based on >> operational experience, to inform their choices for the default settings >> that operators will end up using. >> >> I think RFC 6840 gets it right: it acknowledges that trust anchor >> preference is a matter of local policy, but recommends an operationally safe >> default of "Accept Any Success". >> >> Why would one want a "Closest Encloser" trust anchor preference policy? >> I've heard two reasons in this thread: >> >> 1. The untrusted parent scenario: I submit there's no practical >> implication of distinguishing between the parent's control of the delegation >> and its control of the DS: the child zone is completely at the will of the >> parent zone, so if your parent has it in for you, you lose. This scenario is >> not sufficient motivation, in my opinion, to suggest "Closest Encloser" as a >> default policy. >> >> 2. In a split DNS context, reject answers that leak into the wrong view: I >> think using DNSSEC as a backstop to enforce split DNS policy is a dubious >> operational practice and likewise not sufficient motivation to suggest >> "Closest Encloser" as a default policy. >> >> In my perfect world, implementations would offer a knob to set "Closest >> Encloser" for consenting adults but default to "Accept Any Success". >> >> Matt > > > I generally agree with you, but wonder if there is a performance penalty to > searching every possible path before failing. Is that a reasonable concern? > > How many paths are there? I can think of: > 1. To the root > 2. To a local trust anchor > 3. To a DLV provider (gone as of Sept 30?) I have no actual data, so I'll pontificate instead :-) I suspect that there is a really small set of resolvers with more than just the root TA -- and if the resolver operator *has* configured a local TA they have done this for a reason important to them, and so presumably are willing to pay the performance cost. Having a (per-TA) knob sounds like a nice compromise, but I'd really like implementors to chime in on how much complexity this adds. If *I* added a local TA for .example (or foo.example.com) I'd automatically assume that this is a closest encloser / Negative Trust Anchor / longest match type operation and would be very surprised if that wasn't the behavior -- this *may* be a combination of being primarily a routing person, and also the fact that if I create a local zone for foo.example.com (in a non-DNSSEC world) I'd expect it to take priority... W > > If local trust anchors are checked before the root, and they are under > operator control, then maybe "Closest Encloser" is a reasonable default. I > don't know where to fit DLV into that plan. > > Also, if an operator does not configure DLV or local trust anchors, then is > root the only path? So "Closest Encloser" and "Accept Any Success" are the > same? > Or am I not understanding something (no experience with this yet)? > > -- > Bob Harold > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Nov 2 08:27:59 2017 Return-Path: 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 5A69113FAAD for ; Thu, 2 Nov 2017 08:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 uhpMaXw8wP5G for ; Thu, 2 Nov 2017 08:27:46 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38FC913FAA3 for ; Thu, 2 Nov 2017 08:27:46 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 2 Nov 2017 08:27:44 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 2 Nov 2017 08:27:44 -0700 From: Edward Lewis To: Bob Harold , Matt Larson CC: Paul Wouters , Moritz Muller , =?utf-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , "dnsop@ietf.org" Thread-Topic: [Ext] Re: [DNSOP] Resolver behaviour with multiple trust anchors Thread-Index: AQHTU+i9bgXp0SADEEG6x6vd1yaJ3qMBpWUAgAAGY4A= Date: Thu, 2 Nov 2017 15:27:44 +0000 Message-ID: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3592466863_1372802540" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 15:27:50 -0000 --B_3592466863_1372802540 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 11/2/17, 11:04, "Bob Harold" wrote: >I generally agree with you, but wonder if there is a performance penalty t= o searching every possible path before failing.=C2=A0 Is that a reasonable conce= rn? There are a bunch of tradeoffs to consider. (I'll start with "it is a conc= ern" but not sure if it's "something to be afraid of.") For one, in terms of latency (time to answering the question), if the attem= pts are in parallel then there's arguably less impact, as network latency mi= ght be greater than compute latency. ("Might" is the operative word.) One of the old debates between myself and Olafur was whether the cost of a = network retrieval was greater than or less than the cost of a cryptographic = operation. That debate is so old I've forgotten which of us sided with whic= h side. I do know that we never resolved it, knew it wasn't generally resol= vable, and would probably change over time anyway. For two, in terms of load on the network (more traffic), it's hard to know.= Depends on what is cached, how often the work is done, whether it is each = validation or not. (You'd only have the question arise when you have a trus= t anchor besides the root to consider - the frequency might be dependent on = whether split-DNS is an issue or not, and so on.) For three, performing actions in parallel complicate code writing. If you = were educated in the days before thread packages existed, you are tempted to= try serially. (pthreads, IEEE Std 1003.1c-1995, came along too late in the= game for me.) Younger kids are apparently able to multi-task better these = days, I hear, so I hope that makes for better code (a'la Go). There's always the "one branch gives me this result, the other branch seems= to be hitting a timeout" case meaning sometimes you have to estimate when i= t's time to give up and get on with it. It's that case that makes coders im= plement "first result wins" more often than is probably wise. This is what makes "robustness" a tricky thing (and why I like to dive into= this again now and then). If "robust" means returning as much data to a qu= ery as possible (like finding the one working secure chain), you might risk = breaking a different definition of "robust" for the relying application, whi= ch has a time-deadline to meet. In short - it's a tradeoff of time (latency) and maximizing validation of a= nswers (robustness) which depends a lot on how the code is implemented and t= he workload provided. Like looking for a needle in a haystack - the longer = you look the higher the chance you will find it, with how you look being a f= actor in speed, as well as the size of the haystack, number of needles prese= nt, etc. --B_3592466863_1372802540 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBR+XBy+pojD3Rvu18KpjdLUtq4vZzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMDIxNTI3NDNaMA0GCSqGSIb3 DQEBAQUABIIBAITtx563JUx8R/rNOylzqOg32kSExBtZ14SympW1ESUvLsj/H603YKjDcri/ MsztCjUGfnd+SNV62GwvyCdIo2yaeSUr8PD9LNHU2/S+mt2A7fY2iKwOhN32sPlH5t+WECDV Pb6isDxkcdgFDRhsC9UVEwpH/m4Wt6Y2HjEVSsro7wCwPfSNKfRS2VV/J1ozSpuybSg/PjCm UkLJGjDbJA6cRp0qblHXYI616MzCfRpp6UCjVtF3cssCNgQxfVlzlsWWzK87/dN0OCFqZYeT WMw3yiDh2noDLo4871eQeY70hBx4K67ZFnN41pxSgWL03Thr+Ac+hZrEb9TPtJ56JOA= --B_3592466863_1372802540-- From nobody Thu Nov 2 08:41:57 2017 Return-Path: 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 8308413F82F for ; Thu, 2 Nov 2017 08:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 IRdcSgyXdtyZ for ; Thu, 2 Nov 2017 08:41:52 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92E113F44D for ; Thu, 2 Nov 2017 08:41:52 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 2 Nov 2017 08:41:51 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 2 Nov 2017 08:41:51 -0700 From: Edward Lewis To: Warren Kumari , Bob Harold CC: =?utf-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , "Matt Larson" , Moritz Muller , "Paul Wouters" , "dnsop@ietf.org" Thread-Topic: [Ext] Re: [DNSOP] Resolver behaviour with multiple trust anchors Thread-Index: AQHTU+i9bgXp0SADEEG6x6vd1yaJ3qMBpWUAgAAGKACAAAQsAA== Date: Thu, 2 Nov 2017 15:41:51 +0000 Message-ID: <1E0EA91F-CAB7-4BB9-A528-D2E60C8E4187@icann.org> References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3592467710_1414157198" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 15:41:54 -0000 --B_3592467710_1414157198 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 11/2/17, 11:27, "DNSOP on behalf of Warren Kumari" wrote: > Having a (per-TA) knob sounds like a nice compromise, but I'd really > like implementors to chime in on how much complexity this adds. If *I* > added a local TA for .example (or foo.example.com) I'd automatically > assume that this is a closest encloser / Negative Trust Anchor / > longest match type operation and would be very surprised if that > wasn't the behavior -- this *may* be a combination of being primarily > a routing person, and also the fact that if I create a local zone for > foo.example.com (in a non-DNSSEC world) I'd expect it to take > priority... This is an interesting viewpoint. I understand that in the routing world, longest match prefix is the way the outgoing interface is chosen. This doesn't translate into the design of DNSSEC though. (Like a pun in English isn't quite the same in any other language and vice versa.) The issue in routing is that you have to choose one solution and go with it. Unless you are multi/broadcasting, the packet is going to go on to one outgoing buffer/queue. The issue in DNSSEC is to retain as much robustness as possible because the decision will have a long-lasting impact (sitting in cache, opening an ssh connection, etc.) This mirrors what Paul said in an earlier message regarding PKIX. On 11/2/17, 11:11, "DNSOP on behalf of Paul Hoffman" wrote: >The consensus conclusion was that any performance penalty was worth the consistency of answers, since the relying part (the stub resolver in our case) had no control over the order of evaluation. Consistency is the objective there, not robustness, but I'd hand-wave the two are closely related. Consistency, in terms of coherence, has historically been part of the DNS rhetoric, which (I'll claim) is a/one foundation for DNSSEC's robustness. So, I get that from a routing backdrop, the longest match expectation is reasonable but not what was written into the DNSSEC documents because DNS and DNSSEC have different objectives than routing (or forwarding, whichever is more appropriate). --B_3592467710_1414157198 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBS/nLhjyo40TnxZCJlbsHPdE/fgLDAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMDIxNTQxNTBaMA0GCSqGSIb3 DQEBAQUABIIBABQZYwhgucsx/1yMQBufevevxCRDhjh5ynjHQPS5HuqeBvZBIGB0JAS9OtDo nYV2lAp8sAB83OFZDO5KDO58niqfu6M5NEd/rJv1b1igUzZA88GcdslwNdUPU0u4A0GEemXN OtcIfOCrx0+yiRkAKQiwpno9X8CaiftSs6o3imrP4g9zH/TF4RD8MmCHh1dArtISUenlBWvC nAOK2hmf40HhPGd8ud8Kcv6xCuTf1cUeu5yftxoK0gzHBBaPqQTYR4Ub3tYSAM/+qCToc2lK Xts7d7lyfcEkyG1AfsYcPF6ZDaDniD71ap+NBNTiRuI2E1ZdKf0w71MdFgbvaNU9+X4= --B_3592467710_1414157198-- From nobody Thu Nov 2 08:49:35 2017 Return-Path: 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 BE377139504 for ; Thu, 2 Nov 2017 08:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 ESe9vNPatZ1y for ; Thu, 2 Nov 2017 08:49:32 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 1E78E13F967 for ; Thu, 2 Nov 2017 08:49:31 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:56916) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eAHk8-000yTL-0n (Exim 4.89) (return-path ); Thu, 02 Nov 2017 15:49:20 +0000 Date: Thu, 2 Nov 2017 15:49:20 +0000 From: Tony Finch To: Bob Harold cc: Matt Larson , Ed Lewis , Moritz Muller , =?UTF-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= , Paul Wouters , "dnsop@ietf.org" In-Reply-To: Message-ID: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 15:49:34 -0000 Bob Harold wrote: > > How many paths are there? I can think of: > 1. To the root > 2. To a local trust anchor These are actually the same path since you'll find the relevant local trust anchors in the process of walking down from or up to the root. (Or, down from or up to the closest enclosing validated DNSKEY.) > 3. To a DLV provider (gone as of Sept 30?) I have a half-formed evil plan to use DLV to distribute trust anchors for reverse DNS zones that lack DS records (RFC 1918 and others). One managed key is easier than c. 20 keys! As Mark said, DLV only applies when the normal path says insecure. > Also, if an operator does not configure DLV or local trust anchors, then is > root the only path? So "Closest Encloser" and "Accept Any Success" are the > same? Closest encloser implies to me that you don't fall back to looking at the DS records if you can't validate a DNSKEY that has a local trust anchor. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fisher, German Bight: Northwest 5 or 6, occasionally 7 in Fisher, backing southwest 4 or 5 later. Moderate, occasionally rough for a time. Showers. Good. From nobody Thu Nov 2 08:53:50 2017 Return-Path: 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 90B0013FABC for ; Thu, 2 Nov 2017 08:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 phMJu9k8CV1p for ; Thu, 2 Nov 2017 08:53:46 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 1358F13F710 for ; Thu, 2 Nov 2017 08:53:46 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:57298) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eAHoL-0001Qn-2c (Exim 4.89) (return-path ); Thu, 02 Nov 2017 15:53:41 +0000 Date: Thu, 2 Nov 2017 15:53:41 +0000 From: Tony Finch To: Paul Hoffman cc: Bob Harold , "dnsop@ietf.org" In-Reply-To: Message-ID: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 15:53:48 -0000 Paul Hoffman wrote: > On 2 Nov 2017, at 8:04, Bob Harold wrote: > > > I generally agree with you, but wonder if there is a performance penalty to > > searching every possible path before failing. Is that a reasonable concern? > > These are reasonable questions, ones that were actively discussed in the PKIX > world 20+ years ago. The consensus conclusion was that any performance penalty > was worth the consistency of answers, since the relying part (the stub > resolver in our case) had no control over the order of evaluation. It's worth noting that the PKIX chain of trust is a directed graph whereas the DNS is a tree, and trees are a lot easier to follow. (No loops etc.) Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fitzroy: Cyclonic 4 or 5, increasing 6 at times. Slight or moderate. Rain or thundery showers. Good, occasionally poor. From nobody Thu Nov 2 09:38:27 2017 Return-Path: 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 4276813F4F4 for ; Thu, 2 Nov 2017 09:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 XE3u3OKlYSlC for ; Thu, 2 Nov 2017 09:38:24 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21D9D13B262 for ; Thu, 2 Nov 2017 09:38:24 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id p186so252492ioe.12 for ; Thu, 02 Nov 2017 09:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H7z8sALIMF+cSCF+rqefREjQ0npJh5m7X0FvqzrSZyI=; b=ULhpz3VfOy/UcMaT46pZQdedhL2mktFyn62FX64ePPFWngQYNqZvqSPPQHC/sdhBU/ fqv+Fy390E5igjOeibGWqd9bqYUZMFjuIp2ms6vH0dsHRmh/tO+PHsyvKu/mlR19IjqX /SIbXm26AUfKyX5rnTkIok7DvSru99xpRJO8w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H7z8sALIMF+cSCF+rqefREjQ0npJh5m7X0FvqzrSZyI=; b=OLg2R6GGE681NCxzdOTxHtcV1QmPiHNjnfYlXfAS9pgmh+oxpPZaZXizd9YxSg6a+M SJa9gpV4HWQ8ZGYsJODPDcVIDcBWuv4oX4PJqOFbeTghrvPfDew/nODY+GA03C0+BEZX YTK93MW52PgyMLd2CXSS5p9ziJK4nWFczu/h48KPDSkWtUt8P47plImTrVCi6d8QjnPz 8kDgN08QoFnykH4yp0NipHNzzm+WFT1RfnuKK6zfoWOizpKx/kacIdQ+2SWHg1UtY1c1 aNkrEyCrgg9eQTBOo05wZTHoK/xdP1m9Z+HM1slTwp9EeSRqD+LcwaaxY5Vf7hkWJ3Rs j/ow== X-Gm-Message-State: AMCzsaW5NER58xHN2GoEPd+d70W/M0lnrvhjqEdBtSCfEW9uPkbEieQ/ DvjQWZrdC9fiNfNbuBG8Ukwixw== X-Google-Smtp-Source: ABhQp+TaHIqxWM6T5etZVjvhIHtGxHD+FBqicz1uI0Xqn+R64NIXC4b3/aFd6Cuc2SEzp9naofkYUw== X-Received: by 10.36.0.207 with SMTP id 198mr3375526ita.128.1509640703395; Thu, 02 Nov 2017 09:38:23 -0700 (PDT) Received: from node-131fec9w2t6im3n57e.ipv6.teksavvy.com ([2607:f2c0:101:202:546:52b9:e331:151a]) by smtp.gmail.com with ESMTPSA id b13sm1798632iod.16.2017.11.02.09.38.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 09:38:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Joe Abley In-Reply-To: Date: Thu, 2 Nov 2017 12:38:18 -0400 Cc: Larson Matt , Ed Lewis , Moritz Muller , =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= , Paul Wouters , "dnsop@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <956BA758-D584-44BB-8E7C-7F0843F4CA99@hopcount.ca> References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> To: Bob Harold X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 16:38:26 -0000 On 2 Nov 2017, at 11:04, Bob Harold wrote: > I generally agree with you, but wonder if there is a performance = penalty to searching every possible path before failing. Is that a = reasonable concern? I think there's a much bigger performance penalty from returning an = error to an application and requiring an end-user to do something; the = small delay introduced by validating a signature chain against a = different trust anchor is likely smaller than that in the event that = validation subsequently succeeds and irrelevant in the case that it = fails. I think that the performance angle, whilst always worth considering e.g. = for impact on scaling properties, is a red herring in this particular = case. I think the focus on what policy makes sense and where it should = be applied is the right one. Joe From nobody Thu Nov 2 10:27:33 2017 Return-Path: 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 1519613F6FF for ; Thu, 2 Nov 2017 10:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 PAi24RetPXsG for ; Thu, 2 Nov 2017 10:27:30 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id C5B1613F6F3 for ; Thu, 2 Nov 2017 10:27:29 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 86A6D3743A42; Thu, 2 Nov 2017 17:27:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 767nvnlxsRJB; Thu, 2 Nov 2017 13:27:24 -0400 (EDT) Received: from Maxs-MBP.hsd1.co.comcast.net (c-67-176-54-195.hsd1.co.comcast.net [67.176.54.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 6274B3741035; Thu, 2 Nov 2017 13:27:24 -0400 (EDT) To: Shane Kerr Cc: dnsop@ietf.org References: From: "Dr. Pala" Organization: OpenCA Labs Message-ID: Date: Thu, 2 Nov 2017 11:27:23 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030008050506060407070405" Archived-At: Subject: Re: [DNSOP] New I-D for OCSP over DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 17:27:32 -0000 This is a cryptographically signed message in MIME format. --------------ms030008050506060407070405 Content-Type: multipart/alternative; boundary="------------08B285D00D26D2B8C812F310" Content-Language: en-US This is a multi-part message in MIME format. --------------08B285D00D26D2B8C812F310 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Shane, thanks for the reply and feedback, we do really appreciate :D For the=20 replies to your comments, see inline. Again, thanks! On 10/30/17 3:23 AM, Shane Kerr wrote: > Dr. Pala, > [...] > Some minor points, and then on to major issues.... > > Section 6.3, "Time Validity" might be tricky. Someone reading the > specification may infer that authoritative DNS servers are supposed to > look at the OSCP record and clamp TTL to the expiration of the OCSP > response. While there is some precedence for this (in RRSIG records), > those are limited to cryptography that is for the DNS itself. > > My recommendation here is that it be made clear that as an operational > matter that operators ensure that the records are published in a way > that the TTL is low enough that they expire from caches before the OCSP= > response expiration. Thanks. This is a good point. I will update the draft and add this=20 consideration. It is to be noted that, today, most of the pre-computed=20 OCSP tokens/responses are generated at specific times (few times a day)=20 and usually have a configured validity time. This is probably easy to=20 implement also in the DNS case where the ZONE file might be updated at=20 specific times and the TTL, in that case, would be the same for all entri= es. Good point, I will add some specific considerations for that. > > Section 7.2, "Use of TXT Records" may hit a problem similar to what > happened with the SPF record. In SPF (a mail authentication & > authorization technology), early implementations used TXT records. The > DNS community encouraged a switch to a "real" RRTYPE for this. However,= > what ended up happening is that implementations had to support SPF *and= * > TXT records. This was extra work and even extra packets on the wire, an= d > eventually the next SPF revision deprecated the SPF type. > > If the OSCPRR is not yet widely deployed, I would suggest at the very > least changing "MAY use TXT records" to "SHOULD NOT use TXT records". I= f > it is widely deployed, then... ug. ;) I do agree with this point. I will remove the TXT example/suggestion. > > Now on to the big stuff. :) > > I think that more work needs to be done explaining why DNS is a more > efficient delivery mechanism than HTTP or some other technology. If the= > idea is that resolvers provide "free" caching close to the user then > this may be reasonable. If the idea is that DNS is a simple UDP > protocol, then this may quite possibly backfire when you stick largish > cryptographic blobs into the DNS responses; DNS is probably less > efficient than HTTP then because you'll get UDP responses that tell you= > to switch to TCP... instead of starting with TCP in the first place. The main point of this I-D is to allow for simple "caching" closer to=20 the user. So, it is not about UDP or "low-latency" (as someone else in=20 other WG asked about). This I-D is meant to leverage the widely=20 distributed nature of the DNS so that operational costs can be lowered=20 (from a Certification Authority point of view and the revocation=20 information has another channel/transport mechanism that (in my opinion) = will ease the use of revocation information in applications (not only=20 browsers) and IoT space. So, "free" caching is the target for us. > > Next, I think you may want to consider more security implications in > pressing the DNS infrastructure into service as a critical component of= > a PKI infrastructure. > > Unlike HTTP, most DNS traffic is not encrypted (there are not even any > drafts proposing a solution in the resolver-to-authoritative server > space). This means that, for example, an attacker who gains access to > DNS logs may not be able to infer clients who have not updated their > revocation lists in a way that was not previously possible. I am not sure about your point on the DNS logs - could you elaborate a=20 little bit more? For the security of the communication (i.e., DNS=20 traffic not being encrypted), consider that, today, most (if not all)=20 the major Internet Certification Authorities distribute the pre-computed = OCSP responses via CDNs over HTTP (not HTTPS). This is because all the=20 OCSP responses are signed, therefore they can not be forged. However,=20 this approach has security implications about MITM attacks that are the=20 same as the DNS ones. > None of this means that the proposal is a bad idea, just that more text= > would make it more convincing. > Again, I do really appreciate the feedback :D The whole point of IETF is = to mold a good ideas by one person/group into a great idea that=20 incorporates feedback from experts in different fields :D Our goal is to = provide a good alternative to HTTP that is also easy to deploy so that=20 it can be adopted and deployed easily. Cheers, Max --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------08B285D00D26D2B8C812F310 Content-Type: multipart/related; boundary="------------8B1060B15AE21F4D3D1E96A3" --------------8B1060B15AE21F4D3D1E96A3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Shane,

thanks for the reply and feedback, we do really appreciate :D For the replies to your comments, see inline.

Again, thanks!


On 10/30/17 3:23 AM, Shane Kerr wrote:= 
Dr. Pala,
[...]
Some minor points, and then on to major issues....

Section 6.3, "Time Validity" might be tricky. Someone reading the
specification may infer that authoritative DNS servers are supposed to
look at the OSCP record and clamp TTL to the expiration of the OCSP
response. While there is some precedence for this (in RRSIG records),
those are limited to cryptography that is for the DNS itself.

My recommendation here is that it be made clear that as an operational
matter that operators ensure that the records are published in a way
that the TTL is low enough that they expire from caches before the OCSP
response expiration.
Thanks. This is a good point. I will update the draft and add this consideration. It is to be noted that, today, most of the pre-computed OCSP tokens/responses are generated at specific times (few times a day) and usually have a configured validity time. This is probably easy to implement also in the DNS case where the ZONE file might be updated at specific times and the TTL, in that case, would be the same for all entries.

Good point, I will add some specific considerations for that.

Section 7.2, "Use of TXT Records" may hit a problem similar to what
happened with the SPF record. In SPF (a mail authentication &
authorization technology), early implementations used TXT records. The
DNS community encouraged a switch to a "real" RRTYPE for this. However,
what ended up happening is that implementations had to support SPF *and*
TXT records. This was extra work and even extra packets on the wire, and
eventually the next SPF revision deprecated the SPF type.

If the OSCPRR is not yet widely deployed, I would suggest at the very
least changing "MAY use TXT records" to "SHOULD NOT use TXT records". If
it is widely deployed, then... ug. ;)
I do agree with this point. I will remove the TXT example/suggestion.

Now on to the big stuff. :)

I think that more work needs to be done explaining why DNS is a more
efficient delivery mechanism than HTTP or some other technology. If the
idea is that resolvers provide "free" caching close to the user then
this may be reasonable. If the idea is that DNS is a simple UDP
protocol, then this may quite possibly backfire when you stick largish
cryptographic blobs into the DNS responses; DNS is probably less
efficient than HTTP then because you'll get UDP responses that tell you
to switch to TCP... instead of starting with TCP in the first place.
The main point of this I-D is to allow for simple "caching" closer to the user. So, it is not about UDP or "low-latency" (as someone else in other WG asked about). This I-D is meant to leverage the widely distributed nature of the DNS so that operational costs can be lowered (from a Certification Authority point of view and the revocation information has another channel/transport mechanism that (in my opinion) will ease the use of revocation information in applications (not only browsers) and IoT space.

So, "free" caching is the target for us.

Next, I think you may want to consider more security implications in
pressing the DNS infrastructure into service as a critical component of
a PKI infrastructure.

Unlike HTTP, most DNS traffic is not encrypted (there are not even any
drafts proposing a solution in the resolver-to-authoritative server
space). This means that, for example, an attacker who gains access to
DNS logs may not be able to infer clients who have not updated their
revocation lists in a way that was not previously possible.
I am not sure about your point on the DNS logs - could you elaborate a little bit more? For the security of the communication (i.e., DNS traffic not being encrypted), consider that, today, most (if not all) the major Internet Certification Authorities distribute the pre-computed OCSP responses via CDNs over HTTP (not HTTPS). This is because all the OCSP responses are signed, therefore they can not be forged. However, this approach has security implications about MITM attacks that are the same as the DNS ones.
None of this means that the proposal is a bad idea, just that more text
would make it more convincing.
Again, I do really appreciate the feedback :D The whole point of IETF is to mold a good ideas by one person/group into a great idea that incorporates feedback from experts in different fields :D Our goal is to provide a good alternative to HTTP that is also easy to deploy so that it can be adopted and deployed easily.

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------8B1060B15AE21F4D3D1E96A3 Content-Type: image/png; name="oopiddefeffceckm.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="oopiddefeffceckm.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------8B1060B15AE21F4D3D1E96A3-- --------------08B285D00D26D2B8C812F310-- --------------ms030008050506060407070405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfUwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU+MIIEJqADAgECAhEA/bu0LJsAKXVhEpPllE0lYzANBgkq hkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE2MTEzMDAwMDAwMFoXDTE3MTEzMDIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ ARYTZGlyZWN0b3JAb3BlbmNhLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKnGg/GUuTjn0dKCEpRhVd+uiYbCjLQht+dbkvyRLm4aqlL7yHCe+21HQLIcU68ZCHT2ImpF CFFrxQMQh4KijAwkbLc8+xZZSwXeZt58qnPn5c4vcpYU5LFq1q9oDT8MXH33DhVUT/7/IDSi wRWM6FcgM6VrIjBmmvl9dW3gQaEd1bOAhO2X489fChRQYTaB6AEhqb8RSvWW7ZYzfNw8sPxV afMCzWBPpO5RmLqOciZBhAinAM9dXmP5ckg/HjJQYSjvTc7HDcg75mpr5wH8Tk/ChyIYk4CT zqONQV8HKCzZPTVmd2ZuMrliJwMFs3uEg0aBSzHjJTyAmZ89q5Mz3XsCAwEAAaOCAfEwggHt MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTGgh9JWBvcrak1 PhAWBLGrECNAjzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3Bl bmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAdIqtPcvA+g6VTYUpEo0I9Vtnrf9PiZ3OpkRL O7U78EaeUfvOotThqj74XyrIl6eYlg+EdGIIUVB1CI05wPMRlZN3/R/Tj28vWkwckLRIbpL4 A5ZQyKgA9vK15/EEBVFIpCtAI6xJX0zx6TySlIgjcca05L0JgO7nzLGD2MY/dVWEE+QBuNI+ NBci+c+9q6YDPoXOpo0Wwbe0Bq95jNNWmZwhGzc+N5rhOGZmQT4P7TnpzvMik8ugbkqWyyHa DQbLKYzM1RKS/mwcvFqjJCQgORnaCilSbfClwdWGI7vwcTR8eAzduvwG61u46Cgb57K5sMck RicpWRvEYxCCVTwnozGCBEQwggRAAgEBMIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCWCGSAFlAwQC AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEx MDIxNzI3MjNaMC8GCSqGSIb3DQEJBDEiBCAH5jTq4vmr7+ZrTldPxj8BweXZNv9IAGNyGSBj 99sUMzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBAKeFK7LIyd4YZxrc fFakKkHfxs9PbctRlkat5AUQwKXLkpYEKNJ8PIvfj/FsIkunYxjkqk1gbjKuF8kqS6MFGIfe WORI6S4l5fYmpOLOg8Pz6/Rs+Arjyq0KscQMjVsesgnvXIp6UEoeZ2hWnZqElF729bW0yyJW mxLgNuUY3y4C5AVBpixoUeluG/J9UVnx9Tw4orJL7xEm8barFysZdTZZ+W69dzJu/+VTSlwC H940j23mev+MCU6Bpm0CDB+591Lh2KRQ4hrAOTZIij+hreBp8qVjbb2rogVTsdm/7gACfPvZ t7BB83OxrKogtVbUiCnsWJW825/j8CTvS96+opMAAAAAAAA= --------------ms030008050506060407070405-- From nobody Thu Nov 2 12:58:42 2017 Return-Path: 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 9787813F8FA for ; Thu, 2 Nov 2017 12:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fqjePI6SdPLx for ; Thu, 2 Nov 2017 12:58:38 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB0713F8EB for ; Thu, 2 Nov 2017 12:58:38 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id 101so1609226ioj.3 for ; Thu, 02 Nov 2017 12:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Yo/e9CshoDL7qG5lhR6I6doH0VJCQXPbWFrLbFxQHYc=; b=iyZtR4AhxOhXH3YoqUfOarPZqk3OAU5pbu/ml209TiYk/ggiWwN4idUXrFudlkn0Em 0OZ2tFNtcfo+KCMWmOfOzaqcfeeFCo0PaZAF3aFGT1T/HiGtEtsQ04Gnml+nig87ayh8 C/9TB8xnudx6zsQQQcTHotEYK9snijtzA+iP17wkwHuuV2HtmJUWWKhv8KHNtlYF/rZS amjBv4VdV1e1ZHXrPdopcjjlXAVfawXlGoLvsRuyGIiFTwvUHHoev+MRKjIEOmSE8geA AMXnzvF5O+/K4+6BMNUY6fk25v0mEzGqa+uDxHW8F81L3o9VA6GhUCp7D+DXhh7AmXNb h+/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Yo/e9CshoDL7qG5lhR6I6doH0VJCQXPbWFrLbFxQHYc=; b=FKT49kgfHspAopm798kEazhYwnCzBmG5qVKyv4SL9KC2IygjmSyX01niMUBABW+let AkMUL8pMaWajwSclJYSh2HCpis9Rxc4Io0mXJ4o8JFYmy3Z5wqfcUaVrUVXdsrC+EcWr i/riuEjLfx7sd8/G5NK2HpfBY31iSmNPAtrtPbkpwgXv/MSHynJD3vIrGhlnNdrAPR3+ pVgGrst9oTcU++HIci4bMQmJocDxEZhKVzscQp8H2GklcCJIwcUfrpYtB+xzNxVzwhNW JKW8QTDWUunuaVlmzi9aXhMmqWp0llymIgnSdj93ycCGXS1qQ+3V3EpR06I4wBIqxe42 SOSA== X-Gm-Message-State: AMCzsaV1mkJfgGz16FgcA5yvi+2EQvEYIzIWa7ZxGLFamwNeQySBfZlw UhsJ1CgU4rPnkEht4J1+UmDIOGC3BViMAWM6BNs= X-Google-Smtp-Source: ABhQp+QuuCDzSF9dAe9MXN5bexL95gsedQTQkRVAwDFs1C0VzGgHn2KCNTxucYJ858oCidz+4CsU7WjkT3R0N/OV22M= X-Received: by 10.36.123.149 with SMTP id q143mr4129964itc.122.1509652717688; Thu, 02 Nov 2017 12:58:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.208.79 with HTTP; Thu, 2 Nov 2017 12:58:37 -0700 (PDT) From: Brian Dickson Date: Thu, 2 Nov 2017 12:58:37 -0700 Message-ID: To: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="001a11473fcaf8da95055d0569fb" Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 19:58:41 -0000 --001a11473fcaf8da95055d0569fb Content-Type: text/plain; charset="UTF-8" (Apologies for neither top- nor bottom- posting, i.e. not quoting any other emails.) There are corner cases which exist, where desired behavior of some resolvers is not possible to achieve. This mostly has to do with constraints where "local policy" may have more than one scope. I.e. Inside a big enough org, there may be a "large" local policy which conflicts with local policy of smaller sub-orgs. Here's an example: - Suppose an enterprise E has perimeter resolvers, which do not validate DNSSEC. - Suppose that E blocks DNS traffic to the outside world, except from those perimeter resolvers. - Now suppose a small org within E, call it E-prime, deploys DNSSEC using its own local trust anchor. The issue has to do with not only which trust anchor is preferred for any given portion of the DNS tree, but also whether the policy of "validation" applies, and with what scope. There may be other corner cases, but the main point is that the above scenario does not depend on any notion of "split DNS" per se. The E-prime element is, for sake of argument, still globally resolvable, but happens to be an "island of security". There is no split DNS. I think the question may boil down to the following: - What local policies might operators need to configure? - What advice to implementers can be provided, given the possible complexities of what operators need? - Does it make sense to formalize (or at least categorize) policy logic? - What defaults are likely to maximize "correct" behavior, and/or minimize failures? - E.g. suppose the presence of trust anchors in non-5011 configuration files, vs trust anchors in 5011 configuration files, and suppose multiple trust anchors. Is the mere existence of a trust anchor sufficient to signal intent, or is it always the case that some policy needs to be declared over the combination of all existing trust anchors? Brian --001a11473fcaf8da95055d0569fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Apologies for neither top- nor bottom- posting, i.e. not = quoting any other emails.)

There are corner cases which = exist, where desired behavior of some resolvers is not possible to achieve.=

This mostly has to do with constraints where &quo= t;local policy" may have more than one scope.

I.e. Inside a big enough org, there may be a "large" local polic= y which conflicts with local policy of=C2=A0 smaller sub-orgs.
Here's an example:
- Suppose an enterprise E has= perimeter resolvers, which do not validate DNSSEC.
- Suppose tha= t E blocks DNS traffic to the outside world, except from those perimeter re= solvers.
- Now suppose a small org within E, call it E-prime, dep= loys DNSSEC using its own local trust anchor.

The = issue has to do with not only which trust anchor is preferred for any given= portion of the DNS tree, but also whether the policy of "validation&q= uot; applies, and with what scope.

There may be ot= her corner cases, but the main point is that the above scenario does not de= pend on any notion of "split DNS" per se. The E-prime element is,= for sake of argument, still globally resolvable, but happens to be an &quo= t;island of security". There is no split DNS.

I think the question may boil down to the following:
- What loca= l policies might operators need to configure?
- What advice to im= plementers can be provided, given the possible complexities of what operato= rs need?
- Does it make sense to formalize (or at least categoriz= e) policy logic?
- What defaults are likely to maximize "cor= rect" behavior, and/or minimize failures?
- E.g. suppose the= presence of trust anchors in non-5011 configuration files, vs trust anchor= s in 5011 configuration files, and suppose multiple trust anchors. Is the m= ere existence of a trust anchor sufficient to signal intent, or is it alway= s the case that some policy needs to be declared over the combination of al= l existing trust anchors?

Brian
--001a11473fcaf8da95055d0569fb-- From nobody Thu Nov 2 14:24:49 2017 Return-Path: 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 516AB13F65E for ; Thu, 2 Nov 2017 14:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 6rVrAy0kA5FB for ; Thu, 2 Nov 2017 14:24:45 -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 D429013B11B for ; Thu, 2 Nov 2017 14:24:45 -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 8E7DF3AC656; Thu, 2 Nov 2017 21:24:31 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 36EEF16007C; Thu, 2 Nov 2017 21:24:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1DA0416008A; Thu, 2 Nov 2017 21:24:31 +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 OnFbP0dM0ix1; Thu, 2 Nov 2017 21:24:31 +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 C8DCE16007C; Thu, 2 Nov 2017 21:24:30 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2FB1A8EAAC52; Fri, 3 Nov 2017 08:24:28 +1100 (AEDT) To: Edward Lewis Cc: Warren Kumari , Bob Harold , Matt Larson , =?utf-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , Paul Wouters , "dnsop@ietf.org" , Moritz Muller From: Mark Andrews References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> <1E0EA91F-CAB7-4BB9-A528-D2E60C8E4187@icann.org> In-reply-to: Your message of "Thu, 02 Nov 2017 15:41:51 -0000." <1E0EA91F-CAB7-4BB9-A528-D2E60C8E4187@icann.org> Date: Fri, 03 Nov 2017 08:24:28 +1100 Message-Id: <20171102212428.2FB1A8EAAC52@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 21:24:48 -0000 This is only about which trust anchors applies for a given name with you have several configured with different names. Multiple trust anchors with the same name is still any match will do. There are enough senarios where you want *only* the closest trust-anchor to apply that that is what was coded. This does however result in occassional breakages when that trust anchor is not keep up to date and it is only being used to provide a trust anchor for a site in the event of a link failure. That said if you have the trust anchor there for link failures you *need* to keep them up to date or they do not do their job when the link fails. Having validation fail is a good way to show that they are out of date and that your processes have failed. I don't see a reason to change from only using the deepest match. It is the best overall strategy. If you are getting validation failures because the trust anchors are out of date, fix the process that keeps the trust anchors up to date. Once that is done worring about DS overriding a configured trust anchor is moot. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Nov 3 13:07:44 2017 Return-Path: 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 6509913FF78 for ; Fri, 3 Nov 2017 13:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bDv_hHI-na9a for ; Fri, 3 Nov 2017 13:07:40 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4393613FF77 for ; Fri, 3 Nov 2017 13:07:40 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id w105so3489547wrc.0 for ; Fri, 03 Nov 2017 13:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=QBVkKA6HwaKe9+YIai7SMSBCLrADaeUPciBcCcMAH48=; b=NpCP2MEe7P//LDwsAzZ4kHbaIzjseeHU1DeeIAPU3oapkAJ/qbizAm+6WjRB9lLVjA 4K0E9uS+qzO4902LrHMDukwl5CLcarrZMI8m4mpfhMLTI9EtJsWb4JT0DSz/Loh58u/4 SX2vUKtV2Z56qi78/jsSHWgz3NetJ2RnrwShxTSHIvMczuf9bedhdeNJNesZ00gj7K4X CFTNEp5Hvt/F82wSJT2UdR993e74zu3aS2LBQDoEWLo4/c1XR6K9Ol8WYB250t1+aBTP 0WNo6f9rh2CtmlUVH+hW3ruyHxmVNAvnTqwiOSoT/aX6zdXxBvniLiaKzak7UQnxJy00 CT3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=QBVkKA6HwaKe9+YIai7SMSBCLrADaeUPciBcCcMAH48=; b=p/DYwZtV7U4oUgdpBOutk0rQi+Kq42PAhCfET8axV/imw4ty+QIDMXOwgWWIUhKDRk S7AxAQrIHidolYzAGJNFDoC2RrMvs1BUuGyAmHXwTOdQeABwBlAMj4UVGYPRl+WxZEcC paHOZy9o+YSdnCWC/2fNCNDrJdP+pcANUkJU+LuVeACDaIzlS1/zXLSNiKjxDnolpaCi jWmERVvD5B/NTdPiPVQHrvkDBF1eEszRrHCU01PvlVJnS6sjop0pA0kh+V2buXgMuGT0 oNLPNIsGwCMRpguDK/5zp2HlgyrwUye/GoFkhathfQWD7D+7JzWQkx4LTHbTEHWUQ4VM XxxA== X-Gm-Message-State: AMCzsaWTIxPpmR8MyMqQtv12UzK2V9fyhZXhFtNvRa1Pf6X6UTqfweiV RRKvQ+7PsQdbOpj9r0HjGl3ZCjzMyXKRngRWSOI= X-Google-Smtp-Source: ABhQp+RQ9YwS2auXCyPFLmVJT25DB53cSkAW2YWmAaLkP+w2o1Y6F7mT+Nf1T/891xIFgUBULcDtySHRyVdE6Q0lcc4= X-Received: by 10.223.153.234 with SMTP id y97mr6716240wrb.165.1509739658679; Fri, 03 Nov 2017 13:07:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.184.60 with HTTP; Fri, 3 Nov 2017 13:07:38 -0700 (PDT) In-Reply-To: <61d64c0a-ebd8-528c-5255-ec5205405fdc@nthpermutation.com> References: <04C3E53E-985F-49DD-A731-A2DE0911538B@vpnc.org> <61d64c0a-ebd8-528c-5255-ec5205405fdc@nthpermutation.com> From: tjw ietf Date: Fri, 3 Nov 2017 16:07:38 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="f403045f4d1a0f1954055d19a832" Archived-At: Subject: Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-rfc5011-security-considerations X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 20:07:43 -0000 --f403045f4d1a0f1954055d19a832 Content-Type: text/plain; charset="UTF-8" All The Working Group Last Call has ended on this draft two days ago, with two problems. First, there was not enough comments from folks calling it ready for publication, and second, there are two strong voices against publishing this document. With one against, we could work some rough consensus, though the second set of comments need to be addressed. The authors are addressing the issues, and hopefully have a new version before the meeting, and we can revisit this. thanks tim On Thu, Oct 26, 2017 at 1:42 PM, Michael StJohns wrote: > On 10/26/2017 11:11 AM, Warren Kumari wrote: > > Wes and I do believe that this is an important document - getting > these timers wrong potentially has really bad security implications; > > > So, pretty please, review this document and send feedback. We've tried > hard to make it readable, but the topic is unfortunately complex and > can only be simplified so far - it is also really hard to talk about > sliding windows of time. > > > *sigh* > > > It's really not complex and its neither a timer nor an interval nor a > window - but a fixed point in time given the input data: > > earliest date when its safe to revoke ALL old trust anchor keys ::= latest > expiration date of any RRSet containing the key(s) to be revoked + > queryInterval (from 5011) + holdDownTime (from 5011) + queryInterval (from > 5011) > > > earliest date when the zone owner thinks its safe to revoke all the old > keys ::= the above + safetyFactor > > The first query time is the maximum time it takes for all resolvers to > make their first query (assuming no retries). The second query time is the > time for all resolvers to make the "next query after the hold down time > expires" (again assuming no retries). > > The safety factor is there primarily to deal with network outages AT THE > RESOLVER and is a SWAG that should represent a value that captures the > answer to the question "given the retry interval and a 99% network uptime > and N resolvers, how long until 99.99% of the resolvers have completed all > necessary retries at both the beginning and the end of the process?" Like > most retry questions, this has a bi-modal answer - given a reliable > network, the vast majority of resolvers will be successful in small > multiples of the retry interval. A very tiny few will not be successful > even after 100s of retries. The SWAG should pick a number of retries that > balances the operational need to complete the process with the possibility > of a few resolvers not getting the word. > > so: safetyFactor ::= retryInterval (from 5011) * (5 + func(N)) - 5 is a > SWAG to set a minimum for even a small group of resolvers. > > > I was thinking Log2(N) - which would give 23 for 10 million resolvers or > 28*retryInterval. Or something suitably non-linear.... > > > Note that "latest expiration date of any RRSet containing the key(s) to be > revoked" makes a worst case assumption: that the pre-signed RRSets are not > necessarily protected from disclosure. If this is not true, then this > reduces down to "the latest expiration date of any RRSet containing the > keys to be revoked that has been seen publicly". The document SHOULD > assume that any signed RRSet may be available to an attacker whether it's > been published in the DNS or not. > > 5011 was a timer based document because it applied to each resolver in > each resolver's time domain. When a timer fired on resolver A, it had no > impact on the behavior of resolver B nor on the DNS server that was being > queried. > > With this document, the 5011 timer intervals are useful only to figure out > an earliest possible safe date given the previous live data set. When > that (those) data set become irrelevant for the purposes of Wes' attack is > pretty straight forward: when it expires! The 5011 intervals can be used > to calculate forward from that DATE and TIME to get an idea of when most > well-behaving resolvers will have accepted new trust anchors even if they > were being attacked. Note "most". There is no guarantee that even if you > waited 6 years that all resolvers would get the new trust anchors and you > just need to accept that the fall back is for the resolver owner to fix the > problem when it occurs. > > This discussion has been helpful because it forced me to consider two > things the root does that I never contemplated in 5011: 1) A steady state > of a single trust anchor and 2) pre-signing RRSets. Neither of these > affects the resolver implementation, but both make the publishing/signing > schedules more security sensitive - hence this document. > > Later, Mike > > > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --f403045f4d1a0f1954055d19a832 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All

The Working Group Last Call has end= ed on this draft two days ago, with two problems. =C2=A0 First, there was n= ot enough comments from folks calling it ready for publication, and second,= there are two strong voices against publishing this document.=C2=A0 With o= ne against, we could work some rough consensus, though the second =C2=A0set= of comments need to be addressed.

The authors are= addressing the issues, and hopefully have a new version before the meeting= , and we can revisit this.

thanks
tim




On Thu, Oct 26, 2017 at 1:42 PM, Micha= el StJohns <msj@nthpermutation.com> wrote:
=20 =20 =20
On 10/26/2017 11:11= AM, Warren Kumari wrote:
Wes and I do believe that this is an important document - gett=
ing
these timers wrong potentially has really bad security implications;

So, pretty please, review this document and send feedback. We=
9;ve tried
hard to make it readable, but the topic is unfortunately complex and
can only be simplified so far - it is also really hard to talk about
sliding windows of time.


*sigh*


It's really not complex and its neither a timer nor an interval nor a window - but a fixed point in time given the input data:

earliest date when its safe to revoke ALL old trust anchor keys ::=3D latest expiration date of any RRSet containing the key(s) to be revoked + queryInterval (from 5011) + holdDownTime (from 5011) + queryInterval (from 5011)


earliest date when the zone owner thinks its safe to revoke all the old keys ::=3D the above + safetyFactor

The first query time is the maximum time it takes for all resolvers to make their first query (assuming no retries).=C2=A0 The second query time is the time for all resolvers to make the "nex= t query after the hold down time expires" (again assuming no retries).=C2=A0

The safety factor is there primarily to deal with network outages AT THE RESOLVER and is a SWAG that should represent a value that captures the answer to the question "given the retry interval an= d a 99% network uptime and N resolvers, how long until 99.99% of the resolvers have completed all necessary retries at both the beginning and the end of the process?"=C2=A0 Like most retry que= stions, this has a bi-modal answer - given a reliable network, the vast majority of resolvers will be successful in small multiples of the retry interval.=C2=A0=C2=A0 A very tiny few will not be successful ev= en after 100s of retries.=C2=A0 The SWAG should pick a number of retries that balances the operational need to complete the process with the possibility of a few resolvers not getting the word.

so:=C2=A0 safetyFactor ::=3D retryInterval (from 5011) * (5 + func(N= ))=C2=A0 - 5 is a SWAG to set a minimum for even a small group of resolvers.


I was thinking Log2(N) - which would give 23 for 10 million resolvers or 28*retryInterval.=C2=A0=C2=A0 Or something suitably non-linear....


Note that "latest expiration date of any RRSet containing the key(s) to be revoked" makes a worst case assumption:=C2=A0 that = the pre-signed RRSets are not necessarily protected from disclosure.=C2=A0=C2=A0=C2=A0 If this is not true, then this reduces = down to "the latest expiration date of any RRSet containing the keys to be revoked that has been seen publicly".=C2=A0 The document SHOULD = assume that any signed RRSet may be available to an attacker whether it'= s been published in the DNS or not.

5011 was a timer based document because it applied to each resolver in each resolver's time domain.=C2=A0 When a timer fired= on resolver A, it had no impact on the behavior of resolver B nor on the DNS server that was being queried.

With this document, the 5011 timer intervals are useful only to figure out an earliest possible safe date given the previous live data set.=C2=A0 When that=C2=A0 (those) data set become irrelevant fo= r the purposes of Wes' attack is pretty straight forward: when it expires!=C2=A0=C2=A0 The 5011 intervals can be used to calculate forw= ard from that DATE and TIME to get an idea of when most well-behaving resolvers will have accepted new trust anchors even if they were being attacked.=C2=A0 Note "most".=C2=A0 There is no guaran= tee that even if you waited 6 years that all resolvers would get the new trust anchors and you just need to accept that the fall back is for the resolver owner to fix the problem when it occurs.

This discussion has been helpful because it forced me to consider two things the root does that I never contemplated in 5011:=C2=A0 1) = A steady state of a single trust anchor and 2) pre-signing RRSets.=C2= =A0 Neither of these affects the resolver implementation, but both make the publishing/signing schedules more security sensitive - hence this document.

Later, Mike






_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--f403045f4d1a0f1954055d19a832-- From nobody Fri Nov 3 20:08:00 2017 Return-Path: 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 E4ACC13FAE0 for ; Fri, 3 Nov 2017 20:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XiUf_93Zuo7p for ; Fri, 3 Nov 2017 20:07:57 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D546413FADC for ; Fri, 3 Nov 2017 20:07:56 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id p75so4643388wmg.3 for ; Fri, 03 Nov 2017 20:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=bF2iLTn3bEV982giMU5UJduKVAcZZw7RVsxEKuCtvwc=; b=iZIqoujqCBKNYp/dEkQKcg9uc4JnAtd63lryxglrtd2g7RdQWOipurBlHrfU4Owkjs IiYe2U+4f6dQZkj0xxraRSecAft5wu4EL0GsH5Bh7A4swZqksDcqUwPtBiIVDINDx13z 5wwyNbBQE115y75/ZK1Q8V1yuM8z+zz/d0x8HxtIXA492LDnscTKAdMdSp8P3byEuM9c PdgADwLejiOOFDF3BbSAPDsK1JAY5AtoOUmepj08ataLoChXfnmjboPqShr2QOSAnbsc m3U/8ZCdPSNjeSu2bNqc1hV+ZQq+/W/RYYmyWPW/sdxC9MkOXIAIv6jNbk6Qnev59ZMZ IiTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bF2iLTn3bEV982giMU5UJduKVAcZZw7RVsxEKuCtvwc=; b=JYN1C2DCtI42lldD7SWwIJyL8Nz+a2YW2IYN2fyOvIIRKr7qrey+voD1gbkv2UgvC3 8wWb0JXjP7j6wLfZfxH2JXsVOZM7GOo/q+0k1jPWgz9nV7EI/sNTonZFiHShpjS5lOHA OtnATQ5x4DqaOJfV0ycxheHpHa5KUhbC4BB6PuReeE49mJMEiyXfToucK9wmNVG0slMp XGhmmjgC5FouDc9A6kBy+CEoprZVkFYv+wHA6POT0MlXK/NEd8+7Gg1sLHw4y3q1QwFA aUPFHVyq2s7owmYrcQm8lMnDBnnF4rWmrRGJAaYRthAliq/LFEDrEBxZmSl8ymVhBTNn 9S1A== X-Gm-Message-State: AJaThX5GuJhJoStxS4oIZUgRo4zP/bedO9f3C2L0ELG5y5xnLyU9Fekh 0sC5aIOBURSiegPZI+qowXpXp+TaYj3oV+fu+jLUqw== X-Google-Smtp-Source: ABhQp+TLohC8TFOYQU1kekTcmZSVHphRwVY+ybpwy8Zni2JBEm3mWHfL94l9IuL+C/YqOJSpYGXAD0+BgcgRISuv6V4= X-Received: by 10.28.47.201 with SMTP id v192mr639302wmv.98.1509764874956; Fri, 03 Nov 2017 20:07:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.184.60 with HTTP; Fri, 3 Nov 2017 20:07:54 -0700 (PDT) From: tjw ietf Date: Fri, 3 Nov 2017 23:07:54 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="001a1142490810f3bd055d1f878b" Archived-At: Subject: [DNSOP] Agenda for IETF100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 03:07:59 -0000 --001a1142490810f3bd055d1f878b Content-Type: text/plain; charset="UTF-8" All, Here's the latest agenda for IETF100 in Singapore. https://datatracker.ietf.org/meeting/100/materials/agenda-100-dnsop/ This should take into account all requests for time as of this afternoon. Definitely email if something was missed. I don't plan on major changes at this point. As you can see, we have time for our Monday Morning slot of 2.5 hours. Because of this, we're currently planning on giving back the Thursday meeting slot. Since the Monday meeting is *first thing* Monday Morning, I will be expecting slides by Sunday afternoon 12 November. I am arriving in Singapore this coming Wednesday 8 November, as I have a few days in the local office. thanks and see folks in Singapore tim ------- # DNS Operations (DNSOP) Working Group ## IETF 100, Singapore ### Session I * Date: Monday 13 November 2017 * Time: 09:30-1200 SGT (UTC+8) * Room: Padang * Chairs: Tim Wicinski * Chairs: Suzanne Woolf * Secretary: Paul Hoffman * IESG Overlord: Warren Kumari * [DocList](https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html) * [DataTracker](https://datatracker.ietf.org/wg/dnsop/documents/) --- ## Agenda ### Administrivia * Agenda Bashing, Blue Sheets, etc, 10 min * Updates of Old Work, Chairs, 10 min --- ### Current Working Group Business * [draft-ietf-dnsop-terminology-bis]( https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-07). Hoffman, 15min Chairs feel we are closing in on WGLC, but need reviewers * [draft-ietf-dnsop-rfc5011-security-considerations]( https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-07), Hardaker, 10min WGLC ended with lack of consensus and gaping questions. * [draft-ietf-dnsop-extended-error]( https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-00), Hardeker, 10min questions from 16 October * [draft-ietf-dnsop-let-localhost-be-localhost]( https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-01), Random HTTP Person, 10min resolve any loose threads from adopted version * [draft-bellis-dnsop-xpf]( https://tools.ietf.org/html/draft-bellis-dnsop-xpf-03), Bellis, 10min lots of push back last time --- ### New Working Group Business * [draft-fujiwara-dnsop-additional-answers]( https://tools.ietf.org/html/draft-fujiwara-dnsop-additional-answers-00), Fujiwara, 15min another multiple responses idea, with code * [draft-mglt-dnsop-dnssec-validator-requirements]( https://tools.ietf.org/html/draft-mglt-dnsop-dnssec-validator-requirements-06), Migault, 10min Authors feel this should be a WG document? * [draft-huston-kskroll-sentinel]( https://tools.ietf.org/html/draft-huston-kskroll-sentinel-02), Huston, 10min does the working group feel as a useful option? * [draft-dupont-dnsop-rfc2845bis]( https://tools.ietf.org/html/draft-dupont-dnsop-rfc2845bis-00), Dupont, 10min this addresses the TSIG bug from this summer * [draft-wkumari-dnsop-internal]( https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00), Kumari, 10min --001a1142490810f3bd055d1f878b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

All,

Here's the late= st agenda for IETF100 in Singapore. =C2=A0

=
This should take into account all requests for time as of this a= fternoon.=C2=A0 Definitely email if something was missed.=C2=A0 I don't= plan on major changes at this point.

As you can s= ee, we have time for our Monday Morning slot of 2.5 hours. =C2=A0 Because o= f this, we're currently planning on giving back the Thursday meeting sl= ot.=C2=A0

Since the Monday meeting is *first thing= * Monday Morning, I will be expecting slides by Sunday afternoon 12 Novembe= r. =C2=A0

I am arriving in Singapore this coming W= ednesday 8 November, as =C2=A0I have a few days in the local office.=C2=A0<= /div>

thanks and see folks in Singapore

tim

-------
# DNS Operatio= ns (DNSOP) Working Group
## IETF 100, Singapore
### Ses= sion I

* Date: Monday 13 November 2017
*= Time: 09:30-1200 SGT (UTC+8)
* Room: Padang

=
* Chairs: Tim Wicinski <tjw.i= etf@gmail.com>
* Chairs: Suzanne Woolf <suzworldwide@gmail.com>

* Secretary: Paul Hoffman <paul.hoffman@icann.org>

* IESG Overlor= d: Warren Kumari <warren@kumari.net= >


---
## Agenda

### Administrivia=C2=A0

* Agenda Bashing,= Blue Sheets, etc, =C2=A010 min

* Updates of Old W= ork, Chairs, 10 min

---
### Current Work= ing Group Business

* [draft-ietf-dnsop-terminology= -bis](https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-07)= . Hoffman, 15min
=C2=A0 =C2=A0 Chairs feel we are closing in on W= GLC, but need reviewers

* [draft-ietf-dnsop-rfc501= 1-security-considerations](https://tools.ietf.org/html/dra= ft-ietf-dnsop-rfc5011-security-considerations-07), Hardaker, 10min
=C2=A0 =C2=A0 WGLC ended with lack of consensus and gaping questions.= =C2=A0

* [draft-ietf-dnsop-extended-error](https:/= /tools.ietf.org/html/draft-ietf-dnsop-extended-error-00), Hardeker, 10m= in
=C2=A0 =C2=A0 questions from 16 October=C2=A0

* [draft-ietf-dnsop-let-localhost-be-localhost](https:= //tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-01), = Random HTTP Person, 10min
=C2=A0 =C2=A0 resolve any loose threads= from adopted version=C2=A0

* [draft-bellis-dnsop-= xpf](http= s://tools.ietf.org/html/draft-bellis-dnsop-xpf-03), Bellis, 10min
=
=C2=A0 =C2=A0 lots of push back last time

---=
### New Working Group Business

* [draft= -fujiwara-dnsop-additional-answers](https://tools.ietf.org/html/dra= ft-fujiwara-dnsop-additional-answers-00), Fujiwara, 15min
=C2= =A0 =C2=A0 another multiple responses idea, with code=C2=A0

<= /div>
* [draft-mglt-dnsop-dnssec-validator-requirements](https://tools.ietf.org/html/draft-mglt-dnsop-dnssec-validator-requirements= -06), Migault, 10min
=C2=A0 =C2=A0 Authors feel this should b= e a WG document?

* [draft-huston-kskroll-sentinel]= (h= ttps://tools.ietf.org/html/draft-huston-kskroll-sentinel-02), Huston, 1= 0min
=C2=A0 =C2=A0 does the working group feel as a useful option= ?

* [draft-dupont-dnsop-rfc2845bis](https://tools.ie= tf.org/html/draft-dupont-dnsop-rfc2845bis-00), Dupont, 10min
= =C2=A0 =C2=A0 this addresses the TSIG bug from this summer

* [draft-wkumari-dnsop-internal](https://tools.ietf.org/html/draft-wk= umari-dnsop-internal-00), Kumari, 10min

--001a1142490810f3bd055d1f878b-- From nobody Fri Nov 3 23:30:31 2017 Return-Path: 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 AD6DE13FB5B for ; Fri, 3 Nov 2017 23:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 AV7k7nHUSBw2 for ; Fri, 3 Nov 2017 23:30:25 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 4075D13FAF3 for ; Fri, 3 Nov 2017 23:30:25 -0700 (PDT) Received: from jurassic.lan.banu.com (unknown [115.118.170.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id F391156A0100; Sat, 4 Nov 2017 06:30:21 +0000 (GMT) Date: Sat, 4 Nov 2017 12:00:18 +0530 From: Mukund Sivaraman To: dnsop@ietf.org Message-ID: <20171104063018.GA25223@jurassic.lan.banu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: Subject: [DNSOP] Review of draft-dupont-dnsop-rfc2845bis-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 06:30:30 -0000 Hi Francis, Stephen After a reading, I felt that this document needs the following: * Editing for clarity of sentences * Addressing insufficient protocol specification Review follows that suggests changes. Some are nitpicking, but changes are needed to be pedantically correct. > This protocol allows for transaction level authentication using > shared secrets and one way hashing. It can be used to authenticate I'd start as "This document describes a protocol for transaction level authentication...". > shared secrets and one way hashing. It can be used to authenticate > dynamic updates as coming from an approved client, or to authenticate > responses as coming from an approved recursive name server. s/recursive name server/name server/ > No provision has been made here for distributing the shared secrets: > it is expected that a network administrator will statically configure > name servers and clients using some out of band mechanism such as > sneaker-net until a secure automated mechanism for key distribution > is available. This paragraph may be misconstrued to imply that such an automated mechanism is forthcoming. I'd leave it at just this: "This document does not describe how to distribute the shared secrets. It is expected that a network administrator will statically configure name servers and clients using some out of band mechanism." > This document includes revised original TSIG specifications > (RFC2845) and the extension for HMAC-SHA (RFC4635). s/and the extension/and its extension/ > 1. Introduction > > In 2017, security problems in two nameservers strictly following > [RFC2845] and [RFC4635] (i.e., TSIG and HMAC-SHA extension) s/TSIG and HMAC-SHA extension/TSIG and its HMAC-SHA extension/ > specifications were discovered. The implementations were fixed but, > to avoid similar problems in the future, the two documents were > updated and merged, producing these revised specifications for TSIG. > > The Domain Name System (DNS) [RFC1034], [RFC1035] is a replicated > hierarchical distributed database system that provides information > fundamental to Internet operations, such as name <=> address > translation and mail handling information. > > This document specifies use of a message authentication code (MAC), > either HMAC-MD5 or HMAC-SHA (keyed hash functions), to provide an > efficient means of point-to-point authentication and integrity > checking for transactions. I'd avoid listing the HMACs here and instead refer to the section below that lists them. > The second area where the secret key based MACs specified in this > document can be used is to authenticate DNS update requests as well > as transaction responses, providing a lightweight alternative to the > protocol described by [RFC3007]. It isn't clear how this is different from "first area". DNS updates are also transactions. > A further use of this mechanism is to protect zone transfers. In > this case the data covered would be the whole zone transfer including > any glue records sent. The protocol described by DNSSEC does not > protect glue records and unsigned records unless SIG(0) (transaction > signature) is used. I'd avoid including this whole sentence about DNSSEC. > The authentication mechanism proposed in this document uses shared > secret keys to establish a trust relationship between two entities. I'd s/shared secret keys/pre-shared secret keys/ > Such keys must be protected in a fashion similar to private keys, s/fashion/manner/ > lest a third party masquerade as one of the intended parties (forge > MACs). There is an urgent need to provide simple and efficient > authentication between clients and local servers and this proposal > addresses that need. This proposal is unsuitable for general server > to server authentication for servers which speak with many other > servers, since key management would become unwieldy with the number > of shared keys going up quadratically. But it is suitable for many > resolvers on hosts that only talk to a few recursive servers. > > A server acting as an indirect caching resolver -- a "forwarder" in > common usage -- might use transaction-based authentication when > communicating with its small number of preconfigured "upstream" > servers. Other uses of DNS secret key authentication and possible > systems for automatic secret key distribution may be proposed in > separate future documents. > > Note that use of TSIG presumes prior agreement between the resolver > and server involved as to the algorithm and key to be used. Again this document seems to tie itself to the resolver case only. s/between the resolver and server/between the client and server/ > Since the publication of first version of this document ([RFC2845]) a > mechanism based on asymmetric signatures using the SIG RR was > specified (SIG(0) [RFC2931]) when this document uses symmetric > authentication codes calculated by HMAC [RFC2104] using strong hash > functions. s/when this document/whereas this document/ > 4.1. TSIG RR Type > > To provide secret key authentication, we use a new RR type whose > mnemonic is TSIG and whose type code is 250. TSIG is a meta-RR and > MUST NOT be cached. TSIG RRs are used for authentication between DNS > entities that have established a shared secret key. TSIG RRs are > dynamically computed to cover a particular DNS transaction and are > not DNS RRs in the usual sense. The last sentence doesn't appear to be particularly accurate. TSIG RRs are dynamically computed to cover specific DNS *messages* or used possibly sparingly over a message sequence such as with zone transfers (in this latter case, more than a single TSIG RR may be used). I'd rewrite it as: "TSIG RRs are dynamically computed to cover DNS transactions and are not DNS RRs in the usual sense." > > 4.2. TSIG Calculation > > As the TSIG RRs are related to one DNS request/response, there is no > value in storing or retransmitting them, thus the TSIG RR is > discarded once it has been used to authenticate a DNS message. All > multi-octet integers in the TSIG record are sent in network byte > order (see [RFC1035] 2.3.2). > > 4.3. TSIG Record Format > > NAME The name of the key used in domain name syntax. The name > should reflect the names of the hosts and uniquely identify the > key among a set of keys these two hosts may share at any given > time. If hosts A.site.example and B.example.net share a key, > possibilities for the key name include .A.site.example, > .B.example.net, and .A.site.example.B.example.net. It > should be possible for more than one key to be in simultaneous > use among a set of interacting hosts. The name only needs to > be meaningful to the communicating hosts but a meaningful > mnemonic name as above is strongly recommended. > > The name may be used as a local index to the key involved and > it is recommended that it be globally unique. Where a key is > just shared between two hosts, its name actually only need only > be meaningful to them but it is recommended that the key name > be mnemonic and incorporate the resolver and server host names > in that order. > > TYPE TSIG (250: Transaction SIGnature) > > CLASS ANY > > TTL 0 Please include text that TTL MUST be set to 0, class MUST be set to ANY. > > RdLen (variable) > > RDATA > > 4.3.1. TSIG RDATA Wire Format > > The RDATA for a TSIG RR consists of an octet stream Algorithm Name > field, a uint48_t Time Signed field, a uint16_t Fudge field, a > uint16_t MAC Size field, a octet stream MAC field, a uint16_t > Original ID, a uint16_t Error field, a uint16_t Other Len field and > an octet stream of Other Data. > > > 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > / Algorithm Name / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Time Signed +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | Fudge | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MAC Size | / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAC / > / / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Original ID | Error | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Other Len | / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Other Data / > / / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 4.3.1.1. The Algorithm Name Field > > The Algorithm Name field identifies the TSIG algorithm name in the > domain name syntax. Please clarify that this field needs to be in RFC 1035 DNS name wire format without name compression. Also for clarity I'd first explicitly specify that unlike with other algorithm fields (represented by integers) in DNS, the TSIG algorithm identifier is represented as a DNS name. > > 4.3.1.2. The Time Signed Field > > The Time Signed field specifies seconds since 1970-01-01 UTC. > > 4.3.1.3. The Fudge Field > > The Fudge field specifies allowed time difference in seconds > permitted in the Time Signed field. > > > 4.3.1.4. The MAC Size Field > > The MAC Size field specifies the length of MAC field in octets. > Truncation is indicated by a MAC size less than the HMAC size. > > 4.3.1.5. The MAC Field > > The MAC field contents are defined by the used Algorithm. > > 4.3.1.6. The Error field > > The Error field contains the Expanded RCODE covering TSIG processing. > > 4.3.1.7. The Other Len Field > > The Other Len field specifies the length of Other Data in octets. > > 4.3.1.8. The Other Data Field > > The Other Data field is empty unless Error == BADTIME. What is in the Other Data field if Error is equal to BADTIME? A person reading this document sequentially will not understand this. Please introduce what "Other Data" is useful for. Is it an error to use Other Data when Error != BADTIME? > > 4.4. Example > > NAME HOST.EXAMPLE. Even this example does not follow the "should" recommendation under section 4.3 above. > > TYPE TSIG > > CLASS ANY > > TTL 0 > > RdLen As appropriate > > RDATA > > Field Name Contents > -------------- ------------------- > Algorithm Name SAMPLE-ALG.EXAMPLE. Please use a valid algorithm in example. > Time Signed 853804800 > Fudge 300 > MAC Size As appropriate > MAC As appropriate > Original ID As appropriate > Error 0 (NOERROR) > Other Len 0 > Other Data Empty > > > > > > 5. Protocol Operation > > 5.1. Effects of adding TSIG to outgoing message > > Once the outgoing message has been constructed, the keyed message > digest operation can be performed. I'd replace this with "Once the outgoing message has been constructed, the HMAC computation can be performed." > The resulting message digest will I'd use s/message digest/MAC/ for clarity (even though the HMAC operation outputs a message digest of some data). > then be stored in a TSIG which is appended to the additional data > section (the ARCOUNT is incremented to reflect this). When is it incremented? Before MAC computation or after? Please specify. > If the TSIG record cannot be added without causing the message to > be truncated, the server MUST alter the response so that a TSIG can > be included. This response consists of only the question and a > TSIG record, and has the TC bit set and RCODE 0 (NOERROR). The > client SHOULD at this point retry the request using TCP (per > [RFC1035] 4.2.2). > > 5.2. TSIG processing on incoming messages > > If an incoming message contains a TSIG record, it MUST be the last > record in the additional section. Multiple TSIG records are not > allowed. If a TSIG record is present in any other position, the > packet is dropped and a response with RCODE 1 (FORMERR) MUST be > returned. Upon receipt of a message with a correctly placed TSIG RR, > the TSIG RR is copied to a safe location, removed from the DNS > Message, and decremented out of the DNS message header's ARCOUNT. At > this point the keyed message digest operation is performed: until Here again, I'd replace keyed message digest with MAC computation for consistency. > this operation concludes that the signature is valid, the signature > MUST be considered to be invalid. If the algorithm name or key name > is unknown to the recipient, or if the message digests do not match, > the whole DNS message MUST be discarded. Perhaps s/discarded/rejected/ is a better wording here. > If the message is a query, a response with RCODE 9 (NOTAUTH) MUST > be sent back to the originator with TSIG ERROR 17 (BADKEY) or TSIG > ERROR 16 (BADSIG). If no key is available to sign this message it > MUST be sent unsigned (MAC size == 0 and empty MAC). A message to > the system operations log SHOULD be generated, to warn the > operations staff of a possible security incident in progress. Care > should be taken to ensure that logging of this type of event does > not open the system to a denial of service attack. This passage assumes that something is wrong with the message. It should be separated into a different paragraph corresponding to what to do when something is wrong with the message. Surely we must not send NOTAUTH for messages that validate? The use of a single paragraph in 5.2 is confusing. > 5.3. Time values used in TSIG calculations > > The data digested includes the two timer values in the TSIG header in > order to defend against replay attacks. If this were not done, an > attacker could replay old messages but update the "Time Signed" and > "Fudge" fields to make the message look new. This data is named > "TSIG Timers", and for the purpose of digest calculation they are > invoked in their "on the wire" format, in the following order: first > Time Signed, then Fudge. For example: > > > > > > > Field Name Value Wire Format Meaning > ----------- --------- ----------------- ------------------------ > Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997 > Fudge 300 01 2C 5 minutes > > 5.4. TSIG Variables and Coverage > > When generating or verifying the contents of a TSIG record, the > following data are digested, in network byte order or wire format, as > appropriate: s/following data are digested/following data are passed as input to MAC computation/ (Yes it is a digest within HMAC.) > > 5.4.1. DNS Message > > A whole and complete DNS message in wire format, before the TSIG RR > has been added to the additional data section and before the DNS > Message Header's ARCOUNT field has been incremented to contain the > TSIG RR. If the message ID differs from the original message ID, the > original message ID is substituted for the message ID. This could > happen when forwarding a dynamic update request, for example. > > 5.4.2. TSIG Variables > > Source Field Name Notes > ---------- -------------- ----------------------------------------- > TSIG RR NAME Key name, in canonical wire format > TSIG RR CLASS (Always ANY in the current specification) > TSIG RR TTL (Always 0 in the current specification) > TSIG RDATA Algorithm Name in canonical wire format > TSIG RDATA Time Signed in network byte order > TSIG RDATA Fudge in network byte order > TSIG RDATA Error in network byte order > TSIG RDATA Other Len in network byte order > TSIG RDATA Other Data exactly as transmitted > > The RR RDLEN and RDATA MAC Length are not included in the hash since > they are not guaranteed to be knowable before the MAC is generated. s/hash/input to MAC computation/ > The Original ID field is not included in this section, as it has > already been substituted for the message ID in the DNS header and > hashed. > > For each label type, there must be a defined "Canonical wire format" > that specifies how to express a label in an unambiguous way. For > label type 00, this is defined in [RFC4034], for label type 01, this > is defined in [RFC6891]. The use of label types other than 00 and 01 > is not defined for this specification. What? This paragraph does not fit into this document. It seems to appear in RFC 2845 too. What is this in relevance to? > 5.4.3. Request MAC > > When generating the MAC to be included in a response, the validated > request MAC MUST be included in the digest. If the request MAC s/digest/MAC computation/ Please be careful when you use "digest" like this as it could be misconstrued to mean "prepended/appended to the digest output". > failed to validate, an unsigned error message MUST be returned > instead. (Section 6.3). > > The request's MAC is digested in wire format, including the following > fields: > > Field Type Description > ---------- ------------ ---------------------- > MAC Length uint16_t in network byte order > MAC Data octet stream exactly as transmitted > > 5.5. Padding > > Digested components are fed into the hashing function as a continuous > octet stream with no interfield padding. Digested components? Are components digested before feeding them into the MAC function? > > 6. Protocol Details > > 6.1. TSIG generation on requests > > Client performs the message digest operation and appends a TSIG > record to the additional data section and transmits the request to > the server. The client MUST store the message digest from the s/message digest/MAC/ > request while awaiting an answer. The digest components for a > request are: > > DNS Message (request) > TSIG Variables (request) > > Note that some older name servers will not accept requests with a > nonempty additional data section. Clients SHOULD only attempt signed > transactions with servers who are known to support TSIG and share > some secret key with the client -- so, this is not a problem in > practice. > > 6.2. TSIG on Answers > > When a server has generated a response to a signed request, it signs > the response using the same algorithm and key. The server MUST NOT > generate a signed response to an unsigned request or a request that > fails validation. The digest components are: > > Request MAC > DNS Message (response) > > TSIG Variables (response) > > 6.3. TSIG on TSIG Error returns > > When a server detects an error relating to the key or MAC, the server > SHOULD send back an unsigned error message (MAC size == 0 and empty > MAC). If an error is detected relating to the TSIG validity period > or the MAC is too short for the local policy, the server SHOULD send > back a signed error message. The digest components are: > > Request MAC (if the request MAC validated) > DNS Message (response) > TSIG Variables (response) > > The reason that the request is not included in this digest in some > cases is to make it possible for the client to verify the error. If > the error is not a TSIG error the response MUST be generated as > specified in Section 6.2. > > 6.4. TSIG on TCP connection > > A DNS TCP session can include multiple DNS envelopes. This is, for > example, commonly used by zone transfer. Using TSIG on such a > connection can protect the connection from hijacking and provide data > integrity. The TSIG MUST be included on the first and last DNS > envelopes. It can be optionally placed on any intermediary > envelopes. It is expensive to include it on every envelopes, but it > MUST be placed on at least every 100'th envelope. The first envelope > is processed as a standard answer, and subsequent messages have the > following digest components: > > Prior Digest (running) > DNS Messages (any unsigned messages since the last TSIG) > TSIG Timers (current message) > > This allows the client to rapidly detect when the session has been > altered; at which point it can close the connection and retry. If a > client TSIG verification fails, the client MUST close the connection. > If the client does not receive TSIG records frequently enough (as > specified above) it SHOULD assume the connection has been hijacked > and it SHOULD close the connection. The client SHOULD treat this the > same way as they would any other interrupted transfer (although the > exact behavior is not specified). When reading RFC 2845, I felt this section was underspecified and this document seems to replicate it. 1. s/envelope/message/ for consistency. It is confusing to have such synonyms without any explanation. 2. The first paragraph is not properly written. A "DNS TCP session" can be a single DNS connection. It can also accept mutiple pipelined messages (separate transactions) which are not continuations. AIUI, the sparse signing of intermediate messages in a TSIG TCP continuation is only for the zone transfer case, and not for pipelined TCP messages (separate transactions). Please correct me if I'm wrong, and if I'm not wrong, then please rewrite this text specifically for TSIG for zone transfers. 3. "Prior Digest (running)" is inadequately specified. A new reader of this document will not understand what it is. Also, s/The first envelope is processed as a standard answer, and subsequent messages have the following digest components/The first message is processed normally generating a TSIG RR, and the TSIG RR in subsequent messages is generated with the MAC computation over the following components in sequence/ 4. I'd remove the text "It is expensive to include it on every envelopes". As an example, BIND and Knot currently includes TSIG RR in every DNS message in a zone transfer, whereas NSD currently includes it sparsely. I don't think any users notice it as particularly expensive. It is after all just hashing below. Whether something is expensive in space or time also doesn't stand the test of time, so I'd not include a statement that states definitely that it is expensive. > > 6.5. Server TSIG checks > > Upon receipt of a message, server will check if there is a TSIG RR. > If one exists, the server is REQUIRED to return a TSIG RR in the > response. The server MUST perform the following checks in the > following order, check Key, check MAC, check Time values, check > Truncation policy. > > 6.5.1. Key check and error handling > > If a non-forwarding server does not recognize the key used by the > client, the server MUST generate an error response with RCODE 9 > (NOTAUTH) and TSIG ERROR 17 (BADKEY). This response MUST be unsigned > as specified in Section 6.3. The server SHOULD log the error. > > 6.5.2. Specifying Truncation Shouldn't this section be moved to appear after the time checks below (6.5.4) in logical order? > > When space is at a premium and the strength of the full length of an > HMAC is not needed, it is reasonable to truncate the HMAC and use the > truncated value for authentication. HMAC SHA-1 truncated to 96 bits > is an option available in several IETF protocols, including IPsec and > TLS. > > Processing of a truncated MAC follows these rules > > 1. If "MAC size" field is greater than HMAC output length: > > This case MUST NOT be generated and, if received, MUST cause the > packet to be dropped and RCODE 1 (FORMERR) to be returned. s/packet/DNS message/ > > 2. If "MAC size" field equals HMAC output length: > > The entire output HMAC output is present and used. > > 3. "MAC size" field is less than HMAC output length but greater than > that specified in case 4, below: > > This is sent when the signer has truncated the HMAC output to an > allowable length, as described in [RFC2104], taking initial > octets and discarding trailing octets. TSIG truncation can only > be to an integral number of octets. On receipt of a packet with > truncation thus indicated, the locally calculated MAC is > similarly truncated and only the truncated values are compared > for authentication. The request MAC used when calculating the > TSIG MAC for a reply is the truncated request MAC. How about the "Prior Digest (running)" (section 6.4) ? Please specify. > 4. "MAC size" field is less than the larger of 10 (octets) and half > the length of the hash function in use: > > > > Dupont & Morris Expires May 3, 2018 [Page 12] > > Internet-Draft DNS TSIG October 2017 > > > With the exception of certain TSIG error messages described in > Section 6.3, where it is permitted that the MAC size be zero, > this case MUST NOT be generated and, if received, MUST cause the > packet to be dropped and RCODE 1 (FORMERR) to be returned. > > 6.5.3. MAC check and error handling > > If a TSIG fails to verify, the server MUST generate an error response > as specified in Section 6.3 with RCODE 9 (NOTAUTH) and TSIG ERROR 16 > (BADSIG). This response MUST be unsigned as specified in > Section 6.3. The server SHOULD log the error. > > 6.5.4. Time check and error handling > > If the server time is outside the time interval specified by the > request (which is: Time Signed, plus/minus Fudge), the server MUST > generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18 > (BADTIME). The server SHOULD also cache the most recent time signed > value in a message generated by a key, and SHOULD return BADTIME if a > message received later has an earlier time signed value. A response > indicating a BADTIME error MUST be signed by the same key as the > request. It MUST include the client's current time in the time > signed field, the server's current time (a uint48_t) in the other > data field, and 6 in the other data length field. This is done so > that the client can verify a message with a BADTIME error without the > verification failing due to another BADTIME error. The data signed > is specified in Section 6.3. The server SHOULD log the error. > > 6.5.5. Truncation check and error handling > > If a TSIG is received with truncation that is permitted under > Section 6.5.2 above but the MAC is too short for the local policy in > force, an RCODE 9 (NOTAUTH) and TSIG ERROR 22 (BADTRUNC) MUST be > returned. The server SHOULD log the error. > > 6.6. Client processing of answer > > When a client receives a response from a server and expects to see a > TSIG, it first checks if the TSIG RR is present in the response. > Otherwise, the response is treated as having a format error and > discarded. The client then extracts the TSIG, adjusts the ARCOUNT, > and calculates the keyed digest in the same way as the server, > applying the same rules to decide if truncated MAC is valid. If the > TSIG does not validate, that response MUST be discarded, unless the > RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to > verify the response as if it were a TSIG Error response, as specified > in Section 6.3. A message containing an unsigned TSIG record or a > TSIG record which fails verification SHOULD NOT be considered an > > > > Dupont & Morris Expires May 3, 2018 [Page 13] > > Internet-Draft DNS TSIG October 2017 > > > acceptable response; the client SHOULD log an error and continue to > wait for a signed response until the request times out. > > 6.6.1. Key error handling > > If an RCODE on a response is 9 (NOTAUTH), and the response TSIG > validates, and the TSIG key is different from the key used on the > request, then this is a Key error. The client MAY retry the request > using the key specified by the server. This should never occur, as a > server MUST NOT sign a response with a different key than signed the > request. > > 6.6.2. MAC error handling > > If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), > this is a MAC error, and client MAY retry the request with a new > request ID but it would be better to try a different shared key if > one is available. Clients SHOULD keep track of how many MAC errors > are associated with each key. Clients SHOULD log this event. > > 6.6.3. Time error handling > > If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18 > (BADTIME), or the current time does not fall in the range specified > in the TSIG record, then this is a Time error. This is an indication > that the client and server clocks are not synchronized. In this case > the client SHOULD log the event. DNS resolvers MUST NOT adjust any > clocks in the client based on BADTIME errors, but the server's time > in the other data field SHOULD be logged. > > 6.6.4. Truncation error handling > > If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 22 > (BADTRUNC) the this is a Truncation error. The client MAY retry with > lesser truncation up to the full HMAC output (no truncation), using > the truncation used in the response as a hint for what the server > policy allowed (Section 8). Clients SHOULD log this event. > > 6.7. Special considerations for forwarding servers > > A server acting as a forwarding server of a DNS message SHOULD check > for the existence of a TSIG record. If the name on the TSIG is not > of a secret that the server shares with the originator the server > MUST forward the message unchanged including the TSIG. If the name > of the TSIG is of a key this server shares with the originator, it > MUST process the TSIG. If the TSIG passes all checks, the forwarding > server MUST, if possible, include a TSIG of his own, to the > destination or the next forwarder. If no transaction security is > > > > Dupont & Morris Expires May 3, 2018 [Page 14] > > Internet-Draft DNS TSIG October 2017 > > > available to the destination and the response has the AD flag (see > [RFC4035]), the forwarder MUST unset the AD flag before adding the > TSIG to the answer. > > 7. Algorithms and Identifiers > > The only message digest algorithm specified in the first version of > these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321], > [RFC2104]). The "HMAC-MD5" algorithm is mandatory to implement for > interoperability. > > The use of SHA-1 [FIPS180-4], [RFC3174], (which is a 160-bit hash as > compared to the 128 bits for MD5), and additional hash algorithms in > the SHA family [FIPS180-4], [RFC3874], [RFC6234] with 224, 256, 384, > and 512 bits may be preferred in some cases. This is because > increasingly successful cryptanalytic attacks are being made on the > shorter hashes. > > Use of TSIG between a DNS resolver and server is by mutual agreement. > That agreement can include the support of additional algorithms and > criteria as to which algorithms and truncations are acceptable, > subject to the restriction and guidelines in Section 6.5.2 above. > Key agreement can be by the TKEY mechanism [RFC2930] or some other > mutually agreeable method. > > The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are > included in the table below for convenience. Implementations that > support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY > implement gss-tsig and the other algorithms listed below. > > Requirement Name > ----------- ------------------------ > Mandatory HMAC-MD5.SIG-ALG.REG.INT > Optional gss-tsig > Mandatory hmac-sha1 > Optional hmac-sha224 > Mandatory hmac-sha256 > Optional hmac-sha384 > Optional hmac-sha512 > > SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. I don't know if it is outside the scope of this revision to alter this table but I see two things: 1. SHA-512 is a faster hash than SHA-256, and so it would be better to make support for SHA-512 and its truncated SHA-384 mandatory. 2. It makes little sense to support SHA-384 and SHA-224 when we already support MAC truncation in the protocol itself. 3. HMAC-MD5 is still a secure HMAC currently, but it is discouraged for new applications because it is built on top of MD5 which is barred for new applications (RFC 6151). I'm not sure if this revision constitutes a new application (as it is still the backwards compatible protocol), but would it be allowed to specify the use of MD5 on the path to RFC? > 8. TSIG Truncation Policy > > Use of TSIG is by mutual agreement between a resolver and server. Please remove this limitation of TSIG being between resolver and server everywhere in the document. > Implicit in such an "agreement" are criteria as to acceptable keys > and algorithms and, with the extensions in this document, > truncations. Note that it is common for implementations to bind the > > > > Dupont & Morris Expires May 3, 2018 [Page 15] > > Internet-Draft DNS TSIG October 2017 > > > TSIG secret key or keys that may be in place at a resolver and server > to particular algorithms. Thus, such implementations only permit the > use of an algorithm if there is an associated key in place. Receipt > of an unknown, unimplemented, or disabled algorithm typically results > in a BADKEY error. > > Local policies MAY require the rejection of TSIGs, even though they > use an algorithm for which implementation is mandatory. > > When a local policy permits acceptance of a TSIG with a particular > algorithm and a particular non-zero amount of truncation, it SHOULD > also permit the use of that algorithm with lesser truncation (a > longer MAC) up to the full HMAC output. > > Regardless of a lower acceptable truncated MAC length specified by > local policy, a reply SHOULD be sent with a MAC at least as long as > that in the corresponding request. Note if the request specified a > MAC length longer than the HMAC output it will be rejected by > processing rules Section 6.5.2 case 1. > > Implementations permitting multiple acceptable algorithms and/or > truncations SHOULD permit this list to be ordered by presumed > strength and SHOULD allow different truncations for the same > algorithm to be treated as separate entities in this list. When so > implemented, policies SHOULD accept a presumed stronger algorithm and > truncation than the minimum strength required by the policy. > > 9. Shared Secrets > > Secret keys are very sensitive information and all available steps > should be taken to protect them on every host on which they are > stored. Generally such hosts need to be physically protected. If > they are multi-user machines, great care should be taken that > unprivileged users have no access to keying material. Resolvers > often run unprivileged, which means all users of a host would be able > to see whatever configuration data is used by the resolver. > > A name server usually runs privileged, which means its configuration > data need not be visible to all users of the host. For this reason, > a host that implements transaction-based authentication should > probably be configured with a "stub resolver" and a local caching and > forwarding name server. This presents a special problem for > [RFC2136] which otherwise depends on clients to communicate only with > a zone's authoritative name servers. This seems use-case specific. > Use of strong random shared secrets is essential to the security of > TSIG. See [RFC4086] for a discussion of this issue. The secret > > > > > Dupont & Morris Expires May 3, 2018 [Page 16] > > Internet-Draft DNS TSIG October 2017 > > > SHOULD be at least as long as the keyed message digest, i.e., 16 > bytes for HMAC-MD5 or 20 bytes for HMAC-SHA1. I'd remove this example from here and add a field for minimum secret length to the table of supported algorithms above. > > 10. IANA Considerations > > IANA maintains a registry of algorithm names to be used as "Algorithm > Names" as defined in Section 4.3. Algorithm names are text strings > encoded using the syntax of a domain name. There is no structure > required other than names for different algorithms must be unique > when compared as DNS names, i.e., comparison is case insensitive. > Previous specifications [RFC2845] and [RFC4635] defined values for > HMAC MD5 and SHA. IANA has also registered "gss-tsig" as an > identifier for TSIG authentication where the cryptographic operations > are delegated to the Generic Security Service (GSS) [RFC3645]. > > New algorithms are assigned using the IETF Consensus policy defined > in [RFC8126]. The algorithm name HMAC-MD5.SIG-ALG.REG.INT looks like > a fully-qualified domain name for historical reasons; other algorithm > names are simple (i.e., single-component) names. > > IANA maintains a registry of "TSIG Error values" to be used for > "Error" values as defined in Section 4.3. Initial values should be > those defined in Section 3. New TSIG error codes for the TSIG error > field are assigned using the IETF Consensus policy defined in > [RFC8126]. > > 11. Security Considerations > > The approach specified here is computationally much less expensive > than the signatures specified in DNSSEC. As long as the shared > secret key is not compromised, strong authentication is provided for > the last hop from a local name server to the user resolver. This is again use-case specific. I'd replace this with "is provided between client and server." > Secret keys should be changed periodically. How periodically? I suggest referring to RFC 2104 section 3 rather than recommending best practice here. > If the client host has been compromised, the server should suspend > the use of all secrets known to that client. If possible, secrets > should be stored in encrypted form. Secrets should never be > transmitted in the clear over any network. This document does not > address the issue on how to distribute secrets. Secrets should > never be shared by more than two entities. > > This mechanism does not authenticate source data, only its > transmission between two parties who share some secret. The original > source data can come from a compromised zone master or can be > corrupted during transit from an authentic zone master to some > "caching forwarder." However, if the server is faithfully performing > the full DNSSEC security checks, then only security checked data will > be available to the client. > > > > Dupont & Morris Expires May 3, 2018 [Page 17] > > Internet-Draft DNS TSIG October 2017 > > > A fudge value that is too large may leave the server open to replay > attacks. A fudge value that is too small may cause failures if > machines are not time synchronized or there are unexpected network > delays. The recommended value in most situation is 300 seconds. I have felt that 300s (5 minutes) is too long to make up for clock skew and message transmission delays. It becomes possible for a man-in-the-middle to replay traffic (such as DNS UPDATEs) during this opportunity window. Server and client clocks must be synchronized to a common time, and it is very improbable that a machine synchronizing to a clock source (e.g., using NTP software such as ntpd or chronyd) is off by more than a single digit number of seconds. It appears that the fudge time is not configurable at least in BIND (without patching the source code). > For all of the message authentication code algorithms listed in this > document, those producing longer values are believed to be stronger; > however, while there have been some arguments that mild truncation > can strengthen a MAC by reducing the information available to an > attacker, excessive truncation clearly weakens authentication by > reducing the number of bits an attacker has to try to break the > authentication by brute force [RFC2104]. > > Significant progress has been made recently in cryptanalysis of hash > functions of the types used here, all of which ultimately derive from > the design of MD4. After SHA-3 (though it is not yet in the table of TSIG algorithms as HMAC currently), saying that all hash functions derive from the design of MD4 would be incorrect, so I'd remove the last part of the sentence above for future proofing. > While the results so far should not effect HMAC, > the stronger SHA-1 and SHA-256 algorithms are being made mandatory > due to caution. Note that today SHA-3 [FIPS202] is available as an > alternative to SHA-2 using a very different design. Available as TSIG algorithm? Unless it is added to the table above, I suggest removing this reference. > > See also the Security Considerations section of [RFC2104] from which > the limits on truncation in this RFC were taken. > > 11.1. Issue fixed in this document > > To bind an answer with its corresponding request the MAC of the > answer is computed using the MAC request. Unfortunately original > specifications [RFC2845] failed to clearly require the MAC request to > be successfully validated. I suggest rewriting this: When signing a DNS reply message using TSIG, its MAC computation uses the request message's MAC as an input to cryptographically relate the reply to the request. Unfortunately, the original TSIG specification [RFC2845] failed to clearly require the request MAC to be successfully validated before using it. This created a security vulnerability [add reference to Synacktiv paper]. > This document proposes the principle that the MAC must be considered > to be invalid until it was validated. This leads to the requirement > that only a validated request MAC is included in a signed answer. Or > with other words when the request MAC was not validated the answer > must be unsigned with a BADKEY or BADSIG TSIG error. "This document makes it a requirement that the request MAC must be considered to be invalid until it passes validation." > > 11.2. Why not DNSSEC? > > This section from the original document [RFC2845] analyzes DNSSEC in > order to justify the introduction of TSIG. > > DNS has recently been extended by DNSSEC ([RFC4033], [RFC4034] and > [RFC4035]) to provide for data origin authentication, and public key > distribution, all based on public key cryptography and public key > based digital signatures. To be practical, this form of security > generally requires extensive local caching of keys and tracing of > authentication through multiple keys and signatures to a pre-trusted > locally configured key. > > > > Dupont & Morris Expires May 3, 2018 [Page 18] > > Internet-Draft DNS TSIG October 2017 > > > One difficulty with the DNSSEC scheme is that common DNS > implementations include simple "stub" resolvers which do not have > caches. Such resolvers typically rely on a caching DNS server on > another host. It is impractical for these stub resolvers to perform > general DNSSEC authentication and they would naturally depend on > their caching DNS server to perform such services for them. To do so > securely requires secure communication of queries and responses. > DNSSEC provides public key transaction signatures to support this, > but such signatures are very expensive computationally to generate. > In general, these require the same complex public key logic that is > impractical for stubs. > > A second area where use of straight DNSSEC public key based > mechanisms may be impractical is authenticating dynamic update > [RFC2136] requests. DNSSEC provides for request signatures but with > DNSSEC they, like transaction signatures, require computationally > expensive public key cryptography and complex authentication logic. > Secure Domain Name System Dynamic Update ([RFC3007]) describes how > different keys are used in dynamically updated zones. > > 12. References > > 12.1. Normative References > > [FIPS180-4] > National Institute of Standards and Technology, "Secure > Hash Standard (SHS)", FIPS PUB 180-4, August 2015. > > [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", > STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, > . > > [RFC1035] Mockapetris, P., "Domain names - implementation and > specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, > November 1987, . > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, > DOI 10.17487/RFC2119, March 1997, > . > > [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. > Wellington, "Secret Key Transaction Authentication for DNS > (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, > . > > > > > > > Dupont & Morris Expires May 3, 2018 [Page 19] > > Internet-Draft DNS TSIG October 2017 > > > [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication > Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", > RFC 4635, DOI 10.17487/RFC4635, August 2006, > . > > [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC > 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, > May 2017, . > > 12.2. Informative References Please cite Synacktiv paper on vulnerability in RFC 2845 here. Mukund From nobody Mon Nov 6 02:25:22 2017 Return-Path: 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 CF9DF13FB52 for ; Mon, 6 Nov 2017 02:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 nrEDB498Byo2 for ; Mon, 6 Nov 2017 02:25:17 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 8ADBC13FB1A for ; Mon, 6 Nov 2017 02:25:17 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ac1f:fcff:fe36:e9f8] (unknown [IPv6:2001:1488:fffe:6:ac1f:fcff:fe36:e9f8]) by mail.nic.cz (Postfix) with ESMTPSA id CCAC962E11 for ; Mon, 6 Nov 2017 11:25:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1509963915; bh=HUgtvnD1rI+S1FRLBktP/DD0ywK7puuhwexnX5Dh9qw=; h=To:From:Date; b=QQXeV8oPNw8cdLGgl4zaAhDFpJSY2bBafS2UHCUBbNI3VJGbMZvgI7G4QCD6XSm+K ZvCtYIpnkR5NdGp8KOgyPPp4TZKJCeJ6PgaNVtSsE6U6pL/4khW8VONQSy+SYksIPC Ktqh/MUOfl62tDrxSSCX0MbgK4bgPd0cdyr94BdY= To: dnsop@ietf.org References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <20171101005014.0A2E38DCF888@rock.dv.isc.org> <49FB4D49-C7C7-44E3-B1A6-BA97A9535D83@icann.org> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <68987c9a-599f-1a12-144e-697612aac105@nic.cz> Date: Mon, 6 Nov 2017 11:25:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <49FB4D49-C7C7-44E3-B1A6-BA97A9535D83@icann.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 10:25:20 -0000 On 1.11.2017 12:11, Edward Lewis wrote: > On 10/31/17, 20:50, "DNSOP on behalf of Mark Andrews" wrote: > >> Secondly doing deepest match on trust anchors is the only secure way to prevent a parent overriding the child zone's security policy. Even though Knot Resolver implements "use any" (DS or trust anchor, whichever matches), I think we should move to "deepest match on trust anchors", i.e. I agree with Mark. "Use any" strategy is insecure and will surprise people, as ilustrated by reaction from Edward quoted below: > By this, do you mean choice of cryptographic algorithm and/or length? > To achieve "independence" in this way, the child can simply refuse to > have a DS record at the parent and then lean on managing trust anchors > at all relying resolvers. With current implementation of "use any" nothing prevents the parent from publishing a DS and thus hijacking the domain without clients noticing even if there was a local TA installed for given subdomain on clients. For this reason I propose to document that "deepest match" is mandated behavior. -- Petr Špaček @ CZ.NIC From nobody Mon Nov 6 07:16:01 2017 Return-Path: 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 85CCF13FC3F for ; Mon, 6 Nov 2017 07:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 QVqQG7uLDuBW for ; Mon, 6 Nov 2017 07:15:59 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 9680B13FC30 for ; Mon, 6 Nov 2017 07:15:59 -0800 (PST) Received: from [10.32.60.122] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vA6FEV7s066651 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Nov 2017 08:14:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.122] From: "Paul Hoffman" To: dnsop@ietf.org Cc: "Petr =?utf-8?b?xaBwYcSNZWs=?=" Date: Mon, 06 Nov 2017 07:15:55 -0800 Message-ID: <86322707-A3EC-4574-96B1-977D664053FE@vpnc.org> In-Reply-To: <68987c9a-599f-1a12-144e-697612aac105@nic.cz> References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <20171101005014.0A2E38DCF888@rock.dv.isc.org> <49FB4D49-C7C7-44E3-B1A6-BA97A9535D83@icann.org> <68987c9a-599f-1a12-144e-697612aac105@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 15:16:00 -0000 Doesn't "I don't trust my parent's security policy" open up a million cans of worms anyway? It feels like making this change to the default behavior will make validation more brittle (because people *will* forget to update their lower-level trust anchors) in order to help a very small number of people who could have made the configuration change themselves. --Paul Hoffman From nobody Mon Nov 6 07:39:12 2017 Return-Path: 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 B798A13FAE3 for ; Mon, 6 Nov 2017 07:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tAUfjJSUtGtK for ; Mon, 6 Nov 2017 07:39:08 -0800 (PST) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF95513FAD9 for ; Mon, 6 Nov 2017 07:39:08 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 204643F446; Mon, 6 Nov 2017 10:39:07 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23040.33307.69754.133713@gro.dd.org> Date: Mon, 6 Nov 2017 10:39:07 -0500 From: Dave Lawrence To: dnsop@ietf.org In-Reply-To: <150940017764.7814.6739838599217498076@ietfa.amsl.com> References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 15:39:11 -0000 internet-drafts@ietf.org writes: > Title : Serving Stale Data to Improve DNS Resiliency > Filename : draft-ietf-dnsop-serve-stale-00.txt This is the same as draft-tale-dnsop-serve-stale-02, only renamed for WG adoption. The differences between -01 and -02 are here: https://www.ietf.org/rfcdiff?url1=draft-tale-dnsop-serve-stale-01&url2=draft-tale-dnsop-serve-stale-02 The main changes, based on previous feedback, are: * Clarifying what the action is for Standards Track; * Describing the algorithm previously proposed (and still included) as one example way of achieving the goals; and, * Adding a rough proposal for an EDNS option that could be used for explicit signalling. That last item will be fleshed out more if there's demonstrated interest from implementers in having such a thing. From nobody Mon Nov 6 07:44:37 2017 Return-Path: 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 2F3FB13FAE3 for ; Mon, 6 Nov 2017 07:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 w5W9f5ef6AgC for ; Mon, 6 Nov 2017 07:44:35 -0800 (PST) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC62A13FAD9 for ; Mon, 6 Nov 2017 07:44:34 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id CB9003F446; Mon, 6 Nov 2017 10:44:33 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23040.33633.784218.659394@gro.dd.org> Date: Mon, 6 Nov 2017 10:44:33 -0500 From: Dave Lawrence To: dnsop@ietf.org In-Reply-To: <150940619490.28403.7485909732104218964@ietfa.amsl.com> References: <150940619490.28403.7485909732104218964@ietfa.amsl.com> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 15:44:36 -0000 internet-drafts@ietf.org writes: > Title : BULK DNS Resource Records > Filename : draft-woodworth-bulk-rr-07.txt Changes are here: https://www.ietf.org/rfcdiff?url1=draft-woodworth-bulk-rr-06&url2=draft-woodworth-bulk-rr-07 The primary differences are to add a bit more text on the motivating use cases to the introduction (not just for "wallpapering IPv6 reverse space") and to remove the proposed Numeric Pattern Normalization DNSSEC record from this particular draft. From nobody Mon Nov 6 07:56:59 2017 Return-Path: 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 2647E13FAD9 for ; Mon, 6 Nov 2017 07:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 VeVyPSk3c4fX for ; Mon, 6 Nov 2017 07:56:49 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 955C313FC4C for ; Mon, 6 Nov 2017 07:56:48 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:b083:7eff:fe6f:13cd] (unknown [IPv6:2001:1488:fffe:6:b083:7eff:fe6f:13cd]) by mail.nic.cz (Postfix) with ESMTPSA id CB6EA6352F; Mon, 6 Nov 2017 16:56:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1509983807; bh=4PEejeaWRESE0AoMa//sc+rtDizno4slX/u4ZyBBD80=; h=To:From:Date; b=vyEgoUG7w5CabvOG3uNdJpaaNebrcUTdFYkNoltapwl1CCozWkBD7YYaqzVs42W79 ABGVGNxmWpdPOf7TriTppsbuoal3couXQHfGFHGYYO6/OXOp7DCMsKqNOQer1xdq3L /lSZWMoizfL6yfeD1M2Sq6jS9tm5LVqx8DTTUunU= To: Paul Hoffman , dnsop@ietf.org References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <20171101005014.0A2E38DCF888@rock.dv.isc.org> <49FB4D49-C7C7-44E3-B1A6-BA97A9535D83@icann.org> <68987c9a-599f-1a12-144e-697612aac105@nic.cz> <86322707-A3EC-4574-96B1-977D664053FE@vpnc.org> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <85032928-8f1d-e1c2-fbfd-9b2db97537a0@nic.cz> Date: Mon, 6 Nov 2017 16:56:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <86322707-A3EC-4574-96B1-977D664053FE@vpnc.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 15:56:58 -0000 On 6.11.2017 16:15, Paul Hoffman wrote: > Doesn't "I don't trust my parent's security policy" open up a million > cans of worms anyway? It feels like making this change to the default 1. The problem is that there were (and certainly will be) successfull hacks into registries, that seems just inevitable. 2. Vast majority of people will not bother with setting up own trust anchors. I.e. vast majority of people will not be affected by any brittlenes you envision. 3. The small fraction of people who configure their own TA do it for a reason. The reason I can see is "TA pinning". This provides users ability to to configure their critical systems in a way which turns successfull hack into my parent registry into Bogus status. Yes, it requires them to keep TA up-to-date, but that is the price you pay for pinning. > behavior will make validation more brittle (because people *will* forget > to update their lower-level trust anchors) in order to help a very small > number of people who could have made the configuration change themselves. Personally I do not see justification for 'trust DS or TA' behavior so I'm not willing to make security critical code paths more complex just for sake of having an unused configuration knob. In other words, "could have made the configuration change themselves" is not applicable here because the knob is not going to be available. I did my best to explain my reasoning, let me know if you can see some holes in the reasoning. -- Petr Špaček @ CZ.NIC From nobody Mon Nov 6 08:08:22 2017 Return-Path: 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 6E07913FAD9 for ; Mon, 6 Nov 2017 08:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 mKCE_q-mE7nq for ; Mon, 6 Nov 2017 08:08:19 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 6ADE913F698 for ; Mon, 6 Nov 2017 08:08:19 -0800 (PST) Received: from [10.32.60.122] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vA6G6q61073581 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Nov 2017 09:06:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.122] From: "Paul Hoffman" To: "Petr =?utf-8?b?xaBwYcSNZWs=?=" Cc: dnsop@ietf.org Date: Mon, 06 Nov 2017 08:08:17 -0800 Message-ID: In-Reply-To: <85032928-8f1d-e1c2-fbfd-9b2db97537a0@nic.cz> References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <20171101005014.0A2E38DCF888@rock.dv.isc.org> <49FB4D49-C7C7-44E3-B1A6-BA97A9535D83@icann.org> <68987c9a-599f-1a12-144e-697612aac105@nic.cz> <86322707-A3EC-4574-96B1-977D664053FE@vpnc.org> <85032928-8f1d-e1c2-fbfd-9b2db97537a0@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 16:08:20 -0000 On 6 Nov 2017, at 7:56, Petr Špaček wrote: > 2. Vast majority of people will not bother with setting up own trust > anchors. I.e. vast majority of people will not be affected by any > brittlenes you envision. > > 3. The small fraction of people who configure their own TA do it for a > reason. The reason I can see is "TA pinning". This provides users > ability to to configure their critical systems in a way which turns > successfull hack into my parent registry into Bogus status. > > Yes, it requires them to keep TA up-to-date, but that is the price you > pay for pinning. In retrospect, I agree that these two are good justification for "if a subordinate trust anchor has been configured, the default is to trust it more than the superordinate one" as long as the document also says "but this should be configurable". So, are you volunteering to start the effort for rfc6840-bis? :-) --Paul Hoffman From nobody Wed Nov 8 10:17:29 2017 Return-Path: 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 0ABE1129527 for ; Wed, 8 Nov 2017 10:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 p5NHU3aNf9gF for ; Wed, 8 Nov 2017 10:17:25 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0137C12950A for ; Wed, 8 Nov 2017 10:17:23 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 8 Nov 2017 10:17:20 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 8 Nov 2017 10:17:20 -0800 From: Edward Lewis To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= , Paul Hoffman , "dnsop@ietf.org" Thread-Topic: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors Thread-Index: AQHTVumQ9Sx/szK9UESN2BoiNrPbqKMH/JGAgAALagCAA0vtAA== Date: Wed, 8 Nov 2017 18:17:20 +0000 Message-ID: <67FFDD4B-285B-4F4C-ACE8-DB8B105FF0C0@icann.org> References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <20171101005014.0A2E38DCF888@rock.dv.isc.org> <49FB4D49-C7C7-44E3-B1A6-BA97A9535D83@icann.org> <68987c9a-599f-1a12-144e-697612aac105@nic.cz> <86322707-A3EC-4574-96B1-977D664053FE@vpnc.org> <85032928-8f1d-e1c2-fbfd-9b2db97537a0@nic.cz> In-Reply-To: <85032928-8f1d-e1c2-fbfd-9b2db97537a0@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3592991838_1037652375" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 18:17:28 -0000 --B_3592991838_1037652375 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 11/6/17, 10:57, "DNSOP on behalf of Petr =C5=A0pa=C4=8Dek" wrote: >I did my best to explain my reasoning, let me know if you can see some hol= es in the reasoning. Coming from my assumption that "use any chain" is the best way to go, I tri= ed to figure out why you are coming to a different conclusion. There are two "holes" I see. One is that DNSSEC's design is centered on pr= eventing a receiver from accepting forged data. Two is that the design of D= NSSEC has to take into account the limitations of the base (DNS) protocol. >From the point of view of a validator (operator), it is your choice to deci= de what to trust, or not. You may decide that a certain signed zone is crit= ical to your operations, so you get the DNSKEY with the SEP bit set and pin = it as trusted. How do you know whether the zone manages its keys in accorda= nce with Automated Updates of DNSSEC Trust Anchors? How do you know when to= update the trust anchor, especially if the zone is not running in accord wi= th Automated Updates? The DNS protocol doesn't let you know. You could find this via out-of-band= channels, like via something at a URL (listing the secure entry points), vi= a direct communication with the zone operators. The protocol (DNS) lacks per-zone signaling. For that reason, the assumpti= ons of how DNSSEC is set up assumes a unified one-protocol set up. E.g., ev= en in the early days, .COM was an unusual case and we were tempted to define= DNSSEC to act differently for it or other large delegated zones. It took a= while to get "opt-out" into the protocol in a way anyone could make use of = it, which was a central issue. (The history of that is murkier than I may b= e presenting.) We even tried to have different key "strengths." That failed to materializ= e as we realized the weakest link is still the weakest link. Trying to differentiate zones by "criticality" begins walking a thread of d= eciding "what is critical" and how does one decide that? (There are TLD ope= rators who told me "it's okay, we think of this TLD as experimental." To me= a TLD would be critical, but that view is apparently not universally shared= .) How would a validator determine, objectively, whether a zone is critical= to the validator's audience? Once it did determine, how would it know what= the security policy was of the zone (does it honor the add hold-down time, = etc., does it even separate the KSK from the ZSK, would it switch to a CSK, = and so on). I could see a knob for a validator operator to select zones for pinning the= trust anchors, for selecting them for STD 69 (Automated Update) treatment. = I can't see though having a restrictive policy (if trust anchor, no DS - so= to speak) be the default as that would be the unusual case (having a trust = anchor). DNSSEC never assumed that the whole tree would be signed. That is why trus= t anchors were invented. DNSSEC, at first, even tried to allow an arbitrary= policy of "who can sign what." (That is why there's "Domain Name System Se= curity Extensions" from March 1999 and then "Domain Name System Security (DN= SSEC) Signing Authority' from November 2000. That's RFC 2535 and 3008 for t= hose that speak RFC numbers. DNSSEC didn't adopt the on-tree signing author= ity until we exhausted attempts at something more liberal.) The problem wit= h arbitrary policies is that, first, you must be able to write them down. This is why the guidance in "Protocol Modifications for the DNS Security Ex= tensions" leads to "any" chain. "Clarifications and Implementation Notes for= DNS Security (DNSSEC)" opens the possibility that knobs can be included, wh= ich is the prerogative of the implementer to build and the operator to use (= local policy). I see these two documents as compatible. The bottom line is that one can choose to abide by a rule of "if a trust an= chor is there, ignore other chains" but recall that the choice is made by th= e validator operator, not the zone administrator, as the validator operator = is also responsible for keeping the trust anchors current and accurate, it i= s their own failure if that is not the case, and they exclusively have the a= bility to fix a conflict. The bottom line is that the zone administrator doesn't get a say - it's all= up to the validator operators. --B_3592991838_1037652375 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBS3gJiuaTZ5aOp6656j1ulKlkRm0zAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMDgxODE3MThaMA0GCSqGSIb3 DQEBAQUABIIBAKy85K7haRsqTS/ztmmbejyddIIZZWGYq2bYhwwKwldGDiWc49w79W1dPJg1 wY0zRuRzhEllmC5f26nueWwmjeeKgAs7iQro7dlsD9lEmrxaO4TQif0eC1SQSm2VigoMYDKM nn0yZ+4tZq+0FPkntUEQlEcp/ZJ3a/gnSiXl4i6jZvG9v4oFjzV6PeDbC/h0TUPfXTlXMQOj oe6v7piHjfOjklWrf+K86LxLsTUqmFMPcSsqZ6Ui32R/jcQJIzwEVtTSZudQsgjmyoCTvapt I5o28glK258qVjwW0UKzvp+TkYBQYf567XZEuc77Dqs7anykG+qQWrOUXEKne7rUpl4= --B_3592991838_1037652375-- From nobody Wed Nov 8 21:01:28 2017 Return-Path: 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 4963B12954C for ; Wed, 8 Nov 2017 21:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 D1BVI7WEPvgj for ; Wed, 8 Nov 2017 21:01:26 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 279911242EA for ; Wed, 8 Nov 2017 21:01:26 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yXWGW2kC5z38M for ; Thu, 9 Nov 2017 06:01:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510203683; bh=CJhuOGmIxwNhQSuQZNhCvQArZKu3ZL5YvA+uQkl9Xns=; h=Date:From:To:Subject:In-Reply-To:References; b=gucfMVyQpBNVG/ngpS+FO+YtgyXgv2i64/Itj/0npkQTnMVvvBm1xDsdlGI/CjCs2 fO5eOxYYPDJdHuyxBwsq36d0ks4Dba0V3m0ob4Gcn8Ei8t8MVxcXHj5qrKMeC3Ceg8 SpFNgVPxpIpRchHhfO8WyviDBSWBXe2UAmJaygQI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LSIW9dDQacBc for ; Thu, 9 Nov 2017 06:01:21 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 9 Nov 2017 06:01:20 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A1F9D62D29; Thu, 9 Nov 2017 00:01:19 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca A1F9D62D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7FC0F40D35AF for ; Thu, 9 Nov 2017 00:01:19 -0500 (EST) Date: Thu, 9 Nov 2017 00:01:19 -0500 (EST) From: Paul Wouters To: dnsop In-Reply-To: <67FFDD4B-285B-4F4C-ACE8-DB8B105FF0C0@icann.org> Message-ID: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <20171101005014.0A2E38DCF888@rock.dv.isc.org> <49FB4D49-C7C7-44E3-B1A6-BA97A9535D83@icann.org> <68987c9a-599f-1a12-144e-697612aac105@nic.cz> <86322707-A3EC-4574-96B1-977D664053FE@vpnc.org> <85032928-8f1d-e1c2-fbfd-9b2db97537a0@nic.cz> <67FFDD4B-285B-4F4C-ACE8-DB8B105FF0C0@icann.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 05:01:27 -0000 On Wed, 8 Nov 2017, Edward Lewis wrote: > This is why the guidance in "Protocol Modifications for the DNS Security Extensions" leads to "any" chain. "Clarifications and Implementation Notes for DNS Security (DNSSEC)" opens the possibility that knobs can be included, which is the prerogative of the implementer to build and the operator to use (local policy). I see these two documents as compatible. "prerogative of the implementer" canont apply to how one defines trust in a protocol. You can't have two implementations make different trust decisions, especially as most endusers don't control their resolver. > The bottom line is that one can choose to abide by a rule of "if a trust anchor is there, ignore other chains" but recall that the choice is made by the validator operator, not the zone administrator, as the validator operator is also responsible for keeping the trust anchors current and accurate, it is their own failure if that is not the case, and they exclusively have the ability to fix a conflict. > > The bottom line is that the zone administrator doesn't get a say - it's all up to the validator operators. It's up to neither. You cannot retroactively argue that hardcoding trust anchors is an option can that be ignored by an implementation. knot had a bug some people thought would be a nice fallback recovery feature to a failed rollover procedure. knot should just be fixed. This really does not require an RFC update. Paul From nobody Thu Nov 9 01:12:09 2017 Return-Path: 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 EE8F312ECA9 for ; Thu, 9 Nov 2017 01:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9Mh8HQHUq4Wh for ; Thu, 9 Nov 2017 01:12:06 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BCAC129B1E for ; Thu, 9 Nov 2017 01:12:06 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id y80so15468427wmd.0 for ; Thu, 09 Nov 2017 01:12:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JTX/43nfzAESNYDCfFszwJMigr5CUqSlZ8X939vKAxI=; b=B9V3DbYQP6TA44XEHQpfB5NWs3AzzxoiWfT5jBKRxXkkQzU3AboSFg1F3e6ZDAnIOr qDHwf+80C2/S8pXFqIUXLpBeowGT8m6ZSmN4uE0v9zB3V7q/2ekS5jlIwJwgM80UX2nv 3WFsxqygukKw5dnAUj9T/VLQ2M8OUw3/isJor8BdMqKU+CM52m7z0+TLLTO3kV45eX4M H3KD3HCgrdd3CaQASow7RMenWfkE62iMAc8sMD5VV3HKw2aCmsapH8ewVe+r6Q+ij2qW p23KtUnzQcXfX3WmOyNx+EMuvCpC9gxsBfLVtJG0zoroCW66poJmS9TgVAl+alWVb+4t GRsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JTX/43nfzAESNYDCfFszwJMigr5CUqSlZ8X939vKAxI=; b=iL78OMiZRu4v0cXzSF0actV9d9xSW7lfe2DasxD7bJ/IatInv1BUOmznBslNs8knss QiM/qSZrKvwb2sFLjJ1BOHp11UJo2TvJOGzyK8EBATmsmKL/SoJXMobv4JV21exzNv/r lzky11I1dKvho+lYEd/f2F1pMwNKWI/TXA1tdromJpF20RHoz8I7nl+x5K+cfEl9WJfY z2vWnXU20bZwmpiZ+f4GL/e/x0ZCsCJp5zbRPHaRqKqYD+B5/XtFZ6TRDOeYYJpTp1O2 a2b8gYRRbaOPf67ZjLrZ1tvpJKGGEKqf3QqTQq8MEIF/aJXxun5ZtEnyEkwau+1MR27N Nv3g== X-Gm-Message-State: AJaThX4FOgXQnPI/EKnmelVJ7Sw9PFKCR4B+tOX47HL+zJzztyvnmieo k+UNf6X0rHWTw5uocfMNvea8X8qHQBQtfolKYzQ= X-Google-Smtp-Source: ABhQp+R+zQjJs0U1dNFS3JFILxhwSnZEoeVkQ01syLKUhCQPJPcwXfamLMCBuZY3w4iheoyLidm1HbXHv2gJbxjTMP8= X-Received: by 10.80.181.194 with SMTP id a60mr4263153ede.231.1510218725015; Thu, 09 Nov 2017 01:12:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lanlan Pan Date: Thu, 09 Nov 2017 09:11:54 +0000 Message-ID: To: Brian Dickson Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c19568ea34761055d893243" Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 09:12:09 -0000 --94eb2c19568ea34761055d893243 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brian Dickson =E4=BA=8E2017=E5=B9=B411=E6=9C= =883=E6=97=A5=E5=91=A8=E4=BA=94 =E4=B8=8A=E5=8D=883:58=E5=86=99=E9=81=93=EF= =BC=9A > (Apologies for neither top- nor bottom- posting, i.e. not quoting any > other emails.) > > There are corner cases which exist, where desired behavior of some > resolvers is not possible to achieve. > > This mostly has to do with constraints where "local policy" may have more > than one scope. > > I.e. Inside a big enough org, there may be a "large" local policy which > conflicts with local policy of smaller sub-orgs. > > Here's an example: > - Suppose an enterprise E has perimeter resolvers, which do not validate > DNSSEC. > - Suppose that E blocks DNS traffic to the outside world, except from > those perimeter resolvers. > - Now suppose a small org within E, call it E-prime, deploys DNSSEC using > its own local trust anchor. > > The issue has to do with not only which trust anchor is preferred for any > given portion of the DNS tree, but also whether the policy of "validation= " > applies, and with what scope. > > There may be other corner cases, but the main point is that the above > scenario does not depend on any notion of "split DNS" per se. The E-prime > element is, for sake of argument, still globally resolvable, but happens = to > be an "island of security". There is no split DNS. > no split DNS +1 very hard work: maintain many trust anchors like TLS CA, make sure information automate update in global recursive resolvers. limit local policy: special zone publish its own trust anchor, a small sets of recursive resolvers configure to trust it, similar with some local root hints for short rescue time. (if software support) > > I think the question may boil down to the following: > - What local policies might operators need to configure? > - What advice to implementers can be provided, given the possible > complexities of what operators need? > - Does it make sense to formalize (or at least categorize) policy logic? > - What defaults are likely to maximize "correct" behavior, and/or minimiz= e > failures? > - E.g. suppose the presence of trust anchors in non-5011 configuration > files, vs trust anchors in 5011 configuration files, and suppose multiple > trust anchors. Is the mere existence of a trust anchor sufficient to sign= al > intent, or is it always the case that some policy needs to be declared ov= er > the combination of all existing trust anchors? > > Brian > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --94eb2c19568ea34761055d893243 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Brian = Dickson <brian.peter.di= ckson@gmail.com>=E4=BA=8E2017=E5=B9=B411=E6=9C=883=E6=97=A5=E5=91=A8= =E4=BA=94 =E4=B8=8A=E5=8D=883:58=E5=86=99=E9=81=93=EF=BC=9A
(Apologies for neither top- nor b= ottom- posting, i.e. not quoting any other emails.)

Ther= e are corner cases which exist, where desired behavior of some resolvers is= not possible to achieve.

This mostly has to do wi= th constraints where "local policy" may have more than one scope.=

I.e. Inside a big enough org, there may be a &quo= t;large" local policy which conflicts with local policy of=C2=A0 small= er sub-orgs.

Here's an example:
- Su= ppose an enterprise E has perimeter resolvers, which do not validate DNSSEC= .
- Suppose that E blocks DNS traffic to the outside world, excep= t from those perimeter resolvers.
- Now suppose a small org withi= n E, call it E-prime, deploys DNSSEC using its own local trust anchor.

The issue has to do with not only which trust anchor i= s preferred for any given portion of the DNS tree, but also whether the pol= icy of "validation" applies, and with what scope.

<= /div>
There may be other corner cases, but the main point is that the a= bove scenario does not depend on any notion of "split DNS" per se= . The E-prime element is, for sake of argument, still globally resolvable, = but happens to be an "island of security". There is no split DNS.=

no split DNS=C2=A0+1
=

very hard work: maintain many trust anchors like TLS CA= , make sure information automate update in global recursive resolvers.

limit local policy: special zone publish its own trust= anchor, a small sets of recursive resolvers configure to trust it, similar= with some local root hints for short rescue time. (if software support)
=C2=A0

I think the question may boil down to the following:
=
- What local policies might operators need to configure?
- W= hat advice to implementers can be provided, given the possible complexities= of what operators need?
- Does it make sense to formalize (or at= least categorize) policy logic?
- What defaults are likely to ma= ximize "correct" behavior, and/or minimize failures?
- = E.g. suppose the presence of trust anchors in non-5011 configuration files,= vs trust anchors in 5011 configuration files, and suppose multiple trust a= nchors. Is the mere existence of a trust anchor sufficient to signal intent= , or is it always the case that some policy needs to be declared over the c= ombination of all existing trust anchors?
=
Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
=E8=87=B4=E7= =A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanl= an
--94eb2c19568ea34761055d893243-- From nobody Thu Nov 9 05:29:41 2017 Return-Path: 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 A8A241242F5 for ; Thu, 9 Nov 2017 05:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUaCnem_8QON for ; Thu, 9 Nov 2017 05:29:37 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09A31201FA for ; Thu, 9 Nov 2017 05:29:37 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Nov 2017 05:29:35 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 9 Nov 2017 05:29:35 -0800 From: Edward Lewis To: Paul Wouters , dnsop Thread-Topic: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors Thread-Index: AQHTVumQ9Sx/szK9UESN2BoiNrPbqKMH/JGAgAALagCAA0vtAIAAs/CAgACN/4A= Date: Thu, 9 Nov 2017 13:29:34 +0000 Message-ID: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <20171101005014.0A2E38DCF888@rock.dv.isc.org> <49FB4D49-C7C7-44E3-B1A6-BA97A9535D83@icann.org> <68987c9a-599f-1a12-144e-697612aac105@nic.cz> <86322707-A3EC-4574-96B1-977D664053FE@vpnc.org> <85032928-8f1d-e1c2-fbfd-9b2db97537a0@nic.cz> <67FFDD4B-285B-4F4C-ACE8-DB8B105FF0C0@icann.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3593060973_13227723" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 13:29:40 -0000 --B_3593060973_13227723 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 11/9/17, 00:01, "DNSOP on behalf of Paul Wouters" wrote: >"prerogative of the implementer" canont apply to how one defines trust >in a protocol. You can't have two implementations make different >trust decisions, especially as most endusers don't control their >resolver. The first split I make when considering this is the difference between general purpose implementations - such as BIND, Unbound, Microsoft's, and others that are distributed to a general population - and turn-key implementations which are purpose built for a specific need. The latter do exist, are generally not considered when it comes to standards as, for them, conformance to open standards just doesn't matter. For general purpose implementations, it is up to the distributor of the software to decide what and how to implement. Whether to faithfully implement a Request for Comments is a choice. I have been witness to an implementation that tried to fix itself to be more compliant only to find the relying parties balking, requesting a return to the non-conformant behavior. When it comes to DNS resolution, there is the basic protocol to implement - the messages, the formats, timing, etc. If not done correctly, a resolution engine may suffer rcode=FORMERR and get nowhere. But there is a lot of choice for an implementer and still remain interoperable with other software builds. One feature is what I've often called the "aggressive nature" of searching for an answer. Neglecting DNSSEC for the moment, in 2012 I tried to write a basic resolver to find information about a popular ranking engine's top zones. I discovered that many of the zones were "broken" in the sense that the servers operating them did not answer queries for SOA, NS, etc., errors that should have made the zones unreachable. Yet these zones were ranked as popular. I realized that general purpose resolvers went beyond the basic strategy for getting an answer, I mentally tagged this as "aggressive resolution". In the same sense that an experienced librarian may find a reference book that an inexperienced one may not. DNSSEC offers more choice in terms of aggressive resolution. For example, if a resolver is suffering a forgery attack (a'la what Kaminsky described long ago now) the first response the resolver would get is the forgery. If the resolver waited longer, the real answer would likely arrive. Early, and as far as I know still true for current, resolvers close their listener after getting the forgery. It is possible to continue listening (but for how long?) to get the real answer. With DNSSEC proving the first answer wrong, the real answer could be validated - if the listener is not torn down. I understand why this more aggressive implementation was not chosen. There is much leeway in what an implementer chooses to encode. The goal of the RFC series, early on at least, was to give guidance on how to allow interoperability. The documents are not requirements nor design guides. I spent a long time with "The Algorithm" in section 4.3.2 of "Domain Concepts and Facilities" (part of STD 13) to come to know what that means. (Thanks to Rob Austein.) Implementers, like any kind of writer, have to put their audience foremost in mind. This is why there are many extra-standards features (and bloat) in software today. (Round-robin deliver of answers worked its way into mainstream code that way.) Implementers have to balance simplicity of tools with functionality via complex configurations. I've been told that many times the operator will just go with the default settings - so that is important. >It's up to neither. You cannot retroactively argue that hardcoding trust anchors is an option can that be ignored by an implementation. I don't understand this point. If you are referring to the practice of general purpose code shipping with a set of trust anchors, at least in BIND one can turn DNSSEC off - or remove/override the packaged defaults. That is useful when deploying code on a network that is not the global public internet. >knot had a bug some people thought would be a nice fallback recovery feature to a failed rollover procedure. knot should just be fixed. This really does not require an RFC update. It's not clear whether the "bug" was a "feature you didn't like" or a coding error from this statement, so I don't know what the latter sentence is saying. I realize I'm writing a lot, and I'm not sure I'm making a strong enough case about why "for the sake of resiliency" any chain that validates ought to be taken as a good thing. This might take a different approach as trying to talk about "trust" is too ill-defined when discussing a protocol whose basic design did not consider "trust" regarding the data delivered. "Trustworthiness" in "Clarifications to the DNS Specification" relied on what section the data appeared in a response and from what IP address it came. Forgeries weren't considered even in that round of clarification. --B_3593060973_13227723 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSNeL4oXeOCw7jOkw1kCkdGN7mnKjAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMDkxMzI5MzNaMA0GCSqGSIb3 DQEBAQUABIIBAJaA+b70E2p6q6IAvnCZqGJIJZCMEsYqa7hGfZAH7aFJcynmCCpZlOf/7xTg u74xe2U/pHQjx9y7wJPmKBk/Hk2ACxD6QsdisJFAe8sQdJ680R9U8po06XP7/lHRBF3GbdXl IvJmxRL1uXMnhshFgzI5oo3qsIq5lFrHanTXo98hW6eCRIDzatQ1Mi+T3FVkVrangLFk1jp5 f/GDTzOO9UCZlLjPUC5NcIYX1FQAkSwIbOOmEKZbLUljSRUmy0wizS5n2XjPRbJMoFpXWlOJ Dk8mlxoCn9WAFoWOnPbukfr151mW5NEd+LvsLOxN+8bjZ5cS001F6wvrVVzdgll/SZ0= --B_3593060973_13227723-- From nobody Thu Nov 9 06:17:14 2017 Return-Path: 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 B545E1200F3 for ; Thu, 9 Nov 2017 06:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com 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 F9CgpMOrB5dX for ; Thu, 9 Nov 2017 06:17:11 -0800 (PST) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 952D5124319 for ; Thu, 9 Nov 2017 06:17:11 -0800 (PST) Received: by mail-wr0-x232.google.com with SMTP id j15so5729782wre.8 for ; Thu, 09 Nov 2017 06:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9LvNclAUu2+8ud2P3QWNE8HPSL+6ZTyi4LZFWdinmkc=; b=fVtgLfN9yc3iQLVlzmTITfuzqqUW0/31tS58c4XBG/q06F8AIdrparG5CmlX1O0fOW Cqm3xTfalNwrUjy6Dgkas/L5bbsHHv+gIfP3x/MuClRZ0Vj3O7RjyQwXAiSfLvYjPTmg XmBbc8vWJ8czorh0vPzAFTjdicHkRFvHPOPbQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9LvNclAUu2+8ud2P3QWNE8HPSL+6ZTyi4LZFWdinmkc=; b=TUl3eXE9SKLk4xmHdBkAMN5zqTXOD2gLLTyh4MNfbkVwqWNrHFzZyeG46SQSyJjyz4 TbSUoTqv6o4Ga1fFU7OdbUVLNrcebH+spxdZ1HfG3HjceoTGvEtXNpotJPgeSL1JIHga Xgj1cLzqxAhOZSRSdvsyRIiaFTWKOc45TZjPKf9QSp0SijGnOOlWuQeUa8Qf5bHILxyu T4B0mwI46pGuG2yFP4xm0XaNCEsOjbtqxqsx3z0Q56sWqhPkNbLszVnmBiNG3DRuO6S/ iqz3hDcnJ6ISuuakDJbrdGaG3r++Tap8EXig2j9Hdk172seP/U8aOOKIH5NMClfpZqHc q95A== X-Gm-Message-State: AJaThX4MUzcrX37GqhJA3ugyYmi8Wvnw09xQUELsLn2uQ3mNn2f5oQCt i+6WvHIDxkVlRKcFvSpFPMrr8XfEe7Drrl5l/tl5kQWW X-Google-Smtp-Source: ABhQp+Tr0HE8qCFyMmrlWeb0L/6MF6zXbXGE4LXKuJW1BO6RRjrQqYGZiKgdQqmxZuiTDDZ0qqNL2fLTj4UVSXg2i8k= X-Received: by 10.223.187.3 with SMTP id r3mr582825wrg.34.1510237029983; Thu, 09 Nov 2017 06:17:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.201.10 with HTTP; Thu, 9 Nov 2017 06:17:09 -0800 (PST) In-Reply-To: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <20171101005014.0A2E38DCF888@rock.dv.isc.org> <49FB4D49-C7C7-44E3-B1A6-BA97A9535D83@icann.org> <68987c9a-599f-1a12-144e-697612aac105@nic.cz> <86322707-A3EC-4574-96B1-977D664053FE@vpnc.org> <85032928-8f1d-e1c2-fbfd-9b2db97537a0@nic.cz> <67FFDD4B-285B-4F4C-ACE8-DB8B105FF0C0@icann.org> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Thu, 9 Nov 2017 09:17:09 -0500 Message-ID: To: Paul Wouters Cc: dnsop Content-Type: multipart/alternative; boundary="089e0821528cb2f43f055d8d75a7" Archived-At: Subject: Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 14:17:14 -0000 --089e0821528cb2f43f055d8d75a7 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 9, 2017 at 12:01 AM, Paul Wouters wrote: > On Wed, 8 Nov 2017, Edward Lewis wrote: > > This is why the guidance in "Protocol Modifications for the DNS Security >> Extensions" leads to "any" chain. "Clarifications and Implementation Notes >> for DNS Security (DNSSEC)" opens the possibility that knobs can be >> included, which is the prerogative of the implementer to build and the >> operator to use (local policy). I see these two documents as compatible. >> > > "prerogative of the implementer" canont apply to how one defines trust > in a protocol. You can't have two implementations make different > trust decisions, especially as most endusers don't control their > resolver. > > Paul, I have been thinking about what you said and why it is perfectly valid, but that I think it is wrong. The issue here is three fold IMHO Operator is using split-DNS i.e. internal and external Operator is using the SAME name space for both views i.e. foo.example.com can exist in both name spaces with different values. Operator is using DIFFERENT keys to sign the two namespaces. We have no way at the moment to express which namespace a "name" comes from thus you want to give preference to the "internal" namespace for users of that namespace The purist in me says this is bad setup, the practical part of me says "you get what you ask for" i.e. IETF failed to write guidelines for Spit-DNS thus we should expect things like this. Either way I think the use of Different Key is what we should strongly discourage as that makes the other problems go away. The bottom line is that one can choose to abide by a rule of "if a trust >> anchor is there, ignore other chains" but recall that the choice is made by >> the validator operator, not the zone administrator, as the validator >> operator is also responsible for keeping the trust anchors current and >> accurate, it is their own failure if that is not the case, and they >> exclusively have the ability to fix a conflict. >> >> The bottom line is that the zone administrator doesn't get a say - it's >> all up to the validator operators. >> > > It's up to neither. You cannot retroactively argue that hardcoding trust > anchors is an option can that be ignored by an implementation. > > knot had a bug some people thought would be a nice fallback recovery > feature to a failed rollover procedure. knot should just be fixed. This > really does not require an RFC update. > > Paul > > Olafur --089e0821528cb2f43f055d8d75a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Nov 9, 2017 at 12:01 AM, Paul Wouters <paul@nohats.ca> wrote:
On Wed, 8 Nov= 2017, Edward Lewis wrote:

This is why the guidance in "Protocol Modifications for the DNS Securi= ty Extensions" leads to "any" chain. "Clarifications an= d Implementation Notes for DNS Security (DNSSEC)" opens the possibilit= y that knobs can be included, which is the prerogative of the implementer t= o build and the operator to use (local policy).=C2=A0 I see these two docum= ents as compatible.

 "prerogative of the implementer" canont apply to how one defines = trust
in a protocol. You can't have two implementations make different
trust decisions, especially as most endusers don't control their
resolver.


Paul,=C2=A0

I have been thinking about what you said and why it is perfectly vali= d, but that I think it is wrong.=C2=A0
The issue here is three fo= ld IMHO=C2=A0
Operator is using split-DNS i.e. internal and exter= nal=C2=A0
Operator is using the SAME name space for both views=C2= =A0 i.e. foo.example.com can exist i= n both name spaces with different values.=C2=A0
Operator is using= DIFFERENT keys to sign the two namespaces.=C2=A0

= We have no way at the moment to express=C2=A0 which namespace a "name&= quot; comes from thus you want to give preference to the "internal&quo= t; namespace for users of that namespace=C2=A0

The= purist in me says this is bad setup, the practical part of me says "y= ou get what you ask for" i.e. IETF failed to write guidelines for Spit= -DNS thus we should expect things like this.=C2=A0
Either way I t= hink the use of Different Key is what we should strongly discourage as that= makes the other problems go away.=C2=A0

The bottom line is that one can choose to abide by a rule of "if a tru= st anchor is there, ignore other chains" but recall that the choice is= made by the validator operator, not the zone administrator, as the validat= or operator is also responsible for keeping the trust anchors current and a= ccurate, it is their own failure if that is not the case, and they exclusiv= ely have the ability to fix a conflict.

The bottom line is that the zone administrator doesn't get a say - it&#= 39;s all up to the validator operators.

 It's up to neither. You cannot retroactively argue that hardcoding trus= t
anchors is an option can that be ignored by an implementation.

knot had a bug some people thought would be a nice fallback recovery
feature to a failed rollover procedure. knot should just be fixed. This
really does not require an RFC update.

Paul

<= /blockquote>
Olafur
=C2=A0
--089e0821528cb2f43f055d8d75a7-- From nobody Thu Nov 9 06:39:54 2017 Return-Path: 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 EF39C128B51 for ; Thu, 9 Nov 2017 06:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3KjDbFQxh3km for ; Thu, 9 Nov 2017 06:39:50 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E1C124319 for ; Thu, 9 Nov 2017 06:39:50 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Nov 2017 06:39:48 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 9 Nov 2017 06:39:48 -0800 From: Edward Lewis To: dnsop Thread-Topic: Configured Trust Anchor vs. DS record Thread-Index: AQHTWWiXPRp7CRP4/kG/0ZKc0dRV5w== Date: Thu, 9 Nov 2017 14:39:47 +0000 Message-ID: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3593065186_1844476778" MIME-Version: 1.0 Archived-At: Subject: [DNSOP] Configured Trust Anchor vs. DS record X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 14:39:52 -0000 --B_3593065186_1844476778 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit To set up the problem to solve. Asking for points that are missed. (Purposefully omitting the trailing dot, not talking about 'root' because that could get confusing.) Trust anchor for "one/17" (i.e., key_id=17) Trust anchor for "two.one/145" Received data for "three.two.one" signed by "two.one/9342" What would cause "two.one/9342" to be signed by "one/17" and not by "two.one/145"? (I think this captures the question of interest.) 1. "two.one/145" is in the MISSING state from STD 69. 2. "two.one/145" was revoked but the validator didn't remove it. 3. "two.one/145" is stale, as the validator is not using STD 69. 4. "two.one" was re-delegated, the previous holder still uses "two.one/145" 5. (open for more scenarios of "why") What should the validator do with the response? For cases 1,2,3, the chain ought to be accepted. For case 4, although the appropriate DNS response (according to the DNS protocol) was received, the application calling it might not want to take action based on the response (action such as open a connection and/or flow data). Is there a way, within the DNS, to differentiate amongst the reasons why the response is signed up to "one" and not "two.one"? Is there a way the application can tell? With DANE as "an application" in mind: When it comes to DANE, what bothers me is this, in "DNS-Based Authentication for TLS", the section "The Certificate Usage Field" (that is RFC 6698, section 2.1.1), for value "3 -- Certificate usage 3". For that value, this is stated: "PKIX validation is not tested for certificate usage 3". My reading of this is that the "problem" with PKIX certificate authorities has just been shifted over to DNS hosting services (in this case for "one"), concerns about the DNS hoster are on par with concerns regarding the certificate authorities. (In essence, either could re-delegate a name.) (Yes, this is a tangential off-shoot, anticipating questions about how DANE plays with this.) In essence, usage 3 removes the benefit of pinning, which the application could use to detect a re-delegation. --B_3593065186_1844476778 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSDcwGRtujzhbI1ljF2dZNZGA+jGTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMDkxNDM5NDZaMA0GCSqGSIb3 DQEBAQUABIIBAHQ0UL2RApzu+FzhSZBeqtHPprRkURJWGRjWUd6WGVCAxg1P/WyPMO7PVeyQ GOhlzWwFgMfT8bD1xca+BQ1yr8dsO4Pr6Mqu/MDnjazQYrcafS+9nrmq1m8Kej2h3RUXD7qg Wi4Hgfu2Vb68PIvQFjGN5NM5D3f1r+2FvS9NB1DYkkEEN7fTZCAu/Eh4knY2JX2QTYd4pgJM ZSaGSOTDd4vt7VQTAQg9SdZTCtrQ7tQ0kwUQtrUL5PHz+08TOnVDgoYLAOPhYJ6prRm7gSGC mvheFNg1yXKb4HMh9yaYIJjIiJTrXzF90gaG0fFFinxQ8w+5sJMtRzoZUlstpmvRJts= --B_3593065186_1844476778-- From nobody Thu Nov 9 06:48:33 2017 Return-Path: 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 4704312EC9C for ; Thu, 9 Nov 2017 06:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 0qplyKPxSqXP for ; Thu, 9 Nov 2017 06:48:30 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 4DA47126CF9 for ; Thu, 9 Nov 2017 06:48:29 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:2814:1dff:feea:faf7] (unknown [IPv6:2001:1488:fffe:6:2814:1dff:feea:faf7]) by mail.nic.cz (Postfix) with ESMTPSA id CF04C641E0 for ; Thu, 9 Nov 2017 15:48:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510238906; bh=suqnqTCeaVlynUWt8tkP3z0poDy0dx5hKQZq7nMF1oE=; h=To:From:Date; b=I/JZdKz11FfyofwkPMrCq7HKbHCXuCzWTmSNOefkBn5BF4W0TK+3dGoUIrD6a8MJ+ XHawXR+rugqMXDHdd7I0IfvaHqL38N304LkepLR2UPFe5OeTsDvYvBOZGDsmPbgAvE tFmcPH3aUh7GnNK2FiEQbZF31upFaUtLD/rb4QAY= To: dnsop@ietf.org References: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Thu, 9 Nov 2017 15:48:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] Configured Trust Anchor vs. DS record X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 14:48:32 -0000 On 9.11.2017 15:39, Edward Lewis wrote: > To set up the problem to solve. Asking for points that are missed. > > (Purposefully omitting the trailing dot, not talking about 'root' because that could get confusing.) > > Trust anchor for "one/17" (i.e., key_id=17) > > Trust anchor for "two.one/145" > > Received data for "three.two.one" signed by "two.one/9342" > > What would cause "two.one/9342" to be signed by "one/17" and not by "two.one/145"? (I think this captures the question of interest.) > > 1. "two.one/145" is in the MISSING state from STD 69. > 2. "two.one/145" was revoked but the validator didn't remove it. > 3. "two.one/145" is stale, as the validator is not using STD 69. > 4. "two.one" was re-delegated, the previous holder still uses "two.one/145" > 5. (open for more scenarios of "why") > > What should the validator do with the response? > > For cases 1,2,3, the chain ought to be accepted. > > For case 4, although the appropriate DNS response (according to the DNS protocol) was received, the application calling it might not want to take action based on the response (action such as open a connection and/or flow data). > > Is there a way, within the DNS, to differentiate amongst the reasons why the response is signed up to "one" and not "two.one"? > > Is there a way the application can tell? > > With DANE as "an application" in mind: When it comes to DANE, what bothers me is this, in "DNS-Based Authentication for TLS", the section "The Certificate Usage Field" (that is RFC 6698, section 2.1.1), for value "3 -- Certificate usage 3". For that value, this is stated: "PKIX validation is not tested for certificate usage 3". My reading of this is that the "problem" with PKIX certificate authorities has just been shifted over to DNS hosting services (in this case for "one"), concerns about the DNS hoster are on par with concerns regarding the certificate authorities. (In essence, either could re-delegate a name.) (Yes, this is a tangential off-shoot, anticipating questions about how DANE plays with this.) In essence, usage 3 removes the benefit of pinning, which the application could use to detect a re-delegation. Nice write-up Edward! You have nicely summarized why Mark and me agree that validator should use longest suffix match when selecting TA to validate data. Things might get even more complicated when negative trust anchors are configured, bleh. Let me repeat that I very much prefer longest suffix match because it is predictable, easy to understand, and thus more secure than "use any". (And again, this is relevant only to people who bothered to configure TA for domain different than root, i.e. largely irrelevant for vast majority of users.) -- Petr Špaček @ CZ.NIC From nobody Thu Nov 9 09:48:14 2017 Return-Path: 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 8253D12878D for ; Thu, 9 Nov 2017 09:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 a07_uvgfzhq1 for ; Thu, 9 Nov 2017 09:48:06 -0800 (PST) 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 AB4531286B2 for ; Thu, 9 Nov 2017 09:48:06 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 28B133BAC8A; Thu, 9 Nov 2017 17:48:05 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 11344216C1C; Thu, 9 Nov 2017 17:48:05 +0000 (UTC) Date: Thu, 9 Nov 2017 17:48:05 +0000 From: Evan Hunt To: Petr =?utf-8?B?xaBwYcSNZWs=?= Cc: dnsop@ietf.org Message-ID: <20171109174804.GA63012@isc.org> References: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] Configured Trust Anchor vs. DS record X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 17:48:12 -0000 On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr Špaček wrote: > Nice write-up Edward! You have nicely summarized why Mark and me agree > that validator should use longest suffix match when selecting TA to > validate data. +1. > Things might get even more complicated when negative trust anchors are > configured, bleh. Fortuantely a negative trust anchor is a longest suffix match too. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Fri Nov 10 04:18:28 2017 Return-Path: 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 0A67812EC13 for ; Fri, 10 Nov 2017 04:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 G6SmixhEDlYf for ; Fri, 10 Nov 2017 04:18:25 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 8769712702E for ; Fri, 10 Nov 2017 04:18:25 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 0B82C31D12; Fri, 10 Nov 2017 13:18:23 +0100 (CET) Received: by godin (Postfix, from userid 1000) id F1908EC10C2; Fri, 10 Nov 2017 13:12:41 +0100 (CET) Date: Fri, 10 Nov 2017 20:12:41 +0800 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20171110121241.GA2621@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [DNSOP] draft-wkumari-dnsop-internal and DNAME X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 12:18:27 -0000 draft-wkumari-dnsop-internal-00 says "This document requests that the .internal TLD be assigned to the IANA (similar to the way that .example is) and a DNSSEC insecure delegation (that is, a delegation with no DS records) be inserted into the root-zone, delegated to blackhole-[12].iana.org." This implies NS records in the root. Why not using the DNAMEs of RFC 7535 instead? I understand there is currently no ICANN process to add DNAME in the root zone but there is no process to add .internal either. (draft-bortzmeyer-dname-root may be relevant here.) From nobody Fri Nov 10 04:18:35 2017 Return-Path: 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 7E4C812EC20 for ; Fri, 10 Nov 2017 04:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 2B9d41oJh4kB for ; Fri, 10 Nov 2017 04:18:25 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 87E011289C3 for ; Fri, 10 Nov 2017 04:18:25 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 1447931D16; Fri, 10 Nov 2017 13:18:23 +0100 (CET) Received: by godin (Postfix, from userid 1000) id D5DC6EC10C2; Fri, 10 Nov 2017 13:16:00 +0100 (CET) Date: Fri, 10 Nov 2017 20:16:00 +0800 From: Stephane Bortzmeyer To: tjw ietf Cc: dnsop Message-ID: <20171110121600.GA2749@laperouse.bortzmeyer.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] Agenda for IETF100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 12:18:28 -0000 On Fri, Nov 03, 2017 at 11:07:54PM -0400, tjw ietf wrote a message of 202 lines which said: > As you can see, we have time for our Monday Morning slot of 2.5 hours. > Because of this, we're currently planning on giving back the Thursday > meeting slot. Any news on that? The monday session collides with DIN which is really unfortunate for me because they talk a lot about name resolution (Namecoin, Ethereum Name Service). I may face a hard choice. (And thursday collides with CBOR, which is a smaller problem for me.) From nobody Fri Nov 10 04:28:29 2017 Return-Path: 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 60F5512702E for ; Fri, 10 Nov 2017 04:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 GvztZxD3rtPX for ; Fri, 10 Nov 2017 04:28:26 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 00BDD12EC24 for ; Fri, 10 Nov 2017 04:28:25 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yYK7q1L45z5T4; Fri, 10 Nov 2017 13:28:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510316903; bh=UMKnCSia+qE2ulN1q7nFN21oUrk4mJMZ6kws6dUDEBQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ELK9sfTme1d5lm2ASLgUoxpqilXgfkIsqitN0tZ/5vN8RA/CT8C8KuD9U/wv8FrpZ dY0ZL9M1I4xNSVoCddfPxtirIdI9IQBKST761B8JlmGwyk99yh4P9ZJYVDPHu/vmjP QAamO3agY4XvvXiDAZpO+U8vZekrbCqvursL44lc= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id pzNUQV1oiq-W; Fri, 10 Nov 2017 13:28:20 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 10 Nov 2017 13:28:20 +0100 (CET) Received: from [IPv6:2402:3a80:521:9f87:24ab:802:7ac4:d051] (unknown [42.109.245.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 1BA5E62D29; Fri, 10 Nov 2017 07:28:19 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1BA5E62D29 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (15A432) In-Reply-To: <20171110121600.GA2749@laperouse.bortzmeyer.org> Date: Fri, 10 Nov 2017 17:58:13 +0530 Cc: tjw ietf , dnsop Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171110121600.GA2749@laperouse.bortzmeyer.org> To: Stephane Bortzmeyer Archived-At: Subject: Re: [DNSOP] Agenda for IETF100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 12:28:28 -0000 I can summarize ENS for you. It takes 4 out of 7 geeks to bypass the blockchain in case of emergency, cou= rt orders or kneecaps. According to the presentation held at ICANN60 Sent from my iPhone > On Nov 10, 2017, at 17:46, Stephane Bortzmeyer wrote: >=20 > On Fri, Nov 03, 2017 at 11:07:54PM -0400, > tjw ietf wrote=20 > a message of 202 lines which said: >=20 >> As you can see, we have time for our Monday Morning slot of 2.5 hours. >> Because of this, we're currently planning on giving back the Thursday >> meeting slot. >=20 > Any news on that? The monday session collides with DIN which is really > unfortunate for me because they talk a lot about name resolution > (Namecoin, Ethereum Name Service). I may face a hard choice. >=20 > (And thursday collides with CBOR, which is a smaller problem for me.) >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Fri Nov 10 05:53:11 2017 Return-Path: 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 EF5CA1242F7 for ; Fri, 10 Nov 2017 05:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NEUTRAL=0.779] autolearn=no 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 MOE4PSnmWg16 for ; Fri, 10 Nov 2017 05:53:08 -0800 (PST) Received: from smtp117.ord1d.emailsrvr.com (smtp117.ord1d.emailsrvr.com [184.106.54.117]) (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 11956120721 for ; Fri, 10 Nov 2017 05:53:07 -0800 (PST) Received: from smtp7.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp7.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 2F584C0075; Fri, 10 Nov 2017 08:53:07 -0500 (EST) X-Auth-ID: matt@kahlerlarson.org Received: by smtp7.relay.ord1d.emailsrvr.com (Authenticated sender: matt-AT-kahlerlarson.org) with ESMTPSA id 06CC0C0055; Fri, 10 Nov 2017 08:53:06 -0500 (EST) X-Sender-Id: matt@kahlerlarson.org Received: from [192.168.1.26] (static-71-178-167-85.washdc.fios.verizon.net [71.178.167.85]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:465 (trex/5.7.12); Fri, 10 Nov 2017 08:53:07 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Matt Larson In-Reply-To: <20171110121241.GA2621@laperouse.bortzmeyer.org> Date: Fri, 10 Nov 2017 08:53:06 -0500 Cc: dnsop@ietf.org X-Mao-Original-Outgoing-Id: 532014786.265238-29707d637f57f2c3517c265f179cc869 Content-Transfer-Encoding: quoted-printable Message-Id: <0C063F76-BFBD-4E54-AFBE-51B00678020B@kahlerlarson.org> References: <20171110121241.GA2621@laperouse.bortzmeyer.org> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] draft-wkumari-dnsop-internal and DNAME X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 13:53:09 -0000 > On Nov 10, 2017, at 7:12 AM, Stephane Bortzmeyer = wrote: >=20 > draft-wkumari-dnsop-internal-00 says "This document requests that the > .internal TLD be assigned to the IANA (similar to the way that > .example is) and a DNSSEC insecure delegation (that is, a delegation > with no DS records) be inserted into the root-zone, delegated to > blackhole-[12].iana.org." >=20 > This implies NS records in the root. Why not using the DNAMEs of RFC > 7535 instead? I understand there is currently no ICANN process to add > DNAME in the root zone but there is no process to add .internal > either. Without commenting on the contents of that particular draft, I'll note = that from a technical/mechanical perspective, ICANN's and Verisign's = root zone management systems already know how to deal with delegations. = A DNAME in the root would require an unknown level of development by = both parties. While you're correct about no existing process (that I'm aware of) to = add either .internal or a DNAME to the root, at least with a delegation = there is only process work, not technical work, as well. Adding new types of information to the root is certainly possible: I'm = not trying to discourage that. But for planning and expectation-setting = purposes, the community needs to take into account the long lead time = that will be required for anything that requires technical modifications = to the root zone management system. Matt From nobody Fri Nov 10 06:28:43 2017 Return-Path: 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 594DD1205F1 for ; Fri, 10 Nov 2017 06:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 dyqJPFiznDnx for ; Fri, 10 Nov 2017 06:28:39 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 868F21243FE for ; Fri, 10 Nov 2017 06:28:39 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id EB3CC31D12; Fri, 10 Nov 2017 15:28:36 +0100 (CET) Received: by godin (Postfix, from userid 1000) id 62188EC10C2; Fri, 10 Nov 2017 15:25:08 +0100 (CET) Date: Fri, 10 Nov 2017 22:25:08 +0800 From: Stephane Bortzmeyer To: Paul Wouters Cc: Stephane Bortzmeyer , tjw ietf , dnsop Message-ID: <20171110142508.GA4062@laperouse.bortzmeyer.org> References: <20171110121600.GA2749@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] Agenda for IETF100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 14:28:41 -0000 On Fri, Nov 10, 2017 at 05:58:13PM +0530, Paul Wouters wrote a message of 29 lines which said: > It takes 4 out of 7 geeks to bypass the blockchain in case of > emergency, court orders or kneecaps. > > According to the presentation held at ICANN60 Well, if someone at ICANN said so, someone is wrong (or, at the minimum, over-simplificator). From nobody Fri Nov 10 06:28:48 2017 Return-Path: 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 207B81205F1 for ; Fri, 10 Nov 2017 06:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9jppE-pfMceN for ; Fri, 10 Nov 2017 06:28:39 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 86BB61267BB for ; Fri, 10 Nov 2017 06:28:39 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id F2B1731D05; Fri, 10 Nov 2017 15:28:36 +0100 (CET) Received: by godin (Postfix, from userid 1000) id 66249EC10C2; Fri, 10 Nov 2017 15:28:18 +0100 (CET) Date: Fri, 10 Nov 2017 22:28:18 +0800 From: Stephane Bortzmeyer To: Matt Larson Cc: Stephane Bortzmeyer , dnsop@ietf.org Message-ID: <20171110142818.GB4062@laperouse.bortzmeyer.org> References: <20171110121241.GA2621@laperouse.bortzmeyer.org> <0C063F76-BFBD-4E54-AFBE-51B00678020B@kahlerlarson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C063F76-BFBD-4E54-AFBE-51B00678020B@kahlerlarson.org> X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] draft-wkumari-dnsop-internal and DNAME X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 14:28:42 -0000 On Fri, Nov 10, 2017 at 08:53:06AM -0500, Matt Larson wrote a message of 32 lines which said: > I'll note that from a technical/mechanical perspective, ICANN's and > Verisign's root zone management systems already know how to deal > with delegations. A DNAME in the root would require an unknown level > of development by both parties. I've never read the source code of the root zone management system, but it seems surprising that it could be a non-trivial level of development. I assume this system is complicated because it is highly sensitive, and because it needs to incorporate a lot of defenses against both mistakes and attacks, but they should be more or less the same for DNAME and NS/A/AAAA, no? > Adding new types of information to the root is certainly possible: > I'm not trying to discourage that. But for planning and > expectation-setting purposes, the community needs to take into > account the long lead time that will be required for anything that > requires technical modifications to the root zone management system. Wild guess (and I pay beers if I'm wrong): the technical work will take much less time than the process one. From nobody Fri Nov 10 06:47:46 2017 Return-Path: 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 DB103126CE8 for ; Fri, 10 Nov 2017 06:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 7BmoVRptdGIA for ; Fri, 10 Nov 2017 06:47:43 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 2B131120046 for ; Fri, 10 Nov 2017 06:47:43 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yYNDX4TmVzB2B; Fri, 10 Nov 2017 15:47:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510325260; bh=+/ZVKSkI5MlQ0aPiL7t5jLFm5ul5m8jlsTcHK7RFz1k=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=LEgrW3JF6pcYDONyS5/biUzCFGHfWRJCoUgtZqoIslViZNdTT1qoesR1sC8qSUY+b SuWP+e2IjWfZHcWmQ5f5Hy4X8wMLIYNZstMl/gJMGMaV4PcrOZI+HWZdiZu+zP/K5/ cp4iuuMu1FSTpOcsIgJMzWp07f9lsAwfnpDrnaBg= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id czOVvcGMaZYH; Fri, 10 Nov 2017 15:47:39 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 10 Nov 2017 15:47:38 +0100 (CET) Received: from [10.10.11.24] (unknown [1.186.85.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id D0A4262D29; Fri, 10 Nov 2017 09:47:37 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca D0A4262D29 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (15A432) In-Reply-To: <20171110142508.GA4062@laperouse.bortzmeyer.org> Date: Fri, 10 Nov 2017 20:17:34 +0530 Cc: tjw ietf , dnsop Content-Transfer-Encoding: 7bit Message-Id: References: <20171110121600.GA2749@laperouse.bortzmeyer.org> <20171110142508.GA4062@laperouse.bortzmeyer.org> To: Stephane Bortzmeyer Archived-At: Subject: Re: [DNSOP] Agenda for IETF100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 14:47:45 -0000 The ENS developer said so in response to my question. Sent from my iPhone > On Nov 10, 2017, at 19:55, Stephane Bortzmeyer wrote: > > On Fri, Nov 10, 2017 at 05:58:13PM +0530, > Paul Wouters wrote > a message of 29 lines which said: > >> It takes 4 out of 7 geeks to bypass the blockchain in case of >> emergency, court orders or kneecaps. >> >> According to the presentation held at ICANN60 > > Well, if someone at ICANN said so, someone is wrong (or, at the > minimum, over-simplificator). > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Fri Nov 10 11:04:21 2017 Return-Path: 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 5A0E91293F2 for ; Fri, 10 Nov 2017 11:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized-org.20150623.gappssmtp.com 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 IPTpGqBRazKD for ; Fri, 10 Nov 2017 11:04:16 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2770B1293E0 for ; Fri, 10 Nov 2017 11:04:16 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id j16so2532990pgn.9 for ; Fri, 10 Nov 2017 11:04:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=R1uwJvf1MRlSh0teK6HRUFQH6/+BBggMbJinTPI+T4A=; b=aQj10fe0CdiXlprqapRnF7bCZvr22ZuS1mHf85efTBvxsbUxv/RWgt6bFopdJgqbOr WSJcx7lnUwYh1+jM3942lwuGTb/tOHctDgoTughH1FqReaNB73YHLz8SypscXUEjLu+x rBJBsIrrLDpCdQvyMghT8YKGMnyEEVnEMjB0W7aXJTelhnLzbmPA7yiLPbWYB525qm6L vSKv2JhXwMND6sJXC/8z8xmTEYhtf3xvnqDkM21HXSDCKeQ/qTHeOtzKouAnziddNFK3 mQDnH7nHLd1rNgbvGplkBcHOyF7VNFJzrOfLXfppJw2YlE5PSmdPxC5zeSkHdlYqZhiy NApw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=R1uwJvf1MRlSh0teK6HRUFQH6/+BBggMbJinTPI+T4A=; b=Pl/9F2RMqhrF5XlPBWMgE1WjbT3RfoQmAaCEwRyAbT9efkeEutdRDPXtWeXrIHtL9C /ObCExhVFruD5IPCjI/p5Ut6hrk0ykzhzIZzaZtlf2/SjxAF/q8+jqbb9dvpqr3xrp7I 0EA5Fsnj7H2X1W57f7GxHJhhLKCYpWp/aJOrd72tG3cqby94y0VCMLlTlM4/dMumEB8e r5gNl5jeGBmcYBUE7aN9s1rcB/YgfHja6knqY7i0XJedp11FS3LzdsPR7VqHVsHpKrYl RqHDRGkOEpUWxgzcidtNlRXNXooNe5QdArdPzmH4tRJ3HDnUODhAL5nIBtevpzbtIrja GhHw== X-Gm-Message-State: AJaThX6PVAUhDQSuWl7683KtLYf1o4wL6qH9wivy29y+oJKdz1mrmWLu RjG8ar8xH74OR/HZm2ec9fuHWg== X-Google-Smtp-Source: AGs4zMbMQ/bppos1FbDT8CyRzSs56lEIdBHL3xo1Hf6ZUmWFS84lo+Xq11XuMN7Mkb2DgVsOwFs8Pg== X-Received: by 10.99.127.67 with SMTP id p3mr1241657pgn.321.1510340655619; Fri, 10 Nov 2017 11:04:15 -0800 (PST) Received: from [172.16.148.71] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id x1sm18552880pfh.113.2017.11.10.11.04.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 11:04:14 -0800 (PST) Date: Sat, 11 Nov 2017 02:59:28 +0800 From: David Conrad To: Stephane Bortzmeyer , Paul Wouters Cc: tjw ietf , dnsop Message-ID: <809562de-bbde-4548-a701-fe7fbfef6b5e@Spark> In-Reply-To: References: <20171110121600.GA2749@laperouse.bortzmeyer.org> <20171110142508.GA4062@laperouse.bortzmeyer.org> X-Readdle-Message-ID: 809562de-bbde-4548-a701-fe7fbfef6b5e@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5a05f82a_625558ec_800" Archived-At: Subject: Re: [DNSOP] Agenda for IETF100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 19:04:19 -0000 --5a05f82a_625558ec_800 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Can confirm, as can anyone willing to go to an Adobe Connect archive. =46= or the curious: https://participate.icann.org/p6u03rimy92/=3Flauncher=3Dfalse&fcsContent=3D= true&pbMode=3Dnormal The discussion on Ethereum by Leonard Tan, an Ethereum developer, starts = at 00:31:00. Paul=E2=80=99s question is at 00:42:16. =46rom the transcrip= t: >> PAUL: =C2=A0PAUL, IET=46. =C2=A0LET'S SAY IET=46 GETS THE DOMAINS IET=46= IN THIS NAMING SYSTEM AND WE PAY OUR =46EES =46OR A COUPLE O=46 YEARS. =C2= =A0EVERYBODY USES THE SITE. =C2=A0AND THEN AT SOME POINT WE =46ORGET TO P= AY AND THE DOMAIN =46ALLS BACK INTO THE POOL AND SOMEBODY ELSE REGISTERS = IT AND WE DON'T KNOW WHERE THEY ARE OR WHO THEY ARE. =C2=A0NOW I GO TO A = COURT SYSTEM. =C2=A0I GET SOME LEGAL OPINION SAYING I OWN THIS TRADEMARK = AND NOW I WANT TO GET THIS DOMAIN BACK. =C2=A0IS THERE ANY WAY =46OR ME T= O GET THIS DOMAIN BACK=3F >>LEONARD TAN: =C2=A0SO RIGHT NOW, THE ENS INDUSTRY, YOU CAN CHANGE IT BE= CAUSE IT REQUIRES =46OUR OUT O=46 SEVEN PEOPLE. =C2=A0MOST O=46 THEM ARE = ETHEREUM DEVELOPERS. =C2=A0AND IT IS A CONSENSUS O=46 THEM TO MAKE ANY CH= ANGES. =C2=A0SO IT IS POSSIBLE, BUT IT IS GOING TO BE A VERY DI=46=46ICUL= T THING TO DO. Regards, -drc On Nov 10, 2017, 10:47 PM +0800, Paul Wouters , wrote: > The ENS developer said so in response to my question. > > Sent from my iPhone > > > On Nov 10, 2017, at 19:55, Stephane Bortzmeyer = wrote: > > > > On =46ri, Nov 10, 2017 at 05:58:13PM +0530, > > Paul Wouters wrote > > a message of 29 lines which said: > > > > > It takes 4 out of 7 geeks to bypass the blockchain in case of > > > emergency, court orders or kneecaps. > > > > > > According to the presentation held at ICANN60 > > > > Well, if someone at ICANN said so, someone is wrong (or, at the > > minimum, over-simplificator). > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > DNSOP mailing list > > DNSOP=40ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > DNSOP mailing list > DNSOP=40ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --5a05f82a_625558ec_800 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Can confirm, as can anyone willing to go to an Adobe Connect archive= . =46or the curious:


The discussion on Ethereum by Leonard Tan, an Ethereum developer, st= arts at 00:31:00. Paul=E2=80=99s question is at 00:42:16. =46rom the tran= script:

>> PAUL: &=23160;PAUL, IET=46. &=23160;LET'S SAY IET=46 GETS T= HE DOMAINS IET=46 IN THIS NAMING SYSTEM AND WE PAY OUR =46EES =46OR A COU= PLE O=46 YEARS. &=23160;EVERYBODY USES THE SITE. &=23160;AND THEN AT SOME= POINT WE =46ORGET TO PAY AND THE DOMAIN =46ALLS BACK INTO THE POOL AND S= OMEBODY ELSE REGISTERS IT AND WE DON'T KNOW WHERE THEY ARE OR WHO THEY AR= E. &=23160;NOW I GO TO A COURT SYSTEM. &=23160;I GET SOME LEGAL OPINION S= AYING I OWN THIS TRADEMARK AND NOW I WANT TO GET THIS DOMAIN BACK. &=2316= 0;IS THERE ANY WAY =46OR ME TO GET THIS DOMAIN BACK=3F
>>LEONARD TAN: &=23160;SO RIGHT NOW, THE ENS INDUSTRY, YOU CAN= CHANGE IT BECAUSE IT REQUIRES =46OUR OUT O=46 SEVEN PEOPLE. &=23160;MOST= O=46 THEM ARE ETHEREUM DEVELOPERS. &=23160;AND IT IS A CONSENSUS O=46 TH= EM TO MAKE ANY CHANGES. &=23160;SO IT IS POSSIBLE, BUT IT IS GOING TO BE = A VERY DI=46=46ICULT THING TO DO.

Regards,
-drc

On Nov 10, 2017, 10:47 PM +0800, Paul Wouters <paul=40nohats.ca>, w= rote:
The ENS developer said so in r= esponse to my question.

Sent from my iPhone

On Nov 10, 2017, at 19:55, Ste= phane Bortzmeyer <bortzmeyer=40nic.fr> wrote:

On =46ri, Nov 10, 2017 at 05:58:13PM +0530,
Paul Wouters <paul=40nohats.ca> wrote
a message of 29 lines which said:

It takes 4 out of 7 geeks to b= ypass the blockchain in case of
emergency, court orders or kneecaps.

According to the presentation held at ICANN60

Well, if someone at ICANN said so, someone is wrong (or, at the
minimum, over-simplificator).

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
DNSOP mailing list
DNSOP=40ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
DNSOP mailing list
DNSOP=40ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--5a05f82a_625558ec_800-- From nobody Fri Nov 10 21:09:58 2017 Return-Path: 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 4EF8712941D for ; Fri, 10 Nov 2017 21:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Wir-VGhYbKji for ; Fri, 10 Nov 2017 21:09:47 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7C2128B51 for ; Fri, 10 Nov 2017 21:09:47 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id m191so3988110itg.2 for ; Fri, 10 Nov 2017 21:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DbFV6WxMDGvs8VGffw5V1yll0o/4x4sQABt1G0MfYEY=; b=f54gPBjiDSELxu4XA6Tfg0wVj6BSHPnPegxRJ5sgTU8RyaqueW41pKQxLgL3Q41dvX bjzljNiNPQVuDvy3I/vOPSTag2a+VRucd81XhQ6TzCqSYsaGCCr43tipW9opNwDTbp4d MiuVIPxjQThWjVFmf7CD+tE8i9GzSEOGOkyqzh50+EP+yL+9cc+CBrJDK+jU/K76rSMs anbDT6I9BvKDIZYiKaiVICcXyvNhmG1a90ThOBo/MHZJnenlOzOj09zELWuAG7XRj7Yz eUNCiD753WkUtP62cFLHt7vKKodjIAqmX/wvX0DuP3NMqgRx19NCa5db5IwEsULMFtKN FYAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DbFV6WxMDGvs8VGffw5V1yll0o/4x4sQABt1G0MfYEY=; b=leQEN/tOE0SNlF9/x6EYdO9rUUXuO4tqq4SdK8ZeWt46ZU+C9veZwxm5h94cMcze39 bBWZgG6sFA/Tq1YSFPYJPL41/a9/z24IzbkipWHxV29DXYe+Az7ZlRMRvLuUvf0Czc3t 2ijO1ojnsTQclv+95SPRut+8+iCIoNvYiFd+fK+maOJ5iUmTGifWYoLs8F/DuQd+8yLZ jHAuKDikbEyFT3dlxnhrxLHQ5fFwbpnwPIEZmdbrFppD08ha/K6J3r2X45A8WpBFWd/M Fv57wVbcOiQslDiIX2rVJlvL5mS9f2+NhpOL1M2eGzHonAHInO/fnHEDdRfVxfMdd5jq DEDg== X-Gm-Message-State: AJaThX5OZxmoHKcHJGrUh0+pWr7BwwB/S68DG2yMibLo83TcB5lb+zbG TeVcYfmA8TPzThtJl2XrY7Ym33bde/3GvGCDUAM= X-Google-Smtp-Source: AGs4zMaLq9mBrWo4iDv00Mvp+HbqUXg3XiUahbruzIfYoCQAYySd1GpyM36/pqXpPV/BALVz1fvXevLH0MGWfdG2VKo= X-Received: by 10.36.181.82 with SMTP id j18mr3309896iti.18.1510376987072; Fri, 10 Nov 2017 21:09:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.7.42 with HTTP; Fri, 10 Nov 2017 21:09:46 -0800 (PST) In-Reply-To: <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> From: william manning Date: Fri, 10 Nov 2017 21:09:46 -0800 Message-ID: To: Matt Larson Cc: Paul Wouters , Ed Lewis , Moritz Muller , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , "dnsop@ietf.org" Content-Type: multipart/alternative; boundary="f403045d9d8cca9c63055dae0bfe" Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 05:09:50 -0000 --f403045d9d8cca9c63055dae0bfe Content-Type: text/plain; charset="UTF-8" in the last 20 years, there have been a few testbeds that have explored this space. irl.cs.ucla.edu/papers/imc71-osterweil.pdf https://eprint.iacr.org/2013/254.pdf that suggest Matt is spot on here. accepting any success is likely to present the fewest problems from a user perspective. /Wm On Thu, Nov 2, 2017 at 7:41 AM, Matt Larson wrote: > The root KSK rollover project has given me a real appreciation for the > brittleness of trust anchor configuration, even with RFC 5011. (Automated > update support should get better over time, especially after the first KSK > roll exposes problems, but right now it's pretty shaky, which is my > informed opinion based on observation from the operational trenches.) In > the real world, where trust anchors are going to go stale, an "Accept Any > Success" (in the language of Appendix C) trust anchor policy is the safest > operationally. > > I agree with Ed's observation that operators are, by and large, going to > use the defaults in whatever implementation they're running, so defaults > are important. > > Trust is always going to be a matter of local policy, so with DNSSEC > there's never going to be a consistent output given a consistent input. The > best we can do is give good guidance to implementors, ideally based on > operational experience, to inform their choices for the default settings > that operators will end up using. > > I think RFC 6840 gets it right: it acknowledges that trust anchor > preference is a matter of local policy, but recommends an operationally > safe default of "Accept Any Success". > > Why would one want a "Closest Encloser" trust anchor preference policy? > I've heard two reasons in this thread: > > 1. The untrusted parent scenario: I submit there's no practical > implication of distinguishing between the parent's control of the > delegation and its control of the DS: the child zone is completely at the > will of the parent zone, so if your parent has it in for you, you lose. > This scenario is not sufficient motivation, in my opinion, to suggest > "Closest Encloser" as a default policy. > > 2. In a split DNS context, reject answers that leak into the wrong view: I > think using DNSSEC as a backstop to enforce split DNS policy is a dubious > operational practice and likewise not sufficient motivation to suggest > "Closest Encloser" as a default policy. > > In my perfect world, implementations would offer a knob to set "Closest > Encloser" for consenting adults but default to "Accept Any Success". > > Matt > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --f403045d9d8cca9c63055dae0bfe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
in the last 20 years, there have been a few testbeds that = have explored this space.=C2=A0=C2=A0


that suggest Matt is spot on here.=C2=A0 =C2=A0accepting any success is l= ikely to present the fewest problems from a user perspective.
<= div><= br>
/Wm

On Thu, Nov 2, 2017 at 7:41 AM, Matt Larson <mat= t@kahlerlarson.org> wrote:
= The root KSK rollover project has given me a real appreciation for the brit= tleness of trust anchor configuration, even with RFC 5011. (Automated updat= e support should get better over time, especially after the first KSK roll = exposes problems, but right now it's pretty shaky, which is my informed= opinion based on observation from the operational trenches.) In the real w= orld, where trust anchors are going to go stale, an "Accept Any Succes= s" (in the language of Appendix C) trust anchor policy is the safest o= perationally.

I agree with Ed's observation that operators are, by and large, going t= o use the defaults in whatever implementation they're running, so defau= lts are important.

Trust is always going to be a matter of local policy, so with DNSSEC there&= #39;s never going to be a consistent output given a consistent input. The b= est we can do is give good guidance to implementors, ideally based on opera= tional experience, to inform their choices for the default settings that op= erators will end up using.

I think RFC 6840 gets it right: it acknowledges that trust anchor preferenc= e is a matter of local policy, but recommends an operationally safe default= of "Accept Any Success".

Why would one want a "Closest Encloser" trust anchor preference p= olicy? I've heard two reasons in this thread:

1. The untrusted parent scenario: I submit there's no practical implica= tion of distinguishing between the parent's control of the delegation a= nd its control of the DS: the child zone is completely at the will of the p= arent zone, so if your parent has it in for you, you lose. This scenario is= not sufficient motivation, in my opinion, to suggest "Closest Enclose= r" as a default policy.

2. In a split DNS context, reject answers that leak into the wrong view: I = think using DNSSEC as a backstop to enforce split DNS policy is a dubious o= perational practice and likewise not sufficient motivation to suggest "= ;Closest Encloser" as a default policy.

In my perfect world, implementations would offer a knob to set "Closes= t Encloser" for consenting adults but default to "Accept Any Succ= ess".

Matt

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--f403045d9d8cca9c63055dae0bfe-- From nobody Fri Nov 10 21:11:44 2017 Return-Path: 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 5DA1B1200C1 for ; Fri, 10 Nov 2017 21:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 D1jfvjJl2BzL for ; Fri, 10 Nov 2017 21:11:41 -0800 (PST) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99DE1126C23 for ; Fri, 10 Nov 2017 21:11:41 -0800 (PST) Received: by mail-io0-x241.google.com with SMTP id d66so15662888ioe.5 for ; Fri, 10 Nov 2017 21:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HTKRLhHFrRsniUqGzLVNjl7z0aPuRcEi9NnQ7ai9V2E=; b=U1386XhDcb/pq3vzZvq0IgnfmRY9iu1t7d91JbX3ZRVBrRB85m44Q/a2GQ60hub7GR NQ7OESzwRWTYWMxsnf7VwOwPzgwdP/9BydPx8DWc3aaoRla1beypdC7LMdMWsy6V9v5l s9XZDmAmYeGPkilvcG5Pu/95/sHx7UjE1ZdXvfxXMtU/N/Ue2fWn/VHjzpqA8zavTr9v JBR3IogvgVkqvJARz6bBZPRNGDdeDaVdVj1+foNLFQWoU0ir3OIDwop5OX098mZHeDyQ Y8iA3jn11tv5OFG8Jq+eedJK3Jmj7r9T/HcWuk9cHsvOV6MvRWH0sqPQSIWpkMx/7sty j38A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HTKRLhHFrRsniUqGzLVNjl7z0aPuRcEi9NnQ7ai9V2E=; b=RrOPT8V/B67tC2NOO/0nTuoDlzCSc7m60WvIDJ8lg2OSOPHF3gFleFPoNZSL5ObJye Dxy/Qfy0Ef6eZWMM6YKYgeJhTd4LetnyLcw2w1mfLv2/zKahwbJ3CHxqPDmsmPiJWphy QkTsAFnmoVTVTsh0Sah7mzcvaJE8GKWKQfEHnsYm72eZkvZqt/KqdnUBt/sN8yQwo4KK Osz74GogfC4lYHdT8LdXyvnzd950slr2qSOtkjMcb6dQbpiWI4VVZ71DuArSXTCcE3WA /2gKo2weNv+05+8ifd3/TlAXPdQVWaUMYCj5J52PbxMttLt9fmqPzlXACZDt8I+hfEeP DHxg== X-Gm-Message-State: AJaThX7VN0KF2/oyMgdUMOsVzdsIKHNjdNempAJTxKtQL1xXQPPA38s+ OkDowhnE65OcticlmaO0aRbdr3WwlforpXZrkHU= X-Google-Smtp-Source: AGs4zMa0L8fG8A+IVNN/gKy7WtSWjoTSMtZ1fxCauvIpPxom6cYjgOwUGLEzCkvNbZzgcp2W+NzPRfRSFSJls0lUhIo= X-Received: by 10.107.139.144 with SMTP id n138mr2931171iod.173.1510377100895; Fri, 10 Nov 2017 21:11:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.7.42 with HTTP; Fri, 10 Nov 2017 21:11:40 -0800 (PST) In-Reply-To: References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <4678D8A8-1AA0-4684-BFD1-40C969305C49@icann.org> <54030D6D-0B7D-4408-A50A-FDBD66A940B4@kahlerlarson.org> From: william manning Date: Fri, 10 Nov 2017 21:11:40 -0800 Message-ID: To: Bob Harold Cc: Matt Larson , Ed Lewis , Moritz Muller , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , Paul Wouters , "dnsop@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c058680936b89055dae12f3" Archived-At: Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 05:11:44 -0000 --94eb2c058680936b89055dae12f3 Content-Type: text/plain; charset="UTF-8" in reverse order of trustworthiness: the root a third party - e.g. DLV locally verified - e.g. my employer, ISP, someone I have a binding legal relationship with /Wm On Thu, Nov 2, 2017 at 8:04 AM, Bob Harold wrote: > > On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson > wrote: > >> The root KSK rollover project has given me a real appreciation for the >> brittleness of trust anchor configuration, even with RFC 5011. (Automated >> update support should get better over time, especially after the first KSK >> roll exposes problems, but right now it's pretty shaky, which is my >> informed opinion based on observation from the operational trenches.) In >> the real world, where trust anchors are going to go stale, an "Accept Any >> Success" (in the language of Appendix C) trust anchor policy is the safest >> operationally. >> >> I agree with Ed's observation that operators are, by and large, going to >> use the defaults in whatever implementation they're running, so defaults >> are important. >> >> Trust is always going to be a matter of local policy, so with DNSSEC >> there's never going to be a consistent output given a consistent input. The >> best we can do is give good guidance to implementors, ideally based on >> operational experience, to inform their choices for the default settings >> that operators will end up using. >> >> I think RFC 6840 gets it right: it acknowledges that trust anchor >> preference is a matter of local policy, but recommends an operationally >> safe default of "Accept Any Success". >> >> Why would one want a "Closest Encloser" trust anchor preference policy? >> I've heard two reasons in this thread: >> >> 1. The untrusted parent scenario: I submit there's no practical >> implication of distinguishing between the parent's control of the >> delegation and its control of the DS: the child zone is completely at the >> will of the parent zone, so if your parent has it in for you, you lose. >> This scenario is not sufficient motivation, in my opinion, to suggest >> "Closest Encloser" as a default policy. >> >> 2. In a split DNS context, reject answers that leak into the wrong view: >> I think using DNSSEC as a backstop to enforce split DNS policy is a dubious >> operational practice and likewise not sufficient motivation to suggest >> "Closest Encloser" as a default policy. >> >> In my perfect world, implementations would offer a knob to set "Closest >> Encloser" for consenting adults but default to "Accept Any Success". >> >> Matt >> > > I generally agree with you, but wonder if there is a performance penalty > to searching every possible path before failing. Is that a reasonable > concern? > > How many paths are there? I can think of: > 1. To the root > 2. To a local trust anchor > 3. To a DLV provider (gone as of Sept 30?) > > If local trust anchors are checked before the root, and they are under > operator control, then maybe "Closest Encloser" is a reasonable default. I > don't know where to fit DLV into that plan. > > Also, if an operator does not configure DLV or local trust anchors, then > is root the only path? So "Closest Encloser" and "Accept Any Success" are > the same? > Or am I not understanding something (no experience with this yet)? > > -- > Bob Harold > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --94eb2c058680936b89055dae12f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
in reverse order of trustworthiness:

th= e root
a third party - e.g. DLV
locally verified - e.g.= my employer, ISP, someone I have a binding legal relationship with

/Wm

On Thu, Nov 2, 2017 at 8:04 AM, Bob Harold <rharolde@umi= ch.edu> wrote:

On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson <matt@kahlerlarson.o= rg> wrote:
The root KSK rollover project has given me a real appreciation for the b= rittleness of trust anchor configuration, even with RFC 5011. (Automated up= date support should get better over time, especially after the first KSK ro= ll exposes problems, but right now it's pretty shaky, which is my infor= med opinion based on observation from the operational trenches.) In the rea= l world, where trust anchors are going to go stale, an "Accept Any Suc= cess" (in the language of Appendix C) trust anchor policy is the safes= t operationally.

I agree with Ed's observation that operators are, by and large, going t= o use the defaults in whatever implementation they're running, so defau= lts are important.

Trust is always going to be a matter of local policy, so with DNSSEC there&= #39;s never going to be a consistent output given a consistent input. The b= est we can do is give good guidance to implementors, ideally based on opera= tional experience, to inform their choices for the default settings that op= erators will end up using.

I think RFC 6840 gets it right: it acknowledges that trust anchor preferenc= e is a matter of local policy, but recommends an operationally safe default= of "Accept Any Success".

Why would one want a "Closest Encloser" trust anchor preference p= olicy? I've heard two reasons in this thread:

1. The untrusted parent scenario: I submit there's no practical implica= tion of distinguishing between the parent's control of the delegation a= nd its control of the DS: the child zone is completely at the will of the p= arent zone, so if your parent has it in for you, you lose. This scenario is= not sufficient motivation, in my opinion, to suggest "Closest Enclose= r" as a default policy.

2. In a split DNS context, reject answers that leak into the wrong view: I = think using DNSSEC as a backstop to enforce split DNS policy is a dubious o= perational practice and likewise not sufficient motivation to suggest "= ;Closest Encloser" as a default policy.

In my perfect world, implementations would offer a knob to set "Closes= t Encloser" for consenting adults but default to "Accept Any Succ= ess".
=
Matt

I generally agree with you, but wonder = if there is a performance penalty to searching every possible path before f= ailing.=C2=A0 Is that a reasonable concern?

How many paths are there?=C2=A0 I can= think of:
1. To the root
2. To a local trust anchor
3. To a DLV provider (gone as of Sept 30?)

If local trust anchors are checked be= fore the root, and they are under operator control, then maybe "Closes= t Encloser" is a reasonable default.=C2=A0 I don't know where to f= it DLV into that plan.

Also, if an operator does not configure DLV or local trust= anchors, then is root the only path?=C2=A0 So "Closest Encloser"= and=C2=A0"Accept Any Success" are the same?
Or am I not understanding something (no experience with this ye= t)?

--=C2=A0
Bob Harold


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--94eb2c058680936b89055dae12f3-- From nobody Fri Nov 10 22:27:05 2017 Return-Path: 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 A3F62129463 for ; Fri, 10 Nov 2017 22:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 JzYwWRDO8CVQ for ; Fri, 10 Nov 2017 22:27:01 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A034B129439 for ; Fri, 10 Nov 2017 22:27:00 -0800 (PST) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id vAB65eKe082628; Sat, 11 Nov 2017 07:05:40 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201711110605.vAB65eKe082628@givry.fdupont.fr> From: Francis Dupont To: Mukund Sivaraman cc: dnsop@ietf.org In-reply-to: Your message of Sat, 04 Nov 2017 12:00:18 +0530. <20171104063018.GA25223@jurassic.lan.banu.com> Date: Sat, 11 Nov 2017 07:05:40 +0100 Archived-At: Subject: Re: [DNSOP] Review of draft-dupont-dnsop-rfc2845bis-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 06:27:04 -0000 In your previous mail you wrote: > After a reading, I felt that this document needs the following: > > * Editing for clarity of sentences => I agree until the text comes from original RFCs (i.e. you are 17 year too late) or can only be clarified at the margin. > * Addressing insufficient protocol specification => these should be fixed if they have an impact on security (a priori we already fixed them but perhaps we missed a few?) > Review follows that suggests changes. Some are nitpicking, but changes > are needed to be pedantically correct. > > > This protocol allows for transaction level authentication using > > shared secrets and one way hashing. It can be used to authenticate > > I'd start as "This document describes a protocol for transaction level > authentication...". => 17y > > shared secrets and one way hashing. It can be used to authenticate > > dynamic updates as coming from an approved client, or to authenticate > > responses as coming from an approved recursive name server. > > s/recursive name server/name server/ => 17y but removing extra/superfluous word is good: adopted > > No provision has been made here for distributing the shared secrets: > > it is expected that a network administrator will statically configure > > name servers and clients using some out of band mechanism such as > > sneaker-net until a secure automated mechanism for key distribution > > is available. > > This paragraph may be misconstrued to imply that such an automated > mechanism is forthcoming. I'd leave it at just this: > > "This document does not describe how to distribute the shared secrets. > It is expected that a network administrator will statically configure > name servers and clients using some out of band mechanism." => adopted > > This document includes revised original TSIG specifications > > (RFC2845) and the extension for HMAC-SHA (RFC4635). > > s/and the extension/and its extension/ => adopted > > 1. Introduction > > > > In 2017, security problems in two nameservers strictly following > > [RFC2845] and [RFC4635] (i.e., TSIG and HMAC-SHA extension) > > s/TSIG and HMAC-SHA extension/TSIG and its HMAC-SHA extension/ => adopted > > This document specifies use of a message authentication code (MAC), > > either HMAC-MD5 or HMAC-SHA (keyed hash functions), to provide an > > efficient means of point-to-point authentication and integrity > > checking for transactions. > > I'd avoid listing the HMACs here and instead refer to the section below > that lists them. => I disagree: it is not a good idea to have forward references in the introduction. > > The second area where the secret key based MACs specified in this > > document can be used is to authenticate DNS update requests as well > > as transaction responses, providing a lightweight alternative to the > > protocol described by [RFC3007]. > > It isn't clear how this is different from "first area". DNS updates are > also transactions. => 17y > > A further use of this mechanism is to protect zone transfers. In > > this case the data covered would be the whole zone transfer including > > any glue records sent. The protocol described by DNSSEC does not > > protect glue records and unsigned records unless SIG(0) (transaction > > signature) is used. > > I'd avoid including this whole sentence about DNSSEC. => 17y > > The authentication mechanism proposed in this document uses shared > > secret keys to establish a trust relationship between two entities. > > I'd s/shared secret keys/pre-shared secret keys/ => I don't think pre-shared is really clearer. > > Such keys must be protected in a fashion similar to private keys, > > s/fashion/manner/ => 17y > > Note that use of TSIG presumes prior agreement between the resolver > > and server involved as to the algorithm and key to be used. > > Again this document seems to tie itself to the resolver case only. > > s/between the resolver and server/between the client and server/ => I disagree and BTW 17y too. > > Since the publication of first version of this document ([RFC2845]) a > > mechanism based on asymmetric signatures using the SIG RR was > > specified (SIG(0) [RFC2931]) when this document uses symmetric > > authentication codes calculated by HMAC [RFC2104] using strong hash > > functions. > > s/when this document/whereas this document/ +> adopted (I assume your English is better than mine :-) > > 4.1. TSIG RR Type > > > > To provide secret key authentication, we use a new RR type whose > > mnemonic is TSIG and whose type code is 250. TSIG is a meta-RR and > > MUST NOT be cached. TSIG RRs are used for authentication between DNS > > entities that have established a shared secret key. TSIG RRs are > > dynamically computed to cover a particular DNS transaction and are > > not DNS RRs in the usual sense. > > The last sentence doesn't appear to be particularly accurate. > TSIG RRs are dynamically computed to cover specific DNS *messages* or > used possibly sparingly over a message sequence such as with zone > transfers (in this latter case, more than a single TSIG RR may be used). > > I'd rewrite it as: "TSIG RRs are dynamically computed to cover DNS > transactions and are not DNS RRs in the usual sense." => it was the original text so a priori clear enough... I request a second opinion. > > CLASS ANY > > > > TTL 0 > > Please include text that TTL MUST be set to 0, class MUST be set to ANY. => 17y > > The Algorithm Name field identifies the TSIG algorithm name in the > > domain name syntax. > > Please clarify that this field needs to be in RFC 1035 DNS name wire > format without name compression. Also for clarity I'd first explicitly > specify that unlike with other algorithm fields (represented by > integers) in DNS, the TSIG algorithm identifier is represented as a DNS > name. => 17y > > 4.3.1.8. The Other Data Field > > > > The Other Data field is empty unless Error == BADTIME. > > What is in the Other Data field if Error is equal to BADTIME? A person > reading this document sequentially will not understand this. Please > introduce what "Other Data" is useful for. => 17y > Is it an error to use Other Data when Error != BADTIME? => no and this has not changed since original RFC 2845. > > > > 4.4. Example > > > > NAME HOST.EXAMPLE. > > Even this example does not follow the "should" recommendation under > section 4.3 above. => I agree but again you are 17 year too late... > > Algorithm Name SAMPLE-ALG.EXAMPLE. > > Please use a valid algorithm in example. => 17y > > Once the outgoing message has been constructed, the keyed message > > digest operation can be performed. > > I'd replace this with "Once the outgoing message has been constructed, > the HMAC computation can be performed." => 17y but it is a simplification: adopted > > The resulting message digest will > > I'd use s/message digest/MAC/ for clarity (even though the HMAC > operation outputs a message digest of some data). => adopted with the previous one. > > then be stored in a TSIG which is appended to the additional data > > section (the ARCOUNT is incremented to reflect this). > > When is it incremented? Before MAC computation or after? Please specify. => then means after > > If an incoming message contains a TSIG record, it MUST be the last > > record in the additional section. Multiple TSIG records are not > > allowed. If a TSIG record is present in any other position, the > > packet is dropped and a response with RCODE 1 (FORMERR) MUST be > > returned. Upon receipt of a message with a correctly placed TSIG RR, > > the TSIG RR is copied to a safe location, removed from the DNS > > Message, and decremented out of the DNS message header's ARCOUNT. At > > this point the keyed message digest operation is performed: until > > Here again, I'd replace keyed message digest with MAC computation for > consistency. => adopted (for consistency) > > this operation concludes that the signature is valid, the signature > > MUST be considered to be invalid. If the algorithm name or key name > > is unknown to the recipient, or if the message digests do not match, > > the whole DNS message MUST be discarded. > > Perhaps s/discarded/rejected/ is a better wording here. => 17y > > If the message is a query, a response with RCODE 9 (NOTAUTH) MUST > > be sent back to the originator with TSIG ERROR 17 (BADKEY) or TSIG > > ERROR 16 (BADSIG). If no key is available to sign this message it > > MUST be sent unsigned (MAC size == 0 and empty MAC). A message to > > the system operations log SHOULD be generated, to warn the > > operations staff of a possible security incident in progress. Care > > should be taken to ensure that logging of this type of event does > > not open the system to a denial of service attack. > > This passage assumes that something is wrong with the message. It should > be separated into a different paragraph corresponding to what to do when > something is wrong with the message. Surely we must not send NOTAUTH for > messages that validate? The use of a single paragraph in 5.2 is > confusing. => even the original RFC has a single paragraph I agree so adopted (I cut it after the (new) ..considered to be invalid.) > > 5.4. TSIG Variables and Coverage > > > > When generating or verifying the contents of a TSIG record, the > > following data are digested, in network byte order or wire format, as > > appropriate: > > s/following data are digested/following data are passed as input to MAC > computation/ => adopted (for consistency) > > The RR RDLEN and RDATA MAC Length are not included in the hash since > > they are not guaranteed to be knowable before the MAC is generated. > > s/hash/input to MAC computation/ => adopted (for consistency) > > For each label type, there must be a defined "Canonical wire format" > > that specifies how to express a label in an unambiguous way. For > > label type 00, this is defined in [RFC4034], for label type 01, this > > is defined in [RFC6891]. The use of label types other than 00 and 01 > > is not defined for this specification. > > What? This paragraph does not fit into this document. It seems to appear > in RFC 2845 too. What is this in relevance to? => it is where is the no compression for instance. So it is relevant! > > 5.4.3. Request MAC > > > > When generating the MAC to be included in a response, the validated > > request MAC MUST be included in the digest. If the request MAC > > s/digest/MAC computation/ => adopted (by consistency) > Please be careful when you use "digest" like this as it could be > misconstrued to mean "prepended/appended to the digest output". => 17y! > > 5.5. Padding > > > > Digested components are fed into the hashing function as a continuous > > octet stream with no interfield padding. > > Digested components? Are components digested before feeding them into > the MAC function? => yes, HMAC has two arguments and the second (i.ee. not the key) is "digested". So if the term is not the best it is NOT incorrect. BTW the goal is not to rewrite the whole TSIG specification, just to fix it. So I added an explaination at the first occurrence of "digested components". > > 6.1. TSIG generation on requests > > > > Client performs the message digest operation and appends a TSIG > > record to the additional data section and transmits the request to > > the server. The client MUST store the message digest from the > > s/message digest/MAC/ => adopted > > This allows the client to rapidly detect when the session has been > > altered; at which point it can close the connection and retry. If a > > client TSIG verification fails, the client MUST close the connection. > > If the client does not receive TSIG records frequently enough (as > > specified above) it SHOULD assume the connection has been hijacked > > and it SHOULD close the connection. The client SHOULD treat this the > > same way as they would any other interrupted transfer (although the > > exact behavior is not specified). > > When reading RFC 2845, I felt this section was underspecified and this > document seems to replicate it. => of course it replicates it (:-)! > 1. s/envelope/message/ for consistency. It is confusing to have such > synonyms without any explanation. => IMHO envelope is more accurate than message. Any second opinion? > 2. The first paragraph is not properly written. A "DNS TCP session" can > be a single DNS connection. It can also accept mutiple pipelined > messages (separate transactions) which are not continuations. > > AIUI, the sparse signing of intermediate messages in a TSIG TCP > continuation is only for the zone transfer case, and not for pipelined > TCP messages (separate transactions). Please correct me if I'm wrong, > and if I'm not wrong, then please rewrite this text specifically for > TSIG for zone transfers. => I agree about only one thing: the text applies only to zone transfer. How to fix it? > 3. "Prior Digest (running)" is inadequately specified. A new reader of > this document will not understand what it is. > > Also, s/The first envelope is processed as a standard answer, and > subsequent messages have the following digest components/The first > message is processed normally generating a TSIG RR, and the TSIG RR in > subsequent messages is generated with the MAC computation over the > following components in sequence/ => 17y (note I replaced Digest by MAC) > 4. I'd remove the text "It is expensive to include it on every > envelopes". > > As an example, BIND and Knot currently includes TSIG RR in every DNS > message in a zone transfer, whereas NSD currently includes it > sparsely. I don't think any users notice it as particularly > expensive. It is after all just hashing below. > > Whether something is expensive in space or time also doesn't stand the > test of time, so I'd not include a statement that states definitely that > it is expensive. => it is a matter of taste so I apply the 17y argument here. > > 6.5.2. Specifying Truncation > > Shouldn't this section be moved to appear after the time checks below > (6.5.4) in logical order? => it is not so logical because it is about how MAC is computed and checked so should be before MAC and time checks. > > 1. If "MAC size" field is greater than HMAC output length: > > > > This case MUST NOT be generated and, if received, MUST cause the > > packet to be dropped and RCODE 1 (FORMERR) to be returned. > > s/packet/DNS message/ => changed all "packet"s to "DNS message"s > > for authentication. The request MAC used when calculating the > > TSIG MAC for a reply is the truncated request MAC. > > How about the "Prior Digest (running)" (section 6.4) ? Please specify. => I don't understand your concern. > > SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. > > I don't know if it is outside the scope of this revision to alter this > table but I see two things: => it is outside the scope. > 1. SHA-512 is a faster hash than SHA-256, and so it would be better to > make support for SHA-512 and its truncated SHA-384 mandatory. => note it is true only on 64 bit CPUs. > 2. It makes little sense to support SHA-384 and SHA-224 when we already > support MAC truncation in the protocol itself. => SHA-224 is not the same than SHA-256/224 and some implementations do not support HMAC truncation. So it is clearly a 17y case. > 3. HMAC-MD5 is still a secure HMAC currently, but it is discouraged for > new applications because it is built on top of MD5 which is barred for > new applications (RFC 6151). > > I'm not sure if this revision constitutes a new application (as it is > still the backwards compatible protocol), but would it be allowed to > specify the use of MD5 on the path to RFC? => interesting question... > > 8. TSIG Truncation Policy > > > > Use of TSIG is by mutual agreement between a resolver and server. > > Please remove this limitation of TSIG being between resolver and server > everywhere in the document. => I don't understand: in DNS transactions the initiator is named resolver and the responder the server. Can you exhibit another case? Or do you simply want to use more general client and server? > > A name server usually runs privileged, which means its configuration > > data need not be visible to all users of the host. For this reason, > > a host that implements transaction-based authentication should > > probably be configured with a "stub resolver" and a local caching and > > forwarding name server. This presents a special problem for > > [RFC2136] which otherwise depends on clients to communicate only with > > a zone's authoritative name servers. > > This seems use-case specific. => 17y > > SHOULD be at least as long as the keyed message digest, i.e., 16 > > bytes for HMAC-MD5 or 20 bytes for HMAC-SHA1. > > I'd remove this example from here and add a field for minimum secret > length to the table of supported algorithms above. => I am against to remove it but I'd like the idea to add it in the table. BTW the SHOULD is a change from original RFCs. > > 11. Security Considerations > > > > The approach specified here is computationally much less expensive > > than the signatures specified in DNSSEC. As long as the shared > > secret key is not compromised, strong authentication is provided for > > the last hop from a local name server to the user resolver. > > This is again use-case specific. I'd replace this with "is provided > between client and server." => another case of client/server. > > Secret keys should be changed periodically. > > How periodically? I suggest referring to RFC 2104 section 3 rather than > recommending best practice here. => RFC 2104 is referenced for truncation so we can also reference it for secret key management in general, can't we? > > A fudge value that is too large may leave the server open to replay > > attacks. A fudge value that is too small may cause failures if > > machines are not time synchronized or there are unexpected network > > delays. The recommended value in most situation is 300 seconds. > > I have felt that 300s (5 minutes) is too long to make up for clock skew > and message transmission delays. It becomes possible for a > man-in-the-middle to replay traffic (such as DNS UPDATEs) during this > opportunity window. => we all know this replay protection is very weak. If you have a note to add here please propose its text. > It appears that the fudge time is not configurable at least in BIND > (without patching the source code). => does this change really something (:-)? > > Significant progress has been made recently in cryptanalysis of hash > > functions of the types used here, all of which ultimately derive from > > the design of MD4. > > After SHA-3 (though it is not yet in the table of TSIG algorithms as > HMAC currently), saying that all hash functions derive from the design > of MD4 would be incorrect, so I'd remove the last part of the sentence > above for future proofing. => there is a reference to SHA-3 (which is not in the table because it is out of scope and BTW HMAC-SHA3 is broken in OpenSSL so nobody wants to add it...). And the text does not say "all hash functions" but "hash functions of the types used here" so is IMHO correct. > > While the results so far should not effect HMAC, > > the stronger SHA-1 and SHA-256 algorithms are being made mandatory > > due to caution. Note that today SHA-3 [FIPS202] is available as an > > alternative to SHA-2 using a very different design. > > Available as TSIG algorithm? Unless it is added to the table above, I > suggest removing this reference. => I simply disagree. > > 11.1. Issue fixed in this document > > > > To bind an answer with its corresponding request the MAC of the > > answer is computed using the MAC request. Unfortunately original > > specifications [RFC2845] failed to clearly require the MAC request to > > be successfully validated. > > I suggest rewriting this: > > When signing a DNS reply message using TSIG, its MAC computation uses > the request message's MAC as an input to cryptographically relate the > reply to the request. Unfortunately, the original TSIG specification > [RFC2845] failed to clearly require the request MAC to be successfully > validated before using it. This created a security vulnerability [add > reference to Synacktiv paper]. => I don't have the reference to the paper (and I asked so I shan't add one). Adopted without the last sentence. > > This document proposes the principle that the MAC must be considered > > to be invalid until it was validated. This leads to the requirement > > that only a validated request MAC is included in a signed answer. Or > > with other words when the request MAC was not validated the answer > > must be unsigned with a BADKEY or BADSIG TSIG error. > > "This document makes it a requirement that the request MAC must be > considered to be invalid until it passes validation." => no, the principle with its consequence is better. Now what about replacing "it is validated" by "it passes validation"? > > 12.2. Informative References > > Please cite Synacktiv paper on vulnerability in RFC 2845 here. => I asked Synacktiv and put the proposed text from the answer in the I-D. So no reference to the paper. Thanks Francis.Dupont@fdupont.fr PS: don't include the whole I-D. And as you have access to the XML look at the comments in it. From nobody Fri Nov 10 23:11:12 2017 Return-Path: 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 0817C129411 for ; Fri, 10 Nov 2017 23:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Fi3DMpEGKYDS for ; Fri, 10 Nov 2017 23:11:09 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A676612948F for ; Fri, 10 Nov 2017 23:11:08 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id r68so6353549wmr.1 for ; Fri, 10 Nov 2017 23:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q3YQQ+UQEIyXbvbHCkLM/EVUorwEJB+CETGmvCD3COI=; b=Lh54nlm/Iclv+tU8c1Yx7Epl4+zN9ss1j7ll0VlkhgPwvJh1g+XnMK3P75z0TgLaPD uQomOwWMivv3BDLASk9VR4z/3tWPFkCJ9+5602JzMFx78Z26U2kt+XF7dpAX+ND2N06C 5VVNfuzKxth6LUOEFCewebTxnNGQ5cfCRRdMKRBhpW9pykkZpCX7iqTfmra/o+rjhRID Iv9jDfPUAXxT9n9huTcQNH9iNwbRPEGtEGhH7ukscpN1EDlxyHvnhWes6xCSU5E+dUzz dSrseTj7rTiSrjn0BsmHfNq8KhrQduI7aNHUu4JoAcgUaZhzUcg0SeGXysGGucQrzmlh ilWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q3YQQ+UQEIyXbvbHCkLM/EVUorwEJB+CETGmvCD3COI=; b=JBvsstdNHPbZGRc6yenLf/iYOgXcyTdlnojFETThi+MunzEAs1KoVZUTbYvi1Uy9Qo SZHCInvM88rp284hf4eGUJ6GOIGyUs+zrrxqHiBubk3uAuedci+K6TUSdlPplVahaKGc wrysER9ToovB0KPQTUI1Tbg7AnkzvGkGWVlZdIu9nE6rqX2UNcupkdcIT3/KL0cB5Ndq QdJfIgv1Jgd4Lsgwi9e0nv5TYyCewM5fWETOgCnAMCkuJed5xrhThL6FZPSjKo8hRYgd QrQBWxOS3NGP3lKBvcMm5utEeYghNo8a9N5NrZrBAh9L2Z6Hk8ZaXT0VnIfI+a94kaon v8PA== X-Gm-Message-State: AJaThX6joM6o5dLlr/k3tmpAKJ+JoFNF2v6hX+p01XgQB9Px0L1h0URX ziHbUEcY9E0w3+Wj6zSWhZlfmvEbR7DtL4q1WqI= X-Google-Smtp-Source: AGs4zMYZS0cP2IGEeucZPlz7XKUm141R2w7gMQhJ8b1EO3NI+UgO10ptob90yfQM9wErEG4+8je+cUBnG9KvrFpDNNQ= X-Received: by 10.28.73.196 with SMTP id w187mr1899128wma.17.1510384267255; Fri, 10 Nov 2017 23:11:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.196.169 with HTTP; Fri, 10 Nov 2017 23:11:06 -0800 (PST) In-Reply-To: <809562de-bbde-4548-a701-fe7fbfef6b5e@Spark> References: <20171110121600.GA2749@laperouse.bortzmeyer.org> <20171110142508.GA4062@laperouse.bortzmeyer.org> <809562de-bbde-4548-a701-fe7fbfef6b5e@Spark> From: tjw ietf Date: Sat, 11 Nov 2017 15:11:06 +0800 Message-ID: To: David Conrad Cc: Stephane Bortzmeyer , Paul Wouters , dnsop Content-Type: multipart/alternative; boundary="001a114b3092b9655a055dafbd6e" Archived-At: Subject: Re: [DNSOP] Agenda for IETF100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 07:11:11 -0000 --001a114b3092b9655a055dafbd6e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Great question Paul and thanks for getting that on record. On Sat, Nov 11, 2017 at 2:59 AM, David Conrad wrote: > Can confirm, as can anyone willing to go to an Adobe Connect archive. For > the curious: > > https://participate.icann.org/p6u03rimy92/?launcher=3Dfalse& > fcsContent=3Dtrue&pbMode=3Dnormal > > The discussion on Ethereum by Leonard Tan, an Ethereum developer, starts > at 00:31:00. Paul=E2=80=99s question is at 00:42:16. From the transcript: > > >> PAUL: PAUL, IETF. LET'S SAY IETF GETS THE DOMAINS IETF IN THIS NAMIN= G > SYSTEM AND WE PAY OUR FEES FOR A COUPLE OF YEARS. EVERYBODY USES THE > SITE. AND THEN AT SOME POINT WE FORGET TO PAY AND THE DOMAIN FALLS BACK > INTO THE POOL AND SOMEBODY ELSE REGISTERS IT AND WE DON'T KNOW WHERE THEY > ARE OR WHO THEY ARE. NOW I GO TO A COURT SYSTEM. I GET SOME LEGAL OPINI= ON > SAYING I OWN THIS TRADEMARK AND NOW I WANT TO GET THIS DOMAIN BACK. IS > THERE ANY WAY FOR ME TO GET THIS DOMAIN BACK? > >>LEONARD TAN: SO RIGHT NOW, THE ENS INDUSTRY, YOU CAN CHANGE IT BECAUSE > IT REQUIRES FOUR OUT OF SEVEN PEOPLE. MOST OF THEM ARE ETHEREUM > DEVELOPERS. AND IT IS A CONSENSUS OF THEM TO MAKE ANY CHANGES. SO IT IS > POSSIBLE, BUT IT IS GOING TO BE A VERY DIFFICULT THING TO DO. > > Regards, > -drc > > On Nov 10, 2017, 10:47 PM +0800, Paul Wouters , wrote: > > The ENS developer said so in response to my question. > > Sent from my iPhone > > On Nov 10, 2017, at 19:55, Stephane Bortzmeyer wrote: > > On Fri, Nov 10, 2017 at 05:58:13PM +0530, > Paul Wouters wrote > a message of 29 lines which said: > > It takes 4 out of 7 geeks to bypass the blockchain in case of > emergency, court orders or kneecaps. > > According to the presentation held at ICANN60 > > > Well, if someone at ICANN said so, someone is wrong (or, at the > minimum, over-simplificator). > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --001a114b3092b9655a055dafbd6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great question Paul and thanks for getting that on record.= =C2=A0

On Sa= t, Nov 11, 2017 at 2:59 AM, David Conrad <drc@virtualized.org> wrote:
Can confirm, as can anyone willing to go to an Adobe Connect archive. = For the curious:


The discussion on Ethereum by Leonard Tan, an Ethereum developer, star= ts at 00:31:00. Paul=E2=80=99s question is at 00:42:16. From the transcript= :

>> PAUL: =C2=A0PAUL, IETF.=C2=A0 LET'S SAY IETF GETS THE DOM= AINS IETF IN THIS NAMING SYSTEM AND WE PAY OUR FEES FOR A COUPLE OF YEARS.= =C2=A0 EVERYBODY USES THE SITE.=C2=A0 AND THEN AT SOME POINT WE FORGET TO P= AY AND THE DOMAIN FALLS BACK INTO THE POOL AND SOMEBODY ELSE REGISTERS IT A= ND WE DON'T KNOW WHERE THEY ARE OR WHO THEY ARE.=C2=A0 NOW I GO TO A CO= URT SYSTEM.=C2=A0 I GET SOME LEGAL OPINION SAYING I OWN THIS TRADEMARK AND = NOW I WANT TO GET THIS DOMAIN BACK.=C2=A0 IS THERE ANY WAY FOR ME TO GET TH= IS DOMAIN BACK?
>>LEONARD TAN: =C2=A0SO RIGHT NOW, THE ENS INDUSTRY, YOU CAN CHA= NGE IT BECAUSE IT REQUIRES FOUR OUT OF SEVEN PEOPLE.=C2=A0 MOST OF THEM ARE= ETHEREUM DEVELOPERS.=C2=A0 AND IT IS A CONSENSUS OF THEM TO MAKE ANY CHANG= ES.=C2=A0 SO IT IS POSSIBLE, BUT IT IS GOING TO BE A VERY DIFFICULT THING T= O DO.

Regards,
-drc

On Nov 10, 2017, 10:47 PM +0800, Paul Wouters <paul@nohats.ca>, wrote:
The ENS developer said so in response to my questi= on.

Sent from my iPhone

On Nov 10, 2017, at 19:55, Stephane Bortzmeyer <= ;bortzmeyer@nic.fr> wrote:

On Fri, Nov 10, 2017 at 05:58:13PM +0530,
Paul Wouters <paul@n= ohats.ca> wrote
a message of 29 lines which said:

It takes 4 out of 7 geeks to bypass the blockchain= in case of
emergency, court orders or kneecaps.

According to the presentation held at ICANN60

Well, if someone at ICANN said so, someone is wrong (or, at the
minimum, over-simplificator).

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dnsop

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dnsop

--001a114b3092b9655a055dafbd6e-- From nobody Sat Nov 11 17:29:40 2017 Return-Path: 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 0D74C1271FD for ; Sat, 11 Nov 2017 17:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 fZZvxGKkcoEo for ; Sat, 11 Nov 2017 17:29:36 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 0A3A81252BA for ; Sat, 11 Nov 2017 17:29:36 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id B37A331D12; Sun, 12 Nov 2017 02:29:33 +0100 (CET) Received: by godin (Postfix, from userid 1000) id DD82BEC0B85; Sun, 12 Nov 2017 02:28:35 +0100 (CET) Date: Sun, 12 Nov 2017 09:28:35 +0800 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20171112012835.GA16257@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [DNSOP] About draft-ietf-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 01:29:39 -0000 [About -00] Excellent idea, I strongly support the project. I intend to use it to register 451 for DNS censorship , following RFC 7725. (I'm serious.) > This document discusses extended *errors*, but it has been suggested > that this could be used to also annotate *non- error* messages. The > authors do not think that this is a good idea, but could be > persuaded otherwise. Why is it a bad idea? I would appreciate some elaboration. > It can be included in any error response (SERVFAIL, NXDOMAIN, > REFUSED, etc) It can be argued that NODATA (pseudo rcode, I know) is an "error" as well as NXDOMAIN... > Usually attached to SERVFAIL messages. This raises an interesting point. Should extended error codes be limited to a specific rcode? For instance "Extended error code 100 MUST be used only with SERVFAIL"? From nobody Sat Nov 11 17:31:51 2017 Return-Path: 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 0BAA7127419 for ; Sat, 11 Nov 2017 17:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Xl_jDdoYWZKn for ; Sat, 11 Nov 2017 17:31:48 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27F0126E7A for ; Sat, 11 Nov 2017 17:31:48 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id t10so9129006pgo.3 for ; Sat, 11 Nov 2017 17:31:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=GorUkt6j+qGAKoyrbsaJ24EhHa5Qx2cEEf44pwofOLg=; b=eCxF6lW9aWWGt8HyE0+MPxH8erJWyZfeZOLx6M7bGQyRbyIMvyUhEJauJSSSuS26Pr iusTsK2Q2u0EhK1YAvlfTY+98y1yEBO7zGgDqimyMaBscCd2FkHa2Q9Fgg55KC4oMlz5 gIWBW1rKPG7YbQVfPm4i8MYUX82gQwrQiPHoGEoXEsAfqnlMtCz4GnI0KJN9YDsKZMZZ sRvM9o6Z0nJQWPQWz51uFemdOkACYn5AlTbCCYRZ4FNehBZkStV1EmMayLQ843e7tnv3 1baOZ6uSjPgXody0iy33M2hoZmo9DqBJku7Xv+HAamChn4OzXRvtQVZBbks4nrXn73rZ PSSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=GorUkt6j+qGAKoyrbsaJ24EhHa5Qx2cEEf44pwofOLg=; b=E7jMKLwqKtJl/wN34yvwkL8gHEYT3L1USdViPm1XHH+ldZcV7Dk733OVXABr9Gj7bs TEw5r8L+wkuaKl6GrHzbsADJWbFXVTjr/59FI3b8iub3017u9jOWg2tu0KnA74ahLo08 x6A01bRZ+PDoLZ9UyTVU4kKqoOzdsZ+Kj/TaXi5iCdjWP17VSoi4ps5BC2TEJfSZk9ep 5qIH+P2dLcuAVP4BqfB537ke3pxpiTJkC7dQEY0HrP1L/xWX92VQAZI349bWC81wC6+F i6rtoti3LFrXY32vxRShaweFDzpOGAF0TvZdLwPPcfvIHA6IriaflS9PKM6fEBWvH1kl uwqg== X-Gm-Message-State: AJaThX7YxHcl0BBARnkb+AktsyXKfmaCDgGucFu3RXt5iwAk3/UToMk5 KwEw1acVIfrKwn1MHZQQBhkB7rtq X-Google-Smtp-Source: AGs4zMY9MEWu0xSRr8NCuCVBoNLEW3EWtp+arMmgdWGpxAcbjOyAR7gbUFGXAkDr8wsDgwuIz9KfWw== X-Received: by 10.98.32.212 with SMTP id m81mr5252588pfj.227.1510450307976; Sat, 11 Nov 2017 17:31:47 -0800 (PST) Received: from Melindas-MacBook-Pro.local ([202.55.67.146]) by smtp.gmail.com with ESMTPSA id 68sm27139944pfx.105.2017.11.11.17.31.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Nov 2017 17:31:47 -0800 (PST) To: dnsop@ietf.org References: <20171110121600.GA2749@laperouse.bortzmeyer.org> From: Melinda Shore Message-ID: Date: Sun, 12 Nov 2017 09:31:47 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171110121600.GA2749@laperouse.bortzmeyer.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="O9BiOVEWDCgVTl1N33LG4k08l4Pd3So6g" Archived-At: Subject: Re: [DNSOP] Agenda for IETF100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 01:31:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --O9BiOVEWDCgVTl1N33LG4k08l4Pd3So6g Content-Type: multipart/mixed; boundary="QdJKrOSgjlpVqiDbqkkTCQg7liMiRjEET"; protected-headers="v1" From: Melinda Shore To: dnsop@ietf.org Message-ID: Subject: Re: [DNSOP] Agenda for IETF100 References: <20171110121600.GA2749@laperouse.bortzmeyer.org> In-Reply-To: <20171110121600.GA2749@laperouse.bortzmeyer.org> --QdJKrOSgjlpVqiDbqkkTCQg7liMiRjEET Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/10/17 8:16 PM, Stephane Bortzmeyer wrote: > Any news on that? The monday session collides with DIN which is really > unfortunate for me because they talk a lot about name resolution > (Namecoin, Ethereum Name Service). I may face a hard choice. We've had to cancel the dinrg session on Monday, although we may have a small side meeting in that time slot, or another time. Melinda --QdJKrOSgjlpVqiDbqkkTCQg7liMiRjEET-- --O9BiOVEWDCgVTl1N33LG4k08l4Pd3So6g Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOwSIcj4Q6xsnay8FuIZGkzoegS4FAloHpIMACgkQuIZGkzoe gS640A//ZnOTr0esggrhvaXelzrrdMneb6PdUo3nambBRiE2VOKX+QPjTjPE0pKV rT+5tq/unPSLM6w5/fHvIqdmvv4vdavYC54FzK0ky7FUwEBD/XuxFv1+XNk/2gLY WQvYj7a2Hp4ze9AiDeJPpxraJ5FhV8O6rZYJzEQ05oQfdzMcFKebC2RjZ6y5L4mY 1w1mwXdRbeyBfV4+D0yRZlLYzOlPLdavYIVhPdZnApz84a8e7GSuUehJj0ap0BLG ZveiY+/kEOGJ7WQtSJWTEJSPDbSabiiQ7ObGsMXVT/+n9UOUeCmFhvAZ74CIMMkM ZfXzIVOeKXjeGpyx5vS8xbJ28ZtOEEa55tgwjWiX3+sSeekYpRCeqHMwseae1j1Q 7mVhWOPIQ+nEugcJkyTdPFRWKbo59tbXoQugV8X5LfbbItBUavbohFSj/CK8evlo ap9DB84sKC/00lGCcjKZHw44X3QeGih/sa6YHdyDt7iXin+z2Ms9Etyl4eMog5To VVS/j6Og1eV6hNWNbUnqTNApzzeKJLZjZaS4aHai1q9eRXpOLZ6kNzJOuSsd9sPl 83R3zaMg9P8ZsZJdCrdbGNzhxB1Ig+JSkgPnhvKgBo8UJSXa+aFm9bp1y3gN18tY nC62qX7RPLSAvBh6nmHUuKY9nzkbPrVmmVI6onOYXCr3szNev7k= =d0M0 -----END PGP SIGNATURE----- --O9BiOVEWDCgVTl1N33LG4k08l4Pd3So6g-- From nobody Sat Nov 11 18:51:10 2017 Return-Path: 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 08088124BFA for ; Sat, 11 Nov 2017 18:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 6LR9q1DsbIq6 for ; Sat, 11 Nov 2017 18:51:08 -0800 (PST) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 E5669127B52 for ; Sat, 11 Nov 2017 18:51:07 -0800 (PST) Received: from dhcp-9fc3.meeting.ietf.org (unknown [10.32.60.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp01.icann.org (Postfix) with ESMTPS id 22DCFE01A5; Sun, 12 Nov 2017 02:50:55 +0000 (UTC) Date: Sun, 12 Nov 2017 10:50:51 +0800 From: Kim Davies To: Stephane Bortzmeyer Cc: Matt Larson , dnsop@ietf.org Message-ID: <20171112025047.GA69215@dhcp-9fc3.meeting.ietf.org> References: <20171110121241.GA2621@laperouse.bortzmeyer.org> <0C063F76-BFBD-4E54-AFBE-51B00678020B@kahlerlarson.org> <20171110142818.GB4062@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171110142818.GB4062@laperouse.bortzmeyer.org> User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: Subject: Re: [DNSOP] [Ext] Re: draft-wkumari-dnsop-internal and DNAME X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 02:51:09 -0000 Quoting Stephane Bortzmeyer on Friday November 10, 2017: > > > I'll note that from a technical/mechanical perspective, ICANN's and > > Verisign's root zone management systems already know how to deal > > with delegations. A DNAME in the root would require an unknown level > > of development by both parties. > > I've never read the source code of the root zone management system, > but it seems surprising that it could be a non-trivial level of > development. I assume this system is complicated because it is highly > sensitive, and because it needs to incorporate a lot of defenses > against both mistakes and attacks, but they should be more or less the > same for DNAME and NS/A/AAAA, no? ... > Wild guess (and I pay beers if I'm wrong): the technical work will > take much less time than the process one. I suspect that would be a distinction without a difference. Any process changes need to be mapped into technical changes to the systems, as the whole business process from beginning to end is processed in the systems. Allowing DNAME records in the root zone is adding a new concept into root zone management that hasn't been catered to before. Just one of the many things that would need to be looked at is how to transmit DNAME provisioning requests via EPP. I don't know if there is even an EPP mapping for this. We haven't studied what would be involved, but I feel confident in predicting the whole exercise would be non-trivial. kim From nobody Sat Nov 11 18:53:17 2017 Return-Path: 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 0F50E128D16 for ; Sat, 11 Nov 2017 18:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MBnt1NuHuN5u for ; Sat, 11 Nov 2017 18:53:14 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DAAD128C83 for ; Sat, 11 Nov 2017 18:53:13 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id f20so17288732ioj.9 for ; Sat, 11 Nov 2017 18:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W+d/tl+xTH8XRcIl9axa325vS3VCphJf0sAUtLj68T0=; b=TR6HY1TN0b6Iumx8St325le5LISNm6MzOpl+Y8m5uWkXLgz4uMRWldZIekGqUhjXDU 8Fv2s0oZoZDVJmA/Pb69dXCil0JRuhksYsvbpZG2gcjeRsMSSDLIGIl1c+ngSOlcn2BN z/jeUJIYfcUOXtSQ1ibJSg5ymYwk3Pqjg1yYE8Cc9iRrzLhgWWHhi4R9oxSd4w9WMOKA paV4sfH+/1Kz6dlsCute4/vOiIWo2UE5a0dYEg16nJDKHkyBvpc3mXqmAqeGZ44NzRkw vnENptJfgLFmXA5ThGa7PUEO25NFNkArOaC9ABZRHDuEM84iRfqRheNzdow1pf8xgHP9 Ccmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W+d/tl+xTH8XRcIl9axa325vS3VCphJf0sAUtLj68T0=; b=WMIICee5B0qPBDwTWNxUkW1sFQjWI1HDhHFExviNMPeZcpHeXCwj0Ftn85wTW7gOpX NT5g6szD9PJ3lbhtxK220Ok+FehrfBrAMFf24iPJnguRtK+Pg33+srdQeucRHeALRxlW Cox4pMNzjdyJVxn7xsUPaQuCmLJFLABIIYUAcLqSxDL00+Zts/psl+Y4CK/VQ0kjJor2 doK57LDOyjhyrTj1N4VryC5ElRiSAXx1FoqpNByiKr4GLQPhNAzg+ua0iG5hT8x3JF2b tJgrrVl9bh62giE8594a7gCRO5oNpNiEmAtmbXVXXaUHW88KVZln9sC+HdG8jBhUEWx8 U0jA== X-Gm-Message-State: AJaThX4bt4v6zMBBnCsmerSOQfRmee1gL2bfz8b7WXNzgqPh62gbYfib vlMJaHa+pWadmtbHJ6+nKX6uxlytYq/hTyvmS78= X-Google-Smtp-Source: AGs4zMaxoXqMJS7xTlaebK4wYYK7NjZSoREJ0i7TyUKQPB1TmFA5rYFsQ/YyPwF5ZvezWGMR5yoHpWbY9DbU5Q9CPn0= X-Received: by 10.107.140.145 with SMTP id o139mr5690248iod.81.1510455192488; Sat, 11 Nov 2017 18:53:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.7.42 with HTTP; Sat, 11 Nov 2017 18:53:12 -0800 (PST) In-Reply-To: References: <20171110121600.GA2749@laperouse.bortzmeyer.org> From: william manning Date: Sat, 11 Nov 2017 18:53:12 -0800 Message-ID: To: Melinda Shore Cc: "dnsop@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05a544328df7055dc041f1" Archived-At: Subject: Re: [DNSOP] Agenda for IETF100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 02:53:16 -0000 --94eb2c05a544328df7055dc041f1 Content-Type: text/plain; charset="UTF-8" Please keep us posted on the logistics On Sunday, November 12, 2017, Melinda Shore wrote: > On 11/10/17 8:16 PM, Stephane Bortzmeyer wrote: > > Any news on that? The monday session collides with DIN which is really > > unfortunate for me because they talk a lot about name resolution > > (Namecoin, Ethereum Name Service). I may face a hard choice. > > We've had to cancel the dinrg session on Monday, although we > may have a small side meeting in that time slot, or another > time. > > Melinda > > --94eb2c05a544328df7055dc041f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please keep us posted on the logistics

On Sunday, November 12, 2017,= Melinda Shore <melinda.shore= @gmail.com> wrote:
On 11/10/17 8:1= 6 PM, Stephane Bortzmeyer wrote:
> Any news on that? The monday session collides with DIN which is really=
> unfortunate for me because they talk a lot about name resolution
> (Namecoin, Ethereum Name Service). I may face a hard choice.

We've had to cancel the dinrg session on Monday, although we
may have a small side meeting in that time slot, or another
time.

Melinda

--94eb2c05a544328df7055dc041f1-- From nobody Sat Nov 11 19:27:48 2017 Return-Path: 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 2ABD81292C5 for ; Sat, 11 Nov 2017 19:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 k4cy4A0mgB4Y for ; Sat, 11 Nov 2017 19:27:45 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22375129453 for ; Sat, 11 Nov 2017 19:26:49 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id e143so14894062lfg.12 for ; Sat, 11 Nov 2017 19:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=DwKmSQtDT4bFn3VtsDohcL4TLKtOSpbskpjowDSmTkU=; b=Un4Wlg9Npvn/nn0u8px+xIN8XEuwfwJqNPFWrz7ev/A5xJ5Qdv23PcwLV7/Z6+rC9T cvYAWY9NAPn/5Tk4R+FJMMaZgsneB5LKlulGJPxu88I+grVVeGDir9QszlLGdll9+H2j 3cg/NEKg/Plo/pZQGT+eB7i8PK7Yh0wIfrPfY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc; bh=DwKmSQtDT4bFn3VtsDohcL4TLKtOSpbskpjowDSmTkU=; b=AoBgwkCnh0QzuL9KqlZY5Y7SE8PwNCpDiU3BPlgEYJtSY/a45LkrPG9hAmevC/c/mU 71TvPYt2wGPrggswhstWEWRMXzeAT3mgwu5QrPct61eE5Dd8B0CHUkHSOPEYcCoCTd59 e+gAkfILSz+II5fC7V5R66xDvMVIV7dJQJUV4ow57UqK9ee9bvY9uAuyOk9HSGyRWf/w juclCEHVDWrw194xBqDN9yUBeE16fPIRY+MRa4YZ4bdn6zhqdT6O6tMV5D5EIgQn8cCX gsaF2XyeME4Z1PBTtSW2SIWCS/od4j2c2uViJnCIkr2ylB9P0d3xYJ08aymhxsd5e4c5 V/yw== X-Gm-Message-State: AJaThX7VCDoCC2j4tJGu1ngBf2ajb2RbojZuMPnIFBwledhUW+8EJefr dYEPZw9GWkhmZ+2Brj/8Fxazr6jeHYzwv/vjZq5Wrw== X-Google-Smtp-Source: AGs4zMatHIsFr2mrpX7T5U5qWMEr/G90XNIaWAYKLs/1Hiw5fTTZbhrH4+0BOKro51ZrBLNpBEMNWQ1bQ/SvCINBO00= X-Received: by 10.25.15.161 with SMTP id 33mr1944550lfp.57.1510457207299; Sat, 11 Nov 2017 19:26:47 -0800 (PST) From: Joe Abley Mime-Version: 1.0 (1.0) References: <20171110121241.GA2621@laperouse.bortzmeyer.org> <0C063F76-BFBD-4E54-AFBE-51B00678020B@kahlerlarson.org> <20171110142818.GB4062@laperouse.bortzmeyer.org> <20171112025047.GA69215@dhcp-9fc3.meeting.ietf.org> In-Reply-To: <20171112025047.GA69215@dhcp-9fc3.meeting.ietf.org> Date: Sun, 12 Nov 2017 11:26:42 +0800 Message-ID: <-2659975464145644217@unknownmsgid> To: Kim Davies Cc: Stephane Bortzmeyer , Matt Larson , "dnsop@ietf.org" Content-Type: multipart/alternative; boundary="001a113f22004a39dd055dc0b930" Archived-At: Subject: Re: [DNSOP] [Ext] Re: draft-wkumari-dnsop-internal and DNAME X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 03:27:47 -0000 --001a113f22004a39dd055dc0b930 Content-Type: text/plain; charset="UTF-8" On Nov 12, 2017, at 10:51, Kim Davies wrote: We haven't studied what would be involved, but I feel confident in predicting the whole exercise would be non-trivial. It seems to me that you could implement this using lawyers as easily as you could using developers; it is after all arguably a static change in procedure that doesn't need to be especially repeatable. If the root zone maintainer is contracted to include a record, surely the record will be included. However, I think the more general idea that queries for internal names should be leaked towards unknown AS112 operators is problematic. As an end-user I would prefer my leaked queries to be jealously hoarded by one of twelve root server operators than an inbound number of anonymous and potentially ephemeral AS112 operators. The potential for complete data collection at the root servers goes down as resolvers implement aggressive NSEC caching. In the case of a delegation or redirection, that potential is reduced since the non-existence of individual names under internal is then the thing that is cached, not the non-existence of the right-most label in the namespace. Joe --001a113f22004a39dd055dc0b930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Nov 12, 2017, at 10:= 51, Kim Davies <kim.davies@icann= .org> wrote:

We haven't studied what wo= uld be involved, but I feel confident in
predicting the whole exercise would be non-trivial.

It seems to me that you could implement t= his using lawyers as easily as you could using developers; it is after all = arguably a static change in procedure that doesn't need to be especiall= y repeatable. If the root zone maintainer is contracted to include a record= , surely the record will be included.=C2=A0

Howeve= r, I think the more general idea that queries for internal names should be = leaked towards unknown AS112 operators is problematic. As an end-user I wou= ld prefer my leaked queries to be jealously hoarded by one of twelve root s= erver operators than an inbound number of anonymous and potentially ephemer= al AS112 operators.

The potential for complete dat= a collection at the root servers goes down as resolvers implement aggressiv= e NSEC caching. In the case of a delegation or redirection, that potential = is reduced since the non-existence of individual names under internal is th= en the thing that is cached, not the non-existence of the right-most label = in the namespace.


Joe
<= /html> --001a113f22004a39dd055dc0b930-- From nobody Sat Nov 11 23:55:04 2017 Return-Path: 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 4E09A1293D9 for ; Sat, 11 Nov 2017 23:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=eeZ83tFF; dkim=pass (1024-bit key) header.d=yitter.info header.b=Lq5mFUMd 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 Yaqn5l0rDFlC for ; Sat, 11 Nov 2017 23:54:52 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CFC129412 for ; Sat, 11 Nov 2017 23:54:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 997F4BF56C for ; Sun, 12 Nov 2017 07:54:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510473291; bh=nzEXPO/KEhG3yeevwaCjc/okDkKedn5lS1lWHwIkd2o=; h=Date:From:To:Subject:From; b=eeZ83tFFzDaDLQS5pgnye0DQZds7dgrUIY11qILuLzxjPmlKSIMWhMR+EKNShf4jH PzvPJBPtJJxDYwJJ2i9iFynD9uA/rbXiH9I8S70nKJoI3Jza5hkPqGS/TQ3RUULiuh 8SIqtEETodQK9cqnw/A2HQhfAZLiFjMD5mAxDPSQ= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfmoRYDtQGzZ for ; Sun, 12 Nov 2017 07:54:50 +0000 (UTC) Date: Sun, 12 Nov 2017 02:54:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510473290; bh=nzEXPO/KEhG3yeevwaCjc/okDkKedn5lS1lWHwIkd2o=; h=Date:From:To:Subject:From; b=Lq5mFUMdYCvvOI+BxOI8iDuwDVP2LBX55aqcru3SaWACGBjqEAESvzGFmnFXRLnIl MRuGAAsJpwnzke2f6/Ccppal1+o0CyrI0axiCc7wMZeSgqm+3pn/36CT66513Pv9ZN vF61ENenFp2egCLjPOLUjhNpk1ZtWlt/qQTZOaSg= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: Subject: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 07:55:02 -0000 Dear colleagues, In github tracker issue #35 (https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/35), we have an item about the way Referral is defined in RFC 7719. The issue mostly comes from the (as usual incisive) observations of Tony Finch. I think he's right. I think a change is in order, but I'm not fully convinced of the following text, so that's why I'm putting it here for discussion. My co-editors do not deserve the brickbats, so fling them at me. There are questions at the end of this proposed text, because there are two issues about which I am very much in doubt and I'm too lazy to convince myself of the right answer when I can just ask everyone. ---%<---cut here--- Referral: A type of response in which a server, signalling that it is not authoritative for an answer, provides the querying resolver with an alternative place to send its query. All referral responses follow the same form. The response has the AA bit cleared. It has an empty Answer section. It has an Authority section containing an RRset in which the owner name is the referred-to zone, the class is the queried class, the type is NS, and the RDATA holds the nameservers for the referred-to owner name as known by the responding server. The response might also have an Additonal section containing glue records. There are two types of referral response. The first is a delegation referral (sometimes described as "delegation response"), where the server is authoritative for some portion of the QNAME. The Authority section RRset's RDATA contains the name servers specified at the zone cut. In normal DNS operation, this kind of response is required in order to find names beneath a delegation. The second is a non-delegation referral (sometimes described as "referral response", as distinct from the delegation response above), where the server is not authoritative for any portion of the QNAME. In this case, the referred-to zone in the Authority section is usually[1] the root zone (.). In normal DNS operation, this kind of response is not strictly speaking required to work, and in practice some authoritative server operators will not return referral responses beyond those required for delegation. ---cut here--->%--- First, on [1], it seems to me that in principle it ought to be possible for this sort of referral to refer to something other than . , but I can't come up with an example where it happens or really ought to happen. Is this case actually necessarily a referral to the root? (In that case, also, the name of this type should be "root referral", I guess?) Second, is there any circumstance in which glue in a non-delegation referral ought not to be treated as possible poison, and just thrown away? It seems to me that a root referral ought automatically to cause the resolver to go to the results of a priming query and follow that chain. No? Also, maybe that's not a terminological issue, and so it ought to be left out of the document anyway. In any case, I seek guidance from the WG. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sun Nov 12 00:52:10 2017 Return-Path: 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 A1DEC120721 for ; Sun, 12 Nov 2017 00:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cipejoaUVoyc for ; Sun, 12 Nov 2017 00:52:07 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A71F1204DA for ; Sun, 12 Nov 2017 00:52:07 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id u40so11899105wrf.10 for ; Sun, 12 Nov 2017 00:52:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=57QQ51ZPsrQP29Bab/97b72fcrK2yIXbqbGgx326RI0=; b=Txti/Fm72vxo57bzDao7ert5kTXAI7Zd9oEVk5dKqPc+1aWHGr3VzcE7ANSfEy2F2D Skl9e3qoqKNN63943D2kOaRc0w5KGqdOV2lAJ3U29C3G8jGm1W7/b6AQJXOji+v1kQa0 eqtEMhSmSAUplvTsFzFm/oSP5gEwbliytAOxW9Kb/UF9HKkWaLvBrJ1dsM94PVI2IwzH XybRKJB7+04pcjOie0xdCFe57nMvINPSOr7dGKVeO+RdYAGUzJnuL1mgn+VyVNFVKXaX INdXamKwzy8DKCEOGqWoc37VZYMtUkFrOpmNtC67WTbeHnmkmuODDjcceJkZkO0SHxBc FunQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=57QQ51ZPsrQP29Bab/97b72fcrK2yIXbqbGgx326RI0=; b=pPO4wIDSvDHmH2zqSuwL+cXIousPi/bWZsfyVEGh9vufKG8Y4b3ULMxjxfyVknkQnc vPKrVtj/UvR+s5Q6GyEy34Ds66rSbVPRRRAK6LUz/B/UZQLHJ/Xq/hxbp6ShTnSIj6JN Ld/tuIoM2stup7frBH9OECYQYWd88rfWpcytSW+OGUgzkoM0J7FbXFSBiFfeLSajvNfM NZATuDEFxvYTGseA6NY95Eo1N3xjnmr9K1gl0+AAyliLCpNQZsZmATu5m/FfBkw+KOVP x0QL0QhX262awGcQSfMvtpUQBwbJIODsyGhcnehpK8oNZDVwjyc/aKYZ5X7Mnaiy4lc5 A51g== X-Gm-Message-State: AJaThX5BXGmdVRk0iRXU1+oKO9dfGawWBV6YYSp2zNa/p6Z9KjSZ1Jhy HR870CQK3A5CWAVBSClB51peJiEPeNRvPsSoqbg= X-Google-Smtp-Source: AGs4zMapicp0Bcd3WoYZLOlR+5BDyPia2BZCHqpYXyKdpxhmo0qwU+dYKIIInZCLsTQEGEh2jMcNZjb19sYzbXEUL48= X-Received: by 10.223.153.234 with SMTP id y97mr4268790wrb.165.1510476725340; Sun, 12 Nov 2017 00:52:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.196.169 with HTTP; Sun, 12 Nov 2017 00:52:04 -0800 (PST) From: tjw ietf Date: Sun, 12 Nov 2017 16:52:04 +0800 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="f403045f4d1aa7d059055dc54416" Archived-At: Subject: [DNSOP] Jabber Scribes and Minute takers for DNSOP on Monday X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 08:52:09 -0000 --f403045f4d1aa7d059055dc54416 Content-Type: text/plain; charset="UTF-8" Hi We're sending out the note requesting jabber scribes and minute takers for DNSOP. Also, there are a few laggards who need to send slides in. You know whom you are. See you bright and early Monday Morning! thanks, tim/suzanne --f403045f4d1aa7d059055dc54416 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi

We're sending out= the note requesting jabber scribes and minute takers for DNSOP. =C2=A0

Also, there are a few laggards who need to send slide= s in.=C2=A0 You know whom you are.=C2=A0

See you b= right and early Monday Morning!

thanks,=C2=A0
tim/suzanne
--f403045f4d1aa7d059055dc54416-- From nobody Sun Nov 12 04:11:01 2017 Return-Path: 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 997FA12941D for ; Sun, 12 Nov 2017 04:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Ergs-b83mjNW for ; Sun, 12 Nov 2017 04:10:58 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 7DE991292D3 for ; Sun, 12 Nov 2017 04:10:58 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 281B631D12; Sun, 12 Nov 2017 13:10:57 +0100 (CET) Received: by godin (Postfix, from userid 1000) id AEE99EC0B85; Sun, 12 Nov 2017 13:05:44 +0100 (CET) Date: Sun, 12 Nov 2017 20:05:44 +0800 From: Stephane Bortzmeyer To: Kim Davies Cc: Stephane Bortzmeyer , Matt Larson , dnsop@ietf.org Message-ID: <20171112120544.GA30240@laperouse.bortzmeyer.org> References: <20171110121241.GA2621@laperouse.bortzmeyer.org> <0C063F76-BFBD-4E54-AFBE-51B00678020B@kahlerlarson.org> <20171110142818.GB4062@laperouse.bortzmeyer.org> <20171112025047.GA69215@dhcp-9fc3.meeting.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171112025047.GA69215@dhcp-9fc3.meeting.ietf.org> X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] draft-wkumari-dnsop-internal and DNAME X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 12:10:59 -0000 On Sun, Nov 12, 2017 at 10:50:51AM +0800, Kim Davies wrote a message of 32 lines which said: > Just one of the many things that would need to be looked at is how > to transmit DNAME provisioning requests via EPP. I don't know if > there is even an EPP mapping for this. Interesting remark. I indeed did not find one. It should probably be a small extension of RFC 5731: C: C: example.com C: 2 C: empty.as112.arpa C: jd1234 C: sh8013 C: sh8013 C: C: 2fooBAR C: C: I'll ask regext tomorrow about it :-) > We haven't studied what would be involved, but I feel confident in > predicting the whole exercise would be non-trivial. But there is no choice. If we decide to delegate .internal to AS112 (*if*: see Joe Abley's message), we cannot use NS records because the AS112 servers won't recognize the new TLD, and there is no way to change them all these servers (RFC 7535, section 1). From nobody Sun Nov 12 05:19:08 2017 Return-Path: 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 9453D129438 for ; Sun, 12 Nov 2017 05:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 lMD1YTRP06_3 for ; Sun, 12 Nov 2017 05:19:05 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 EE0A71292AE for ; Sun, 12 Nov 2017 05:19:04 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 8089D31D05; Sun, 12 Nov 2017 14:19:03 +0100 (CET) Received: by godin (Postfix, from userid 1000) id D516BEC0B85; Sun, 12 Nov 2017 14:18:31 +0100 (CET) Date: Sun, 12 Nov 2017 21:18:31 +0800 From: Stephane Bortzmeyer To: Andrew Sullivan Cc: dnsop@ietf.org Message-ID: <20171112131831.GA32208@laperouse.bortzmeyer.org> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 13:19:06 -0000 On Sun, Nov 12, 2017 at 02:54:46AM -0500, Andrew Sullivan wrote a message of 74 lines which said: > The second is a non-delegation referral (sometimes described as > "referral response", as distinct from the delegation response > above), where the server is not authoritative for any portion of the > QNAME. In this case, the referred-to zone in the Authority section > is usually[1] the root zone (.). This is an upward referral and I tought it was frowned upon since the ISPrime attack (MUST NOT? SHOULD NOT?) From nobody Sun Nov 12 06:37:27 2017 Return-Path: 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 DBD26129447 for ; Sun, 12 Nov 2017 06:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 3wwi_n13jyu4 for ; Sun, 12 Nov 2017 06:37:24 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420251200F1 for ; Sun, 12 Nov 2017 06:37:24 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id f134so7336742lfg.8 for ; Sun, 12 Nov 2017 06:37:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=HPtUOEsTa+DgZw/+V3QRYr4tLdOhFwq1G/sz8wTaRL0=; b=Wk8srPfBVxSMoFDxg94pvlnAFQI996NlZP0bwGO9IMKuqikdDJvKtBqJL80KIwxaOR E2ICkv4cbmutyQKRp5PqpWhh/kCqaW19CeDnbtA69BHZQP0ZW8rEn76Dekc+aIP9S2c1 GkOjuOZF64jKUkb8biv9wnV4nWb5X1GMrjCE8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc; bh=HPtUOEsTa+DgZw/+V3QRYr4tLdOhFwq1G/sz8wTaRL0=; b=dn/OEQ2hYINonmKbtNPd8zeDXtCf2fZMKuvZTpzfcqT7kv/fcXH27vGb8tI+j90qE3 lcN9xVLapXeyXcyNdE7wUrhV+shCSZ28Fk1RB3R8lIz137Un1T5q+YZdytVfUEjaGFk6 8b9UW1irXaVcE4ZMZ0H1cmRPbhju9Rgj0dQqIs0fm7GO/TW9fF19HdVXWZhvyJlk1h8h 21X4xpY85YeOALUnF/Rm733/GxjswBQhY7zu2M9jI0J1P+FVCjK84RvH9Ag8ifxx2iKB s5Q20kBLecmlNSXtzZYIbYFx6acxgqyjYBm78O6ILUMoBEiZd7ooiP63JAsxUktYpQ3p ad3Q== X-Gm-Message-State: AJaThX6SPt1GiS2oJzT0VmKLOzQL3hZwiMz474NOSy3df31hbPcpAXbO p2nBOLRRl/5FHqI7yMZ8OG9VlPrtZ1IJTmPcyrYYGA== X-Google-Smtp-Source: AGs4zMaDYcFlSLvgCvM2XWha8QMtMuPvGe0Bme0SkHTWXVRqmYNqd4LAUsVvdaU3VkcUwTviw5PPQ2lPezBR1ezHS8o= X-Received: by 10.25.22.24 with SMTP id m24mr712339lfi.185.1510497441343; Sun, 12 Nov 2017 06:37:21 -0800 (PST) From: Joe Abley Mime-Version: 1.0 (1.0) References: <20171110121241.GA2621@laperouse.bortzmeyer.org> <0C063F76-BFBD-4E54-AFBE-51B00678020B@kahlerlarson.org> <20171110142818.GB4062@laperouse.bortzmeyer.org> <20171112025047.GA69215@dhcp-9fc3.meeting.ietf.org> <-2659975464145644217@unknownmsgid> In-Reply-To: <-2659975464145644217@unknownmsgid> Date: Sun, 12 Nov 2017 22:37:19 +0800 Message-ID: <6798813822774553543@unknownmsgid> To: Kim Davies Cc: Stephane Bortzmeyer , Matt Larson , "dnsop@ietf.org" Content-Type: multipart/alternative; boundary="001a11407b5e6cfb07055dca17d5" Archived-At: Subject: Re: [DNSOP] [Ext] Re: draft-wkumari-dnsop-internal and DNAME X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 14:37:26 -0000 --001a11407b5e6cfb07055dca17d5 Content-Type: text/plain; charset="UTF-8" An unbounded number of AS112 operators, not an inbound number. I apologise to all present for sending mail to dnsop from a phone without taking more time to check for autocorrect lunacy. On Nov 12, 2017, at 11:26, Joe Abley wrote: On Nov 12, 2017, at 10:51, Kim Davies wrote: We haven't studied what would be involved, but I feel confident in predicting the whole exercise would be non-trivial. It seems to me that you could implement this using lawyers as easily as you could using developers; it is after all arguably a static change in procedure that doesn't need to be especially repeatable. If the root zone maintainer is contracted to include a record, surely the record will be included. However, I think the more general idea that queries for internal names should be leaked towards unknown AS112 operators is problematic. As an end-user I would prefer my leaked queries to be jealously hoarded by one of twelve root server operators than an inbound number of anonymous and potentially ephemeral AS112 operators. The potential for complete data collection at the root servers goes down as resolvers implement aggressive NSEC caching. In the case of a delegation or redirection, that potential is reduced since the non-existence of individual names under internal is then the thing that is cached, not the non-existence of the right-most label in the namespace. Joe --001a11407b5e6cfb07055dca17d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
An unbounded number of = AS112 operators, not an inbound number.

I apologis= e to all present for sending mail to dnsop from a phone without taking more= time to check for autocorrect lunacy.=C2=A0

On Nov 12, 2017,= at 11:26, Joe Abley <jabley@hopco= unt.ca> wrote:

=
On Nov 12, 2017, at 10:51, Kim Davies <kim.davies@icann.org> wrote:

We= haven't studied what would be involved, but I feel confident in
<= blockquote type=3D"cite">
predicting the whole exercise would be = non-trivial.

It seems to m= e that you could implement this using lawyers as easily as you could using = developers; it is after all arguably a static change in procedure that does= n't need to be especially repeatable. If the root zone maintainer is co= ntracted to include a record, surely the record will be included.=C2=A0

However, I think the more general idea that queries f= or internal names should be leaked towards unknown AS112 operators is probl= ematic. As an end-user I would prefer my leaked queries to be jealously hoa= rded by one of twelve root server operators than an inbound number of anony= mous and potentially ephemeral AS112 operators.

Th= e potential for complete data collection at the root servers goes down as r= esolvers implement aggressive NSEC caching. In the case of a delegation or = redirection, that potential is reduced since the non-existence of individua= l names under internal is then the thing that is cached, not the non-existe= nce of the right-most label in the namespace.


=
Joe
--001a11407b5e6cfb07055dca17d5-- From nobody Sun Nov 12 09:20:41 2017 Return-Path: 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 77C251243FE for ; Sun, 12 Nov 2017 09:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 60oPQxev74XG for ; Sun, 12 Nov 2017 09:20:38 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A37412008A for ; Sun, 12 Nov 2017 09:20:38 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id E757B61FA2; Sun, 12 Nov 2017 17:20:37 +0000 (UTC) Message-ID: <5A0882E5.1080500@redbarn.org> Date: Sun, 12 Nov 2017 09:20:37 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Stephane Bortzmeyer CC: Andrew Sullivan , dnsop@ietf.org References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> In-Reply-To: <20171112131831.GA32208@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 17:20:39 -0000 Stephane Bortzmeyer wrote: > On Sun, Nov 12, 2017 at 02:54:46AM -0500, > Andrew Sullivan wrote > a message of 74 lines which said: > >> The second is a non-delegation referral (sometimes described as >> "referral response", as distinct from the delegation response >> above), where the server is not authoritative for any portion of the >> QNAME. In this case, the referred-to zone in the Authority section >> is usually[1] the root zone (.). > > This is an upward referral and I tought it was frowned upon since the > ISPrime attack (MUST NOT? SHOULD NOT?) it is frowned upon, but the strongest we can do is SHOULD NOT, since current implementations do it, and other current implementations must expect it. -- P Vixie From nobody Sun Nov 12 16:12:09 2017 Return-Path: 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 56D251205F0 for ; Sun, 12 Nov 2017 16:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 C5bVGpYwFEuX for ; Sun, 12 Nov 2017 16:12:07 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A121200C5 for ; Sun, 12 Nov 2017 16:12:07 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id m88so3368436pfi.9 for ; Sun, 12 Nov 2017 16:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=mKUdqMLxsdwldjq6RAhkLOsoE4OM5ju/3fcF0MU9H5Q=; b=pyiVzTX6PfQnV4tUxPwbylTYHnaVc3hmNsZVo5IvyMtmsmB1PMx5ya6sH1UhnuTKQJ UM+dyjckV0YcaFVtX6efhPPklgXM7qDppWnZUG5Gp09SEon3/Mh9v7eSsrTlOj+yp3qG siuM0r08WGGZiQ1zQ8isUgFkU+qHD7srf6hlwwb9jBJ1q6Ha4TI2fbN9+Pa7WaPDp4o/ TKkH57WHzkYOWhKGgb8GmVPS2mjTgYkz2e9H9nnK9O6Z87N0zddChYv5ztUQzeUjHRWs fUtshzd8qlb0rXFzCKYmofozR2Po0BQtpmmPEKc2/hF7n09BIh6pQxd/Vhp0CHzvDX64 ZP2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=mKUdqMLxsdwldjq6RAhkLOsoE4OM5ju/3fcF0MU9H5Q=; b=LLb68oPOZ7cev+cxTtZqFJqTYEtQIjgCDC/DXyIcdTUXEqlSvtHoxasKBmZ8ly3h0N FCm72CfG4X3N/S/RZNoBzfAvzo8kOTjT9g1+NdrjdRaafj0mn91csqR/BZNRUEEosUWq dI4N4irTS5XDuoTc3j90bGdRZfhwAcZ31Y3bWmrxFUWF0A8AawEO7ShKrdrXrril6gJR gE1fxDmeeh8iznmmIaZfqgwg6HrqWJAGjY+0W+gSFuhOPVQke73KC8fzf6mSOrgshdNA Ii1gPl0bMo34OU8hqOTX9h9n1001p8sAOoekXudyLiCzEV01cZIjdT0+ssjDgGC1mTO/ ZQlw== X-Gm-Message-State: AJaThX70m3gH599n6qOzhQMNSJoYZffodFYwjY5OptEkShIG49qGARBf Lwe/T0+NDMWMHge6qp+cRKLtzJGP X-Google-Smtp-Source: AGs4zMZMEf60BGRkc8mvGEe6IgzNos3nXGO0k4Cx74UAdXTZfURaOecRbm8N8oF5LyI4wzhJfbg74w== X-Received: by 10.99.124.89 with SMTP id l25mr6807816pgn.86.1510531926142; Sun, 12 Nov 2017 16:12:06 -0800 (PST) Received: from Melindas-MacBook-Pro.local ([202.55.67.146]) by smtp.gmail.com with ESMTPSA id a4sm30977562pfj.72.2017.11.12.16.12.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 16:12:05 -0800 (PST) To: dnsop@ietf.org From: Melinda Shore Message-ID: <6a9a1b99-20a8-0c25-38d1-d3cdb7255506@gmail.com> Date: Mon, 13 Nov 2017 08:12:03 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EQBGLx7QnSESfLLOUvVbvNC3mvl5v0aOE" Archived-At: Subject: [DNSOP] DINRG update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 00:12:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EQBGLx7QnSESfLLOUvVbvNC3mvl5v0aOE Content-Type: multipart/mixed; boundary="jDwkJUuR6q7uffC0kilLGJc3j84qc1u5k"; protected-headers="v1" From: Melinda Shore To: dnsop@ietf.org Message-ID: <6a9a1b99-20a8-0c25-38d1-d3cdb7255506@gmail.com> Subject: DINRG update --jDwkJUuR6q7uffC0kilLGJc3j84qc1u5k Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable With regrets to the fine folks of dnsop, we've scheduled the dinrg side meeting from 9:30 - 12:00 this morning. We realize that there are many people in the dns community who are interested in decentralized approaches to naming but scheduling during this meeting has been exceptionally difficult. We'll try to make sure to avoid dnsop (and other dns working group) conflicts in the future. Melinda --jDwkJUuR6q7uffC0kilLGJc3j84qc1u5k-- --EQBGLx7QnSESfLLOUvVbvNC3mvl5v0aOE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOwSIcj4Q6xsnay8FuIZGkzoegS4FAloI41QACgkQuIZGkzoe gS5XYQ/7BE51yWrzdug0uFgqhKNURXCmil5el87kc1dVKVQ29MMAWs57jlmFYzF3 yOyv1AC0OTl34k2bLwh4YmsgZn/SyxDx4aNqsP5fMv0nu4rAJ9bmmT7Aozezd747 o6zmWxUnu6i/M0zwUV/Wv4ZuUr6VOcwnTM5tIW+sjaZSJtlzR3QgLc7ERCjzbbV2 FNFNMZwfRJ9BEy7XBc2zjF5TeD7RC8ufGxxI+wxT+twSduXvpU1cpRlSYqbmuN2G WcbKsGGk8HzqUymmef4zUa/awwqeRRheLDh79bDqtT0aQJMgZOU1pRgIsVv6CzsS PX7Qk4ei+M6NXh3wzNAzZaqK70bcgjJWdHsVQ9s7w/FhPt+kM5Ujndy2KYx621mw A1pPItY6i4NeZqK8bu7EOsudRTmXu4v7T/WaM8rn8AbiqvUtJfyZxwH2qMMycbO9 H2Qfb5LGhgf/1Rg+VTOCUEwgTEr2F03B4lSsoG/BsR4bEOTDYnsnuWC8Hizo/WSO EpUuQl9szE5domAmD0XLi3F8oshBnttyA1WYd8ZgBVQA0z9yQwj6F2+AhmfMwhM5 pYnn63q2M/4oBsBJbfiNH7gv2aKC6MDd4wGXX15SpxdV6TfojwP610HiBJlVg4I+ Zw6JA5MX7jjkETkS3rFlB8LXcZiU6oBIaZ8v3ASrS6m6gVwmKPs= =2Lqg -----END PGP SIGNATURE----- --EQBGLx7QnSESfLLOUvVbvNC3mvl5v0aOE-- From nobody Sun Nov 12 16:17:18 2017 Return-Path: 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 651E61241F5 for ; Sun, 12 Nov 2017 16:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 1s7taNgmZtcl for ; Sun, 12 Nov 2017 16:17:16 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425531201F2 for ; Sun, 12 Nov 2017 16:17:16 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id j16so5902125pgn.9 for ; Sun, 12 Nov 2017 16:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=10+wkdWrgugyaVFrvFGYyYPs95hRfkDCjeGL29Ka0PY=; b=YC1iRIvJLtpvgCdlAfsASViQon9VQV3MLZOSVKP4ETfTTFjEA5b6qkopeDcMbe9d+1 fR05LyZIMg1SvhOMwwmmrDGLwoKP4XYQbZVRUJeDspIm0rDA228wu3XHo2i55ffnepbT 5MNdWjLdsJpqpR6Fl+FW+DQLs34dvcfMmzr0QGs8gILjeESrd3ZTlGnJEEKgXH6C+NxB oYg7fUVyj0zXJTAZGz+FmKnp8IkF+gtEMhJ+aCSDg1s12pEriLRrJy98K+XNwRP/ociF bTzufI0KHl+FPe6EtmJ3VX1ELYd6jHLIkOwKpEqMJvXbKHj9TnrPYHc/S6FygP/lrEcJ llBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=10+wkdWrgugyaVFrvFGYyYPs95hRfkDCjeGL29Ka0PY=; b=b1r5T1B4wqvG47zv81pzuE4wWwMzEllbp0M78DKiuZkEKX9R4vpfHSH6xBD5MbRRAv 38XQt0NgUjyvEH36sP8arf7zxxGE06LLKguFhNFaAOiMbFBjCWKWDbCVaerAXaTlGBgs p9kbPewQKGTN68GRBeAE6mdC/W2a1qERdsxrybiFOIqmEMd7vNIo9pz6bBG82WcPa0hY IAXdPAZomUzFjIJk7GFX+p6eHfqsKUX0ARZdw2whZ1iOJ8xI9yVx74hbEf82ShQ8mKu6 Ml4gydL8Ys6600C0zB4YWyIuM96RmOdtxa+cpUQTnW6KlAeTktF/DrvuWYZckuL1c3sr W11g== X-Gm-Message-State: AJaThX5pt9lJ6Vdv/xvEX4v16tiGTDoVG1bwzf6j5Lvv3UkkrOVm5G1Q 5RU2HXjHWuU+jPQGfZqGSavZWg== X-Google-Smtp-Source: AGs4zMYRuy5Emeob+C1x6t5xAvZZgEq4BT3V0UlDRbNmV7mU15fSIEhdA7hW3ZV/DotN6xBeHbAWEg== X-Received: by 10.98.159.210 with SMTP id v79mr7879227pfk.162.1510532235772; Sun, 12 Nov 2017 16:17:15 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:f423:c00b:4688:1866? ([2001:67c:1232:144:f423:c00b:4688:1866]) by smtp.gmail.com with ESMTPSA id 125sm28523972pff.14.2017.11.12.16.17.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 16:17:15 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C8FC5443-9165-4839-84DD-A7BF4BF480F9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 13 Nov 2017 08:17:13 +0800 In-Reply-To: <6a9a1b99-20a8-0c25-38d1-d3cdb7255506@gmail.com> Cc: dnsop@ietf.org To: Melinda Shore References: <6a9a1b99-20a8-0c25-38d1-d3cdb7255506@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] DINRG update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 00:17:17 -0000 --Apple-Mail=_C8FC5443-9165-4839-84DD-A7BF4BF480F9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Nov 13, 2017, at 8:12 AM, Melinda Shore wrote: > With regrets to the fine folks of dnsop, we've scheduled the > dinrg side meeting from 9:30 - 12:00 this morning. We realize > that there are many people in the dns community who are > interested in decentralized approaches to naming but scheduling > during this meeting has been exceptionally difficult. We'll > try to make sure to avoid dnsop (and other dns working group) > conflicts in the future. This is showing up on the agenda as canceled. --Apple-Mail=_C8FC5443-9165-4839-84DD-A7BF4BF480F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Nov 13, 2017, at 8:12 AM, Melinda Shore <melinda.shore@gmail.com> wrote:
With regrets to the fine folks of dnsop, = we've scheduled the
dinrg side meeting = from 9:30 - 12:00 this morning.  We realize
that there are many people in the dns community = who are
interested in decentralized approaches to = naming but scheduling
during this meeting = has been exceptionally difficult.  We'll
try to make sure to avoid dnsop (and other dns = working group)
conflicts in the = future.

This= is showing up on the agenda as canceled.

= --Apple-Mail=_C8FC5443-9165-4839-84DD-A7BF4BF480F9-- From nobody Sun Nov 12 16:23:56 2017 Return-Path: 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 ECC55126579 for ; Sun, 12 Nov 2017 16:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2DBP-WGrLnJO for ; Sun, 12 Nov 2017 16:23:53 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBAE1201F2 for ; Sun, 12 Nov 2017 16:23:53 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id d28so10646104pfe.2 for ; Sun, 12 Nov 2017 16:23:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=U52eurV/1q3koEYjU0dR4yevIqx6jR2WfqpAW36pBVU=; b=YiMzDXi0Zb7/Fb1uSWzFti8FH//9B+Pl8Z77Hi7W14S1DHJk57E1RdP5UCmrICT2T2 5AHtHvzeeRSrCnNc9mWJPhH14O97lIe0j422/5VVHjAQf3qWN/thxv3dQDK25so2aQlB JgD5MTxX/pSOK2ZVAm3MKB74gMLivwQ0RfR5v//fNEnRW9Aw7LRQQUTyYykjBhJBm1mm Y+U7NNfdT+uLUiEweB7gvAl7rsvP2KrlJqfp9aKpW4JJu93MGb8Oq8pdsSCWlOLfQYzd f4GDfOKdUk5nyjslzHn+zwGB9qQniyuKkrKqnBfF/n9Mruzc168NMhJ0bxdScrAkkrty AjKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=U52eurV/1q3koEYjU0dR4yevIqx6jR2WfqpAW36pBVU=; b=N3Vq7EoqURIN8h6+ytiqmYvrrFn73Xw2ISAJoGcRu05R7OSa7dB/ss+CqCow8NvoOc bAT6XZF8MpaawTje5xtKxYMVcMeVbbMuP4vCnavVQlYGv0gLDxtyIlo9nF1Ej9xpQdhc Dh84g/q5BLjqG1mZunBtVAJHGBEgsC1L7jGsO1xP7UXmeDu6G7fUAs9+cHaPSkwZ2isX vhbMLQBqpB1grkGm2AHYRZ4bo87Y88mV13U8HNQS1HKBzwQ/hGmoO7oF9P/vutrC63l5 7X9JZt7qEuQyTY0QKS99JgoQt43epqYqoXti6jCS7PvdYgOx07vcyhApuQmvt8mQR/Cg kuyA== X-Gm-Message-State: AJaThX5xHEbjMJ0b+tu8SFOeNwrYkARK8Xmn41QayVudz5KImy/8z0Lj ohxYZVzQ/k8mxlCVRxeSRusAD+Uc X-Google-Smtp-Source: AGs4zMZRZUgQkMZDFqjZ5CgR5P/Mn+ggkkVdTQzjoWUHWdan+7Zh5bwnFetyj3lxJU05oAmtrWe0nA== X-Received: by 10.99.67.195 with SMTP id q186mr6759949pga.186.1510532632838; Sun, 12 Nov 2017 16:23:52 -0800 (PST) Received: from Melindas-MacBook-Pro.local ([202.55.67.146]) by smtp.gmail.com with ESMTPSA id a13sm23465304pgq.10.2017.11.12.16.23.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 16:23:52 -0800 (PST) To: Ted Lemon Cc: dnsop@ietf.org References: <6a9a1b99-20a8-0c25-38d1-d3cdb7255506@gmail.com> From: Melinda Shore Message-ID: <5dfd8d6e-20d2-4bbe-0d37-cb52699a1f02@gmail.com> Date: Mon, 13 Nov 2017 08:23:50 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0hTfsNKTg30Tp5dTBRJ0H8115SVwofvQr" Archived-At: Subject: Re: [DNSOP] DINRG update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 00:23:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0hTfsNKTg30Tp5dTBRJ0H8115SVwofvQr Content-Type: multipart/mixed; boundary="To9lFqwsq1N3f3obuvhfvIv05x657CV1Q"; protected-headers="v1" From: Melinda Shore To: Ted Lemon Cc: dnsop@ietf.org Message-ID: <5dfd8d6e-20d2-4bbe-0d37-cb52699a1f02@gmail.com> Subject: Re: [DNSOP] DINRG update References: <6a9a1b99-20a8-0c25-38d1-d3cdb7255506@gmail.com> In-Reply-To: --To9lFqwsq1N3f3obuvhfvIv05x657CV1Q Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/13/17 8:17 AM, Ted Lemon wrote: > This is showing up on the agenda as canceled. Yes, this is an informal side meeting - the actual session is canceled. Melinda --To9lFqwsq1N3f3obuvhfvIv05x657CV1Q-- --0hTfsNKTg30Tp5dTBRJ0H8115SVwofvQr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOwSIcj4Q6xsnay8FuIZGkzoegS4FAloI5hYACgkQuIZGkzoe gS54uxAAoT6nlYYR3j0mSaHqaJGyj0gTdw6bSIOWCo3p0iRyNnEAEKlnIhoyYKTb e6806ZEThOW//AEl/70nmA3aegO66SDYCuxHt3fPcNwF/mWzGNPzIwF64BfC0psF p+Xb4kYlqS4h1ILUs8MYWzVBZ7H4Xt0CMCGmzmKiuwkV4sm07ldydpvmerKx3OUX 3hC9P6MpeyD6I4mC5Ym42ldM7i6epoJpr13FCLW4VpMnaOje+BEHhqrB9rRT8LRT d22RR/cCb07+8bzUFjm27P78vc9ZKqdTfRadyn88O3aN39W2QuWavuOXlcVLhNXJ sEMuSWwhh90Bldbvyp53O3JAYTLfJytm0ISNyzG2gQK5Bx2tranGO3Nke75BK5LU UlOdNYqfXkBvY7gHUslpodLkg5jfhjiCEKIfyl5WCHKIlxHiCKXRBad+bDlwc+8u H1hBL12P4r1kkskvRofbmsosCEouYTuTo/9Fcgoxg3LSI0qH5CSGzgtUWy97LVui RMjQ4Vtgv0GAVpPioGCjiM24/fpT9iQCyYQey//KErqSaGIYwQPhx17HFHjwKS7y BgA+eiV+PNuIto3ttZUKvI/2JL0Ucnx5aspIGyT2mBzsIaC8k8FhZeQq8CjhLDKN WdJ/0G56mPz8tz4S/6RF48lZHM5KpKnYkYaEiGYvhEFqDh7tFbs= =YkTx -----END PGP SIGNATURE----- --0hTfsNKTg30Tp5dTBRJ0H8115SVwofvQr-- From nobody Sun Nov 12 17:20:27 2017 Return-Path: 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 E38CC126CB6 for ; Sun, 12 Nov 2017 17:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 zN3dkIlzXj0p for ; Sun, 12 Nov 2017 17:20:14 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4F812741D for ; Sun, 12 Nov 2017 17:20:14 -0800 (PST) Received: from [31.133.137.43] (dhcp-892b.meeting.ietf.org [31.133.137.43]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id vAD1K99R018020 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 12 Nov 2017 17:20:11 -0800 To: Melinda Shore , dnsop@ietf.org References: <6a9a1b99-20a8-0c25-38d1-d3cdb7255506@gmail.com> From: Erik Nordmark Message-ID: <36c30d5f-0968-3b2f-1135-e777d0c6f2de@sonic.net> Date: Mon, 13 Nov 2017 09:20:08 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6a9a1b99-20a8-0c25-38d1-d3cdb7255506@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZNXVMrlFL8c7x+wo2Z6+S3IGJdj6qeV8LvZ5VK9VyFqnIKepI+f4cUPz6r7ce1/mk+2o21AaXKEGbQmgtY3pO8 X-Sonic-ID: C;tow1yhDI5xGDAIKfRUfeDw== M;avRPyxDI5xGDAIKfRUfeDw== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Subject: Re: [DNSOP] DINRG update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 01:20:18 -0000 Melinda, What's the location for the side meeting? Thanks Erik On 11/13/2017 08:12 AM, Melinda Shore wrote: > With regrets to the fine folks of dnsop, we've scheduled the > dinrg side meeting from 9:30 - 12:00 this morning. We realize > that there are many people in the dns community who are > interested in decentralized approaches to naming but scheduling > during this meeting has been exceptionally difficult. We'll > try to make sure to avoid dnsop (and other dns working group) > conflicts in the future. > > Melinda > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Sun Nov 12 17:45:31 2017 Return-Path: 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 BAB39126D85 for ; Sun, 12 Nov 2017 17:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=N8Rv9hX5; dkim=pass (1024-bit key) header.d=yitter.info header.b=RUxyvtDi 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 wnwDYjuCcdhM for ; Sun, 12 Nov 2017 17:45:28 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680C11274D0 for ; Sun, 12 Nov 2017 17:45:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id A7AF0BF56B for ; Mon, 13 Nov 2017 01:44:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510537491; bh=jQZlefpXJ9V7UxQPUOLDjuYHHGtm/whCvfNyDKAUv+U=; h=Date:From:To:Subject:References:In-Reply-To:From; b=N8Rv9hX55UfFouYooxK8WA/18Z81JWQOHTp9mbcu2LLoCFiGnIM07RXZEzKWG0Uf7 bmklFAZBs81qsXhXx3hhVCWMuIZI7AAIkvaWx5bJl6vhn0Gm+MxIDYv+LKrQ9qytq5 mehDKT7ZlYurCNIH5qT8OB7/OQx6irH4n2nrzwlc= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy6jv4-nzNOh for ; Mon, 13 Nov 2017 01:44:50 +0000 (UTC) Date: Sun, 12 Nov 2017 20:44:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510537490; bh=jQZlefpXJ9V7UxQPUOLDjuYHHGtm/whCvfNyDKAUv+U=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RUxyvtDieNujz05cKZBswAvROy+rZl14g/9Ubshgg6SaTzPSB2Fx35mAEwAHCWbe8 EkMQ2YIyarsNbS1kb6Vv17ZtVKWXiECPjfHlicj+fAPMko+MjvWoXi7hqBVQsbPyZK Xe+usFVpu0/V5nhp/+wkhJyvb7EEdfEqz2Xl6Fag= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171112131831.GA32208@laperouse.bortzmeyer.org> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 01:45:30 -0000 On Sun, Nov 12, 2017 at 09:18:31PM +0800, Stephane Bortzmeyer wrote: > This is an upward referral and I tought it was frowned upon since the > ISPrime attack (MUST NOT? SHOULD NOT?) > I tend to agree, but it's certainly something that's around. Should we note that clients sometimes ignore such references? Should we note that servers often do not return these, though they used to commonly? A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sun Nov 12 18:04:10 2017 Return-Path: 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 70C5D12704A for ; Sun, 12 Nov 2017 18:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 LuUo-5EU-C70 for ; Sun, 12 Nov 2017 18:04:07 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E86F127005 for ; Sun, 12 Nov 2017 18:04:07 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 8F1BB61FA2; Mon, 13 Nov 2017 02:04:06 +0000 (UTC) Message-ID: <5A08FD96.8030907@redbarn.org> Date: Sun, 12 Nov 2017 18:04:06 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Andrew Sullivan CC: dnsop@ietf.org References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> In-Reply-To: <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:04:08 -0000 Andrew Sullivan wrote: > On Sun, Nov 12, 2017 at 09:18:31PM +0800, Stephane Bortzmeyer wrote: >> This is an upward referral and I tought it was frowned upon since the >> ISPrime attack (MUST NOT? SHOULD NOT?) >> > > I tend to agree, but it's certainly something that's around. Should > we note that clients sometimes ignore such references? they must be ignored, because they could constitute part of a referral loop. valid referrals are to descendants not ancestors or cousins. > Should we note > that servers often do not return these, though they used to commonly? we should note that an upward or sideways or other non-downward referral is a sign of misconfiguration and must be treated as SERVFAIL. -- P Vixie From nobody Sun Nov 12 18:07:44 2017 Return-Path: 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 78B9912704A for ; Sun, 12 Nov 2017 18:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=ViQg03OV; dkim=pass (1024-bit key) header.d=yitter.info header.b=hoUjvN8q 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 LRhp8RMaUPXV for ; Sun, 12 Nov 2017 18:07:42 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE0B126CB6 for ; Sun, 12 Nov 2017 18:07:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id BC059BF56B for ; Mon, 13 Nov 2017 02:07:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510538861; bh=70CBBDGM9bRK4gv0082TgBp4rgb7UELZsxg7RSKzPBA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ViQg03OVuJgmayoK7v09dxz55ALrh7j4AqzER7izE3pScV3em2zpM3NSuA4KnJlur UDJZBy8XIgUB75VzuTj52lKqMaheO9EvV5vq9gpnWc5Ro+rb3HpjVEN7HahHnoakDd nQh46ivR1TA+FeV6ZYNvj/FD60aMGMqcL4v5CWiM= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHKNcX4eN0V8 for ; Mon, 13 Nov 2017 02:07:40 +0000 (UTC) Date: Sun, 12 Nov 2017 21:07:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510538860; bh=70CBBDGM9bRK4gv0082TgBp4rgb7UELZsxg7RSKzPBA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=hoUjvN8qSRQdF6jQHQGMoiZ586OIh92NKPSKvVhHRS0iE81tCdXecMiJ4sRJZIIJ/ Oj7tNR3hnsWdKTDzizdvk/ah96pV8DmGrxGhmAKmbrv7vaR5ItkZpb7akC9cEkFdrn I4Ug7H9CMDu0EYU691Mw7tl3j5j46+QO2/Vsst0U= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5A08FD96.8030907@redbarn.org> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:07:43 -0000 Hi, On Sun, Nov 12, 2017 at 06:04:06PM -0800, Paul Vixie wrote: > > they must be ignored, because they could constitute part of a referral loop. > valid referrals are to descendants not ancestors or cousins. […] > we should note that an upward or sideways or other non-downward referral is > a sign of misconfiguration and must be treated as SERVFAIL. I am a little uncomfortable with using this document to specify protocol behaviour as opposed to specifying protocol behaviour already specified elsewhere. I may have missed them, but I am not sure either of these requirements (musts) are stated so baldly in any RFC. Have I missed something? A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sun Nov 12 18:42:59 2017 Return-Path: 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 C179512871F for ; Sun, 12 Nov 2017 18:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Nhx2JgAdHf3e for ; Sun, 12 Nov 2017 18:42:55 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240BA128BBB for ; Sun, 12 Nov 2017 18:42:19 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id E1D1461FA2; Mon, 13 Nov 2017 02:42:18 +0000 (UTC) Message-ID: <5A09068A.3030206@redbarn.org> Date: Sun, 12 Nov 2017 18:42:18 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Andrew Sullivan CC: dnsop@ietf.org References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> In-Reply-To: <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:42:57 -0000 Andrew Sullivan wrote: > ... >> we should note that an upward or sideways or other non-downward referral is >> a sign of misconfiguration and must be treated as SERVFAIL. > > I am a little uncomfortable with using this document to specify > protocol behaviour as opposed to specifying protocol behaviour already > specified elsewhere. I may have missed them, but I am not sure either > of these requirements (musts) are stated so baldly in any RFC. Have I > missed something? when i stupidly introduced the idea of upward referrals while evidently hallucinating on crack cocaine back in the mid 1990's, the section of RFC 1034 that somebody should have printed, rolled up, and smacked me with was 4.1: > 4.1. Introduction > > Name servers are the repositories of information that make up the domain > database. The database is divided up into sections called zones, which > are distributed among the name servers. While name servers can have > several optional functions and sources of data, the essential task of a > name server is to answer queries using data in its zones. By design, > name servers can answer queries in a simple manner; the response can > always be generated using only local data, and either contains the > answer to the question or a referral to other name servers "closer" to > the desired information. the operative phrase is '"closer" to'. this is repeated in 4.3.1: > 4.3.1. Queries and responses > > The principal activity of name servers is to answer standard queries. > Both the query and its response are carried in a standard message format > which is described in [RFC-1035]. The query contains a QTYPE, QCLASS, > and QNAME, which describe the types and classes of desired information > and the name of interest. > > The way that the name server answers the query depends upon whether it > is operating in recursive mode or not: > > - The simplest mode for the server is non-recursive, since it > can answer queries using only local information: the response > contains an error, the answer, or a referral to some other > server "closer" to the answer. All name servers must > implement non-recursive queries. here again we see '"closer" to' as the allowed behaviour. of course, we also see that Unbound, and BIND with "recursion no;", are out-of-spec. so there's evidently a lot of fuzz here. that's why i'd love to see your current "clarifying referrals" document reference RFC 1034 4.1 and 4.3.1 and somehow reinforce that this wasn't a part of the spec that folks can just ignore, even though many have and others probably will. in [ibid], this is reinforced a third time: > If recursive service is not requested or is not available, the non- > recursive response will be one of the following: > > - An authoritative name error indicating that the name does not > exist. > > - A temporary error indication. > > - Some combination of: > > RRs that answer the question, together with an indication > whether the data comes from a zone or is cached. > > A referral to name servers which have zones which are closer > ancestors to the name than the server sending the reply. > > - RRs that the name server thinks will prove useful to the > requester. this time the phrase is "closer ancestors" which is even clearer than '"closer" to' as used earlier in the document. and then in 4.3.2 we see: > b. If a match would take us out of the authoritative data, > we have a referral. This happens when we encounter a > node with NS RRs marking cuts along the bottom of a > zone. here, some inclarity is introduced by implication, since in what we now call a "mixed mode" name server, indirect descendant information may be present, and at least one name server whose innards i'm aware of would send a cached referral. also if a name server is authoritative for two zones, one the parent of the other, then when it receives a query it will not know which zone the iterative resolver client thinks it is "in" and will send the "closest" answer which may hide the parent's delegation to the child, effectively gluing two zones into one. i don't think you'll want to bite off all that in this document, but i want to reintroduce this problem to the e-mail archives since the last time it was spoken of was on the namedroppers list in the early 1990's. ("unix mount point" semantics are a steep climb, but the only way out.) importantly however, the time when the algorithm described in [ibid] is allowed to send a referral is when a match would "take us out of the authoritative data", and the referral contents are copied from the non-authoriative NS RRset at the bottom of the zone we were searching. so, further evidence that upward or sideways referrals are off-spec. -- P Vixie From nobody Sun Nov 12 19:27:37 2017 Return-Path: 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 D11A6129415 for ; Sun, 12 Nov 2017 19:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=LwzhBmJe; dkim=pass (1024-bit key) header.d=yitter.info header.b=ACFrQGum 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 V8d2AC0Z7iXV for ; Sun, 12 Nov 2017 19:27:25 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FA0129408 for ; Sun, 12 Nov 2017 19:27:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 6E259BF56B for ; Mon, 13 Nov 2017 03:26:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510543608; bh=Kbyy9+5GyEmvMKpzJ4haVadgbByQorYJXDyEwru/3HQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=LwzhBmJeX944+fyxVGpEqdcn8uxRk3MPg3R5OreS4Ogk2uJpCDuJcEVNJ1QMu5hdm Hm2zOyHGJ4tv0bWZBaN8KK3DEp3/5yEtVfD94eWjjwF8LjXCbXkw1xaH4ZBx7Y/MJc 2w/YFuE3mSnSLSKXoWSYbPH2TWr8UzphAp1wr/rU= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uROe_fcIp8PO for ; Mon, 13 Nov 2017 03:26:47 +0000 (UTC) Date: Sun, 12 Nov 2017 22:26:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510543607; bh=Kbyy9+5GyEmvMKpzJ4haVadgbByQorYJXDyEwru/3HQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ACFrQGumoZUls8smIwgQxmPY1/GI2rlbmrZP1vaP1ib14a+mxtkV6vVzPJj0z912j 9Pba9BZeGlAPjZckLhqAHnkg3NzcNCtz4Akv8uzC5m4LZ2izWZl4Eu7OK9C1T+Xmts c85m9rnv/GjfgluTpkj89GNBEKfoyK5XqWl9MnHc= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A09068A.3030206@redbarn.org> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 03:27:33 -0000 Hi, This is quite a helpful response, thanks. I wonder whether more of it ought to go in discussion (or a new draft), however. For I'm struck by this: On Sun, Nov 12, 2017 at 06:42:18PM -0800, Paul Vixie wrote: > > always be generated using only local data, and either contains the > > answer to the question or a referral to other name servers "closer" to > > the desired information. > > the operative phrase is '"closer" to'. this is repeated in 4.3.1: If I ask the authoritative server for example.com about a name label.example.net, in a graph-theoretic sense the NS RRset for the root zone is clearly closer to label.example.net than anything else I can give. So the upward referral doesn't seem prohibited by this at all; on the contrary, it seems like a requirement. Maybe I need to read this again with better glasses. The current approaches that people have for this are either NODATA responses and REFUSED. Only the latter seems obviously consistent with the text, though I'm aware that there's controversy over using REFUSED here. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Nov 13 01:11:11 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 346E912953B; Mon, 13 Nov 2017 01:11:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151056426921.21486.1491076825222186071.idtracker@ietfa.amsl.com> Date: Mon, 13 Nov 2017 01:11:09 -0800 Archived-At: Subject: [DNSOP] The DNSOP WG has placed draft-dupont-dnsop-rfc2845bis in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 09:11:10 -0000 The DNSOP WG has placed draft-dupont-dnsop-rfc2845bis in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-dupont-dnsop-rfc2845bis/ From nobody Mon Nov 13 01:11:55 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E82E812960D; Mon, 13 Nov 2017 01:11:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151056430694.21354.9434073937927132106.idtracker@ietfa.amsl.com> Date: Mon, 13 Nov 2017 01:11:46 -0800 Archived-At: Subject: [DNSOP] The DNSOP WG has placed draft-huston-kskroll-sentinel in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 09:11:47 -0000 The DNSOP WG has placed draft-huston-kskroll-sentinel in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ From nobody Mon Nov 13 01:45:33 2017 Return-Path: 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 B1F12128BC8; Mon, 13 Nov 2017 01:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RMUepXFq8F2S; Mon, 13 Nov 2017 01:45:30 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBEA12762F; Mon, 13 Nov 2017 01:45:26 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id d28so11463510pfe.2; Mon, 13 Nov 2017 01:45:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=OkOL4474hGfDAYdW6YK7rxS1N9tUM5EsWs0f02pyGLs=; b=lnUY6gnx0pB6aJrb4O6IuPAekf8nH08qVwJX8NO+VsSbppEfizOuXubrQerarwngKY FpWGapnl9r+apZUhUXchZX3uuLT3VnPOWG+xl0DheonGnZiwhdE2XILQ+hNjQdQGAxdu Mgw9eFQT1hQTlOaUaXRcWc1c2rr/2ohBEqhBIn2PpwOuXIIdABuxpDpuSpd2J66vpjGp uR5ffxAilrSiYXHspEPnTvCbEGVj0xpOY+25lP6zKHVu1y5boMY9tXQ+10v8qyH0W1Bo 4zzAEjU6djIxn33h34nZXr1U8Pbuu2/1R/7h1+ccCNyl2G2AV3vTlzV364YgBhrA09ks rP7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=OkOL4474hGfDAYdW6YK7rxS1N9tUM5EsWs0f02pyGLs=; b=YjWV/6KIrnZisS8u/S2iPCLnjK+NrbjpHACi6sAC78eupK7x5mb5EfkT9anMwZclCQ cxX7bNo2QqkVQTaSMRz74IKN88CW6BLwGedFHMDzeho8Tu+PLflGpqfRKLT/BWaajtHp jU9w0D2zemTWGQIF6sdstrhd6pahABzpw0loGFVe4vbn6rQog29jmchDGivfZdh/BTjV jsh/0vLaK8HhCr6hW4LzcIMxkAsZ4R2vuQ8U3nryrKO44aTmaMjCMTfSJhuSWk/qhwUw 5Qm2CI4h6kg0H+xv1vmDUqqVws/uFDBMT37tHXdQpqk+xZV9GbOtfo/9kE2Y5zEb8Zuq 6IfQ== X-Gm-Message-State: AJaThX6ie2mBo+Jf1UFggaVcs3MPA3gnRjaWTnmnaoo4yQXzA8Hno2Ty oeRzoNhYSPzw8NIheFGhBfJhHmHw X-Google-Smtp-Source: AGs4zMaL9RBYTf650m8XbKFRa5QXm/o7vNncJM/Qp7/Rpy6GkbaWCZc05wag5hAcN3UT9BLaFtIEiA== X-Received: by 10.84.242.145 with SMTP id d17mr433586pll.127.1510566325965; Mon, 13 Nov 2017 01:45:25 -0800 (PST) Received: from dhcp-998f.meeting.ietf.org (dhcp-998f.meeting.ietf.org. [31.133.153.143]) by smtp.gmail.com with ESMTPSA id k12sm26128804pgo.5.2017.11.13.01.45.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Nov 2017 01:45:25 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_13CB0DCC-C3F1-4408-A2F1-8A05DEE0D92D" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Suzanne Woolf In-Reply-To: <151056430694.21354.9434073937927132106.idtracker@ietfa.amsl.com> Date: Mon, 13 Nov 2017 04:45:21 -0500 Cc: draft-huston-kskroll-sentinel@ietf.org Message-Id: References: <151056430694.21354.9434073937927132106.idtracker@ietfa.amsl.com> To: dnsop WG X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-huston-kskroll-sentinel in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 09:45:32 -0000 --Apple-Mail=_13CB0DCC-C3F1-4408-A2F1-8A05DEE0D92D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear colleagues, In our meeting earlier today at IETF 100, Geoff presented on this draft. = (Slides are at = https://datatracker.ietf.org/meeting/100/materials/slides-100-dnsop-sessa-= draft-huston-kskroll-sentinel/ = ) It seemed to have significant = interest, and we were asked to consider it for adoption as soon as we = could because it may be helpful in revising the schedule for the root = KSK roll. It=E2=80=99s still new so we think it needs review, but we=E2=80=99re = attempting to move it forward if the WG supports it. So please read it, = perhaps while you=E2=80=99re in Singapore for IETF100 and waiting for = your next WG meeting to start, and look for the formal Call for Adoption = on this list later in the week. thanks, Suzanne & Tim > On Nov 13, 2017, at 4:11 AM, IETF Secretariat = wrote: >=20 >=20 > The DNSOP WG has placed draft-huston-kskroll-sentinel in state > Candidate for WG Adoption (entered by Tim Wicinski) >=20 > The document is available at > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ >=20 --Apple-Mail=_13CB0DCC-C3F1-4408-A2F1-8A05DEE0D92D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear colleagues,

In our meeting earlier today at IETF 100, Geoff presented on = this draft. (Slides are at https://datatracker.ietf.org/meeting/100/materials/slides-100-d= nsop-sessa-draft-huston-kskroll-sentinel/) It seemed to have = significant interest, and we were asked to consider it for adoption as = soon as we could because it may be helpful in revising the schedule for = the root KSK roll.

It=E2=80=99s still new so we think it needs review, but = we=E2=80=99re attempting to move it forward if the WG supports it. So = please read it, perhaps while you=E2=80=99re in Singapore for IETF100 = and waiting for your next WG meeting to start, and look for the formal = Call for Adoption on this list later in the week.

thanks,
Suzanne & Tim

On Nov 13, 2017, at 4:11 AM, IETF Secretariat <ietf-secretariat-reply@ietf.org> wrote:


The = DNSOP WG has placed draft-huston-kskroll-sentinel in state
Candidate for WG Adoption (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/=


= --Apple-Mail=_13CB0DCC-C3F1-4408-A2F1-8A05DEE0D92D-- From nobody Mon Nov 13 02:43:40 2017 Return-Path: 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 66EB9124BE8 for ; Mon, 13 Nov 2017 02:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fCiNtPE3uBD2 for ; Mon, 13 Nov 2017 02:43:36 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D353120726 for ; Mon, 13 Nov 2017 02:43:36 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id r68so14187899wmr.3 for ; Mon, 13 Nov 2017 02:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N44/itIUfaJZZtPn3YM0AUiiH2hN1Wl1HWyUHVCjwbY=; b=ALRluGuW42yguG/IwmFIy8O+4eF/A8DhclQug1looS4vwr5VM8If/PsvHmES5zjaHN YHoGgyqcT/PE0byPbi0aBSUSMYRLidkAgAU9O6C9T0hOlmaQ3MFQpS1RuBWALAygD0rG TNGZFLzlNVh52oimRV5BW3VqhD6yO2ajeRx5AHmRLp1j09X9x7bxw5xqpcS2xkEaWEZh +sRuPlIwMyEWfItMQ2+WFMTrkxppubG3CBnNQSHBHYlgTzw4DxyUG5dF0KKzN1dH7YPi Z8eEjmIMeWdZfs2BlqjbFtHiwP1Sd3UPrao3CXzuNO/ufnifnezfVjnRo1fi4Q27721/ LG2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N44/itIUfaJZZtPn3YM0AUiiH2hN1Wl1HWyUHVCjwbY=; b=c8DiSfGoiED5Qg92lhkH783Va4VpftleMzf5n5ZFmfJRjz5RWi/UwNcFJnhtLUJJw5 Pma6g7iYCbIFlaq1sD4wY1mSbegHRc6cIFGUyoE0Nt6TgSvaBYNp8wWWcKT8fAVzaL0r sI9vQ2pfSuxlgRMs8jAG/QPli/ay7okpJOFdbVqNT2lHZ7ApZuM5txab4g9yVSWR205k 0kBcMnAgUGNpTAqYHOFOrdAiMsqEn1CW8fHZ5MUY0hv7L/YmbL/B/h6pb0iXtR+CB9TG BVVpT6BezV+uoRaE/mjov9Azv/XRcQt7J1iHUtuwHaHRuLgaGXEd5wV/qHZasJWaKFTb efYg== X-Gm-Message-State: AJaThX4vbAPakKHkK1NhX6ChLsdW1ntWATxxNJO7OswWjWZOJqVNt+l4 WURUfRClhF8hUR6NvL9NJqFMW8EYSRBp/bIxFXA= X-Google-Smtp-Source: AGs4zMZSlVBh9rox31VfSfotAEh619kvl4IwSCG2EJ1GWsDsfsaNOmXkYVreKmcmyEQGEbCmY1VdGc45YLlWAKL8/6Y= X-Received: by 10.28.100.212 with SMTP id y203mr6280469wmb.64.1510569814896; Mon, 13 Nov 2017 02:43:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.196.169 with HTTP; Mon, 13 Nov 2017 02:43:34 -0800 (PST) In-Reply-To: References: From: tjw ietf Date: Mon, 13 Nov 2017 18:43:34 +0800 Message-ID: To: Wes Hardaker Cc: dnsop Content-Type: multipart/alternative; boundary="94eb2c0531c039b5ec055ddaf1d8" Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 10:43:38 -0000 --94eb2c0531c039b5ec055ddaf1d8 Content-Type: text/plain; charset="UTF-8" To follow up from the meeting this morning, it sounded from the room that in the case of these four options, #4 was the one which makes the most sense. tim On Tue, Oct 17, 2017 at 6:39 AM, Wes Hardaker wrote: > > Folks, > > We were given feedback during the call for adoption to "use numeric > range codes like those in HTTP". Following that, Warren and I sat down > and came up with some possibilities and would like your feedback about > which of these options you would prefer: > > 1. Individual codes assigned one at a time, per the existing doc > > 2. HTTP like: integer ranges where NNYY indicates the NN integer rcode > and YY indicates the sub-code. Note that this needs a 32 bit error > code field. > > 3. Use a 16 bit error code field, with the 16 bits differ per rcode. > Thus, clients would need to use the combination of rcode and error > code to determine the error. > > 4. 32 bit code field, repeating rcode from elsewhere in the packet > Like #2, but copies the rcode directly into the error code header > within the extended-error component of the packet. Redundant but > clear that the entire 32 bits are needed. > > Thoughts? > > -- > Wes Hardaker > USC/ISI > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --94eb2c0531c039b5ec055ddaf1d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To follow up from the meeting this morning, =C2=A0it sound= ed from the room that in the case of these=C2=A0
four options, #4 was t= he one which makes the most sense. =C2=A0=C2=A0

ti= m

On T= ue, Oct 17, 2017 at 6:39 AM, Wes Hardaker <wjhns1@hardakers.net>= wrote:

Folks,

We were given feedback during the call for adoption to "use numeric range codes like those in HTTP".=C2=A0 Following that, Warren and I sa= t down
and came up with some possibilities and would like your feedback about
which of these options you would prefer:

=C2=A0 1. Individual codes assigned one at a time, per the existing doc

=C2=A0 2. HTTP like: integer ranges where NNYY indicates the NN integer rco= de
=C2=A0 =C2=A0 =C2=A0and YY indicates the sub-code.=C2=A0 Note that this nee= ds a 32 bit error
=C2=A0 =C2=A0 =C2=A0code field.

=C2=A0 3. Use a 16 bit error code field, with the 16 bits differ per rcode.=
=C2=A0 =C2=A0 =C2=A0Thus, clients would need to use the combination of rcod= e and error
=C2=A0 =C2=A0 =C2=A0code to determine the error.

=C2=A0 4. 32 bit code field, repeating rcode from elsewhere in the packet =C2=A0 =C2=A0 =C2=A0Like #2, but copies the rcode directly into the error c= ode header
=C2=A0 =C2=A0 =C2=A0within the extended-error component of the packet.=C2= =A0 Redundant but
=C2=A0 =C2=A0 =C2=A0clear that the entire 32 bits are needed.

Thoughts?

--
Wes Hardaker
USC/ISI

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--94eb2c0531c039b5ec055ddaf1d8-- From nobody Mon Nov 13 03:41:16 2017 Return-Path: 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 83A9E127B31 for ; Mon, 13 Nov 2017 03:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.onmicrosoft.com 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 SGcy02rnoHmj for ; Mon, 13 Nov 2017 03:41:12 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0086.outbound.protection.outlook.com [104.47.92.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8396F124BFA for ; Mon, 13 Nov 2017 03:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lH0gB994/OMMZvbkjGXMTDLBZRQpHSbkXTvQrxQAwac=; b=oAVwj9xifWiQSPSOQJorELOQr53gqIdGIhiul1/JRVFNxGS9b782aFC9hppfVZdi3eSlH9YEMMa3DrkAnSoHf/O2e/lbsZw+0DWMZ310LNklurBOKo896mrKBki22oBSGPATZ277LdtjLTYWE6XvwWnisRSJkX2UAEJ0G9O7X9Y= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; Received: from [IPv6:2001:67c:1232:144:dde6:9fe8:8ece:14a2] (2001:67c:1232:144:dde6:9fe8:8ece:14a2) by TY1PR04MB0703.apcprd04.prod.outlook.com (10.163.246.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Mon, 13 Nov 2017 11:41:08 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Geoff Huston In-Reply-To: Date: Mon, 13 Nov 2017 22:01:30 +1100 Cc: Wes Hardaker , dnsop Content-Transfer-Encoding: quoted-printable Message-Id: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> References: To: tjw ietf X-Mailer: Apple Mail (2.3273) X-Originating-IP: [2001:67c:1232:144:dde6:9fe8:8ece:14a2] X-ClientProxiedBy: HK2PR04CA0081.apcprd04.prod.outlook.com (10.170.154.153) To TY1PR04MB0703.apcprd04.prod.outlook.com (10.163.246.25) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ec0f001a-e68c-4316-6a69-08d52a8b6e7e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:TY1PR04MB0703; X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0703; 3:W2RfmbpxqfL2S2Vb0a/BQZOcyrIKsSCvRMkYg4OPs0uK93IEGvPXD+ZNLAUn6kRa7bJwpXYzoZqPtPx4bZA3MO4jKFBgnSheiCgR99wFgNDc7T5zr2KvVN96ynZMRL1RKC68QQc6QMCjV2P54Z74Vg2pg70GzMm/3od7JeZtDCm8Fq5Rf2tWI39XAd2y5xiFDjcjWmjOTU/UIwnafGtkpFXKZUevqebNpfXxFX+zrkr9u8QAfGClZn/KX+BN/cQp; 25:inruJu6jXyYZ5F4i/4lKql7xQ9z+LJgxdUoBKrTANp9gcHd3+W5QoaJ/dOPXlyFzUBl70YGFzXVhN3gvxNZVrP3QQLCX/L77LOkwyo/VgJKMV8HUJNZjdRhwBjS+BtEHpwiXmkkIhlxuD5NN6lv8z8OcYkhhsSPG47AfoFTNQ8mx0WSjWJVTcLEN2r4AiveXPLP64zkafX91FaQVBqn0BkhxZ5iZWYN45LzKYK1CTqy6z4CLGvIJmM9NnANQL9sNMmmGvBaYzswJiLp/wv3V/PQU9kdyIJld5jeGSUeaX3FEIN7z8qnQaB3pCil5PXOhg+uS5r4qwUBRBalq0xboQQ==; 31:5Sv5/t+S5FqYSJnARjYLEJBLhZHY4zIQ7Flx/luAaq/nyIvV/punkUmK16h+uuVtaQOqQbi2YoQ58O2KP+uVuCfboI86aBmKYGKNlwG+rdCLEI6Tij3vPapChgNyvTIOcWkQiQEKpQtRokoNpiDFBEg+4lMuH86cI+Ti6VF1lHqNrkRsmK4AlVAm+obg0q+MiEVQYkspRBpY6wfWGHbOVMDe1A5W8XCM8WkNAH6N3G0= X-MS-TrafficTypeDiagnostic: TY1PR04MB0703: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231022)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:TY1PR04MB0703; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:TY1PR04MB0703; X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0703; 4:sPqRXpoLZO9tGslJgYaHYH0x8HKH1vc/w6kz8wmKr60NB4usLEduSgcGKrih7z372RV4bQc4NuVuoYOJqRX4UJ3oB+ZonvUgp1hR92T8Axj8sbxQy8/CgMQEseZpJYx4zkRSp2CVHqUuXzLZuaMBoVVY293GSBDRy8Ufa2fx22sxpBrZZlOj9W1ScgYZ111cHXNeerTxZ4ntBbfDB3lTNtB6gRxMX2ANhWD+ZFheunxoeAy/U5NXnvKglgHnXepsUBovrmDwqSrC+LOZAJRYEQ== X-Forefront-PRVS: 0490BBA1F0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(39830400002)(346002)(199003)(189002)(24454002)(305945005)(478600001)(6486002)(50986999)(36756003)(53936002)(39060400002)(4326008)(1706002)(6116002)(86362001)(82746002)(7736002)(81156014)(8676002)(76176999)(81166006)(101416001)(8746002)(8936002)(68736007)(6246003)(2906002)(53546010)(50226002)(57306001)(47776003)(97736004)(189998001)(105586002)(23676003)(106356001)(54906003)(230783001)(83716003)(316002)(33656002)(2950100002)(6916009)(6666003)(5660300001)(50466002)(25786009)(229853002)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:TY1PR04MB0703; H:[IPv6:2001:67c:1232:144:dde6:9fe8:8ece:14a2]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: apnic.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjA0TUIwNzAzOzIzOmlRUS94ekgvMnFEMlJSdityV2dpMk9pWHF0?= =?utf-8?B?OEY5OVNwSUovZ0htREhYL1p3T3ljZnNMUnJQNStqd0NxK3ZVRzlHQ3hDRk1P?= =?utf-8?B?MjdNRVZnK1pqZGhIN3cwRVhNZWl5ZUtRamdjN0NWSXVRSFVoaEhEM1IzdG9V?= =?utf-8?B?YTBIdUgyUmVqeERoS3cxbGlOZFlBT1JsUlRsZkRubDFaWkVJRzMxT0dLd20y?= =?utf-8?B?OUlXQ2ZFZE9pZG83WU9uSDc2UGZudDgxSkxPdldVdUFkRURpUjhYdzJtWHNx?= =?utf-8?B?UzUrallYK3YzUmJoampBdTlvZUVyYkZvU0lNdDV4dmk0N3Rha1VHWG9rdjVt?= =?utf-8?B?cEZmOW1vYVNVQlBPNGtHcXdRdVB4UktYUmJWNU8yTGtwZXVmdi9uWUFIL05D?= =?utf-8?B?QWE0dEpoOVNER001QVM0UU13SlphN29QUE03RG5WT2VoQzlzV3Bka2Y2R05r?= =?utf-8?B?VW9makx0S2RNNU5La2lDQmRidngvcGdYYUhiYkJnakNURG5oUWx2V011VXlJ?= =?utf-8?B?Z0RydU1INm9IbkZEaERTMFkvaExiM2JBM3p1MW1BWFFwei9TbGhiQWh3QlRi?= =?utf-8?B?RlFKNENzaHFYR0JaTFE1Szhodks0ak41bUlUZDI2TTFFMlU5WXZUVHZpRVdo?= =?utf-8?B?c3ZOZWZVK3VJSGxoU1NJSkFaNEUxcURlcUkxLzBLNlphancxM3B5VDJpRTll?= =?utf-8?B?UFl3clhjbzV0NzlKTW5vQmRDL3AzeWRiMUs1L011bjBHTW84S2FJTEFKYm5V?= =?utf-8?B?MjFXa0REY0JFbTFuZ2RFUGlPUGNwYU95VHkrTUV5MGtrc29PQnhhVzZkMFJV?= =?utf-8?B?UWJUbWpSWWRKTWRock1IYjFEZ0lKQVN0V3dIUVJHTkZnU2FLWktGTlE4MmRr?= =?utf-8?B?ZDN0NmgrRG9OUFAxOCtONzUxNnJiR3Y1VDVhTG92VE93dllFdXBmVmFLZ1R6?= =?utf-8?B?eHFZZ0NEM20yWGNSK094UUxsTnVHRUFQcU4wdDRuT3ZWZlRYaGRXMTd4d3Bk?= =?utf-8?B?VTNZZjVlbUQ1R3cva1BkUmhPZ2pUa0xjRFBCRUEwd0JWeFRtcnlrRXBsdXpP?= =?utf-8?B?eGI4Z3owbytNRnI3a1puL0toWWxub2dVMUZzVDdtL2JKRG9wcTZKYm4zRmti?= =?utf-8?B?YjdMRklPbnhkbWVwaDJXeEF3SEZ0SUxMRngvbzhBY09CVVpVQXI3ZmljZHpl?= =?utf-8?B?d254ZHpFK3J5QkNSTW1IaktpMjIwMFh5TEtGQjllaWdHNTNwQjBCQXJkU2dM?= =?utf-8?B?cCtNWjQ0dmdWajBFWkc0UFdFRDkxZVJEZi9xOGlzNHprRGJxTndaQ3owTHZ5?= =?utf-8?B?c3hqZi82MXhzVEtqdGZ5cnBvcUtxLzBQTGNGenE1OENqd2xFUUZiZE9yNXRy?= =?utf-8?B?dWNuTmZ6QVJHNGVSS1Bpd25VWGhRK3ZOREJyL1FuM1RzWE1SY3MzUTFLVnV2?= =?utf-8?B?ajBGRTJMWC9UWjNVcWlUNDljMERXb3B2UWtRSmdXMXlnaVRtZnpxN2xPMk1P?= =?utf-8?B?aW0reHlIdDZ2UWFuUUFRNmRXTFZmUGpnVkdNbjhESzZyUnRtajgyK25DeGw2?= =?utf-8?B?ck90RzRKQzJPOWtEbDRHZXVXZEwyVE9mYkZSK1c1WEpMdzM0NDZhTFdzQzdY?= =?utf-8?B?U3dUWitDNnpxTUN1SFNaUSt1dXNjaDBBdWY4ZkJ6TzFCUjdMZndzYytnPT0=?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0703; 6:VHsmLZ8IghQnE3sOJcaoLJeFAGRgdw564pLMDXwhz8oDhpckTbj6S474iuspVGPVeFGzAP0uzAHgaYJqlMgya/9Ugvgf+LAcKhyjwtRlddPvvm8joXGboiUUmwVPbfwCcl96G7aBFD6Qj1XQHlR2mWmoHAgyqZjaQfPRjBBV27XZFS2jMXux9V7FhIZb+6b58dobfwAFx9lgBpKpXuV9l9urVV9xbTGiVlnjf9KB8Z5ZFQjKT6ydd3JOG9KHDyf0F8p1sJBNloMr4O/fDTq3t7D114r8Qa7G1hx04p/hHYsArhgi2v0WQiDc7b2fV5t/BWIFAFnLkcZXlZPDBiqC+bCgqEEaCBVC9h3BEBf7oPU=; 5:FIUNpP2kvI2jpvEBqX2kUUH3QTuZQENSSqyMA73i0EteFUgKUnyQAjGVrFPhFX5tRDowBDCGpCduC41rgZDguCFmMte3qRKFfz7UgHSv0U+k7hqrdNhYYPfD5fFXDwrnZgaDx4O/5aKZgm7DsC8vVA7bTfsoWHuf2bMpI5Xyj7w=; 24:B5603y/DX0+9mW/aVww434lQoa4wbliGrdNZpAurB6jgMjxheT/V3v7hiMJAjzmDIZJ63RQ02k0qy+02IVkNRqawpGcWIRji0SYhmzTwaew=; 7:TOn8i1sCSOxor2/BUCsDJuInIQ+pQbmAt3fcFXvTvdiVa1d48py7nL+TjO+4Mq+U27QGgMcPeoje/wzYOmBy4sTzRGsIq9UnSm0LC1VPqt5jqGLcTaMgv0Mz9RAoahdoVMBDpB2pZZOcV61523M2LJE9ZOza54F8LR6ElNL1PuL56mroGhC85n2OsMVzmhmsi+h5km1gG9d+4DT7XZofIDjBtSd4d0M1SZJLEWgqwgLR/f7lIvFFp7zqod0Jq6fY SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Nov 2017 11:41:08.0548 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ec0f001a-e68c-4316-6a69-08d52a8b6e7e X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR04MB0703 Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 11:41:14 -0000 > On 13 Nov 2017, at 9:43 pm, tjw ietf wrote: >=20 > To follow up from the meeting this morning, it sounded from the room = that in the case of these=20 > four options, #4 was the one which makes the most sense. =20 >=20 >=20 =E2=80=A6.. >=20 > 4. 32 bit code field, repeating rcode from elsewhere in the packet > Like #2, but copies the rcode directly into the error code header > within the extended-error component of the packet. Redundant but > clear that the entire 32 bits are needed. >=20 > Thoughts? errr - what would it mean if the rcode in the error code header differed from the rcode value in the extended-error component? The issue with duplicated information in a packet is that you then have add even further consideration to cope with the cases where the expected thing did not happen. Not exactly blown away by #4 myself. Geoff From nobody Mon Nov 13 04:37:01 2017 Return-Path: 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 51E49128959 for ; Mon, 13 Nov 2017 04:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 IVzpfjviCWOR for ; Mon, 13 Nov 2017 04:36:58 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 B3BE6128D64 for ; Mon, 13 Nov 2017 04:36:58 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:59123) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eEDyz-000DTk-0x (Exim 4.89) (return-path ); Mon, 13 Nov 2017 12:36:57 +0000 Date: Mon, 13 Nov 2017 12:36:57 +0000 From: Tony Finch To: Stephane Bortzmeyer cc: dnsop@ietf.org In-Reply-To: <20171112012835.GA16257@laperouse.bortzmeyer.org> Message-ID: References: <20171112012835.GA16257@laperouse.bortzmeyer.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] About draft-ietf-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 12:37:00 -0000 Stephane Bortzmeyer wrote: > > > It can be included in any error response (SERVFAIL, NXDOMAIN, > > REFUSED, etc) > > It can be argued that NODATA (pseudo rcode, I know) is an "error" as > well as NXDOMAIN... Or, neither of them are errors :-) Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Biscay: North 4 or 5 becoming variable 3 or 4. Moderate, occasionally rough at first in south. Fair. Good. From nobody Mon Nov 13 04:53:54 2017 Return-Path: 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 4D15612941C for ; Mon, 13 Nov 2017 04:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 faYisQXPtbhn for ; Mon, 13 Nov 2017 04:53:50 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00651292F4 for ; Mon, 13 Nov 2017 04:53:50 -0800 (PST) Received: from [42.61.209.129] (port=50209 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1eEEFH-0002L7-GG (Exim 4.72) for dnsop@ietf.org (return-path ); Mon, 13 Nov 2017 12:53:47 +0000 To: dnsop@ietf.org References: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> From: Ray Bellis Message-ID: Date: Mon, 13 Nov 2017 20:54:16 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 12:53:52 -0000 On 13/11/2017 19:01, Geoff Huston wrote: > errr - what would it mean if the rcode in the error code header differed > from the rcode value in the extended-error component? > > The issue with duplicated information in a packet is that you then have > add even further consideration to cope with the cases where the expected > thing did not happen. > > Not exactly blown away by #4 myself. Would it be feasible to reserve a standard RCODE value in the header that just means "see extended error"? It has always kinda surprised me that the EDNS RCODE didn't work that way, instead of the current situation where if you only read the bottom 4 bits of the extended 12-bit code you could completely misinterpret the status (e.g. treat BADVER[16] as NOERROR[0], since the bottom four bits are all zeros for both). Ray From nobody Mon Nov 13 05:13:26 2017 Return-Path: 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 41195129418 for ; Mon, 13 Nov 2017 05:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 qtzMHfJqY305 for ; Mon, 13 Nov 2017 05:13:24 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 CD4A8129576 for ; Mon, 13 Nov 2017 05:13:23 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:60051) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eEEYE-000pd3-0K (Exim 4.89) (return-path ); Mon, 13 Nov 2017 13:13:22 +0000 Date: Mon, 13 Nov 2017 13:13:22 +0000 From: Tony Finch To: Ray Bellis cc: dnsop@ietf.org In-Reply-To: Message-ID: References: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 13:13:25 -0000 Ray Bellis wrote: > > Would it be feasible to reserve a standard RCODE value in the header > that just means "see extended error"? That would require client-to-server signalling, and the server would be unable to simply unconditionally include the extended error in the OPT record. > It has always kinda surprised me that the EDNS RCODE didn't work that > way, instead of the current situation where if you only read the bottom > 4 bits of the extended 12-bit code you could completely misinterpret the > status (e.g. treat BADVER[16] as NOERROR[0], since the bottom four bits > are all zeros for both). There can only be an EDNS RCODE if the client sent an EDNS OPT; if the client forgot it sent the OPT then it's too broken to worry about. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode South Utsire: Northwesterly, backing southerly for a time, 5 to 7, decreasing 4 for a time. Moderate or rough. Rain for a time. Good, occasionally poor. From nobody Mon Nov 13 05:17:11 2017 Return-Path: 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 30A591242EA for ; Mon, 13 Nov 2017 05:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 g99pI6eXQIg7 for ; Mon, 13 Nov 2017 05:17:04 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A0112025C for ; Mon, 13 Nov 2017 05:17:04 -0800 (PST) Received: from [42.61.209.129] (port=50823 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1eEEbl-0003AR-6v (Exim 4.72) (return-path ); Mon, 13 Nov 2017 13:17:01 +0000 To: Tony Finch Cc: dnsop@ietf.org References: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> From: Ray Bellis Message-ID: <0473f775-e46f-af21-7b72-fb7997914cbc@bellis.me.uk> Date: Mon, 13 Nov 2017 21:16:57 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 13:17:10 -0000 On 13/11/2017 21:13, Tony Finch wrote: > Ray Bellis wrote: >> >> Would it be feasible to reserve a standard RCODE value in the >> header that just means "see extended error"? > > That would require client-to-server signalling, It would. Perhaps the *request* RCODE could contain the same value to signal acceptance of the extended version in the response ? > and the server would be unable to simply unconditionally include the > extended error in the OPT record. > > There can only be an EDNS RCODE if the client sent an EDNS OPT; if > the client forgot it sent the OPT then it's too broken to worry > about. Indeed - unsolicited EDNS OPT RRs aren't legal in responses. Ray From nobody Mon Nov 13 06:49:05 2017 Return-Path: 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 49C62127B52 for ; Mon, 13 Nov 2017 06:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 rBPsY2aPh6Fj for ; Mon, 13 Nov 2017 06:49:02 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8D6124D37 for ; Mon, 13 Nov 2017 06:49:02 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id o7so12809538pgc.4 for ; Mon, 13 Nov 2017 06:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eLqILnHEreHQ3G6/n3riWPlGG3HWMA+UMpDnQUSRC+M=; b=S7WRTNfvQ9ynfHG0YaUPNvQ5fNHjerLS2HXQTSOk1gMZ2Z+Ieg8PlTaXO//kE9YsJV BeIre1H3M7DsstGlcRP1Vy7/eaRnK6khMmYXKpAZZ9kN676z9GIcQEJp867FCnYbtMQp 4zvHUBKz63DVNgO2gMOzk51cQPoF+8ORxfs1q9r5Hb12eVq7ofP+saNX0ecAcgSshJH3 RtjDpSZmSPze7gBBFps5b2VQopADJh1jD+wBa45kaU3OJenAs+jZWVU/NSfWx15im1tz k53dzRL6G3ZgDfZQyFmhjDZH+Eqh4CHmjynLoucMJblvasXjdHw+Mrg84tQr0IT1EK6D yE6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eLqILnHEreHQ3G6/n3riWPlGG3HWMA+UMpDnQUSRC+M=; b=GZ3tkDMGbx2Pi9tr1k1SvRdaxn2/SWuBM8OJqBQ9E291wmZpUOUfG/9t13iBourXgI i5Y0W0LpWMTqsJ154Jsu5KNHCyfmyq8a5pF9ED43xlCCf52QIreEBLUzU+e0JepvVHok iCEG+Bp/u7FzpmEaXGg8RgAie0FrRUsUTU104xzc8xjI6gxD8pzbb9YyB1KmxfzQWvSo dm/IdXCvjG0WkOvNqDpGNp9I/u3y4eLDe2POJjwdjyIgHUGs9D0XKgDzlHWGa8UDT5+3 6un+ZQlwyUcuGfA+YkScKq1FpBz/srnyozOlJt/b732jiBzYr+cuxXTXsvWXbGt4QyC6 SEPA== X-Gm-Message-State: AJaThX5P0/ksfxBe/Ail/VRpy8fOxJgrFkR/7W5/sPi/JJzMsI894slO cTO2gFRKbub2C8vu9K8tc4ebYhqPQkhcGoh4f+RwkiEb X-Google-Smtp-Source: AGs4zMZw7cottU9+RP3A3ep/A3TuhEXM/DjAOpHv2Zwt57xZxvAytbV4ae6WsQs3OMiNffaKCE00S1+cBFz4uLp/Kd8= X-Received: by 10.98.19.202 with SMTP id 71mr8989825pft.181.1510584541485; Mon, 13 Nov 2017 06:49:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.130.4 with HTTP; Mon, 13 Nov 2017 06:49:00 -0800 (PST) In-Reply-To: <151056430694.21354.9434073937927132106.idtracker@ietfa.amsl.com> References: <151056430694.21354.9434073937927132106.idtracker@ietfa.amsl.com> From: Bob Harold Date: Mon, 13 Nov 2017 09:49:00 -0500 Message-ID: To: IETF DNSOP WG Cc: draft-huston-kskroll-sentinel@ietf.org Content-Type: multipart/alternative; boundary="001a11459990ffbbd4055dde5e70" Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-huston-kskroll-sentinel in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 14:49:04 -0000 --001a11459990ffbbd4055dde5e70 Content-Type: text/plain; charset="UTF-8" At the end of section 4 it says: "or a case of mixed signals (SERVFAIL in all three responses), which is similarly an indeterminate response" But I think that maybe this case tells us that at least one of the resolvers is Vold, and we could count this answer as Vold. Would that work? -- Bob Harold --001a11459990ffbbd4055dde5e70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At the end of section 4 it says:
=C2=A0 =C2=A0 "or a case
=C2= =A0 =C2=A0of mixed signals (SERVFAIL in all three responses), which is
=C2=A0 =C2=A0similarly an indeterminate res= ponse"

But I think that maybe this case tells us that at least one o= f the resolvers is Vold, and we could count this answer as Vold.=C2=A0 Woul= d that work?

--=C2=A0
Bob Harold

--001a11459990ffbbd4055dde5e70-- From nobody Mon Nov 13 06:52:40 2017 Return-Path: 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 DA523129417 for ; Mon, 13 Nov 2017 06:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 zk_RSaqaE_8n for ; Mon, 13 Nov 2017 06:52:36 -0800 (PST) Received: from aharp.iorc.depaul.edu (aharp.iorc.depaul.edu [IPv6:2620:0:2250:2115:c0a7:18f5:bca1:ba92]) by ietfa.amsl.com (Postfix) with ESMTP id 6D03A1289B5 for ; Mon, 13 Nov 2017 06:52:36 -0800 (PST) Received: from p50.localdomain (localhost [127.0.0.1]) by aharp.iorc.depaul.edu (Postfix) with ESMTP id 6F69A1D84; Mon, 13 Nov 2017 14:52:35 +0000 (UTC) Date: Mon, 13 Nov 2017 08:52:35 -0600 From: John Kristoff To: Andrew Sullivan Cc: "dnsop@ietf.org" Message-ID: <20171113085235.2fddd72a@p50.localdomain> In-Reply-To: References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> Reply-To: jtk@aharp.iorc.depaul.edu X-Trump: Sucks MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 14:52:38 -0000 On Mon, 13 Nov 2017 03:26:41 +0000 Andrew Sullivan wrote: > This is quite a helpful response, thanks. I wonder whether more of it > ought to go in discussion (or a new draft), I'd suggest a new draft be produced with which discussion could ensue. The references Paul cites would not be clear to me that closer excludes pointing up towards the root for instance. In fact, I would have thought this is precisely what closer would mean from a pure graph/routing perspective in certain scenarios. REFUSED does not seem ideal to me either, but what if anything might be better is probably ripe discussion in a new draft. Paul, are you willing and able to work on a draft for this? For what it's worth I'd be supportive of that work. John From nobody Mon Nov 13 06:53:43 2017 Return-Path: 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 6FDF7129744 for ; Mon, 13 Nov 2017 06:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 h7eXAEzsWE7P for ; Mon, 13 Nov 2017 06:53:41 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A3E127B52 for ; Mon, 13 Nov 2017 06:53:41 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 13 Nov 2017 06:53:39 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Mon, 13 Nov 2017 06:53:39 -0800 From: Edward Lewis To: Andrew Sullivan , "dnsop@ietf.org" Thread-Topic: [Ext] Re: [DNSOP] Clarifying referrals (#35) Thread-Index: AQHTW7jgL05NzMUFqUGI7Uu05JFbo6MSEKIAgAAFZwCAAAD7gIAACbEAgAAMZ4CAAL/uAA== Date: Mon, 13 Nov 2017 14:53:38 +0000 Message-ID: References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> In-Reply-To: <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3593411618_464944154" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 14:53:42 -0000 --B_3593411618_464944154 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit At the tail of this thread, I'll add my (random) thoughts. 1) Upward referrals are an example of something that started out as a good idea, good intention, but ran into operational problems as the DNS setting changed. Early, in the late 90's, a popular DNS implementation would chase an upward referral meant to indicate a lame delegation, resulting in an infinite loop in iteration. (Better coding stopped that. See also ARIN Policy [proposal] 2002-01 as an artifact of that time.) Later, upward referrals were seen as a tool in building a flood attack, which is what cause implementations to stop using them as lame delegation notices. 2) I learned this long ago (while implementing ancient DNSSEC code) - the DNS tree is inherently unidirectional. A parent knows about its children and not vice versa. DNSSEC wanted to have arbitrary security chains but had to settle for on-tree ("Domain Name System Security (DNSSEC) Signing Authority" aka RFC 3008). The same issue came into play when trying to design the "Automating DNSSEC Delegation Trust Maintenance" - related to scaling (the parent has to poll the children, not the other way around). (In "Detecting a Changed CDS/CDNSKEY", the parent either polls or has to have something out-of-DNS-band: " The delegation user interface has a button".) I.e., trying to see referrals as going anyway but down is an uphill battle. --B_3593411618_464944154 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTlY4tCIop4KBQRRbzJcnB8gwYBjzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMTMxNDUzMzhaMA0GCSqGSIb3 DQEBAQUABIIBADh7pLeXM2DkCenO2aCFsneTjNkZ4fNtZkDAf3j6Xd6UvdMW3cWfXIpmAJtB CMhvMftQ2ldJz5+oW/rS748XGISJK4pHVk2sjlT/ReQGrgzFXeZB6tJrfKMtkwiYrc4VFg1a MBdWKguuYealPIYcyFxkitSEnbc1ka59frI57YhO42R6dzRSqIvTKCibhL/iOGr+0kmlZSsm SGMSVWJPb78cYimeeH7Wp1lFO9y7Jg5cIZ96XggOWCRhLJXzUlUWDrD2adUJa4qoGNgwnbp1 e9SScuzncnbCp50pIyqTCwHDkVUAS7eTY8eP6kT9rlJO6pggeSyMizdu8Bq1Zwlwhrs= --B_3593411618_464944154-- From nobody Mon Nov 13 07:19:29 2017 Return-Path: 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 4ED55129459 for ; Mon, 13 Nov 2017 07:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 zgNA5CJyCBTg for ; Mon, 13 Nov 2017 07:19:26 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 A1487129454 for ; Mon, 13 Nov 2017 07:19:26 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:34863) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eEGWC-000kjr-1O (Exim 4.89) (return-path ); Mon, 13 Nov 2017 15:19:24 +0000 Date: Mon, 13 Nov 2017 15:19:23 +0000 From: Tony Finch To: Edward Lewis cc: "dnsop@ietf.org" In-Reply-To: Message-ID: References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 15:19:28 -0000 Edward Lewis wrote: > > The same issue came into play when trying to design the "Automating > DNSSEC Delegation Trust Maintenance" - related to scaling (the parent > has to poll the children, not the other way around). (In "Detecting a > Changed CDS/CDNSKEY", the parent either polls or has to have something > out-of-DNS-band: " The delegation user interface has a button".) Funny you should mention that - I have been thinking about it. One of the most common reactions I have seen to RFC 7344 is the scaling issue (though you need to be over a million signed delegations before it gets seriously problematic, I guess). It seems to me that a reasonable in-band mechanism would be to send a NOTIFY to the parental agent. I can only find a little discussion of this idea in 2014, and it wasn't very enthusiastic - there were questions like, how do you know where to send the NOTIFY? On the other hand there are similar questions about how you would make an out-of-band request. (From my point of view, adding some also-notify configurations would be a lot easier than implementing draft-latour-dnsoperator-to-rrr-protocol!) Dunno if this is worth pursuing ... Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode South Fitzroy: Northeasterly 4 or 5, occasionally 6 in east. Moderate or rough. Fair. Good. From nobody Mon Nov 13 07:28:51 2017 Return-Path: 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 51B78129AC1 for ; Mon, 13 Nov 2017 07:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 1PcmB8uZT8yd for ; Mon, 13 Nov 2017 07:28:39 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9AB0129AF1 for ; Mon, 13 Nov 2017 07:28:39 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id o7so12894237pgc.4 for ; Mon, 13 Nov 2017 07:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SZVXsBUTOvNqrStO6k62UwdH+s6oKUQ6GeNRhJq9jds=; b=hncPqaPz0quy+DxSp3GqA7U855+8b3/UGbbCbjbLnWJ1nMoD4EQGNPFXR4BYeHLpBC /Rk4I5fqK7sLeaxLHvypPipO0XnpBaciIeqz8gLnrX+bmqj+z9IQcRXQOt5doP3qEcCf USCpgfQPykmGh6l5iXRhBC/0jbKzxOQ311XPFEwvcx3dITXqIgFgAadRuc3YSl+3B82D SzJApOcFV2VPgGtP9cmMVLl85ZP+u9fgVNK2OZhvoPdKXazAjpi6X6PL8sq5vlO6oTRU TwbeoIWAgyRMFQGQ3xPgdJo29K26abGCXEJXPdCxFlw2mcAfpSQ9ohhHnkSYwl8kk2Qy AmTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SZVXsBUTOvNqrStO6k62UwdH+s6oKUQ6GeNRhJq9jds=; b=Z8wGDu6IeICErWpZQ0To1+skMVkpRl6oyN2C30N8lzUH4cmt/woXqpd6Ee0n0Sw6ol rVL6lHTl0F2JM/nR1FB94/D8pC0FEb0YuM9rNUkSHfmMbHF8JinfBmgWCxtdziKvwMh0 sn8xbU84/lP2CtlhhIP2Fw+QUY1wEI+4XSsqENpYVvmCC7epeWMZOFynkdO1uMW5ROpz abrHgzlv48YUI+lS3v82EYi75MPzSBoM5sDJRR3SXOlNJDc16gfRZ/bZ4J5kB7KJB8uh Yx7xi7FVRLQDtBes6qXugArOneSnQnjjHug+oyJMTBnXNOO98cpEwYES1isk7toCUzZL PwGg== X-Gm-Message-State: AJaThX4vX59Mdsa7jMO/C7MHrInUHXCgULNhJBIXaogndxiXUGrWKF0r 17ue3ANNlLjCenWJlA4guzyXpJzcyjrH/nrZUVopfg== X-Google-Smtp-Source: AGs4zMZKqAvfWGWGWmsgM/mkBq8r+03Ws/4rozhrKKs8o1zHVnKxuxkM61J1ezyZady2t6eGBAqzVDVNniBzVUHHNUU= X-Received: by 10.159.218.148 with SMTP id w20mr9654734plp.398.1510586919198; Mon, 13 Nov 2017 07:28:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.130.4 with HTTP; Mon, 13 Nov 2017 07:28:38 -0800 (PST) In-Reply-To: <151056426921.21486.1491076825222186071.idtracker@ietfa.amsl.com> References: <151056426921.21486.1491076825222186071.idtracker@ietfa.amsl.com> From: Bob Harold Date: Mon, 13 Nov 2017 10:28:38 -0500 Message-ID: To: IETF Secretariat Cc: IETF DNSOP WG , dnsop-chairs@ietf.org, draft-dupont-dnsop-rfc2845bis@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1e6234b8b451055ddeec11" Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-dupont-dnsop-rfc2845bis in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 15:28:45 -0000 --94eb2c1e6234b8b451055ddeec11 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 13, 2017 at 4:11 AM, IETF Secretariat < ietf-secretariat-reply@ietf.org> wrote: > > The DNSOP WG has placed draft-dupont-dnsop-rfc2845bis in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-dupont-dnsop-rfc2845bis/ > Some minor wording suggestions: The last paragraph of 1. Introduction " Since the publication of first version of this document ([RFC2845]) a mechanism based on asymmetric signatures using the SIG RR was specified (SIG(0) [RFC2931]) when this document uses symmetric authentication codes calculated by HMAC [RFC2104] using strong hash functions." I think "when" should be "where" (or "whereas"). In 4.3. TSIG Record Format "its name actually only need only be meaningful to them" Remove the first 'only' -- Bob Harold --94eb2c1e6234b8b451055ddeec11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Mon, Nov 13, 2017 at 4:11 AM, IETF Secretariat <ietf-secr= etariat-reply@ietf.org> wrote:

The DNSOP WG has placed draft-dupont-dnsop-rfc2845bis in state
Candidate for WG Adoption (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc= /draft-dupont-dnsop-rfc2845bis/

Some minor wordin= g suggestions:

The last paragraph of 1.=C2=A0 Introduction

"=C2=A0 =C2=A0Since= the publication of first version of this document ([RFC2845]) a
=C2=A0 =C2=A0mechanism based on asymmetric signatures= using the SIG RR was
=C2=A0 =C2=A0specifie= d (SIG(0) [RFC2931]) when this document uses symmetric
=C2=A0 =C2=A0authentication codes calculated by HMAC [RFC2104] = using strong hash
=C2=A0 =C2=A0functions.&q= uot;

I= think "when" should be "where" (or "whereas"= ).

In= =C2=A04.3.=C2=A0 TSIG Record Format

"its name actually only need only
<= div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be meaningful t= o them"

Remove the first 'only'

=
--=C2=A0
B= ob Harold


--94eb2c1e6234b8b451055ddeec11-- From nobody Mon Nov 13 07:45:41 2017 Return-Path: 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 60B371205F1 for ; Mon, 13 Nov 2017 07:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVzfnRpQPKDI for ; Mon, 13 Nov 2017 07:45:34 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76FB1242F7 for ; Mon, 13 Nov 2017 07:45:32 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 13 Nov 2017 07:45:30 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Mon, 13 Nov 2017 07:45:30 -0800 From: Edward Lewis To: Evan Hunt , =?utf-8?B?UGV0ciDFoHBhxI1law==?= CC: "dnsop@ietf.org" Thread-Topic: [Ext] Re: [DNSOP] Configured Trust Anchor vs. DS record Thread-Index: AQHTWWiXPRp7CRP4/kG/0ZKc0dRV56MMpuMAgAAyMoCABicTAA== Date: Mon, 13 Nov 2017 15:45:30 +0000 Message-ID: <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org> References: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> <20171109174804.GA63012@isc.org> In-Reply-To: <20171109174804.GA63012@isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3593414730_1453672502" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 15:45:37 -0000 --B_3593414730_1453672502 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 11/9/17, 12:48, "DNSOP on behalf of Evan Hunt" wrote: > On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr =C5=A0pa=C4=8Dek wrote: > > Nice write-up Edward! You have nicely summarized why Mark and me agr= ee > > that validator should use longest suffix match when selecting TA to > > validate data. > =20 > +1. Hmmm, that wasn't my intent. ;) I had been trying to justify the other con= clusion. But, if my work is leading you towards this "other" conclusion, I'= ve been taking time to understand why. I'm beginning to have a new understanding on this. The overlooked (by me) = point is that we are focusing on a situation where the local operator has ch= osen to explicitly configure a trust anchor. Beside code distributions ship= ping with the IANA managed KSK (or its DS form) for the global public Intern= et's root zone, if any operator wants another trust anchor point, they have = to take explicit action to configure it. The question is - what is the expe= ctation of the operator in doing this? There was a time when TLDs were signed but the root zone was not. Then ope= rators had to configure trust anchors for the TLDs to enable validation. Wh= en the root zone was signed in 2010, the TLDs had to remind all those with t= rust anchors to remove them (before the TLD could change it's KSK). I can n= o longer find reports of the efforts to undo TLD trust anchors (Sweden and m= aybe CzechRep?) that I thought were once floating around. "Fears" surroundi= ng this would lead one to favor the more open "any" policies, on the other h= and, mass migration from TLDs to root for the top of the trust chain was pro= bably a one-time event as a result of the on-set of DNSSEC in the root zone. I'm not sure that the need for robustness outweighs the expectation of some= one explicitly adding a trust anchor anymore. OTOH, in the sense "I am not sure" there's the example of split-DNS and poo= r query path management (i.e., leaks). I'm not sure if robustness helps her= e, or is a bad-behavior enabler. > > Things might get even more complicated when negative trust anchors a= re > > configured, bleh. > =20 > Fortuantely a negative trust anchor is a longest suffix match too. This is an emerging "thing" - more active awareness and management of the t= rust anchor element of a validator. --B_3593414730_1453672502 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSmHWregrm9b74CFkUZJ+iKWAQ1YDAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMTMxNTQ1MzBaMA0GCSqGSIb3 DQEBAQUABIIBAFQPCJC2CsC8M3kFCTWVCGBimZ8NNYO3vDJier4ofzRh/hHVyg7LrBFsVmQA TbRROp/kf1pM8NVE1QtDsrlqZ6xl0EAaYjGbcA1gjMIAl3tKZyLBCvuzv0ASkOAkkkKO5hHm muayFwiKGpncHH7o565arRpRqLNzM0ZZFbOySFU1dPK8EZFlVDHq0o9wsvuZix8mXXKFHB1G Z/Wxp/TK3YWq5Hsg5NSl+ahyIxXATnYi26um3vVSQJ252sJ9uz4mYatnDm/GpgDVqEM3Efun jOGMJYZxDDKa35uAbU+5+77+1zqsdFq2+CPQ2pnZL9fQn62pZ2WvxnVdY4Pw6952T88= --B_3593414730_1453672502-- From nobody Mon Nov 13 08:14:19 2017 Return-Path: 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 D5B0C129B06 for ; Mon, 13 Nov 2017 08:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 g648ajgE2mX3 for ; Mon, 13 Nov 2017 08:14:15 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54DE5120454 for ; Mon, 13 Nov 2017 08:14:15 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 6D0B361FA2; Mon, 13 Nov 2017 16:14:14 +0000 (UTC) Message-ID: <5A09C4D6.6080202@redbarn.org> Date: Mon, 13 Nov 2017 08:14:14 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Andrew Sullivan CC: dnsop@ietf.org References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> In-Reply-To: <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 16:14:17 -0000 Andrew Sullivan wrote: > Hi, > > This is quite a helpful response, thanks. I wonder whether more of it > ought to go in discussion (or a new draft), however. i probably should not be involved in a new draft other than as a reviewer. (consider the fate of resimprove.) > For I'm struck > by this: > > On Sun, Nov 12, 2017 at 06:42:18PM -0800, Paul Vixie wrote: >>> always be generated using only local data, and either contains the >>> answer to the question or a referral to other name servers "closer" to >>> the desired information. >> the operative phrase is '"closer" to'. this is repeated in 4.3.1: > > If I ask the authoritative server for example.com about a name > label.example.net, in a graph-theoretic sense the NS RRset for the > root zone is clearly closer to label.example.net than anything else I > can give. dns is not that kind of graph. if the qname is acetes.pa.dec.com and the query is being processed by the dec.com authority server who knows that pa.dec.com is a delegation, then pa.dec.com is closer to acetes.pa.dec.com than the root would be. > The current approaches that people have for this are either NODATA > responses and REFUSED. Only the latter seems obviously consistent > with the text, though I'm aware that there's controversy over using > REFUSED here. as i wrote during the SOPA wars, REFUSED has been widely used as an administrative denial, and repurposing it would not be effective at this late date. see: http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/ -- P Vixie From nobody Mon Nov 13 08:28:19 2017 Return-Path: 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 0C018129B10 for ; Mon, 13 Nov 2017 08:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Smf8TvUSiPqU for ; Mon, 13 Nov 2017 08:28:13 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FB2129B0E for ; Mon, 13 Nov 2017 08:28:13 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id DC86C61FA2; Mon, 13 Nov 2017 16:28:12 +0000 (UTC) Message-ID: <5A09C81C.4080905@redbarn.org> Date: Mon, 13 Nov 2017 08:28:12 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: jtk@aharp.iorc.depaul.edu CC: Andrew Sullivan , "dnsop@ietf.org" References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113085235.2fddd72a@p50.localdomain> In-Reply-To: <20171113085235.2fddd72a@p50.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 16:28:14 -0000 John Kristoff wrote: > ... > > Paul, are you willing and able to work on a draft for this? For what > it's worth I'd be supportive of that work. my drafting skills seem to be gone. nothing i've written in the last ten years was adopted. i think it would be better for me to review and to provide text, than to be named as an author or even co-author. -- P Vixie From nobody Mon Nov 13 10:30:12 2017 Return-Path: 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 9DA43129B30 for ; Mon, 13 Nov 2017 10:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 oZXAkxhVenNu for ; Mon, 13 Nov 2017 10:30:08 -0800 (PST) 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 7609012944F for ; Mon, 13 Nov 2017 10:30:08 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 1B6D43B0102; Mon, 13 Nov 2017 18:30:05 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id C1194216C1C; Mon, 13 Nov 2017 18:30:04 +0000 (UTC) Date: Mon, 13 Nov 2017 18:30:04 +0000 From: Evan Hunt To: Tony Finch Cc: Edward Lewis , "dnsop@ietf.org" Message-ID: <20171113183004.GA35038@isc.org> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 18:30:10 -0000 On Mon, Nov 13, 2017 at 03:19:23PM +0000, Tony Finch wrote: > It seems to me that a reasonable in-band mechanism would be to send a > NOTIFY to the parental agent. I can only find a little discussion of this > idea in 2014, and it wasn't very enthusiastic - there were questions like, > how do you know where to send the NOTIFY? On the other hand there are > similar questions about how you would make an out-of-band request. Mark's idea to push updates to the parent instead of relying on polling used a SRV query to identify the correct recipient of an UPDATE: https://tools.ietf.org/html/draft-andrews-dnsop-update-parent-zones-04 The same trick could be used to find the right NOTIFY target. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Mon Nov 13 10:37:27 2017 Return-Path: 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 D5774129ACD for ; Mon, 13 Nov 2017 10:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com 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 AdGvWbydYOMr for ; Mon, 13 Nov 2017 10:37:24 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D52B124BAC for ; Mon, 13 Nov 2017 10:37:24 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id 189so21653492iow.10 for ; Mon, 13 Nov 2017 10:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wq9jYjYbaQViDuOIwDUeeKhEVSKTCz8qVoOTiR9puHY=; b=zL2z5QYmVUL1USAmDUxHpUYBs8hRdcORxDWuRaxkubx3ucMmPc2mTVc+ScfhGdGlTM P0qRypJ75q8aeZcx8T9ihZlMXZOqfZHc9WuY+fu3SWDxhJO7JOj63Y63lHmKdP+Ucfkt LTuGqYCuUK1wa16GK13ccagNaBGi30IHcOawKfghIHjK8+hQvDwKC8lRzkWFqM092Yn4 e4+KlqzFmQg0NjUhHvxYGWIrM6cZx8ZryMDdpZscd5CZCtoj4fGtBz9Pg6TMkSqBIILb uvF28wL9OZxgKOsPTqOtO7emKTjmxrSnvCwkvvjsPD4PmhOtxGQLHVwfljEIgoWxZOXp spIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wq9jYjYbaQViDuOIwDUeeKhEVSKTCz8qVoOTiR9puHY=; b=tNzj5i/G6laOfA3XNzIsOimz6O1zKQs37qpIxnbmFnBZY//RhRjnYEGHWPnnrLS6AU wNp2QZdlsCyK24cIZHozq/kJWKGAiHpMxfP8t0wdgN/PuyVMqOasRAgx4yM1R+kj5Zwr 4oUJij1QDvFpBKLwmwQp7Jhll6r4+8qLPUrL30g+qnUkbCl5TKxNnlya12pW64Rii+uA pHlkNd1aLlfDdX05iXESI7q6gmg80GWFWr5v+vIZ/udxweDINV3TpJ2ZRsY82iLMo5CP rM9JtX4524HW8nGzO70vdilJL3iJdEOGJ6s9u1r47LYh4CxhszQQFvBvh1wk0YFNxjeK AR4Q== X-Gm-Message-State: AJaThX5f/EdY3n3mvQRm14dcSCpet9nuGEfaAbE8FEm0TN8+WXuXrxPU A2wny5CjjWr5cxYKMW9kSjz8+ZIDhWVY4eTi7ZoSf7HG X-Google-Smtp-Source: AGs4zMaSRIyHhzJq3C63ooLLyGjSN2l3QpPTFZ8zW5fvIfybVR4o/cGxit/eVWBsfSrJsHWoAW/hmR3S5Ha+88w8LpA= X-Received: by 10.107.170.153 with SMTP id g25mr7419901ioj.207.1510598243095; Mon, 13 Nov 2017 10:37:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.11.196 with HTTP; Mon, 13 Nov 2017 10:37:22 -0800 (PST) In-Reply-To: <20171113085235.2fddd72a@p50.localdomain> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113085235.2fddd72a@p50.localdomain> From: Matthew Pounsett Date: Mon, 13 Nov 2017 10:37:22 -0800 Message-ID: To: jtk@aharp.iorc.depaul.edu Cc: Andrew Sullivan , "dnsop@ietf.org" Content-Type: multipart/alternative; boundary="001a1142ef84adaa51055de18fbc" Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 18:37:26 -0000 --001a1142ef84adaa51055de18fbc Content-Type: text/plain; charset="UTF-8" On 13 November 2017 at 06:52, John Kristoff wrote: > REFUSED does not seem ideal to me either, but what if anything might be > better is probably ripe discussion in a new draft. > > It makes perfect sense to me. REFUSED is an indication that the querier has been blocked from asking that question (or receiving the answer they requested) by configuration, as distinct from a broken configuration preventing them from getting that answer (SERVFAIL). Given that upward referrals have obvious problems (There is no protocol or process to tell a TLD operator "I am not authoritative for that delegation someone else asked you to point at me") it seems to me that REFUSED is the only obvious choice for indicating that an authoritative-only server is not authoritative for anything at or below the QNAME. --001a1142ef84adaa51055de18fbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 13 November 2017 at 06:52, John Kristoff <jtk@depaul.edu> wrote:
REFUSED does not seem ideal to m= e either, but what if anything might be
better is probably ripe discussion in a new draft.

It makes perfect sense to me.=C2=A0 REFUSED is an indication that the quer= ier has been blocked from asking that question (or receiving the answer the= y requested) by configuration, as distinct from a broken configuration prev= enting them from getting that answer (SERVFAIL).=C2=A0 =C2=A0Given that upw= ard referrals have obvious problems (There is no protocol or process to tel= l a TLD operator "I am not authoritative for that delegation someone e= lse asked you to point at me") it seems to me that REFUSED is the only= obvious choice for indicating that an authoritative-only server is not aut= horitative for anything at or below the QNAME.=C2=A0 =C2=A0


--001a1142ef84adaa51055de18fbc-- From nobody Mon Nov 13 10:45:48 2017 Return-Path: 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 8EB16129B43 for ; Mon, 13 Nov 2017 10:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eXs8r_JwLsl for ; Mon, 13 Nov 2017 10:45:45 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3310B129B38 for ; Mon, 13 Nov 2017 10:45:45 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 13 Nov 2017 10:45:43 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Mon, 13 Nov 2017 10:45:43 -0800 From: Edward Lewis To: Evan Hunt , Tony Finch CC: "dnsop@ietf.org" Thread-Topic: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35) Thread-Index: AQHTXJLPNUyUqySGDEiQ+i+aqTCpNKMTJ88AgAAEXgA= Date: Mon, 13 Nov 2017 18:45:42 +0000 Message-ID: <436111CF-FCA8-44A2-B83D-6540DE6D64AC@icann.org> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <20171113183004.GA35038@isc.org> In-Reply-To: <20171113183004.GA35038@isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3593425542_1874074950" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 18:45:46 -0000 --B_3593425542_1874074950 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 11/13/17, 13:30, "DNSOP on behalf of Evan Hunt" wrote: >Mark's idea to push updates to the parent instead of relying on polling used a SRV query to identify the correct recipient of an UPDATE: > > ...draft-andrews-dnsop-update-parent-zones-04... This would mean then signing all the SRV sets, so I assume to preserve the benefits of "OPTOUT", you'd want these only for the names that had DS sets. For the others, I assume either no answer or the wildcard ... in the TLD. (That latter thought might be unsettling to some people.) What I mean is that there is still a scaling problem, in some dimension, to deal with because the DNS is inherently a "down-only" tree. --B_3593425542_1874074950 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTuCzLNTu6nvQb/ADtuQlU98Dt7BDAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMTMxODQ1NDJaMA0GCSqGSIb3 DQEBAQUABIIBAKNYguLN5WstFKCzt3LIE2hx35OXo3hR9ranNrPpc3LcbEJKyYuMeN6ewomd 9cdqfSTs9TcjWi8GqnCTW91k9lSoYGVw5cFYqX8McNiAyNROrmxFfwmWA2K0iATA5pRHqWA7 3G4w+ysvevLfyjKaV0Pxsu3pRysKBaoB6SILGbm0+O0DXhz8WxUbHSM0ZVjNfVZvNiQcZACQ L08Sh0i3KkTvJuSj1GAVW0H3Z7Fn+TsNtFzOnMX76If8I80VgfF7e8f9vUZeDw7vPNlgZk8a XLaMd+gxTvw/Q47u96M2OXv1N+Xg6PuH4eUgSTWsB3L52NQRaFFSD3mIx57tOaLsu6E= --B_3593425542_1874074950-- From nobody Mon Nov 13 10:53:24 2017 Return-Path: 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 A8650129B2C for ; Mon, 13 Nov 2017 10:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 EHsbwcfksU9j for ; Mon, 13 Nov 2017 10:53:21 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE5B129B06 for ; Mon, 13 Nov 2017 10:53:21 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 434B761FA2; Mon, 13 Nov 2017 18:53:21 +0000 (UTC) Message-ID: <5A09EA20.80507@redbarn.org> Date: Mon, 13 Nov 2017 10:53:20 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Evan Hunt CC: Tony Finch , Edward Lewis , "dnsop@ietf.org" References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <20171113183004.GA35038@isc.org> In-Reply-To: <20171113183004.GA35038@isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 18:53:23 -0000 Evan Hunt wrote: > ... > > Mark's idea to push updates to the parent instead of relying on polling > used a SRV query to identify the correct recipient of an UPDATE: > > https://tools.ietf.org/html/draft-andrews-dnsop-update-parent-zones-04 > > The same trick could be used to find the right NOTIFY target. +1. -- P Vixie From nobody Mon Nov 13 10:55:38 2017 Return-Path: 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 4FB01129B50 for ; Mon, 13 Nov 2017 10:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 nYMheXHVw0Uz for ; Mon, 13 Nov 2017 10:55:35 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA43D129B06 for ; Mon, 13 Nov 2017 10:55:34 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id D0EB061FA2; Mon, 13 Nov 2017 18:55:34 +0000 (UTC) Message-ID: <5A09EAA6.5010305@redbarn.org> Date: Mon, 13 Nov 2017 10:55:34 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Matthew Pounsett CC: jtk@aharp.iorc.depaul.edu, "dnsop@ietf.org" , Andrew Sullivan References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113085235.2fddd72a@p50.localdomain> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 18:55:36 -0000 Matthew Pounsett wrote: > > > On 13 November 2017 at 06:52, John Kristoff > wrote: > > REFUSED does not seem ideal to me either, but what if anything might be > better is probably ripe discussion in a new draft. > > It makes perfect sense to me. REFUSED is an indication that the querier > has been blocked from asking that question (or receiving the answer they > requested) by configuration, as distinct from a broken configuration > preventing them from getting that answer (SERVFAIL). why is this nor a broken configuration? > ... Given that upward > referrals have obvious problems (There is no protocol or process to tell > a TLD operator "I am not authoritative for that delegation someone else > asked you to point at me") it seems to me that REFUSED is the only > obvious choice for indicating that an authoritative-only server is not > authoritative for anything at or below the QNAME. i strongly disagree. this is not an administrative denial scenario. see, again: http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/ -- P Vixie From nobody Mon Nov 13 11:12:57 2017 Return-Path: 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 96A3C124C27 for ; Mon, 13 Nov 2017 11:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com 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 KD6WEErxUIgY for ; Mon, 13 Nov 2017 11:12:54 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C53120721 for ; Mon, 13 Nov 2017 11:12:54 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id w127so4381478iow.11 for ; Mon, 13 Nov 2017 11:12:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I+2Z5Ouer93RC2e+D7BZOuh6WKdMrIlCOzhLTFdOmo0=; b=XGZqEObEAxOB92pfH5ZoeRCA22MvbFOozbqrKdWXJ+5gMm67zM+OYRj11d7YGPamqk oh5N0Sza/dAdCfrAmbzBo153d0Hxv1n0cUUQm36MIYg00SuBWWJonAsM2QWBwQfB7Ydg wUOadckq4hCvXBqfU/b5dNiUw2m5poWUUQPYsggVT3fU43wigMnCKcy09otbwRDjKkAU sYfvdTsDLhAZYn9DzlXSDETo19M15XSIbgA22RBbmj/rFuOQSlv1MLVoiANqbDgTpXew xebOHHPdBcHkALHexVhNHUI+9kIiY3aSVJ5uk9MOHFkW23DQwkQq64yoD3FZxEoe2JTF hUxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I+2Z5Ouer93RC2e+D7BZOuh6WKdMrIlCOzhLTFdOmo0=; b=KH4dCdPnmI+AlGnd9LxMHOGduuInXElWO1o1p1p+iptKysBdBJpOHS32qDu6YxQG/e h0b25K6QhygzgISCPhGmKSjvXdg2UabtNmkJ+2cy3ICPZ9dQxxF8Bfn2NFmY4o8MMf9F wOS5x7nLlrcS0uI7++DgUMrHsjrjy4Ocou6NBTscE9d+GTPwZSlJ/CfFEwH/RhfeV86N Jo6WVjGYubvX5O22k0RjUq9q7gHB87jBVt30jWMUXDqD/x4qwelIv0oRSSOc4VURRkuE UTRECtx+hKUBY4q0T0g1UqYSiWAdTNYTOOIQ6rGp7NvRNjckM3nBqwVuQ532njgUX+wh NzGQ== X-Gm-Message-State: AJaThX69dyF/qJyZwN3k9d03W+uxNf4uTSC9akGzzux4CXJjd8Qil75o FbHtsDoDT+u9GcPu2tkgN8zQ5grPIeBu6L1lTPbbpw== X-Google-Smtp-Source: AGs4zMY5LzQ7aZ1rpTpsJj9qH6tLQg8BwSQTCGjJWoMTuAa9+Fyl7VmDhXHxW1IA9e0FaXDrTk4sa4bKPPhik+ubztg= X-Received: by 10.107.128.1 with SMTP id b1mr7751139iod.164.1510600373522; Mon, 13 Nov 2017 11:12:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.11.196 with HTTP; Mon, 13 Nov 2017 11:12:52 -0800 (PST) In-Reply-To: <5A09EAA6.5010305@redbarn.org> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113085235.2fddd72a@p50.localdomain> <5A09EAA6.5010305@redbarn.org> From: Matthew Pounsett Date: Mon, 13 Nov 2017 11:12:52 -0800 Message-ID: To: Paul Vixie Cc: jtk@aharp.iorc.depaul.edu, "dnsop@ietf.org" , Andrew Sullivan Content-Type: multipart/alternative; boundary="001a113f8fd0a96904055de20e0e" Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 19:12:56 -0000 --001a113f8fd0a96904055de20e0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 13 November 2017 at 10:55, Paul Vixie wrote: > > > Matthew Pounsett wrote: > >> >> >> On 13 November 2017 at 06:52, John Kristoff > > wrote: >> >> REFUSED does not seem ideal to me either, but what if anything might >> be >> better is probably ripe discussion in a new draft. >> >> It makes perfect sense to me. REFUSED is an indication that the querier >> has been blocked from asking that question (or receiving the answer they >> requested) by configuration, as distinct from a broken configuration >> preventing them from getting that answer (SERVFAIL). >> > > why is this nor a broken configuration? > It's my understanding that SERVFAIL indicates that the server sending the RCODE=E2=80=93or in the case of a recursive response, the upstream authorit= ative server=E2=80=93has a broken configuration. I don't believe SERVFAIL indica= tes "you followed a lame delegation." As far as I'm aware, we don't have a clearly defined signal for that, which is why many implementations chose to use REFUSED in that case. > > ... Given that upward >> referrals have obvious problems (There is no protocol or process to tell >> a TLD operator "I am not authoritative for that delegation someone else >> asked you to point at me") it seems to me that REFUSED is the only >> obvious choice for indicating that an authoritative-only server is not >> authoritative for anything at or below the QNAME. >> > > i strongly disagree. this is not an administrative denial scenario. see, > again: > > > http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/ > > I haven't got the time this morning to search release notes, but I'm fairly sure that in 2012, when you wrote that article, current versions of BIND were already handing out REFUSED to indicate "I'm not authoritative for that." At the very least it began doing that not long after. If that were a problem, given BIND's market share, we should be seeing widespread brokenness, but I don't think we are=E2=80=93none that's making it from my = support department to me or to our hostmaster@ accounts, at any rate. --001a113f8fd0a96904055de20e0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 13 November 2017 at 10:55, Paul Vixie <paul@redbarn.org> wrote:


Matthew Pounsett wrote:


On 13 November 2017 at 06:52, John Kristoff <jtk@depaul.edu
 <mailto:jtk@depaul.e= du>> wrote:

=C2=A0 =C2=A0 REFUSED does not seem ideal to me either, but what if anythin= g might be
=C2=A0 =C2=A0 better is probably ripe discussion in a new draft.

It makes perfect sense to me.=C2=A0 REFUSED is an indication that the queri= er
has been blocked from asking that question (or receiving the answer they requested) by configuration, as distinct from a broken configuration
preventing them from getting that answer (SERVFAIL).

why is this nor a broken configuration?

It's my understanding that SERVFAIL indicates that the server sending = the RCODE=E2=80=93or in the case of a recursive response, the upstream auth= oritative server=E2=80=93has a broken configuration.=C2=A0 I don't beli= eve SERVFAIL indicates "you followed a lame delegation."=C2=A0 As= far as I'm aware, we don't have a clearly defined signal for that,= which is why many implementations chose to use REFUSED in that case.
=
=C2=A0

... Given that upward
referrals have obvious problems (There is no protocol or process to tell a TLD operator "I am not authoritative for that delegation someone els= e
asked you to point at me") it seems to me that REFUSED is the only
obvious choice for indicating that an authoritative-only server is not
authoritative for anything at or below the QNAME.

i strongly disagree. this is not an administrative denial scenario. see, ag= ain:


http://www.circleid.com/posts/= 20120111_refusing_refused_for_sopa_pipa/


I haven't got the t= ime this morning to search release notes, but I'm fairly sure that in 2= 012, when you wrote that article, current versions of BIND were already han= ding out REFUSED to indicate "I'm not authoritative for that."= ;=C2=A0 At the very least it began doing that not long after.=C2=A0 =C2=A0I= f that were a problem, given BIND's market share, we should be seeing w= idespread brokenness, but I don't think we are=E2=80=93none that's = making it from my support department to me or to our hostmaster@ accounts, = at any rate.




--001a113f8fd0a96904055de20e0e-- From nobody Mon Nov 13 11:28:47 2017 Return-Path: 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 79D30129B06 for ; Mon, 13 Nov 2017 11:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 9tdJqS3bqMjw for ; Mon, 13 Nov 2017 11:28:45 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35353120721 for ; Mon, 13 Nov 2017 11:28:45 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 2A08361FA2; Mon, 13 Nov 2017 19:28:44 +0000 (UTC) Message-ID: <5A09F26B.40705@redbarn.org> Date: Mon, 13 Nov 2017 11:28:43 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Matthew Pounsett CC: jtk@aharp.iorc.depaul.edu, "dnsop@ietf.org" , Andrew Sullivan References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113085235.2fddd72a@p50.localdomain> <5A09EAA6.5010305@redbarn.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 19:28:46 -0000 Matthew Pounsett wrote: > > > On 13 November 2017 at 10:55, Paul Vixie > wrote: > > > why is this nor a broken configuration? > > > It's my understanding that SERVFAIL indicates that the server sending > the RCODEor in the case of a recursive response, the upstream > authoritative serverhas a broken configuration. I don't believe > SERVFAIL indicates "you followed a lame delegation." As far as I'm > aware, we don't have a clearly defined signal for that, which is why > many implementations chose to use REFUSED in that case. someone asking you an RD=0 question about a zone you're not authoritative for indicates a misconfiguration somewhere. this is what SERVFAIL is for, because at the signalling level, it tells the client that no possible query about that name can succeed, and it ought to stop sending questions like that to this server. it's no different in principle from "i'm out of disk space, so i can't fetch the zone, so even though i'm supposed to be a secondary, i can't do it right now." > > http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/ > > I haven't got the time this morning to search release notes, but I'm > fairly sure that in 2012, when you wrote that article, current versions > of BIND were already handing out REFUSED to indicate "I'm not > authoritative for that." At the very least it began doing that not long > after. the implication of REFUSED is that if someone else asked this question, we might be able to answer. so if BIND is doing what you say, it's wrong. > ... If that were a problem, given BIND's market share, we should be > seeing widespread brokenness, but I don't think we arenone that's > making it from my support department to me or to our hostmaster@ > accounts, at any rate. yikes! you remind me of the guy who said on nanog a few years back that since he wasn't seeing spoofed-source ddos attacks any more, we should all stop worrying about them. your lived experience can be cause for concern, but never for complacency. -- P Vixie From nobody Mon Nov 13 11:59:40 2017 Return-Path: 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 05B31129601 for ; Mon, 13 Nov 2017 11:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com 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 V8_-qBHwOgT5 for ; Mon, 13 Nov 2017 11:59:37 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2603F1241F3 for ; Mon, 13 Nov 2017 11:59:36 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id m191so7883385itg.1 for ; Mon, 13 Nov 2017 11:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JYk4zZ1ditQtnNHDa56sUbCiHMCGi+erTpffd/YfjGM=; b=QQE4lEFzMzykbbDT6yeUKPjcPLXQrMXOolqDiIW+83dy8Ycb9biXDEJFJfS2JC240K r7LvthRbgSAPEiViFTnbcMkF8zOnYgDLOsN+2RtYl8LZ7UJLJw0FaSubAC1BPPfLj3i/ yQbb0qbeHTmcSNXOOEzimXFAsaM/oJ1OUPMLKWgen8KK8cQr5UHcnCvNW0qZjetlru6p OTpfEByotpM1GncQ9eQQGSOgcjcht+bUHC5BSIJz5ilj9Vc8qf7Nhv66N5N6BDz+8oZx rEa+oMY+wwdq0L+wUDPUFx92Pqr3s2aOOtQYinqgV6e4dpISoE14JdYPHu5BoHDHdtfb l33w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JYk4zZ1ditQtnNHDa56sUbCiHMCGi+erTpffd/YfjGM=; b=pKhYJ3yR6MEF0DNk5xUpV1jgUPfaZCdMnwVADvt2Sff5E6a389Nv2wOUzPYFrN1mVA uSDJZg/fySJBcwpmB0D3L/ztco6QpgWhk9jANGgja6HfJcolQEH4GFnAjDO0Dg+qAZjg /rG0ga0/9HrYqOS2RDJYAYXXKWMOeZ3lXOP7IFqX5j5OiRS33nOKM09q6aA05vKUi6O4 Z5QPad99d7BQ0RnplCh8xbEoND54NbPQxXJ2fls3FEfQGnC8g6rSBGyWpoewEPPfPZ17 5gXhxGIkKEA/j2d/w3/ftV+POvzqjsjQIngfl0pVUy68jtXFTQ7ip537FdZi+qAtDMuy xllg== X-Gm-Message-State: AJaThX4Ju9kSVNPc5nzm5SGLkp0oevlqKi3aUXBsJyYtpaaNK2DTBcZv P/retHNspXQ0oVkng5K2S0vHk7DxMVg4Ah+gvlRMeyoyqxI= X-Google-Smtp-Source: AGs4zMapQglBa10bg8y/+HY4nTj10D6iKm03EFFqcYh5oFHzcG1C4HapWY/gq3vRh/VeCjwAnxs1BvqxD6SAGnh7PjY= X-Received: by 10.36.40.207 with SMTP id h198mr7199335ith.95.1510603176318; Mon, 13 Nov 2017 11:59:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.11.196 with HTTP; Mon, 13 Nov 2017 11:59:35 -0800 (PST) In-Reply-To: <5A09F26B.40705@redbarn.org> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113085235.2fddd72a@p50.localdomain> <5A09EAA6.5010305@redbarn.org> <5A09F26B.40705@redbarn.org> From: Matthew Pounsett Date: Mon, 13 Nov 2017 11:59:35 -0800 Message-ID: To: Paul Vixie Cc: jtk@aharp.iorc.depaul.edu, "dnsop@ietf.org" , Andrew Sullivan Content-Type: multipart/alternative; boundary="001a113f651cb8aad6055de2b501" Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 19:59:39 -0000 --001a113f651cb8aad6055de2b501 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 13 November 2017 at 11:28, Paul Vixie wrote: > > ... If that were a problem, given BIND's market share, we should be >> > seeing widespread brokenness, but I don't think we are=E2=80=93none that'= s >> making it from my support department to me or to our hostmaster@ >> accounts, at any rate. >> > > yikes! you remind me of the guy who said on nanog a few years back that > since he wasn't seeing spoofed-source ddos attacks any more, we should al= l > stop worrying about them. > your lived experience can be cause for concern, but never for complacency. I don't think that word means what you think it means. Lack of concern for a non-problem is not complacency. The rest of us still see spoofed-source DDoS attacks, and they're a frequent topic of discussion in the networking and DNS communities, so even someone who doesn't see them on their network should still be aware that they happen. I have seen no similar discussion of REFUSED-generated chaos in recursive servers. If someone is seeing such brokenness, they haven't brought it to dnsop@, or dns-operations@, or an OARC or NANOG meeting. If someone is seeing such brokenness, hopefully they'll speak up so that we can advise the authoritative implementations to change their behaviour again. I use the plural there deliberately. I referenced BIND above because that was the implementation I was most familiar with at the time the behaviour changed ... but it does seem to be the consensus among the authoritative implementors that REFUSED is the correct response. It wouldn't be the first time that a majority of implementations settled on a behaviour that didn't strictly follow the specification because it was necessary for good inter-operation. Perhaps someone who was present for an implementer's internal discussion about replacing upward referrals could comment on the reasoning, and what (if any) collaboration occurred between the authoritative and recursive implementations at the time. --001a113f651cb8aad6055de2b501 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 13 November 2017 at 11:28, Paul Vixie <paul@redbarn.org> wrote:

... If that were a problem, give= n BIND's market share, we should be
seeing widespread brokenness, but I don't think we are=E2=80=93none tha= t's
making it from my support department to me or to our hostmaster@
accounts, at any rate.

yikes! you remind me of the guy who said on nanog a few years back that sin= ce he wasn't seeing spoofed-source ddos attacks any more, we should all= stop worrying about them.

your live= d experience can be cause for concern, but never for complacency.

I don't think that word means what you th= ink it means.=C2=A0 Lack of concern for a non-problem is not complacency.= =C2=A0

The rest of us still see spoofed-sour= ce DDoS attacks, and they're a frequent topic of discussion in the netw= orking and DNS communities, so even someone who doesn't see them on the= ir network should still be aware that they happen.=C2=A0 I have seen no sim= ilar discussion of REFUSED-generated chaos in recursive servers.=C2=A0 =C2= =A0If someone is seeing such brokenness, they haven't brought it to dns= op@, or dns-operations@, or an OARC or NANOG meeting.=C2=A0 If someone is s= eeing such brokenness, hopefully they'll speak up so that we can advise= the authoritative implementations to change their behaviour again.

I use the plural there deliberately.=C2=A0 I referenced B= IND above because that was the implementation I was most familiar with at t= he time the behaviour changed ... but it does seem to be the consensus amon= g the authoritative implementors that REFUSED is the correct response.=C2= =A0 It wouldn't be the first time that a majority of implementations se= ttled on a behaviour that didn't strictly follow the specification beca= use it was necessary for good inter-operation.=C2=A0 =C2=A0 Perhaps someone= who was present for an implementer's internal discussion about replaci= ng upward referrals could comment on the reasoning, and what (if any) colla= boration occurred between the authoritative and recursive implementations a= t the time.


--001a113f651cb8aad6055de2b501-- From nobody Mon Nov 13 12:14:51 2017 Return-Path: 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 63056129B5E for ; Mon, 13 Nov 2017 12:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JtzRR0lIHVoW for ; Mon, 13 Nov 2017 12:14:48 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2D1129436 for ; Mon, 13 Nov 2017 12:14:48 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 5637C61FA2; Mon, 13 Nov 2017 20:14:48 +0000 (UTC) Message-ID: <5A09FD37.3080000@redbarn.org> Date: Mon, 13 Nov 2017 12:14:47 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Matthew Pounsett CC: jtk@aharp.iorc.depaul.edu, "dnsop@ietf.org" , Andrew Sullivan References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113085235.2fddd72a@p50.localdomain> <5A09EAA6.5010305@redbarn.org> <5A09F26B.40705@redbarn.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 20:14:49 -0000 Matthew Pounsett wrote: > ... I have seen no similar discussion of REFUSED-generated chaos in > recursive servers. If someone is seeing such brokenness, they > haven't brought it to dnsop@, or dns-operations@, or an OARC or NANOG > meeting. If someone is seeing such brokenness, hopefully they'll > speak up so that we can advise the authoritative > implementations to change their behaviour again. are you sure they'd be here listening, and that they would even understand the errors they are experiencing and connect those errors to this protocol change? > ... but it does seem to be the consensus among the > authoritative implementors that REFUSED is the correct response. are you sure they aren't just copying BIND's behaviour? do you remember when BIND only included one RR per message in outbound AXFR, and that there were some AXFR initiators that depended on this behaviour since they had never witnessed any other behaviour and hadn't read the spec? and how do you know about that consensus -- or do you mean a consensus among those present on this mailing list who have chosen to speak up? > ... It wouldn't be the first time that a majority of implementations > settled on a behaviour that didn't strictly follow the specification > because it was necessary for good inter-operation. i have seen no discussion, here or anywhere else, about necessity, or good interoperation, regarding this apparent departure from the spec. can you include a URI where i can study further? in other words, who argues for this, and on what basis? when we change a protocol on an existing signal path, we have a burden of do-no-harm to existing implementations who will never be changed. this burden is even higher when re-purposing existing signalling. if it's possible to have interpreted the old signal in some way, then we have to treat our change as "bearing a cost". > ... Perhaps someone who was present for an implementer's internal > discussion about replacing upward referrals could comment on the > reasoning, and what (if any) collaboration occurred between the > authoritative and recursive implementations at the time. i'd hope to see not only this, but someone currently participating in this discussion who can explain why an upward referral is a good signal. no query initiator should follow such a referral, but some may, which i'd view as a calamity. if the goal is some initiator reaction that is not what they would do if they heard SERVFAIL, then what is that goal? -- P Vixie From nobody Mon Nov 13 12:20:23 2017 Return-Path: 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 41769129B39 for ; Mon, 13 Nov 2017 12:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ph_JsgcYFFdg for ; Mon, 13 Nov 2017 12:20:21 -0800 (PST) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4215A1241F3 for ; Mon, 13 Nov 2017 12:20:21 -0800 (PST) Received: by chase.mycre.ws (Postfix, from userid 1000) id 84CF012C1555; Mon, 13 Nov 2017 15:20:20 -0500 (EST) Date: Mon, 13 Nov 2017 15:20:20 -0500 From: Robert Edmonds To: Paul Vixie Cc: Matthew Pounsett , "dnsop@ietf.org" , jtk@aharp.iorc.depaul.edu, Andrew Sullivan Message-ID: <20171113202020.bsgzpjyzxwgnep63@mycre.ws> References: <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113085235.2fddd72a@p50.localdomain> <5A09EAA6.5010305@redbarn.org> <5A09F26B.40705@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A09F26B.40705@redbarn.org> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 20:20:22 -0000 Paul Vixie wrote: > Matthew Pounsett wrote: > > I haven't got the time this morning to search release notes, but I'm > > fairly sure that in 2012, when you wrote that article, current versions > > of BIND were already handing out REFUSED to indicate "I'm not > > authoritative for that." At the very least it began doing that not long > > after. > > the implication of REFUSED is that if someone else asked this question, we > might be able to answer. so if BIND is doing what you say, it's wrong. In theory, any authoritative nameserver could secretly also be a resolver that will answer from cache if the right client sends it the same question. Does that make it OK, then? The REFUSED RCODE is documented as: Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data. In this case the server's policy would be that it doesn't perform a particular operation (i.e., QUERY) for particular data (i.e., data that it's not authoritative for). Where does the implication that REFUSED is only appropriate if the server might be able to answer if "someone else" asks the question come from? -- Robert Edmonds From nobody Mon Nov 13 13:19:37 2017 Return-Path: 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 39DC212945C for ; Mon, 13 Nov 2017 13:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 qTlAqiUuydkr for ; Mon, 13 Nov 2017 13:19:33 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A4C1201F8 for ; Mon, 13 Nov 2017 13:19:33 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id l24so313030pfj.6 for ; Mon, 13 Nov 2017 13:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n1ldU3YwjVTrI83zEZaWy3hUHUQS+8i66mcj3JbOIyo=; b=i1XP4/dRQ0b3civO3GbA82AnqOSdeUaa1384cwNOWVF7e1GBacSVueWoJBGPY7B1kd zzUplVllE4Ts2EBuA/hpzbUz8frLyEzlLfZkTalNmb/6bpinMb2Jiy8U6qGj72NfEKzj jl3ex0hReAaVJ/2P1CLfHDPMl8Wr65iVTnLHM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n1ldU3YwjVTrI83zEZaWy3hUHUQS+8i66mcj3JbOIyo=; b=OYzeae5xsHRDQ5AdODMaWlj5EvtPz+OGLfk+bV4mz96nVM/sNMojhx5S+5188agGDj hKxy4k8XTZxYuRZ9T9dYIFw2LQvQmrSiMzu6oZc5SI0XoUX1kZ32od6RAejyjbPASu6k 7mBfDoS6GrS9EAInFDICN/7oiJgmlOLNlizxKUp9BCyUWSrH7t/ELHjjh0B/tFpim8/x VgfmZ84Fi35Pz14vmf970wnRP+CIB4tOYRID/mqN934CW0A59BsorONNTlyrdYaJiXCg Z7zvAWkwQw0No4yHSMTxODkx9pUJ3ZmrKe8nkatK565jtrk6fISspvlgK26Z0/BDQYcZ ogXw== X-Gm-Message-State: AJaThX4AXRGFoakCjRPzao8s8qecLkUwS9pU0bPS2AdkmNFNwZMQryJD 64wk3X2Fx8uGgyTPmRPs+CSVsQ== X-Google-Smtp-Source: AGs4zMZ1FBOL/z6C5BbYp0qSUfpJCr1uP80ax0ZskOhOMIEx7DjN0eeHs71nTa/yALQWqBS2JLX9Tw== X-Received: by 10.98.58.199 with SMTP id v68mr11425604pfj.44.1510607973217; Mon, 13 Nov 2017 13:19:33 -0800 (PST) Received: from [31.133.149.171] (dhcp-95ab.meeting.ietf.org. [31.133.149.171]) by smtp.gmail.com with ESMTPSA id g7sm34941827pfj.13.2017.11.13.13.19.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 13:19:32 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (15B150) In-Reply-To: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> Date: Tue, 14 Nov 2017 05:19:30 +0800 Cc: tjw ietf , dnsop , Wes Hardaker Content-Transfer-Encoding: quoted-printable Message-Id: <3FFE9D39-DD16-4863-9F9B-46D585F90BF1@hopcount.ca> References: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> To: Geoff Huston Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 21:19:35 -0000 Hi Geoff, I think the number 4 on the slide was different from the one in the mail. The option on the slide that I mentioned I liked the most was the one that d= idn't copy the RCODE value from the header, but in effect provided a 16/32/w= hatever-bit sub-code for whatever the RCODE happened to be. So, for each permissible value of the RCODE field, this new field would prov= ide additional information that was relevant to that value. Compared to the other options presented, this avoids having to specify behav= iour for all the unhelpful corner cases of RCODE in message header doesn't m= atch the copy in the new field, new field value (e.g. "validation failed" or= something) doesn't make sense for this particular RCODE (e.g. "NOERROR"), e= tc. Joe > On Nov 13, 2017, at 19:01, Geoff Huston wrote: >=20 >=20 >> On 13 Nov 2017, at 9:43 pm, tjw ietf wrote: >>=20 >> To follow up from the meeting this morning, it sounded from the room tha= t in the case of these=20 >> four options, #4 was the one which makes the most sense. =20 >>=20 >>=20 > =E2=80=A6.. >=20 >>=20 >> 4. 32 bit code field, repeating rcode from elsewhere in the packet >> Like #2, but copies the rcode directly into the error code header >> within the extended-error component of the packet. Redundant but >> clear that the entire 32 bits are needed. >>=20 >> Thoughts? >=20 >=20 > errr - what would it mean if the rcode in the error code header differed > from the rcode value in the extended-error component? >=20 > The issue with duplicated information in a packet is that you then have > add even further consideration to cope with the cases where the expected > thing did not happen. >=20 > Not exactly blown away by #4 myself. >=20 > Geoff >=20 >=20 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon Nov 13 13:19:53 2017 Return-Path: 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 04620129562 for ; Mon, 13 Nov 2017 13:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 c3haQeMwB2qY for ; Mon, 13 Nov 2017 13:19:43 -0800 (PST) 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 5759E1294CF for ; Mon, 13 Nov 2017 13:19:43 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id A5D9D3BA219; Mon, 13 Nov 2017 21:19:41 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 8E5C1216C1E; Mon, 13 Nov 2017 21:19:41 +0000 (UTC) Date: Mon, 13 Nov 2017 21:19:41 +0000 From: Evan Hunt To: Matthew Pounsett Cc: Paul Vixie , "dnsop@ietf.org" , jtk@aharp.iorc.depaul.edu, Andrew Sullivan Message-ID: <20171113211941.GA36173@isc.org> References: <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113085235.2fddd72a@p50.localdomain> <5A09EAA6.5010305@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 21:19:53 -0000 On Mon, Nov 13, 2017 at 11:12:52AM -0800, Matthew Pounsett wrote: > I haven't got the time this morning to search release notes, but I'm fairly > sure that in 2012, when you wrote that article, current versions of BIND > were already handing out REFUSED to indicate "I'm not authoritative for > that." At the very least it began doing that not long after. That became the default behavior in 9.4.2 in Nov 2007. (It was documented in 9.4.0 in Feb 2007, but there was a bug in how the default setting was applied.) The relevant change was the addition of the allow-query-cache ACL. The REFUSED rcode in this case doesn't mean "I'm not authoritative", it means "you're not allowed to look in my cache to see the root referral I would've sent otherwise". It'd be nice if we could use NOTAUTH for this, but that rcode didn't exist when the spec was written. REFUSED isn't an exact fit, but it's legal, sensible in context, and gets the job done. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Mon Nov 13 13:38:11 2017 Return-Path: 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 69195126CC7 for ; Mon, 13 Nov 2017 13:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.onmicrosoft.com 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 6LVmT2u40cRZ for ; Mon, 13 Nov 2017 13:38:06 -0800 (PST) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0060.outbound.protection.outlook.com [104.47.125.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5035A124319 for ; Mon, 13 Nov 2017 13:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3V+mVWnRbVrb6NZ5J7oYTC5H+1q5SeCsQ5NrUuIBpek=; b=lpnVc3xdApfp2+BZyY4nhLwFvupl3cxEJD+dj7cw2gPuiEe//CrLoKNn91q7mIvzGUnPYXpbYA1vpb20fTJbIa0oql8WNhMWK5wB2G0YxtrrZsN30x13bif8l0wUb2PQB0Vo+sBhNZFg7WaXBcEFy/kLptEmLBwiPh/kiusTbmg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; Received: from [IPv6:2001:67c:1232:144:a13b:1cab:5bb7:fc74] (2001:67c:1232:144:a13b:1cab:5bb7:fc74) by SIXPR04MB0700.apcprd04.prod.outlook.com (2a01:111:e400:51ee::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Mon, 13 Nov 2017 21:38:02 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Geoff Huston In-Reply-To: <3FFE9D39-DD16-4863-9F9B-46D585F90BF1@hopcount.ca> Date: Tue, 14 Nov 2017 08:37:55 +1100 Cc: tjw ietf , dnsop , Wes Hardaker Content-Transfer-Encoding: quoted-printable Message-Id: <9EAE2E1F-CE2E-4F9F-92B2-1FE2A6023492@apnic.net> References: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> <3FFE9D39-DD16-4863-9F9B-46D585F90BF1@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.3273) X-Originating-IP: [2001:67c:1232:144:a13b:1cab:5bb7:fc74] X-ClientProxiedBy: SG2PR01CA0106.apcprd01.prod.exchangelabs.com (2603:1096:3:15::32) To SIXPR04MB0700.apcprd04.prod.outlook.com (2a01:111:e400:51ee::22) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f9391aa3-f719-4ab9-2bae-08d52aded16c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:SIXPR04MB0700; X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0700; 3:rgXEhowKsciASXy0Aady+dJQR2JF608jFBWojtTjHCK9IdIl3/81ooT+FB8niuTIrmPLNhaZk0VDL/cq/YH/Dsw1xHA1GGxhYSkzh3awkt6E83D8cf/LdkBgzprTJhupglrfV7Kw2q8wro1n6XvrZNPIf5VFdKk4M87TGvVpmtVr0JivzsymVCd5DARoN3iV47ly93GRkDuzaahLjrrseQ0kAfTtru3nw6qTsVARLDOOcn+Y52w9lcOVqBvh0fXX; 25:cORBhAaUlczTB+Lug3vtUu1zzziIC5vkQOZSaO1/WY7FdcBBhO/5W9caI4D8bFqKDb8Uud4s0ZfNNZdC4/0+VeEld8ZHfLo63cIWs/ICoXo1WzvSGH3Hi/9aC61S3XACu55wVy2xUwqiHvymqyyJQG6L+5HDJVIbwSJKe96zHMTTb2Vpbf73HGV8S5Q2hQoDCy1nx35eJ20zT/8OyXdb8K8fHdS9uqjG89I4sdXn2++Z052RBj40Dzi3Iy78UA5La9fSXGz7SDluRXYpUqd6KqSo0MaFiVMqoGYUL2L7zlPtEP6MF3fBbLF7FbRLDdJp7AJNTS7RbM51zzAOk4TUew==; 31:wVnOPzN3ogAd8opzQjesmCeWwL3B+23zNAysY7ysb54i0X7AeH517uO8JuBApSRYHJgrMukhCuKa/dv9qW+N2w3k2Xt1i0DmqQ1pWyifPr4OITyY0EPTa4rF3UD7hG1warjDL3ukPUIdfgGlFdhtuCpUitBh08m9Z36erkf4onYVIkeFZ6DlKyBlroySIpiHK/q/1rZndl3tcdVJolBG258u880CiHDWBYlFv9G+HGo= X-MS-TrafficTypeDiagnostic: SIXPR04MB0700: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3231022)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SIXPR04MB0700; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SIXPR04MB0700; X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0700; 4:4+fbYlLdEjX8sUa4sg5hMEuKf7tEObA8ziFLx/s7uXVQEn+FwHJFOjlyIFkWuZr5HM67/gackAKFwOzJQP9GuxVyET+ejnDNFR6tqoIJ//pLVJQ80rwNZOATk6hTPPvCpIIXp2ceLkW213Y2wXAv6ruUeqBfIujYmptMZ7MinMAgxhHhXm2/yL6JUV4gMEox+Qp7rMkQN6FGYJn4LvM6wqKXg9Ae/wVrCkZTrgYbK/1Zoliu3G23+iSgQyG6/tQiT2+HiwHtJLoortDd3qvxrg== X-Forefront-PRVS: 0490BBA1F0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(39830400002)(199003)(189002)(24454002)(82746002)(86362001)(478600001)(53936002)(6246003)(6486002)(50226002)(68736007)(54906003)(53546010)(316002)(2906002)(83716003)(105586002)(8936002)(81156014)(8746002)(23676003)(8676002)(81166006)(93886005)(6666003)(5660300001)(189998001)(6916009)(39060400002)(106356001)(2950100002)(4326008)(97736004)(47776003)(36756003)(57306001)(305945005)(33656002)(101416001)(230783001)(25786009)(50466002)(76176999)(6116002)(1706002)(50986999)(7736002)(229853002)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:SIXPR04MB0700; H:[IPv6:2001:67c:1232:144:a13b:1cab:5bb7:fc74]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: apnic.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTSVhQUjA0TUIwNzAwOzIzOnlOaEpQckhqNmhUY2xjNFJPZWV0SXFNYyty?= =?utf-8?B?ODY2dDE4anoxREs2aVhXMUpnazdON0htclRFTDVYVExwL1VsYkxHN1h5MFBw?= =?utf-8?B?bW44WDNRL3dPZVUwQmVoaEZkT0lnS0N0alFhQVVnalFaa3EzVVUyNFhPNXdQ?= =?utf-8?B?NTQxc3gxa3RzU0R5aEt5UzlNblhKdURxYTIwajVHOHBNWUh0N1dNVHd0YnJt?= =?utf-8?B?REFUS1pHT2JjMzI5MXFrTGtVTWQ5cjFwMVI2TzVhajQyUGx3SDlNWStjblg2?= =?utf-8?B?WGxzZzM4VUNJUkgyN0xuWWF6TzBjWEtqU1NWRXM4b3ArMjFERFF6TFgyRDNz?= =?utf-8?B?RUJzdXBhcVE1V2ZsUTJXcVZiU3g3alZjcFF5VzZ1RWFwRStqTUd3VnNsN2Za?= =?utf-8?B?L3Vqb214Ti9xTjNJRmVwekN2QzlBeVJVV05URXpvUVpHM0VUMU1TcjhxWjJu?= =?utf-8?B?dHVsV3pVc0ptL3ovMzc2OVRqR1lQWFNJZkUyZHdRUTZhOFlzZFpPRFZiREda?= =?utf-8?B?ZjJ2dXZRMUMwemlxTHhldGpFR2pBbFNVczVDTWRlRkQwaE5CWnJLT0pRclZD?= =?utf-8?B?Q3E3blQ4MGRJTlYxUHVhdUtuM0NQcmFXUTJMdGdjbmp0eTI0MVZxMTVudXpD?= =?utf-8?B?ZHpiVFRrWStyUGxSUHhVdGQ4UXI1VTFCbHg4elc1WmRUalR4WlJ5cG52Tjl3?= =?utf-8?B?Y1pQWWlDcThMTzYzaDVhbWc5K01UNmphNlkxdjhJME80MFZzVll4MjU0SkE3?= =?utf-8?B?WU01MzJ4UEdUT0lDU1hnSEVycGQ5MlMrTm92Rk54eFVQb0hxeWVyaTlQK3A0?= =?utf-8?B?cTYxTWNURWR5clJVVHltT1c0N25hWUhGSkFZZjZEV2NpZE0wOERERDZNa3Ju?= =?utf-8?B?SVVaS0U0Yk03MVdWN3dKWExTVG13VW1lRE02NFNadTgvL3cwVlUrUmRYSnkv?= =?utf-8?B?VE5EZ1FUZExNdzVNalZrUmlpZXdHMmlvbytaNkc3V1RaOUZGTUxtVUl2UkJB?= =?utf-8?B?Qzd6N2hxcXcxdnY1Mm40ZzV6NXJsU2o2U3BNV2NVa2dUVkJFQUt0WEpwQllv?= =?utf-8?B?eGFsSzVvS1hicVlOSmorRjdCZTArWGdUOEViMndMWEYwUGROR0ExQUpvRk1l?= =?utf-8?B?OExTNUJONFIrQnhRT1E0NU54M1ZPZTR1WUJ5b3R1TlM1R3VIRkxYaTVLaUZx?= =?utf-8?B?dllZMStkSUxacmdHVUlyZGlRWHdBN1lIWWRENTlqTUFKNnlqNHUzU1d0VTFm?= =?utf-8?B?bmFwRzU2OHBwMkVra2VrTVFKM1hmWVBoRi9NcGNETEZ5Z082YlBzSnVyZktP?= =?utf-8?B?cUErbFZWamQwejJyQmE1T1B3eGtNb2xaYUVEZDVtQm5sMEhaNElFSEdkTTlU?= =?utf-8?B?c2VaOG5lQWZkTVBYODdqSlJobnlRZGxUOURBdTVDVUY2SDdsN0NSWFhMak9K?= =?utf-8?B?bi9xck9Fc3JIZnFYMTZQb3FocXR5RmpLbDhCSTdUWkxOQ3Fodk1lOEorZ0dP?= =?utf-8?B?WEZhSTZTSEF1QTlXU2VOKys0a3VLUGtWeXVJdUtxaHNvazV0Q3pPcjY0OGhj?= =?utf-8?B?eUZoVmwxQllwdG5GL1FpbnJraUZObnlMRlJQejhMYTBtZ2hIZk43c1FwV0xl?= =?utf-8?B?ZTM0cVdIb1J0Nm10V2VEc2EvNjRscEU2Ym5ObXBjSFJnSWhRNkluV2t0TnpJ?= =?utf-8?Q?M7yy1C485WxWAecqm0=3D?= X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0700; 6:7xyqQoAsp7mKwCrnV2000t4sM/3qdTyUoKecKMXX0DXVYstapfhEF66BLqgDn4CirUi8Pk3OqYF75V5fa7bTtd+tVLia7YrgIlzpj3J+qcQiM0hQD5O2jH9eeHLrceiD4Rz9+X4yYSQLy0A3LbcBAT5dwMZACr7ROx4rbbBSfD8GLk0SMkr1luhSLDVD2lD6j3S9edJYukJgWmYvPxYMmqIEs8FDV30LEMvNirEMYRiLzSlsnwQYPP5+3hY27qtBEyJLgX0xGNjTwqT1npF2xExX6U//tB2f3TEpmwNkgso9xDUgqZKE6tUusQqxyExHBnmOSzDAlkwubNXy4cOYTfdO3OsR8UHALidMgeRESZk=; 5:i9OX3OYorolJUlE7WqGXGGeEAL2egl6++eP5WwuSeRUXwpG3fI9NQIkmlDZSg/fymuDZnijncajMtxJEgI018/wvSaygq7THnmYDJlJnYrdouIJf1W0tAKfRz3F6xEB2I+FVb5c6nkSog8VT5SpfffQjUsnyvBo8qSzyf8laIyU=; 24:DANIS0KwoNzkjE7yf4Gue8te8BT5ZkTP69AG/DppTMLR+jWwBBmX2FlgvrHImj8r/ictAHcpa4shWhIUqQAWVtwbK0L+7P7i55HHmiCMUpc=; 7:8lD90fAVdH/t4pnc8QaFY1u/bBQTZZom9jY1AvVFz6KK4R0DX4ffSCYW2vYZxIXVsLgvagQUPZ5X1qU+/Mw1md5o2/h/W/j6QSIbk/vlJOYzv2ZRNL8yZk5vSCtN+WcAEWhkrhjqLPk3rpdOcAD10bdjD+ayoGjKWw5tFWnJd+e81y8CNRvaChfCni3WGdhMCScumxUWaTj2MnAwiKWSoA+4f/HaqUgQ3C2IBirEB5VQOVwyJv5UOAt7fCnjPhzr SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Nov 2017 21:38:02.6957 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f9391aa3-f719-4ab9-2bae-08d52aded16c X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: SIXPR04MB0700 Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 21:38:09 -0000 > On 14 Nov 2017, at 8:19 am, Joe Abley wrote: >=20 > Hi Geoff, >=20 > I think the number 4 on the slide was different from the one in the = mail. I thought so too, but I wasn=E2=80=99t sure if it was me not paying = attention in the WG meeting or not! >=20 > The option on the slide that I mentioned I liked the most was the one = that didn't copy the RCODE value from the header, but in effect provided = a 16/32/whatever-bit sub-code for whatever the RCODE happened to be. and that makes sense to me, considering my perspective of the risk = associated with duplication of protocol field values >=20 > So, for each permissible value of the RCODE field, this new field = would provide additional information that was relevant to that value. >=20 > Compared to the other options presented, this avoids having to specify = behaviour for all the unhelpful corner cases of RCODE in message header = doesn't match the copy in the new field, new field value (e.g. = "validation failed" or something) doesn't make sense for this particular = RCODE (e.g. "NOERROR"), etc. >=20 thanks Joe, Geoff From nobody Mon Nov 13 14:17:05 2017 Return-Path: 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 7642D126C2F for ; Mon, 13 Nov 2017 14:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 ob0mJVW5aDVs for ; Mon, 13 Nov 2017 14:17:03 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 42CAC120724 for ; Mon, 13 Nov 2017 14:17:03 -0800 (PST) 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 7AF2A3B6A62; Mon, 13 Nov 2017 22:16:47 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 6919D16005B; Mon, 13 Nov 2017 22:16:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 56001160086; Mon, 13 Nov 2017 22:16:47 +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 U5oNZby2rnKP; Mon, 13 Nov 2017 22:16:47 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 5188416005B; Mon, 13 Nov 2017 22:16:46 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <436111CF-FCA8-44A2-B83D-6540DE6D64AC@icann.org> Date: Tue, 14 Nov 2017 09:16:43 +1100 Cc: Evan Hunt , Tony Finch , "dnsop@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <66BA5F27-B044-459B-A2B2-54221FD768C6@isc.org> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <20171113183004.GA35038@isc.org> <436111CF-FCA8-44A2-B83D-6540DE6D64AC@icann.org> To: Edward Lewis X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 22:17:04 -0000 > On 14 Nov 2017, at 5:45 am, Edward Lewis = wrote: >=20 > On 11/13/17, 13:30, "DNSOP on behalf of Evan Hunt" = wrote: >=20 >> Mark's idea to push updates to the parent instead of relying on = polling used a SRV query to identify the correct recipient of an UPDATE: >>=20 >> ...draft-andrews-dnsop-update-parent-zones-04... >=20 > This would mean then signing all the SRV sets, so I assume to preserve = the benefits of "OPTOUT", you'd want these only for the names that had = DS sets. For the others, I assume either no answer or the wildcard ... = in the TLD. (That latter thought might be unsettling to some people.) = What I mean is that there is still a scaling problem, in some dimension, = to deal with because the DNS is inherently a "down-only" tree. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop That part of the namespace doesn=E2=80=99t require signing as the = UPDATES themselves are signed and can be easily split off as a separate zone. The worst that would = happen is that the UPDATE request would be blocked if a spoofed response was accepted. = Using servers that relay the UPDATE request (which is what slave zones do today for = UPDATE) only requires a single SRV record. Even if the SRV records are all signed and the registry doesn=E2=80=99t = run a UPDATE relay there still isn=E2=80=99t a scaling issue. It is possible to serve COM with = every delegation being a secure delegation even though we don=E2=80=99t do it today. At worst this = creates a zone of slightly smaller size. Add to that there would be a ramp up process as registrars come = online supporting this method. Remember the draft was designed to handle ALL record updates to the = parent zone after being approved by the registrar in a unified manner. NS, DS, A, = DNAME, AAAA, TXT, CNAME, etc. This isn=E2=80=99t restricted to DS records. =20 Mark --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Nov 13 15:39:46 2017 Return-Path: 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 155CE1286B2 for ; Mon, 13 Nov 2017 15:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 0MRw-ILX8g-n for ; Mon, 13 Nov 2017 15:39:45 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 15B1D1270AC for ; Mon, 13 Nov 2017 15:39:45 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id CF74E3B6D4B; Mon, 13 Nov 2017 23:37:56 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id B7626216C1C; Mon, 13 Nov 2017 23:37:56 +0000 (UTC) Date: Mon, 13 Nov 2017 23:37:56 +0000 From: Evan Hunt To: Mark Andrews Cc: Edward Lewis , Tony Finch , "dnsop@ietf.org" Message-ID: <20171113233756.GA37394@isc.org> References: <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <20171113183004.GA35038@isc.org> <436111CF-FCA8-44A2-B83D-6540DE6D64AC@icann.org> <66BA5F27-B044-459B-A2B2-54221FD768C6@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <66BA5F27-B044-459B-A2B2-54221FD768C6@isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 23:39:46 -0000 On Tue, Nov 14, 2017 at 09:16:43AM +1100, Mark Andrews wrote: > Remember the draft was designed to handle ALL record updates to the > parent zone after being approved by the registrar in a unified manner. > NS, DS, A, DNAME, AAAA, TXT, CNAME, etc. This isn’t restricted to DS > records. In the present context, I was only suggesting this method be used for NOTIFY, not UPDATE -- to signal the parent that it should poll the child for CDS/CDNSKEY. (I guess CSYNC could be included in the mix as well, though, for updating NS and glue.) I would suggest the child should be polled periodically regardless. If the SRV record were spoofed, causing the child to send a NOTIFY to the wrong address, synchronization should still occur, just not as quickly. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Mon Nov 13 17:33:27 2017 Return-Path: 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 205D5129445 for ; Mon, 13 Nov 2017 17:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 AY5PLAOLJWwf for ; Mon, 13 Nov 2017 17:33:24 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 72CF8126E7A for ; Mon, 13 Nov 2017 17:33:24 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id E4F4031D12; Tue, 14 Nov 2017 02:33:21 +0100 (CET) Received: by godin (Postfix, from userid 1000) id 67385EC0BB6; Tue, 14 Nov 2017 02:30:49 +0100 (CET) Date: Tue, 14 Nov 2017 09:30:49 +0800 From: Stephane Bortzmeyer To: Ray Bellis Cc: dnsop@ietf.org Message-ID: <20171114013049.GA19865@laperouse.bortzmeyer.org> References: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:33:26 -0000 On Mon, Nov 13, 2017 at 08:54:16PM +0800, Ray Bellis wrote a message of 29 lines which said: > Would it be feasible to reserve a standard RCODE value in the header > that just means "see extended error"? First reaction: no. Middleboxes would block these responses, or old clients would not know what to do with it. From nobody Mon Nov 13 17:37:58 2017 Return-Path: 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 E4C10126E7A for ; Mon, 13 Nov 2017 17:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com 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 BTGvSPo4wnko for ; Mon, 13 Nov 2017 17:37:50 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D081270FC for ; Mon, 13 Nov 2017 17:37:49 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id b7so11264697vkh.12 for ; Mon, 13 Nov 2017 17:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1DJXxr6sZHVTU7fhR0pvt0FE7jHAim0qp+0cdq4i6p0=; b=VutyXZMXaOfbS2M/UpSkj/FkQ5uss5fVNUmEc6Qav0zfeiDBeP96810Dr1ltjXtmse K49A/nxmsIIkl8dp6mWs94Y4qpOusttO1ekd3c32YHodElAbnMiHVlVbSkQ5WcgBNh+t 5Xe/nCGwTWnaXDWAsIT2pz290XT4iBh1j5/XT9V7f0fuWg9dy1cU4/j3Lb085pSjAUaJ DcnYnf1UEgfLFlau8gxCrxsJQnE4bmgf/XrLHPPAmqCaflNhcXxLv9ztJBNtbNO4zqSA H7Yr9KeQYV2lLAe6a1z+WSoy+XyNdCBT+vffWauNlshgcKcsDMZS5zyCt8bxB9YtfviC tKXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1DJXxr6sZHVTU7fhR0pvt0FE7jHAim0qp+0cdq4i6p0=; b=D2saFyqZrCdBeMpxyEQKh4iAeavMKKJX1KbsgshAahbgPHJy08YzPxau8fU8rkZznj lwsZqIzg6lvuYbZ8tU3+ATrd+fOnurgeXxTgLbcS5hciNezubtu9g5pjGbfUYgdnW/Hj gc2T5Sp/Rt4Mh/7459hyq59RFP8OC2p7wpZ/hwk0woxj4uejEGCd1M8Sa/5rCqdTe4Yl CyG/dwzEULnq1M8AD15l+Nusts9Mh3T3OrtUDFall9Ukh2H4+j+hmcE/9az3tccafAPW az+GzAvSkC3tOAMJV77vrjzsguGwCouwlLCCo43RqVlTTtVoihbrASa0Ryk9m0Sp1+YP CWzg== X-Gm-Message-State: AJaThX5dmbVJAuTr9vxgS5DW4Qggs1IvkYN39WpCjb8orOvW+CrEjEYg gKuRMPqSaf6pErx1hY+jiXzKue+CjGurm6JgQGfJF8a4 X-Google-Smtp-Source: AGs4zMbA/hNGf0NkZjFMt99BuR08jIgOqwp2z79cuwvjWRo9PYxnz6Ivy0kCngmPkZkKW1dKHgW3hfZKrjI8o0xqPe0= X-Received: by 10.31.135.17 with SMTP id j17mr8048490vkd.34.1510623468953; Mon, 13 Nov 2017 17:37:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.91.2 with HTTP; Mon, 13 Nov 2017 17:37:48 -0800 (PST) X-Originating-IP: [101.100.166.3] In-Reply-To: <20171114013049.GA19865@laperouse.bortzmeyer.org> References: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> <20171114013049.GA19865@laperouse.bortzmeyer.org> From: George Michaelson Date: Tue, 14 Nov 2017 09:37:48 +0800 Message-ID: To: Stephane Bortzmeyer Cc: dnsop WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:37:52 -0000 Stephane, I don't entirely understand your response. old systems can never understand new code point assignments, or know what to do with it, no proposed change can alter this. Middleboxes dropping unexpected things will hit almost any proposed modification of packets in flight. Basically, I don't think any proposed modification of DNS in this space can be done, which doesn't face this risk: therefore, I don't see it having directing force. If there is some trick to doing something which doesn't expose the risk, What is it? cheers -George On Tue, Nov 14, 2017 at 9:30 AM, Stephane Bortzmeyer wrote: > On Mon, Nov 13, 2017 at 08:54:16PM +0800, > Ray Bellis wrote > a message of 29 lines which said: > >> Would it be feasible to reserve a standard RCODE value in the header >> that just means "see extended error"? > > First reaction: no. Middleboxes would block these responses, or old > clients would not know what to do with it. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon Nov 13 17:48:38 2017 Return-Path: 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 77BB01270A3 for ; Mon, 13 Nov 2017 17:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 Gg9AEHcKDTNA for ; Mon, 13 Nov 2017 17:48:32 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C4B1270FC for ; Mon, 13 Nov 2017 17:48:32 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id z184so8734130pgd.13 for ; Mon, 13 Nov 2017 17:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uphbbzWd5lYxKJ9mfOmCJBOYxx6vD7etKsDWaILkm58=; b=f+zafc+QF5HLY43KnbxknzMFRceB6mGRF/j0egNu0k/tnQTgCQVotCw+Mr3kcj0XHK B6IV8evRm6g50Qd1ojoHl5PsELswWvbzSOGechEnYI+POl8/Acf0WivfKCQDnv0iyKJM Eqwls7xdkZmdfvXzWJkn4sMgmHKtlbXtpHUUs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uphbbzWd5lYxKJ9mfOmCJBOYxx6vD7etKsDWaILkm58=; b=Mg8sutugzyOEBVnKzP1Ofl0zvk3e97InzwdIi349vFmyj4gC0bls0HOF9wRyDg8JSh daVHYvOBqXzJ4l1Q0ad2TNDIwQ1Zi1i9wfLU8jM4D97SAQ6g88B7wh+QBFaWpNxMjGWJ EfdarPD8L2YSKMUAV63X0TEx/kJk/z1e8GGt4fyQFTGd/8LFqgCcGuCddTE6EMjMEYVK Ug4yfJwriGLS0YjaGnXtA9ds5mnmhgjT9CV6x4p5soU3kWjCgrMTWUWyRwHmF4kPLzzN L7G/A02dWz9Ltqi3HhLU7HiEZ+/sIO1fbHsN42I8beq7uF6EKSyCiGiNbuFAL4roqZ30 xasA== X-Gm-Message-State: AJaThX7PiBUkI4zLqLDDpLMI1lFX+zFiwd17nuV+KZbt5BeUewX+cgEm PBl1EjwEp89irzNbrcnx8mtVEG+hZkQ= X-Google-Smtp-Source: AGs4zMbr50RFeU8nHnDWpffSMjczqwxqR9Gk/6o6MPAXzFCt3BgfBzCnLxEKjfZW2KXIjDoKKw9rqg== X-Received: by 10.84.232.76 with SMTP id f12mr10537172pln.195.1510624111632; Mon, 13 Nov 2017 17:48:31 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:5cb5:2fa:3be:e25a? ([2001:67c:370:128:5cb5:2fa:3be:e25a]) by smtp.gmail.com with ESMTPSA id a19sm36245122pfh.30.2017.11.13.17.48.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 17:48:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (15B150) In-Reply-To: Date: Tue, 14 Nov 2017 09:48:28 +0800 Cc: Stephane Bortzmeyer , dnsop WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> <20171114013049.GA19865@laperouse.bortzmeyer.org> To: George Michaelson Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:48:33 -0000 On Nov 14, 2017, at 09:37, George Michaelson wrote: > Stephane, I don't entirely understand your response. old systems can > never understand new code point assignments, or know what to do with > it, no proposed change can alter this. Middleboxes dropping unexpected > things will hit almost any proposed modification of packets in flight. The implication is, I think, that some new code points are more likely to su= rvive the attention of Sauron's Middleware than others. We have seen claims in the past that new RRTYPEs, new EDNS(0) options, new E= DNS(i) with i > 0, new records in ADDITIONAL sections, etc that will all fal= l fail of middleware or other dependent systems. What's not clear is the rel= ative impact of each, but it seems intuitively true that the impact of each i= s probably not the same. For example, I bet it's more practical to implement a new EDNS(0) option tha= n it is to deploy EDNS(1), but I have no science to back up that intuition. If only there was some kind of research group adept at wide-scale measuremen= t from the end-user perspective that could shed some light on this! Joe= From nobody Mon Nov 13 17:49:12 2017 Return-Path: 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 3840F1294FA for ; Mon, 13 Nov 2017 17:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=M+SGdoad; dkim=pass (1024-bit key) header.d=yitter.info header.b=bUc1q1Il 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 Qa1HefKP0Y9V for ; Mon, 13 Nov 2017 17:49:10 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17ABF1201F2 for ; Mon, 13 Nov 2017 17:49:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 863A4BF56B for ; Tue, 14 Nov 2017 01:49:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510624149; bh=/NkMGRxJi7vsE9DO82g1D1nKb+K8p2gJXOgwyCcO0Sg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=M+SGdoadey6RvqjnrMyjGw5Ibk0YY7spFXLUwi6sXycI/FhYK6nyIcsoLQmUzTcdf wfFg38pWE1uo2V+TAypxQZr4uVM/6BA9Yt/IZCre2wqIDn66XEvvGWjKycczNWdrZc Ksd/Nkydsjvwhm0YYt2/UQfq0YJP4gFt7psMxfYo= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pp21RhQ6lp-B for ; Tue, 14 Nov 2017 01:49:08 +0000 (UTC) Date: Mon, 13 Nov 2017 20:49:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510624148; bh=/NkMGRxJi7vsE9DO82g1D1nKb+K8p2gJXOgwyCcO0Sg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=bUc1q1IlXRpzArHfoyUw3uPXeIgxcYHI9NpEIuQcpTwcN2TqZ62O+0QbosnZo5hDZ rll9wMHs7WASBQpsMw6oysgEDarIYLd76FyInR9IJaVL9JJe83xF6FVgysNXejMsPg MKItRZ/s7Mle2xKFmxDRuOXUjiyX8aJtPsp1UFGU= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171114014905.kvxzagf7gduupzm4@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113085235.2fddd72a@p50.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171113085235.2fddd72a@p50.localdomain> Archived-At: Subject: [DNSOP] another draft (was Re: Clarifying referrals (#35) ) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:49:11 -0000 On Mon, Nov 13, 2017 at 08:52:35AM -0600, John Kristoff wrote: > On Mon, 13 Nov 2017 03:26:41 +0000 > Andrew Sullivan wrote: > > > This is quite a helpful response, thanks. I wonder whether more of it > > ought to go in discussion (or a new draft), > > I'd suggest a new draft be produced with which discussion could ensue. Given the discussion that ensued only here, it's pretty clear that some new text is needed. If nobody else writes one before I get the round tuit, I will, and will update the text about referrals also. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Nov 13 17:56:48 2017 Return-Path: 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 DFD6D1274D2 for ; Mon, 13 Nov 2017 17:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 2GXF5TUhdkmp for ; Mon, 13 Nov 2017 17:56:46 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 EF84D1200C5 for ; Mon, 13 Nov 2017 17:56:45 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 68E6231D12; Tue, 14 Nov 2017 02:56:44 +0100 (CET) Received: by godin (Postfix, from userid 1000) id E57EBEC0BB6; Tue, 14 Nov 2017 02:56:31 +0100 (CET) Date: Tue, 14 Nov 2017 09:56:31 +0800 From: Stephane Bortzmeyer To: Joe Abley Cc: George Michaelson , Stephane Bortzmeyer , dnsop WG Message-ID: <20171114015631.GA20438@laperouse.bortzmeyer.org> References: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> <20171114013049.GA19865@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:56:47 -0000 On Tue, Nov 14, 2017 at 09:48:28AM +0800, Joe Abley wrote a message of 24 lines which said: > The implication is, I think, that some new code points are more > likely to survive the attention of Sauron's Middleware than others. ... > it seems intuitively true that the impact of each is probably not > the same. Exactly. Thanks for a better wording of my concern. > If only there was some kind of research group adept at wide-scale > measurement from the end-user perspective that could shed some light > on this! There is such a research group, it's called Geoff Huston. From nobody Mon Nov 13 18:02:20 2017 Return-Path: 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 CF4211200C5 for ; Mon, 13 Nov 2017 18:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] 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 pfH-k6XHSCQb for ; Mon, 13 Nov 2017 18:02:17 -0800 (PST) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B351F128656 for ; Mon, 13 Nov 2017 18:02:17 -0800 (PST) Received: from localhost (unknown [IPv6:2001:67c:1232:144:fd59:400e:83b4:e6de]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 05A2B241E9; Mon, 13 Nov 2017 18:02:14 -0800 (PST) From: Wes Hardaker To: Tony Finch Cc: Stephane Bortzmeyer , dnsop@ietf.org References: <20171112012835.GA16257@laperouse.bortzmeyer.org> Date: Mon, 13 Nov 2017 18:02:11 -0800 In-Reply-To: (Tony Finch's message of "Mon, 13 Nov 2017 12:36:57 +0000") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] About draft-ietf-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:02:19 -0000 Tony Finch writes: > Stephane Bortzmeyer wrote: >> >> > It can be included in any error response (SERVFAIL, NXDOMAIN, >> > REFUSED, etc) >> >> It can be argued that NODATA (pseudo rcode, I know) is an "error" as >> well as NXDOMAIN... > > Or, neither of them are errors :-) We'll remove the restriction in any wording that says it can only be for errors. I think there is clear consensus to do so. -- Wes Hardaker USC/ISI From nobody Mon Nov 13 18:15:36 2017 Return-Path: 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 CFFB4129AFE for ; Mon, 13 Nov 2017 18:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 0ZKgaPfp2zfQ for ; Mon, 13 Nov 2017 18:15:33 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 38633129ADF for ; Mon, 13 Nov 2017 18:15:33 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ybWLm4P4Fz2n; Tue, 14 Nov 2017 03:15:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510625728; bh=TNOSBWu8k1NZR85q1W558QpA4y7vCVKc7CaXgrVlosI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=U7U/MHzFhdzBLiYeRkU0MMuRZ2P+slVlXvNwa9vR0kbeVZG7SFVTRCs0aTh3huLMz r9mBZPTOxANXXuCZILCB8D6+1i9aXsLTz8DnbJOAKP2aR0z7zoO2pSSgcThWj/5YkL oDNo1f98xBaRUlf798DzkrrOygQhfTI0TtYzsTgg= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id sA3xfGdvcgEu; Tue, 14 Nov 2017 03:15:27 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 14 Nov 2017 03:15:27 +0100 (CET) Received: from [31.133.130.95] (dhcp-825f.meeting.ietf.org [31.133.130.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 14BD362D29; Mon, 13 Nov 2017 21:15:26 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 14BD362D29 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (15A432) In-Reply-To: <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org> Date: Tue, 14 Nov 2017 10:15:22 +0800 Cc: Evan Hunt , =?utf-8?Q?Petr_=C5=A0pa=C4=8Dek?= , "dnsop@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <463C4A1E-D189-4A0D-9814-D215F930B0D4@nohats.ca> References: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> <20171109174804.GA63012@isc.org> <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org> To: Edward Lewis Archived-At: Subject: Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:15:35 -0000 >=20 > I'm not sure that the need for robustness outweighs the expectation of som= eone explicitly adding a trust anchor anymore. But that=E2=80=99s not your call to make, but the call of the entity decidin= g to put in that hard coded trust anchor. We just ask you not to block us from doing as we have been doing for years. > OTOH, in the sense "I am not sure" there's the example of split-DNS and po= or query path management (i.e., leaks). I'm not sure if robustness helps he= re, or is a bad-behavior enabler. I would like split-DNS to die too but I dont think that=E2=80=99s happening s= oon. Paul From nobody Mon Nov 13 18:20:03 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4A512954B; Mon, 13 Nov 2017 18:19:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151062599759.5833.10004739044907246221@ietfa.amsl.com> Date: Mon, 13 Nov 2017 18:19:57 -0800 Archived-At: Subject: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:19:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : A Sentinel for Detecting Trusted Keys in DNSSEC Authors : Geoff Huston Joao Silva Damas Warren Kumari Filename : draft-huston-kskroll-sentinel-03.txt Pages : 8 Date : 2017-11-13 Abstract: The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user to determine the trusted key state of the resolvers that handle the user's DNS queries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-huston-kskroll-sentinel-03 https://datatracker.ietf.org/doc/html/draft-huston-kskroll-sentinel-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-huston-kskroll-sentinel-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 13 18:26:09 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98115129AFE; Mon, 13 Nov 2017 18:26:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151062636258.5917.14497839377888768972@ietfa.amsl.com> Date: Mon, 13 Nov 2017 18:26:02 -0800 Archived-At: Subject: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:26:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : A Sentinel for Detecting Trusted Keys in DNSSEC Authors : Geoff Huston Joao Silva Damas Warren Kumari Filename : draft-huston-kskroll-sentinel-04.txt Pages : 8 Date : 2017-11-13 Abstract: The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user to determine the trusted key state of the resolvers that handle the user's DNS queries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-huston-kskroll-sentinel-04 https://datatracker.ietf.org/doc/html/draft-huston-kskroll-sentinel-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-huston-kskroll-sentinel-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 13 19:06:05 2017 Return-Path: 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 A3E2E124217 for ; Mon, 13 Nov 2017 19:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 c_lWj9PMRwNo for ; Mon, 13 Nov 2017 19:06:00 -0800 (PST) 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 ABDCA126DFF for ; Mon, 13 Nov 2017 19:06:00 -0800 (PST) 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 5C8D43B7454; Tue, 14 Nov 2017 03:05:56 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 40006160046; Tue, 14 Nov 2017 03:05:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 21C5D160076; Tue, 14 Nov 2017 03:05:56 +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 8oqAgbYcRg5m; Tue, 14 Nov 2017 03:05:56 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 4E451160046; Tue, 14 Nov 2017 03:05:55 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: Date: Tue, 14 Nov 2017 14:05:52 +1100 Cc: George Michaelson , dnsop WG Content-Transfer-Encoding: quoted-printable Message-Id: <9B7083BF-8A0F-4C64-824D-0FA29587EAE5@isc.org> References: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> <20171114013049.GA19865@laperouse.bortzmeyer.org> To: Joe Abley X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 03:06:03 -0000 > On 14 Nov 2017, at 12:48 pm, Joe Abley wrote: >=20 > On Nov 14, 2017, at 09:37, George Michaelson wrote: >=20 >> Stephane, I don't entirely understand your response. old systems can >> never understand new code point assignments, or know what to do with >> it, no proposed change can alter this. Middleboxes dropping = unexpected >> things will hit almost any proposed modification of packets in = flight. >=20 > The implication is, I think, that some new code points are more likely = to survive the attention of Sauron's Middleware than others. >=20 > We have seen claims in the past that new RRTYPEs, new EDNS(0) options, = new EDNS(i) with i > 0, new records in ADDITIONAL sections, etc that = will all fall fail of middleware or other dependent systems. What's not = clear is the relative impact of each, but it seems intuitively true that = the impact of each is probably not the same. >=20 > For example, I bet it's more practical to implement a new EDNS(0) = option than it is to deploy EDNS(1), but I have no science to back up = that intuition. Only marginally. Both are deployable between recursive server and = authoritative. It=E2=80=99s easy enough to detect mis-implementations and fallback = though one shouldn=E2=80=99t have to do that. If Amazon (bad EDNS version negotiation), GoDaddy (bad EDNS flags = handling) and Microsoft (bad EDNS version negotiation, bad EDNS options) would fix = their respective DNS server farms we would have much improved error rates. Amazon, = GoDaddy have removed the firewall entries that were dropping the test queries since = testing started. I can=E2=80=99t remember if Microsoft was blocking queries. Amazon=E2=80=99s mis-implementation needs to be fixed before they start = serving any signed zones as the answers to EDNS(1) queries appear as if they come from a = server that doesn=E2=80=99t support EDNS at all (no opt record returned). 18f.gov. @205.251.192.110 (ns-110.awsdns-13.com.): dns=3Dok edns=3Dok = edns1=3Dnoerror,noopt,soa edns@512=3Dok ednsopt=3Dok = edns1opt=3Dnoerror,noopt,soa do=3Dok ednsflags=3Dok = optlist=3Dok,nsid,subnet signed=3Dok ednstcp=3Dok 29palmsbomi-nsn.gov. @208.109.255.45 (ns70.domaincontrol.com.): dns=3Dok = edns=3Dok edns1=3Dok edns@512=3Dok ednsopt=3Dok edns1opt=3Dok do=3Dok = ednsflags=3Dmbz optlist=3Dok,nsid signed=3Dok ednstcp=3Dok boimi.gov. @64.4.48.6 (ns2-06.azure-dns.net.): dns=3Dok edns=3Dok = edns1=3Dnoerror,badversion edns@512=3Dok ednsopt=3Dechoed = edns1opt=3Dnoerror,badversion do=3Dok ednsflags=3Dok optlist=3Dok,subnet = signed=3Dok ednstcp=3Dok http://ednscomp.isc.org/compliance/summary.html > If only there was some kind of research group adept at wide-scale = measurement from the end-user perspective that could shed some light on = this! >=20 >=20 > Joe > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Nov 13 20:11:41 2017 Return-Path: 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 14487126E64 for ; Mon, 13 Nov 2017 20:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 N4CB9iyJuOpn for ; Mon, 13 Nov 2017 20:11:38 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF5C1243F6 for ; Mon, 13 Nov 2017 20:11:38 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f] (unknown [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 4A89D61FA2; Tue, 14 Nov 2017 04:11:38 +0000 (UTC) Message-ID: <5A0A6CF9.105@redbarn.org> Date: Mon, 13 Nov 2017 20:11:37 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Robert Edmonds CC: "dnsop@ietf.org" References: <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113085235.2fddd72a@p50.localdomain> <5A09EAA6.5010305@redbarn.org> <5A09F26B.40705@redbarn.org> <20171113202020.bsgzpjyzxwgnep63@mycre.ws> In-Reply-To: <20171113202020.bsgzpjyzxwgnep63@mycre.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 04:11:40 -0000 Robert Edmonds wrote: > Paul Vixie wrote: >> the implication of REFUSED is that if someone else asked this question, we >> might be able to answer. so if BIND is doing what you say, it's wrong. > > In theory, any authoritative nameserver could secretly also be a > resolver that will answer from cache if the right client sends it the > same question. Does that make it OK, then? no, because it can, should, and probably will have different responses and different reasons for those responses based on the query's RD value. in this sense, we (i was at ISC when it happened) got "allow-query-cache" almost precisely wrong. with what confusion, you can now witness. > The REFUSED RCODE is documented as: > > Refused - The name server refuses to perform the specified operation > for policy reasons. For example, a name server may not wish to > provide the information to the particular requester, or a name > server may not wish to perform a particular operation (e.g., zone > transfer) for particular data. > > In this case the server's policy would be that it doesn't perform a > particular operation (i.e., QUERY) for particular data (i.e., data that > it's not authoritative for). if the reason were due to something about the specified operation such as the RD bit (like, it's 1 when it has to be 0) then i'd follow your reasoning here. > Where does the implication that REFUSED is only appropriate if the > server might be able to answer if "someone else" asks the question come > from? first, the example, "provide the information to the particular requester". as in, some other requester might get a non-REFUSED answer. second, the example, "zone transfer". when i added my very first BIND4 feature it was "allow-xfer" and i did indeed return REFUSED when asked by someone who wasn't allowed. this also happens on TSIG failures today. third, the differences and distinctions in initiator behaviour. there is no difference in desired or expected initiator behaviour between "i am out of disk space and can't write a secondary zone file, so while i am configured to be a secondary server for this zone, i can't do it", vs. "i am configured to be a primary server for this zone but there is no zone file so i can't do it", vs. "i am not configured to be a server for this zone and either RA=0 or RD=0 or both". in all three cases, we want the initiator to cache our inability to satisfy it so as not to melt the tubez with repeated (doomed) requests, try other name servers (but not other addresses for this name server), and retry here later (after, say, ten minutes) in case the situation improves. the only hoped-for reason i can imagine for sending SERVFAIL in the first two cases and REFUSED in the last case is to control the logging on the initiator -- expecting the sysadmin to behave differently when cleaning up the resulting mess. using REFUSED vs. SERVFAIL in this case is a distinction without a difference, and a costly one, because REFUSED actually has a different intended reaction in the initiator than SERVFAIL. but i've covered that in the archives (several times) and won't repeat it again here. -- P Vixie From nobody Mon Nov 13 20:21:37 2017 Return-Path: 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 91F94127058 for ; Mon, 13 Nov 2017 20:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5vfmIN80V1fg for ; Mon, 13 Nov 2017 20:21:35 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4AFB126E64 for ; Mon, 13 Nov 2017 20:21:35 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f] (unknown [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id AEBA161FA2; Tue, 14 Nov 2017 04:21:35 +0000 (UTC) Message-ID: <5A0A6F4E.8050202@redbarn.org> Date: Mon, 13 Nov 2017 20:21:34 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Paul Wouters CC: "dnsop@ietf.org" References: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> <20171109174804.GA63012@isc.org> <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org> <463C4A1E-D189-4A0D-9814-D215F930B0D4@nohats.ca> In-Reply-To: <463C4A1E-D189-4A0D-9814-D215F930B0D4@nohats.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 04:21:36 -0000 Paul Wouters wrote: > >> I'm not sure that the need for robustness outweighs the expectation >> of someone explicitly adding a trust anchor anymore. > > But that’s not your call to make, but the call of the entity deciding > to put in that hard coded trust anchor. > > We just ask you not to block us from doing as we have been doing for > years. +1. all policy is local. >> OTOH, in the sense "I am not sure" there's the example of split-DNS >> and poor query path management (i.e., leaks). I'm not sure if >> robustness helps here, or is a bad-behavior enabler. > > I would like split-DNS to die too but I dont think that’s happening > soon. -1. like NAT, we will have a better internet if we embrace split-DNS rather than wishing it wasn't real or wishing it did not exist. due to network partitions, both permanent and ephemeral, the global or universal namespace should be a last resort, after permitting namespace searches at the host, server, LAN, campus, corporate, league, and regional layers. names at any layer of this hierarchy should be treated as first-class, should be secure, and should be tagged so as to be either re-qualified when carried to higher or lower layers, or marked as unresolvable by those layers. whether DNS can adapt remains to be seen. but declaring working and desired configurations such as split-DNS to be undesireable, or breaking them, or failing to support them, are head-in-sand moves. the internet historically responds to head-in-sand moves by moving on in its own way. -- P Vixie From nobody Mon Nov 13 22:32:23 2017 Return-Path: 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 C5F9A127337 for ; Mon, 13 Nov 2017 22:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=UTPziQ7L; dkim=pass (1024-bit key) header.d=yitter.info header.b=Dj4qTCm/ 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 5asXgHHeOxQI for ; Mon, 13 Nov 2017 22:32:20 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3800812717E for ; Mon, 13 Nov 2017 22:32:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 9357BBF56B for ; Tue, 14 Nov 2017 06:32:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510641139; bh=t9AV0ZjfBorpJvQ4OpoHnKT69HEDuGYw71nf5b+ManY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=UTPziQ7LqMj/rOAicw4G9YK7jq5BDwUk7JN51xMu40CbjPODEdydNxdDG7bM8uKBJ TQgc2BCodB85WWeUxBzzo9+dd2DDE9COSOlLEwI8at6yd/mIGfnO/tzW6qSgPrtEDr krLXKV4HQ02HC119YQnknbf97FXFk/z7sEyHSru4= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KG4ar33ULZ78 for ; Tue, 14 Nov 2017 06:32:17 +0000 (UTC) Date: Tue, 14 Nov 2017 01:32:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510641137; bh=t9AV0ZjfBorpJvQ4OpoHnKT69HEDuGYw71nf5b+ManY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Dj4qTCm/OOHKyrwkmeIHsUvVwpYb8O+UCqOXQ6TdEPwTpykTAt4nwxSJi1GsM3dYu 3webQpKbcjJP34vBOK8Fz4VZEmZgTIBlCXz+XJV08zJuVrdDsvSVxDnr++OVhB29Qu Z6ooGIinDSzfuYzHEX21uxF5LFqSAQf74X9tODyY= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171114063209.gjubqyovnwcrl33a@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <5A09C4D6.6080202@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A09C4D6.6080202@redbarn.org> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 06:32:22 -0000 Hi, On Mon, Nov 13, 2017 at 08:14:14AM -0800, Paul Vixie wrote: > > If I ask the authoritative server for example.com about a name > > label.example.net, in a graph-theoretic sense the NS RRset for the > > root zone is clearly closer to label.example.net than anything else I > > can give. > > dns is not that kind of graph. > > if the qname is acetes.pa.dec.com and the query is being processed by the > dec.com authority server who knows that pa.dec.com is a delegation, then > pa.dec.com is closer to acetes.pa.dec.com than the root would be. Obviously. But your example is still on the current tree, just not immediately below. The example I gave is in a completely different section of the tree, and my point is that none of the text you quoted shows why "." isn't the "closer server" that an authoritative server somewhere beneath com. can give in response to a qname that is somewhere beneath net. We might think today that is a misfeature in STD13, but I don't think it's a misinterpretation of what STD13 says. I don't know what kind of graph would make that false. > as i wrote during the SOPA wars, REFUSED has been widely used as an > administrative denial, and repurposing it would not be effective at this > late date. This, too, seems to be a claim that is at best poorly justified. It might be that it is how BIND interprets the RCODE, but it's not what it is defined to be. I'm anyway not sure your description in the circleid piece (or elsewhere) is inconsistent with the RFC 1035 definition of RCODE 5: "The name server refuses to perform the specified operation for policy reasons." Refusing to respond to this or that IP address is a policy, and refusing to perform upward referrals is also a policy, no? Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Nov 13 23:03:14 2017 Return-Path: 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 17E7A128961 for ; Mon, 13 Nov 2017 23:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wTDsDOpjbDbR for ; Mon, 13 Nov 2017 23:03:12 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37DF127977 for ; Mon, 13 Nov 2017 23:03:11 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f] (unknown [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id BE2DF61FA2; Tue, 14 Nov 2017 07:03:11 +0000 (UTC) Message-ID: <5A0A952F.1060001@redbarn.org> Date: Mon, 13 Nov 2017 23:03:11 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Andrew Sullivan CC: dnsop@ietf.org References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <5A09C4D6.6080202@redbarn.org> <20171114063209.gjubqyovnwcrl33a@mx4.yitter.info> In-Reply-To: <20171114063209.gjubqyovnwcrl33a@mx4.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 07:03:13 -0000 Andrew Sullivan wrote: > Hi, > > On Mon, Nov 13, 2017 at 08:14:14AM -0800, Paul Vixie wrote: >>> If I ask the authoritative server for example.com about a name >>> label.example.net, in a graph-theoretic sense the NS RRset for the >>> root zone is clearly closer to label.example.net than anything else I >>> can give. >> dns is not that kind of graph. >> >> ... > > Obviously. But your example is still on the current tree, just not > immediately below. The example I gave is in a completely different > section of the tree, and my point is that none of the text you quoted > shows why "." isn't the "closer server" that an authoritative server > somewhere beneath com. can give in response to a qname that is > somewhere beneath net. We might think today that is a misfeature in > STD13, but I don't think it's a misinterpretation of what STD13 says. > I don't know what kind of graph would make that false. actually, i had misread you (com vs net). i apologize. let me re-answer. there is no reason for an authority server to know who the root name servers are. so, there can be no expectation that it would know any "closer" name server set than the one at its zone bottom. since RFC 1034 talks about zone bottoms, and "closest enclosing", and its algorithm speaks specifically of a referral being generated by copying non-authoritative NS RRs from the zone bottom into the answer, there is no reasonable interpretation of "closer" other than an NS RRset which is closer, along the path from the zone apex to the qname, than the zone apex was. in fact, from that algorithm, there is no way to generate a referral other than by copying along-the-path data into an answer. any attempt to interpret "closer" in an off-the-path way is a clear misinterpretation of RFC 1034. we are only on "the current tree" here. >> as i wrote during the SOPA wars, REFUSED has been widely used as an >> administrative denial, and repurposing it would not be effective at this >> late date. > > This, too, seems to be a claim that is at best poorly justified. It > might be that it is how BIND interprets the RCODE, but it's not what > it is defined to be. it's defined as "administrative denial" not merely "widely interpreted as administrative denial" as i wrote above. > ... I'm anyway not sure your description in the circleid piece (or > elsewhere) is inconsistent with the RFC 1035 definition of RCODE 5: > "The name server refuses to perform the specified operation for > policy reasons." Refusing to respond to this or that IP address is a > policy, and refusing to perform upwardreferrals is also a policy, no? "no." the client isn't asking for an upward referral, it's asking for an answer, and is expecting either an answer (positive or negative or empty) or an on-the-path referral copied from the non-authoritative data at the bottom of the authority zone. it is not expecting its query to be interpreted as a request for an upward referral, so, it cannot treat REFUSED as an administrative denial of that upward referral. the rest of the text of the definition of REFUSED makes this clearer: <> the word "particular" appears four times. as witnessed in discussions of the u.s. constitutions and the christian bible, arguments about the literal intent of the authors are interesting mostly to scholars, whereas our concern should be with the actions taken by the far end given the data pattern we transmit and the circumstances as we know them. while specific guidance was not given as to resolver action in response to each possible authority RCODE, i have both witnessed and implemented full resolvers which treated REFUSED as a permanent failure whereas SERVFAIL was a temporary failure. that is, receipt of a REFUSED from any authority consulted during iteration would cause a final error code (assuming no other authority gave a more useful answer) of NO_RECOVERY, whereas if only timeouts and SERVFAILs were heard, the final error code would be TRY_AGAIN. (these are BSD h_errno values, but modern API's have equivalents.) --- treating "i don't have the zone configured" as a REFUSED condition, while treating "i can't write the secondary zone" or "i can't read the primary zone" as SERVFAIL conditions, adds no value, but does subtract it. usually when i don't have a zone configured that is delegated to me, it's because i have not caught up with my inbox, or i have FUBAR'd my configuration file using "git" or similar. in those cases, the name being looked up _might exist_ and retrying later _might succeed_. i have heard a number of folks argue that this logic is common, but i have heard noone argue that it is superior to known alternatives. can we hear someone who is in favour of this for reasons beyond "five million frenchmen cannot be wrong"? -- P Vixie From nobody Mon Nov 13 23:09:49 2017 Return-Path: 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 A7AAF126C25 for ; Mon, 13 Nov 2017 23:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 y41Es4MjLJ0v for ; Mon, 13 Nov 2017 23:09:46 -0800 (PST) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5D286124205 for ; Mon, 13 Nov 2017 23:09:46 -0800 (PST) Received: from ponyo.lan.banu.com (unknown [IPv6:2001:67c:370:128:ab3f:8762:ac2a:7f00]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id A4AEB56A0309; Tue, 14 Nov 2017 07:09:44 +0000 (GMT) Date: Tue, 14 Nov 2017 15:09:39 +0800 From: Mukund Sivaraman To: dnsop@ietf.org Message-ID: <20171114070939.GA19501@ponyo.lan.banu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: Subject: [DNSOP] Some comments on draft-ietf-dnsop-terminology-bis-07 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 07:09:48 -0000 I haven't done a full review, but want to. Please answer this first: The terminology document seems to contain both easy and hard-to-come-by definitions. Without knowing what to filter, I keep getting a large vocabulary of DNS phrases to propose but I don't know if they belong in this terminology document. Is any DNS phrase acceptable? Examples: * DNS indirection (a phrase also used in the infamous iDNS attack.. lookup of name leads to lookup of nameserver's address nsname1/A, which leads to lookup of another nameserver's address nsname2/A), etc. * Cache (explanation of what a cache is, what it contains, how long the cache may be expected to store data, whether it is strongly coupled to authoritative data, etc.) * Chain-of-trust (in DNSSEC) * Owner name (of RRs) * Truncated message (I feel it's important to describe it and what happens due to it, as it's a commonly seen occurrence) * DNS continuation (e.g., the sequence of AXFR messages) * Inline signing * Stub zones (it's a feature available from multiple implementations, but not clearly explained in most documentation) * DNS class (what is it good for? :) * Notification * DNSSEC lookaside validation (though ISC's DLV service is "off", the protocol itself is not) * Kaminsky attack (why not mention this phrase that's used to identify a DNS poisoning attack?) * DNS cookie * Key rollover * Wire format * DNS64 * RPZ * RRL * Prefetching I'll be happy to contribute definitions if you select any phrases to include. And also more DNS terms if it's clear what can be included. ---- Some comments: * Negative response - shouldn't this also include "name doesn't exist" NXDOMAIN?) * Reverse lookup - is it worth mentioning PTR here? * Occluded name - This is not limited to DNS UPDATE and introduction of DNAME. It _can_ also occur via regular zone loading process, if the parser allows non-address "glue" (the wider use). I think it isn't strictly specified that such occluded records should be rejected during zone load. Mukund From nobody Mon Nov 13 23:32:32 2017 Return-Path: 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 8146C129490 for ; Mon, 13 Nov 2017 23:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wH0fjbWqdWHM for ; Mon, 13 Nov 2017 23:32:29 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C471293DA for ; Mon, 13 Nov 2017 23:32:28 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C148E7A330A; Tue, 14 Nov 2017 07:32:27 +0000 (UTC) Date: Tue, 14 Nov 2017 07:32:27 +0000 From: Viktor Dukhovni To: dnsop@ietf.org Message-ID: <20171114073227.GO3322@mournblade.imrryr.org> Reply-To: dnsop@ietf.org References: <20171112012835.GA16257@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [DNSOP] About draft-ietf-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 07:32:30 -0000 On Mon, Nov 13, 2017 at 06:02:11PM -0800, Wes Hardaker wrote: > Tony Finch writes: > > >> It can be argued that NODATA (pseudo rcode, I know) is an "error" as > >> well as NXDOMAIN... > > > > Or, neither of them are errors :-) > > We'll remove the restriction in any wording that says it can only be for > errors. I think there is clear consensus to do so. For the record, I'm with Tony, neither NODATA nor NXDomain are DNS lookup errors. Lack of answers may (or may not) lead to application-level errors depending on whether the data sought was functionally essential, but either way the DNS lookup was successful, and returned the status of the requested RRset. This is, for example, important with opportunistic DANE TLS, where actual lookup errors are potential downgrade attacks, but NODATA and NXDomain are not lookup errors. And indeed unlike actual errors, there is nothing one could possibly add in the form extended "error" diagnostics when returning a NODATA or NXDomain response, these non-error conditions don't require any additional context to aid problem resolution. -- Viktor. From nobody Mon Nov 13 23:56:59 2017 Return-Path: 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 578031292C5 for ; Mon, 13 Nov 2017 23:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HcJxAwxb6I3R for ; Mon, 13 Nov 2017 23:56:57 -0800 (PST) Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2831126C23 for ; Mon, 13 Nov 2017 23:56:56 -0800 (PST) Received: from ori.enn.lu ([85.248.227.163] helo=[127.0.0.1]) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1eEW7p-0005Jr-0H for dnsop@ietf.org; Tue, 14 Nov 2017 07:59:17 +0000 To: dnsop@ietf.org References: <20171112012835.GA16257@laperouse.bortzmeyer.org> <20171114073227.GO3322@mournblade.imrryr.org> From: Shane Kerr Message-ID: <3b429f8e-1046-e70d-ab9f-0ac4ba735232@time-travellers.org> Date: Tue, 14 Nov 2017 07:56:00 +0000 MIME-Version: 1.0 In-Reply-To: <20171114073227.GO3322@mournblade.imrryr.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] About draft-ietf-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 07:56:58 -0000 Viktor, Viktor Dukhovni: > On Mon, Nov 13, 2017 at 06:02:11PM -0800, Wes Hardaker wrote: > >> Tony Finch writes: >> >>>> It can be argued that NODATA (pseudo rcode, I know) is an "error" as >>>> well as NXDOMAIN... >>> >>> Or, neither of them are errors :-) >> >> We'll remove the restriction in any wording that says it can only be for >> errors. I think there is clear consensus to do so. > > For the record, I'm with Tony, neither NODATA nor NXDomain are DNS > lookup errors. Lack of answers may (or may not) lead to > application-level errors depending on whether the data sought was > functionally essential, but either way the DNS lookup was successful, > and returned the status of the requested RRset. > > This is, for example, important with opportunistic DANE TLS, where > actual lookup errors are potential downgrade attacks, but NODATA > and NXDomain are not lookup errors. > > And indeed unlike actual errors, there is nothing one could possibly > add in the form extended "error" diagnostics when returning a NODATA > or NXDomain response, these non-error conditions don't require any > additional context to aid problem resolution. Be careful when you say "nothing ... possibly". ;) For example, you could have something like: RCODE: SUCCESS (NODATA) Extended code: ERRBLACKLIST Explanation: "Client blacklisted for IPv6 queries" This could be helpful for a user or operator. (Of course, it also hints that being able to add arbitrary text to an error may be useful, as including a URL with more information in the response might provide further insight. But perhaps having Google is enough that this is not necessary?) Cheers, -- Shane From nobody Mon Nov 13 23:58:47 2017 Return-Path: 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 89CA4129484 for ; Mon, 13 Nov 2017 23:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=nQpIHioF; dkim=pass (1024-bit key) header.d=yitter.info header.b=Pn1zQyV5 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 ndPQn8tJfWcd for ; Mon, 13 Nov 2017 23:58:45 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFA91292C5 for ; Mon, 13 Nov 2017 23:58:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 5D86FBF56B for ; Tue, 14 Nov 2017 07:58:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510646294; bh=jtiAcoWJd9fVkKeUxCWZV7v/VL3wwXW7hkdR98bmXMU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=nQpIHioF7rdJmwfZwNf4AmFdQKEWMkYS2Co7osawKelgUtzKTqDoB2mLxNt3pHCSn X3Oggg+1sp7+Y7e+pr8nTRV0R1ILMHMneOoixhV44GycWoC5j3T6S7Ts46VolHZfiG B5bALfj59N3yYRmJH+A2EwfQ2oUdHVVzcyLjowRg= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tb8ffyAnvy2e for ; Tue, 14 Nov 2017 07:58:12 +0000 (UTC) Date: Tue, 14 Nov 2017 02:58:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510646292; bh=jtiAcoWJd9fVkKeUxCWZV7v/VL3wwXW7hkdR98bmXMU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Pn1zQyV5/HN+WQHz8wPoS7pNUQ4dr4oS/dps5sIYm4mt2JecYwhhM8xzwvSvrkc+2 wz71fnUeqKA4E8TaOzFL2nV7kGByNBQpnl3O2W9PGdrcYxDJy7P/aAUTk191lhwUwO eezKcvD9Cz9iZqtmW53bu3aJfmOOolc1eOcl1rmU= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171114075805.l46jp5oi6qwedrom@mx4.yitter.info> References: <20171114070939.GA19501@ponyo.lan.banu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171114070939.GA19501@ponyo.lan.banu.com> Archived-At: Subject: Re: [DNSOP] Some comments on draft-ietf-dnsop-terminology-bis-07 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 07:58:46 -0000 Hi, Speaking only for myself and not the other editors: On Tue, Nov 14, 2017 at 03:09:39PM +0800, Mukund Sivaraman wrote: > The terminology document seems to contain both easy and > hard-to-come-by definitions. Without knowing what to filter, I keep > getting a large vocabulary of DNS phrases to propose but I don't > know if they belong in this terminology document. Is any DNS phrase > acceptable? Maybe :) The editors will of course do whatever the WG consensus is. Still, the point is not, IMO, to cover every term that has to do with the DNS in any context, and if a term is not used except in a given context I'd expect familiarity with that part of the protocol to be enough unless the terms are otherwise poorly defined. The genesis of the document was in part, at least for me, irritant terms: 1. There were terms that I would trip across even though they were well-documented (nobody would bother to look them up), and I wanted an easy thing to point to. Usually these were terms that were used badly or carelessly (sometimes by people who were obviously pretending to know what they were talking about). 2. There were terms that got thrown around all the time, and when someone would ask me the meaning I found I didn't have a good reference, but I knew perfectly well that everyone knew what was meant. 3. There were terms that I was afraid were being used ambiguously or even equivocally. Some of these haven't made the cut yet :) I don't know whether Paul's and Kazunori's inspirations were the same. I think in general though the WG has attempted to include terms that are in wide enough use and sufficiently DNS-specific so as to be appropriate for processing through the DNSOP WG. > * DNS indirection (a phrase also used in the infamous iDNS > attack.. lookup of name leads to lookup of nameserver's address > nsname1/A, which leads to lookup of another nameserver's address > nsname2/A), etc. I am not sure I have ever heard this term, so I can't tell whether it ought to be included. > > * Cache (explanation of what a cache is, what it contains, how long the > cache may be expected to store data, whether it is strongly coupled to > authoritative data, etc.) Probably the general term cache doesn't need explaining, but it's true that 7719 has a lot of mentions of caches without saying what they ought to have, and I'm not sure the older RFCs are too clear about this. > * Chain-of-trust (in DNSSEC) Is this a DNS-specific term? I think it's pretty common in PK crypto, no? > * Owner name (of RRs) Already there ;-) > * Truncated message (I feel it's important to describe it and what > happens due to it, as it's a commonly seen occurrence) If you have proposed text, I can maybe see a spot for this. > * DNS continuation (e.g., the sequence of AXFR messages) There is a pretty exhaustive AXFR document, and this only comes up in that context, right? […] > * DNS class (what is it good for? :) Absolutely nothing, say it again. I offered a draft about this a while ago and got enough push back that I gave up. I am not convinced that a terminology draft could tackle the definition of class in STD 13 without attempting to alter the meaning, myself. > > * Negative response - shouldn't this also include "name doesn't exist" > NXDOMAIN?) It does, no? We don't reproduce the stuff to which we refer: you're supposed to follow those referrals, just like a resolver ;-) > * Reverse lookup - is it worth mentioning PTR here? Text? > * Occluded name - This is not limited to DNS UPDATE and introduction of > DNAME. It _can_ also occur via regular zone loading process, if the > parser allows non-address "glue" (the wider use). I think it isn't > strictly specified that such occluded records should be rejected > during zone load. This sounds like a somewhat wider definition. I'd like to see text and strong WG support before it gets included. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Nov 14 00:06:45 2017 Return-Path: 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 365E6128DF6 for ; Tue, 14 Nov 2017 00:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 vM2emdSQbqpK for ; Tue, 14 Nov 2017 00:06:42 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 E2AEC124234 for ; Tue, 14 Nov 2017 00:06:42 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 250C93B1174; Tue, 14 Nov 2017 08:06:38 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 10F2D216C1C; Tue, 14 Nov 2017 08:06:38 +0000 (UTC) Date: Tue, 14 Nov 2017 08:06:38 +0000 From: Evan Hunt To: Paul Vixie Cc: Andrew Sullivan , dnsop@ietf.org Message-ID: <20171114080638.GA41253@isc.org> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <5A09C4D6.6080202@redbarn.org> <20171114063209.gjubqyovnwcrl33a@mx4.yitter.info> <5A0A952F.1060001@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A0A952F.1060001@redbarn.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 08:06:44 -0000 On Mon, Nov 13, 2017 at 11:03:11PM -0800, Paul Vixie wrote: > while specific guidance was not given as to resolver action in response > to each possible authority RCODE, i have both witnessed and implemented > full resolvers which treated REFUSED as a permanent failure whereas > SERVFAIL was a temporary failure. What do you mean by "permanent" in this context? As far as I know, BIND treats REFUSED as persistent during the resolution process -- i.e., it won't bother to retry the same server with the same query immediately. It would go to the next delegated name server, and if all servers refused, eventually it would return SERVFAIL to the client. It might add the address to a bad server cache; I'm not actually sure whether it does that in this scenario, I'd have to check. If it does, that would keep it from retrying the server for 30 minutes, which is a reasonable recovery time for the "haven't caught up with my inbox" class of error. > treating "i don't have the zone configured" as a REFUSED condition, > while treating "i can't write the secondary zone" or "i can't read the > primary zone" as SERVFAIL conditions, adds no value, but does subtract > it. I'm not seeing the value subtracted. In those two cases, your server knows that it's *supposed* to be authoritative for the zone in question, and that there's a problem preventing it from answering. This fits the definition of SERVFAIL, "unable to process this query due to a problem with the name server", and the other case doesn't. > usually when i don't have a zone configured that is delegated to me, > it's because i have not caught up with my inbox, or i have FUBAR'd my > configuration file using "git" or similar. in those cases, the name > being looked up _might exist_ and retrying later _might succeed_. Or, very likely, the parent zone is misconfigured or out of date, in which case the name doesn't exist and retrying later won't sucseed. Perhaps you run a secondary name service and your customer hasn't paid the bill, or they're in the process of switching to a new provider, or they just put in the wrong glue. Your server isn't failing; it's just being asked for a name it never heard of. > i have heard a number of folks argue that this logic is common, but i > have heard noone argue that it is superior to known alternatives. can we > hear someone who is in favour of this for reasons beyond "five million > frenchmen cannot be wrong"? I wish NOTAUTH had been defined in 1035. Since it wasn't, there are only three answers that make any sense: NOERROR with upward referral, SERVFAIL, REFUSED. We already disposed of upward referral. SERVFAIL gets you spurious retries. REFUSED makes the querant go away for a sensible amount of time; we have ten years of operational experience with it. I don't see the problem. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Tue Nov 14 00:21:15 2017 Return-Path: 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 09FCC128D19 for ; Tue, 14 Nov 2017 00:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 unKLLzy1ayqS for ; Tue, 14 Nov 2017 00:21:12 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98308127077 for ; Tue, 14 Nov 2017 00:21:12 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f] (unknown [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 82ABB61FA2; Tue, 14 Nov 2017 08:21:12 +0000 (UTC) Message-ID: <5A0AA777.9010908@redbarn.org> Date: Tue, 14 Nov 2017 00:21:11 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Evan Hunt CC: dnsop@ietf.org References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <5A09C4D6.6080202@redbarn.org> <20171114063209.gjubqyovnwcrl33a@mx4.yitter.info> <5A0A952F.1060001@redbarn.org> <20171114080638.GA41253@isc.org> In-Reply-To: <20171114080638.GA41253@isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 08:21:14 -0000 Evan Hunt wrote: > On Mon, Nov 13, 2017 at 11:03:11PM -0800, Paul Vixie wrote: >> while specific guidance was not given as to resolver action in response >> to each possible authority RCODE, i have both witnessed and implemented >> full resolvers which treated REFUSED as a permanent failure whereas >> SERVFAIL was a temporary failure. > > What do you mean by "permanent" in this context? i mean propagating REFUSED back to the stub so that it can return an error to its application or user. in SMTP terms this would cause a 4xx rather than a 5xx. in fact, SMTP might bounce the e-mail rather than requeuing it for later retry, if an SMTP relay got REFUSED from DNS rather than SERVFAIL when looking up an MX or AAAA or A to send to. >> i have heard a number of folks argue that this logic is common, but i >> have heard noone argue that it is superior to known alternatives. can we >> hear someone who is in favour of this for reasons beyond "five million >> frenchmen cannot be wrong"? > > I wish NOTAUTH had been defined in 1035. Since it wasn't, there are only > three answers that make any sense: NOERROR with upward referral, SERVFAIL, > REFUSED. We already disposed of upward referral. SERVFAIL gets you > spurious retries. SERVFAIL's retries aren't spurious. > ... REFUSED makes the querant go away for a sensible amount > of time; SERVFAIL's have to be cached. perhaps we should document that fact as part of explaining why REFUSED is wrong-headed for this signaling purpose. > ... we have ten years of operational experience with it. I don't see > the problem. i think we have to be very careful reasoning about nonexistence from an absence of evidence. not everyone who could be having problems related to BIND's use of REFUSED from this will recognize it as a BIND problem or even as a DNS problem, and even if they do, they may not know to contact ISC or to join this mailing list. this is one of the few areas in which i agree with the robustness principle. what you're not seeing doesn't matter nearly as much as what the people you're not seeing may have coded by looking only at the spec. at some time when we know how and why to increment the EDNS version number we should start using NOTAUTH. until then we should be using SERVFAIL. and we should document the need to cache SERVFAILs. REFUSED has a well understood purpose when RD=1 and the server has an ACL, which may mean a mixed-mode server has an "allow-query-cache" ACL. let us please not treat that as a reason to repurpose REFUSED when RD=0. -- P Vixie From nobody Tue Nov 14 00:47:33 2017 Return-Path: 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 E2BBD126FB3 for ; Tue, 14 Nov 2017 00:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 sIvSaei4PV1v for ; Tue, 14 Nov 2017 00:47:30 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3E2128D3E for ; Tue, 14 Nov 2017 00:47:26 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DFDE27A330A; Tue, 14 Nov 2017 08:47:25 +0000 (UTC) Date: Tue, 14 Nov 2017 08:47:25 +0000 From: Viktor Dukhovni To: dnsop@ietf.org Message-ID: <20171114084725.GP3322@mournblade.imrryr.org> Reply-To: dnsop@ietf.org References: <20171112012835.GA16257@laperouse.bortzmeyer.org> <20171114073227.GO3322@mournblade.imrryr.org> <3b429f8e-1046-e70d-ab9f-0ac4ba735232@time-travellers.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3b429f8e-1046-e70d-ab9f-0ac4ba735232@time-travellers.org> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [DNSOP] About draft-ietf-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 08:47:32 -0000 On Tue, Nov 14, 2017 at 07:56:00AM +0000, Shane Kerr wrote: > > And indeed unlike actual errors, there is nothing one could possibly > > add in the form extended "error" diagnostics when returning a NODATA > > or NXDomain response, these non-error conditions don't require any > > additional context to aid problem resolution. > > Be careful when you say "nothing ... possibly". ;) > > For example, you could have something like: > > RCODE: SUCCESS (NODATA) > Extended code: ERRBLACKLIST > Explanation: "Client blacklisted for IPv6 queries" Well, once we're in the "lying with DNS" business, we hardly need to restrict extended diagnostics to errors, we can equally contemplate them for policy-based answers that don't reflect the authoritative zone content... :-8 -- Viktor. From nobody Tue Nov 14 00:51:25 2017 Return-Path: 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 8036A124D6C for ; Tue, 14 Nov 2017 00:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 LDqdGNkbUC-H for ; Tue, 14 Nov 2017 00:51:21 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 B6D2412008A for ; Tue, 14 Nov 2017 00:51:21 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ybh7W04J2z3H5; Tue, 14 Nov 2017 09:51:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510649479; bh=IrBo5ZftbSjEp7Vtq+q3TR9ZvAj3y7YY/ADLVyxnv5Q=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Dk362c3jPUp9Obkjjzx/NI1SPjIH4OeevnKSsXah6YLE2odt3Y8MKsMbbe9K6y9B7 D+eXE46KoNLGY14PFdXJqxle61PXwdMutF9J51Jqp4IyaZa3I5BqLwqRZ9pmT5YfQe Dd1Tz8LOrM3dnCsgYQP7l1V5EvmTkd63F1e0v/IU= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id pB4bN6MGZw8A; Tue, 14 Nov 2017 09:51:16 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 14 Nov 2017 09:51:16 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A338562D29; Tue, 14 Nov 2017 03:51:15 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca A338562D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7788D40D35AF; Tue, 14 Nov 2017 03:51:15 -0500 (EST) Date: Tue, 14 Nov 2017 03:51:15 -0500 (EST) From: Paul Wouters To: Paul Vixie cc: "dnsop@ietf.org" In-Reply-To: <5A0A6F4E.8050202@redbarn.org> Message-ID: References: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> <20171109174804.GA63012@isc.org> <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org> <463C4A1E-D189-4A0D-9814-D215F930B0D4@nohats.ca> <5A0A6F4E.8050202@redbarn.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 08:51:23 -0000 On Mon, 13 Nov 2017, Paul Vixie wrote: > whether DNS can adapt remains to be seen. but declaring working and > desired configurations such as split-DNS to be undesireable, or breaking > them, or failing to support them, are head-in-sand moves. the internet > historically responds to head-in-sand moves by moving on in its own way. For the record, while I don't like split-dns, I do actively support it, even with DNSSEC, for instance in: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns Paul From nobody Tue Nov 14 00:54:32 2017 Return-Path: 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 8B161124D6C for ; Tue, 14 Nov 2017 00:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 ob_YH1y5Yjuq for ; Tue, 14 Nov 2017 00:54:20 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9832128AB0 for ; Tue, 14 Nov 2017 00:54:19 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id f134so13049115lfg.8 for ; Tue, 14 Nov 2017 00:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to; bh=tLXrG6MNaUE8MaLyGYEMGg880dBOE71cFlEaTjIzPbc=; b=ddUS0Rhbjfu/wIRLzNmu0/ewxvmsXa0i2+7v+3o9GPURE3Zqrt4M5EwS24bKRDx1zw U6Wf+un+wFtjDPZFHgt2o73thdvosQpVl0g4hMy3W8GCnyri8T6N9BikQEdlX6sSabCr XeMt8NTrfOjANGsc1avfitiSuu8k4c9Q2LfjI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to; bh=tLXrG6MNaUE8MaLyGYEMGg880dBOE71cFlEaTjIzPbc=; b=WcF1GErG6n6Qh4QBmiZ4Vk9Vlk6ygwv5+vtDpso3METHmK0yJFIFbYp4jjUehpYwxE MztPc5HpieSA1yGqFXU1X3guY0jrYMtCI6nifvzZqq1be0NKc/2m5PHhCTYcbeFD5vEw djdRaK4swn028FCTRCjvsWc9gXezUM+qiHbGPJzUe77MR15+WVS7dMUKyHiB7Qod6/9T z2+vrPzE8Q/DxatvyerDmcajv1JSExklsZ2bAQVGYipzEnN8cpBY3slR0UN6NGVR38h+ NYmLEiRvV1YfFi2XcFSPZ5lWlkZtGGlKQ+AGnBbEyDohDxvOkZNonPdU/w9BJUL+wGLQ YX9Q== X-Gm-Message-State: AJaThX71Ku+8Wc57lE1fsg/zpse1NqBO3eQvxW89wtNC3zet4h/TNBl2 kjlmKkbhGkAVgySbMGNiBfITrGlR1mlqz43SB8VcbQ== X-Google-Smtp-Source: AGs4zMYj/fEz4bB1o/NvKZ7QoZEKgCztdlbXTaU0x6is6qDP9mT8NLGY+DFW5E8bH6/EPPaWRCdVZ+ii2K1FhvmiOAE= X-Received: by 10.46.65.14 with SMTP id o14mr4544266lja.172.1510649657981; Tue, 14 Nov 2017 00:54:17 -0800 (PST) From: Joe Abley Mime-Version: 1.0 (1.0) References: <20171112012835.GA16257@laperouse.bortzmeyer.org> <20171114073227.GO3322@mournblade.imrryr.org> <3b429f8e-1046-e70d-ab9f-0ac4ba735232@time-travellers.org> <20171114084725.GP3322@mournblade.imrryr.org> In-Reply-To: <20171114084725.GP3322@mournblade.imrryr.org> Date: Tue, 14 Nov 2017 16:54:15 +0800 Message-ID: <7043569809190448225@unknownmsgid> To: dnsop@ietf.org Content-Type: multipart/alternative; boundary="94eb2c07572e3e9480055ded88ca" Archived-At: Subject: Re: [DNSOP] About draft-ietf-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 08:54:24 -0000 --94eb2c07572e3e9480055ded88ca Content-Type: text/plain; charset="UTF-8" On Nov 14, 2017, at 16:47, Viktor Dukhovni wrote: Well, once we're in the "lying with DNS" business, we hardly need to restrict extended diagnostics to errors, we can equally contemplate them for policy-based answers that don't reflect the authoritative zone content... :-8 You make it sound like "lying with DNS" is some future thing and not something that happens right now, 500,000 times per second! I think it's fair to clarify that we're not talking about extended errors any more but rather extended RCODEs or something, if that's what we are doing. I don't think it's sensible to say absolutely that there will never be a need to disambiguate NXDOMAIN or NOERROR since never is an awfully long time, and who knows or dares to dream? Joe --94eb2c07572e3e9480055ded88ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Nov 14, 2017, at 16:= 47, Viktor Dukhovni <ietf-dane= @dukhovni.org> wrote:

Well, once we're = in the "lying with DNS" business, we hardly need
to restrict extended diagnostics to errors, we ca= n equally contemplate
them for policy-based answers that do= n't reflect the authoritative
zone content... :-8

You make it sound like "ly= ing with DNS" is some future thing and not something that happens righ= t now, 500,000 times per second!

I think it's = fair to clarify that we're not talking about extended errors any more b= ut rather extended RCODEs or something, if that's what we are doing.=C2= =A0

I don't think it's sensible to say abs= olutely that there will never be a need to disambiguate NXDOMAIN or NOERROR= since never is an awfully long time, and who knows or dares to dream?


Joe
--94eb2c07572e3e9480055ded88ca-- From nobody Tue Nov 14 01:06:49 2017 Return-Path: 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 188EF124205 for ; Tue, 14 Nov 2017 01:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EJIhnyD2sIag for ; Tue, 14 Nov 2017 01:06:47 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E72612008A for ; Tue, 14 Nov 2017 01:06:47 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f] (unknown [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 00ECA61FA2; Tue, 14 Nov 2017 09:06:46 +0000 (UTC) Message-ID: <5A0AB226.9040105@redbarn.org> Date: Tue, 14 Nov 2017 01:06:46 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Joe Abley CC: dnsop@ietf.org References: <20171112012835.GA16257@laperouse.bortzmeyer.org> <20171114073227.GO3322@mournblade.imrryr.org> <3b429f8e-1046-e70d-ab9f-0ac4ba735232@time-travellers.org> <20171114084725.GP3322@mournblade.imrryr.org> <7043569809190448225@unknownmsgid> In-Reply-To: <7043569809190448225@unknownmsgid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] About draft-ietf-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 09:06:48 -0000 Joe Abley wrote: > ... > > I don't think it's sensible to say absolutely that there will never be a > need to disambiguate NXDOMAIN or NOERROR since never is an awfully long > time, and who knows or dares to dream? that outcome depends on scope. if you imagine a protocol speaker behaving differently based on fine-grained differences in cause that relate in small ways to the larger NXDOMAIN/NOERROR status code, then i think we should not allow for that -- it would be madness, even compared to the present day. if you believe that it will appear in "dig" output and syslogs and dnstap traces, so as to help diagnosticians and academicians decide the whichness of what, after the fact, then i agree, we should not prohibit the fine detail just because we think the gross details are obvious. -- P Vixie From nobody Tue Nov 14 01:10:37 2017 Return-Path: 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 28A6112008A for ; Tue, 14 Nov 2017 01:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dJagxnB1k9U1 for ; Tue, 14 Nov 2017 01:10:34 -0800 (PST) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2AB124205 for ; Tue, 14 Nov 2017 01:10:34 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id D23EF3F43D; Tue, 14 Nov 2017 04:10:32 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23050.45832.787089.325014@gro.dd.org> Date: Tue, 14 Nov 2017 04:10:32 -0500 From: Dave Lawrence To: dnsop@ietf.org In-Reply-To: <23040.33307.69754.133713@gro.dd.org> References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 09:10:36 -0000 Dave Lawrence writes: > The main changes, based on previous feedback, are: > > * Clarifying what the action is for Standards Track; > * Describing the algorithm previously proposed (and still included) as > one example way of achieving the goals; and, > * Adding a rough proposal for an EDNS option that could be used for > explicit signalling. > > That last item will be fleshed out more if there's demonstrated > interest from implementers in having such a thing. At the moment I'll observe there are no open issues against the draft, which is my comically passive-aggressive way of pointing out that it is obviously perfect and so let's just move it along to Last Call. This is now your opportunity to correspondingly observe that someone is wrong on the Internet and to respond appropriately. At the very least, we'd like to know whether there is sufficient support for pursuing the EDNS option or just to take it back out (and leave the rest of the obviously perfect document as-is). Thanks in advance for any feedback, tale From nobody Tue Nov 14 01:13:38 2017 Return-Path: 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 01DCE124205 for ; Tue, 14 Nov 2017 01:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wGhebQa17exa for ; Tue, 14 Nov 2017 01:13:36 -0800 (PST) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302D212008A for ; Tue, 14 Nov 2017 01:13:36 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 287C23F43D; Tue, 14 Nov 2017 04:13:35 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23050.46015.119981.671790@gro.dd.org> Date: Tue, 14 Nov 2017 04:13:35 -0500 From: Dave Lawrence To: dnsop@ietf.org In-Reply-To: References: <6a9a1b99-20a8-0c25-38d1-d3cdb7255506@gmail.com> Archived-At: Subject: Re: [DNSOP] DINRG update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 09:13:37 -0000 On Nov 13, 2017, at 8:12 AM, Melinda Shore wrote: > With regrets to the fine folks of dnsop, we've scheduled the > dinrg side meeting from 9:30 - 12:00 this morning. We realize > that there are many people in the dns community who are > interested in decentralized approaches to naming but scheduling > during this meeting has been exceptionally difficult. Given that the Thursday dnsop slot from 15:50-17:50 has been cancelled, is there interest in having another get-together then? From nobody Tue Nov 14 01:16:02 2017 Return-Path: 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 01B27129400 for ; Tue, 14 Nov 2017 01:16:00 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 GmHRvdK7Y3x6 for ; Tue, 14 Nov 2017 01:15:57 -0800 (PST) Received: from relay.vweb.co.za (relay.vweb.co.za [IPv6:2001:43f8:790:61::200]) (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 C4E8C12008A for ; Tue, 14 Nov 2017 01:15:56 -0800 (PST) Received: from [165.255.69.12] (port=39884 helo=mjelap.posix.co.za) by relay.vweb.co.za with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eEXIx-0004x7-Ep for dnsop@ietf.org; Tue, 14 Nov 2017 11:14:52 +0200 Reply-To: mje@posix.co.za To: dnsop@ietf.org References: <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <20171113183004.GA35038@isc.org> <436111CF-FCA8-44A2-B83D-6540DE6D64AC@icann.org> <66BA5F27-B044-459B-A2B2-54221FD768C6@isc.org> <20171113233756.GA37394@isc.org> From: Mark Elkins Organization: Posix Systems Message-ID: Date: Tue, 14 Nov 2017 11:15:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171113233756.GA37394@isc.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 09:16:00 -0000 On 14/11/2017 01:37, Evan Hunt wrote: > On Tue, Nov 14, 2017 at 09:16:43AM +1100, Mark Andrews wrote: >> Remember the draft was designed to handle ALL record updates to the >> parent zone after being approved by the registrar in a unified manner. >> NS, DS, A, DNAME, AAAA, TXT, CNAME, etc. This isn’t restricted to DS >> records. > In the present context, I was only suggesting this method be used for > NOTIFY, not UPDATE -- to signal the parent that it should poll the child > for CDS/CDNSKEY. (I guess CSYNC could be included in the mix as well, > though, for updating NS and glue.) > > I would suggest the child should be polled periodically regardless. If > the SRV record were spoofed, causing the child to send a NOTIFY to the > wrong address, synchronization should still occur, just not as quickly. Getting the parent to examine the child in order to examine changes in CDS/CDNSKEY is something I'd dearly like to see done. With foot firmly stuck in mouth and probably breaking all protocols.... Who am I: I'm a 'local' Registrar (Non-ICANN Accredited), running DNSSEC for clients. I speak EPP mainly to the ZACR (South African Central Registry) - usually for the CO.ZA Domain name space. I also speak EPP to a bunch of other people. I either run the DNS zone for the client - so know when to send an EPP update to the Registry (this is totally automated) or run a "Registration Only" service where clients run their own (DNSSEC Signed) zones. When the latter do a KSK rollover, they are currently obliged to login to https://vweb.co.za into their account, find their Domain and push a [Reread Zone info] button which does a DNS Lookup over TCP using a DNSSEC aware recursive resolver to see what NS and DNSKEY records have changed, brings them back and presents them to the user. I automatically generate CDS records from the DNSKEY. A short time later - these are pushed to the Parent via EPP. More ideally, this [Reread Zone info] button should be triggered by the client using a well documented standard (RFC?), probably a URL and passing to the URL the Domain Name to "check". (I like to call this the "tickle RFC"). The same could be used directly with Registry systems... If you want to get CO.ZA to "Poll" your Nameservers, look for a DNS record (lets call it TCKL) in the top of the zone which should return a web like URL which you can then "GET" with... (GET seems more simple than POST) co.za    IN    TCKL    "https://poll.registry.net.za?Domain=" (Most ccTLD's might do the same?) For myself, I'd tell my clients mentioned above to look for: vweb.co.za    IN    TCKL    "https://tickle.vweb.co.za?Domain=" (Most COM type Registrars might do the same?) I guess one could have multiple answers for redundancy. No "security" as in passwords should be needed. I don't see this being used to DDOS Registries, only do something further if the domain is one of yours, only if it is already DNSSEC signed, and only trust the answer if the DNS Connection validates properly, any faults - wait 5 seconds and then report an error (if so desired). I don't quite see how a SVR record could do this as per https://tools.ietf.org/html/draft-andrews-dnsop-update-parent-zones-04 I also don't remember seeing any DNS record types where the RHS is a full URL. To me, for now, this would only be used for DNSSEC updates (i.e. CDS/CDNSKEY where the Child Zone is already signed) Anyway - that's my baby step, so just a small foot in my mouth. Please be gentle. -- Mark James ELKINS - Posix Systems - (South) Africa mje@posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za From nobody Tue Nov 14 01:22:06 2017 Return-Path: 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 8A74D124B09 for ; Tue, 14 Nov 2017 01:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TmlGkuyUaxK6 for ; Tue, 14 Nov 2017 01:22:03 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BAD112008A for ; Tue, 14 Nov 2017 01:22:03 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id i15so3664411pfa.3 for ; Tue, 14 Nov 2017 01:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=VWYiSQbMNLbfdyWYu5Y1WUIPfd2tvPS0/IkzBy5QpaQ=; b=BsF9xlMLt5WRJSygAlTFNvm6fwUNpPo+79VLLaa6ncZg5Iq8xk6xIT0Aqvc7uDDThd Se7vJhOL+rc8eNGgIcRlbiukcQByVSunyIlHAkdPFLwFl/LCD3AnSRfzL4uBDtm+hJld yw+mhShRpRo0aFLQxiavVgQMBOD11yaKBF38qFoB2+Yr0Xh1H6+dnULEA6tn2iGqjMq5 mwn/eXkd8Ned+Sgw7JzRbonV7bK38g8zhQ4V6Zyxi3iD+0jo8O8x60AAz8pAeTOf0TIV ZpM83U+u4yN6Bm2ohN+9ohnzjEitPFIYPlETQF82rbH5DkDyXaBeI1NdHpFL1C4Fk/yz wKxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=VWYiSQbMNLbfdyWYu5Y1WUIPfd2tvPS0/IkzBy5QpaQ=; b=DH5gkzo3BkK7vDTy+I4yE1cOI+ygTg3KGvG0f23VHCfzeeEsB5UHT4e1xsNkvlthYu j0QJEnyXc2rFwbpUwlaocP6FbWdHy9zZLeqg4DStRoA9Wuzlx3sJv5NkFJj2vz5/yf+i cg84o8ChxikOItw++SSPSPfhDQxaoxrCFDB5VLLECE/x7S1RoNo1dxidKHwOS2LCKQeI hkgbgD0Xo1GYDrPFx7OGE33xjJFRJZSmBapN2IoVzFxZSweU4QLDWIdatwGDP641Qnyj sv5EKnn05SujkEakiYz+HcEajszVql9NRKnmmJjMjkpLK98s4dmKjHfXhSc1PY/RpuHh LrUQ== X-Gm-Message-State: AJaThX5denR4aE41OKS6BZb0m5ypLY0F+R1vCUp/bp77hoeosq1qvSGD SbE/diOExB4RXDF2Vfx0/jnXm5Yk X-Google-Smtp-Source: AGs4zMargrfAZscaOtruxavn/ze+nKUk9qbezep6UXYgiWXcHZNi3yK83mjMHeGb+g9yWa3tSQOSCw== X-Received: by 10.159.216.145 with SMTP id s17mr11659585plp.297.1510651322397; Tue, 14 Nov 2017 01:22:02 -0800 (PST) Received: from Melindas-MacBook-Pro.local ([203.127.152.4]) by smtp.gmail.com with ESMTPSA id r188sm16738295pfr.123.2017.11.14.01.22.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 01:22:01 -0800 (PST) To: dnsop@ietf.org References: <6a9a1b99-20a8-0c25-38d1-d3cdb7255506@gmail.com> <23050.46015.119981.671790@gro.dd.org> From: Melinda Shore Message-ID: <93fd5b5e-6634-3b58-8865-c746a3322211@gmail.com> Date: Tue, 14 Nov 2017 17:21:59 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <23050.46015.119981.671790@gro.dd.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="h6fFR1u1iSTTuLSF2Qx1sDW3JiwquhvXA" Archived-At: Subject: Re: [DNSOP] DINRG update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 09:22:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h6fFR1u1iSTTuLSF2Qx1sDW3JiwquhvXA Content-Type: multipart/mixed; boundary="n0XhIW6n2u7XxIgdKlpsdCkWSqsXxWV0w"; protected-headers="v1" From: Melinda Shore To: dnsop@ietf.org Message-ID: <93fd5b5e-6634-3b58-8865-c746a3322211@gmail.com> Subject: Re: [DNSOP] DINRG update References: <6a9a1b99-20a8-0c25-38d1-d3cdb7255506@gmail.com> <23050.46015.119981.671790@gro.dd.org> In-Reply-To: <23050.46015.119981.671790@gro.dd.org> --n0XhIW6n2u7XxIgdKlpsdCkWSqsXxWV0w Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/14/17 5:13 PM, Dave Lawrence wrote: > Given that the Thursday dnsop slot from 15:50-17:50 has been > cancelled, is there interest in having another get-together then? That's still scheduled against both nwcrg and acme, so it's not a great time. The core issue that led to us canceling the session was that many of the people doing active work in this space (and naming is by no means the only infrastructure problem, here) were unable to travel to Singapore. We have loose plans to have an interim at NDSS and then to meet again in London, People doing work in this area should definitely join the dinrg mailing list, and let us know what you're working on and if you'd like to present that work at an upcoming session. Melinda --n0XhIW6n2u7XxIgdKlpsdCkWSqsXxWV0w-- --h6fFR1u1iSTTuLSF2Qx1sDW3JiwquhvXA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOwSIcj4Q6xsnay8FuIZGkzoegS4FAloKtbgACgkQuIZGkzoe gS6vMw//d6daIFr7eATAmG3SogF1kHrseABjiQB46vul14Hfeb3AZ/6ECh/5+iFi zYNQx7pH/0QkrfbAm7DDIj6VHpoga7nFJNgLBhqyoJpaC/ws+snExHKuZi8w727V PbThEi5QBC8IpsTJz9+j6n58h2oP+a3hcjdTc0wmj+zksSD9MZgfyR23upbYftfF 3URVTBiVzLzP+1WKbJLT0TSvpUZeVMPc2bNHTEXoHxwqvPuzMp1OzCNIdo0BlUe7 j/TTqgGEnhXTxHD+e8YJvGlMN7oWMLU1++mkMWAyWxVV2lmGkenm9VuZSvAcJnCf deQwCrOEPrgwdp2edNNacuQh0tnwnoBgEPvP/oKtjzOBJV/dByD7SSXzg9DwGR7n q+dnQSR/ZgZjWdXFy/dKgtTFIFKDPuOAU0OzWj3hV0aMfPlxUQmac7SWKjyLrTx7 N8G3sj42lk+7hb3UtKJx1kYeS1+HsSMCJLvHUgqaYXOTirHfbdZMYoJCaFD/7kV2 8GAOUI8BjQ1vDJulzzmPzeSFfy1uL8zGOLjSsla64uDZOJVFCz8ubXveKrHnLagN 9/j1cd9+q6jT9OIhBpvFoM+P8ezHNNHG2UTkCK3F0MzoZfp46znAPFOFOeb6/e5n jb1OUArEtARJO0WuKROa/A8d2R+tf6PsExHEyB6REn77S42LL68= =L9+P -----END PGP SIGNATURE----- --h6fFR1u1iSTTuLSF2Qx1sDW3JiwquhvXA-- From nobody Tue Nov 14 01:26:03 2017 Return-Path: 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 00873128D19 for ; Tue, 14 Nov 2017 01:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sQ07ncLYOzJf for ; Tue, 14 Nov 2017 01:26:00 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5DC71286C7 for ; Tue, 14 Nov 2017 01:26:00 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f] (unknown [IPv6:2001:559:8000:c9:2c81:6cd7:5872:4e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id A8E8661FA2; Tue, 14 Nov 2017 09:26:00 +0000 (UTC) Message-ID: <5A0AB6A7.1050807@redbarn.org> Date: Tue, 14 Nov 2017 01:25:59 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Dave Lawrence CC: dnsop@ietf.org References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> In-Reply-To: <23050.45832.787089.325014@gro.dd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 09:26:02 -0000 Dave Lawrence wrote: > Dave Lawrence writes: >> The main changes, based on previous feedback, are: >> >> * Clarifying what the action is for Standards Track; >> * Describing the algorithm previously proposed (and still included) as >> one example way of achieving the goals; and, >> * Adding a rough proposal for an EDNS option that could be used for >> explicit signalling. >> >> That last item will be fleshed out more if there's demonstrated >> interest from implementers in having such a thing. > > At the moment I'll observe there are no open issues against the draft, > which is my comically passive-aggressive way of pointing out that it > is obviously perfect and so let's just move it along to Last Call. i apologize for my silence. there's been a lot going on in this WG. > > This is now your opportunity to correspondingly observe that someone > is wrong on the Internet and to respond appropriately. At the very > least, we'd like to know whether there is sufficient support for > pursuing the EDNS option or just to take it back out (and leave the > rest of the obviously perfect document as-is). this document must not proceed without explicit signaling, because this practice must not grow without explicit signaling. > > Thanks in advance for any feedback, you're welcome in advance! -- P Vixie From nobody Tue Nov 14 01:51:24 2017 Return-Path: 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 DBE31126CC7 for ; Tue, 14 Nov 2017 01:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=iVAAjbDP; dkim=pass (1024-bit key) header.d=yitter.info header.b=lSkCjEET 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 AiHr7kKcAg71 for ; Tue, 14 Nov 2017 01:50:57 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E65124B09 for ; Tue, 14 Nov 2017 01:50:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 13F23BF56B for ; Tue, 14 Nov 2017 09:50:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510653057; bh=BJ2GOiimTGysYhHF8a0hpemD/RvSHL4bdhfw5bVgjZ4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=iVAAjbDPaq9frFapqTK9KbJgqoEFZenTB3oa6gEg7m9qV78h9KsYmMQ76d9Oa30gg aDRi54u/IQpDjsPgsl8gwbuHDN8kyzoMyMcqdC8/9SX6DAYoszcwu/35BKmcSOgKVH IVeNlXDheXbG5BFKv5LE3ERHwhf8QuOD5/xpkAZs= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF2dzGwH4ANy for ; Tue, 14 Nov 2017 09:50:55 +0000 (UTC) Date: Tue, 14 Nov 2017 04:50:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510653055; bh=BJ2GOiimTGysYhHF8a0hpemD/RvSHL4bdhfw5bVgjZ4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=lSkCjEETwWj/7amB0hRsEAs0lWaZBsEp4R2ejcTU84lGGub6wcdTT59VwT7LIrYM5 bRk8z8qsIMWmo3G8hM8pUqhbMuNqhN9xacr8SPg5fIRUB8ykxsZi0CagyOfMiLdk+0 AT/Z0w+3qh77zupGu4zFGpdRvektbd/I9i+MOQL4= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171114095044.yowfpwlsyfvdsgss@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171112131831.GA32208@laperouse.bortzmeyer.org> <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <5A09C4D6.6080202@redbarn.org> <20171114063209.gjubqyovnwcrl33a@mx4.yitter.info> <5A0A952F.1060001@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A0A952F.1060001@redbarn.org> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 09:51:22 -0000 Hi, On Mon, Nov 13, 2017 at 11:03:11PM -0800, Paul Vixie wrote: > > there is no reason for an authority server to know who the root name servers > are. so, there can be no expectation that it would know any "closer" name > server set than the one at its zone bottom. I think your claim there depends on a strict role separation that is not in the protocol definition (yet). It implies that there is such a thing as "an authority server", whereas it seems to me that we have not defined servers quite so exclusively (yet). Interestingly (and really helpfully I must emphasise), you have just made me realise that there's actually a problem in the definition of "authoritative server" in 7719 and -bis. In that definition, we quote 2182: A server that knows the content of a DNS zone from local knowledge, and thus can answer queries about that zone without needing to query other servers. But then we go on to say that the server has been configured to answer with AA set for the zone. Yet that is not entailed by 2182's definition, for it seems to me that 2182's definition of "knows the content" could under one reading include the root hints file. I note that RFC 8109 doesn't actually cover the case of an authoritative server, and of course we haven't (yet) got consensus that mixed-mode servers are harmful, either. Now, one might argue (I can see such a reading, and I think it is what you are arguing) that the root hints file is RFC 1034's SBELT structure, and that 1034 defines SBELT is to "be used when the resolver doesn't have any local information to guide name server selection", and that the SBELT structure is anyway defined only for resolvers and not servers. All of that _should_ mean that a server that is only ever authoritative ought not to have this sort of information and probably also that it ought never to reveal it when the RD bit is clear even if it did have it. I think it is reasonble to say, however, that this information is not entirely clear from the RFCs as they currently stand, particularly since the algorithm in section 4.3.2 of RFC 1034 seems explicitly to contemplate having a cache, and it's not clear (at least to me) in that algorithm whether there are ever cases where a cache ought to be excluded completely from consideration. > since RFC 1034 talks about zone bottoms, and "closest enclosing", and its > algorithm speaks specifically of a referral being generated by copying > non-authoritative NS RRs from the zone bottom into the answer, there is no > reasonable interpretation of "closer" other than an NS RRset which is > closer, along the path from the zone apex to the qname, than the zone apex > was. in fact, from that algorithm, there is no way to generate a referral > other than by copying along-the-path data into an answer. Step 4 of the algorithm in RFC 1034 reads to me like a flat-out contradiction of your claim there: 4. Start matching down in the cache. If QNAME is found in the cache, copy all RRs attached to it that match QTYPE into the answer section. If there was no delegation from authoritative data, look for the best one from the cache, and put it in the authority section. Go to step 6. So your entire argument turns on whether a server should ever have a root hints file and use it. If there is written down somewhere advice that some class of servers should never have such information, I have overlooked it. > > This, too, seems to be a claim that is at best poorly justified. It > > might be that it is how BIND interprets the RCODE, but it's not what > > it is defined to be. > > it's defined as "administrative denial" not merely "widely interpreted as > administrative denial" as i wrote above. Where is it defined that way? RFC 1035 just says it is refused "for policy reasons", and the IANA registry is less descriptive than that because it refers to RFC 1035. I'm unaware of another place this is defined. > "no." the client isn't asking for an upward referral, it's asking for an > answer, and is expecting either an answer (positive or negative or empty) or > an on-the-path referral copied from the non-authoritative data at the bottom > of the authority zone. I don't think that you have shown this follows from the algorithm, and the fact that clients seem not to spit up on root referrals strikes me as empirical evidence that your assertion of what the client is expecting is at least in doubt. > < particular requester Right. Such as, for instance, not wishing to provide the upward referral (or anything else). The particular requester might be a member of the class, "all requesters asking for zones for which I am not authoritative". I get why your interpretation is one plausible one, but I do not see that it is the _only_ one. > as witnessed in discussions of the u.s. constitutions and the christian > bible, arguments about the literal intent of the authors are interesting > mostly to scholars, whereas our concern should be with the actions taken by > the far end given the data pattern we transmit and the circumstances as we > know them. Well, I want to be neither talmudic nor supreme. I don't think I disagree with your view (though FWIW I find your tone a little patronizing), but I think we are doing two things in this discussion: 1. Providing fodder for a draft I've already started writing that provides guidance not to return upward referrals. 2. Providing the necessary information for the terminology document so that we have written down our current best understanding of terms as people use them. I do not believe that (2) ought to include an effort to define terms to exclude operations we (for some value of we) think are a bad idea. IMO, the goal of 7719bis is not to define problems out of existence but to give us a clear and common set of terms to talk about all of this, _so that_ we can specify improvements to what the traditional specifications say. > while specific guidance was not given as to resolver action in response to > each possible authority RCODE, i have both witnessed and implemented full > resolvers which treated REFUSED as a permanent failure whereas SERVFAIL was > a temporary failure. And that "permanent failure" marks the server dead, not the server-qname or even server-zone combination dead, I guess. I think I have seen this too. That seems like another thing that ought to be documented, however, as a possible issue: at least one full service resolver interprets an RCODE somewhat more liberally than the specification does under some (other) plausible reading. I'm here to document things so that we can maximise interoperation, not specify what is Correct. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Nov 14 04:09:16 2017 Return-Path: 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 427A8126D74 for ; Tue, 14 Nov 2017 04:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 h6C5pVGrMJGn for ; Tue, 14 Nov 2017 04:09:12 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 88682120726 for ; Tue, 14 Nov 2017 04:09:12 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:36202) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eEa1T-0002xS-0e (Exim 4.89) (return-path ); Tue, 14 Nov 2017 12:08:59 +0000 Date: Tue, 14 Nov 2017 12:08:59 +0000 From: Tony Finch To: Evan Hunt cc: Mark Andrews , Edward Lewis , "dnsop@ietf.org" In-Reply-To: <20171113233756.GA37394@isc.org> Message-ID: References: <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <20171113183004.GA35038@isc.org> <436111CF-FCA8-44A2-B83D-6540DE6D64AC@icann.org> <66BA5F27-B044-459B-A2B2-54221FD768C6@isc.org> <20171113233756.GA37394@isc.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 12:09:14 -0000 Evan Hunt wrote: > > In the present context, I was only suggesting this method be used for > NOTIFY, not UPDATE -- to signal the parent that it should poll the child > for CDS/CDNSKEY. (I guess CSYNC could be included in the mix as well, > though, for updating NS and glue.) Yes. > I would suggest the child should be polled periodically regardless. If > the SRV record were spoofed, causing the child to send a NOTIFY to the > wrong address, synchronization should still occur, just not as quickly. The starting point for this thread was parental agents saying they don't like polling, but having thought about this a bit more I think I agree that it would be unwise not to poll. If there's a way to get polled early by NOTIFY then that's probably still good for both parent and child - parent can poll more slowly, and child can get prompt updates. I read Mark Elkins' article with interest. I would prefer to use NOTIFY rather than a web hook because it's much more plausible to imagine supporting this inside a DNS server with some kind of notify-parent feature. I like the idea of being able to automatically discover where to send parental notifies. But this can only work if the parental agent doesn't require TSIG. On the other hand, we can't rely on autodiscovery because I wouldn't bet on the registries publishing the necessary SRV records... Any opinions on whether this is worth pursuing? Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Viking, North Utsire: Northwesterly backing westerly 5 to 7. Moderate or rough, occasionally very rough later in north. Squally showers. Good. From nobody Tue Nov 14 06:44:51 2017 Return-Path: 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 453FE126C0F for ; Tue, 14 Nov 2017 06:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 LcgNFvtLQ7Ca for ; Tue, 14 Nov 2017 06:44:47 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B319712426E for ; Tue, 14 Nov 2017 06:44:47 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 14 Nov 2017 06:44:45 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 14 Nov 2017 06:44:45 -0800 From: Edward Lewis To: Paul Wouters CC: Evan Hunt , "dnsop@ietf.org" , =?utf-8?B?UGV0ciDFoHBhxI1law==?= Thread-Topic: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record Thread-Index: AQHTXO52tQkp3dARdE2OI0U03tcjj6MUencA Date: Tue, 14 Nov 2017 14:44:45 +0000 Message-ID: <7FE86715-53B2-4C9E-ACFE-22465B0E75EF@icann.org> References: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> <20171109174804.GA63012@isc.org> <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org> <463C4A1E-D189-4A0D-9814-D215F930B0D4@nohats.ca> In-Reply-To: <463C4A1E-D189-4A0D-9814-D215F930B0D4@nohats.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3593497484_1473080730" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 14:44:49 -0000 --B_3593497484_1473080730 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 11/13/17, 21:15, "DNSOP on behalf of Paul Wouters" wrote: >> I'm not sure that the need for robustness outweighs the expectation of s= omeone explicitly adding a trust anchor anymore. >But that=E2=80=99s not your call to make, but the call of the entity deciding to= put in that hard-coded trust anchor. To clarify, the "robustness" was the goal of the protocol design leading up= to the 2004 publication of the current DNSSEC definition, it's not a call a= nyone is making now. The goals of robustness, local policy, and other factors fed into the curre= nt design. How these, sometimes conflicting, objectives were weighted was s= ubjective and with more 20/20 hindsight, perhaps the weightings were wrong. =20 >We just ask you not to block us from doing as we have been doing for years= . I don't know how to take this - what's being discussed is the way the proto= col was designed in the past versus how implementations have chosen to go. = In the spirit of code trumps spec, then specifications need to catch up if t= here's a deviation. >I would like split-DNS to die too but I dont think that=E2=80=99s happening soon= . Arguing split-DNS would be another thread, I want to clarify that the "too"= in your quote shouldn't implicate anything I've said about split-DNS meanin= g I wished it to "go away". (I.e., I see split-DNS as a reality.) --B_3593497484_1473080730 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTuzc9A+/XK8lgo1DVqajKA37NpQjAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMTQxNDQ0NDRaMA0GCSqGSIb3 DQEBAQUABIIBACu1SRETEIML4WJm9UUYx9dTfSxfXDwoUVgrw52ulZ1D8mMgRmgc5GOaq2Yo s1S4x3c+We4dyM2qOKB3wYLL3ipVc9iGfcMm7eg2EwUFx0adTHY4BhVbJ5s/EVvPFyfHz+9p wH30SK+E9WbRarAex5g8pJYA04ohOgBft44wlYiF7xUGMu8t+VPni6Vq8vl6zH1wRAEMJ2qe aESwAgBuvjiedbnrwjFO+eYr7XYisZqkbVCM6g/Biuf0eE1o4Q5p5h9j8bvEphg6LZQPzRlE NUrM2LBolmFJa9FvPmD+obq2WowlGc3l1pcdcy8242ZGxti928mMKmGBGcju9tMSgg8= --B_3593497484_1473080730-- From nobody Tue Nov 14 07:09:32 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA9B1271FD; Tue, 14 Nov 2017 07:09:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151067217119.5956.14531432430759507943@ietfa.amsl.com> Date: Tue, 14 Nov 2017 07:09:31 -0800 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-01.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 15:09:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Transport over TCP - Operational Requirements Authors : John Kristoff Duane Wessels Filename : draft-ietf-dnsop-dns-tcp-requirements-01.txt Pages : 15 Date : 2017-11-14 Abstract: This document encourages the practice of permitting DNS messages to be carried over TCP on the Internet. It also describes some of the consequences of this behavior and the potential operational issues that can arise when this best common practice is not upheld. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-dns-tcp-requirements-01 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-tcp-requirements-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-tcp-requirements-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 14 08:06:56 2017 Return-Path: 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 64B4C1273E2 for ; Tue, 14 Nov 2017 08:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 axnvNBvEJstX for ; Tue, 14 Nov 2017 08:06:47 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841521271FD for ; Tue, 14 Nov 2017 08:06:47 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id s11so10225767pgc.5 for ; Tue, 14 Nov 2017 08:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fYVdps3Tjc0Ii2tN63EwBlYQZJSD8X22vv20YJ38L1I=; b=px6nkoSNe0mLlOw95TGKbtAVhEAP3vZ0/L/+c766et8xmfVZg2OvEqAB4lsH66Eglp ptnUoV5Ede9ucCqPeAzT0ANfGmpN1Yg2j0veRB9F+oL/2lI/AzPMBPtTqK3uH5VapOD0 14ng0wCDfbexID3b4fCQjR2LZGXZIv+Y7awwF/EyMXWjMvEDgooqVkBbFwDf4roDUR8R h8Yf3fnuN+tqaK2c12f5w/UhUuK103zxHE6oP4rQSmlR5h0plgtjjbIty8eB8wb+zzs4 5ox0cpbwFzw7CSfFTVZGM0ibrJ3YgfVotacloBpHmRLXcZVlYgu+gh7C3tY5Ba+ReZVs ylyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fYVdps3Tjc0Ii2tN63EwBlYQZJSD8X22vv20YJ38L1I=; b=bluAzlt9VNscgGURUEQBxQCNlRTYyxYnII0ci37UiuV/AcM71Ht14X3mJvSe+MywIC JhlzBnNmZ+iCiZD9RMmHyOuw2V904yStNsc/CwtT+bhNkheepNLF/Pn66FZao6235+z3 scbFo4Fn31BomXKcOgIBPQAbqBnWZA5pJpjyLodv6KmyeAOhfyOhAusFOfsX+ud2mB2u yE/4bRzlI0mO5UkeOWSyLMhG0zUilcek0HEpBFeQJf3/7iDF9ket9myWam7/M3dFee3w 5krNs7XEDqBkZf259dIuuLArIcRESu9wDJH34WFgqBf2SU4WlwssCvwbtSkaU/uCo0eP csKQ== X-Gm-Message-State: AJaThX7B49xgUqOw+eP3VfluEzQlqYhib0EuLpAHIwFQlHj66suaKsPg spf6HtaiZ/E/J71irx3N55wxTrDtwIs2DkFIFxvrDA== X-Google-Smtp-Source: AGs4zMYuqNeNqPe+zoZ5TU8G8nhnQBc9Ke+NnXpj3XZy9PQlj2k39nc9nXZsr80/79U14vnb15WGvn9+W9XDhqvco/Y= X-Received: by 10.84.179.67 with SMTP id a61mr11630019plc.338.1510675606845; Tue, 14 Nov 2017 08:06:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.171.6 with HTTP; Tue, 14 Nov 2017 08:06:45 -0800 (PST) In-Reply-To: <23050.45832.787089.325014@gro.dd.org> References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> From: Bob Harold Date: Tue, 14 Nov 2017 11:06:45 -0500 Message-ID: To: Dave Lawrence Cc: IETF DNSOP WG Content-Type: multipart/alternative; boundary="94eb2c11a6c0ead171055df392a5" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 16:06:54 -0000 --94eb2c11a6c0ead171055df392a5 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 14, 2017 at 4:10 AM, Dave Lawrence wrote: > Dave Lawrence writes: > > The main changes, based on previous feedback, are: > > > > * Clarifying what the action is for Standards Track; > > * Describing the algorithm previously proposed (and still included) as > > one example way of achieving the goals; and, > > * Adding a rough proposal for an EDNS option that could be used for > > explicit signalling. > > > > That last item will be fleshed out more if there's demonstrated > > interest from implementers in having such a thing. > > At the moment I'll observe there are no open issues against the draft, > which is my comically passive-aggressive way of pointing out that it > is obviously perfect and so let's just move it along to Last Call. > > This is now your opportunity to correspondingly observe that someone > is wrong on the Internet and to respond appropriately. At the very > least, we'd like to know whether there is sufficient support for > pursuing the EDNS option or just to take it back out (and leave the > rest of the obviously perfect document as-is). > > Thanks in advance for any feedback, > tale > I think signaling between the client and resolver is important. I am a little concerned about yet another option that the client might want to send with every query. Can the existence of *any* EDNS option from the client be taken to mean that EDNS options are understood in general, and the resolver is ok to respond with this ENDS option, which the client might not understand but will not choke on? Signalling between the resolver and authoritative server gets more complicated. Probably a good idea, but if the defaults are reasonable, it probably won't need to be used often. -- Bob Harold --94eb2c11a6c0ead171055df392a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Tue, Nov 14, 2017 at 4:10 AM, Dave Lawrence <tale@dd.org> wrote= :
Dave Lawrence writes:<= br> > The main changes, based on previous feedback, are:
>
> * Clarifying what the action is for Standards Track;
> * Describing the algorithm previously proposed (and still included) as=
>=C2=A0 =C2=A0one example way of achieving the goals; and,
> * Adding a rough proposal for an EDNS option that could be used for >=C2=A0 =C2=A0explicit signalling.
>
> That last item will be fleshed out more if there's demonstrated > interest from implementers in having such a thing.

At the moment I'll observe there are no open issues against the = draft,
which is my comically passive-aggressive way of pointing out that it
is obviously perfect and so let's just move it along to Last Call.

This is now your opportunity to correspondingly observe that someone
is wrong on the Internet and to respond appropriately.=C2=A0 At the very least, we'd like to know whether there is sufficient support for
pursuing the EDNS option or just to take it back out (and leave the
rest of the obviously perfect document as-is).

Thanks in advance for any feedback,
tale

=
I think signaling between the client and r= esolver is important.=C2=A0 I am a little concerned about yet another optio= n that the client might want to send with every query.=C2=A0 Can the existe= nce of *any* EDNS option from the client be taken to mean that EDNS options= are understood in general, and the resolver is ok to respond with this END= S option, which the client might not understand but will not choke on?

Signalling= between the resolver and authoritative server gets more complicated.=C2=A0= Probably a good idea, but if the defaults are reasonable, it probably won&= #39;t need to be used often.

--=C2=A0
Bob Harold<= /div>

--94eb2c11a6c0ead171055df392a5-- From nobody Tue Nov 14 08:23:22 2017 Return-Path: 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 A6426128D44 for ; Tue, 14 Nov 2017 08:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 SFUssfIXFrNq for ; Tue, 14 Nov 2017 08:23:18 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397E4128BC8 for ; Tue, 14 Nov 2017 08:23:18 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id j28so12439756pfk.8 for ; Tue, 14 Nov 2017 08:23:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QT9BEnnritPfLk8+a3xyMzCZJGYZbI1T4yVAlfw4bNY=; b=DH6t86UF5oYmnKqcPEz4whiweJwn3AwYipfRmLmC+yJ34bZrIUsnXg2O0gmDJWigyt a4WtMga+pGbfATDEy7dW1osaeDFNUep47qsdke32gq1VdVITxSaFySSBFkJA9qGNQTnC IHWc9Zy1aQ4MIAeXb3onHmUGnGfN4HdwIx22weBsd34kP0a2c6w+O8btTIWAs8vOviXk u/kJW9SkKIz+PiOSfGQ9oUbqqfLHw5G2pqrMYRE4zkzdVW5jWHso7mvYwOTtAdetQcOP YsfRRwqhqNJ0KTaqq01/o2wEIKqffb08W+x3DEWW5ligbv2iGYfj1y6Cwks+3ySG/JQ/ bQew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QT9BEnnritPfLk8+a3xyMzCZJGYZbI1T4yVAlfw4bNY=; b=tDuj7yPg7dmcRemWeQkdR/PZuKIO3n2tssGv4T/xtjoTS/l13kENglITJP2D2cTYHB vEcjO/ILbt/w3eYMx21wu0kxHv6polYsMYlFc0dkz0jeEAtFJuRQZDk4XYBbqn0piUsE LKQAkR1F/o17yu2bVqH3UllXAQVyRLurdW49zRHscEW0jEb0a3kFYbjyxpNH8JwwWote hsN5VQQ/bVSxpunzfuC6ie5b9xiswE6YsDT0SBVjFuizfx8OI4t4IlbBRISpv7YKxPM9 DWngpVuTbAhdwLQIuKEALcXsYwtz8rSL4bGlfcphJeK7NRDbEo/ZWYdZM07PoRZlTHsn kHTg== X-Gm-Message-State: AJaThX6Y7FBmDefFsRpho7zkL/L9lkKfNpZ19mZGm7ub+LsI5fME596s fHuL/lo4LRleCNZPF8ZoKCxN9RdkD7NdW2lRoI1dgfX9 X-Google-Smtp-Source: AGs4zMZeuaMq+8RWl8hECmAr4yyAIMOnaj4zkk6yPmslE2lrI/ZIhXUjulNogubGdMYRzRhAqc6PfRqCFppIp3iUEjw= X-Received: by 10.101.82.76 with SMTP id q12mr5733651pgp.140.1510676597560; Tue, 14 Nov 2017 08:23:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.171.6 with HTTP; Tue, 14 Nov 2017 08:23:16 -0800 (PST) In-Reply-To: <151062636258.5917.14497839377888768972@ietfa.amsl.com> References: <151062636258.5917.14497839377888768972@ietfa.amsl.com> From: Bob Harold Date: Tue, 14 Nov 2017 11:23:16 -0500 Message-ID: To: internet-drafts@ietf.org Cc: IETF DNSOP WG Content-Type: multipart/alternative; boundary="f403043e6878f7e8e3055df3cd74" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 16:23:22 -0000 --f403043e6878f7e8e3055df3cd74 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 13, 2017 at 9:26 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : A Sentinel for Detecting Trusted Keys in DNSSEC > Authors : Geoff Huston > Joao Silva Damas > Warren Kumari > Filename : draft-huston-kskroll-sentinel-04.txt > Pages : 8 > Date : 2017-11-13 > > Abstract: > The DNS Security Extensions (DNSSEC) were developed to provide origin > authentication and integrity protection for DNS data by using digital > signatures. These digital signatures can be verified by building a > chain of trust starting from a trust anchor and proceeding down to a > particular node in the DNS. This document specifies a mechanism that > will allow an end user to determine the trusted key state of the > resolvers that handle the user's DNS queries. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-huston-kskroll-sentinel-04 > https://datatracker.ietf.org/doc/html/draft-huston-kskroll-sentinel-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-huston-kskroll-sentinel-04 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Looks like you clarified that "_is-ta-." and "_not-ta-." are the left-most labels. Thanks, that's an improvement. I like the draft. If I have to add those entries to each zone, I worry that the automated DNS appliance that I use might not be able to create the broken records required. But I am not using DNSSEC yet, so that is a future issue for me. Still waiting for more automation (CDSKEY etc) and 'time' to work on it. -- Bob Harold --f403043e6878f7e8e3055df3cd74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Nov 13, 2017 at 9:26 PM, <internet-drafts@ietf= .org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A Sentinel for Detecting Trusted Keys in DNSSEC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Geof= f Huston
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Joao Silva Damas
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Warren Kumari
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-hus= ton-kskroll-sentinel-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-11-13

Abstract:
=C2=A0 =C2=A0The DNS Security Extensions (DNSSEC) were developed to provide= origin
=C2=A0 =C2=A0authentication and integrity protection for DNS data by using = digital
=C2=A0 =C2=A0signatures.=C2=A0 These digital signatures can be verified by = building a
=C2=A0 =C2=A0chain of trust starting from a trust anchor and proceeding dow= n to a
=C2=A0 =C2=A0particular node in the DNS.=C2=A0 This document specifies a me= chanism that
=C2=A0 =C2=A0will allow an end user to determine the trusted key state of t= he
=C2=A0 =C2=A0resolvers that handle the user's DNS queries.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc= /draft-huston-kskroll-sentinel/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-h= uston-kskroll-sentinel-04
https://datatracker.ietf.org/<= wbr>doc/html/draft-huston-kskroll-sentinel-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-huston-kskroll-sentinel-04


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


Looks like you clarified that "_is-ta-<tag-in= dex>." and "_not-ta-<tag-index>." are the left-most= labels.
Thanks, that's an improvement.

I like the draft.

If I have to add those e= ntries to each zone, I worry that the automated DNS appliance that I use mi= ght not be able to create the broken records required.=C2=A0 But I am not u= sing DNSSEC yet, so that is a future issue for me.=C2=A0 Still waiting for = more automation (CDSKEY etc) and 'time' to work on it.
--=C2=A0
Bob Harold


--f403043e6878f7e8e3055df3cd74-- From nobody Tue Nov 14 09:53:06 2017 Return-Path: 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 3856312869B for ; Tue, 14 Nov 2017 09:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 yqfZxLxvtSM4 for ; Tue, 14 Nov 2017 09:53:03 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 42C7F12009C for ; Tue, 14 Nov 2017 09:53:03 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 61A193B8594; Tue, 14 Nov 2017 17:53:00 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 4C450216C1C; Tue, 14 Nov 2017 17:53:00 +0000 (UTC) Date: Tue, 14 Nov 2017 17:53:00 +0000 From: Evan Hunt To: Paul Vixie Cc: dnsop@ietf.org Message-ID: <20171114175300.GA45323@isc.org> References: <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <5A09C4D6.6080202@redbarn.org> <20171114063209.gjubqyovnwcrl33a@mx4.yitter.info> <5A0A952F.1060001@redbarn.org> <20171114080638.GA41253@isc.org> <5A0AA777.9010908@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A0AA777.9010908@redbarn.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 17:53:04 -0000 On Tue, Nov 14, 2017 at 12:21:11AM -0800, Paul Vixie wrote: > i mean propagating REFUSED back to the stub so that it can return an > error to its application or user. Okay. I haven't encountered a resolver that propgates REFUSED from the authority to the stub. If there is such a beast, then IMHO that, not the authority, is the one that's mis-using REFUSED; REFUSED only makes sense on a hop-by-hop basis. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Tue Nov 14 12:02:40 2017 Return-Path: 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 10655128B51 for ; Tue, 14 Nov 2017 12:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 p5_ZqZviSq8d for ; Tue, 14 Nov 2017 12:02:36 -0800 (PST) Received: from mx2.cira.ca (mx2.cira.ca [192.228.22.117]) by ietfa.amsl.com (Postfix) with ESMTP id 2370F1242F7 for ; Tue, 14 Nov 2017 12:02:31 -0800 (PST) X-Virus-Scanned: by SpamTitan at corp.cira.ca Received: from CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) by CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Tue, 14 Nov 2017 15:02:28 -0500 Received: from CRP-EX16-02.CORP.CIRA.CA ([fe80::15c6:1482:4083:e9f7]) by CRP-EX16-02.CORP.CIRA.CA ([fe80::15c6:1482:4083:e9f7%13]) with mapi id 15.01.0669.032; Tue, 14 Nov 2017 15:02:28 -0500 From: Jacques Latour To: Tony Finch , Evan Hunt CC: Edward Lewis , "dnsop@ietf.org" Thread-Topic: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35) Thread-Index: AQHTXJLOsSgnJWB7GEuhsqDmioRxpaMS9YQAgAAEXgCAADr1gIAAFrIAgADR14CAADB2AA== Date: Tue, 14 Nov 2017 20:02:28 +0000 Message-ID: References: <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <20171113183004.GA35038@isc.org> <436111CF-FCA8-44A2-B83D-6540DE6D64AC@icann.org> <66BA5F27-B044-459B-A2B2-54221FD768C6@isc.org> <20171113233756.GA37394@isc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [10.2.36.1] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8A99D827472D2C42B195219774B69F13@cira.ca> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 20:02:38 -0000 Parental synchronization is inevitable so we would be better to find the best way to make it happen. I think there are 3 plausible methods to do the synchronization. 1. Child Notification: Child sends NOTIFY to a predefined parental destination. The parent then polls the child zone for changes and EPP commands issued to reflect the changes. 2. DNS Operator Notification: DNS Operator changes the child zone. DNS Operator finds parental agent API via RDAP or TCKL to notify of changes to be performed. The parent then polls the child zone for changes and EPP commands issued to reflect the changes. -=20 https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-to-rrr-protocol-0 4 - parental agent can be the registrar or the registry 3. Parent Polling*: On a batch/regular basis, the parent then polls all child zones for changes and EPP commands issued to reflect the changes. *The parent can be the registrar or the registry. - a la cz.nic, full zone polling (https://en.blog.nic.cz/2017/06/21/lets-make-dns-great-again/) - it would be nice to send an EPP poll message to the registrar when a domain is changed by the TLD - some of the research we=B9ve done shows that there are no ICANN policy impact of doing #3 across the board (ccTLD and gTLD). Personally, I like a mix of #3 and #1, on a regular basis poll the entire zone for changes, and have a mechanism to listen to child notifications for urgent changes. _AND_ remember, the preferred method by far is to submit a DS/DNSKEY record is via the RRR EPP model. The above is when that RRR EPP model is non functional. Jack On 2017-11-14, 7:08 AM, "DNSOP on behalf of Tony Finch" wrote: >Evan Hunt wrote: >> >> In the present context, I was only suggesting this method be used for >> NOTIFY, not UPDATE -- to signal the parent that it should poll the child >> for CDS/CDNSKEY. (I guess CSYNC could be included in the mix as well, >> though, for updating NS and glue.) > >Yes. > >> I would suggest the child should be polled periodically regardless. If >> the SRV record were spoofed, causing the child to send a NOTIFY to the >> wrong address, synchronization should still occur, just not as quickly. > >The starting point for this thread was parental agents saying they don't >like polling, but having thought about this a bit more I think I agree >that it would be unwise not to poll. If there's a way to get polled early >by NOTIFY then that's probably still good for both parent and child - >parent can poll more slowly, and child can get prompt updates. > >I read Mark Elkins' article with interest. I would prefer to use NOTIFY >rather than a web hook because it's much more plausible to imagine >supporting this inside a DNS server with some kind of notify-parent >feature. > >I like the idea of being able to automatically discover where to send >parental notifies. But this can only work if the parental agent doesn't >require TSIG. On the other hand, we can't rely on autodiscovery because >I wouldn't bet on the registries publishing the necessary SRV records... > >Any opinions on whether this is worth pursuing? > >Tony. >--=20 >f.anthony.n.finch http://dotat.at/ - I xn--zr8h >punycode >Viking, North Utsire: Northwesterly backing westerly 5 to 7. Moderate or >rough, occasionally very rough later in north. Squally showers. Good. > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue Nov 14 16:42:32 2017 Return-Path: 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 4FE7812940D for ; Tue, 14 Nov 2017 16:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 YYPygaPbQBaS for ; Tue, 14 Nov 2017 16:42:29 -0800 (PST) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4C41200B9 for ; Tue, 14 Nov 2017 16:42:29 -0800 (PST) Received: from localhost (dhcp-92bb.meeting.ietf.org [31.133.146.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id C5C7D28090; Tue, 14 Nov 2017 16:42:26 -0800 (PST) From: Wes Hardaker To: Geoff Huston Cc: Joe Abley , tjw ietf , dnsop , Wes Hardaker References: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> <3FFE9D39-DD16-4863-9F9B-46D585F90BF1@hopcount.ca> <9EAE2E1F-CE2E-4F9F-92B2-1FE2A6023492@apnic.net> Date: Tue, 14 Nov 2017 16:40:09 -0800 In-Reply-To: <9EAE2E1F-CE2E-4F9F-92B2-1FE2A6023492@apnic.net> (Geoff Huston's message of "Tue, 14 Nov 2017 08:37:55 +1100") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 00:42:30 -0000 Geoff Huston writes: >> I think the number 4 on the slide was different from the one in the mail. > > > I thought so too, but I wasn=E2=80=99t sure if it was me not paying atten= tion > in the WG meeting or not! Yes, you're both right. And absolutely my bad for writing the presentation without looking at the mail I sent and synchronizing the numbering. The preferred option in the room was the 16-bit value that would be used in combination with the rcode to indicate the full meaning of the extension value. --=20 Wes Hardaker USC/ISI From nobody Tue Nov 14 16:58:38 2017 Return-Path: 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 71256129454 for ; Tue, 14 Nov 2017 16:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tr4GSGEO6i5t for ; Tue, 14 Nov 2017 16:58:34 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E182312944B for ; Tue, 14 Nov 2017 16:58:32 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id z3so15122836wme.3 for ; Tue, 14 Nov 2017 16:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iPeOEBwKiESabK/FHrIQ6noVpYlnyEkcKSB2Qzb1zE0=; b=iBhhMC/UHRBCLNns8aQPdIvgLhoS+/5dqBr/Rri+pI7DNIw4jPGGifHfMTovxcsltG GWG1tXmaoa5DXihNSxfiDwFH1o1KLmSg0UbRWWrJKyiicXxOMF7HmjuV2VNVUxelVS7m VTELhWYzwwhGqvdkqXAAuyZX9HNlLkQR/O6C6Bnj9EP84pBk40q9SS8f7c5AAMB3u/dd QbZkPK7Atu5cUbWcoxxQv9Ufut6IK8eWJL7GLaco6TXx+61X03YFFcMyAf2nqghoYdbS NDyU2iFBGic5Dij9EsStoWBt1BVz/C87unfjR/voyxcW3IimvFlj1+evhLdgpchpnc2L Xdfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iPeOEBwKiESabK/FHrIQ6noVpYlnyEkcKSB2Qzb1zE0=; b=TOEfNHN77uvPUmw4s+0TWWUDb8NK2qVmOrpOFLMimb+ixWsMEkZ4BYs7yt0nj8r6YM HcSzTOz4BvGHtqD/pKmxlseRefnMOd6Qt9XfVGa/9HjG+4KKBfL6SSdoPapKibFP6KCg TWTzhU5g7sRlciOTxGYAj2YvsQzcf3hM95Kd3bikt5f5HvbfeOkJdSoxh22+AgX42KPy oze0s/04oX6sUik//vkVZHs0k/XfJCXonIRFPHZtM6IoS5VV2d57cCAqvB2p8CO8EKwy ycoUmIHJFVDAlPWEDym4N9NEhncccIzglTPxIDuab7QPse1cC8pbBbYun6Od+5V0JwLF 0Mxg== X-Gm-Message-State: AJaThX4d5omMObQTU1IuPuujtcaGotGfHjtPpi7HF8f2AGGOxCVh2OQd DTURIMwcZ5mnIQIlXpmj4LYI8rhsm6iBN3NR+6Q= X-Google-Smtp-Source: AGs4zMZpnCAoL4b3ycq08uZStkb0dgonxcxIkKWJw+EygCHeW/lBe9X4QoWfO8IkC3CQ/Z3T2qlGuE6tcIvr/gm1rbw= X-Received: by 10.28.30.151 with SMTP id e145mr9459839wme.8.1510707511450; Tue, 14 Nov 2017 16:58:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.196.169 with HTTP; Tue, 14 Nov 2017 16:58:30 -0800 (PST) In-Reply-To: References: <26DB1BD1-A877-482A-83B3-7A7F673AAB4A@apnic.net> <3FFE9D39-DD16-4863-9F9B-46D585F90BF1@hopcount.ca> <9EAE2E1F-CE2E-4F9F-92B2-1FE2A6023492@apnic.net> From: tjw ietf Date: Wed, 15 Nov 2017 08:58:30 +0800 Message-ID: To: Wes Hardaker Cc: Geoff Huston , Joe Abley , dnsop Content-Type: multipart/alternative; boundary="001a114b2efc945f95055dfb0012" Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 00:58:36 -0000 --001a114b2efc945f95055dfb0012 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Actually Wes, it was absolutely bad for me making the poor assumption on the choices aligned between the email and the slide. You are correct the preferred option we hear as the 16 bit value. On Wed, Nov 15, 2017 at 8:40 AM, Wes Hardaker wrote: > Geoff Huston writes: > > >> I think the number 4 on the slide was different from the one in the > mail. > > > > > > I thought so too, but I wasn=E2=80=99t sure if it was me not paying att= ention > > in the WG meeting or not! > > Yes, you're both right. And absolutely my bad for writing the > presentation without looking at the mail I sent and synchronizing the > numbering. > > The preferred option in the room was the 16-bit value that would be used > in combination with the rcode to indicate the full meaning of the > extension value. > -- > Wes Hardaker > USC/ISI > --001a114b2efc945f95055dfb0012 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Actually Wes, it was absolutely bad for me making= the poor assumption on the choices aligned between the email and the slide= .=C2=A0

You are correct the preferred option we he= ar as the 16 bit value.=C2=A0

On Wed, Nov 15, 2017 at 8:40 AM, Wes Hardaker <= wjhns1@hardakers.net> wrote:
Geoff Huston <gih@ap= nic.net> writes:

>> I think the number 4 on the slide was different from the one in th= e mail.
>
>
> I thought so too, but I wasn=E2=80=99t sure if it was me not paying at= tention
> in the WG meeting or not!

Yes, you're both right.=C2=A0 And absolutely my bad for writing = the
presentation without looking at the mail I sent and synchronizing the
numbering.

The preferred option in the room was the 16-bit value that would be used in combination with the rcode to indicate the full meaning of the
extension value.
--
Wes Hardaker
USC/ISI

--001a114b2efc945f95055dfb0012-- From nobody Tue Nov 14 17:45:53 2017 Return-Path: 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 57B2612945D for ; Tue, 14 Nov 2017 17:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 NqEiChs-yAf3 for ; Tue, 14 Nov 2017 17:45:51 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8505129418 for ; Tue, 14 Nov 2017 17:45:50 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id k66so12387814lfg.3 for ; Tue, 14 Nov 2017 17:45:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=k6+TNR0GpJJ+RXVj6alCzAWBFLJy9oq+/2NOC0a5c60=; b=Mtw6t/+fZF31hYjDkiUAtqc5lAJ1AfrqTpKYmvhgrMHQaRTo+Br2jQetQ3RJQM+vjl gtGiaCYVf8Wl4cD5AiL9uIzYQ01jChd1WwNFAAhX2zEpNtsMhdL9c7MdTBt3IY7UESWY gtmLtdlZUy58AZ67s0o6tt2BHamkXG8W3I0Vc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc; bh=k6+TNR0GpJJ+RXVj6alCzAWBFLJy9oq+/2NOC0a5c60=; b=sU2mhA5N7UD4WydegoLgZ81EKVyvLz8kSqqms6nvYMkR4C8NdzIfiD5UDrFaPLGe7b EmihzLcdSODFRFQxakigIOTMMBdD9sLxY6/LjoZ0QERl8qynakywKuigJL9HbTjPk0xa Mu7au2e/Y+IAqefvEc2XvOBP7yGlDyEZy/CoxcZwnWUfabGm1ra0Mmc6+o4qRztK2GqG RAS/s4NXDNiMirR9cFFd9o+xU/GjJigw+WpXJm3K0aAoTfMZ+9hAxAmI4O+jNWedtrfP M4gslnyi2SrQlntEi9gOqrOgVJhrgL5HOzZI0nXhlLDHPw1XEJBq3lXScrvLZeiK8RzI ciOQ== X-Gm-Message-State: AJaThX4AuVkhqeBf0xEUl8uIiEQxkdlHaZlm26RXS+vE20P260nL4hNc jBm+dBlJB2YfuPrMlZ2UpSVVCQzLNBk3NhuGmeEr3w== X-Google-Smtp-Source: AGs4zMYlJAhKGwd+9mvYF1Nc0oK/PeXLMj/WV7AZoEtF/IYK2EFZrUnOy9FhltrYjxDl7V/Zwbx9kAuXatlRMkd/HPw= X-Received: by 10.25.22.24 with SMTP id m24mr3684761lfi.185.1510710349131; Tue, 14 Nov 2017 17:45:49 -0800 (PST) From: Joe Abley Mime-Version: 1.0 (1.0) References: <151062636258.5917.14497839377888768972@ietfa.amsl.com> In-Reply-To: Date: Wed, 15 Nov 2017 09:45:47 +0800 Message-ID: <7572271693475788861@unknownmsgid> To: Bob Harold Cc: "internet-drafts@ietf.org" , IETF DNSOP WG Content-Type: multipart/alternative; boundary="001a11407b5eb80449055dfba928" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 01:45:52 -0000 --001a11407b5eb80449055dfba928 Content-Type: text/plain; charset="UTF-8" Hi Bob, On Nov 15, 2017, at 00:23, Bob Harold wrote: If I have to add those entries to each zone, I worry that the automated DNS appliance that I use might not be able to create the broken records required. Since the implementation of the mechanism requires special handling of queries whose QNAMEs contain the special labels, I don't see why you would ever need to add anything to any zone. The point of this mechanism is to require no administrator action and to be on by default, I think. Joe --001a11407b5eb80449055dfba928 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bob,

<= /div>
On Nov 15, 2017, at 00:23, Bob Harold <rharolde@umich.edu> wrote:

If I have to= add those entries to each zone, I worry that the automated DNS appliance t= hat I use might not be able to create the broken records required.=C2=A0
Since the implementation of the mechanism requires = special handling of queries whose QNAMEs contain the special labels, I don&= #39;t see why you would ever need to add anything to any zone.
The point of this mechanism is to require no administrator act= ion and to be on by default, I think.


Joe
--001a11407b5eb80449055dfba928-- From nobody Tue Nov 14 17:51:57 2017 Return-Path: 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 31A13128AFE for ; Tue, 14 Nov 2017 17:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] 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 ANNbYuPcaglK for ; Tue, 14 Nov 2017 17:51:55 -0800 (PST) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A49D1200CF for ; Tue, 14 Nov 2017 17:51:55 -0800 (PST) Received: from localhost (dhcp-8309.meeting.ietf.org [31.133.131.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 1AA382808D for ; Tue, 14 Nov 2017 17:51:53 -0800 (PST) From: Wes Hardaker To: dnsop@ietf.org Date: Tue, 14 Nov 2017 17:49:35 -0800 Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [DNSOP] 5011-security-considerations and the safetyMargin X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 01:51:56 -0000 The discussion has been long with respect to the safetyMargin in the 5011 security considerations document. There hasn't been a huge conclusion and many different ideas have been floated by, and we're now at the point where we need to pick between them. Below, I try to lay out the primary and sub-options available based on discussions so far. Please provide your opinions on your preference so I can wrap up this draft. Background: This document is not intended to provide operational guidance on what you SHOULD do. It's intended to draw the timing line below which you MUST NOT venture. The safetyMargin was introduced to prevent race conditions based on network delays, eg, which can mean that a RFC5011 Resolver operating at the same time as a PEP Publisher making a change at exactly at the minimum addWaitTime or addWallClockTime values would lead to a failure. So the primary question today is "how do we want to deal with this issue of real-world speed-of-light and other issues?". To complicate this a bit further, packets are never guaranteed to be delivered and network losses can entirely prevent a 5011 Resolver from succeeding at all for a given operation. Option 1. Include a safetyMargin of some value. 1A) safetyMargin = MAX(2*TTL, 1.5Hr) -- current draft 1B) safetyMargin = something based on the retryTime, (an example solution was suggested by MSJ) 1C) Your value here Option 2. Don't include a safetyMargin 2A) Just ignore the issues entirely 2B) Explain that this document does not cover operational complexities like retries (already in the -07 version), network delays and other operational issues. After thinking about this for far far too long, I've now switched my own opinion to that of 2C for the principal reason that this is the line-in-the-sand document, and to be honest people should be using values much larger than this, per MSJ's guidance on how 5011 should be used. Thus, it makes more sense to define this as the "MUST NOT go below this line" without trying to be precise about a value that can never be perfectly accurate, by definition. But, forget my opinion. What's yours? If nothing else, pick one of the [12][ABC] options above please, even without any text defining why you think so (until someone pokes you). -- Wes Hardaker USC/ISI From nobody Tue Nov 14 17:57:41 2017 Return-Path: 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 98571129477 for ; Tue, 14 Nov 2017 17:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hHNX5bmKGshL for ; Tue, 14 Nov 2017 17:57:38 -0800 (PST) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1841F1200CF for ; Tue, 14 Nov 2017 17:57:38 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id E83C73F442; Tue, 14 Nov 2017 20:57:36 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23051.40720.908131.277454@gro.dd.org> Date: Tue, 14 Nov 2017 20:57:36 -0500 From: Dave Lawrence To: IETF DNSOP WG In-Reply-To: References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 01:57:39 -0000 Bob Harold writes: > I am a little concerned about yet another option that the client > might want to send with every query. Can the existence of *any* > EDNS option from the client be taken to mean that EDNS options are > understood in general, and the resolver is ok to respond with this > ENDS option, which the client might not understand but will not choke on? I personally am of the belief that yes, if the request has an OPT then a responder can include an option code that was not in the request. At least I don't see anything in 6891 to prohibit it. This is behaviour that draft-ietf-dnsop-extended-error is also expecting. From nobody Tue Nov 14 18:04:39 2017 Return-Path: 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 1ADE6129418 for ; Tue, 14 Nov 2017 18:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OL0K9Sq_nYqv for ; Tue, 14 Nov 2017 18:04:37 -0800 (PST) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8261200CF for ; Tue, 14 Nov 2017 18:04:37 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 398663F432; Tue, 14 Nov 2017 21:04:36 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23051.41140.187552.962508@gro.dd.org> Date: Tue, 14 Nov 2017 21:04:36 -0500 From: Dave Lawrence To: dnsop@ietf.org In-Reply-To: <20171114175300.GA45323@isc.org> References: <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <5A09C4D6.6080202@redbarn.org> <20171114063209.gjubqyovnwcrl33a@mx4.yitter.info> <5A0A952F.1060001@redbarn.org> <20171114080638.GA41253@isc.org> <5A0AA777.9010908@redbarn.org> <20171114175300.GA45323@isc.org> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:04:38 -0000 Evan Hunt writes: > Okay. I haven't encountered a resolver that propgates REFUSED from the > authority to the stub. If there is such a beast, then IMHO that, not the > authority, is the one that's mis-using REFUSED; REFUSED only makes sense on > a hop-by-hop basis. Very much agree. I'd be surprised to see REFUSED from a resolver. Now on the other hand, using extended-error for signalling from a resolver that the known authorities all returned REFUSED, that's interesting and can be made unambiguous as a code apart from the currently proposed extended-error 4, "Prohibited". From nobody Tue Nov 14 19:27:07 2017 Return-Path: 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 21FAE1294C8 for ; Tue, 14 Nov 2017 19:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 CGKiMmP7-YAT for ; Tue, 14 Nov 2017 19:27:02 -0800 (PST) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) (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 6D4551292D3 for ; Tue, 14 Nov 2017 19:27:02 -0800 (PST) Received: by clone.registro.br (Postfix, from userid 1000) id 3252B2101F6; Wed, 15 Nov 2017 01:27:00 -0200 (BRST) Date: Wed, 15 Nov 2017 01:27:00 -0200 From: Frederico A C Neves To: Edward Lewis Cc: Evan Hunt , Petr =?utf-8?B?xaBwYcSNZWs=?= , "dnsop@ietf.org" Message-ID: <20171115032700.GE94801@registro.br> References: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> <20171109174804.GA63012@isc.org> <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org> Archived-At: Subject: Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 03:27:04 -0000 On Mon, Nov 13, 2017 at 03:45:30PM +0000, Edward Lewis wrote: > On 11/9/17, 12:48, "DNSOP on behalf of Evan Hunt" wrote: > > > On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr Špaček wrote: > > > Nice write-up Edward! You have nicely summarized why Mark and me agree > > > that validator should use longest suffix match when selecting TA to > > > validate data. > > > > +1. > > Hmmm, that wasn't my intent. ;) I had been trying to justify the other conclusion. But, if my work is leading you towards this "other" conclusion, I've been taking time to understand why. > > I'm beginning to have a new understanding on this. The overlooked (by me) point is that we are focusing on a situation where the local operator has chosen to explicitly configure a trust anchor. Beside code distributions shipping with the IANA managed KSK (or its DS form) for the global public Internet's root zone, if any operator wants another trust anchor point, they have to take explicit action to configure it. The question is - what is the expectation of the operator in doing this? > > There was a time when TLDs were signed but the root zone was not. Then operators had to configure trust anchors for the TLDs to enable validation. When the root zone was signed in 2010, the TLDs had to remind all those with trust anchors to remove them (before the TLD could change it's KSK). I can no longer find reports of the efforts to undo TLD trust anchors (Sweden and maybe CzechRep?) that I thought were once floating around. "Fears" surrounding this would lead one to favor the more open "any" policies, on the other hand, mass migration from TLDs to root for the top of the trust chain was probably a one-time event as a result of the on-set of DNSSEC in the root zone. > Yes. And add to that cases were TLDs rolled just before adding to the root. https://eng.registro.br/pipermail/gter/2010-May/027981.html https://eng.registro.br/pipermail/gter/2010-June/028053.html https://eng.registro.br/pipermail/gter/2010-July/028138.html Fred From nobody Tue Nov 14 19:36:31 2017 Return-Path: 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 ECBB01274A5 for ; Tue, 14 Nov 2017 19:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0dXbVjO6R11C for ; Tue, 14 Nov 2017 19:36:29 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF91126CBF for ; Tue, 14 Nov 2017 19:36:29 -0800 (PST) Received: from [10.170.78.140] (unknown [65.158.49.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id D0AF361FA2; Wed, 15 Nov 2017 03:36:28 +0000 (UTC) Message-ID: <5A0BB63B.70607@redbarn.org> Date: Tue, 14 Nov 2017 19:36:27 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Dave Lawrence CC: IETF DNSOP WG References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <23051.40720.908131.277454@gro.dd.org> In-Reply-To: <23051.40720.908131.277454@gro.dd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 03:36:30 -0000 Dave Lawrence wrote: > Bob Harold writes: >> I am a little concerned about yet another option that the client >> might want to send with every query. Can the existence of *any* >> EDNS option from the client be taken to mean that EDNS options are >> understood in general, and the resolver is ok to respond with this >> ENDS option, which the client might not understand but will not choke on? > > I personally am of the belief that yes, if the request has an OPT then > a responder can include an option code that was not in the request. > At least I don't see anything in 6891 to prohibit it. This is > behaviour that draft-ietf-dnsop-extended-error is also expecting. while i've seen every kind of misbehaviour from EDNS responders, i've yet to suspect that an initiator who knows EDNS in any form will choke on, or syslog about, unrecognized options in the response. so, +1 to tale. -- P Vixie From nobody Tue Nov 14 19:42:51 2017 Return-Path: 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 30F22128959 for ; Tue, 14 Nov 2017 19:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YgD37nCl2zM6 for ; Tue, 14 Nov 2017 19:42:48 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23482126B72 for ; Tue, 14 Nov 2017 19:42:48 -0800 (PST) Received: from [10.170.78.140] (unknown [65.158.49.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id E5E8461FA2; Wed, 15 Nov 2017 03:42:47 +0000 (UTC) Message-ID: <5A0BB7B5.8050804@redbarn.org> Date: Tue, 14 Nov 2017 19:42:45 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Dave Lawrence CC: dnsop@ietf.org References: <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <5A09C4D6.6080202@redbarn.org> <20171114063209.gjubqyovnwcrl33a@mx4.yitter.info> <5A0A952F.1060001@redbarn.org> <20171114080638.GA41253@isc.org> <5A0AA777.9010908@redbarn.org> <20171114175300.GA45323@isc.org> <23051.41140.187552.962508@gro.dd.org> In-Reply-To: <23051.41140.187552.962508@gro.dd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 03:42:49 -0000 Dave Lawrence wrote: > Evan Hunt writes: >> Okay. I haven't encountered a resolver that propgates REFUSED from the >> authority to the stub. If there is such a beast, then IMHO that, not the >> authority, is the one that's mis-using REFUSED; REFUSED only makes sense on >> a hop-by-hop basis. i'll stop arguing about it. > Very much agree. I'd be surprised to see REFUSED from a resolver. i think you'd be within your rights as a stub to treat REFUSED as your lack of permission to use that recursive, and not an end-to-end signal. this bolsters evan's observation of its ambiguity. > Now on the other hand, using extended-error for signalling from a > resolver that the known authorities all returned REFUSED, that's > interesting and can be made unambiguous as a code apart from the > currently proposed extended-error 4, "Prohibited". for each code we have to be explicit about what we expect the initiator to do in response. the reason i use SERVFAIL for NOTAUTH is because what i want the initiator to do when i'm configured as primary but can't read my zone file, or am configured as secondary but can't write my zone file, is the same as what i want when i'm not configured for the zone: cache this failure under a hold-down timer so as not to melt the tubez, but do try again later in case i'm merely late to change my config, or flubbed my config in some way. i think the need for a hold-down timer on cached SERVFAIL may be catching a number of you by surprise. but really, what we want for NOTAUTH, we already have to have for SERVFAIL. administrative denial is something else. -- P Vixie From nobody Tue Nov 14 19:47:42 2017 Return-Path: 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 CFC45126C22 for ; Tue, 14 Nov 2017 19:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 v3-uIRex5m7Y for ; Tue, 14 Nov 2017 19:47:34 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E49D1294C9 for ; Tue, 14 Nov 2017 19:47:24 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id k3so15406886ywk.8 for ; Tue, 14 Nov 2017 19:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uWjStv18iWffamtDoRNmdBtkPFd2MB677X+4vIXWgWI=; b=Q/77Jt1GcagqpwLAuI3qQj4dlib9kOPFeaq508qEE3UbaNn/vCQhciMZLMx1Rs3ovV YtCIWE6aHMGzMJ2RNHSCSjWkkVPQXO9Q/QCmpVhTfmKX50fCLtdISIURavsmjtuehixN cDKUAOYNw84VU3MCqZHfY3DS8i6/i8BoUFTjHcJkbgOgWX1hsnGOYheGSHh1C66+CLtt l0/4B/X/mi8DFiESDCyvgMvTnSnCWAJvKhkSbwcmzzgVj1YAySKBa6k71xajWhc/Wjy/ uNvYHqhKy5rAIpns+yE/wkJPbqbKXifo3ZZ6Ea2TTzvqqydvE6L3V4jyDsGyODEGhp0x X0XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uWjStv18iWffamtDoRNmdBtkPFd2MB677X+4vIXWgWI=; b=qAl+Zb/zjJ1Tu34fAq1XhAhL6J4MTvvSg4FyBlg/HCCQ6e7FzKnDicF3rIAoCyKp0h MAgq1T58tR07gmHFrdYBaHaeAo0GqkLs1N4PBemXsA5o2FrAunSKJ8ylFMwRc3WvvsTU 32SFVhhgiBgikhYqw5ng9jDDfDJ700oveQ/iKf0tFXPRLU3nqp/c4s8NNwJSNdCGDmch l3nsB3HcsSDa/3nvZ5HCZm+LFUNlXpWXdz6U15sLEcaLjUQ+s77gLfpthpWwMQGduiS9 OYeAsvL2jqgwFpjCU2+E7/oKshUiDIuay2oLni9mryriV5imQQ4T+Tzz5xSPEXEaBp19 MEBw== X-Gm-Message-State: AJaThX7RFOm4lcFp9HJ+QFrHpP7IQzNF+yxDvO5t5k7cG6y+PNgjI5uB B9skrwl00thmrpdd7dz7LobeAGBETa3VzC5aGro= X-Google-Smtp-Source: AGs4zMbTGoNMTmSU+Hup/a3sLoSb6+QVaUmY7jBog2rZkKNaCh4SKCEmECvFNtXhtD75SDvH1qCCFoNdZCZPRUzmYNM= X-Received: by 10.37.160.35 with SMTP id x32mr8550331ybh.387.1510717643323; Tue, 14 Nov 2017 19:47:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.115.212 with HTTP; Tue, 14 Nov 2017 19:47:22 -0800 (PST) In-Reply-To: <23051.40720.908131.277454@gro.dd.org> References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <23051.40720.908131.277454@gro.dd.org> From: Alexander Mayrhofer Date: Wed, 15 Nov 2017 11:47:22 +0800 Message-ID: To: Dave Lawrence Cc: IETF DNSOP WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 03:47:36 -0000 On Wed, Nov 15, 2017 at 9:57 AM, Dave Lawrence wrote: > I personally am of the belief that yes, if the request has an OPT then > a responder can include an option code that was not in the request. > At least I don't see anything in 6891 to prohibit it. This is > behaviour that draft-ietf-dnsop-extended-error is also expecting. I agree that signaling is important, and i also believe that if there's an OPT in the request, we can safely assume that the client would not choke on this option. I'm torn on the question whether or not stale data should be served (without signaling, in that case) when the request does *not* contain an OPT request. Probably we should err on the side of *not* serving stale when a client is not "EDNS capable", because that would mean no change from current behaviour. Alex From nobody Tue Nov 14 19:51:28 2017 Return-Path: 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 CA2B0129436 for ; Tue, 14 Nov 2017 19:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 IsP0zhcdnWxy for ; Tue, 14 Nov 2017 19:51:23 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BEC127698 for ; Tue, 14 Nov 2017 19:51:23 -0800 (PST) Received: from dhcp-9ab5.meeting.ietf.org ([31.133.154.181]:51528) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1eEojN-0003Su-8O (Exim 4.72) for dnsop@ietf.org (return-path ); Wed, 15 Nov 2017 03:51:17 +0000 To: dnsop@ietf.org References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <23051.40720.908131.277454@gro.dd.org> From: Ray Bellis Message-ID: <1a020200-3e7d-47a2-bd63-b745fceb7958@bellis.me.uk> Date: Wed, 15 Nov 2017 11:51:20 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 03:51:26 -0000 On 15/11/2017 11:47, Alexander Mayrhofer wrote: > I agree that signaling is important, and i also believe that if > there's an OPT in the request, we can safely assume that the client > would not choke on this option. I'm torn on the question whether or > not stale data should be served (without signaling, in that case) when > the request does *not* contain an OPT request. Probably we should err > on the side of *not* serving stale when a client is not "EDNS > capable", because that would mean no change from current behaviour. I'm not particularly arguing either way on this question of signalling, but do we have any feel for how many stubs ever send EDNS? libresolv can do it, and getdns does, but I don't think glibc's resolver routinely sends EDNS. Ray From nobody Tue Nov 14 19:54:22 2017 Return-Path: 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 7F174127698 for ; Tue, 14 Nov 2017 19:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nXeG1_gWJ-gN for ; Tue, 14 Nov 2017 19:54:19 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1A9126CBF for ; Tue, 14 Nov 2017 19:54:19 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id p74so5044670ywe.2 for ; Tue, 14 Nov 2017 19:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DPCqo2TaFCwUhNozU7kx7A9yUwb5CquUMiddvXv4a7k=; b=SpnLVGHA5FQS8ViXrbM813Av7qtwjJROgjFCYK2VSsUckzFq3k8JcRY/sc4zoBRhb+ p8QrYflPKD2QTM9J1372agJ+thF/ohtYjr3+uABGRLHBZO7MtIqpIh8fP5zv4JcqcM4u +/vAWyKfIYaQzCkoFPN/QTCCDvyph+ymBMaLxc1lFAP1RWizLjhwMmI3jamc3raA21GW EbYpiZ0t0+IQziwbgotMNd1jx9lL/ZDv3HEX5erUoUuhYjgD3K3+ITT+YOhVJlMlTdpV S/9NfUGg7e5ayGiurP6jmEs/t+NGqXMxvh8kTeGWlQI2x74WJzaQBKMip8YdOvgryiwS /rXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DPCqo2TaFCwUhNozU7kx7A9yUwb5CquUMiddvXv4a7k=; b=MU80/akOJyg5hfGTd29Gj+dcQPZLMYVEt2IZ5E2Wy7Ppil83o8j+RsZJjEC0aLzTbG jevKFiMDHxgUJs4clZ+oHwb0p09mpVlhEHlZX8mASEGeXUQw1PsIlJzmMeQ+AQdVCGCG S63syknTzswAo6qu4K87iS0d1f+TtYvjSLzKtwa4YopwDr3SM1IlqpP7CDB1hBJmxQBt xblKEWWd8mfz2pmOY+NIZg99RlH+CgCsU9McmjhNvbf6DJVMyqEEdpcRetrVjcGXsYFW ya4A8yk0owz0cFcaOyF3AmRDwB2kWsZvg98m5NLtaunaahIN0LJBI1hh6It0TJdIAsMQ 0G3w== X-Gm-Message-State: AJaThX4q1gN6Ux9rIGC+XS3M/5vsjGruHEFOqxQ5LXY90TY0SY4ur4bD vtaWdPo6o3uqyYCEWTjU8bC1E4B+c15VMVoIu94= X-Google-Smtp-Source: AGs4zMZ2/Hx5Kt4xXce5HryViIv3HXX6Pl7pQfIyT6YOA1uNfV2ar7w/s3ZvX1574aDBJyvJWEL4Pkq5E+wVDknGhOM= X-Received: by 10.37.188.146 with SMTP id e18mr8962683ybk.27.1510718058757; Tue, 14 Nov 2017 19:54:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.115.212 with HTTP; Tue, 14 Nov 2017 19:54:18 -0800 (PST) In-Reply-To: <1a020200-3e7d-47a2-bd63-b745fceb7958@bellis.me.uk> References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <23051.40720.908131.277454@gro.dd.org> <1a020200-3e7d-47a2-bd63-b745fceb7958@bellis.me.uk> From: Alexander Mayrhofer Date: Wed, 15 Nov 2017 11:54:18 +0800 Message-ID: To: Ray Bellis Cc: IETF DNSOP WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 03:54:20 -0000 > I'm not particularly arguing either way on this question of signalling, > but do we have any feel for how many stubs ever send EDNS? > > libresolv can do it, and getdns does, but I don't think glibc's resolver > routinely sends EDNS. Ray, i do agree - having figures "from the field" about this would be great. We don't see much direct stub resolver traffic obviously, so i can't provide any, unfortunately.. From nobody Tue Nov 14 19:57:46 2017 Return-Path: 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 88BEA126C22 for ; Tue, 14 Nov 2017 19:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ix07Hr9W8P9a for ; Tue, 14 Nov 2017 19:57:44 -0800 (PST) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16595124217 for ; Tue, 14 Nov 2017 19:57:44 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 8DAC83F442; Tue, 14 Nov 2017 22:57:42 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23051.47926.538193.725450@gro.dd.org> Date: Tue, 14 Nov 2017 22:57:42 -0500 From: Dave Lawrence To: IETF DNSOP WG In-Reply-To: References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <23051.40720.908131.277454@gro.dd.org> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 03:57:45 -0000 Alexander Mayrhofer writes: > I'm torn on the question whether or not stale data should be served > (without signaling, in that case) when the request does *not* > contain an OPT request. I'm personally not torn on this; for me the whole point of implementing this functionality is to add resiliency to the existing DNS ecosystem. Very specifically for my implementation it was needed in an environment where answers were going to a stub resolver that did not (and still does not) speak EDNS. It is significantly less operationally beneficial if it demands EDNS. From nobody Tue Nov 14 20:07:29 2017 Return-Path: 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 49237124217 for ; Tue, 14 Nov 2017 20:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CNBwomgeRmse for ; Tue, 14 Nov 2017 20:07:27 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A258126CBF for ; Tue, 14 Nov 2017 20:07:27 -0800 (PST) Received: from [10.170.78.140] (unknown [65.158.49.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 4F29961FA2; Wed, 15 Nov 2017 04:07:27 +0000 (UTC) Message-ID: <5A0BBD7C.1000307@redbarn.org> Date: Tue, 14 Nov 2017 20:07:24 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Ray Bellis CC: dnsop@ietf.org References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <23051.40720.908131.277454@gro.dd.org> <1a020200-3e7d-47a2-bd63-b745fceb7958@bellis.me.uk> In-Reply-To: <1a020200-3e7d-47a2-bd63-b745fceb7958@bellis.me.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 04:07:28 -0000 Ray Bellis wrote: > ... > > I'm not particularly arguing either way on this question of signalling, > but do we have any feel for how many stubs ever send EDNS? > > libresolv can do it, and getdns does, but I don't think glibc's resolver > routinely sends EDNS. i would look to opendns or gdns for those stats. they've got to be seeing an excellent cross-section of every possible stub implementation. -- P Vixie From nobody Tue Nov 14 20:08:59 2017 Return-Path: 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 A38E812878D for ; Tue, 14 Nov 2017 20:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oRRRl3VrBb71 for ; Tue, 14 Nov 2017 20:08:56 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C5112778D for ; Tue, 14 Nov 2017 20:08:56 -0800 (PST) Received: from [10.170.78.140] (unknown [65.158.49.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C37C461FA2; Wed, 15 Nov 2017 04:08:56 +0000 (UTC) Message-ID: <5A0BBDD7.2070406@redbarn.org> Date: Tue, 14 Nov 2017 20:08:55 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Dave Lawrence CC: IETF DNSOP WG References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <23051.40720.908131.277454@gro.dd.org> <23051.47926.538193.725450@gro.dd.org> In-Reply-To: <23051.47926.538193.725450@gro.dd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 04:08:58 -0000 Dave Lawrence wrote: > Alexander Mayrhofer writes: >> I'm torn on the question whether or not stale data should be served >> (without signaling, in that case) when the request does *not* >> contain an OPT request. > > I'm personally not torn on this; for me the whole point of > implementing this functionality is to add resiliency to the existing > DNS ecosystem. Very specifically for my implementation it was needed > in an environment where answers were going to a stub resolver that did > not (and still does not) speak EDNS. > > It is significantly less operationally beneficial if it demands EDNS. i'm of the opposite view. we should not change behaviour without explicit signaling. if that means it takes 10 years to reach 50% penetration, like EDNS did, then that's the cost of doing business. -- P Vixie From nobody Tue Nov 14 20:11:10 2017 Return-Path: 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 452FA1270FC for ; Tue, 14 Nov 2017 20:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 qEpx9AdERyBZ for ; Tue, 14 Nov 2017 20:11:08 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 0134C124217 for ; Tue, 14 Nov 2017 20:11:08 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yc9sk1dFGz30y; Wed, 15 Nov 2017 05:11:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510719066; bh=xVPdmKCR5Sc1QEDTraBzRjbebj+i6vRl/D9XTwGUV24=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=B8lKTp3V4vIUciKA91Cb019Z20azAzpel9ekUrFr31igF70L07m7oAjUbE1rVd/sM DpwtTKnjTDJOgtYRywE0R1Y5aiOaJyJVmZg0f2pIrIxQcklnUH2MyL4a+aANFd2bWy xTqooiDethnbx3UgIUeHdq/GTL9/jLwDS9YqxxI8= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 7juUjOrMaZ1v; Wed, 15 Nov 2017 05:11:05 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 15 Nov 2017 05:11:05 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 2537862D29; Tue, 14 Nov 2017 23:11:04 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 2537862D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0E6A940D35AF; Tue, 14 Nov 2017 23:11:04 -0500 (EST) Date: Tue, 14 Nov 2017 23:11:03 -0500 (EST) From: Paul Wouters To: Frederico A C Neves cc: "dnsop@ietf.org" In-Reply-To: <20171115032700.GE94801@registro.br> Message-ID: References: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> <20171109174804.GA63012@isc.org> <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org> <20171115032700.GE94801@registro.br> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 04:11:09 -0000 On Wed, 15 Nov 2017, Frederico A C Neves wrote: > Yes. And add to that cases were TLDs rolled just before adding to the > root. So what is the security model then? Let's say .example rolled and now has a bad DS. Someone overrides this with a local trust anchor so the domain does not go dark. - How do you know the roll was legitimate? - How does an application make a security decision about a found TLSA record that depends on this trust anchor? Now .example rolls to yet another key to fix their mistake and updates the DS. - How does the application know the roll is legitimate? - How does an application make a security decision about a found TLSA record that depends on this trust anchor? - Who, why and when does the local trust anchor get deleted. What if _this_ is the key that example.com lost the private key to? Now same as above, but one of these rolls were done by an attacker and is malicious. Trusting "any"thing is just a path to madness. Paul From nobody Tue Nov 14 20:13:05 2017 Return-Path: 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 23BA6124217 for ; Tue, 14 Nov 2017 20:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 wlOX_Wti3xTt for ; Tue, 14 Nov 2017 20:13:02 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 5B2CE12778D for ; Tue, 14 Nov 2017 20:13:02 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3yc9vw2frTz30y for ; Wed, 15 Nov 2017 05:13:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510719180; bh=Hmk70Jr6BOsjoowoh/c5oKxbbYyBcRM3UgOu/BY5wLw=; h=Date:From:To:Subject:In-Reply-To:References; b=Wd2pULbd0Kz4ZX7eFFFq/MX0J6PXnzNpBWY/WU0CFjHvSC34RU5+Yhk7k3ncrgneN Lfrmy4sozrkl2XIp8lP5s6ABqjM4Y2EeoqD7FA4Kl5PzTaeefZTIY7r3n9CBC7bRtl HXB8sXsN1RoBE/OWbi3qdi/yasQdcrswxdlV1JP0= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id xLiRNectf3HC for ; Wed, 15 Nov 2017 05:12:59 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 15 Nov 2017 05:12:59 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6DC0C62D29; Tue, 14 Nov 2017 23:12:58 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 6DC0C62D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 56BB240D35AF for ; Tue, 14 Nov 2017 23:12:58 -0500 (EST) Date: Tue, 14 Nov 2017 23:12:58 -0500 (EST) From: Paul Wouters To: dnsop In-Reply-To: <5A0BBDD7.2070406@redbarn.org> Message-ID: References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <23051.40720.908131.277454@gro.dd.org> <23051.47926.538193.725450@gro.dd.org> <5A0BBDD7.2070406@redbarn.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 04:13:04 -0000 On Tue, 14 Nov 2017, Paul Vixie wrote: >> It is significantly less operationally beneficial if it demands EDNS. > > i'm of the opposite view. we should not change behaviour without explicit > signaling. if that means it takes 10 years to reach 50% penetration, like > EDNS did, then that's the cost of doing business. Agreed. DNS updates are slow enough as it is. Taking into account 10+ year old non-updated DNS software will make the future more even more slowly. It's not actually helping us. Paul From nobody Tue Nov 14 20:22:00 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A641294DF; Tue, 14 Nov 2017 20:21:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151071971325.25964.14024142690717747488@ietfa.amsl.com> Date: Tue, 14 Nov 2017 20:21:53 -0800 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 04:21:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Reverse DNS in IPv6 for Internet Service Providers Author : Lee Howard Filename : draft-ietf-dnsop-isp-ip6rdns-04.txt Pages : 14 Date : 2017-11-14 Abstract: In IPv4, Internet Service Providers (ISPs) commonly provide IN- ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches and considerations for ISPs in managing the ip6.arpa zone for IPv6 address space assigned to many customers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-isp-ip6rdns-04 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-isp-ip6rdns-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-isp-ip6rdns-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 14 20:54:29 2017 Return-Path: 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 2FD88128B4E for ; Tue, 14 Nov 2017 20:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sdsKHobEdliP for ; Tue, 14 Nov 2017 20:54:27 -0800 (PST) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC601201F8 for ; Tue, 14 Nov 2017 20:54:27 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 250443F442; Tue, 14 Nov 2017 23:54:26 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23051.51330.101425.365809@gro.dd.org> Date: Tue, 14 Nov 2017 23:54:26 -0500 From: Dave Lawrence To: dnsop In-Reply-To: References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <23051.40720.908131.277454@gro.dd.org> <23051.47926.538193.725450@gro.dd.org> <5A0BBDD7.2070406@redbarn.org> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 04:54:28 -0000 tale: >> It is significantly less operationally beneficial if it demands EDNS. Paul, and echoed by Paul: > i'm of the opposite view. we should not change behaviour without > explicit signaling. I've opened this as an issue to track toward WG consensus and suspect that, unless strong consensus for one view or the other obviously emerges on the list, that we'll be looking for a hum on it in London. On the practical side, private implementations are of course going to easily evade any MUST that could eventually make its way here and still be seamlessly interoperable with clients. The restriction's effect would mainly be binding for implementations claiming the strictest compliance. From nobody Tue Nov 14 20:59:24 2017 Return-Path: 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 DB73A128AB0 for ; Tue, 14 Nov 2017 20:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 o4r76C7Rb_qH for ; Tue, 14 Nov 2017 20:59:23 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 057681288A9 for ; Tue, 14 Nov 2017 20:59:23 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ycBxP280qz39g; Wed, 15 Nov 2017 05:59:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510721961; bh=8zTwY9xk8R+7yy2s8Ac04SnC0e1D6EM2BFO5t6ygk98=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=q+384bXa8WaPRiC+mlsP03kNsMTfQspoDJ3zeT3c2sStgxocASGKJATSk2F2UbKzE 0rxL4q9KbL9E9ytH86MOo5lPcylDAKablx9Pk67z09vv7SiF19aFeG+bMnthovoFNW ViLZ0VscK97LpnbWIe+M+ZgYUIwN6p8w+mY467YI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 3nxh-GwWTx-H; Wed, 15 Nov 2017 05:59:20 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 15 Nov 2017 05:59:20 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4F8BC62D29; Tue, 14 Nov 2017 23:59:19 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 4F8BC62D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3F00B40D35AF; Tue, 14 Nov 2017 23:59:19 -0500 (EST) Date: Tue, 14 Nov 2017 23:59:19 -0500 (EST) From: Paul Wouters To: Jacques Latour cc: "dnsop@ietf.org" In-Reply-To: Message-ID: References: <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <20171113183004.GA35038@isc.org> <436111CF-FCA8-44A2-B83D-6540DE6D64AC@icann.org> <66BA5F27-B044-459B-A2B2-54221FD768C6@isc.org> <20171113233756.GA37394@isc.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 04:59:24 -0000 On Tue, 14 Nov 2017, Jacques Latour wrote: > Personally, I like a mix of #3 and #1, on a regular basis poll the entire > zone for changes, and have a mechanism to listen to child notifications > for urgent changes. Agreed. > _AND_ remember, the preferred method by far is to submit a DS/DNSKEY > record is via the RRR EPP model. The above is when that RRR EPP model is > non functional. That preference might be political not technical. I personally like the DNS based solutions over the EPP based one, because it requires no humans or webgui's :) Paul From nobody Tue Nov 14 21:13:35 2017 Return-Path: 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 5BE571271DF for ; Tue, 14 Nov 2017 21:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6WwsLMhTeJPY for ; Tue, 14 Nov 2017 21:13:31 -0800 (PST) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F326A127058 for ; Tue, 14 Nov 2017 21:13:30 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id E39A03F442; Wed, 15 Nov 2017 00:13:29 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23051.52473.880861.251236@gro.dd.org> Date: Wed, 15 Nov 2017 00:13:29 -0500 From: Dave Lawrence To: IETF DNSOP WG In-Reply-To: <5A0BBDD7.2070406@redbarn.org> References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <23051.40720.908131.277454@gro.dd.org> <23051.47926.538193.725450@gro.dd.org> <5A0BBDD7.2070406@redbarn.org> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 05:13:33 -0000 Paul Vixie writes: > i'm of the opposite view. we should not change behaviour without > explicit signaling. if that means it takes 10 years to reach 50% > penetration, like EDNS did, then that's the cost of doing business. Just so I'm clear, am I understanding correctly from this that you believe a recursive server should only fall back to stale data from cache if the request explicitly included a staleness option? I ask because Bob's comment that started this thread was exploring being able to signal staleness back when OPT was included in the request but the option being defined by the draft wasn't included. To me this makes three different positions we're trying to reach consensus about, for allowing fallback to stale either: 1) when the request explicitly signals it is ok; 2) when the request groks EDNS but might or might not understand a staleness option; or 3) in all cases. My current understanding is that you and Paul are of position 1, while I'm at 3. At first glance 2 would appear to be pretty nearly the same as 3 as far as its permissive toward unaware clients, but significantly it does at least provide signal you could still access via protocol debugging (dig, tcpdump, etc). From nobody Tue Nov 14 21:41:11 2017 Return-Path: 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 E4E56128DF2 for ; Tue, 14 Nov 2017 21:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 ow4bgcJ7T2pm for ; Tue, 14 Nov 2017 21:41:08 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9300B1243F6 for ; Tue, 14 Nov 2017 21:41:08 -0800 (PST) Received: from [IPv6:2600:1011:b04d:6a9a:e9c8:25a9:9bb0:78b0] (unknown [IPv6:2600:1011:b04d:6a9a:e9c8:25a9:9bb0:78b0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C486661FA2; Wed, 15 Nov 2017 05:41:07 +0000 (UTC) Date: Wed, 15 Nov 2017 05:41:04 +0000 User-Agent: K-9 Mail for Android In-Reply-To: <23051.52473.880861.251236@gro.dd.org> References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <23051.40720.908131.277454@gro.dd.org> <23051.47926.538193.725450@gro.dd.org> <5A0BBDD7.2070406@redbarn.org> <23051.52473.880861.251236@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dnsop@ietf.org,Dave Lawrence ,IETF DNSOP WG From: P Vix Message-ID: <8D809B23-8A29-483F-9962-4A2E7C426184@redbarn.org> Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 05:41:10 -0000 On November 14, 2017 9:13:29 PM PST, Dave Lawrence wrote: >Paul Vixie writes: >> i'm of the opposite view=2E we should not change behaviour without=20 >> explicit signaling=2E if that means it takes 10 years to reach 50%=20 >> penetration, like EDNS did, then that's the cost of doing business=2E > >Just so I'm clear, am I understanding correctly from this that you >believe a recursive server should only fall back to stale data from >cache if the request explicitly included a staleness option? Yes=2E I know that coherency does not rank high in a cdn operator's priori= ty queue, but the dns has other users also=2E >I ask because Bob's comment that started this thread was exploring >being able to signal staleness back when OPT was included in the >request but the option being defined by the draft wasn't included=2E Ah=2E >To me this makes three different positions we're trying to reach >consensus about, for allowing fallback to stale either: > >1) when the request explicitly signals it is ok; >2) when the request groks EDNS but might or might not understand > a staleness option; or >3) in all cases=2E > >My current understanding is that you and Paul are of position 1, while >I'm at 3=2E At first glance 2 would appear to be pretty nearly the same >as 3 as far as its permissive toward unaware clients, but >significantly it does at least provide signal you could still access >via protocol debugging (dig, tcpdump, etc)=2E I expect you to implement 3=2E I expect us to document 1=2E 2 would be chaos, helping nobody=2E >_______________________________________________ >DNSOP mailing list >DNSOP@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dnsop --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From nobody Tue Nov 14 21:52:26 2017 Return-Path: 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 7CE431294D3 for ; Tue, 14 Nov 2017 21:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 72AZIln_51Nm for ; Tue, 14 Nov 2017 21:52:23 -0800 (PST) Received: from mail.hardakers.net (unknown [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0CA91243F6 for ; Tue, 14 Nov 2017 21:52:23 -0800 (PST) Received: from localhost (unknown [IPv6:2001:67c:370:128:4f95:5348:c746:6554]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 6F6F4245F9; Tue, 14 Nov 2017 21:52:22 -0800 (PST) From: Wes Hardaker To: Wes Hardaker Cc: dnsop@ietf.org References: Date: Tue, 14 Nov 2017 21:52:19 -0800 In-Reply-To: (Wes Hardaker's message of "Tue, 14 Nov 2017 17:49:35 -0800") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] 5011-security-considerations and the safetyMargin X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 05:52:24 -0000 Wes Hardaker writes: > After thinking about this for far far too long, I've now switched my own > opinion to that of 2C (errr... that should have been "2B") -- Wes Hardaker USC/ISI From nobody Tue Nov 14 22:39:01 2017 Return-Path: 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 00C80129503 for ; Tue, 14 Nov 2017 22:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 fuN5gY47B9A6 for ; Tue, 14 Nov 2017 22:38:57 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012A4129508 for ; Tue, 14 Nov 2017 22:38:56 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id 9so705711wme.4 for ; Tue, 14 Nov 2017 22:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A7DSQJQ4pqTWmbeyAWloqtaIKl5YvTVAvVm0Pp9rH4E=; b=ubA0ODJdxHFpYnDTgIqoyL9VEeo0s1NC0OMgQ+vnyRLN8nWbL6Exztuv+O02p55Y1V 5Hpty+3QXmViUhvcXS5BwS0m8ADl815OFlEYCj7QQo6k2KlpCvg8X2BH/Oz4oAX17MNU Ayfx4zLBs4DtxkODmYRDx5thU8isQXKtI52glA+A7UB9SWUqN+qViQAdsELjcPAkAMfP Tg6jdTsfrGY3DwLg+6n37zMr/WqbeBzmv+fEJ+6QPB3D+C1IaJ53IRGv79ukin83d7Lv tyN7sT4y579UPRxH2I98cHboHcBWvJaiBduyFhOiKACoShMO18SlPFC1xOqbR+DykfxY w8pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A7DSQJQ4pqTWmbeyAWloqtaIKl5YvTVAvVm0Pp9rH4E=; b=rORmve1oVBY32Uu+Pw83Y2biPt6S1i0+/mTowvw3V7J4IOGYeNumUT5FMzIWSbDGkd Gw4+dQmJ5VxgG9/stKPrPgpndAd5MRVcalthbUdZ08aj0QQEd+u8/gYlVfV0T4ghSo/0 6JTIMOHLyxFPL4uaeLesfLUeJkoOChXrfxseCmP+BpmvwNt23mVflWqsqEn5jRL5mUM3 ZGVleXIpiPk2Av2bJqjWaLQcoThmIw/LhrrUO27JrUDtT7KhpJ2tujYUrXFZoFjEWJ/k 7NIKVdjQXRkFu/lfbL3MRsxKJtgX3uFW6KaO+UyIJcdJJlGUDC8f1Y+cEMGa2qruisU7 EmpQ== X-Gm-Message-State: AJaThX4CWl8ZNHkAM9EkHZy3/Y4cUCjRSIwJ8PafbV40Lut03TckCZrm oSRQZfNEKiwrSpCDrhaewFni+Tk2AZkfCgG8rs/jFw== X-Google-Smtp-Source: AGs4zMamr3gdvAAkDg1ouztXdClQ+C2VzzXpQxeiuECD7aWV+6xF6WTMZwnDRtj8/gAiyfOllgzbHDPHMU1KRa2DZM4= X-Received: by 10.28.26.194 with SMTP id a185mr443649wma.124.1510727935285; Tue, 14 Nov 2017 22:38:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.149 with HTTP; Tue, 14 Nov 2017 22:38:14 -0800 (PST) In-Reply-To: <7572271693475788861@unknownmsgid> References: <151062636258.5917.14497839377888768972@ietfa.amsl.com> <7572271693475788861@unknownmsgid> From: Warren Kumari Date: Wed, 15 Nov 2017 14:38:14 +0800 Message-ID: To: Joe Abley Cc: Bob Harold , IETF DNSOP WG , "internet-drafts@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 06:38:59 -0000 On Wed, Nov 15, 2017 at 9:45 AM, Joe Abley wrote: > Hi Bob, > > On Nov 15, 2017, at 00:23, Bob Harold wrote: > > If I have to add those entries to each zone, I worry that the automated DNS > appliance that I use might not be able to create the broken records > required. > > Since the implementation of the mechanism requires special handling of > queries whose QNAMEs contain the special labels, I don't see why you would > ever need to add anything to any zone. > > The point of this mechanism is to require no administrator action and to be > on by default, I think. Yup, *you* should not need to create these records, as long as someone does the testing will work -- e.g if example.com publishes: _is-ta-4f66.example.com _not-ta-4f66.example.com badlysigned.example.com and you can resolve things in example.com you can do the testing. If your appliance has not been upgraded to know about this new technique the result will correctly be "unknown / indeterminate" (Vleg[0]) W [0]: Vleg: A DNSSEC-Validating resolver that does not include this mechanism will respond with an A record response for "_is-ta", an A record response for "_not-ta" and SERVFAIL for the invalid name. > > > Joe > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Nov 14 22:44:12 2017 Return-Path: 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 C8D65128796 for ; Tue, 14 Nov 2017 22:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bX1dmoHQFtFn for ; Tue, 14 Nov 2017 22:44:09 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0B291274D0 for ; Tue, 14 Nov 2017 22:44:08 -0800 (PST) Received: from [10.1.94.75] (unknown [199.36.244.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id CCCAE61FA2 for ; Wed, 15 Nov 2017 06:44:08 +0000 (UTC) Message-ID: <5A0BE237.5090104@redbarn.org> Date: Tue, 14 Nov 2017 22:44:07 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: "dnsop@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] state management related to TTL X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 06:44:11 -0000 tonight's exchanges here related to "use-stale" seem discordant to me. i'd like to play the straight man for a moment and ask some indulgent person to bring me up to speed by way of correcting my impressions. the DNS TTL field is a state management variable. in this case the held state is in the form of cached RRsets, and the TTL associated with the RRset describes the period of time during which they can be reused. by the original DNS specifications, after this reuse period, these RRsets are to be discarded, and if the data is still needed, it is re-fetched. in practice, TTL expiry is often not discovered until the records are about to be reused; this avoids the cpu and memory bandwidth costs of sweeping the cache periodically in search of expiration-ready RRsets, and avoids the additional state requirements of threading these RRsets by TTL in addition to the standard cost of threading them by recency of use (to facilitate LRU based purge when the cache reaches its limit.) what this practice leads to is a "sudden concurrent need" for the RRset at the precise moment when it is being discarded. in order to avoid simultaneous "not having" and "great need", some RDNS servers do in fact sweep their caches or perhaps thread their RRsets by TTL expiration, in order to pre-launch a refreshment query when the TTL still has some fraction (like 5%) or period (like one minute) remaining. this is non-ideal since we often find that we're refreshing data that will not be used soon or perhaps ever. work is underway by several teams to find a "tuning set" of variables and thresholds which will better predict reuse in order to avoid refresh costs for non-reuse. another method that's been deployed of avoiding simultaneous "don't have" with "great need" is to liberally reinterpret TTL such that RRsets can be reused beyond their explicit TTL lifetime, while their refresh queries proceed in the background. commonly, the authority servers responsible for answering these refresh events are down or unreachable at the time of most acute need. therefore the term "serve stale" to indicate a state management method whereby stale (beyond its TTL) data is served for some period of time, measured in minutes or hours, until the authority server can be reached to either refresh the RRsets or verify that they have in fact disappeared. the danger of TTL stretching is that reuse beyond TTL may cause RRsets that are in fact supposed to be unreachable, to be effectively reachable. examples include security-related takedown of criminal DNS servers or networks, or failover strategies where end systems will not try to reach their backup servers unless they cannot reach their primary servers, and the unreachability of those primary servers is hidden from them by TTL stretching. fundamentally, an RRset and its TTL are the property of the zone administrator, and it's controversial for any other party to use this data beyond its specified use parameters. all of this trouble comes from DNS's use of a single state variable (TTL) to represent usability lifetime, rather than two such variables, one indicating the periodicity of refresh, the other indicating the periodicity of discard. many of us would like our data to be rechecked hourly by all caching servers who store it, but used for days or weeks if we become unreachable by some or all of those servers. using one variable for two purposes represents an inconvenient compromise which often provides "no right answer" as to setting. therefore an idealized solution would be to provide a second variable, and where that second variable is present, the meaning of the existing variable (TTL) could be subtly altered to support a two-variable setting. therefore a "serve stale" team within IETF-DNSOP was convened, to try to standardize the methods and signal patterns necessary to extend the usability lifetime of records when their authority servers are not reachable at the time of normal TTL-based expiry. most of us recognize that TTL's will continue to be stretched no matter what changes are or are not made to the specification, and so we expect the resulting RFC to document current practice _without recommending it_ and to also document a new practice _with recommendations_ as to its proper uses. there are hangups in signaling options due to the sloppy specification for EDNS, about which the author of EDNS0 feels just awful, believe me. however, we are all relatively sure that EDNS can be used to encode a desire for new state management behaviour, within the limitation that EDNS must first be signaled by the initiator before it can be answered by a responder, and we might wish it otherwise. that's why it was important to realize that if _any_ EDNS option is provided by an initiator, then _any_ EDNS option can be provided by a responder. in theory this means we could provide state management options in a response without having heard any state management options in a request -- so long as some form of EDNS was in fact used in the request. it's not yet clear that this evasive maneuver will be required, however. the most straightforward signaling would be for an RD=0 initiator (normally a recursive DNS server) to ask some or all of its responders (normally authority servers) for permission to stretch the TTL. some responders will not answer this signal at all, some will say no, and some will say yes and give maximum tension values for the RRsets contained in the answer and authority sections -- but not for the additional section since that data might have a different authority server and may only be present as "glue". the new tension variable might be "maximum stretch interval" in which case the RRset's TTL _in this answer or authority section_ would be interpreted as a refresh interval. this system would allow gradual insertion of the new state management logic on an opportunistic basis -- motivated authority and recursive server operators, which would include CDN operators who must perform both services perfectly -- would be early adopters, and like ECS before it, the "hot" part of the community would be upgraded years earlier than the last outlier. noone has proposed any new signaling between the stub and the recursive, but it's possible that a stub may want a true TTL and so we might add signaling from the stub (as initiator) saying, don't stretch, or perhaps saying, if this is a stretched TTL, tell me so explicitly. if this understanding isn't wrong or incomplete, then i fail to see why there would be any drama that would prevent the construction of a draft. -- P Vixie From nobody Wed Nov 15 04:18:32 2017 Return-Path: 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 31BD3129409 for ; Wed, 15 Nov 2017 04:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 4GbYhjNQLcLq for ; Wed, 15 Nov 2017 04:18:29 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 A0495129401 for ; Wed, 15 Nov 2017 04:18:29 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:42131) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eEweA-000gQr-0w (Exim 4.89) (return-path ); Wed, 15 Nov 2017 12:18:26 +0000 Date: Wed, 15 Nov 2017 12:18:25 +0000 From: Tony Finch To: Paul Vixie cc: Dave Lawrence , dnsop@ietf.org In-Reply-To: <5A0BB7B5.8050804@redbarn.org> Message-ID: References: <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <5A09C4D6.6080202@redbarn.org> <20171114063209.gjubqyovnwcrl33a@mx4.yitter.info> <5A0A952F.1060001@redbarn.org> <20171114080638.GA41253@isc.org> <5A0AA777.9010908@redbarn.org> <20171114175300.GA45323@isc.org> <23051.41140.187552.962508@gro.dd.org> <5A0BB7B5.8050804@redbarn.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 12:18:31 -0000 Paul Vixie wrote: > > the reason i use SERVFAIL for NOTAUTH is because what i want the initiator to > do when i'm configured as primary but can't read my zone file, or am > configured as secondary but can't write my zone file, is the same as what i > want when i'm not configured for the zone: cache this failure under a > hold-down timer so as not to melt the tubez, but do try again later in case > i'm merely late to change my config, or flubbed my config in some way. I'm interested in this discussion. Recently I changed private.cam.ac.uk so that queries from off-campus get NXDOMAIN instead of REFUSED. This had the unanticipated effect of halving the query load on our authoritative servers. Not really surprising except perhaps for the size of the effect. I've had a skim through BIND's resolver code to see how the lame server cache works. It's, um, not simple :-) but as far as I can see, both SERVFAIL and REFUSED responses get the server put in the lame cache. (BIND's servfail cache is different - that's for failures of this server itself, not the servers it is sending queries to.) Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fisher, German Bight: Northwest backing south 4 or 5, veering southwest 5 to 7 later. Moderate, occasionally rough. Showers. Moderate or good. From nobody Wed Nov 15 04:43:06 2017 Return-Path: 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 205A4126D74 for ; Wed, 15 Nov 2017 04:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9vtDTITzwHT for ; Wed, 15 Nov 2017 04:43:01 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA23124B17 for ; Wed, 15 Nov 2017 04:43:01 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 15 Nov 2017 04:42:59 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 15 Nov 2017 04:42:58 -0800 From: Edward Lewis To: Paul Wouters , Frederico A C Neves CC: "dnsop@ietf.org" Thread-Topic: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record Thread-Index: AQHTXcGe5RTSMuDUDEWyuzc/3muvWKMVWhmAgACPBoA= Date: Wed, 15 Nov 2017 12:42:57 +0000 Message-ID: <5BC62E72-6C8F-4F40-94B1-FF8FBD3A335E@icann.org> References: <5C194845-AB79-47DE-B936-97560D071C5D@icann.org> <20171109174804.GA63012@isc.org> <3440AE65-DE72-4AAE-8A93-2D698CEF79C4@icann.org> <20171115032700.GE94801@registro.br> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3593576577_79742661" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 12:43:03 -0000 --B_3593576577_79742661 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit To begin...thanks, Frederico, I was trying to find that case but had forgotten which ccTLD was involved. (Web searches failed me...) On 11/14/17, 23:11, "DNSOP on behalf of Paul Wouters" wrote: > On Wed, 15 Nov 2017, Frederico A C Neves wrote: > > > Yes. And add to that cases were TLDs rolled just before adding to the > > root. > > So what is the security model then? Keep in mind that DNSSEC is enabling the receiver to validate the DNS protocol was followed. (Including, if the DNS has bad data in it, the bad data is protected.) >Let's say .example rolled and now has a bad DS. This has happened a number of times already. >Someone overrides this with a local trust anchor so the domain does not go dark. Or configures a negative trust anchor. >- How do you know the roll was legitimate? In-band, you can't tell. But word of mouth speeds quickly, for better or worse. One quip from one case was "twitter is faster than nagios!" (I don't know how a DNS message receiver would realize/detect a roll, outside of STD 69's automated updates process.) >- How does an application make a security decision about a found TLSA record that depends on this trust anchor? That is a matter for the application, not the DNS. ... >Now same as above, but one of these rolls were done by an attacker and is malicious. I am scratching my head a bit trying to first imagine a validator even detecting a key rollover, legit or not. As it is now, caches are fickle, if what's cached doesn't have the key needed, they SERVFAIL the answer, not get a new copy of the keys (because of rollover-and-die, an issue documented many years ago). They don't distinguish between a botched rollover and someone one-time forging a response. >Trusting "any"thing is just a path to madness. Not trusting anything is a path to paranoia. ;) Madness or paranoia... The case for "any" trusted chain is rooted in the desire to retain as much robustness when slapping on security. This assumes that the greater issue lies in operational errors than re-delegation of zones. The track record shows that operator error is the greater source of DNSSEC invalidations, on the other hand, the thought that data gets misdirected is a concern. Ask this question...when a validator begins to systematically SERVFAIL data, what happens now? Followed actions include checking DNSVIZ to see if there's a DNSSEC problem with the authority and potentially negative trust anchors being applied. (This in the response to trouble tickets being lodged, support desk calls, etc.) With this as the current response, would preferring trust anchors over DS records (to put this problem tritely) be effective? Once a validator notes a re-delegation, the operator might just open the flood gates and let all the traffic go to the re-delegation anyway. (Not, myself, understanding if the operator, when adding a negative trust anchor would realize there was a positive trust anchor for the same name.) --B_3593576577_79742661 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBR8gdzmBOFvsIWGXzgnL3fBxBCY5zAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMTUxMjQyNTdaMA0GCSqGSIb3 DQEBAQUABIIBALCoxBjSKkn/Dm1K4D4Xth3SI8sUU/UhHViMZmlX5pE+fJDcBsni+fhdDNEj 37AYt5wl/KZVP75Xd6lsWlBRpiVgl4C4JgchSXluNHZQChMRDJHz9ihpvXr7YAnLp1bF8OYy HWdBCRBvsY8ac/T435JEIJLek4Jdlp4moNgzpxfaKCkTw4UUHsMwDOMhgOZ5AE8TG8FgXCCr EFgfI/DeUyu7wKTAsVOIkoT4Mm4hku2YOsnB1q0SdDvCQBdUN+R8ICfVd1jf00gfyb3fKhvL igEB2CUvxoFvHtD2nUe0YrEH9ai/R/Ftk4hpFvpPN9xOxZ7ejok3c0pcmgJa1fbpiSo= --B_3593576577_79742661-- From nobody Wed Nov 15 06:34:22 2017 Return-Path: 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 6762A126B7E for ; Wed, 15 Nov 2017 06:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 MUAaa7TrKVy2 for ; Wed, 15 Nov 2017 06:34:15 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E148B127A90 for ; Wed, 15 Nov 2017 06:34:13 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 15 Nov 2017 06:34:12 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 15 Nov 2017 06:34:12 -0800 From: Edward Lewis To: "dnsop@ietf.org" Thread-Topic: Comments on mic comments, 5011 update's authorship Thread-Index: AQHTXh7NpV2yHBaWTkKhad3Wpe/DFg== Date: Wed, 15 Nov 2017 14:34:11 +0000 Message-ID: <121B74B2-A670-48E2-B4DF-09E02F376012@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3593583250_1014628276" MIME-Version: 1.0 Archived-At: Subject: [DNSOP] Comments on mic comments, 5011 update's authorship X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 14:34:17 -0000 --B_3593583250_1014628276 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit ...From listening to the recording of the meeting on Monday, Nov 13,2017: It seems that there is an impression that I feel the authors of the 5011-update draft are wrong choice to be documenting this. This is not meant to be a personal attack on the authors but a blanket comment on seeing operator-focused documents being produced without operator involvement. (Apologies if it is thought to be an ad hominum "attack".) (Sub-point: It also seems that I've made the comment that ICANN hasn't been involved, which could be contradicted by messages I've sent, as well as Paul Hoffman. ICANN people have been reading and commenting on the document. What I'd like to stress is that ICANN has no special place regarding this document, I don't think that this document is something ICANN deserves "final" edit. Why this confusion exists, I'll explain further on.) Perhaps because I refrain from naming names of operators, my comments have been too vague. From data (meaning what's at the apex of TLD zones) I've collected over many years, I observe that only a handful of TLD operators have ever published a DNSKEY record with the revoked bit set. Within that handful, there are two operators (not two zones as each operator runs multiple zones) that publish a revoked key according to a detectable schedule, from this I have deduced that only two operators - at most - have *fully executed* Automated Updates in the course of normal operations. I write "at most" because I have only asked one of the operators for confirmation and received it, the other I have not. (Drilling deeper, with incomplete data on this, I have also polled delegations within ICANN-affliated TLDs and very rarely see revoked keys. Of course, without a sufficient history of data, this data would only lead to an under count on operators.) Related to my ICANN comment above, ICANN has not fully executed an Automated Updates key rollover yet. We are in the middle of our first roll with STD 69 semantics in mind. FWIW, I sent the names of the two operators in private email to Wes and Warren. For the curious, the two operators are principally operating ccTLDs in east Asia, also operating IDN ccTLDs. I.e., not ICANN is not one of them. My criteria for 5011-update being "operator influenced" would be to have those operators (the confirmed and the other possible one) participate in the review. They may not have a lot to say, but having an operator review and contribute to a document would go a long way to adding credibility in terms of "an operations document." I've made the comment in other contexts - any operational document written by researchers would benefit from an experienced operator's review. It isn't that Wes and Warren aren't qualified to write the document. I'm commenting on the legacy of documents written by protocol designers that are passed off as operations guidance. About 5 years ago, I did a study where I looked at DNSSEC operator guides (written by the IETF) versus parameter settings seen in the wild. (Results presented at RIPE, NANOG in 2012.) The comparison was interesting - some guidance in the document was followed, some was not. Interviewing an operator, they said (to paraphrase) we don't read the RFCs, we use tools and rely on default settings. This was an eye-opening moment for me. Since then I wondered what could be done to improve the usefulness of RFCs to operators and why I have begun to think of "return on investment" of documents. Is the IETF spending time (and the RFC editor) on documents that help the audience? Will this document help the audience? --B_3593583250_1014628276 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSsHugn0cr3Va1hHPY6Byubr9GypTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMTUxNDM0MTBaMA0GCSqGSIb3 DQEBAQUABIIBAGD30qY4V87TMmYykMyT8v+jNI1N7qZ0sJ2G/dHOkkOvmyrc6q6TvgnCpj6B b6WsENbMZNb9SiTEf0LJBqi81+7iy++N8cLxi+kM883f8XHMZ4/mB2eU6s4fEI6IMzWLDigc 384F3IQ1xTtu3iZv6WdynjIvOSS08HeZ9MFpnKii7srk1nxow4M3DSl+KsKUVfEhymxxfTVk LfIGo2ZYGSnNYwGCjQS+7iB33JwvMC1ltHKCinkle8145BHRJEIXnS+SMMlu8CllvtOKkrPz +LeGzhYF5fivZxznBtsUzLZ7bYXZBxe9/ALeWHQnmGb3VtRGDvnDOAMAnAtO2+DM3IU= --B_3593583250_1014628276-- From nobody Wed Nov 15 06:51:43 2017 Return-Path: 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 E51DD12751F for ; Wed, 15 Nov 2017 06:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 bDU6aK9Dyufn for ; Wed, 15 Nov 2017 06:51:40 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C585F120713 for ; Wed, 15 Nov 2017 06:51:39 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id f8so34862546qta.5 for ; Wed, 15 Nov 2017 06:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=FZw4YFA/OEyEoqquqWDfR4UbTErRB7u81KtBFQ0bNMo=; b=Mo4VHPI0g3Ir//eZaxOA4kqO2Sti3BA/5VpaEAeEvb6H9qV3fsSrmS9yXOjSNnl4dA 4qr/0kswu8GhmfLQ3MoRYoqtYIRvrCf6zIMRb3nErzRIjJDZChnejdRWFpq+sd3ghKau +e7m7tMPigXs7Cv7PjQ16h4sIjZbaFqljzfPZZVbjA+2ZZn53YkQs2CJe6TjsJUPGlTN ZfQPXSLj5ymApHUXcs98vlgoY12e8I6HRgwLhnEhtk3azXgc+6haxEmSbqIAygBayX8c xFlRkdlQxn3S1JhG5T5UUlWBOdfSIT/ueyda7G3e/f/xM15/nTeqjGWp3dmcHeAdPIXW DX7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FZw4YFA/OEyEoqquqWDfR4UbTErRB7u81KtBFQ0bNMo=; b=o4lJSbA9ErPwjmicjqbySq57UTwegZr5+uReun+zEkMgcyaNCE3lK6sfS3MKWdsOQA ViojQcmUbk6dNd6zqs8w4NNS8ROpprPhXLzYqDsVijAZNkZux1weQ/7b9i9jtImE1UxX OC7usnX2TBNXKseUL0XLo9ugE4KRvLg6cKypsaY4x0ocgkFAgb/kll5IyHY3mRM2MEaS oQM1pRWY93qB16aZuj1F7AB7wThPVmSgL3/QOAkodK7hXZAw+rDP2NH6oYIg47Fw6yMj +rSnZTxaiTRgK/mBdzKuyJnLh9h4GwlT/md9vzc3sWg5LLn4Ap0Y1Ss5IzPmcpxMM0kf 7ESA== X-Gm-Message-State: AJaThX4o1nIevLdf8QjxbmvfrENhyX+Kvq4zUlWND8jbrTaOzirrtd8y o0DFXq7niYBNK6tg9svthrbWHQBOm3QjK7ygzSau+Omecmg= X-Google-Smtp-Source: AGs4zMbonQSnGAttf+jqP3SqEY53z95PoSNI+/jHhiA80uvnvT+QaK4qcIrFgtxYjKxUcDM55XYf8xfMundh8bwhus4= X-Received: by 10.200.3.194 with SMTP id z2mr7275102qtg.309.1510757498331; Wed, 15 Nov 2017 06:51:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.6.210 with HTTP; Wed, 15 Nov 2017 06:51:17 -0800 (PST) From: Mike West Date: Wed, 15 Nov 2017 15:51:17 +0100 Message-ID: To: dnsop WG Content-Type: multipart/alternative; boundary="f40304379228085c15055e06a4bc" Archived-At: Subject: [DNSOP] `localhost` and DNS. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 14:51:42 -0000 --f40304379228085c15055e06a4bc Content-Type: text/plain; charset="UTF-8" Hey folks! Skimming through the recording of Monday's meeting (starting at around 53:56), it sounds to me as though there's at least loose agreement that signing a response for `localhost` is not what we'd like to recommend: all the folks who commented explicitly took that position for similar reasons. The current text in https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-01#section-4.2 reflects this position, and IMO it's what we should run with. Are there contrary opinions that weren't expressed in the room on Monday? If not, is there additional work we need to do on the draft before moving on? I believe the remaining feedback that's been provided on the list has been addressed in the current -01. Also, one suggestion made at the mic is that `127.0.0.1` isn't the only loopback address (with the example of FreeBSD jails). I believe the current draft accepts that reality by allowing a range of loopback addresses in https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-01#section-2. Are there loopback addresses outside the 127.0.0.0/8 range? Thanks! -mike --f40304379228085c15055e06a4bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey folks!

Skimming through the recording of Monday's meeting=C2=A0(starting at around 53:5= 6), it sounds to me as though there's at least loose agreement that sig= ning a response for `localhost` is not what we'd like to recommend: all= the folks who commented explicitly took that position for similar reasons.= The current text in=C2=A0https://tools.ietf.org/ht= ml/draft-ietf-dnsop-let-localhost-be-localhost-01#section-4.2=C2=A0refl= ects this position, and IMO it's what we should run with.
Are there contrary opinions that weren't expressed in the r= oom on Monday? If not, is there additional work we need to do on the draft = before moving on? I believe the remaining feedback that's been provided= on the list has been addressed in the current -01.

Also, one suggestion made at the mic is that `127.0.0.1` isn't the on= ly loopback address (with the example of FreeBSD jails). I believe the curr= ent draft accepts that reality by allowing a range of loopback addresses in= =C2=A0https://tools.ietf.org/html/draft-ietf-dnsop-le= t-localhost-be-localhost-01#section-2. Are there loopback addresses out= side the 127.0.0.0/8 range?
Thanks!

-mike
--f40304379228085c15055e06a4bc-- From nobody Wed Nov 15 07:35:41 2017 Return-Path: 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 0D7491204DA for ; Wed, 15 Nov 2017 07:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 Z1zUO5FhTnU9 for ; Wed, 15 Nov 2017 07:35:38 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 2B89D1200FC for ; Wed, 15 Nov 2017 07:35:38 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:46795) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eEziu-000YQD-1k (Exim 4.89) (return-path ); Wed, 15 Nov 2017 15:35:32 +0000 Date: Wed, 15 Nov 2017 15:35:32 +0000 From: Tony Finch To: Paul Wouters cc: Jacques Latour , "dnsop@ietf.org" In-Reply-To: Message-ID: References: <20171113014445.ncldrwnuuvluecx7@mx4.yitter.info> <5A08FD96.8030907@redbarn.org> <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <20171113183004.GA35038@isc.org> <436111CF-FCA8-44A2-B83D-6540DE6D64AC@icann.org> <66BA5F27-B044-459B-A2B2-54221FD768C6@isc.org> <20171113233756.GA37394@isc.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 15:35:40 -0000 Paul Wouters wrote: > On Tue, 14 Nov 2017, Jacques Latour wrote: > > > Personally, I like a mix of #3 and #1, on a regular basis poll the entire > > zone for changes, and have a mechanism to listen to child notifications > > for urgent changes. > > Agreed. Yes. > > _AND_ remember, the preferred method by far is to submit a DS/DNSKEY > > record is via the RRR EPP model. The above is when that RRR EPP model is > > non functional. > > That preference might be political not technical. I personally like the > DNS based solutions over the EPP based one, because it requires no > humans or webgui's :) EPP isn't available to most registrants or operators, since it's a registrar <-> registry protocol -- remember the motivation for CDS/CSYNC was lack of any operator <-> registrar update protocol, and lack of any way to provide registrar credentials to DNS operators. There are plenty of parent zones which don't have an EPP back end - examples I care about include the reverse DNS, ac.uk, cam.ac.uk, etc. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode South Utsire, Southeast Forties: Northwesterly backing southerly 5 or 6, increasing 7 or gale 8 later. Moderate or rough. Showers, rain later. Good, occasionally poor later. From nobody Wed Nov 15 13:05:17 2017 Return-Path: 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 C3CFE1273E2 for ; Wed, 15 Nov 2017 13:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 72tVW0tvZK2U for ; Wed, 15 Nov 2017 13:05:14 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178ED1271FD for ; Wed, 15 Nov 2017 13:05:14 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id 17so17880969pfn.12 for ; Wed, 15 Nov 2017 13:05:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=woEQ7eL6N1MohiQ5zpguu5sGGGyK+c3YfngIPYmGXw0=; b=M2R52IxLD1QuvdyTJ6uVrewgQkLUyJBfXW1Le11/vGmv9qhZ9Cngw9+c6jsCSSQXOu 7cu68sX9pmPqKa2AjEklFGC2n+49TOIxXqDrABcE4zTRVqxhvn63jYljYS8/TqllWRVx 1ElZ0J+KAoLlcVk2VLDREMbGxpBUz4Q6Onz62Es7UPgjVjnBCz+Ah/kwx1EdXBRLQ3TU c4sOhxsXbHS3RCIxVk1hSDhdh259NeFb/N0iZt5bLZgGnchCQ/vF0KKv3iOP4rhtXYSs GQ5vi7+1j5QLspUw5M/GU+qTNhF6XAnh89Gu9YLTEq1e+fE/VGg+ARiK+4TKD7u/DFMY p0sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=woEQ7eL6N1MohiQ5zpguu5sGGGyK+c3YfngIPYmGXw0=; b=AbECa4vcGV94mbUqxrEgpTHicltrYLi6FqGF3bq/clZocNMu4XpQrSKgxZHHbolSPp ee29mxJ24uuJf0ZmE10FtEaTbZ1L12XOrWBqBwlYWMwjDDWvCKIx/N/Xx/jt/bTH6KCp Jx1W/nUzS8duSDcrvzhKuYH/3VCq0COMFdzeheyKOeI/Wtw9LWLBmtFlz7UR9NlFJP/+ q8YmBufu8thcTy162f1m5l13SboPh4SzD8yt+uBUxpZSoPc5udgyBLs+2YZ3qc/8ykEE 54C+1k37yigwfm/frM4htuB/KeXbdvF+xkuKGB9Fb7uDMFzWpWekDUtohB0BGzmmwwVd E6KQ== X-Gm-Message-State: AJaThX5gpnl0TtpvR9FLrwGfHfUroFdnL07OyriDk6OtlRViOKfiLxIq WcKsYt7yzv2RQlqPbtSE4i6/OfilMY8= X-Google-Smtp-Source: AGs4zMZencPza4l+0AOjj0yogu/SnJWBn/kQvEbo873JRCd8vOMTnRwQdSLF7YiN9jvDXg4ZOXoatA== X-Received: by 10.84.247.148 with SMTP id o20mr7103006pll.137.1510779913599; Wed, 15 Nov 2017 13:05:13 -0800 (PST) Received: from [192.168.43.27] ([111.65.61.187]) by smtp.gmail.com with ESMTPSA id 62sm21036268pgh.31.2017.11.15.13.05.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 13:05:13 -0800 (PST) From: Ted Lemon Message-Id: <57BD04DF-B473-41B8-9ECD-D197232365FB@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DF6B7816-67BF-419C-85BC-2AA6D3CA79BF" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 16 Nov 2017 05:05:05 +0800 In-Reply-To: Cc: dnsop WG To: Mike West References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] `localhost` and DNS. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 21:05:16 -0000 --Apple-Mail=_DF6B7816-67BF-419C-85BC-2AA6D3CA79BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 15, 2017, at 10:51 PM, Mike West wrote: > Skimming through the recording of Monday's meeting = (starting at around 53:56), it sounds to me as though there's at = least loose agreement that signing a response for `localhost` is not = what we'd like to recommend: all the folks who commented explicitly took = that position for similar reasons. The current text in = https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-01= #section-4.2 = reflects this position, and IMO it's what we should run = with. Yes, the current text appears to me to be correct. --Apple-Mail=_DF6B7816-67BF-419C-85BC-2AA6D3CA79BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Nov 15, 2017, at 10:51 PM, Mike West <mkwst@google.com> = wrote:
Skimming through the recording of Monday's meeting (starting = at around 53:56), it sounds to me as though there's at least loose = agreement that signing a response for `localhost` is not what we'd like = to recommend: all the folks who commented explicitly took that position = for similar reasons. The current text in https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-l= ocalhost-01#section-4.2 reflects this position, and IMO it's = what we should run with.

Yes, the current text appears to me to be correct.

= --Apple-Mail=_DF6B7816-67BF-419C-85BC-2AA6D3CA79BF-- From nobody Wed Nov 15 16:01:56 2017 Return-Path: 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 624161292FD for ; Wed, 15 Nov 2017 16:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 7Tt2Srl-Ke14 for ; Wed, 15 Nov 2017 16:01:52 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35F4129353 for ; Wed, 15 Nov 2017 16:01:51 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id y42so21924705wrd.3 for ; Wed, 15 Nov 2017 16:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6TE8FhlOubUv15oeA7Gc7sbQokvhMDs9XAM8wsbj610=; b=YBNrBSX0qV50chuJg+HSOr5fc2drOyza8g5XP0LkQgwb6V6jZm5fLlFcOZF7jG/1Mi NkF03SdjJt5+Kd/Rg9pqNY+Wj+gbPzqeW8iehUYxcALVlOeF8o48+OqfkyMvT3DOS+iB ILAUK9ozcAspus+vhq0a9nHwRKfW+fUw5299OP2lIFGztjEOTetsTyuY8310hEbFMxoC eVZSwSP8o6iSUySUMUzRXE9KA8N96K5n++jgrgzyziktdTnPBEYcyDwGz1C7y8Jl6Qbt 5Rrv4O/wI2Rqtf/9KpqePoWkC2hLLIHr6z8+7Ecem2t4FKssnaDB9y4KI10AT78YK2gN 4v7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6TE8FhlOubUv15oeA7Gc7sbQokvhMDs9XAM8wsbj610=; b=eENEY1LWMJEed6kolTZ8WXAbMPwwQ2ERLvKWYxhLQmfxO/2Xk0kPP+w8sWIn3eskgY LBnhi+JCs0+PytKeesDkjsLceuzBhPXInIK/CRfJBbXoUXI/Hq/vVJGkXrszpzRo+qPS EPKwo+AJjwcMk++v3DIPOAP/CXGiQZdMPi6RqcJ+NZzdQtstORLOJtzf1YZ1zhtlW8OX 46XGlz4TG00NPomuwoSHlzbBI8n5SJrv+lMEpygbE0/xQal3Vnedbvbummo7AjkWbkNk +klA/TvQ656N/UgecjlRvVfYPUhQMIwieqwYw5fmM3OMZKr+T4q/lL6z9VBcNe5rMcwu q3NQ== X-Gm-Message-State: AJaThX7S7HxHLTfdSxon0g+Cn2eYuGbTz2toV7ngxyMUnRXRG3HOKJrv 8WgJ7/jZtUe0R+3STTdjC2SaNia60QzIMDRAIvqUKw== X-Google-Smtp-Source: AGs4zMbTKMA2KetANvSI33akAPjuNW/HIvUMKiVcPvhmQi+47Ks4BZkNzfoGJv9LNRhk2BHhFIGwZegHx7cmBIKPLl8= X-Received: by 10.223.169.100 with SMTP id u91mr304284wrc.108.1510790510094; Wed, 15 Nov 2017 16:01:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Wed, 15 Nov 2017 16:01:49 -0800 (PST) In-Reply-To: <57BD04DF-B473-41B8-9ECD-D197232365FB@fugue.com> References: <57BD04DF-B473-41B8-9ECD-D197232365FB@fugue.com> From: Richard Barnes Date: Thu, 16 Nov 2017 08:01:49 +0800 Message-ID: To: Ted Lemon Cc: Mike West , dnsop WG Content-Type: multipart/alternative; boundary="f403045cf7ecaf3b41055e0e532e" Archived-At: Subject: Re: [DNSOP] `localhost` and DNS. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 00:01:54 -0000 --f403045cf7ecaf3b41055e0e532e Content-Type: text/plain; charset="UTF-8" On Thu, Nov 16, 2017 at 5:05 AM, Ted Lemon wrote: > On Nov 15, 2017, at 10:51 PM, Mike West wrote: > > Skimming through the recording of Monday's meeting > (starting > at around 53:56), it sounds to me as though there's at least loose > agreement that signing a response for `localhost` is not what we'd like to > recommend: all the folks who commented explicitly took that position for > similar reasons. The current text in https://tools.ietf.org/ > html/draft-ietf-dnsop-let-localhost-be-localhost-01#section-4.2 reflects > this position, and IMO it's what we should run with. > > > Yes, the current text appears to me to be correct. > +1 > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --f403045cf7ecaf3b41055e0e532e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Nov 16, 2017 at 5:05 AM, Ted Lemon <mellon@fugue.com> wrote:
On Nov 15, 2017, at 10:51 PM, Mike West <mkwst@google.com> wro= te:
Skimming through the=C2=A0recording of Monday's meeting=C2=A0(starting at around= 53:56), it sounds to me as though there's at least loose agreement tha= t signing a response for `localhost` is not what we'd like to recommend= : all the folks who commented explicitly took that position for similar rea= sons. The current text in=C2=A0ht= tps://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-local= host-01#section-4.2=C2=A0reflects this position, and IMO it's = what we should run with.

Yes,= the current text appears to me to be correct.

+1

=C2=A0

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--f403045cf7ecaf3b41055e0e532e-- From nobody Wed Nov 15 18:44:34 2017 Return-Path: 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 11F87126CC4 for ; Wed, 15 Nov 2017 18:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hiGfViqdzyJw for ; Wed, 15 Nov 2017 18:44:30 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CED129421 for ; Wed, 15 Nov 2017 18:44:16 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id t139so6689418wmt.1 for ; Wed, 15 Nov 2017 18:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=v4s49NX+xzDToI6wwecehIlnKna+6LtoGu50jEGCuC8=; b=ewzlJK3GoOP9CHkG9nq24biwClguYTuXDnIxZGpJCgyeYqIWSHE1pa1QdUJulOZXuS 8000VXmVqSwZPuRf8MsOycYFfTRSuKWU7dyNSfZMQruktOZBUq1aJThp9JYBKXzdgtYu B17j3Z2yJIzN/9MtcMBzC2BfACMqVOentvTbpXg6kg1EMvDw0sGhVJn+NPsUxWKn8XZb abEeU6WbQ45vAUKXg/7/AJaZOUByi7754Z+e6SP/UAyYvQzUa+MrrTrtVYgyN+yq4Yi+ sVqBpI1l0E9xWy72rjn1WIX97HlyDshz+8k/xl/pRwJqP9rApBmCDz1LFyOwKPUaXORz 4FKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=v4s49NX+xzDToI6wwecehIlnKna+6LtoGu50jEGCuC8=; b=o7xdwzCm9SQsOcz0atk8hkmBJtZZNsQEJ0zaCDgT9M8KOy7Uc+XfTvmq49Snp2FS5a zWW3F8uvR2UCEHo4Vtgtdkv13m2qD5xkk+VwtK8WrR//obw9YqYaHpKA7GSDRAKD6rZg R9sCuwq8V5J8BxkCZNY0Gnc2ZxeKW3KnNbdZjhoMleEih8pA3xMSEc0dRHs+LYAfkyxO xHBWqNi1E/6NZGCGq7iQcPJ6944be+/qYe/3McMqJqPF4VOn1dntrD3ooSyTCI9XqKpY NJxL0LAHDE0r2yLINNXtYORj1nG5lQxjDMH4G/RIli2QjwDGFx7sfhY3yglZ7GLMxPg5 8kOw== X-Gm-Message-State: AJaThX5Q+AtUPtdP8zvPGxavwABk+NWnuxCNBO6oB4W0Hjxz23DcCcZ+ FGpgpsblwyOlmKTd/7OQnWUCoKz5uSkv4mwlOrJBuA== X-Google-Smtp-Source: AGs4zMY+YhRhykchLQyipvTgo5CNv1litw/jRtL22IgTYvQC1U/0raz0f1CBOQDEiV4LPnWp7jZCCS52DqujMPpLhNQ= X-Received: by 10.28.120.19 with SMTP id t19mr303254wmc.64.1510800255315; Wed, 15 Nov 2017 18:44:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.146.229 with HTTP; Wed, 15 Nov 2017 18:44:14 -0800 (PST) From: tjw ietf Date: Thu, 16 Nov 2017 10:44:14 +0800 Message-ID: To: dnsop Content-Type: multipart/mixed; boundary="089e082fadd08ba07a055e10983c" Archived-At: Subject: [DNSOP] Draft Minutes from IETF100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 02:44:33 -0000 --089e082fadd08ba07a055e10983c Content-Type: multipart/alternative; boundary="089e082fadd08ba077055e10983a" --089e082fadd08ba077055e10983a Content-Type: text/plain; charset="UTF-8" Thanks again to Paul Hoffman for taking the minutes. please take a look to see if there are any updates that need to be made and let the chairs know. https://datatracker.ietf.org/meeting/100/materials/minutes-100-dnsop/ You can also just submit a pull request: https://github.com/DNSOP/wg-materials/blob/master/ietf100/dnsop-ietf100-minutes.txt Thanks again. We'll send out a chairs note on we see direction and outcomes from the meeting today/tomorrow. tim --089e082fadd08ba077055e10983a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks again to Paul Hoffman for taking the minut= es. =C2=A0please take a look to see if there are any updates that need to b= e made and let the chairs know.=C2=A0

https= ://datatracker.ietf.org/meeting/100/materials/minutes-100-dnsop/

You can also just submit a pull request:=C2=A0
=


Thanks again.=C2=A0 We'll send out a chairs note on we see dire= ction and outcomes from the meeting today/tomorrow.=C2=A0

tim

--089e082fadd08ba077055e10983a-- --089e082fadd08ba07a055e10983c Content-Type: text/plain; charset="UTF-8"; name="dnsop-ietf100-minutes.txt" Content-Disposition: attachment; filename="dnsop-ietf100-minutes.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ja1veu390 RE5TT1AgV0cgbWludXRlcwpJRVRGIDEwMCwgU2luZ2Fwb3JlCjIwMTctMTEtMTMKVGltIFdpY2lu c2tpIGFuZCBTdXphbm5lIFdvb2xmLCBjaGFpcnMKTWludXRlcyB0YWtlbiBieSBQYXVsIEhvZmZt YW4KTWF0ZXJpYWwgZnJvbSB0aGUgc2xpZGVzIG5vdCByZXByb2R1Y2VkIGhlcmUKCkFnZW5kYSBC YXNoaW5nLCBCbHVlIFNoZWV0cwoKVXBkYXRlcyBvZiBPbGQgV29yayAtIENoYWlycwoKZHJhZnQt aWV0Zi1kbnNvcC10ZXJtaW5vbG9neS1iaXMgLSBQYXVsIEhvZmZtYW4KICAgICAgICBDb25zaWRl ciBnZXR0aW5nIHlvdXIgYXNzaXRhbnRzIC8gY29sbGVhZ3VlcyAvIGJvc3NlcyB3aG8gc2hvdWxk IHVuZGVyc3RhbmQgdGhlIEROUyBtb3JlIHRvIHJldmlldwogICAgICAgIEFsZXggTWV5ZXJob2Zl cjogVm9sdW50ZWVycyB0byByZXZpZXcgdGhlIHdob2xlIGRvY3VtZW50CiAgICAgICAgICAgICAg ICBNYXliZSBkZWZpbmUgImxvY2FsIGFueWNhc3QiCiAgICAgICAgU3TDqXBoYW5lIEJvcnR6bWV5 ZXI6IERpc2FncmVlcyB3aXRoIGhvdyBQYXVsIGRpc2N1c3NlZCBRTkFNRSBpbiB0aGUgc2xpZGVz CiAgICAgICAgICAgICAgICBXZSBuZWVkIHRvIGRlY2ljZSB3aGV0aGVyIHRvIHJvbGwgYmFjayB0 byBvbGQgZGVmaW5pdGlvbiwgb3IgYWNrbm93bGVkZ2UgdGhhdCB0aGVyZSBhcmUgdHdvIGRlZmlu aXRpb25zCiAgICAgICAgICAgICAgICBQYXVsOiBEbyB3ZSBhY2tub3dsZWRnZSB0aGF0IHNvbWUg cGVvcGxlIGFyZSB1c2luZyB0aGUgbmV3IG9uZSBidXQgbW9zdCBwZW9wbGUgYXJlIHVzaW5nIHRo ZSBvbGQgb25lCiAgICAgICAgU3V6YW5uZTogV2Ugc2hvdWxkIGhhdmUgYSByYWZmbGU6IGFkb3B0 LWEtdGVybQogICAgICAgIEJpbGwgTWFubmluZzogVGVybWlub2xvZ3kgaXMgbm90IHN0YXRpYwog ICAgICAgICAgICAgICAgUGVvcGxlIHdpbGwgY29tZSB1cCB3aXRoIG5ldyB0ZXJtcyBvdmVyIHRp bWUKICAgICAgICBBbmRyZXcgU3VsbGl2YW46CiAgICAgICAgICAgICAgICBObyBvbmUgdGhpbmtz IHdlJ3JlIHBvdXJpbmcgY29uY3JldGUKICAgICAgICAgICAgICAgIFRoaXMgaXMganVzdCBsaWtl IG5vcm1hbCBkaWN0aW9uYXJpZXMKICAgICAgICBUaW06IFRoaXMgd2lsbCBiZSBTdGFuZGFyZHMg VHJhY2sgd2hlcmVhcyBSRkMgNzcxOSB3YXMgSW5mb3JtYXRpb25hbAoKZHJhZnQtaWV0Zi1kbnNv cC1yZmM1MDExLXNlY3VyaXR5LWNvbnNpZGVyYXRpb25zIC0gV2VzIEhhcmRha2VyCiAgICBBIGJ1 bmNoIG9mIGNvbW1lbnRzIGZyb20gYSBmZXcgcGVvcGxlCiAgICBOZXcgdmVyc2lvbiBjb21pbmcg b3V0IHRoaXMgd2VlawogICAgU2hvdWxkIHRoaXMgYmUgcHVibGlzaGVkIGF0IGFsbD8KICAgICAg ICBOZWVkIG1vcmUgb3BpbmlvbnM/CiAgICAgICAgR2VvcmdlIE1pY2hhZWxzb246IERpc2FncmVl cyB3aXRoIEVkIGFib3V0IGl0J3MgdGhlIHdyb25nIGF1dGhvcnMKICAgICAgICAgICAgICAgIFN0 cnVnZ2xlcyB3aXRoIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBtYXRoCiAgICAgICAgICAgICAgICBJ dCdzIGRheXMsIG5vdCBzZWNvbmRzCiAgICAgICAgRGF2aWQgTGF3cmVuY2U6IFNob3VsZCBiZSBh ZHZhbmNlZCwgc3VwcmlzZWQgdGhhdCB0aGVyZSBpcyBldmVuIGEgcXVlc3Rpb24KICAgICAgICAg ICAgICAgIEZvY3VzIG9uIHRoZSB3b3JkcyBiZWluZyBzYWlkCiAgICAgICAgSm9lIEFibGV5OiBT aG91bGQgYmUgcHVibGlzaGVkLCBldmVuIHRob3VnaCB0aGVyZSBpcyBwcm9iYWJseSBqdXN0IG9u ZSB6b25lIGltcG9ydGFudAogICAgICAgICAgICAgICAgVG9vayBzb21ldGhpbmcgdGhhdCB3YXMg Y29tcGxpY2F0ZWQsIGFuZCBtYWRlIGl0IG1vcmUgY29tcGxpY2F0ZWQKICAgICAgICAgICAgICAg IEhhc24ndCBoZWFyZCBhbnlvbmUgc2F5IGludGVydmFscyBpcyBpbXBvcnRhbnQsIGxpa2VzIHdh bGwgdGltZSBiZXR0ZXIKICAgICAgICBEYXZpZCBDb25yYWQ6IFRoaW5rcyBFZCBtZWFudCB0aGF0 IHRoZXJlIHNob3VsZCBiZSBtb3JlIG9wZXJhdG9yIGlucHV0CiAgICAgICAgICAgICAgICBTdXBw b3J0cyBwdWJsaWNhdGlvbgogICAgICAgICAgICAgICAgUHJlZmVycyBpbnRlcnZhbAogICAgICAg IE1pa2UgU3RKb2huczogUm9vdCBkaWQgdHdvIHRoaW5ncyBoZSBkaWRuJ3QgY29udGVtcGxhdGUK ICAgICAgICAgICAgICAgIFNpbmdsZSB0cnVzdCBhbmNob3Igc3RlYWR5IHN0YXRlCiAgICAgICAg ICAgICAgICBFYXJseSBzaWduYXR1cmVzIG9mIHRoaW5ncyB0aGF0IG1ha2UgaXQgaW4gdGhlIHdp bGQKICAgICAgICBFcmljIE9zdGVyd2VpbDogR29vZCB0byBwdWJsaXNoIGJlY2F1c2UgaXQgaXMg Z29vZCB0byBzaG93IHBlcnNwZWN0aXZlcwogICAgTW9yZSBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0 IG9uIGludGVydmFsIHZzLiB3YWxsIHRpbWUKCmRyYWZ0LWlldGYtZG5zb3AtZXh0ZW5kZWQtZXJy b3IgLSBXZXMgSGFyZGFrZXIKICAgICAgICBGb3VyIGNob2ljZXMgZm9yIGhvdyB0byBjcmVhdGUg dGhlIGZ1bGwgZXJyb3IgY29kZQogICAgICAgICAgICAgICAgUGF1bCBIb2ZmbWFuOiBUaGlzIGRp ZG4ndCB3b3JrIHdlbGwgaW4gSFRUUCwgdXNlIGNob2ljZSA0CiAgICAgICAgICAgICAgICBTdGVw aGFuZTogVGhlcmUgbWlnaHQgYmUgZXJyb3JzIHRoYXQgd291bGQgY3Jvc3MgbXVsaXRwbGUgY2F0 ZWdvcmllcwogICAgICAgICAgICAgICAgSm9lOiBGaXJzdCB0aHJlZSBuZWVkIGFkZGl0aW9uYWwg cHJvY2Vzc2luZywgc28gZm91cnRoIGlzIHRoZSBvbmx5IHJlYXNvbmFibGUgb25lCiAgICAgICAg ICAgICAgICBSYWxmIFdlYmVyOiBDb3B5aW5nIGluZm9ybWF0aW9uIHdlIGFscmVhZHkgaGF2ZSBp biB0aGUgcGFja2V0IGlzbid0IGEgZ29vZCBpZGVhCiAgICAgICAgICAgICAgICBBbGV4OiBJQU5B IHJlZ2lzdHJ5IGNvdWxkIGFsc28gaGF2ZSB0aGUgbGlzdCBvZiB3aGljaCBSQ09ERXMgY291bGQg YmUgdXNlZCB0b2dldGhlcgogICAgICAgIFN0ZWZhbjogRm9yIHNlY3VyaXR5LCB1c2UgRE5TLW92 ZXItVExTCiAgICAgICAgRXJpYzogU2VjdXJpdHkgY29uY2VybjogaXQncyBPSyBhcyBsb25nIGFz IHlvdSB0aGluayBhYm91dCB3aGF0IHdpbGwgY2F1c2UgYW4gYWN0aW9uIGJhc2VkIG9uIGVycm9y CiAgICAgICAgICAgICAgICBEb24ndCB1c2UgdHJhbnNwb3J0IHNlY3VyaXR5CiAgICAgICAgUm9i ZXJ0IFN0b3J5OiBNYXliZSB1c2UgZmxhZ3MgaW5zdGVhZCBvZiBjb2RlCiAgICAgICAgICAgICAg ICBXZXM6IEl0IGNvdWxkIGdldCByZWFsbHkgbG9uZwogICAgICAgIEpvZTogVGhpcyBpcyBkZWZp bml0ZWx5IHRyYW5zcG9ydCwgbm90IG9iamVjdHMKICAgICAgICAgICAgICAgIENvZGVzIGFyZSBh Ym91dCB0cmFuc3BvcnQKICAgICAgICAgICAgICAgIFdlczogQXJlIHdlIG9ubHkgZG9pbmcgdGhp bmdzIHRoYXQgYXJlIHRyYW5zcG9ydC1zcGVjaWZpYz8KICAgICAgICBTdGVwaGFuZTogT3BlbiBx dWVzdGlvbiBhYm91dCB3aGV0aGVyIHRvIGhhdmUgaW5mb3JtYXRpb25hbCBtZXNzYWdlcwoKZHJh ZnQtaWV0Zi1kbnNvcC1sZXQtbG9jYWxob3N0LWJlLWxvY2FsaG9zdCAtIFRpbQogICAgICAgIE1h am9yIGlzc3VlIGlzIEROU1NFQwogICAgICAgIFN1emFubmU6IGlmIHRoZSBuYW1lIG5lZWRzIHRv IGJlIHNpZ25lZCwgd2Ugd291bGQgbmVlZCB0byBnZXQgaXQgaW4gdGhlIHJvb3QKICAgICAgICBX YXJyZW4gS3VtYXJpOiBUaGlua3MgdGhhdCBOWERPTUFJTiBpcyBhIGZpbmUgYW5zd2VyIGZvciB3 aGF0IHRoaXMgbmVlZHMKICAgICAgICBXZXM6IFdlIGtub3cgdGhhdCB0aGVyZSBhcmUgbXVsdGlw bGUgbmFtaW5nIHN5c3RlbXMsIHNvIE5YRE9NQUlOIGlzIGEgZ29vZCBhbnN3ZXIgaGVyZQogICAg ICAgICAgICAgICAgVGhpcyBpcyBvdXRzaWRlIHRoZSBETlMsIHNvIGZhbGwgYmFjayB0byBvbmUg b2YgeW91ciBsb2NhbCByZXNvbHV0aW9uIHN5c3RlbQogICAgICAgIFdpbGxlbSBUb3Jvb3A6IEZy ZWVCU0QgamFpbHMgbmVlZCBpbmRpdmlkdWFsIGxvb3BiYWNrIGFkZHJlc3NlcwoKZHJhZnQtYmVs bGlzLWRuc29wLXhwZiAtIFJheSBCZWxsaXMKICAgICAgICAoTm8gc2xpZGVzKQogICAgICAgIExv dHMgb2YgZmVlYmFjayBmcm9tIGxhc3QgbWVldGluZywgdXBkYXRlZCBkcmFmdAogICAgICAgIEFs cmVhZHkgaGF2ZSBvbmUgaW1wbGVtZW50YXRpb246IGRucy1kaXN0CiAgICAgICAgTWFueSBoYXZl IHJlYWQgdGhlIGRyYWZ0CiAgICAgICAgU2FyYSBEaWNrZW5zb24gaGFkIHJhaXNlZCBwcml2YWN5 IG9iamVjdGlvbnMgZWFybGllcgoKZHJhZnQtZnVqaXdhcmEtZG5zb3AtYWRkaXRpb25hbC1hbnN3 ZXJzIC0gS2F6dW5vcmkgRnVqaXdhcmEKICAgICAgICBXZXM6IFRoaXMgYW5kIG11bGl0cGxlLXJl c3BvbnNlcyBjb3VsZCBiZSBjb21iaW5lZC4KICAgICAgICBCZW5ubyBPdmVyZWluZGVyOiBHb29k IGNoYXJ0LgogICAgICAgIE11a3VuZCBTaXZhcmFtYW46IEluIEJJTkQsIG1vdmluZyBhd2F5IGZy b20gbGFyZ2UgcmVzcG9uc2VzLgogICAgICAgICAgICAgICAgR3Vlc3Npbmcgd2hhdCB0byBhZGQg aW4gYSByZXNwb25zZSB3YXN0ZXMgdGltZQogICAgICAgIE9uZHJlaiBTdXJ5OiBXaGF0IGFyZSB3 ZSBhY3R1YWxseSBzYXZpbmc/CiAgICAgICAgICAgICAgICBBZGRpb25hbCBhbnN3ZXJzIGluY3Jl YXNlcyBjb21wbGV4aXR5IGFuZCBvdmVyaGVhZCBhbmQgRERvUyB2ZWN0b3IKICAgICAgICAgICAg ICAgIElzIHRoaXMgcmVhbGx5IGhlbHBmdWwgYmV5b25kIGJvb3RzdHJhcHBpbmcgb3IganVzdCBs b3cgVFRMPwogICAgICAgIFJhbGY6IEFsbCBvZiB0aGlzIGlzIHNvbHZpbmcgYSB0ZXJyaWJseSBz bWFsbCBwcm9ibGVtCiAgICAgICAgICAgICAgICBDYWNoZSBoaXQgcmF0ZXMgYXJlIGFscmVhZHkg c28gaGlnaAogICAgICAgICAgICAgICAgQWRkcyBjb21wbGV4aXR5IHRvIHRoZSBjb2RlCiAgICAg ICAgRGF2ZTogU3RpbGwgc3VwcG9ydHMgbXVsdGktUVRZUEVzCiAgICAgICAgICAgICAgICBEZXBs b3ltZW50IGlzIGdyYWR1YWwgYmVjYXVzZSB0aGUgY2xpZW50IGFza3MKICAgICAgICBKaWFua2lu ZyBZYW86IFRoZSBXRyBpcyBvYnZpb3VzbHkgaXNzdWVkIGluIHRoZSB0b3BpYwogICAgICAgICAg ICAgICAgRGVtb25zdHJhdGVzIGNvb3BlcmF0aW9uIG9mIHByb3Bvc2FscwogICAgICAgIENhcmwg QW5kZXJzb246IE5lZWRzIGEgY29zdC1iZW5lZml0IGFuYWx5c2lzIG9mIGhvdyBtdWNoIG1vcmUg eW91IGdldAogICAgICAgIEppbSBSZWlkOiBOZWVkcyBhIGNvc3QtYmVuZWZpdCBhbmFseXNpcwog ICAgICAgICAgICAgICAgVGltOiBQZW9wbGUgbGlrZSBjbGllbnRzIGFza2luZyBpbnN0ZWFkIG9m IHNlcnZlcnMgdGVsbGluZwogICAgICAgIEJpbGw6IFRoaXMgaXMgYSBnb29kIHZlbnVlIGZvciBh biBhdHRhY2sgcHJvZmlsZQogICAgICAgIEpvZTogVGhlIGFtb3VudCBvZiBiYW5kd2lkdGggaXMg c28gY2xvc2UgdG8gemVybyBhcyB0byBiZSBmcmVlCiAgICAgICAgRGF2ZXkgU29uZzogTmVlZCB0 byB0aGluayBhYm91dCBJUHY2IGNvbnRleHQgZm9yIHNpemVzCiAgICAgICAgSXNhYmVsbCAoPyk6 IEhhcHB5IHRvIGJlIHJldmlld2luZwogICAgICAgIFN1emFubmU6IExvdCBvZiBpbnRlcmVzdCBp biB0aGUgZ2VuZXJhbCBwcm9ibGVtIHNwYWNlCiAgICAgICAgICAgICAgICBDaGFydCBpcyB2ZXJ5 IGdvb2QgdG8gdGhlIHBvaW50CiAgICAgICAgICAgICAgICBXaGF0IHByb2JsZW1zIGRvIHRoZXNl IHByb3Bvc2FscyBzb2x2ZSB0aGF0IGFyZSB3b3J0aCBkb2luZwogICAgICAgICAgICAgICAgV2hv IHdpbGwgd29yayBvbiB1c2UgY2FzZXM/CiAgICAgICAgICAgICAgICAgICAgICAgIERhdmlkIExh d3JlbmNlLCBJc2FiZWxsCiAgICAgICAgICAgICAgICBUaW06IHdlIGNhbiBzdGFydCBmcm9tIHRo ZSB0YWJsZSBhbmQgbWF5YmUgYWRkIHJvd3MKICAgICAgICAgICAgICAgIFJheTogRm91bmQgcHJv YmxlbXMgaW4gdGhlIHRhYmxlCiAgICAgICAgICAgICAgICBBbGV4OiBJZiBvcGVyYXRvciBjYW4g ZG8gYSBjb3N0IHNpbXVsYXRpb24gb3IgYSBiZW5lZml0IHNpbXVsYXRpb24sIHRoYXQgd291bGQg YmUgZ29vZAoKZHJhZnQtbWdsdC1kbnNvcC1kbnNzZWMtdmFsaWRhdG9yLXJlcXVpcmVtZW50cyAt IERhbmllbCBNaWdhdWx0CiAgICAgICAgUmFsZjogVGhpbmtzIGl0IGlzIGdvb2Qgd29yawogICAg ICAgIEppbTogUmV2b2tpbmcgZGF0YSBpbiBhIGNhY2hlIGJlY2F1c2UgdGhlIGtleSBoYXMgZ29u ZSBiYWQgaXMgYSBiYWQgaWRlYQogICAgICAgICAgICAgICAgTGVhdmUgaXQgYXMgdGhlIFRUTAog ICAgICAgICAgICAgICAgRG9uJ3QgYWRkIGNvbXBsZXhpdHkgdG8gc29tZXRoaW5nIGFscmVhZHkg Y29tcGxleAogICAgICAgIEpvZTogQWdyZWVzIHdpdGggSmltCiAgICAgICAgICAgICAgICBTdGls bCB3b3VsZCBsaWtlIFdHIHRvIHBpY2sgdXAgdmFsaWRhdG9yIGJvb3RzdHJhcHBpbmcKICAgICAg ICAgICAgICAgICAgICAgICAgU2hvdWxkIGJlIG9mZiB0byB0aGUgc2lkZQogICAgICAgIEVyaWM6 IEFsc28gZG9lc24ndCBsaWtlIHRoZSByZXZva2luZyBpbiB0aGUgZHJhZnQKICAgICAgICAgICAg ICAgIENhY2hpbmcgaXMgc2VwYXJhdGUKICAgICAgICAgICAgICAgIEZsdXNoaW5nIGEgcmV2b2tl ZCBrZXkgb3V0IG9mIHRoZSBjYWNoZSBjb3VsZCBtYWtlIGl0IGZvcmdvdHRlbgogICAgICAgIFJ1 c3MgTXVuZHk6IElmIHRoZXJlIGlzIGEgc3VkZGVuIHJldm9jYXRpb24sIGV2ZXJ5dGhpbmcgYXNz b2NpYXRlZCB3aXRoIGl0IHNob3VsZCBiZSBmbHVzaGVkCiAgICAgICAgV2VzOiBDYW4ndCBpbWFn aW5lIGltcGxlbWVudGVycyB3YW50aW5nIHRvIGtlZXAgdGhlIGxpc3Qgb2YgdGhlIGtleXMgc28g dGhleSBjYW4gYmUgZmx1c2hlZCBpbmRpdmlkdWFsbHkKICAgICAgICAgICAgICAgIERvZXNuJ3Qg c2VlIGEgdmlhYmxlIG1lY2hhbmlzbSBmb3IgdGhpcwogICAgICAgIER1YW5lIFdlc3NlbHM6IEJl IGNhcmVmdWwgd2l0aCBLU0sgLyBaU0sKICAgICAgICAgICAgICAgIFdvcmsgd2l0aCBwZW9wbGUg d2hvIGp1c3QgdXNlIG9uZSBrZXkgZm9yIHNpZ25pbmcgdGhlIHpvbmUKICAgICAgICBKaW06IFdo YXQgaWYgdGhlIHJldm9rZWQga2V5IGlzIGZvciB0aGUgcm9vdCB6b25lPwogICAgICAgIFN1emFu bmU6IElzIGl0IHJlYWR5IHRvIGNvbnNpZGVyIGFkb3B0aW9uPyBOb3QgY2xlYXIgb3V0Y29tZSBv ZiB0aGUgaHVtLgoKZHJhZnQtaHVzdG9uLWtza3JvbGwtc2VudGluZWwgLSBHZW9mZiBIdXN0b24K ICAgICAgICBCZW5ubzogR29vZCBqb2IKICAgICAgICAgICAgICAgIENhbiBpbXBsZW1lbnQgaW4g YSBtb250aAogICAgICAgIEdlb2ZmOiBMZWFkaW5nIHVuZGVyc2NvcmUgbWFrZXMgaXQgYSBub24t aG9zdCBuYW1lCiAgICAgICAgUmF5OiBRdWVzdGlvbiBhYm91dCBob3cgdG8gdGVsbCBkaWZmZXJl bmNlIGJldHdlZW4gZmFpbHVyZSB0byByZXNvbHZlCiAgICAgICAgT25kcmVqOiBXaGF0IHNob3Vs ZCBoYXBwZW4gaWYgdGhlIGtleXRhZyBpcyBub3QgYSBrZXl0YWc/CiAgICAgICAgICAgICAgICBH ZW9mZjogU2VuZCBiYWNrIHdoYXRldmVyIHlvdSB3b3VsZCBoYXZlCiAgICAgICAgV2FycmVuOiBI b3cgaGFyZCBpcyB0aGlzIHRvIGltcGxlbWVudD8KICAgICAgICBEYXZpZCBDb25yYWQ6IEdldHRp bmcgcmVzb2x1dGlvbiBzb29uZXIgcmF0aGVyIHRoYW4gbGF0ZXIgd291bGQgYmUgaGVscGZ1bCBv biB0aGUgcmV2aWV3CgpkcmFmdC1kdXBvbnQtZG5zb3AtcmZjMjg0NWJpcyAtIEZyYW5jaXMgRHVw b250CiAgICAgICAgTm90IG1hbnkgcGVvcGxlIGhhdmUgcmVhZCBpdCB5ZXQuCiAgICAgICAgTXVr dW5kOiBXYW50cyB0byBzZWUgdGhpcwogICAgICAgICAgICAgICAgMjg0NSBpcyB1bmNsZWFyIGlu IGEgcGxhY2VzCiAgICAgICAgICAgICAgICBTaG91bGQgcmVtb3ZlIGRlZmljaWVuY2VzIGZyb20g dGhlIDI4NDUgdGV4dAogICAgICAgIFRpbTogT25jZSB3ZSBvcGVuIHRoZSBkb2N1bWVudCwgd2Ug c2hvdWxkIGRvIGl0IGZ1bGx5CgpkcmFmdC13a3VtYXJpLWRuc29wLWludGVybmFsIC0gV2FycmVu IEt1bWFyaQogICAgICAgIEppbTogUHJvYmFibHkgYSBnb29kIGlkZWEKICAgICAgICAgICAgICAg IE5vdCBzdXJlIGl0IGlzIGdvb2QgaWRlYSB0byBnZXQgYSBkZWxlZ2F0aW9uCiAgICAgICAgICAg ICAgICBXaWxsIGdldCBpbnRvIElDQU5OIHBvbGljeQogICAgICAgICAgICAgICAgV2FycmVuOiBP dGhlcndpc2UgRE5TU0VDIGJyZWFrCiAgICAgICAgICAgICAgICAgICAgICAgIE1heWJlIGFzayBm b3IgdGhlIGRlbGVnYXRpb24gaW4gcGFyYWxsZWwKICAgICAgICBBbGFpbiBEdXJhbmQ6IE1lcmdl cnMgaXMgbm90IHRoZSBvbmx5IHByb2JsZW0KICAgICAgICAgICAgICAgIFJlZmVycmFscyBpcyBh bm90aGVyIHByb2JsZW0KICAgICAgICBKb2U6IERvZXNuJ3QgdGhpbmsgaXQgbmVlZHMgYSBkZWxl Z2F0aW9uCiAgICAgICAgICAgICAgICBEb2Vzbid0IHRoaW5rIHRoZXJlIGlzIGFueSB3b3JrIGZv ciB0aGUgSUVURiBoZXJlCiAgICAgICAgQW5kcmV3OiBBZ3JlZXMgd2l0aCBKb2UKICAgICAgICAg ICAgICAgIFJlcXVpcmVzIHByb2Nlc3MgaW4gYSBkaWZmZXJlbnQgb3JnYW5pemF0aW9uOiBJQ0FO TgogICAgICAgICAgICAgICAgR2V0IGl0IG91dCBvZiBoZXJlCiAgICAgICAgT2xhZiBLb2xrbWFu bjogSW50ZXJuYXRpb25hbGl6YXRpb24gaXNzdWVzCiAgICAgICAgRGF2aWQgQ29ucmFkOiBXaHkg c2hvdWxkIHRoaXMgYmUgdGhyb3duIG92ZXIgdG8gSUNBTk4/CiAgICAgICAgICAgICAgICBOb21p bmVlIGZvciBzcGVjYWwgdXNlIHJlZ2lzdHJ5CiAgICAgICAgQmVybmllIFZvbHR6OiBSZWR1Y2Ug Y29sbGlzaW9ucyBieSB1c2luZyB5b3VyIG5hbWUKICAgICAgICBBbmRyZXc6IFRoaXMgaXMgbm90 IGEgc3BlY2lhbC11c2UgbmFtZQogICAgICAgICAgICAgICAgSXQgaXMganVzdCBmb3Igc3BsaXQg aG9yaXpvbgogICAgICAgIFdhcnJlbjogTWF5YmUgdGhlIElFVEYgaXMgbm90IHRoZSByaWdodCBw bGFjZSBmb3IgdGhpcyBkaXNjdXNzaW9uCiAgICAgICAgRWRtb25kOiBUaGlzIHdvcmsgc2hvdWxk IGJlIGF0IElDQU5OCiAgICAgICAgICAgICAgICBCb2FyZCBqdXN0IHN0YXJ0ZWQgd29yayB0aHJv dWdoIFNTQUMKICAgICAgICBTdHVhcnQgQ2hlc2hpcmU6IERvbid0IHB1dCBvdXIgaGVhZCBpbiB0 aGUgc2FuZAogICAgICAgICAgICAgICAgTWF5YmUgdXNlZCBmb3IgYm9vdHN0cmFwcGluZyBzeXN0 ZW1zIG91dCBvZiB0aGUgYm94CiAgICAgICAgICAgICAgICBPdGhlciB2YWx1YWJsZSB1c2UgY2Fz ZXMKICAgICAgICBEYXZpZCBDb25yYWQ6IEhvdyBpcyB0aGlzIGRpZmZlcmVudCB0aGFuIC5sb2Nh bCBpbiB0aGUgc3BlY2lhbCB1c2UgZGlyZWN0b3J5CiAgICAgICAgICAgICAgICBTU0FDIHdvcmsg aXMgb3J0aG9nb25hbCB0byB0aGlzCiAgICAgICAgICAgICAgICBJZiBkb25lIGluIElDQU5OLCB0 aGF0IHN1Z2dlc3RzIHRoYXQgaXQgaXMgRE5TLXJlbGF0ZWQKICAgICAgICAgICAgICAgIElmIGRv bmUgaW4gc3BlY2lhbCB1c2UgcmVnaXN0cnksIGl0IGNvdWxkIGJlIGRvbmUgcXVpY2tseQogICAg ICAgIEpvaG4gTGV2aW5lOiBEaWZmZXJlbnRpYXRlcyB3aG9zZSBpc3N1ZXMgaXQgaXMKCkNsb3Np bmcgY29tbW1lbnRzIC0gVGltCiAgICAgICAgZHJhZnQtaWV0Zi1kbnNvcC10ZXJtaW5vbG9neS1i aXM6IFNob290IGZvciBKYW4gMTUgZm9yIFdHIGxhc3QgY2FsbCB3aXRoIHJldmlld3Mgbm93CiAg ICAgICAgZHJhZnQtaWV0Zi1kbnNvcC1yZmM1MDExLXNlY3VyaXR5LWNvbnNpZGVyYXRpb25zOiBO ZXcgdmVyc2lvbiBjb21pbmcgb3V0LCBkbyBhIHNob3J0IFdHIExhc3QgQ2FsbAogICAgICAgIGRy YWZ0LWJlbGxpcy1kbnNvcC14cGY6IEpvZSBhbmQgU2FyYSB3aWxsIGEgcmV2aWV3LCB0aGVuIGNh bGwgZm9yIGFkb3B0aW9uCiAgICAgICAgQWRkaXRpb25hbCBhbnN3ZXJzOiBPcGVucyB1cCB0aGUg d2hvbGUgZGlzY3Vzc2lvbiBvZiBmcmFtaW5nIGl0CiAgICAgICAgZHJhZnQtaHVzdG9uLWtza3Jv bGwtc2VudGluZWw6IElmIHdlIGNhbiBzZWUgc29tZSByZXZpZXdzIHRoaXMgd2VlaywgYSBjYWxs IGZvciBhZG9wdGlvbiBjb3VsZCBiZSBpbiB0aGUgbmV4dCBjb3VwbGUgb2Ygd2Vla3MKICAgICAg ICBXZXMgSGFyZGFrZXIgaGFzIGEgZGVtbyBvZiBSRkMgNzcwNiBhdXRvbWF0ZWQgdXBkYXRlcwog ICAgICAgIGRyYWZ0LXRhcmlxLWRuc29wLWl2aXB0cjogUmFuIG91dCBvZiB0aW1lLCBidXQgcGxl YXNlIHJldmlldwogICAgICAgIFN0YXRlZnVsIE9wZXJhdGlvbnM6IHdhbnRzIGEgV0cgTGFzdCBD YWxsIGluIGEgZmV3IHdlZWtz --089e082fadd08ba07a055e10983c-- From nobody Wed Nov 15 18:50:36 2017 Return-Path: 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 5E41412943F for ; Wed, 15 Nov 2017 18:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 OV5M1NneQAwg for ; Wed, 15 Nov 2017 18:50:30 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 F32B5126CC4 for ; Wed, 15 Nov 2017 18:50:29 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ycm2C46sfz27F; Thu, 16 Nov 2017 03:50:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510800627; bh=qhtTemGjhOnDNz3hoEgrSTJRayaF4207XYE+r8ldLSw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=omioqOJ2q77vClWewwDDxWTKW/EOYcFumiGKVFB0R8xDEKElCAjrx4kQ2Uz0Pms4u Vg1nBlHbLaRF+pQgrOrLgrDG5iab6Vto2qYj69XxDFc+KCtOeHlVn3A54tnLXd76Vk gvC7rYbASgJCzv1VYkwV+bqz8STn2Yi8VQFOwq3Y= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id BelY11-5Ae2f; Thu, 16 Nov 2017 03:50:25 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 16 Nov 2017 03:50:24 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E428062D29; Wed, 15 Nov 2017 21:50:23 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E428062D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CD9D040D35AF; Wed, 15 Nov 2017 21:50:23 -0500 (EST) Date: Wed, 15 Nov 2017 21:50:23 -0500 (EST) From: Paul Wouters To: tjw ietf cc: dnsop In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [DNSOP] Draft Minutes from IETF100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 02:50:32 -0000 On Thu, 16 Nov 2017, tjw ietf wrote: > Thanks again to Paul Hoffman for taking the minutes.  please take a look to see if there are any updates that need to be made and let the chairs know.  > > https://datatracker.ietf.org/meeting/100/materials/minutes-100-dnsop/ Thanks PaulH! I couldn't make it and reading these was very helpful. Paul From nobody Thu Nov 16 00:23:39 2017 Return-Path: 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 5402612954C for ; Thu, 16 Nov 2017 00:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jybffglaBXeH for ; Thu, 16 Nov 2017 00:23:36 -0800 (PST) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A4912956D for ; Thu, 16 Nov 2017 00:23:34 -0800 (PST) Received: by mail-wr0-x229.google.com with SMTP id 4so22683032wrt.0 for ; Thu, 16 Nov 2017 00:23:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MXtJ4QVvSuoHkRZGgdoFKHq6uwWs40zLOHgTM0zgr2o=; b=t2r/BrRpX2eWdjdMv3IpWYARduhC8RDu5N8zZ8bkpLYkJtFrrnNdbcEiHEi8zaA1wd vl3oDOVdAEedR2Da2iX4/kmQHJiuU0DQnSk9kMw4jBVcFxdxOzVPbbrgvvhlRGJdpV4j ZoQ8t65Q+fXmOPR3zRra40uU3P/PwmhBnWfoWzBaVzBo8773T2CwoIIhSZBDfQCMzhKm wFehkLW6VEkJezszeelMJ5sWPNmsdaMUM8f54Hgq3XA5aZ8CS+fCweDymq3dLS9Aijg+ ydRPbf+CxP5NrXPUwAAYKnJX7+4Q1hwQrWafIdyyYpMflEe/GadUjRQa8ywYv3VPNpTD xJ1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MXtJ4QVvSuoHkRZGgdoFKHq6uwWs40zLOHgTM0zgr2o=; b=MfILi2T4JGw5eLPF5yIvtWBzRlZ2X8ZgSDKonY202tKSOfpLNMWbRiHKmv3+KqIUX9 VrL0gKlTCpP7bxyUMiCzf5DWmoTGvDrOpZuJU+ypCmD1RbGtjwSDyLuaLlBO639bWdFN 4juTfdAalWkZ+8cE3ZxGdV0asJrP8awGBkkEBQ9SzfIagpLMWrY4kfTq88iy5bP+mEwT 7fmd28AHi2XDT1OIZ4aWPEfEtiq0Hn2JeDZh3+IE9xOIZdWYE4aZi+Rx57Evt2xlU26S qV5LGOaPnsUCd8oOZm/OtMsx5ZE03iuzAlbOtxQMY1NNrrBIX2y1vXUChv3z/1eLzcKC m9RQ== X-Gm-Message-State: AJaThX5SaOb5Ks7KJxu/EqOaWU7pYBWGcBtNjtO56IrQ4+bpLbBvqHKJ PDhKDzfCnIiSs47MYPF88CAbL6bsEA/F2gYNxDZMuA== X-Google-Smtp-Source: AGs4zMZN6lRsFNYNgIbPwInqJFGqgE9u9soz3pThP86a4myvqJ5o4uEOf2AikuzZiLYAZwNu7fToOjxdWdu4sowPBJs= X-Received: by 10.223.164.22 with SMTP id d22mr801539wra.232.1510820612530; Thu, 16 Nov 2017 00:23:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.146.229 with HTTP; Thu, 16 Nov 2017 00:23:32 -0800 (PST) From: tjw ietf Date: Thu, 16 Nov 2017 16:23:32 +0800 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="f403045f1fa0ede704055e155546" Archived-At: Subject: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 08:23:38 -0000 --f403045f1fa0ede704055e155546 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All The author has rolled out a new version addressing comments from the meeting on Monday, and we feel it=E2=80=99s ready to move this along. This starts a Call for Adoption for draft-huston-kskroll-sentinel The draft is available here: https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 30 November 2017 23:59 Thanks, tim wicinski DNSOP co-chair --f403045f1fa0ede704055e155546 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All
<= div>
The author has rolle= d out a new version addressing comments from the meeting on Monday, and we = feel it=E2=80=99s ready to move this along.

This starts a Call for Adoption for d= raft-huston-kskroll-sentinel

The draft is available here:

Please review this draft to see if you think it is suitable for adoptio= n by DNSOP, and comments to the list, clearly stating your view.

Please also indic= ate if you are willing to contribute text, review, etc.
This call for adoption end= s: 30 November 2017 23:59

Thanks,
tim wicinski
DNSO= P co-chair
--f403045f1fa0ede704055e155546-- From nobody Thu Nov 16 00:34:10 2017 Return-Path: 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 90202129566 for ; Thu, 16 Nov 2017 00:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com 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 XIlov21H4We6 for ; Thu, 16 Nov 2017 00:34:07 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F194C126BFD for ; Thu, 16 Nov 2017 00:34:06 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id j67so10560429vkd.8 for ; Thu, 16 Nov 2017 00:34:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bygrtzMw6hXLXQ3wPaSxRp+Dg1EkiFYzsfl84Ww5bvc=; b=UC8FOVMg2fvZJNgh0lEG13yOk7WsJ1wxbHH9StgShvGEouq+TPTnGyku4dpFAslyh7 LXQOPwvUDT50F+g+x1IJ9/C9ACMxaSbIOeRiyqqk/q1H3oxAhk8T/i8CVnVFBn6SC2eq WsEayToJJwtGkt9rMxJbPQOEwQHwi/KLmiJG0uE984lkcmgxZrIdAzKI82LVFDgR/6fq UMB34g77TaPkEGEJ6bZkSHqVFTho/2OsWiXowD24yWhRlsN/p7m7jGrXvEqCvALWx6xo IKmuSzV+TWwBqcvU+75Wg9oz3igxOxfsAN0+pgPqqLHAXTCV97bte2iqIZo97o5lF589 HaNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bygrtzMw6hXLXQ3wPaSxRp+Dg1EkiFYzsfl84Ww5bvc=; b=sWe8S8AjDtyyqPWsk2yYF/usGtkjdQ92N+cZ2z7mUBNF6LL2wW/KYiJUIwEguMJ/0C IPOJFkQu0u6WCqdLdSisauaCGvvmLL/c3JMJLh9eyMs6QFYltCk43lXdWmW9r0CuQd7x 6jKC3fHtKhIiVCtRbNEq0ZLg0mUcAP4UdtbW9JyKxiuQ4MdDVTkuXdP+3O0AXzOOlbFv jVROzpp/Q2qGkFkcdxTMazkyAR675lYZwUQXy/8hihp+AHvQHBUztoQahmX6Qo8Kx2Hf R/tDoDVue5ebnBbGNfnaHoBCZW3hlYG5wDlnEZuKLQy8T5qukwo/3XqZ5+pmE8NavB7n 4D3A== X-Gm-Message-State: AJaThX7QNepwhnEmZprBOVwa9JhuW8oxTVaraNN438h00QB0CgZ3n2/T i9saHiCigeNetKqtWAfPPKDi0zsn4zz7i1QLf47jTg== X-Google-Smtp-Source: AGs4zMauWF+dxsl8gWRBNPKoB1k6iWsGqXW/2gLmpeNUEV3gQirygnHO8WnXUezHw/Z2aNMzStyVfd4V0x02q3K9uOk= X-Received: by 10.31.151.21 with SMTP id z21mr540963vkd.44.1510821246020; Thu, 16 Nov 2017 00:34:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.91.2 with HTTP; Thu, 16 Nov 2017 00:34:05 -0800 (PST) X-Originating-IP: [2001:67c:1232:144:e8cf:3ef5:8fba:c3a3] In-Reply-To: References: From: George Michaelson Date: Thu, 16 Nov 2017 16:34:05 +0800 Message-ID: To: tjw ietf Cc: dnsop Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 08:34:09 -0000 I support adoption of this work. Its a sensible, simple proposal which has immediate benefit, and can be used by anyone to test the ability of their nominated resolver to recognise specific keys, and their trust state. I believe as a community, at large, we need code deployed into the resolvers in the wild, and we need a document specifying the behaviour we need deployed into those resolvers. We can use this to inform ourselves of operational risk under keychange. We can know as individuals, as organizations what we will see, if keys change. I think this is quite powerful. compared to measurement of what resolvers see, or what authoritatives or roots see, going back to these service-providers themselves. This method informs the client side of the transaction. Thats big. I'm not saying we shouldn't do other things, or measure. I'm saying that this proposal has a qualitative aspect which I think is different, and good. -George On Thu, Nov 16, 2017 at 4:23 PM, tjw ietf wrote: > All > > The author has rolled out a new version addressing comments from the meet= ing > on Monday, and we feel it=E2=80=99s ready to move this along. > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > The draft is available here: > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ > > Please review this draft to see if you think it is suitable for adoption = by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 30 November 2017 23:59 > > Thanks, > tim wicinski > DNSOP co-chair > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From nobody Thu Nov 16 01:18:40 2017 Return-Path: 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 68FA9120724 for ; Thu, 16 Nov 2017 01:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 4G5KEGSkvD7O for ; Thu, 16 Nov 2017 01:18:36 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4EB1200CF for ; Thu, 16 Nov 2017 01:18:36 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id b5so5079204itc.3 for ; Thu, 16 Nov 2017 01:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=S/dFOA4U9omvvwQ2CJs4GNw82PnNGiZMkbyobIejh9o=; b=lFA4PUs5a5/bAeA1sbjOfAG8flgGdTZQLiqhiq9NFKD4A7k0DirhaXayAMcTGjmQxb GfYnbLrWDP0k7WS3ZHUXxAq3BkpU8TANKeZJ3NR6ta70d8H9QAzLyun91ZC2q2Af6Qm3 5CM5ECE5qCCuEY/Ay/moHWIN1N77Ppf6iH38w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=S/dFOA4U9omvvwQ2CJs4GNw82PnNGiZMkbyobIejh9o=; b=DM/ts/S/yM2RtMEzjXedqV1TzkS6YEDvo67op/jCJ3xdXW2uQLbXLzl8Bam3qYTPAh X3rxLaygvY/VxU6X9dIHKsdkdKmBAEi6O1PsJaz6PXKWRz9YYxccz98ckpjzczuzmWY+ YPn7vIStF7nDpYxUYsQfnDVugWL/mz22aXP7wGwjkSsEIGOHFMBVwVcTw1qkU9SHr0ps WYZcCmRlhUqSbT+SOUTTQcnjO4zLcpmS6/oMynMXwUCywBpPJZDfSdm+63ylSYZMDikJ vpJW1LYLFxFD7CxARF/GnOSUIuh8NP2MEUFTNFbPzDFRvl1gygYqCPInvTSpL80GxU23 6Qjg== X-Gm-Message-State: AJaThX7GbCxRXfKMguiJ45wPpP0epUCR6NDqkgDIoCDNGRT/3aY8VwTR lO0bnWbcbqgrryGxTv5BNc1z7UPDe4o= X-Google-Smtp-Source: AGs4zMZB0s6A6rNHPYL21W0+CTV1IIPvEftVfOO9uqqDM32pnEq1OMz+bMNLnqkUORVi0X+WLpmpIA== X-Received: by 10.36.14.207 with SMTP id 198mr1686707ite.66.1510823915552; Thu, 16 Nov 2017 01:18:35 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:fc8f:bb9b:666a:eca1? ([2001:67c:1232:144:fc8f:bb9b:666a:eca1]) by smtp.gmail.com with ESMTPSA id i76sm585735itf.3.2017.11.16.01.18.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 01:18:34 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-E778082F-7A42-4D13-82C4-D3304B9B82F6 Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (15B150) In-Reply-To: Date: Thu, 16 Nov 2017 17:18:32 +0800 Cc: dnsop Content-Transfer-Encoding: 7bit Message-Id: References: To: tjw ietf Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 09:18:38 -0000 --Apple-Mail-E778082F-7A42-4D13-82C4-D3304B9B82F6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I support adoption and am willing to contribute and review. > On Nov 16, 2017, at 16:23, tjw ietf wrote: >=20 > All >=20 > The author has rolled out a new version addressing comments from the meeti= ng on Monday, and we feel it=E2=80=99s ready to move this along. >=20 > This starts a Call for Adoption for draft-huston-kskroll-sentinel >=20 > The draft is available here: > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ >=20 > Please review this draft to see if you think it is suitable for adoption b= y DNSOP, and comments to the list, clearly stating your view. >=20 > Please also indicate if you are willing to contribute text, review, etc. >=20 > This call for adoption ends: 30 November 2017 23:59 >=20 > Thanks, > tim wicinski > DNSOP co-chair > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail-E778082F-7A42-4D13-82C4-D3304B9B82F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I support adoption and am w= illing to contribute and review.

On Nov 16, 2017, at 16:23, tj= w ietf <tjw.ietf@gmail.com> w= rote:

All

The author has rolled out a new version addressi= ng comments from the meeting on Monday, and we feel it=E2=80=99s ready to mo= ve this along.

This starts a Call for Adoption for draft-huston-kskroll-sentinel

The draft i= s available here:

Please review this draft to see if= you think it is suitable for adoption by DNSOP, and comments to the list, c= learly stating your view.

Please also indicate if you are willing to contribute text= , review, etc.

This call for adoption ends: 30 November 2017 23:59
=
Thanks,
= tim wicinski
DNSOP co-chair
____________________= ___________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mai= lman/listinfo/dnsop
= --Apple-Mail-E778082F-7A42-4D13-82C4-D3304B9B82F6-- From nobody Thu Nov 16 03:05:53 2017 Return-Path: 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 E5A59129459 for ; Thu, 16 Nov 2017 03:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 1HwoQ9_QOaLh for ; Thu, 16 Nov 2017 03:05:49 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 86175129420 for ; Thu, 16 Nov 2017 03:05:49 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ycz1l62dKz34k; Thu, 16 Nov 2017 12:05:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1510830347; bh=saiSqUQ2qUXedNqe5l68fm90j9jOOU/7PjtKMFJj6vU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Z7gOkwL7x/vDC4++FHFtLSKSJ9py+K2e+LJTjS6EQnJCyYcJG53vxFXTu67Ja4zEa r0BI2S6fa6J6t2u6q6Yz0l5E2YlsLkijlTA5qO1tW1o3IrB1GLQZ2QPwTTK+MbdJfp 0AmnxH28LLMTKc0kPquGKkddQ8QXhrp6dUHBIJnE= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wjzVanwBj32x; Thu, 16 Nov 2017 12:05:42 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 16 Nov 2017 12:05:41 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 135C662D29; Thu, 16 Nov 2017 06:05:40 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 135C662D29 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F10F240D35AF; Thu, 16 Nov 2017 06:05:40 -0500 (EST) Date: Thu, 16 Nov 2017 06:05:40 -0500 (EST) From: Paul Wouters To: tjw ietf cc: dnsop In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 11:05:52 -0000 On Thu, 16 Nov 2017, tjw ietf wrote: > The author has rolled out a new version addressing comments from the meeting on Monday, and we feel it’s ready to move this along. > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > The draft is available here: > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ > > Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. In favour of adopting, but still confused about parts of the draft. But I agree with the idea. > Please also indicate if you are willing to contribute text, review, etc. willing to review. Paul From nobody Thu Nov 16 04:23:33 2017 Return-Path: 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 9E7FA1294B5 for ; Thu, 16 Nov 2017 04:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 VySF8ISidKWg for ; Thu, 16 Nov 2017 04:23:29 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 C8A8B12947E for ; Thu, 16 Nov 2017 04:23:28 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:50c4:3bff:fe64:f3c0] (unknown [IPv6:2001:1488:fffe:6:50c4:3bff:fe64:f3c0]) by mail.nic.cz (Postfix) with ESMTPSA id 1CEAD6455A for ; Thu, 16 Nov 2017 13:23:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1510835007; bh=WQ0VZzjhJ8/VHD70qWHKUNhtB7CDehIXVZsq0nHg7Pc=; h=To:From:Date; b=UR+lX1hY7RpRjNeMyyhTSY07ddSXn0tZWz1fn80bxUh3WFlmEuyEsRFqfAcjhcJLQ 7JyRQQJdQtl6IYpeyDYs9j0tCxnaMzaTtHA0+QKTRj8aZxZUdfIcFLfAng0cSwdqzP mDUWLbqMRHiGSErvFkihh6mdbPz6z42SEFHTP5To= To: dnsop@ietf.org References: From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Thu, 16 Nov 2017 13:23:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 12:23:32 -0000 I support adoption, will review. Petr Špaček @ CZ.NIC On 16.11.2017 09:23, tjw ietf wrote: > All > > The author has rolled out a new version addressing comments from the > meeting on Monday, and we feel it’s ready to move this along. > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > The draft is available here: > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 30 November 2017 23:59 > > Thanks, > tim wicinski > DNSOP co-chair From nobody Thu Nov 16 05:33:35 2017 Return-Path: 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 7E2D7129439 for ; Thu, 16 Nov 2017 05:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8] 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 qdT5plrFgOfh for ; Thu, 16 Nov 2017 05:33:31 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 8B6E0124B18 for ; Thu, 16 Nov 2017 05:33:31 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vAGDXUv7022226 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 16 Nov 2017 13:33:30 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vAGDXT11022794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 16 Nov 2017 13:33:29 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vAGDXTRK014690 for ; Thu, 16 Nov 2017 13:33:29 GMT Received: from [172.19.131.190] (/216.146.45.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Nov 2017 05:33:29 -0800 To: dnsop@ietf.org References: From: Matthijs Mekking Message-ID: Date: Thu, 16 Nov 2017 14:33:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [DNSOP] 5011-security-considerations and the safetyMargin X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 13:33:33 -0000 Wes, My preference is to include safetyMargin and have text to explain it exists because of network delays etcetera, and also reference to RFC 5011's retryTime. So that's some mix of 1B 1C or 2B I guess :) Best regards, Matthijs On 15-11-17 02:49, Wes Hardaker wrote: > > The discussion has been long with respect to the safetyMargin in the > 5011 security considerations document. There hasn't been a huge > conclusion and many different ideas have been floated by, and we're now > at the point where we need to pick between them. Below, I try to lay > out the primary and sub-options available based on discussions so far. > Please provide your opinions on your preference so I can wrap up this > draft. > > Background: This document is not intended to provide operational > guidance on what you SHOULD do. It's intended to draw the timing line > below which you MUST NOT venture. The safetyMargin was introduced to > prevent race conditions based on network delays, eg, which can mean that > a RFC5011 Resolver operating at the same time as a PEP Publisher making > a change at exactly at the minimum addWaitTime or addWallClockTime > values would lead to a failure. So the primary question today is "how > do we want to deal with this issue of real-world speed-of-light and > other issues?". To complicate this a bit further, packets are never > guaranteed to be delivered and network losses can entirely prevent a > 5011 Resolver from succeeding at all for a given operation. > > Option 1. Include a safetyMargin of some value. > > 1A) safetyMargin = MAX(2*TTL, 1.5Hr) -- current draft > > 1B) safetyMargin = something based on the retryTime, > (an example solution was suggested by MSJ) > > 1C) Your value here > > Option 2. Don't include a safetyMargin > > 2A) Just ignore the issues entirely > > 2B) Explain that this document does not cover operational > complexities like retries (already in the -07 version), > network delays and other operational issues. > > > After thinking about this for far far too long, I've now switched my own > opinion to that of 2C for the principal reason that this is the > line-in-the-sand document, and to be honest people should be using > values much larger than this, per MSJ's guidance on how 5011 should be > used. Thus, it makes more sense to define this as the "MUST NOT go > below this line" without trying to be precise about a value that can never be > perfectly accurate, by definition. > > But, forget my opinion. What's yours? If nothing else, pick one of the > [12][ABC] options above please, even without any text defining why you > think so (until someone pokes you). > From nobody Thu Nov 16 05:57:10 2017 Return-Path: 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 A77AB1294FF for ; Thu, 16 Nov 2017 05:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andreasschulze.de 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 qLl8bSyx_GKK for ; Thu, 16 Nov 2017 05:57:01 -0800 (PST) Received: from mail.somaf.de (mail.somaf.de [IPv6:2001:470:77b3:100::7]) (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 9EF9512944E for ; Thu, 16 Nov 2017 05:57:01 -0800 (PST) Date: Thu, 16 Nov 2017 14:56:56 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=ybz; t=1510840617; x=1515840617; bh=ufI1USucySOIQ5U7Tt54wdqKMQTuQCb95w66ziErIRE=; h=Date:Message-ID:From:To:Subject:In-Reply-To:Content-Type:from: reply-to:subject:date:to:cc:content-type:message-id; b=rq0M2cCDQDI3Vx7yXf6gYnqBwRfmjlSwt1fnD6PBvlkg1Zkz6qcdBcWtoBJNUj7sy tqWb4avGqlWdgf6VbHs5yrb0bI3yl7sowt5Yk8eO3aHOfmDZqd7efqQzyELS/WRSfR ikQ1OvzUuiyV/OnAFY9gS+l0rSxYORsEnRGA0GDd6aBTW0+HqXBUC3eDc8P26NNX+N H9htVU4+WDEbY6xfPjTtsPsjPbAdSpLrhhJmz0lIDNcmDlASz0A3CCUqqiK15As8Go oxCT8wvWkbBTwSYdRYekPH016grj3YYUKZc9bLGhDLLl7J5FL/lcQvZ0e3LDAmaMyg y2oATkNzAObcg== Message-ID: <20171116145656.Horde.W1pnQn15q87cLvsAa7Coxyx@andreasschulze.de> From: "A. Schulze" To: dnsop@ietf.org In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 13:57:10 -0000 tjw ietf: > The draft is available here: > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ the draft uses Vnew Vold Vleg and nonV without description. that makes it hard for me as I still do not fully understand the idea ... Andreas From nobody Thu Nov 16 06:39:11 2017 Return-Path: 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 CEEE3127137 for ; Thu, 16 Nov 2017 06:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kfYQUlEQuH1d for ; Thu, 16 Nov 2017 06:39:08 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411E6120454 for ; Thu, 16 Nov 2017 06:39:08 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id m1so14462829lfj.9 for ; Thu, 16 Nov 2017 06:39:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dPvnOl1+LeHs5+1hVTcpqr/xvrHziL9McwB5eXsRD9k=; b=th4B900G1gxesIuzF88oCCsmpWUhOuwW76OEsTdOaYBrRpmEjNJgSbFIVCA1PpayAq du3RtwDUPRAtjS/l3YDDpyoVHJ10XC6P6bZQJ/5ffiMRX95BKrT9l6JLgWviP0mRdZHb z30NlLVuFIkr99E7lRrq22mDRKKJnEjG1gG80prCPmAZWguZ3NFlfhoSSWyTb1/u6pFb HXlCFl7F8311Oyh+e0WFVU8oSn+d2A+P3wohKsekarzkmb8EgBT+0Cl+sxXBlCYDs3pH 8cfHxqhguogtWe6b6KzvVO0HnV9zPtHIkDW0AhToz4SdD6fgOBbV3EmltjQo859GLxms bAzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dPvnOl1+LeHs5+1hVTcpqr/xvrHziL9McwB5eXsRD9k=; b=WgLqeY/K4ogfZgOdknyvlRHMGpg9HrTweOTju3zxIV5wm6rBHNtyFDSp2Pr8mJZa4i EoOa8p41Hez+4M8oXz+U1mxE+QtUAJWba1tZoJZ1h2tBro1IzHe04tg/gLvvCaUvbzmC x9y7bVjeBym49R4HVNpv/qSamzw9P1Wm0wM8tajuFPEWxUOP8EPkr9sxacdXPblt5RZi asX5caFhXLgY+ha1gG2bGljRyyUjjMTVilkmpQp9c8Ww5dBjPzdrlTcy735fX9mUfpUu 6TNZAl1383bLtPG2U5uem5qYmHptL67lwh3cRE8XCxwVYX8ple1cwv0yTLOfn9+K3+jG j4IQ== X-Gm-Message-State: AJaThX7irlz4jNmErQyzOEoLt8EDAfF5cZn8VBt/lBt4RAoZSq9uzxMG EcDg7h4tbHOeNeodq4g3z0Cl8Dbcx9ZITm4o+w+POQ== X-Google-Smtp-Source: AGs4zMaYTVZWzm5ihru7V0YRXdey6/npgaEVDx4dY/0qyARa0nQ5j3UXds7NpBg6nuEVq+6heHooDac66HA1cVD6j/c= X-Received: by 10.46.126.1 with SMTP id z1mr217001ljc.81.1510843146467; Thu, 16 Nov 2017 06:39:06 -0800 (PST) MIME-Version: 1.0 References: <20171116145656.Horde.W1pnQn15q87cLvsAa7Coxyx@andreasschulze.de> In-Reply-To: <20171116145656.Horde.W1pnQn15q87cLvsAa7Coxyx@andreasschulze.de> From: manu tman Date: Thu, 16 Nov 2017 14:38:55 +0000 Message-ID: To: "A. Schulze" Cc: dnsop@ietf.org Content-Type: multipart/alternative; boundary="089e0827ae180e80de055e1a957c" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 14:39:10 -0000 --089e0827ae180e80de055e1a957c Content-Type: text/plain; charset="UTF-8" > the draft uses Vnew Vold Vleg and nonV without description. > that makes it hard for me as I still do not fully understand the idea ... Well it is defined/described in section 3 but I agree that a high level explanation in the terminology section would not hurt. Manu --089e0827ae180e80de055e1a957c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

the draft uses Vnew Vold Vleg and nonV without description.
that makes it hard for me as I still do not fully understand the idea ...
Well it is defined/described in s= ection 3 but I agree that a high level explanation in the terminology secti= on would not hurt.

Manu<= /div>
--089e0827ae180e80de055e1a957c-- From nobody Thu Nov 16 09:58:06 2017 Return-Path: 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 7F682129329 for ; Thu, 16 Nov 2017 09:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com 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 1lfU8rIzC_2Z for ; Thu, 16 Nov 2017 09:58:02 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681B61205F1 for ; Thu, 16 Nov 2017 09:58:02 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id x28so1013718ita.0 for ; Thu, 16 Nov 2017 09:58:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=dO/j/fw42ejG1F5MtCruLDagxUyWt+FI1wGc6wdXhB8=; b=NN1q7XK5lAiKD8P2Mr+kyUU4K4O0pJ4V+8hoNHC65eDtLkqkPqHgEILm6T3/GxraiL l+KCu0rkK5L6NCZOqniFqFMWrhLxBhLHHOj5XOx3zpwCxAWOj5mjpFBTZGvdRD6SDgls eDdMOor73riXd0ZiD8hyahyoEagZ2k4b2z6TX55WlBhL1zasVUg4AFPUaH+EtV0UCTY+ dqPOA/K7uJh6tKsiDej5JKjhKYW6H5ymcN8nEVNFEE6MkOFJi/l5XyecPNuYeLhhZJEa /6z8+tzw38FXqQbF6aIgVFYoeDuttpmo/LOhfWK/E3vEs0Z1c62TSUxwDo0AJJ9rXM/D yESw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=dO/j/fw42ejG1F5MtCruLDagxUyWt+FI1wGc6wdXhB8=; b=fFLau+Ksr/IsqhQbQeHbGc0Nl2KvC4Nz2SCRllht9ZxaEshmtPxv39NCO3G40JGZlY 3kBy7oYO6zwuiNeWbkjE55hTH5B8pgFapBu/tNPV2j36gp9C0i+k5mza75FNVn/+F46K GBbY4kJSqb9TsJ2efvb7bkBNnS0T/mhwFzw1nMwITNwNqBaSz70JyVnxAostBZBcum+5 I1VNaWvodLvbb3KgnZgtydAx+YMfCwGLIkpS1zThux/IigdRD8KD6LGNmIN4L2yQqxFe 3OAdlsXJYW4xJ4f0KP8w+VR4y3bqUahxUSPDFpPynTn4aESJpv7f5eSUwKAbY5XsBZW4 38DA== X-Gm-Message-State: AJaThX5zlgYykaGKgySq6V+xEZonLLjHbTnDkeppa/7mZv5YvNdj1CU0 AZj6Hr31ovV+gIqZGVGdfSKhFj8CQuh2jbjE6StxkJjq/jI= X-Google-Smtp-Source: AGs4zMZ0Rg7GKIz8KFmQb8jcj/0OvB+47k/kGYLaEai6OL/LdH41Hrf0nVirlPJwjSW7Mzs6X95prUQrtEeiegHjVpE= X-Received: by 10.36.98.20 with SMTP id d20mr3228939itc.110.1510855081296; Thu, 16 Nov 2017 09:58:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.155.47 with HTTP; Thu, 16 Nov 2017 09:58:00 -0800 (PST) In-Reply-To: References: From: Matthew Pounsett Date: Thu, 16 Nov 2017 09:58:00 -0800 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="001a113f80926dbe05055e1d5cfe" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 17:58:04 -0000 --001a113f80926dbe05055e1d5cfe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 16 November 2017 at 00:23, tjw ietf wrote: > All > > The author has rolled out a new version addressing comments from the > meeting on Monday, and we feel it=E2=80=99s ready to move this along. > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > I support adoption, and I'm willing to review. This seems like an incredible valuable mechanism. In fact, I already have some comments/questions: In the last paragraph of section 2, "This mechanism is to be applied only by resolvers that perform DNSSEC validation ..." I seem to recall there was some ambiguity in the signal from RFC 8145 validators caused by some implementations that might send a signal even if they weren't actively validating. I think it would be worthwhile to make this statement stronger and more explicit that an implementation should only enable this mechanism if it is actually configured to validate, and not simply capable of validation. The records being queried seem to be anchored at the root. Given that a server in state Vleg is expected to return A responses that implies that the root zone needs to include these records, but I don't see that stated anywhere.. perhaps I just missed it? At the bottom of section 3, the document gives two definitions for a Vleg response. One seems to be a typo and should be Vold. "A Vleg response pattern says that the nominated key is not yet trusted by the resolver in its own right." --001a113f80926dbe05055e1d5cfe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 16 November 2017 at 00:23, tjw ietf <tjw.ietf@gmail.com> wrote:
All

=
The author has rolled out a = new version addressing comments from the meeting on Monday, and we feel it= =E2=80=99s ready to move this along.

This starts a Call for Adoption for draft-hu= ston-kskroll-sentinel
=

I support adoption,= and I'm willing to review.=C2=A0 This seems like an incredible valuabl= e mechanism.

In fact, I already have some comments= /questions:

In the last paragraph of section 2,=C2= =A0
"This mechanism is to be applied only by resolvers that = perform DNSSEC validation ..."
I seem to recall there was so= me ambiguity in the signal from RFC 8145 validators caused by some implemen= tations that might send a signal even if they weren't actively validati= ng.=C2=A0 I think it would be worthwhile to make this statement stronger an= d more explicit that an implementation should only enable this mechanism if= it is actually configured to validate, and not simply capable of validatio= n.

The records being queried seem to be anchored a= t the root. Given that a server in state Vleg is expected to return A respo= nses that implies that the root zone needs to include these records, but I = don't see that stated anywhere.. perhaps I just missed it?=C2=A0 =C2=A0=

At the bottom of section 3, the document give= s two definitions for a Vleg response.=C2=A0 One seems to be a typo and sho= uld be Vold.
"A Vleg response pattern says that the= nominated key is not yet trusted by the resolver in its own right."



--001a113f80926dbe05055e1d5cfe-- From nobody Thu Nov 16 11:11:01 2017 Return-Path: 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 AF14B12717E for ; Thu, 16 Nov 2017 11:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TxBk-ycI7HQ3 for ; Thu, 16 Nov 2017 11:10:57 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E3812009C for ; Thu, 16 Nov 2017 11:10:57 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id o14so48582wrf.9 for ; Thu, 16 Nov 2017 11:10:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=SzNzNMybR6TPVx1igclfmIuTAwfZjiYg+RnIkHsMMHg=; b=HlGU+US+wh29SYSHspQaB7Q7fqeLsgDE+NHW4BmfbmQN8HFasqYTzNyk5/7MHBJybK PwYe53+KfQlFdOlDE0CT4l4TMjZt/FeXJvFp1SxA1e9gu572/mDKQZZqUD76eLLza+sy jOUKS4+fqwVtJPTnPddX3ujpm9pvFobYSWSzwEo7teXd98qU874O3s2AiAQ9pSVR44cu uEk8O9Q/fLRFE4bAU6Ie/pGRXaP0yongS/jvn9+IvJutGrJ8owJoF8z6abMCMpdrMzmg pVPfJC/Eua7yz9R/djTbBobIAWsRwxBMP8MmbTqMwzvSWvwPPCDzwx91l7kn29csO8nD tnyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SzNzNMybR6TPVx1igclfmIuTAwfZjiYg+RnIkHsMMHg=; b=WCCETKChOPCAkMgK1pdMvnb2AqCU+/yHjjF2HKEBHh7LZ7Yxr7cxv5EUAp0lCxouop 2yg/EtnILR6bqzO/jvG7+ROPp4k50GcpgyyVOZH+0s4zFIOQj8dZauBdPpEJ3oraxEvy jvtVUZ0l/gBqjz7gaB9q9LBwBweKagIDUu2mE5vDEkzGFiS+PqQhZbuAQ2la1iL0m/hg DVgWN3/U8ewsX6Q6o9KdPVbP7IQXM5HuYCELV1TNm5LGuzfg4oy8vcMQhheS5KmQQePH +tDtURxeRTxE6ocuFQZ47DDvqDS4yly3jxAYTvsBk3J00jGfDK4ylgNHItFhGF87k/ym /ZsQ== X-Gm-Message-State: AJaThX4JexHCY2sQDZcDn3J/hAFMIUEHOQB5/VLtrqvZbgrLwfpt+7r2 m2WWOvZBsTWJ1IopPKje00jDIPQ/37lLAGM3MZpopXTy X-Google-Smtp-Source: AGs4zMZrzyjQugbMyz1dZ0OPzCzTJReezzd5Ge/CWu6SDjIVlgfqAs1LtxTKrAdqn2y6w7Pk+quUn2QTON6T4xWozrU= X-Received: by 10.223.184.171 with SMTP id i40mr2534464wrf.124.1510859455493; Thu, 16 Nov 2017 11:10:55 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.223.179.196 with HTTP; Thu, 16 Nov 2017 11:10:54 -0800 (PST) In-Reply-To: <8D809B23-8A29-483F-9962-4A2E7C426184@redbarn.org> References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <23051.40720.908131.277454@gro.dd.org> <23051.47926.538193.725450@gro.dd.org> <5A0BBDD7.2070406@redbarn.org> <23051.52473.880861.251236@gro.dd.org> <8D809B23-8A29-483F-9962-4A2E7C426184@redbarn.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 16 Nov 2017 11:10:54 -0800 X-Google-Sender-Auth: ZaAfvuqwNtx8yx15mTUq34UQPkM Message-ID: To: P Vix Cc: Dave Lawrence , IETF DNSOP WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 19:11:00 -0000 At Wed, 15 Nov 2017 05:41:04 +0000, P Vix wrote: > >1) when the request explicitly signals it is ok; > >2) when the request groks EDNS but might or might not understand > > a staleness option; or > >3) in all cases. > > > >My current understanding is that you and Paul are of position 1, while > >I'm at 3. At first glance 2 would appear to be pretty nearly the same > >as 3 as far as its permissive toward unaware clients, but > >significantly it does at least provide signal you could still access > >via protocol debugging (dig, tcpdump, etc). > > I expect you to implement 3. I expect us to document 1. Realistically, I expect virtually everyone will implement 3, given how this kind of feature is sold in the marketing context. Open-source reference implementations may implement 1 if it actually becomes the standard behavior, but I bet any serious large-scale user of those implementations will make a custom change to disable that part. I'd be sad about that, but that's quite likely to be the reality. I don't want the IETF to standardize a bad practice, and in that sense I'd personally prefer option 1 (or something that shares its spirit). But, as an engineering group, if there's basically no chance to deploy it I don't see a point of bothering to standardize it. So, if we choose to document option 1, I'd like to know the plan of this group of its deployability. Is it that we optimistically think that nearly all stub resolvers eventually (in 5-10 years?) support the signaling option and enable it by default, and then server implementations will gradually start honoring the standard (and until then we'll just grumble about the deployment of non-compliant implementations)? -- JINMEI, Tatuya From nobody Thu Nov 16 20:13:08 2017 Return-Path: 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 6F14E126CD8 for ; Thu, 16 Nov 2017 20:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 yMt3cfkRa6yP for ; Thu, 16 Nov 2017 20:13:03 -0800 (PST) Received: from atl4mhob10.registeredsite.com (atl4mhob10.registeredsite.com [209.17.115.48]) (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 C12D6127868 for ; Thu, 16 Nov 2017 20:13:03 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob10.registeredsite.com (8.14.4/8.14.4) with ESMTP id vAH4D0n0030930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Nov 2017 23:13:01 -0500 Received: (qmail 26537 invoked by uid 0); 17 Nov 2017 04:13:00 -0000 X-TCPREMOTEIP: 31.133.153.67 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?31.133.153.67?) (lee@asgard.org@31.133.153.67) by 0 with ESMTPA; 17 Nov 2017 04:13:00 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Fri, 17 Nov 2017 12:12:53 +0800 From: Lee Howard To: Message-ID: Thread-Topic: draft-ietf-dnsop-isp-ip6rdns Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3593765579_14203037" Archived-At: Subject: [DNSOP] draft-ietf-dnsop-isp-ip6rdns X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 04:13:05 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3593765579_14203037 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I updated this draft months ago, based on feedback from the previous WGLC, and it expired without comment. I=E2=80=99ve refreshed it, and would like to ask again for reviews (especially if anything has changed in the past year) and another WGLC. https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/ Thanks, Lee --B_3593765579_14203037 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
I updated this draft months a= go, based on feedback from the previous WGLC, and it expired without comment= . I’ve refreshed it, and would like to ask again for reviews (especial= ly if anything has changed in the past year) and another WGLC.
https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/

Thanks,

Lee
--B_3593765579_14203037-- From nobody Thu Nov 16 21:27:13 2017 Return-Path: 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 0F0E4127B5A for ; Thu, 16 Nov 2017 21:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 K0I_ZAPrfCpH for ; Thu, 16 Nov 2017 21:27:09 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74FF81286B2 for ; Thu, 16 Nov 2017 21:27:09 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id u70so1133446pfa.7 for ; Thu, 16 Nov 2017 21:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xyieop/eVyzMlE+wqWe4R/61MvVPv8APgOa9KADFROE=; b=jRa+MsJaz1bGFvl1Im1QqzFF7UVQc61lvRx1CIJjWVnBBIpDKVdq3Xn/G/NGBvyHSs v1FhtpzFMx4rFrlBtzl1/7s9uLMJZ9OitD1BauQGuke5ZP56TCnWmlfdeE8GTNeWelPu LrPYPMFPTMW2vxWjW1zgPIONBExfwhfVQpVuSlOIn+yJCFOeaR6ejn/m740p7sbHlBFa TMGIjfSj+cqJlZC9wUQfkZVGUGpDyVXmp5qxn1fOwxP0jAxk69GHtT4X7E+qkcTfqx4E st0fcHY017gnYOJeyxtO9zNHZAEJ56qaHI50cfwOSLg98/6fr8IbNrCTWCJE+d5ySh1Z QuJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xyieop/eVyzMlE+wqWe4R/61MvVPv8APgOa9KADFROE=; b=dOWzE/au/dZ/TTNserXgTkE3c4IPm1ffamdiugIa2loi+iJ9wpXUTH1EAt88xPYEIS ZH/5VNW6awDrd+FIGqhQHPlL/U+aW1ovbYQbKMCzm4MKWANQ4eytqTBazZfk3u2jSRFi 5ObOP7HLfwxI8qlycqRk1ZwlbhwgRiQIOcyBjiu7sbt1/UPijTK5AFSnp0sHDAobsc+t cWEetWMA8PNWr4BDrIghKL9MNpfgrRtvbY9LwZ5mQ0s3plvZt0Dn9tblIrm7bX8ARKzg 882uUlVRO851RCjrtSvnLsJL06VraYXCDRyo44qCHoJ4oYVGnL0Wa3Ahzw9Fs6Gi9Zs0 ekHA== X-Gm-Message-State: AJaThX6wX35YhMmHcQlJM7lwbeBs05xmJ1JlFtR+xs1DsSgTYmR+jsuA tn2RUOrF4uJDCh4J4a2Vn6J8+1e3FqPnxhxGX7FAqQ== X-Google-Smtp-Source: AGs4zMYijJimGsW3IryIwi4mNNiqvlDU7bF6PeFTx2Y1DaK/jKg4hJy3xrvlJMwmQGWO7CmKEHF4+cAqygWpFkm/qq4= X-Received: by 10.84.217.20 with SMTP id o20mr4076473pli.62.1510896428881; Thu, 16 Nov 2017 21:27:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.171.6 with HTTP; Thu, 16 Nov 2017 21:27:08 -0800 (PST) In-Reply-To: References: From: Bob Harold Date: Fri, 17 Nov 2017 00:27:08 -0500 Message-ID: To: Matthijs Mekking Cc: IETF DNSOP WG Content-Type: multipart/alternative; boundary="f403045c61acefad63055e26fc5a" Archived-At: Subject: Re: [DNSOP] 5011-security-considerations and the safetyMargin X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 05:27:12 -0000 --f403045c61acefad63055e26fc5a Content-Type: text/plain; charset="UTF-8" On Thu, Nov 16, 2017 at 8:33 AM, Matthijs Mekking wrote: > Wes, > > My preference is to include safetyMargin and have text to explain it > exists because of network delays etcetera, and also reference to RFC 5011's > retryTime. So that's some mix of 1B 1C or 2B I guess :) > > Best regards, > Matthijs > > > On 15-11-17 02:49, Wes Hardaker wrote: > >> >> The discussion has been long with respect to the safetyMargin in the >> 5011 security considerations document. There hasn't been a huge >> conclusion and many different ideas have been floated by, and we're now >> at the point where we need to pick between them. Below, I try to lay >> out the primary and sub-options available based on discussions so far. >> Please provide your opinions on your preference so I can wrap up this >> draft. >> >> Background: This document is not intended to provide operational >> guidance on what you SHOULD do. It's intended to draw the timing line >> below which you MUST NOT venture. The safetyMargin was introduced to >> prevent race conditions based on network delays, eg, which can mean that >> a RFC5011 Resolver operating at the same time as a PEP Publisher making >> a change at exactly at the minimum addWaitTime or addWallClockTime >> values would lead to a failure. So the primary question today is "how >> do we want to deal with this issue of real-world speed-of-light and >> other issues?". To complicate this a bit further, packets are never >> guaranteed to be delivered and network losses can entirely prevent a >> 5011 Resolver from succeeding at all for a given operation. >> >> Option 1. Include a safetyMargin of some value. >> >> 1A) safetyMargin = MAX(2*TTL, 1.5Hr) -- current draft >> >> 1B) safetyMargin = something based on the retryTime, >> (an example solution was suggested by MSJ) >> >> 1C) Your value here >> >> Option 2. Don't include a safetyMargin >> >> 2A) Just ignore the issues entirely >> >> 2B) Explain that this document does not cover operational >> complexities like retries (already in the -07 version), >> network delays and other operational issues. >> >> >> After thinking about this for far far too long, I've now switched my own >> opinion to that of 2C for the principal reason that this is the >> line-in-the-sand document, and to be honest people should be using >> values much larger than this, per MSJ's guidance on how 5011 should be >> used. Thus, it makes more sense to define this as the "MUST NOT go >> below this line" without trying to be precise about a value that can >> never be >> perfectly accurate, by definition. >> >> But, forget my opinion. What's yours? If nothing else, pick one of the >> [12][ABC] options above please, even without any text defining why you >> think so (until someone pokes you). >> >> I prefer 1A since the reasoning is well documented. or MAX(1A,1B), but that is more complex for little gain. -- Bob Harold --f403045c61acefad63055e26fc5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Thu, Nov 16, 2017 at 8:33 AM, Matthijs Mekking <matthijs@pletterpe= t.nl> wrote:
Wes,

My preference is to include safetyMargin and have text to explain it exists= because of network delays etcetera, and also reference to RFC 5011's r= etryTime. So that's some mix of 1B 1C or 2B I guess :)

Best regards,
=C2=A0 Matthijs


On 15-11-17 02:49, Wes Hardaker wrote:

The discussion has been long with respect to the safetyMargin in the
5011 security considerations document.=C2=A0 There hasn't been a huge conclusion and many different ideas have been floated by, and we're now=
at the point where we need to pick between them.=C2=A0 Below, I try to lay<= br> out the primary and sub-options available based on discussions so far.
Please provide your opinions on your preference so I can wrap up this
draft.

Background: This document is not intended to provide operational
guidance on what you SHOULD do.=C2=A0 It's intended to draw the timing = line
below which you MUST NOT venture.=C2=A0 The safetyMargin was introduced to<= br> prevent race conditions based on network delays, eg, which can mean that a RFC5011 Resolver operating at the same time as a PEP Publisher making
a change at exactly at the minimum addWaitTime or addWallClockTime
values would lead to a failure.=C2=A0 So the primary question today is &quo= t;how
do we want to deal with this issue of real-world speed-of-light and
other issues?".=C2=A0 To complicate this a bit further, packets are ne= ver
guaranteed to be delivered and network losses can entirely prevent a
5011 Resolver from succeeding at all for a given operation.

Option 1.=C2=A0 Include a safetyMargin of some value.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1A) safetyMargin =3D MAX(2*TTL, 1= .5Hr)=C2=A0 =C2=A0-- current draft

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1B) safetyMargin =3D something ba= sed on the retryTime,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (an example solutio= n was suggested by MSJ)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1C) Your value here

Option 2.=C2=A0 Don't include a safetyMargin

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2A) Just ignore the issues entire= ly

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2B) Explain that this document do= es not cover operational
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 complexities like r= etries (already in the -07 version),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 network delays and = other operational issues.


After thinking about this for far far too long, I've now switched my ow= n
opinion to that of 2C for the principal reason that this is the
line-in-the-sand document, and to be honest people should be using
values much larger than this, per MSJ's guidance on how 5011 should be<= br> used.=C2=A0 Thus, it makes more sense to define this as the "MUST NOT = go
below this line" without trying to be precise about a value that can n= ever be
perfectly accurate, by definition.

But, forget my opinion.=C2=A0 What's yours?=C2=A0 If nothing else, pick= one of the
[12][ABC] options above please, even without any text defining why you
think so (until someone pokes you).

=

I prefer 1A since the reasoning is w= ell documented.
or=C2=A0 MAX(1A,1B), but that is more complex= for little gain.

--
Bob Harold

--f403045c61acefad63055e26fc5a-- From nobody Thu Nov 16 22:02:39 2017 Return-Path: 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 9CD90128ACA for ; Thu, 16 Nov 2017 22:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 4bhgWUUaiwGJ for ; Thu, 16 Nov 2017 22:02:35 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB32B120227 for ; Thu, 16 Nov 2017 22:02:35 -0800 (PST) Received: from [IPv6:2600:1000:b028:e134:fdd1:411f:8758:2525] (unknown [IPv6:2600:1000:b028:e134:fdd1:411f:8758:2525]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id B80FA61FA3; Fri, 17 Nov 2017 06:02:34 +0000 (UTC) Message-ID: <5A0E7B79.5010608@redbarn.org> Date: Thu, 16 Nov 2017 22:02:33 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= CC: IETF DNSOP WG , Dave Lawrence References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <23051.40720.908131.277454@gro.dd.org> <23051.47926.538193.725450@gro.dd.org> <5A0BBDD7.2070406@redbarn.org> <23051.52473.880861.251236@gro.dd.org> <8D809B23-8A29-483F-9962-4A2E7C426184@redbarn.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 06:02:38 -0000 神明達哉 wrote: > At Wed, 15 Nov 2017 05:41:04 +0000, > P Vix wrote: > >>> 1) when the request explicitly signals it is ok; >>> 2) when the request groks EDNS but might or might not understand >>> a staleness option; or >>> 3) in all cases. >>> >>> My current understanding is that you and Paul are of position 1, while >>> I'm at 3. At first glance 2 would appear to be pretty nearly the same >>> as 3 as far as its permissive toward unaware clients, but >>> significantly it does at least provide signal you could still access >>> via protocol debugging (dig, tcpdump, etc). >> I expect you to implement 3. I expect us to document 1. > > Realistically, I expect virtually everyone will implement 3, given how > this kind of feature is sold in the marketing context. ,,, me too. that's why, in: https://mailarchive.ietf.org/arch/msg/dnsop/zRuuXkwmklMHFvl_Qqzn2N0SOGY/?qid=ff8e732c964b76fed3bbf333b89b111f ...i wrote: > therefore a "serve stale" team within IETF-DNSOP was convened, to try to > standardize the methods and signal patterns necessary to extend the > usability lifetime of records when their authority servers are not > reachable at the time of normal TTL-based expiry. most of us recognize > that TTL's will continue to be stretched no matter what changes are or > are not made to the specification, and so we expect the resulting RFC to > document current practice _without recommending it_ and to also document > a new practice _with recommendations_ as to its proper uses. comments would be very welcome. -- P Vixie From nobody Fri Nov 17 00:55:35 2017 Return-Path: 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 A7B3A1200E5 for ; Fri, 17 Nov 2017 00:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com 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 2BVpN_bZyXyc for ; Fri, 17 Nov 2017 00:55:31 -0800 (PST) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD661200CF for ; Fri, 17 Nov 2017 00:55:30 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id k61so1449365wrc.4 for ; Fri, 17 Nov 2017 00:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b/c8zm4ZK6s1lY8Vd+55Txuf2xHir1RnzddIAccF2bU=; b=Y7MazjyvT4KcsPpnPUaUknBhJoKyIOsgkTmBYPIyFJTjG2F7kDtRHvJWuARj1LVgME uz/vb2TJQLnkxAk/6xsdM+K8DCTXb1ceezz75RJlnED+pxT/DexmD5lOOgAdDJOeBMwr w3/4bGGUhqrX3YL2IN+Y8LXf2rc78ylKOlWUI16R3I3k/T4MMAoUwaHjzySOSZtZYasa gKWqKJwUGTbAyvs/PzL5BhWIGzxNZGsRo2LYh1jUlFD2UdyEsuSJ6rfKMSsXyFNFe0V2 65yqhlHyOS8WG9SyvU6G7xpH5LFNn5A1p/dFYxyWLlPX5+P5ZHbj5146nkXI1l0U2qIF nDTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b/c8zm4ZK6s1lY8Vd+55Txuf2xHir1RnzddIAccF2bU=; b=J6Rre1tN8uSqeOG5r57Il1JzoTB7386IbIaRdNuSc+axWvq/PFZUzHAqu2GF+jR4NT aZxCN+6wJ4KlwhbdalGSAQBZDl57+e1A5FFT3LSvevX4Ow7QsMjoVVROmAc4Jbck3g1P boXOFOa7728rsIQqCQYVWnyL+jzcFdKMQBBrMP1OF+ObkJmIM0moaXC4UrInbJFJlITO 8Z301Y2sl5mRekgxavtMNOTZT4KjxlPtULaR5n16v5r5hfYB4MYZYGLOLhsNLSwNOaqP DsgLkH0h1YPrtwm3l4UrEiiouajL8wthXRNuSoAMq6CVsVtI9IrOi2zFnjQqNkbbn/6x GiEw== X-Gm-Message-State: AJaThX4dVEgyioJ/70sv0y/rlQLkm/Ha9bYOeQjKuUi841dV6MNahw4d 1P3cHmCeWgzHM9b26WHr7661tivgQwcXKeGknPm8hg== X-Google-Smtp-Source: AGs4zMaaNPH9hAi8TGGTlsZK7cgAWLOP78/iOMvLmlYV1SrzK7BJQsfjYIOKZtEE6Qczwb5fPGiy3vh3cZ42WfjPT+Y= X-Received: by 10.223.190.14 with SMTP id n14mr4082474wrh.46.1510908929198; Fri, 17 Nov 2017 00:55:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Michael StJohns Date: Fri, 17 Nov 2017 08:55:18 +0000 Message-ID: To: Bob Harold Cc: IETF DNSOP WG , Matthijs Mekking Content-Type: multipart/alternative; boundary="089e082fc4b0036097055e29e609" Archived-At: Subject: Re: [DNSOP] 5011-security-considerations and the safetyMargin X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 08:55:34 -0000 --089e082fc4b0036097055e29e609 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 1 something. I also believe it should scale as to the size of the subscription base in some way. Basically, this should answer the question of =E2=80=9C given a set of subscribers of size N, a per request failure ra= te of f, a retry time of R, how long do you have to wait until P% of the subscribers have had a successful query?=E2=80=9D So with P =3D=3D 99.99%, R being the fast retry time, f being 5%? And N bei= ng 10M, it should be possible to calculate how long to wait. Basically a cumulative distribution function. When I get back to my laptop, I=E2=80=99= ll check in with excel and see if I can give you an idea of what this looks like. That gives you a reasonable lower bounds for the uptake AFTER dealing with expiring old records and reprents N resolvers doing their last query to validate the new trust anchor. I estimated it as a log function time retry time in an earlier email. Later, mike On Fri, Nov 17, 2017 at 13:27 Bob Harold wrote: > On Thu, Nov 16, 2017 at 8:33 AM, Matthijs Mekking > wrote: > >> Wes, >> >> My preference is to include safetyMargin and have text to explain it >> exists because of network delays etcetera, and also reference to RFC 501= 1's >> retryTime. So that's some mix of 1B 1C or 2B I guess :) >> >> Best regards, >> Matthijs >> >> >> On 15-11-17 02:49, Wes Hardaker wrote: >> >>> >>> The discussion has been long with respect to the safetyMargin in the >>> 5011 security considerations document. There hasn't been a huge >>> conclusion and many different ideas have been floated by, and we're now >>> at the point where we need to pick between them. Below, I try to lay >>> out the primary and sub-options available based on discussions so far. >>> Please provide your opinions on your preference so I can wrap up this >>> draft. >>> >>> Background: This document is not intended to provide operational >>> guidance on what you SHOULD do. It's intended to draw the timing line >>> below which you MUST NOT venture. The safetyMargin was introduced to >>> prevent race conditions based on network delays, eg, which can mean tha= t >>> a RFC5011 Resolver operating at the same time as a PEP Publisher making >>> a change at exactly at the minimum addWaitTime or addWallClockTime >>> values would lead to a failure. So the primary question today is "how >>> do we want to deal with this issue of real-world speed-of-light and >>> other issues?". To complicate this a bit further, packets are never >>> guaranteed to be delivered and network losses can entirely prevent a >>> 5011 Resolver from succeeding at all for a given operation. >>> >>> Option 1. Include a safetyMargin of some value. >>> >>> 1A) safetyMargin =3D MAX(2*TTL, 1.5Hr) -- current draft >>> >>> 1B) safetyMargin =3D something based on the retryTime, >>> (an example solution was suggested by MSJ) >>> >>> 1C) Your value here >>> >>> Option 2. Don't include a safetyMargin >>> >>> 2A) Just ignore the issues entirely >>> >>> 2B) Explain that this document does not cover operational >>> complexities like retries (already in the -07 version), >>> network delays and other operational issues. >>> >>> >>> After thinking about this for far far too long, I've now switched my ow= n >>> opinion to that of 2C for the principal reason that this is the >>> line-in-the-sand document, and to be honest people should be using >>> values much larger than this, per MSJ's guidance on how 5011 should be >>> used. Thus, it makes more sense to define this as the "MUST NOT go >>> below this line" without trying to be precise about a value that can >>> never be >>> perfectly accurate, by definition. >>> >>> But, forget my opinion. What's yours? If nothing else, pick one of th= e >>> [12][ABC] options above please, even without any text defining why you >>> think so (until someone pokes you). >>> >>> > I prefer 1A since the reasoning is well documented. > or MAX(1A,1B), but that is more complex for little gain. > > -- > Bob Harold > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --089e082fc4b0036097055e29e609 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
1 something.=C2=A0 I also believe it should scale as= to the size of the subscription base in some way. =C2=A0 Basically, this s= hould answer the question of =E2=80=9C given a set of subscribers of size N= , a per request failure rate of f, a retry time of R, how long do you have = to wait until P% of the subscribers have had a successful query?=E2=80=9D= =C2=A0

So with P =3D=3D = 99.99%, R being the fast retry time, f being 5%? And N being 10M, it should= be possible to calculate how long to wait.=C2=A0 Basically a cumulative di= stribution function.=C2=A0 When I get back to my laptop, I=E2=80=99ll check= in with excel and see if I can give you an idea of what this looks like. = =C2=A0

That gives = you a reasonable lower bounds for the uptake AFTER dealing with expiring ol= d records and reprents N resolvers doing their last query to validate the n= ew trust anchor. =C2=A0

= I estimated it as a log function time retry time in an earlier email. =C2= =A0

Later, mike



On Fri, Nov 17, 2017 at 13:27 Bob Harold <rharolde@umich.edu>= ; wrote:
On Thu, Nov 16, 2017 at 8:33 AM, Matthijs = Mekking <matthijs@pletterpet.nl> wrote:
Wes,

My preference is to include safetyMargin and have text to explain it exists= because of network delays etcetera, and also reference to RFC 5011's r= etryTime. So that's some mix of 1B 1C or 2B I guess :)

Best regards,
=C2=A0 Matthijs


On 15-11-17 02:49, Wes Hardaker wrote:

The discussion has been long with respect to the safetyMargin in the
5011 security considerations document.=C2=A0 There hasn't been a huge conclusion and many different ideas have been floated by, and we're now=
at the point where we need to pick between them.=C2=A0 Below, I try to lay<= br> out the primary and sub-options available based on discussions so far.
Please provide your opinions on your preference so I can wrap up this
draft.

Background: This document is not intended to provide operational
guidance on what you SHOULD do.=C2=A0 It's intended to draw the timing = line
below which you MUST NOT venture.=C2=A0 The safetyMargin was introduced to<= br> prevent race conditions based on network delays, eg, which can mean that a RFC5011 Resolver operating at the same time as a PEP Publisher making
a change at exactly at the minimum addWaitTime or addWallClockTime
values would lead to a failure.=C2=A0 So the primary question today is &quo= t;how
do we want to deal with this issue of real-world speed-of-light and
other issues?".=C2=A0 To complicate this a bit further, packets are ne= ver
guaranteed to be delivered and network losses can entirely prevent a
5011 Resolver from succeeding at all for a given operation.

Option 1.=C2=A0 Include a safetyMargin of some value.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1A) safetyMargin =3D MAX(2*TTL, 1= .5Hr)=C2=A0 =C2=A0-- current draft

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1B) safetyMargin =3D something ba= sed on the retryTime,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (an example solutio= n was suggested by MSJ)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1C) Your value here

Option 2.=C2=A0 Don't include a safetyMargin

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2A) Just ignore the issues entire= ly

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2B) Explain that this document do= es not cover operational
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 complexities like r= etries (already in the -07 version),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 network delays and = other operational issues.


After thinking about this for far far too long, I've now switched my ow= n
opinion to that of 2C for the principal reason that this is the
line-in-the-sand document, and to be honest people should be using
values much larger than this, per MSJ's guidance on how 5011 should be<= br> used.=C2=A0 Thus, it makes more sense to define this as the "MUST NOT = go
below this line" without trying to be precise about a value that can n= ever be
perfectly accurate, by definition.

But, forget my opinion.=C2=A0 What's yours?=C2=A0 If nothing else, pick= one of the
[12][ABC] options above please, even without any text defining why you
think so (until someone pokes you).


I prefer 1A since the r= easoning is well documented.
or=C2=A0 MAX(1A,1B), but that is= more complex for little gain.

--
Bob Harold

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--089e082fc4b0036097055e29e609-- From nobody Fri Nov 17 05:11:25 2017 Return-Path: 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 6C627127058 for ; Fri, 17 Nov 2017 05:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 2Xbdj5kPqsNs for ; Fri, 17 Nov 2017 05:11:22 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0585E126CB6 for ; Fri, 17 Nov 2017 05:11:21 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id o7so1946801pgc.4 for ; Fri, 17 Nov 2017 05:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NQtJEnIGxKL7uuPMcJq09SXytZFEhYIqFb9GmfAppbA=; b=kliAdrRfzeHt3eSLkT2isxIPrM7g/qccpzGgotZmFfH+JUCplojqXORy6KVzYNqZlq 3BLw7fBUvivg6aDXusoGi1EC9x5FsZPrr52hKsLkxoT09hUQvM1hnBHedJZIQOxwn2m3 AH+UEIVG7wPUHaExgvIMx8UesrWsdKm9KXxttDLhUgv3KRV358xwK3/w6aUnklnGRd9P a6RTwaT4WaQNUQ7dfLqrRWCrBN3upJ840Y1UbBCkC2wzUy4Iakf+6v8gi/coUsTL/onS xK5FyWW0fh9P9qZ2dLn4dZ7YbPEZWvPvZgeR/t8BEeilGvyhMF6j09/WDTAFOpUGrXZG PqmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NQtJEnIGxKL7uuPMcJq09SXytZFEhYIqFb9GmfAppbA=; b=uTji/P5poFOVH7UfSkMSZOXB471H+HKia2K1xmq0InzxcKt8Rno9FyaEZDC3UML2yb C++1tIycTMHdAuffpN79pYwR3I6cK8rOimrNrrj461dx8QZX+uQ+wE31tDRzHT/yoRxJ bu+cvN0wIQ+rapP/nRcBT7Ic9LMMu/f/gz1gQ+7VnvPA5dGvALYhHOg8HGAgbzan+WDa K2b82pyivzOq+ouGEl74QANidXgkaRSyMvEgmPbK8Fw3YI2/+IHmiRJyJV2zHQi1FH1R 6vdRBIZlnj4i+PDBMOhvShVoxqErflhy3KM6tolxTYItz35vX9gyqnneig0D8f8S7zqg Q8qQ== X-Gm-Message-State: AJaThX5D/j15TVzxFwLw3lkhT+rvafvlETGV1kmihfE7Ld+NYi9JjxCK YlRDhCd5X86nr6I9vkiSscRDPMVS3ACqX+NnpDLNlw== X-Google-Smtp-Source: AGs4zMb/uFMZE0TMjBo/Mng9n+LY/WgfCslxkcYDkUF6fVv2qA22R6B7P4oRGHiw8q2TcdcYiqwV5RrjyAfAtyGsZsw= X-Received: by 10.84.239.8 with SMTP id w8mr1241212plk.46.1510924281231; Fri, 17 Nov 2017 05:11:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.171.6 with HTTP; Fri, 17 Nov 2017 05:11:20 -0800 (PST) In-Reply-To: References: <151062636258.5917.14497839377888768972@ietfa.amsl.com> <7572271693475788861@unknownmsgid> From: Bob Harold Date: Fri, 17 Nov 2017 08:11:20 -0500 Message-ID: To: Warren Kumari Cc: Joe Abley , IETF DNSOP WG , "internet-drafts@ietf.org" Content-Type: multipart/alternative; boundary="f4030436049210d054055e2d7990" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 13:11:24 -0000 --f4030436049210d054055e2d7990 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 15, 2017 at 1:38 AM, Warren Kumari wrote: > On Wed, Nov 15, 2017 at 9:45 AM, Joe Abley wrote: > > Hi Bob, > > > > On Nov 15, 2017, at 00:23, Bob Harold wrote: > > > > If I have to add those entries to each zone, I worry that the automated > DNS > > appliance that I use might not be able to create the broken records > > required. > > > > Since the implementation of the mechanism requires special handling of > > queries whose QNAMEs contain the special labels, I don't see why you > would > > ever need to add anything to any zone. > > > > The point of this mechanism is to require no administrator action and to > be > > on by default, I think. > > Yup, *you* should not need to create these records, as long as someone > does the testing will work -- e.g if example.com publishes: > _is-ta-4f66.example.com > _not-ta-4f66.example.com > badlysigned.example.com > > and you can resolve things in example.com you can do the testing. If > your appliance has not been upgraded to know about this new technique > the result will correctly be "unknown / indeterminate" (Vleg[0]) > > W > > [0]: Vleg: A DNSSEC-Validating resolver that does not include this > mechanism will respond with an A record response for "_is-ta", an > A record response for "_not-ta" and SERVFAIL for the invalid name. > > > > > > > > Joe > So for resolvers that can reach the public internet, only one publicly available authoritative server needs to have these special records in one zone? Could that be made clearer in the draft? -- Bob Harold --f4030436049210d054055e2d7990 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Wed, Nov 15, 2017 at 1:38 AM, Warren Kumari <warren@kumari.net><= /span> wrote:
On Wed, No= v 15, 2017 at 9:45 AM, Joe Abley <= jabley@hopcount.ca> wrote:
> Hi Bob,
>
> On Nov 15, 2017, at 00:23, Bob Harold <rharolde@umich.edu> wrote:
>
> If I have to add those entries to each zone, I worry that the automate= d DNS
> appliance that I use might not be able to create the broken records > required.
>
> Since the implementation of the mechanism requires special handling of=
> queries whose QNAMEs contain the special labels, I don't see why y= ou would
> ever need to add anything to any zone.
>
> The point of this mechanism is to require no administrator action and = to be
> on by default, I think.

Yup, *you* should not need to create these records, as long as someo= ne
does the testing will work -- e.g if example.com publishes:
_is-ta-4f66.example.com
_not-ta-4f66.example.com
badlysigned.example.com

and you can resolve things in example.com you can do the testing. If
your appliance has not been upgraded to know about this new technique
the result will correctly be "unknown / indeterminate" (Vleg[0])<= br>
W

[0]: Vleg: A DNSSEC-Validating resolver that does not include this
=C2=A0 =C2=A0 =C2=A0 mechanism will respond with an A record response for &= quot;_is-ta", an
=C2=A0 =C2=A0 =C2=A0 A record response for "_not-ta" and SERVFAIL= for the invalid name.


>
>
> Joe

So for resolvers that can reach the public internet, only one publicly a= vailable authoritative server needs to have these special records in one zo= ne?

Could that be made clearer in the draft?

--
Bob Harold

--f4030436049210d054055e2d7990-- From nobody Fri Nov 17 10:46:38 2017 Return-Path: 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 C0CE8126BF6 for ; Fri, 17 Nov 2017 10:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KjJJnCJXSKHC for ; Fri, 17 Nov 2017 10:46:36 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE08E124C27 for ; Fri, 17 Nov 2017 10:46:35 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id p96so2890991wrb.7 for ; Fri, 17 Nov 2017 10:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Bzngmfd50x1gGcLrS4v22jNvWPEeX6tu9gnxczvUiTE=; b=feszZD25kYexUsOWForqyvlPze8PPlRlULh5iFhFP/5CPc7aH97xU5CyzWrfG/hN1j PVD1O9CUDQqgWVFsLRMToIDew6M7EPy9vPm1u6bDzBfBIp/GWvnO4oC2sf0yPDH1uPVv KHwbJi2+ykXr5jSl9ZtlW6+yjJOmUxpj7bEC5Q/PZAtBHD8BTeoJgMScYy6evSq9/toR tuSUFeVqqfnU9pHbp7j6n3nYkc61cHarpP+21JAgK10q8evD7EpYJxRPYpHURYD4bhrg hlFGvaYhX28TWyhFhWKxlD7u/6AFXYdUZJiUvGhCQe3mNIgfa+VoSNbiibSkrtuDlzto WbiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Bzngmfd50x1gGcLrS4v22jNvWPEeX6tu9gnxczvUiTE=; b=ZboPX9oGVkFJ9hWn4oUuKK6cuKoM5h03G4zr50UvLRPLLJwDqaVYiwJqx+kAVz446o IsZNU0XVjQPlOrZaslV2XMc8KNGAYCjvrNd6UwgrHhZsf9fjH5hnVlrA80836AieZ3pX SHvAQ/AUupNoEVkO5lL4q9zGbtgAgbh9KszxEmMQiVq2GSHAL4iS7Jay4bTLKxrsgIec fvxhGLIhsOgu2Mi/XvG0oRbIJtyMtofkDUYF+nPSRicSlydsvEeug5vwKOqZQwWUn++X aXbhCbMQHc2vICf+hhFV13q3ZlODjuNLilFEEtgMlXO8Aun/odf1ZkFNpufWQtXqZ+iA Ef2Q== X-Gm-Message-State: AJaThX6OJQmCluVMQo51LsoQ65nljkn6spBloHzSIxPlAtfA/QtJccMM YbsaDhDbgJswIFVE2D12qgdj6nml/TKb9fEyB3OyHPHO X-Google-Smtp-Source: AGs4zMa5ggil+lsvW1pyF4iaLl3DYAn40VaDfyupyEkqBWRk4pVWuwCByrXIJPao7LRtTrP3bPA3KKSDpXJCuJc958o= X-Received: by 10.223.178.232 with SMTP id g95mr4991137wrd.53.1510944393893; Fri, 17 Nov 2017 10:46:33 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.223.179.196 with HTTP; Fri, 17 Nov 2017 10:46:33 -0800 (PST) In-Reply-To: <5A0E7B79.5010608@redbarn.org> References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <23051.40720.908131.277454@gro.dd.org> <23051.47926.538193.725450@gro.dd.org> <5A0BBDD7.2070406@redbarn.org> <23051.52473.880861.251236@gro.dd.org> <8D809B23-8A29-483F-9962-4A2E7C426184@redbarn.org> <5A0E7B79.5010608@redbarn.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 17 Nov 2017 10:46:33 -0800 X-Google-Sender-Auth: URZMH_eiMGS-NT5GDDruTMQVUp0 Message-ID: To: Paul Vixie Cc: IETF DNSOP WG , Dave Lawrence Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 18:46:38 -0000 At Thu, 16 Nov 2017 22:02:33 -0800, Paul Vixie wrote: > > Realistically, I expect virtually everyone will implement 3, given how > > this kind of feature is sold in the marketing context. ,,, > > me too. that's why, in: > > https://mailarchive.ietf.org/arch/msg/dnsop/zRuuXkwmklMHFvl_Qqzn2N0SOGY/?qid=ff8e732c964b76fed3bbf333b89b111f > ...i wrote: > > > therefore a "serve stale" team within IETF-DNSOP was convened, to try to > > standardize the methods and signal patterns necessary to extend the > > usability lifetime of records when their authority servers are not > > reachable at the time of normal TTL-based expiry. most of us recognize > > that TTL's will continue to be stretched no matter what changes are or > > are not made to the specification, and so we expect the resulting RFC to > > document current practice _without recommending it_ and to also document > > a new practice _with recommendations_ as to its proper uses. This (including the entire message) looks reasonable to me, as long as we mean it, i.e., we actually seriously work on the "new practice" as a followup wg task, rather than just using it as an excuse to publish the current serve-stale draft. But I'd note there might be some confusion here (perhaps only for me, though). I've been having the impression that we are talking about "signalling" between the stub and caching (usually recursive) server, perhaps because it's a followup of this message: https://www.ietf.org/mail-archive/web/dnsop/current/msg21339.html But your suggestion is signalling (mainly) between caching and authoritative servers, right? I thought recommending to allow fallback to stale >>> 1) when the request explicitly signals it is ok; between stub and caching wasn't realistic, as I didn't see a strong incentive for the developers and users of stub (except for protocol-savvy kinds). That's why I was pessimistic in my previous message. I see more reality if it's about signalling between caching and authoritative since, as you pointed out, there may also be incentive for authoritative operators to adopt the "new practice". -- JINMEI, Tatuya From nobody Fri Nov 17 12:50:01 2017 Return-Path: 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 7D83B12426E for ; Fri, 17 Nov 2017 12:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 Aq0G2Zja6nFL for ; Fri, 17 Nov 2017 12:49:57 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3EA31200B9 for ; Fri, 17 Nov 2017 12:49:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=6XNWdzplusv56wp+gXqOA1J8DTcyBwTmd/i8H598uig=; b=5AFdWiwJ9FR6Pw5AlRiAoenYiU3SlRtIps7CD7Pq45ByiGE2PqywmEhD8WMcK08cce3bcaUNnXls1KHDUiHg7PjiQMtYYi6i8vc1GO4BGlAKz1zaJW21OEpSw8ewGfyDaUTuYOrz+Tp4f2adMmNB57B6c7VAnfaOrcdHXUhtgxw=; Received: ; Fri, 17 Nov 2017 12:49:30 -0800 To: dnsop WG , Phillip Hallam-Baker From: Jacob Hoffman-Andrews Message-ID: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org> Date: Fri, 17 Nov 2017 12:49:33 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [DNSOP] Error handling in CAA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 20:49:59 -0000 In the SPASM group, we are refining CAA (RFC 6844) based on the changes that were needed in order to get it passed at the CA/Browser Forum. There's one sticky bit in particular I'd like input on. Here's the current language in the BRs: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.4.pdf > CAs are permitted to treat a record lookup failure as permission to issue > if: > - the failure is outside the CA's infrastructure; > - the lookup has been retried at least once; and > - the domain's zone does not have a DNSSEC validation chain to the > ICANN root. It would be nice if we could provide more solid language for a future BR update, or possibly for a CAA update. The goal here is to work around the issue that a small but significant number of domains return errors when asked for CAA ((I'd guesstimate 1%?). CAs would like to be able to assume there is no CAA record present for those domains and issue anyhow. However, if you're using a standard recursive resolver inside your own infrastructure, and you get a SERVFAIL, how do you distinguish whether that was a DNSSEC validation failure or another type? I realize the extended-error draft will help enormously with that, but I'm looking for a solution that can be deployed before that is done. One idea: Run two recursive resolvers, one validating and one not. If you get an error from both, it's a network error; if you get an error from the validating one and success from the non-validating one, it's a DNSSEC error and you should refuse issuance. A second issue: How does one determine automatically whether a failure is "outside a CA's infrastructure?" This was inserted as a bit of a handwave to get the ballot passed, but it would be nice if we could formalize this concept, or declare that it's unenforceable. Thanks, Jacob From nobody Fri Nov 17 15:06:23 2017 Return-Path: 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 2561B120724 for ; Fri, 17 Nov 2017 15:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 Td30oFbpFDQv for ; Fri, 17 Nov 2017 15:06:20 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F347B124217 for ; Fri, 17 Nov 2017 15:06:19 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:cd10:acfb:3707:f2f1] (unknown [IPv6:2001:559:8000:c9:cd10:acfb:3707:f2f1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id B259061FA3; Fri, 17 Nov 2017 23:06:19 +0000 (UTC) Message-ID: <5A0F6B6C.1020802@redbarn.org> Date: Fri, 17 Nov 2017 15:06:20 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= CC: IETF DNSOP WG , Dave Lawrence References: <150940017764.7814.6739838599217498076@ietfa.amsl.com> <23040.33307.69754.133713@gro.dd.org> <23050.45832.787089.325014@gro.dd.org> <23051.40720.908131.277454@gro.dd.org> <23051.47926.538193.725450@gro.dd.org> <5A0BBDD7.2070406@redbarn.org> <23051.52473.880861.251236@gro.dd.org> <8D809B23-8A29-483F-9962-4A2E7C426184@redbarn.org> <5A0E7B79.5010608@redbarn.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 23:06:22 -0000 神明達哉 wrote: > At Thu, 16 Nov 2017 22:02:33 -0800, > Paul Vixie wrote: >> https://mailarchive.ietf.org/arch/msg/dnsop/zRuuXkwmklMHFvl_Qqzn2N0SOGY/?qid=ff8e732c964b76fed3bbf333b89b111f > >> ...i wrote: >> >>> therefore a "serve stale" team within IETF-DNSOP was convened, to try to >>> standardize the methods and signal patterns necessary to extend the >>> usability lifetime of records when their authority servers are not >>> reachable at the time of normal TTL-based expiry. most of us recognize >>> that TTL's will continue to be stretched no matter what changes are or >>> are not made to the specification, and so we expect the resulting RFC to >>> document current practice _without recommending it_ and to also document >>> a new practice _with recommendations_ as to its proper uses. > > This (including the entire message) looks reasonable to me, as long as > we mean it, i.e., we actually seriously work on the "new practice" as > a followup wg task, rather than just using it as an excuse to publish > the current serve-stale draft. later in [ibid], i wrote: > this system would allow gradual insertion of the new state management > logic on an opportunistic basis -- motivated authority and recursive > server operators, which would include CDN operators who must perform > both services perfectly -- would be early adopters, and like ECS before > it, the "hot" part of the community would be upgraded years earlier than > the last outlier. i think that it's in the large RDNS operators' interests, and in the large authority operators' interests, and in CDN and proxy operators' interests, to deploy these new protocols -- and that once they see positive results, they will find it in their best interests to turn off the older pre-standard TTL stretching logic that should be described, but _not recommended_, in the TTL-stretch specification. if i could not visualize a fully interest-aligned deployment path for the operators who most need TTL stretching, then i would agree with your concern that we might not "mean" it. > But I'd note there might be some confusion here (perhaps only for me, > though). I've been having the impression that we are talking about > "signalling" between the stub and caching (usually recursive) server, > perhaps because it's a followup of this message: > https://www.ietf.org/mail-archive/web/dnsop/current/msg21339.html > > But your suggestion is signalling (mainly) between caching and > authoritative servers, right? yes. i don't think anything that requires end-system upgrades is going to answer the market need for TTL stretching. even "happy eyeballs" took five years to be adopted and another two years to stabilize. > I thought recommending to allow fallback to stale > >>>> 1) when the request explicitly signals it is ok; > > between stub and caching wasn't realistic, as I didn't see a strong > incentive for the developers and users of stub (except for > protocol-savvy kinds). That's why I was pessimistic in my previous > message. I see more reality if it's about signalling between caching > and authoritative since, as you pointed out, there may also be > incentive for authoritative operators to adopt the "new practice". the TTL stretching specification should ideally introduce new stub signalling to turn off stretching, so that those of us using "dig" in diagnostic mode, can learn more about the TTL-state of the RRset in our local RDNS. -- P Vixie From nobody Sat Nov 18 12:13:17 2017 Return-Path: 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 E58431241F5 for ; Sat, 18 Nov 2017 12:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ouwQTDM6R9Vt for ; Sat, 18 Nov 2017 12:13:14 -0800 (PST) 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 5BCFD1200FC for ; Sat, 18 Nov 2017 12:13:14 -0800 (PST) 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 BA3CF3BA2D6; Sat, 18 Nov 2017 20:13:11 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7B937160072; Sat, 18 Nov 2017 20:13:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6380916006E; Sat, 18 Nov 2017 20:13:10 +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 RvhAUSX9LGKu; Sat, 18 Nov 2017 20:13:10 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 8E98E160044; Sat, 18 Nov 2017 20:13:09 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org> Date: Sun, 19 Nov 2017 07:13:09 +1100 Cc: dnsop WG , Phillip Hallam-Baker Content-Transfer-Encoding: quoted-printable Message-Id: <12877293-384A-4A8B-BC74-F025CCE30765@isc.org> References: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org> To: Jacob Hoffman-Andrews X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Error handling in CAA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2017 20:13:16 -0000 The only real way to determine if a lookup failure in internally or not = is to query the authoritative servers for the zone directly. The simple fix is to charge $1000 extra if the CAA lookup fails due to = the authoritative servers for the zone failing to support lookups for the = CAA record or for the servers being incorrectly delegated. This covers = moving the lookup off the automated path. Make sure this fee is clearly stated up front. RFC 1034 had clear = instructions for how to handle unknown records. You refuse to load the zone if they = present and return SERVFAIL. After that there is no special handling required. = As they are not present in the zone the server returns NOERROR or NXDOMAIN as = appropriate. Recursive servers treat them as opaque blobs. Add to that RFC 3597 was = published in 2003 which provided a master file representation to allow unknown = records to be saved in a master file. It also repeated the handling instructions = from RFC 1034 in different words. Failing to support CAA lookups include but is not limited to: returning SERVFAIL (rcode 2) returning FORMERR (rcode 1) returning NOTIMP (rcode 4) timing out on CAA lookups but not timing out on one of SOA, A or AAAA Mark > On 18 Nov 2017, at 7:49 am, Jacob Hoffman-Andrews = wrote: >=20 > In the SPASM group, we are refining CAA (RFC 6844) based on the = changes > that were needed in order to get it passed at the CA/Browser Forum. > There's one sticky bit in particular I'd like input on. Here's the > current language in the BRs: >=20 > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.4.pdf >=20 >> CAs are permitted to treat a record lookup failure as permission to = issue >> if: >> - the failure is outside the CA's infrastructure; >> - the lookup has been retried at least once; and >> - the domain's zone does not have a DNSSEC validation chain to the >> ICANN root. >=20 > It would be nice if we could provide more solid language for a future = BR > update, or possibly for a CAA update. >=20 > The goal here is to work around the issue that a small but significant > number of domains return errors when asked for CAA ((I'd guesstimate > 1%?). CAs would like to be able to assume there is no CAA record = present > for those domains and issue anyhow. >=20 > However, if you're using a standard recursive resolver inside your own > infrastructure, and you get a SERVFAIL, how do you distinguish whether > that was a DNSSEC validation failure or another type? I realize the > extended-error draft will help enormously with that, but I'm looking = for > a solution that can be deployed before that is done. One idea: Run two > recursive resolvers, one validating and one not. If you get an error > from both, it's a network error; if you get an error from the = validating > one and success from the non-validating one, it's a DNSSEC error and = you > should refuse issuance. >=20 > A second issue: How does one determine automatically whether a failure > is "outside a CA's infrastructure?" This was inserted as a bit of a > handwave to get the ballot passed, but it would be nice if we could > formalize this concept, or declare that it's unenforceable. >=20 > Thanks, > Jacob >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sat Nov 18 13:10:04 2017 Return-Path: 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 A279412009C for ; Sat, 18 Nov 2017 13:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 c8IbIZLMAGcU for ; Sat, 18 Nov 2017 13:10:02 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C2012008A for ; Sat, 18 Nov 2017 13:10:01 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 86AAE7A330A; Sat, 18 Nov 2017 21:10:00 +0000 (UTC) Date: Sat, 18 Nov 2017 21:10:00 +0000 From: Viktor Dukhovni To: dnsop WG Message-ID: <20171118211000.GR3322@mournblade.imrryr.org> Reply-To: dnsop@ietf.org References: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [DNSOP] Error handling in CAA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2017 21:10:03 -0000 On Fri, Nov 17, 2017 at 12:49:33PM -0800, Jacob Hoffman-Andrews wrote: > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.4.pdf > > > CAs are permitted to treat a record lookup failure as permission to issue > > if: > > - the failure is outside the CA's infrastructure; > > - the lookup has been retried at least once; and > > - the domain's zone does not have a DNSSEC validation chain to the ICANN root. This language really should have been much more clear. In particular, the last item warrants clarification. It is critical that the CA determine the lack of a validation chain in a robust manner. The simplest approach: * Request the SOA record of the domain. If this lookup fails, (ServFail, Timeout, ...) stop, the domain's DNSSEC status is unknown. * If the lookup returns NoError with AD=1 (a validated SOA record or a validated NoData), the domain is signed, do not tolerate CAA lookup failure. Ditto for "NXDomain". (As I've repeated too many times, NoError, NoData and NXDomain are not lookup failures). * If the lookup returns NoError with AD=0 (an insecure SOA record or an insecure NODATA), the domain is not signed. Ditto for NXDomain. Tolerate persistent CAA lookup failure. > However, if you're using a standard recursive resolver inside your own > infrastructure, and you get a SERVFAIL, how do you distinguish whether > that was a DNSSEC validation failure or another type? See above, the CA should not attempt to distinguish between different faiure modes. * All failures for domains *not known* to be "insecure" should be fatal. * Persistent CAA lookup failure for *known* "insecure" domains (AD=0 with NoError, NoData or NXDomain) can be ultimately ignored as a software or configuration issue with the remote nameservers. I include NXDomain, because I think (correct me if I'm wrong) CAs may issue certificates for (internal) names that don't appear on the public internet, when the customer controls a public prefix. > I realize the > extended-error draft will help enormously with that, but I'm looking for > a solution that can be deployed before that is done. It is best to not attempt to read the tea-leaves. You can reliably determine which domains are insecure. Your validating resolver will include the AD bit with the SOA lookup result. If even SOA lookups fail, the domain is busted, and needs to be fixed on the customer's end. > One idea: Run two > recursive resolvers, one validating and one not. If you get an error > from both, it's a network error; if you get an error from the validating > one and success from the non-validating one, it's a DNSSEC error and you > should refuse issuance. This is complicated. > A second issue: How does one determine automatically whether a failure > is "outside a CA's infrastructure?" This was inserted as a bit of a > handwave to get the ballot passed, but it would be nice if we could > formalize this concept, or declare that it's unenforceable. That language looks misguided to me. -- Viktor. From nobody Sat Nov 18 16:54:12 2017 Return-Path: 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 5E5C51250B8 for ; Sat, 18 Nov 2017 16:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 eetZObs5sUCQ for ; Sat, 18 Nov 2017 16:54:08 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 3CDAE124B09 for ; Sat, 18 Nov 2017 16:54:08 -0800 (PST) Received: from [169.254.25.203] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vAJ0qbd9036853 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 18 Nov 2017 17:52:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.25.203] From: "Paul Hoffman" To: dnsop@ietf.org Date: Sat, 18 Nov 2017 16:54:04 -0800 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-isp-ip6rdns X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 00:54:09 -0000 On 16 Nov 2017, at 20:12, Lee Howard wrote: > I updated this draft months ago, based on feedback from the previous > WGLC, > and it expired without comment. I’ve refreshed it, and would like to > ask > again for reviews (especially if anything has changed in the past > year) and > another WGLC. > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/ This version seems fine, even without specific recommendations. From the earlier discussion in the WG, it doesn't seem like there is agreement on recommendations, and the draft covers the methods that could be used in enough detail where an operator can decide what they want to do. --Paul Hoffman From nobody Sun Nov 19 01:50:21 2017 Return-Path: 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 E42D61243F6 for ; Sun, 19 Nov 2017 01:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 p1cq90sX6sk5 for ; Sun, 19 Nov 2017 01:50:18 -0800 (PST) Received: from atl4mhob09.registeredsite.com (atl4mhob09.registeredsite.com [209.17.115.47]) (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 1A93E120724 for ; Sun, 19 Nov 2017 01:50:18 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob09.registeredsite.com (8.14.4/8.14.4) with ESMTP id vAJ9oDBB030859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 19 Nov 2017 04:50:15 -0500 Message-Id: <201711190950.vAJ9oDBB030859@atl4mhob09.registeredsite.com> Received: (qmail 31070 invoked by uid 0); 19 Nov 2017 09:50:13 -0000 X-TCPREMOTEIP: 73.251.233.169 X-Authenticated-UID: jw@pcthink.com Received: from unknown (HELO ?10.2.1.116?) (jw@pcthink.com@73.251.233.169) by 0 with ESMTPA; 19 Nov 2017 09:50:13 -0000 SavedFromEmail: jw@pcthink.com Date: Sun, 19 Nov 2017 04:50:11 -0500 Importance: normal From: JW To: dnsop@ietf.org Cc: jw@pcthink.com, dnsop@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1495243731058980" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 09:50:20 -0000 ----_com.samsung.android.email_1495243731058980 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGVsbG8sClRoaXMgZHJhZnQgd2FzIHJlbGVhc2VkIGEgY291cGxlIHdlZWtzIGFnbyBhbmQgaW5j bHVkZXMgd2hhdCB3ZSBmZWVsIGFyZSBzb21lIHZlcnkgbm90ZXdvcnRoeSBjaGFuZ2VzLgpQbGVh c2UgdGFrZSBhbm90aGVyIGxvb2sgd2hlbiB5b3UgaGF2ZSB0aW1lLCBhcyBhbHdheXMgd2UgbG9v ayBmb3J3YXJkIHRvIGFuZCB3ZWxjb21lIGFueSBxdWVzdGlvbnMvIGNvbW1lbnRzLgpJIGFtIGRp c2FwcG9pbnRlZCBJIHdhcyB1bmFibGUgdG8gam9pbiB0aGUgZ3JvdXAgaW4gU2luZ2Fwb3JlIGJ1 dCBhbSBvcHRpbWlzdGljIEknbGwgYmUgYWJsZSB0byBtZWV0IGFnYWluIGluIExvbmRvbi4KClRo YW5rcyxKb2huCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmdTdWJqZWN0OiBbRE5TT1BdIEktRCBBY3Rpb246IGRyYWZ0LXdvb2R3 b3J0aC1idWxrLXJyLTA3LnR4dCAKCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4KVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgRG9tYWluIE5hbWUgU3lzdGVtIE9wZXJhdGlvbnMgV0cgb2Yg dGhlIElFVEYuCgrCoMKgwqDCoMKgwqDCoCBUaXRsZcKgwqDCoMKgwqDCoMKgwqDCoMKgIDogQlVM SyBETlMgUmVzb3VyY2UgUmVjb3JkcwrCoMKgwqDCoMKgwqDCoCBBdXRob3JzwqDCoMKgwqDCoMKg wqDCoCA6IEpvaG4gV29vZHdvcnRoCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIERlYW4gQmFsbGV3CsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIFNoYXNod2F0aCBCaW5kaW5nYW5hdmVsaSBSYWdoYXZhbgrC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBEYXZpZCBD IExhd3JlbmNlCglGaWxlbmFtZcKgwqDCoMKgwqDCoMKgIDogZHJhZnQtd29vZHdvcnRoLWJ1bGst cnItMDcudHh0CglQYWdlc8KgwqDCoMKgwqDCoMKgwqDCoMKgIDogMTYKCURhdGXCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIDogMjAxNy0xMC0zMAoKQWJzdHJhY3Q6CsKgwqAgVGhlIEJVTEsgRE5TIHJl c291cmNlIHJlY29yZCB0eXBlIGRlZmluZXMgYSBtZXRob2Qgb2YgcGF0dGVybi1iYXNlZArCoMKg IGNyZWF0aW9uIG9mIEROUyByZXNvdXJjZSByZWNvcmRzIGJhc2VkIG9uIG51bWVyaWMgc3Vic3Ry aW5ncyBvZiBxdWVyeQrCoMKgIG5hbWVzLsKgIFRoZSBpbnRlbnQgb2YgQlVMSyBpcyB0byBzaW1w bGlmeSBnZW5lcmljIGFzc2lnbm1lbnRzIGluIGEKwqDCoCBtZW1vcnktZWZmaWNpZW50IHdheSB0 aGF0IGNhbiBiZSBlYXNpbHkgc2hhcmVkIGJldHdlZW4gdGhlIHByaW1hcnkKwqDCoCBhbmQgc2Vj b25kYXJ5IG5hbWVzZXJ2ZXJzIGZvciBhIHpvbmUuCgoKVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXdvb2R3b3J0aC1idWxrLXJyLwoKVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVy c2lvbnMgYXZhaWxhYmxlIGF0OgpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd29v ZHdvcnRoLWJ1bGstcnItMDcKaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k cmFmdC13b29kd29ydGgtYnVsay1yci0wNwoKQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNp b24gaXMgYXZhaWxhYmxlIGF0OgpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtd29vZHdvcnRoLWJ1bGstcnItMDcKCgpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uCnVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu CgpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 CmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpETlNPUCBtYWlsaW5nIGxpc3QKRE5TT1BAaWV0 Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnNvcAoK ----_com.samsung.android.email_1495243731058980 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48Zm9udCBmYWNlPSJzYW5zLXNlcmlm Ij5IZWxsbyw8L2ZvbnQ+PGRpdj48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIiBkaXI9ImF1dG8iPjxi cj48L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIiBkaXI9ImF1dG8iPlRo aXMgZHJhZnQgd2FzIHJlbGVhc2VkIGEgY291cGxlIHdlZWtzIGFnbyBhbmQgaW5jbHVkZXMgd2hh dCB3ZSBmZWVsIGFyZSBzb21lIHZlcnkgbm90ZXdvcnRoeSBjaGFuZ2VzLjwvZm9udD48L2Rpdj48 ZGl2Pjxmb250IGZhY2U9InNhbnMtc2VyaWYiIGRpcj0iYXV0byI+PGJyPjwvZm9udD48L2Rpdj48 ZGl2Pjxmb250IGZhY2U9InNhbnMtc2VyaWYiIGRpcj0iYXV0byI+UGxlYXNlIHRha2UgYW5vdGhl ciBsb29rIHdoZW4geW91IGhhdmUgdGltZSwgYXMgYWx3YXlzIHdlIGxvb2sgZm9yd2FyZCB0byBh bmQgd2VsY29tZSBhbnkgcXVlc3Rpb25zLyBjb21tZW50cy48L2ZvbnQ+PC9kaXY+PGRpdj48Zm9u dCBmYWNlPSJzYW5zLXNlcmlmIiBkaXI9ImF1dG8iPjxicj48L2ZvbnQ+PC9kaXY+PGRpdj5JIGFt IGRpc2FwcG9pbnRlZCBJIHdhcyB1bmFibGUgdG8gam9pbiB0aGUgZ3JvdXAgaW4gU2luZ2Fwb3Jl IGJ1dCBhbSBvcHRpbWlzdGljIEknbGwgYmUgYWJsZSB0byBtZWV0IGFnYWluIGluIExvbmRvbi48 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rcyw8L2Rpdj48ZGl2 PkpvaG48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xv cjojMDAwMDAwIj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAw Ij48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAwIj48L2Rpdj48 ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVz c2FnZSAtLT48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2 PkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvZGl2PjxkaXY+U3ViamVjdDogW0ROU09Q XSBJLUQgQWN0aW9uOiBkcmFmdC13b29kd29ydGgtYnVsay1yci0wNy50eHQgPC9kaXY+PGRpdj48 YnI+PC9kaXY+PC9kaXY+PGJyPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+VGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgRG9tYWluIE5hbWUgU3lzdGVtIE9wZXJhdGlvbnMgV0cgb2Yg dGhlIElFVEYuPGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVGl0bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgOiBCVUxLIEROUyBSZXNvdXJjZSBSZWNvcmRzPGJyPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBdXRob3JzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogSm9obiBXb29kd29ydGg8YnI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERlYW4gQmFsbGV3PGJyPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTaGFzaHdhdGggQmluZGluZ2FuYXZlbGkgUmFnaGF2YW48 YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhdmlkIEMgTGF3cmVuY2U8 YnI+CUZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDog ZHJhZnQtd29vZHdvcnRoLWJ1bGstcnItMDcudHh0PGJyPglQYWdlcyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDE2PGJyPglEYXRl Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDogMjAxNy0xMC0zMDxicj48YnI+QWJzdHJhY3Q6PGJyPiZuYnNwOyZuYnNwOyBU aGUgQlVMSyBETlMgcmVzb3VyY2UgcmVjb3JkIHR5cGUgZGVmaW5lcyBhIG1ldGhvZCBvZiBwYXR0 ZXJuLWJhc2VkPGJyPiZuYnNwOyZuYnNwOyBjcmVhdGlvbiBvZiBETlMgcmVzb3VyY2UgcmVjb3Jk cyBiYXNlZCBvbiBudW1lcmljIHN1YnN0cmluZ3Mgb2YgcXVlcnk8YnI+Jm5ic3A7Jm5ic3A7IG5h bWVzLiZuYnNwOyBUaGUgaW50ZW50IG9mIEJVTEsgaXMgdG8gc2ltcGxpZnkgZ2VuZXJpYyBhc3Np Z25tZW50cyBpbiBhPGJyPiZuYnNwOyZuYnNwOyBtZW1vcnktZWZmaWNpZW50IHdheSB0aGF0IGNh biBiZSBlYXNpbHkgc2hhcmVkIGJldHdlZW4gdGhlIHByaW1hcnk8YnI+Jm5ic3A7Jm5ic3A7IGFu ZCBzZWNvbmRhcnkgbmFtZXNlcnZlcnMgZm9yIGEgem9uZS48YnI+PGJyPjxicj5UaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd29vZHdvcnRoLWJ1bGstcnIvPGJyPjxicj5UaGVy ZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PGJyPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13b29kd29ydGgtYnVsay1yci0wNzxicj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXdvb2R3b3J0aC1idWxrLXJyLTA3PGJy Pjxicj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJy Pmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13b29kd29ydGgtYnVsay1y ci0wNzxicj48YnI+PGJyPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+dW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+PGJy PkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8 YnI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88YnI+PGJyPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPkROU09QIG1haWxpbmcgbGlz dDxicj5ETlNPUEBpZXRmLm9yZzxicj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Ruc29wPGJyPjxicj48L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_1495243731058980-- From nobody Sun Nov 19 01:50:28 2017 Return-Path: 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 C78AF120724 for ; Sun, 19 Nov 2017 01:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=unavailable 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 Am52udR-RS4U for ; Sun, 19 Nov 2017 01:50:17 -0800 (PST) Received: from atl4mhob07.registeredsite.com (atl4mhob07.registeredsite.com [209.17.115.45]) (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 B2B521200C1 for ; Sun, 19 Nov 2017 01:50:17 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob07.registeredsite.com (8.14.4/8.14.4) with ESMTP id vAJ9oDKN011534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 19 Nov 2017 04:50:14 -0500 Message-Id: <201711190950.vAJ9oDKN011534@atl4mhob07.registeredsite.com> Received: (qmail 31070 invoked by uid 0); 19 Nov 2017 09:50:13 -0000 X-TCPREMOTEIP: 73.251.233.169 X-Authenticated-UID: jw@pcthink.com Received: from unknown (HELO ?10.2.1.116?) (jw@pcthink.com@73.251.233.169) by 0 with ESMTPA; 19 Nov 2017 09:50:13 -0000 SavedFromEmail: jw@pcthink.com Date: Sun, 19 Nov 2017 04:50:11 -0500 Importance: normal From: JW To: dnsop@ietf.org Cc: jw@pcthink.com, dnsop@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1495243731058980" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 09:50:21 -0000 ----_com.samsung.android.email_1495243731058980 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGVsbG8sClRoaXMgZHJhZnQgd2FzIHJlbGVhc2VkIGEgY291cGxlIHdlZWtzIGFnbyBhbmQgaW5j bHVkZXMgd2hhdCB3ZSBmZWVsIGFyZSBzb21lIHZlcnkgbm90ZXdvcnRoeSBjaGFuZ2VzLgpQbGVh c2UgdGFrZSBhbm90aGVyIGxvb2sgd2hlbiB5b3UgaGF2ZSB0aW1lLCBhcyBhbHdheXMgd2UgbG9v ayBmb3J3YXJkIHRvIGFuZCB3ZWxjb21lIGFueSBxdWVzdGlvbnMvIGNvbW1lbnRzLgpJIGFtIGRp c2FwcG9pbnRlZCBJIHdhcyB1bmFibGUgdG8gam9pbiB0aGUgZ3JvdXAgaW4gU2luZ2Fwb3JlIGJ1 dCBhbSBvcHRpbWlzdGljIEknbGwgYmUgYWJsZSB0byBtZWV0IGFnYWluIGluIExvbmRvbi4KClRo YW5rcyxKb2huCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmdTdWJqZWN0OiBbRE5TT1BdIEktRCBBY3Rpb246IGRyYWZ0LXdvb2R3 b3J0aC1idWxrLXJyLTA3LnR4dCAKCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4KVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgRG9tYWluIE5hbWUgU3lzdGVtIE9wZXJhdGlvbnMgV0cgb2Yg dGhlIElFVEYuCgrCoMKgwqDCoMKgwqDCoCBUaXRsZcKgwqDCoMKgwqDCoMKgwqDCoMKgIDogQlVM SyBETlMgUmVzb3VyY2UgUmVjb3JkcwrCoMKgwqDCoMKgwqDCoCBBdXRob3JzwqDCoMKgwqDCoMKg wqDCoCA6IEpvaG4gV29vZHdvcnRoCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIERlYW4gQmFsbGV3CsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIFNoYXNod2F0aCBCaW5kaW5nYW5hdmVsaSBSYWdoYXZhbgrC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBEYXZpZCBD IExhd3JlbmNlCglGaWxlbmFtZcKgwqDCoMKgwqDCoMKgIDogZHJhZnQtd29vZHdvcnRoLWJ1bGst cnItMDcudHh0CglQYWdlc8KgwqDCoMKgwqDCoMKgwqDCoMKgIDogMTYKCURhdGXCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIDogMjAxNy0xMC0zMAoKQWJzdHJhY3Q6CsKgwqAgVGhlIEJVTEsgRE5TIHJl c291cmNlIHJlY29yZCB0eXBlIGRlZmluZXMgYSBtZXRob2Qgb2YgcGF0dGVybi1iYXNlZArCoMKg IGNyZWF0aW9uIG9mIEROUyByZXNvdXJjZSByZWNvcmRzIGJhc2VkIG9uIG51bWVyaWMgc3Vic3Ry aW5ncyBvZiBxdWVyeQrCoMKgIG5hbWVzLsKgIFRoZSBpbnRlbnQgb2YgQlVMSyBpcyB0byBzaW1w bGlmeSBnZW5lcmljIGFzc2lnbm1lbnRzIGluIGEKwqDCoCBtZW1vcnktZWZmaWNpZW50IHdheSB0 aGF0IGNhbiBiZSBlYXNpbHkgc2hhcmVkIGJldHdlZW4gdGhlIHByaW1hcnkKwqDCoCBhbmQgc2Vj b25kYXJ5IG5hbWVzZXJ2ZXJzIGZvciBhIHpvbmUuCgoKVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXdvb2R3b3J0aC1idWxrLXJyLwoKVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVy c2lvbnMgYXZhaWxhYmxlIGF0OgpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd29v ZHdvcnRoLWJ1bGstcnItMDcKaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k cmFmdC13b29kd29ydGgtYnVsay1yci0wNwoKQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNp b24gaXMgYXZhaWxhYmxlIGF0OgpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtd29vZHdvcnRoLWJ1bGstcnItMDcKCgpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uCnVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu CgpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 CmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpETlNPUCBtYWlsaW5nIGxpc3QKRE5TT1BAaWV0 Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnNvcAoK ----_com.samsung.android.email_1495243731058980 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48Zm9udCBmYWNlPSJzYW5zLXNlcmlm Ij5IZWxsbyw8L2ZvbnQ+PGRpdj48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIiBkaXI9ImF1dG8iPjxi cj48L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIiBkaXI9ImF1dG8iPlRo aXMgZHJhZnQgd2FzIHJlbGVhc2VkIGEgY291cGxlIHdlZWtzIGFnbyBhbmQgaW5jbHVkZXMgd2hh dCB3ZSBmZWVsIGFyZSBzb21lIHZlcnkgbm90ZXdvcnRoeSBjaGFuZ2VzLjwvZm9udD48L2Rpdj48 ZGl2Pjxmb250IGZhY2U9InNhbnMtc2VyaWYiIGRpcj0iYXV0byI+PGJyPjwvZm9udD48L2Rpdj48 ZGl2Pjxmb250IGZhY2U9InNhbnMtc2VyaWYiIGRpcj0iYXV0byI+UGxlYXNlIHRha2UgYW5vdGhl ciBsb29rIHdoZW4geW91IGhhdmUgdGltZSwgYXMgYWx3YXlzIHdlIGxvb2sgZm9yd2FyZCB0byBh bmQgd2VsY29tZSBhbnkgcXVlc3Rpb25zLyBjb21tZW50cy48L2ZvbnQ+PC9kaXY+PGRpdj48Zm9u dCBmYWNlPSJzYW5zLXNlcmlmIiBkaXI9ImF1dG8iPjxicj48L2ZvbnQ+PC9kaXY+PGRpdj5JIGFt IGRpc2FwcG9pbnRlZCBJIHdhcyB1bmFibGUgdG8gam9pbiB0aGUgZ3JvdXAgaW4gU2luZ2Fwb3Jl IGJ1dCBhbSBvcHRpbWlzdGljIEknbGwgYmUgYWJsZSB0byBtZWV0IGFnYWluIGluIExvbmRvbi48 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rcyw8L2Rpdj48ZGl2 PkpvaG48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xv cjojMDAwMDAwIj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAw Ij48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAwIj48L2Rpdj48 ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVz c2FnZSAtLT48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2 PkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvZGl2PjxkaXY+U3ViamVjdDogW0ROU09Q XSBJLUQgQWN0aW9uOiBkcmFmdC13b29kd29ydGgtYnVsay1yci0wNy50eHQgPC9kaXY+PGRpdj48 YnI+PC9kaXY+PC9kaXY+PGJyPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+VGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgRG9tYWluIE5hbWUgU3lzdGVtIE9wZXJhdGlvbnMgV0cgb2Yg dGhlIElFVEYuPGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVGl0bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgOiBCVUxLIEROUyBSZXNvdXJjZSBSZWNvcmRzPGJyPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBdXRob3JzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogSm9obiBXb29kd29ydGg8YnI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERlYW4gQmFsbGV3PGJyPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTaGFzaHdhdGggQmluZGluZ2FuYXZlbGkgUmFnaGF2YW48 YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhdmlkIEMgTGF3cmVuY2U8 YnI+CUZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDog ZHJhZnQtd29vZHdvcnRoLWJ1bGstcnItMDcudHh0PGJyPglQYWdlcyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDE2PGJyPglEYXRl Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDogMjAxNy0xMC0zMDxicj48YnI+QWJzdHJhY3Q6PGJyPiZuYnNwOyZuYnNwOyBU aGUgQlVMSyBETlMgcmVzb3VyY2UgcmVjb3JkIHR5cGUgZGVmaW5lcyBhIG1ldGhvZCBvZiBwYXR0 ZXJuLWJhc2VkPGJyPiZuYnNwOyZuYnNwOyBjcmVhdGlvbiBvZiBETlMgcmVzb3VyY2UgcmVjb3Jk cyBiYXNlZCBvbiBudW1lcmljIHN1YnN0cmluZ3Mgb2YgcXVlcnk8YnI+Jm5ic3A7Jm5ic3A7IG5h bWVzLiZuYnNwOyBUaGUgaW50ZW50IG9mIEJVTEsgaXMgdG8gc2ltcGxpZnkgZ2VuZXJpYyBhc3Np Z25tZW50cyBpbiBhPGJyPiZuYnNwOyZuYnNwOyBtZW1vcnktZWZmaWNpZW50IHdheSB0aGF0IGNh biBiZSBlYXNpbHkgc2hhcmVkIGJldHdlZW4gdGhlIHByaW1hcnk8YnI+Jm5ic3A7Jm5ic3A7IGFu ZCBzZWNvbmRhcnkgbmFtZXNlcnZlcnMgZm9yIGEgem9uZS48YnI+PGJyPjxicj5UaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd29vZHdvcnRoLWJ1bGstcnIvPGJyPjxicj5UaGVy ZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PGJyPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13b29kd29ydGgtYnVsay1yci0wNzxicj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXdvb2R3b3J0aC1idWxrLXJyLTA3PGJy Pjxicj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJy Pmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13b29kd29ydGgtYnVsay1y ci0wNzxicj48YnI+PGJyPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+dW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+PGJy PkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8 YnI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88YnI+PGJyPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPkROU09QIG1haWxpbmcgbGlz dDxicj5ETlNPUEBpZXRmLm9yZzxicj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Ruc29wPGJyPjxicj48L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_1495243731058980-- From nobody Mon Nov 20 00:38:03 2017 Return-Path: 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 B166A1294C7 for ; Mon, 20 Nov 2017 00:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 GBs9ToSf4SPw for ; Mon, 20 Nov 2017 00:37:57 -0800 (PST) Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBBF1294B9 for ; Mon, 20 Nov 2017 00:37:56 -0800 (PST) Received: from [5.254.79.66] (helo=[127.0.0.1]) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1eGhcq-00028T-Iv for dnsop@ietf.org; Mon, 20 Nov 2017 08:40:21 +0000 To: dnsop@ietf.org References: From: Shane Kerr Message-ID: Date: Mon, 20 Nov 2017 08:37:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-isp-ip6rdns X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 08:37:59 -0000 All, Paul Hoffman: > > On 16 Nov 2017, at 20:12, Lee Howard wrote: > >> I updated this draft months ago, based on feedback from the previous >> WGLC, >> and it expired without comment. I’ve refreshed it, and would like to ask >> again for reviews (especially if anything has changed in the past >> year) and >> another WGLC. >> >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/ > > This version seems fine, even without specific recommendations. From the > earlier discussion in the WG, it doesn't seem like there is agreement on > recommendations, and the draft covers the methods that could be used in > enough detail where an operator can decide what they want to do. I also think this version is fine (probably I said so on an early review call). Frankly I'm kind of mystified that it doesn't move forward, as having ANY recommendations for operators on how to deal with this problem seems better than none - and indeed I think this document is about 15 years late. :( Cheers, -- Shane From nobody Mon Nov 20 02:52:17 2017 Return-Path: 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 67E34129530 for ; Mon, 20 Nov 2017 02:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 kVR4oG1afsAl for ; Mon, 20 Nov 2017 02:52:14 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747B41294FF for ; Mon, 20 Nov 2017 02:52:14 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id DC59B6A25F; Mon, 20 Nov 2017 11:52:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by open-xchange.com (Postfix) with ESMTP id D05CD3C1C3E; Mon, 20 Nov 2017 11:52:12 +0100 (CET) Received: from open-xchange.com ([127.0.0.1]) by localhost (imap.open-xchange.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGm49tix-2TH; Mon, 20 Nov 2017 11:52:12 +0100 (CET) Received: from [192.168.0.23] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id B199B3C1829; Mon, 20 Nov 2017 11:52:12 +0100 (CET) From: "Peter van Dijk" To: dnsop Date: Mon, 20 Nov 2017 11:52:12 +0100 Message-ID: <4E17A3CE-FB79-4946-96D5-9F6495A4594C@powerdns.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: [DNSOP] FOSDEM 2018 DNS devroom CfP X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 10:52:16 -0000 Hello DNS-enthusiasts and other developers, (the text below has also been posted at https://blog.powerdns.com/2017/11/20/fosdem-2018-dns-devroom-cfp/ and if anything changes, we'll update that post, so please check there if you have questions. Also, our apologies if you receive multiple copies of this CfP via different mailing lists.) After two successful BoF sessions at FOSDEM 2016 and 2017, FOSDEM 2018 will see a real DNS devroom! We hope to host talks anywhere from hardcore protocol stuff, to practical sessions for programmers that are not directly involved with DNS but may have to deal with DNS in their day to day coding, or system administrators responsible for DNS infrastructure. We have been allotted half a day on Sunday 4 February 2018. We expect to schedule 30 minutes per talk, including questions, but this is open to discussion. If you have something you'd like to share with your fellow developers, please head to pentabarf at https://penta.fosdem.org/submission/FOSDEM18. Examples of topics are measuring, monitoring, DNS libraries, and anecdotes on how you've (ab)used the DNS. The deadline for submission is December 8th. If you have a FOSDEM pentabarf account from a previous year, please use that account. Reach out to dns-devroom-manager@fosdem.org if you run into any trouble. We are also looking for volunteers to help with cameras etc. Please drop us an email at dns-devroom-manager@fosdem.org if you're interested in helping out. See you there! Cheers, Peter van Dijk, Shane Kerr, Pieter Lexis From nobody Mon Nov 20 05:10:50 2017 Return-Path: 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 B044812783A for ; Mon, 20 Nov 2017 05:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 6n-LsrgyPD_y for ; Mon, 20 Nov 2017 05:10:47 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 7648812702E for ; Mon, 20 Nov 2017 05:10:47 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:39570) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eGlqW-000bpm-04 (Exim 4.89) (return-path ); Mon, 20 Nov 2017 13:10:44 +0000 Date: Mon, 20 Nov 2017 13:10:43 +0000 From: Tony Finch To: Jacob Hoffman-Andrews , dnsop WG In-Reply-To: <20171118211000.GR3322@mournblade.imrryr.org> Message-ID: References: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org> <20171118211000.GR3322@mournblade.imrryr.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Error handling in CAA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 13:10:50 -0000 Viktor Dukhovni wrote: > On Fri, Nov 17, 2017 at 12:49:33PM -0800, Jacob Hoffman-Andrews wrote: This is a topic of operational interest to me :-) I previously posted about CAA checks and private domains at: https://lists.dns-oarc.net/pipermail/dns-operations/2017-September/016752.html Our CA has updated their implementation to issue certs if (I am told) "a lookup error is returned (like a SERVFAIL from an internal DNS server) AND the domain does not have a valid DNSSEC signature (or a parent domain does not have valid DNSSEC)." I hope that by "valid DNSSEC signature" they actually mean signed DS RRset, but I have not tested their new behaviour. We have worked around this problem by making a public empty view for our private subdomain, so the fix comes a bit too late to help us. (And it turns out there are other advantages to our workaround.) The other entertaining CAA checking bug was due to checkers getting in loops when CNAMEs closer to the root point at subdomains of themselves - https://twitter.com/fanf/status/915936787171807237 Viktor's message has lots of sound advice, though I have one correction: > This language really should have been much more clear. In particular, > the last item warrants clarification. It is critical that the CA > determine the lack of a validation chain in a robust manner. The > simplest approach: > > * Request the SOA record of the domain. If this lookup fails, > (ServFail, Timeout, ...) stop, the domain's DNSSEC status is > unknown. No, you need to lookup the domain's DS records to determine its DNSSEC status. Apart from that I agree with Viktor's points. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fair Isle, Faeroes: Northeast veering east 4 or 5, occasionally 6 later. Moderate or rough. Wintry showers, rain later. Good occasionally poor. From nobody Mon Nov 20 08:26:43 2017 Return-Path: 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 A9FF7129BD8 for ; Mon, 20 Nov 2017 08:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 Czb9eJAF6zCS for ; Mon, 20 Nov 2017 08:26:41 -0800 (PST) Received: from mail.hardakers.net (unknown [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8B3129BCE for ; Mon, 20 Nov 2017 08:26:40 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 441E624BEF; Mon, 20 Nov 2017 08:26:40 -0800 (PST) From: Wes Hardaker To: Michael StJohns Cc: Bob Harold , Matthijs Mekking , IETF DNSOP WG References: Date: Mon, 20 Nov 2017 08:26:40 -0800 In-Reply-To: (Michael StJohns's message of "Fri, 17 Nov 2017 08:55:18 +0000") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] 5011-security-considerations and the safetyMargin X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 16:26:42 -0000 Michael StJohns writes: > 1 something. I think that the consensus is clearly something like that. Are you (MSJ) interested in supplying a suggested final equation for it? -- Wes Hardaker USC/ISI From nobody Mon Nov 20 08:29:15 2017 Return-Path: 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 0F076129BD1 for ; Mon, 20 Nov 2017 08:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com 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 jSd6PZSt6f_o for ; Mon, 20 Nov 2017 08:29:12 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BED2129B73 for ; Mon, 20 Nov 2017 08:29:12 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id x63so7296395wmf.4 for ; Mon, 20 Nov 2017 08:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zw+njDr+O5DqlVtlWLN900Ez/FeIXEi2ToacHFxorrw=; b=j+YPnw7aZf+W4IGAiEI9vaZoxVCAB4vxIF/gR0y58GvUN2jkvvt0v61i2pn+gPBVB/ UOjBCfxNW1G9IKn72kBQ98zPnNf+COPJTgjPj6Mrc76Y+IS1lRW2OoHlaweYSoYLenKk yPslCq8/fm4kmgMmu+ZlAMYpv5QfXUItBO7lnM/Pu37T/cLuwgCSOzf6X3O3QrPWIHPL NjaZOtBDR9J/sObH1pqGvnuNB1rr+oIF3Y4dLbkooCSMOzu0KDWo8XvoZLf1vlUiunX8 WSBk4DPQ4pVczqz2NEZIqbVWYzKY1IY6N1UdPOvP9lRH7VLDlSwj1o6jY6+Wo2GbqyxL L0uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zw+njDr+O5DqlVtlWLN900Ez/FeIXEi2ToacHFxorrw=; b=KNEpN6A6sd3/8S8BNkKbdosrHFH6U49bizAZ912Tz00iaFj/4sB3lrqsHFKvQQOIxy tY2wLZqaAA3ToozMVc/4jPi9HlKmaynjc8Ha66DIRYTKKt0POhx7MO6dReD7WMFH+Mgf R8VMTqx0SFJDSt3YqlSZpMvGSGdJlU9IPnYHejmKdmZue+j5qdK6rKVUkRJ+ly0RGhWv jT+SX0Y/TgzTuh+zc8Nz0ja9fB/8Ka+XSco1nxuLB24urJqxK8rpO8xIBl8MB6bnA7iH vt1Zw+XYzNgdWR4YYkmjpzfTyH3V6dJKifbtYoJbAByXMcweyVArOlkEVhWvBfzWPdcn VFdg== X-Gm-Message-State: AJaThX6y1DOv2EtlJrYaSUsh3a7eSY0xRqGW/JaIK9S+gB8NZpwq1TCV 9so8aZHG6KQA9sVGDo3i2uBCB+kpNSgfIY7IqjzWig== X-Google-Smtp-Source: AGs4zMb6QWqMo6poJ8oQnAGxUzNVTzHjg14/iSzj35RgQE4JKZWgwS8m4/P8nEblc+gW7S94hJFmeGZcIo/WPKNi1II= X-Received: by 10.28.155.200 with SMTP id d191mr12080244wme.31.1511195350926; Mon, 20 Nov 2017 08:29:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Michael StJohns Date: Mon, 20 Nov 2017 16:29:00 +0000 Message-ID: To: Wes Hardaker Cc: Bob Harold , IETF DNSOP WG , Matthijs Mekking Content-Type: multipart/alternative; boundary="001a1144f650143200055e6c9629" Archived-At: Subject: Re: [DNSOP] 5011-security-considerations and the safetyMargin X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 16:29:14 -0000 --001a1144f650143200055e6c9629 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m running the math right now to see what works. Give me a few da= ys. Mike On Mon, Nov 20, 2017 at 11:26 Wes Hardaker wrote: > Michael StJohns writes: > > > 1 something. > > I think that the consensus is clearly something like that. Are you > (MSJ) interested in supplying a suggested final equation for it? > > -- > Wes Hardaker > USC/ISI > --001a1144f650143200055e6c9629 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80=99m running the math right now to see what w= orks.=C2=A0 Give me a few days. =C2=A0 Mike

On Mon, Nov 20, 2017 at 11:26 Wes Hardaker <wjhns1@hardakers.net> wrote:
Michael StJohns <msj@nthpermutation.com> writes:

> 1 something.

I think that the consensus is clearly something like that.=C2=A0 Are you (MSJ) interested in supplying a suggested final equation for it?

--
Wes Hardaker
USC/ISI
--001a1144f650143200055e6c9629-- From nobody Mon Nov 20 11:47:56 2017 Return-Path: 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 D509C120713 for ; Mon, 20 Nov 2017 11:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com 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 bsoIIQUp0HLh for ; Mon, 20 Nov 2017 11:47:53 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD2712EA8D for ; Mon, 20 Nov 2017 11:47:52 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id r39so16157197qtr.13 for ; Mon, 20 Nov 2017 11:47:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=QGlog9L5crfjXjG6wMpCysXJB8P55XQT/XgIs23C2Gg=; b=NuQXhsqqyxvhBR3lGorWj8+uhOnmpOYdGmgqllFv6hBIQqWiC5AA2eXPHH9b5AutgH mniJ1fwYE7H863MvWUUNe97p505xdBuRRiR1uhvJdTt2Ooozlrms4fbDEgAAs6CRrVF6 hKx7IBUFhkz71a3tO+CWewAuRm/OarTGVFELhJRG9JmU0BvhZeQan8tRM430a4QdJH1l Bbbl0SrWzcdY6bnbj4ZXlakODA3taFrL4r2oCj86zfxdnrZ3yIvhWXa8f8UyhtEPcrbk fS4EnMc0E2aVhNqvXLcKBxoJnI7o5LYfBlM8HU9sZB5dSgyqdw9tK2eSVtQBTJC2E7pb ObWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=QGlog9L5crfjXjG6wMpCysXJB8P55XQT/XgIs23C2Gg=; b=jEqlIKe6m4YwnhDHdsSh4G04zOSOSYh10QGyK0yW3b0t7xoIh/pFpebpeFFtB1TmKd Nk8YsRmgUYQEBfzK7N29tQgtd9Itq+vDNjyybX9wxqfSo18ypmBQSQ7EXLqiJD0jaGP9 Z8sdmR3E6dshV3fD8ZVmolJ33rXjjSJWAOEYHWvhk0d4oCpc6Rw0LZoMjQ0HWtNH62/h ipm/fv1eBKwfaibR1RVLEDEF9/xeM2suV72/6frXkwHvaJ01z07bQjAkPEwp670z96ji BsBMgo+uTE1AAzGorVnVOPGDsoN+Mzm0OPlqyZpDbf3ByZlD9zpLnzf7OUbz9KXvOVf9 OMOw== X-Gm-Message-State: AJaThX4WS7pXWsxqsmEIqXioNuhPtvsGWxXgBnia68u9T2OpbMRi+k6+ 1P5Ub1AAGyS+N7p0LDIGCKbC0PQM X-Google-Smtp-Source: AGs4zMbUYjaCWwOV9zftdFOQszrt4SAOOy9C2feta20q1G/fgKeAk//hJDK/fv5x0E3PHU7ukFsVsw== X-Received: by 10.200.26.33 with SMTP id v30mr22391266qtj.250.1511207271396; Mon, 20 Nov 2017 11:47:51 -0800 (PST) Received: from [192.168.1.117] (c-69-140-114-191.hsd1.md.comcast.net. [69.140.114.191]) by smtp.gmail.com with ESMTPSA id v51sm7654628qtb.7.2017.11.20.11.47.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 11:47:50 -0800 (PST) To: Wes Hardaker Cc: IETF DNSOP WG References: From: Michael StJohns Message-ID: <53d210a2-b4dc-f2ce-33a8-4964cba64c4c@nthpermutation.com> Date: Mon, 20 Nov 2017 14:47:48 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------55DAEDF6F9807F7410D88CCB" Content-Language: en-US Archived-At: Subject: Re: [DNSOP] 5011-security-considerations and the safetyMargin X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 19:47:55 -0000 This is a multi-part message in MIME format. --------------55DAEDF6F9807F7410D88CCB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/20/2017 11:26 AM, Wes Hardaker wrote: > Michael StJohns writes: > >> 1 something. > I think that the consensus is clearly something like that. Are you > (MSJ) interested in supplying a suggested final equation for it? > Ok - after thinking about it, it turns out to be fairly simple. 1) Initially, ignore the outliers - the servers that are down and will be down throughout the entire safety period.  It's probable that most of them were down during the original uptake period. 2) Assume a success rate of p per retry.  I'm going to use .01 - or for each retry period only 1 of 100 entities completes the last query. 3) Calculate Log.x(M) where M is the number of clients - arbitrarily chosen at 10M and where x is (1/(1-p)) - the failure rate (or put another way, the proportion of servers still waiting to complete after the previous retry interval).  Log.x(M) gives the number of intervals to reduce the set of uncompleted servers to 0 assuming normal probability. That gives you 1603 fast retry intervals.   Setting p and M to different values gets you a range of answers: Number of Resolvers 10,000 100,000 1,000,000 10,000,000 100,000,000 Probability of Success Per Retry Interval 0.01 916.4212 1145.526 1374.632 1603.737 1832.84231 0.05 179.5623 224.4528 269.3434 314.23397 359.12454 0.1 87.41738 109.2717 131.1261 152.98042 174.834763 0.15 56.67242 70.84052 85.00862 99.176728 113.344832 0.25 32.01569 40.01961 48.02354 56.027459 64.0313822 0.5 13.28771 16.60964 19.93157 23.253497 26.5754248 0.9 4 5 6 7 8 (Think of it this way.  Pretend you have 1000 resolvers and each has a 10% chance of completing in each interval.  After the first interval, 900 are left.  After the second 810, after the third...729 etc.  Ignoring rounding you need about 65 retries to get down to < 1 left which is Log1.11111(1000). This doesn't account for the servers who are offline, but see (1) above for why its probably safe to ignore them. So a publisher can pick an M and x (or p) that is their best guess from the data they have and calculate: safetyInterval ::=  Log.x(M) * fastRetryInterval Or simply make some worst case assumptions (.01 success rate, 10M clients) and use a number from the table. Mike --------------55DAEDF6F9807F7410D88CCB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/20/2017 11:26 AM, Wes Hardaker wrote:
Michael StJohns <msj@nthpermutation.com> writes:


1 something.

I think that the consensus is clearly something like that.  Are you
(MSJ) interested in supplying a suggested final equation for it?


Ok - after thinking about it, it turns out to be fairly simple.


1) Initially, ignore the outliers - the servers that are down and will be down throughout the entire safety period.  It's probable that most of them were down during the original uptake period.

2) Assume a success rate of p per retry.  I'm going to use .01 - or for each retry period only 1 of 100 entities completes the last query.

3) Calculate Log.x(M) where M is the number of clients - arbitrarily chosen at 10M and where x is (1/(1-p)) - the failure rate (or put another way, the proportion of servers still waiting to complete after the previous retry interval).  Log.x(M) gives the number of intervals to reduce the set of uncompleted servers to 0 assuming normal probability.

That gives you 1603 fast retry intervals.   Setting p and M to different values gets you a range of answers:
Number of Resolvers

  10,000 100,000 1,000,000 10,000,000 100,000,000
Probability of Success Per Retry Interval 0.01 916.4212 1145.526 1374.632 1603.737 1832.84231
0.05 179.5623 224.4528 269.3434 314.23397 359.12454
0.1 87.41738 109.2717 131.1261 152.98042 174.834763
0.15 56.67242 70.84052 85.00862 99.176728 113.344832
0.25 32.01569 40.01961 48.02354 56.027459 64.0313822
0.5 13.28771 16.60964 19.93157 23.253497 26.5754248
0.9 4 5 6 7 8


(Think of it this way.  Pretend you have 1000 resolvers and each has a 10% chance of completing in each interval.  After the first interval, 900 are left.  After the second 810, after the third...729 etc.  Ignoring rounding you need about 65 retries to get down to < 1 left which is Log1.11111(1000).

This doesn't account for the servers who are offline, but see (1) above for why its probably safe to ignore them. 

So a publisher can pick an M and x (or p) that is their best guess from the data they have and calculate:

safetyInterval ::=  Log.x(M) * fastRetryInterval

Or simply make some worst case assumptions (.01 success rate, 10M clients) and use a number from the table.


Mike



--------------55DAEDF6F9807F7410D88CCB-- From nobody Tue Nov 21 07:13:51 2017 Return-Path: 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 298071294B5 for ; Tue, 21 Nov 2017 07:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 eMdR_KL2zdND for ; Tue, 21 Nov 2017 07:13:47 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C31211294BD for ; Tue, 21 Nov 2017 07:13:47 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 21 Nov 2017 07:13:45 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 21 Nov 2017 07:13:45 -0800 From: Edward Lewis To: "dnsop@ietf.org" Thread-Topic: One review of draft-huston-kskroll-sentinel-04.txt Thread-Index: AQHTYttSrJ/bE43XFUq/BTHAuey91w== Date: Tue, 21 Nov 2017 15:13:45 +0000 Message-ID: <802F3877-2156-4C2C-A7D2-9D996381E8D2@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3594104024_1353469530" MIME-Version: 1.0 Archived-At: Subject: [DNSOP] One review of draft-huston-kskroll-sentinel-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 15:13:50 -0000 --B_3594104024_1353469530 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit A review of: https://tools.ietf.org/html/draft-huston-kskroll-sentinel-04 This is not a blow-by-blow, nit picking review, but tries to dive into archtecture level issues: 1. I don't think the Root Zone should be specifically called out, this mechanism ought to work for any domain name. The Intro has an example: ## store. In particular, this response mechanism can be used to ## determine whether a certain Root Zone KSK is ready to be used as a ## trusted key within the context of a key roll by this resolver. As an example, sure, but there seems to be the confusion that "the root is special" when it comes to the management of trust anchors, that notion, that any name is special, ought to be put to rest. Not all deployments of the DNS protocol need to have the same namespace, I used to work with an operational inter-network with its own "everything". The Root Zone is mentioned in a few places in the document, I haven't seen that it needs to be "called out" for this proposal, whatever the final result is, it should work anywhere in any DNS tree. 2. Need to reserve labels according to regular expression All labels matching <_is-ta-*> and <_not-ta-*> would have to be reserved to prevent a collision with a configured name. As we don't know the future key tags we have to clear them all out. For the root zone, that's a swath of TLDs. The same is true for all names (the root is not special!) where some validator has a trust anchor. (That raises an interesting point - how does a zone operator know whether their zone apex is considered to be a point of trust? This is an open link when thinking of Automated Updates of DNSSEC Trust Anchors as a protocol between two entities.) There is no in-DNS-band indication by a zone administrator that they expect to implement timings compatible with STD 69, a trust anchor manager needs out of band indications (and updates). Note that we don't have a protocol definition for matching "partial" labels. Yes, that's a problem. 3. Structure of the draft The draft covers two things - the query/response protocol and the use of the results in a test. This I find confusing: ## 3. Sentinel Processing ## ## This proposed test that uses the DNS resolver mechanism described in Until I got to that line, I was expecting that this document covered only the query/response protocol. I'll structure the rest of the review into "query/response" and then "use of that in testing." 4. The query/response protocol I'm a little unclear, from the description, what is happening at the query/response level. Let's say (for the sake of this email), I want to ask whether my resolver (which is a fuzzy statement) has a trust anchor for example.com, key_id=0x4034. I would then send a query for (_is-ta-4034{*}.example.com./IN/A), flags CD off and EDNS option DO, and expect a response of either: -1. A response with a return code of SERVFAIL (value=2), which would imply that either the responder is saying "no" to the trust anchor status of the key or that there is data matching the query but it has either failed DNSSEC validation or the servers authoritative for the name could not (ultimately) be reached. -2. A positive response with data, indicating that the responder treated this as a normal query and happened to have query-matching data to return. -3. A negative response, either a name error (return code=NXDOMAIN) or an empty answer section, indicating the queried name exists and has other data. In either case, the responder is treating the query as "normal." -4. An indication that the key is held as trusted by the responder. This is where I'm lost - what is returned? The draft says: ## ..., then the resolver should return a response indicating ## that the response contains authenticated data according to section ## 5.8 of [RFC6840]. ... Dereferencing the pointer, there's mumbo-jumbo about the AD bit value in the response. Perhaps my confusion begins here, in earlier text in "Sentinel Mechanism": ## If the outcome of the DNS response validation process indicates that ## the response is authentic, and if the left-most label of the original ## query name matches the template "_is-ta-.", then the DNSSEC validation is not performed on responses, it is performed on RRsets. DNSSEC does not check the headers, does not make a blanket statement over the sections (answer, authority, etc.), does not cover the EDNS stuff (OPT record in the additional), etc. This sentinel mechanism has to have an answer, and it be signed (up to some trust anchor on the responder) for there to be validation. Would this be an IP address (v4/v6 for A/AAAA as appropriate)? What would that address be, given this is not meant to "flow data"? (127.0.0.1/8 for IPv4, IPv6 only has ::1/128 for local.) For the negative case, I'm more at sea. For _not-ta-1111.example.com. to be able to return a set that DNSSEC validation can approve there would need to be a - as yet not defined - wildcard that matches prefixes of labels. There would have to be fake address records for _not-ta-*.example.com. for all values that didn't match held trust anchors. Again, with the validator determining the existence of a trust anchor and not the authority, this is hard to generate at the zone administration's DNSSEC signing time. One factor not covered is the setting of the recursion desired bit, and this might be useful. By clearing the RD bit (RD=0), the responder ought to be consulting only it's local information. For responders unaware of this feature, they'd only consult their local cache, which ought to never have an entry for the queried name (expecting that the authority neither configures the name, with or without a delegation, nor has a wildcard). With a cleared RD bit in the query handled by a responder that is aware of this mechanism, the answer would be something generated from data in the responder's trust anchor data store. For a positive response to a positive query (i.e., yes to _is-ta-*) if something is to be sent back signed, a valid signature is needed. For a negative response to a positive query, ... I don't know. What if the query/response relies on having RD=0 in the query, hoping the responder does not send the query onward (recursion or forwarding), and we use some form of transaction security (like TSIG) for hop-by-hop security? For unaware responders, they'd treat the query as one for an address record. Unless there's a matching name in the cache, they'd never return a data set. Quick check: BIND 9.9.5 returns a referral to the root, unbound 1.5.8 responds with return code of REFUSED. Different answers from different implementations, hmmm, would make this a bit more difficult. To me, the basics of the query/response mechanism aren't very clear, an example would certainly help. (And not one sitting at the root!) Consider how the flags in the response might be used - particularly the recursion desired bit. 5. The "test" In the sense of "walk before you crawl", start with the description of queries and responses to specific targets as a network manager would do. To accurately use the results, one would need to know the specifics of DNS query husbandry in place. This is something only the network manager could know. First, target at an IP address. There may be one or more responders. There could be a load balancer before a number of independent processes answering on port 53. There could be an anycast constellation of servers with some routing instability. TSIG could be used to "secure" the exchange. Next, any single end-consumer of DNS services will likely have a list of IP addresses to target. The different IP addresses may have different network managers running the DNS service (i.e., some do DNSSEC validation, some don't, some have special trust anchors, etc.). That would lead to uncertainty in trying to "convert symptoms into a diagnosis." There are two ways to test. One assumes that the tester is the manager, one with knowledge of the layout. A significant ingredient is that the tester, in this case, would have a list of IP addresses to specifically ask, knowing the use of anycast and load balancing. The other assumes that it is an end-user view, one that does not have the list of IP addresses to target, does not have knowledge of the layout, and is only able to have a black-box (opaque) view of the DNS as a service. For the former, with a well-designed query/response mechanism, scripts can be written to verify that configurations are as expected. Managing anycast deployments could use "service addresses" or an appropriately distributed monitoring source network. Load balancers can be handled too. (Eliding ways of doing that.) And TSIG is an option (for security). For the latter, which I infer is the ultimate intent of the draft, that is, to estimate when a (as opposed to "the") Root Zone KSK rollover (being specific here to the root zone on the global public Internet) can proceed. There's been experience here, leading to the notion that the results would give a coarse approximation in aggregate, as the way in which DNS recursion is done is quite complex. Given that the goal is to measure the trust anchors configured in individual validation engines via testing of units that see the DNS as a black box service, a coarse approximation is all we can hope for - that that this is bad but we have to begin to evaluate where the returns diminish. Summary - The document has a laudable goal. The first suggestion is to structure it in layers. Clean up the query/response section to describe the footwork of the effort, I'd suggest experimenting with the idea of using RD=0, and figuring out what a trust anchor store can originate as a response (as the response is not originating from the administration authoritative for the name). When it comes to the use of the footwork, divide this into how a network manager could incorporate this into a trust anchor maintenance activity and then into a more widespread, third-party, measurement of trust anchor deployment. Other considerations, well beyond the scope of the subject line's document - revamp the Automated Updates of DNSSEC Trust Anchors from a validator-side mechanism into a two-party protocol, with the goal of increased manageability (monitoring, measurement) and, as something not yet raised, more efficient in sizes of network responses (e.g., make MISSING an expected state and then manage around that). --B_3594104024_1353469530 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTi0B5+fdAMnN4s43if4khx5NrwPDAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMjExNTEzNDRaMA0GCSqGSIb3 DQEBAQUABIIBABEr9i5vZT2IFt6r/AHBPhIttWgHP0BcS6xbo67rxeXyqYoP6j3PoApvEurO 60YQUtFXZqpiQv3VPTFIZONt/Xyob5YCaVgWQUWI0bJ499l/jiI8jkGY6S87bqAIBj+E5IFk F8winxOSz+zyCXbDrQvrVT4/a9KzT5IfwPZr58O5JQ7pfgHDmEh4aYiWZvc40wq7Lvp+CNpT ICgUrbnbyzYSAL+u8InEfeAGZRxNQJMVxSI4MD0+18UAUC26HpxzsBMcRYDctBGA7c5FDN+l euYP+jPdO9mhg4I2bpCLWbNmC3h2bvzHcpLQ804Pn0x4LEWoUb0hFGPsPpsp31I7ooM= --B_3594104024_1353469530-- From nobody Tue Nov 21 08:32:20 2017 Return-Path: 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 49D89126D46 for ; Tue, 21 Nov 2017 08:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 fQkTnFpUuAbW for ; Tue, 21 Nov 2017 08:32:16 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 C9D8D129571 for ; Tue, 21 Nov 2017 08:32:15 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 11AB9281BF5 for ; Tue, 21 Nov 2017 17:32:14 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 0C5F4281C05; Tue, 21 Nov 2017 17:32:14 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 059EB281BF5 for ; Tue, 21 Nov 2017 17:32:14 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 0330C663EBE0 for ; Tue, 21 Nov 2017 17:32:14 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id EC2FC3FE26; Tue, 21 Nov 2017 17:32:13 +0100 (CET) Date: Tue, 21 Nov 2017 17:32:13 +0100 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20171121163213.xhy4d3cowf6u7f47@nic.fr> References: <20171112012835.GA16257@laperouse.bortzmeyer.org> <20171114073227.GO3322@mournblade.imrryr.org> <3b429f8e-1046-e70d-ab9f-0ac4ba735232@time-travellers.org> <20171114084725.GP3322@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171114084725.GP3322@mournblade.imrryr.org> X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.020362, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.11.21.162417 Archived-At: Subject: Re: [DNSOP] About draft-ietf-dnsop-extended-error X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 16:32:18 -0000 On Tue, Nov 14, 2017 at 08:47:25AM +0000, Viktor Dukhovni wrote a message of 27 lines which said: > > RCODE: SUCCESS (NODATA) > > Extended code: ERRBLACKLIST > > Explanation: "Client blacklisted for IPv6 queries" > > Well, once we're in the "lying with DNS" business, we hardly need > to restrict extended diagnostics to errors, we can equally contemplate > them for policy-based answers that don't reflect the authoritative > zone content... :-8 May be you were joking but I'm serious and I think it would be a good idea. For instance, extended "error" codes for "This is not the real IP address, I lied to protect you from malware/pedoporn/terrorism" would be very useful (see RFC 7725). From nobody Tue Nov 21 12:54:11 2017 Return-Path: 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 590EB129BCD for ; Tue, 21 Nov 2017 12:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 y2mk32-z7UQm for ; Tue, 21 Nov 2017 12:54:05 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4D221270AC for ; Tue, 21 Nov 2017 12:54:04 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 171E67A330A; Tue, 21 Nov 2017 20:54:04 +0000 (UTC) Date: Tue, 21 Nov 2017 20:54:04 +0000 From: Viktor Dukhovni To: dnsop WG Message-ID: <20171121205403.GT3322@mournblade.imrryr.org> Reply-To: dnsop@ietf.org References: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org> <20171118211000.GR3322@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [DNSOP] Error handling in CAA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 20:54:06 -0000 On Mon, Nov 20, 2017 at 01:10:43PM +0000, Tony Finch wrote: > Viktor's message has lots of sound advice, though I have one correction: > > > This language really should have been much more clear. In particular, > > the last item warrants clarification. It is critical that the CA > > determine the lack of a validation chain in a robust manner. The > > simplest approach: > > > > * Request the SOA record of the domain. If this lookup fails, > > (ServFail, Timeout, ...) stop, the domain's DNSSEC status is > > unknown. > > No, you need to lookup the domain's DS records to determine its DNSSEC > status. Actually, I chose my recommendation of SOA lookup after some thought and with care. A domain may have no DS records, and yet be signed because it is not a (delegated) zone apex domain. Furthermore, an SOA query elicts data from the domain itself, not the parent, and thus ensures that any published DS records up the tree yield working signatures for records in the zone containing the domain. If the SOA lookup fails, then the domain is severely broken beyond just "stoopid" blocking of CAA and other "novel" RRtypes, and so there is no reason for the CA to be "forgiving" of such errors. (Not that I have much sympathy for domains where CAA lookups fail but other lookups do not, they really should feel some pain to fix their DNS). So I stand by the advice to issue "SOA" queries, they are far simpler to implement correctly (without having to chase DS records up the tree, cross check them against NS records, ...) and they yield more useful information, namely whether: * A domain has working "insecure" DNS * A domain has working "secure" DNS * A domains is broken, and needs attention before CAA status can be determined or ignored. -- Viktor. From nobody Tue Nov 21 13:00:45 2017 Return-Path: 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 4B693127076 for ; Tue, 21 Nov 2017 13:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JYC9SqcNAOSZ for ; Tue, 21 Nov 2017 13:00:42 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA8A126BF6 for ; Tue, 21 Nov 2017 13:00:42 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id g104so11769047otg.7 for ; Tue, 21 Nov 2017 13:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=Yn2ksl0VfQAFkQg7HC1AdfcqX6aRHiIx+TH5R3FjkV4=; b=SUwegZJh9Q3Po2tNcm/squNP0sfgYhxVubp/zVoYyHi4naGM+cBalIbV5AKLBDYDnw xemTGVGtZTkkQiBYyfCA2eKOXonctN69wdcPMI+lP/LmzjmXUFv1uBpD/R2t6yjD9HZR DHulU4Wyp19xL0B0vVkUtmksBkUJXlQ02Q5nQk1k+ZSUfxf0X/iaFI7R7NlCl1kaVmjY ZZfJ2AJtc4gvqWmTp2yi23X27sev+SvnqMPMn4G422DikutRTI1OjZRAmEzHcQ/Bbr00 JZAEbE+isa79BNgpNq0CoxiwIWV6ucqj/RkIXomAkhSQaP85/tmLroExf+8ZlrrYRa4b tTBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=Yn2ksl0VfQAFkQg7HC1AdfcqX6aRHiIx+TH5R3FjkV4=; b=nbqgFg0lEgWpFmDGXBgb5KusfWfTzgPF7tuI5VLefwYgjID/mLe7qRKLoV7/tlwIq8 UKEun1h3OaNgtkvrOHF2/a6PcSqy7k0qNnxnDktjrkD11iDIvuWdeclzxeN2wv50gKGI LhQoJz0cadmk/vjhHrOLzorbZJK6B2RD0wEgDD7we9hOP4XjFROH45sBwcpBT01Mbii+ EeDxNJV0OfJT9vYY8ilz8UYgRfHMT2/o739IsGrcUG2aR4epNx2qmOlQWVzDy6EDZsO1 UAUypqkL94Cj6xgWUchpv51IxqCrP5etsBdb5vMm15E7Yi7PEutQco2pCU8k38LDqHSk XS6w== X-Gm-Message-State: AJaThX40FgfMMQGy1hD3NsSsRFDeOGNGygj2CLkNGbpbMv3pGD00PhHM wBxjY8YshJbjlHPnsRwaZN7ncdSrkSLa32d5/60= X-Google-Smtp-Source: AGs4zMYbpS9NdyUEpS7VjlckNX3DCshxZHl0g9pr9etpIWjoUlV42oJWgci1+5HPCRhvRbBHQSCmrPZ9z9JTxhNzUrY= X-Received: by 10.157.91.97 with SMTP id e30mr12526355otj.196.1511298041122; Tue, 21 Nov 2017 13:00:41 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.66.145 with HTTP; Tue, 21 Nov 2017 13:00:40 -0800 (PST) In-Reply-To: <20171121205403.GT3322@mournblade.imrryr.org> References: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org> <20171118211000.GR3322@mournblade.imrryr.org> <20171121205403.GT3322@mournblade.imrryr.org> From: Phillip Hallam-Baker Date: Tue, 21 Nov 2017 16:00:40 -0500 X-Google-Sender-Auth: jR99c4ArstDyuPENgao0jG5tnN4 Message-ID: To: dnsop@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Error handling in CAA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 21:00:43 -0000 On Tue, Nov 21, 2017 at 3:54 PM, Viktor Dukhovni wrote: > On Mon, Nov 20, 2017 at 01:10:43PM +0000, Tony Finch wrote: > >> Viktor's message has lots of sound advice, though I have one correction: >> >> > This language really should have been much more clear. In particular, >> > the last item warrants clarification. It is critical that the CA >> > determine the lack of a validation chain in a robust manner. The >> > simplest approach: >> > >> > * Request the SOA record of the domain. If this lookup fails, >> > (ServFail, Timeout, ...) stop, the domain's DNSSEC status is >> > unknown. >> >> No, you need to lookup the domain's DS records to determine its DNSSEC >> status. > > Actually, I chose my recommendation of SOA lookup after some thought > and with care. A domain may have no DS records, and yet be signed > because it is not a (delegated) zone apex domain. Furthermore, an > SOA query elicts data from the domain itself, not the parent, and > thus ensures that any published DS records up the tree yield working > signatures for records in the zone containing the domain. > > If the SOA lookup fails, then the domain is severely broken beyond > just "stoopid" blocking of CAA and other "novel" RRtypes, and so > there is no reason for the CA to be "forgiving" of such errors. > (Not that I have much sympathy for domains where CAA lookups fail > but other lookups do not, they really should feel some pain to fix > their DNS). > > So I stand by the advice to issue "SOA" queries, they are far > simpler to implement correctly (without having to chase DS records > up the tree, cross check them against NS records, ...) and they > yield more useful information, namely whether: > > * A domain has working "insecure" DNS > * A domain has working "secure" DNS > * A domains is broken, and needs attention before CAA status > can be determined or ignored. If the domain is broken, validation is going to fail as well. Which may prove a useful cut. From nobody Wed Nov 22 04:09:57 2017 Return-Path: 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 9F1F0129415 for ; Wed, 22 Nov 2017 04:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 I81dRJ9GgFqM for ; Wed, 22 Nov 2017 04:09:53 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 BBA7A12940C for ; Wed, 22 Nov 2017 04:09:53 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:50223) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eHTqh-0011E0-32 (Exim 4.89) for dnsop@ietf.org (return-path ); Wed, 22 Nov 2017 12:09:51 +0000 Date: Wed, 22 Nov 2017 12:09:51 +0000 From: Tony Finch To: dnsop WG In-Reply-To: <20171121205403.GT3322@mournblade.imrryr.org> Message-ID: References: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org> <20171118211000.GR3322@mournblade.imrryr.org> <20171121205403.GT3322@mournblade.imrryr.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Error handling in CAA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 12:09:55 -0000 Viktor Dukhovni wrote: > > > No, you need to lookup the domain's DS records to determine its DNSSEC > > status. > > Actually, I chose my recommendation of SOA lookup after some thought > and with care. A domain may have no DS records, and yet be signed > because it is not a (delegated) zone apex domain. Furthermore, an > SOA query elicts data from the domain itself, not the parent, and > thus ensures that any published DS records up the tree yield working > signatures for records in the zone containing the domain. OK I thought you meant to query for the SOA of the zone containing the CAA domain, and I meant to query for the closest enclosing negatively or positively resolvable DS. The CAA search has to walk the DNS tree anyway, so finding the closest enclosing DS is a similar kind of process. > If the SOA lookup fails, then the domain is severely broken No, it might just be private. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Tyne, Dogger, Fisher, German Bight, Humber, Thames: South or southwest 6 to gale 8, occasionally severe gale 9 except Tyne. Rough or very rough, occasionally very high for a time in Biscay. Rain or showers. Good, occasionally poor. From nobody Wed Nov 22 13:30:16 2017 Return-Path: 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 C8E8D124B18 for ; Wed, 22 Nov 2017 13:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5E5gWYS7gCGl for ; Wed, 22 Nov 2017 13:30:13 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FE612957C for ; Wed, 22 Nov 2017 13:30:13 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 005727A330A; Wed, 22 Nov 2017 21:30:11 +0000 (UTC) Date: Wed, 22 Nov 2017 21:30:11 +0000 From: Viktor Dukhovni To: dnsop WG Message-ID: <20171122213011.GU3322@mournblade.imrryr.org> Reply-To: dnsop@ietf.org References: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org> <20171118211000.GR3322@mournblade.imrryr.org> <20171121205403.GT3322@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [DNSOP] Error handling in CAA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 21:30:15 -0000 On Wed, Nov 22, 2017 at 12:09:51PM +0000, Tony Finch wrote: > > If the SOA lookup fails, then the domain is severely broken > > No, it might just be private. We are not using the same (mine is correct :-) definition of failure. An NXDomain reply is not a lookup failure. The security status of the domain is available regardless of whether we get NoError with some answers, NoError with no answers (aka NoData) or NXDomain. A private sub-domain should return NXDomain on the public side of the Internet, with that answer signed or not based on the security status of the parent zone. Having the query ServFail is where of course you run into trouble. My recommended algorithm for CAA probing is that any (really, as in ServFail, ...) failed CAA probe be accompanied by an SOA probe for the *same* domain. If the SOA probe succeeds (including NXDomain), and is signed, then: * Signed NXDomain is sufficient to conclude that CAA does not exist either * Signed NODATA is sufficient to conclude that the zone is signed and CAA lookup failure must not be ignored. * Ditto for a signed SOA RRset. If the SOA probe succeeds (including NXDomain), and is not signed, then: * Unsigned NXDomain is sufficient to conclude (sans DNSSEC) that CAA does not exist either. * Unsigned NODATA is sufficient to conclude that the zone is not signed and persistent CAA failure might eventually be ignored (sparing the domain owner the pain signal they need to take important corrective action, perhaps not a good idea). * Ditto for unsigned SOA RRset. If the SOA lookup (really) fails, then the domain is broken. Any non-public sub-domains that want certificates, should not be broken in this way. Either appear in the public DNS, return NXDomain or NODATA. A wildcard CAA record might in fact be a good way to present a non-public subtree to the outside world: internal.example.com. IN CAA ... *.internal.example.com. IN CAA ... -- Viktor. From nobody Thu Nov 23 03:19:51 2017 Return-Path: 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 D0BE51287A5 for ; Thu, 23 Nov 2017 03:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oyPBGwZd1dm8 for ; Thu, 23 Nov 2017 03:19:47 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:eeb1:d7ff:fe59:fbaa]) by ietfa.amsl.com (Postfix) with ESMTP id D380C12878D for ; Thu, 23 Nov 2017 03:19:46 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id C999843E9D3 for ; Thu, 23 Nov 2017 12:19:43 +0100 (CET) Date: Thu, 23 Nov 2017 12:19:43 +0100 (CET) Message-Id: <20171123.121943.1115399549648860645.he@uninett.no> To: dnsop@ietf.org From: Havard Eidnes X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 11:19:50 -0000 Hi, draft 07 says: Primary master: "The primary master is named in the zone's SOA MNAM= E field and optionally by an NS RR". (Quoted from [RFC1996], Section 2.1). [RFC2136] defines "primary master" as "Master server at the root of the AXFR/IXFR dependency graph. The primar= y master is named in the zone's SOA MNAME field and optionally by a= n NS RR. There is by definition only one primary master server per= zone." The idea of a primary master is only used by [RFC2136], and is considered archaic in other parts of the DNS. First: the last sentence's claim that the idea of a "primary master" is only used by RFC 2136 is surely incorrect. It is also used in RFC 1996, where the first quote is taken from. Secondly: can someone please explain to me why the idea of a "primary master" where the zone data originates from and where updates are performed is considered archaic? Best regards, - H=E5vard From nobody Thu Nov 23 05:26:03 2017 Return-Path: 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 CDA9C12426E for ; Thu, 23 Nov 2017 05:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 m2B6c29qSwgW for ; Thu, 23 Nov 2017 05:26:00 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 166FA120046 for ; Thu, 23 Nov 2017 05:26:00 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:57424) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eHrVt-000iJv-1N (Exim 4.89) for dnsop@ietf.org (return-path ); Thu, 23 Nov 2017 13:25:57 +0000 Date: Thu, 23 Nov 2017 13:25:57 +0000 From: Tony Finch To: dnsop WG In-Reply-To: <20171122213011.GU3322@mournblade.imrryr.org> Message-ID: References: <3e958c19-016f-b413-78c5-4fd3c7c41daa@eff.org> <20171118211000.GR3322@mournblade.imrryr.org> <20171121205403.GT3322@mournblade.imrryr.org> <20171122213011.GU3322@mournblade.imrryr.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Error handling in CAA X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 13:26:02 -0000 Viktor Dukhovni wrote: > A private sub-domain should return NXDomain on the public side of > the Internet, Maaaaaybe. That (mostly) requires that DNS servers support views. Obviously in practice, private zones and views are often used together, but DNS purists have also argued that that you don't need views to have private zones (and that is how private.cam.ac.uk was set up). But purism has disadvantages: REFUSED queries to private domains from the public Internet cause retries and traffic amplification so there are non-CAA-related advantages to having a public NXDOMAIN view. Even so, I know that at least one CA has received enough complaints from customers with REFUSED private domains that they have already updated their implementation to permit certificates in unresolvable zones that lack DNSSEC. It worked before CAA and I don't think there's any particular advantage to breaking it. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Faeroes, Southeast Iceland: Northerly backing northwesterly gale 8 to storm 10. Very rough or high, occasionally very high in north. Squally wintry showers. Moderate or poor. From nobody Thu Nov 23 06:00:30 2017 Return-Path: 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 57186128DE5 for ; Thu, 23 Nov 2017 06:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com 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 0hQJIpT3OI-1 for ; Thu, 23 Nov 2017 06:00:25 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A146D128D8B for ; Thu, 23 Nov 2017 06:00:25 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id 79so19156584ioi.3 for ; Thu, 23 Nov 2017 06:00:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OHJU5l5nvOhmGzPDc2ca5EPd2Dm7ots0BYIPWgA005Q=; b=OQoM7AkhZrSj1zc4RepLXZ4LdAE4itSMtWcf5B/0vJSpzmPW+Fg8GtHrQS2Z+buUXx tXW8Ez5tvW5J4FMTo0ovzKj18rJr5gjqnrKbcjxldM4krZXYBTdGmHOT2otRHetUYj6Q AWACoWOXvOl4NcHmPVTkS6BtaBCpTdTlXJaX8Ox0qQz7BQvA/upg5Hm6LMRIGfJVWURS sa0h7MQlroPlyZ+V55gOTLLr16MDubt4HxRTqTUpjMkGVc4/4/KFFTDBUo9MxFaEQFBb 2ipnpnx/RRz2kl/Ofz19IYWVcZL5huwhib/i74Uxuo70byHIvJvqA5V3X2ZgcwnKoEJ/ frTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OHJU5l5nvOhmGzPDc2ca5EPd2Dm7ots0BYIPWgA005Q=; b=tM2Fo3wRyh/CKKNW5sJZlJMVx34GKeWMdqEcRVscbXAu/aE9UCWwYvLmuVRGlmwMpk pSGvsu2MdQzv9sS3phREvzEe2n1PEu6NAdcRziJgjOoou1pIWNEB/GbVUXHerqFDLk5K ope4Lx9A9HfferOmX9C2JjhKu7vZyodkoVHFlHPHdYByZM/nt3jHy+geArJ+x5YOBv/5 gvf8DTSA5GRJWv0rYlUU9QG94YnzEHuY9FcpUhTH4IP8SSFEf8BxhEmiRhw+wx1kdhmU 7KR84Pt7eUiDQGKA16Kps0XihZLE8Zqj4hQVt9k3lEKgOGdmjKQRClqn4hJ5jizzza1L hd+w== X-Gm-Message-State: AJaThX5NKy/NSl+6D7FP85NHySUpjlQosVO8yjqAy8DuQaWPY8F0+6dX f6W8w4bgFMVs4s7lKP56vQh2nYuQwn9sGQ4rUhLox4+k X-Google-Smtp-Source: AGs4zMYjUBFWYWqmwmqJt52oN+A7SqZYNymAKbDSIlyFxrJVWLhUo+j7iO7vOfOmdb1/oYws4QQYZgAJCxkGjN5Ujv8= X-Received: by 10.107.15.19 with SMTP id x19mr26336933ioi.7.1511445624771; Thu, 23 Nov 2017 06:00:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.181.188 with HTTP; Thu, 23 Nov 2017 06:00:24 -0800 (PST) In-Reply-To: <20171123.121943.1115399549648860645.he@uninett.no> References: <20171123.121943.1115399549648860645.he@uninett.no> From: Matthew Pounsett Date: Thu, 23 Nov 2017 09:00:24 -0500 Message-ID: To: Havard Eidnes Cc: dnsop Content-Type: multipart/alternative; boundary="001a113f1bac8fef67055ea6dbb6" Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 14:00:28 -0000 --001a113f1bac8fef67055ea6dbb6 Content-Type: text/plain; charset="UTF-8" On 23 November 2017 at 06:19, Havard Eidnes wrote: > Hi, > > draft 07 says: > > Primary master: "The primary master is named in the zone's SOA MNAME > field and optionally by an NS RR". (Quoted from [RFC1996], > Section 2.1). [RFC2136] defines "primary master" as "Master > server at the root of the AXFR/IXFR dependency graph. The primary > master is named in the zone's SOA MNAME field and optionally by an > NS RR. There is by definition only one primary master server per > zone." The idea of a primary master is only used by [RFC2136], > and is considered archaic in other parts of the DNS. > > First: the last sentence's claim that the idea of a "primary > master" is only used by RFC 2136 is surely incorrect. It is also > used in RFC 1996, where the first quote is taken from. > I think the intent of the text is that an name is only used by the protocol in RFC 2136. It is referenced as a concept in RFC 1996, but not used by the protocol. But I agree that the text above is confusing, and if that's the intent then it should be rewritten. > > Secondly: can someone please explain to me why the idea of a > "primary master" where the zone data originates from and where > updates are performed is considered archaic? > That doesn't make sense to me either. Perhaps somebody thinks that Update messages are no longer in use? --001a113f1bac8fef67055ea6dbb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 23 November 2017 at 06:19, Havard Eidnes <he@uninett.no> = wrote:
Hi,

draft 07 says:

=C2=A0 =C2=A0Primary master:=C2=A0 "The primary master is named in the= zone's SOA MNAME
=C2=A0 =C2=A0 =C2=A0 field and optionally by an NS RR".=C2=A0 (Quoted = from [RFC1996],
=C2=A0 =C2=A0 =C2=A0 Section 2.1).=C2=A0 [RFC2136] defines "primary ma= ster" as "Master
=C2=A0 =C2=A0 =C2=A0 server at the root of the AXFR/IXFR dependency graph.= =C2=A0 The primary
=C2=A0 =C2=A0 =C2=A0 master is named in the zone's SOA MNAME field and = optionally by an
=C2=A0 =C2=A0 =C2=A0 NS RR.=C2=A0 There is by definition only one primary m= aster server per
=C2=A0 =C2=A0 =C2=A0 zone."=C2=A0 The idea of a primary master is only= used by [RFC2136],
=C2=A0 =C2=A0 =C2=A0 and is considered archaic in other parts of the DNS.
First: the last sentence's claim that the idea of a "primary
master" is only used by RFC 2136 is surely incorrect.=C2=A0 It is also=
used in RFC 1996, where the first quote is taken from.

I think the intent of the text is that an name is only used= by the protocol in RFC 2136.=C2=A0 It is referenced as a concept in RFC 19= 96, but not used by the protocol.=C2=A0 But I agree that the text above is = confusing, and if that's the intent then it should be rewritten.
<= div>=C2=A0

Secondly: can someone please explain to me why the idea of a
"primary master" where the zone data originates from and where updates are performed is considered archaic?

That doesn't make sense to me either.=C2=A0 Perhaps somebody thin= ks that Update messages are no longer in use?


=

--001a113f1bac8fef67055ea6dbb6-- From nobody Thu Nov 23 06:24:47 2017 Return-Path: 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 96A211293FD for ; Thu, 23 Nov 2017 06:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 UFPxq6MWxbXk for ; Thu, 23 Nov 2017 06:24:40 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 3E149129407 for ; Thu, 23 Nov 2017 06:22:36 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:989f:72ff:fe12:ee49] (unknown [IPv6:2001:1488:fffe:6:989f:72ff:fe12:ee49]) by mail.nic.cz (Postfix) with ESMTPSA id 4847863E07 for ; Thu, 23 Nov 2017 15:22:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1511446954; bh=ToGAdYXJxve3lT2ZseNxXTktaKg6sEIOnjI+4UTcHQc=; h=To:From:Date; b=sk0NsN8HJhyfYDlJ7fGvGBjg2gJLOwgny0SZjqN5M1+poI8IxgGoW4m2FBbPWzTcb ppCsiaSHLK+q7pxUiZPkdj0SapprSvMdJXV12ojSUgXmu0ZY/4SV3FJ/SMYlGDYnMx M2/KQOzpihRuKUnsdB+wTMGE8z5BKQTwVJAP5+NM= To: dnsop@ietf.org References: <20171123.121943.1115399549648860645.he@uninett.no> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <911f70e1-aa25-17d6-93fc-55e8c352aec6@nic.cz> Date: Thu, 23 Nov 2017 15:22:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 14:24:46 -0000 On 23.11.2017 15:00, Matthew Pounsett wrote: > On 23 November 2017 at 06:19, Havard Eidnes > wrote: > > Hi, > > draft 07 says: > >    Primary master:  "The primary master is named in the zone's SOA MNAME >       field and optionally by an NS RR".  (Quoted from [RFC1996], >       Section 2.1).  [RFC2136] defines "primary master" as "Master >       server at the root of the AXFR/IXFR dependency graph.  The primary >       master is named in the zone's SOA MNAME field and optionally by an >       NS RR.  There is by definition only one primary master server per >       zone."  The idea of a primary master is only used by [RFC2136], >       and is considered archaic in other parts of the DNS. > > First: the last sentence's claim that the idea of a "primary > master" is only used by RFC 2136 is surely incorrect.  It is also > used in RFC 1996, where the first quote is taken from. > > > I think the intent of the text is that an name is only used by the > protocol in RFC 2136.  It is referenced as a concept in RFC 1996, but > not used by the protocol.  But I agree that the text above is confusing, > and if that's the intent then it should be rewritten. >   > > > Secondly: can someone please explain to me why the idea of a > "primary master" where the zone data originates from and where > updates are performed is considered archaic? > > > That doesn't make sense to me either.  Perhaps somebody thinks that > Update messages are no longer in use? Not really, many Microsoft Active Directory instances have integrated DNS and it uses DNS update to keep client machine's record up-to-date. What is "archaic" is probably concept of primary master, because big systems often have multi-master architecture (AD, or FreeIPA to name an open-source one). -- Petr Špaček @ CZ.NIC From nobody Thu Nov 23 08:12:14 2017 Return-Path: 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 2A87412EB55 for ; Thu, 23 Nov 2017 08:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 keCav0kbkW8e for ; Thu, 23 Nov 2017 08:12:11 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 32F7912EB4E for ; Thu, 23 Nov 2017 08:12:11 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 1858A2826A9; Thu, 23 Nov 2017 17:12:09 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 12A4C28299B; Thu, 23 Nov 2017 17:12:09 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 0BF902826A9; Thu, 23 Nov 2017 17:12:09 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 090076423520; Thu, 23 Nov 2017 17:12:09 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id F1DF33FE23; Thu, 23 Nov 2017 17:12:08 +0100 (CET) Date: Thu, 23 Nov 2017 17:12:08 +0100 From: Stephane Bortzmeyer To: Dave Lawrence Cc: dnsop@ietf.org Message-ID: <20171123161208.wlpuagz54mcpyd3q@nic.fr> References: <20171113020736.ga7rzgst2hurb56h@mx4.yitter.info> <5A09068A.3030206@redbarn.org> <20171113032640.tbn7icsllm6jeeny@mx4.yitter.info> <5A09C4D6.6080202@redbarn.org> <20171114063209.gjubqyovnwcrl33a@mx4.yitter.info> <5A0A952F.1060001@redbarn.org> <20171114080638.GA41253@isc.org> <5A0AA777.9010908@redbarn.org> <20171114175300.GA45323@isc.org> <23051.41140.187552.962508@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23051.41140.187552.962508@gro.dd.org> X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.003696, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.11.23.160316 Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 16:12:13 -0000 On Tue, Nov 14, 2017 at 09:04:36PM -0500, Dave Lawrence wrote a message of 17 lines which said: > I'd be surprised to see REFUSED from a resolver. % dig +norec @9.9.9.9 A www.afnic.fr ; <<>> DiG 9.10.3-P4-Debian <<>> +norec @9.9.9.9 A www.afnic.fr ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 4022 ;; flags: qr ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; Query time: 6 msec ;; SERVER: 9.9.9.9#53(9.9.9.9) ;; WHEN: Thu Nov 23 17:11:30 CET 2017 ;; MSG SIZE rcvd: 12 :-) From nobody Thu Nov 23 08:13:19 2017 Return-Path: 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 54BA412EB4D for ; Thu, 23 Nov 2017 08:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 a7wI77orghLV for ; Thu, 23 Nov 2017 08:13:12 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4850812EB56 for ; Thu, 23 Nov 2017 08:13:12 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id d21so4872888ioe.7 for ; Thu, 23 Nov 2017 08:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8/rsdpqDq0NEaKsCU09c4pO09vFvVc+BmlZt3YnIbOQ=; b=cb/Ijam6OlSZt/Jk4/e2vZPepwStQuF7a3sJmxvJAJwTCF2jJ/QmR4R6gtxV+GJWj+ K6ifRQIMuO8wa6klsnfm2qCZr8VgZyESEfSBcFInLDMciMbd7Ho2j+xFPWw9jC7mop2G S/mtMKurs6sMt9n4em3w7SSyjD/RhkaVYVnuQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8/rsdpqDq0NEaKsCU09c4pO09vFvVc+BmlZt3YnIbOQ=; b=S2dfsJZEwsc73wJrbC23TjI+BhC86TKgj9d3oCRa4X+uXfhvf/XJUDumCjtlohWDMf CmxQa5lzSEyVK38vOOTC1IvgMGQih7/gZ4TeXb2SIb16uk4Wl51wbsiY908QTq0HVzyv e9qofTsS4X4MIasJpoL1ytjqVEe1xlGoK1GvZUsUJqV+QtVSd8hoyGdNhF+BBDGhiqM8 1ZbhNfq1SEDaT7ISq/IrOX8/5IMa5FYlIp65Lxk+s6U784hzaE2nmtvN7BhP7/0SxFMT tfX2u9Eh/li5RERh7bhLAG60m46ChkedetYLP0Kv3K8/DST+3GuTMz8EW1/UPP13tuHh a/xA== X-Gm-Message-State: AJaThX6ihYSYGyHsjUeK5BhYR9Vexd24ggo/q0Gtud2O7Bm85/d5nZnn P7ityRjKq/c3gFWfStjwpo3sp4qgImo= X-Google-Smtp-Source: AGs4zMbQMn4OquG4K5R8xeqN6MoaIOO3zAr8GLuZNE+B0bJwBXo1Ift2AM4Gtj8Q72sq2sS1mw4c9g== X-Received: by 10.107.178.145 with SMTP id b139mr27563551iof.52.1511453591245; Thu, 23 Nov 2017 08:13:11 -0800 (PST) Received: from [199.212.90.68] (23-233-21-69.cpe.pppoe.ca. [23.233.21.69]) by smtp.gmail.com with ESMTPSA id g79sm3487058itb.29.2017.11.23.08.13.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Nov 2017 08:13:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (15B202) In-Reply-To: <20171123.121943.1115399549648860645.he@uninett.no> Date: Thu, 23 Nov 2017 11:13:09 -0500 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> References: <20171123.121943.1115399549648860645.he@uninett.no> To: Havard Eidnes Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 16:13:18 -0000 On Nov 23, 2017, at 06:19, Havard Eidnes wrote: > Secondly: can someone please explain to me why the idea of a > "primary master" where the zone data originates from and where > updates are performed is considered archaic? I think the only in-protocol use of the MNAME field is to specify the name t= o which UPDATE messages are sent. The MNAME was originally used to specify t= he name of a single master server to which slaves would send zone transfer r= equests, and from which zone data would be served in response, but as far as= I am aware this was only ever informational: that is, I'm not aware of any i= mplementation of a slave server that automatically detected its master by lo= oking for the MNAME. Today I think it's fair to say that any non-trivial DNS deployment that uses= zone transfers makes use of a non-trivial graph for distribution of zone tr= ansfers, with slaves configured to send zone transfer requests to more than o= ne master server, and in many cases with layers of servers that act as slave= s and masters simultaneously for reasons of redundancy and scaling. While a single slave sending zone transfer requests to a single master is st= ill a valid example of such a graph, I think it's more a degenerate case tha= n the usual case today. In that sense the idea of using a single master (whi= ch I think is implied by "primary master" and a name published in a single M= NAME field) is defensibly archaic. My perspective may not be universal, of course, but that's what I see. Joe= From nobody Thu Nov 23 08:36:46 2017 Return-Path: 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 2D5F412EB87 for ; Thu, 23 Nov 2017 08:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PiACRN00b7He for ; Thu, 23 Nov 2017 08:36:42 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:eeb1:d7ff:fe59:fbaa]) by ietfa.amsl.com (Postfix) with ESMTP id DDAE912EB8B for ; Thu, 23 Nov 2017 08:36:41 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 55C7243E9D3; Thu, 23 Nov 2017 17:36:40 +0100 (CET) Date: Thu, 23 Nov 2017 17:36:40 +0100 (CET) Message-Id: <20171123.173640.212705919866092469.he@uninett.no> To: jabley@hopcount.ca Cc: dnsop@ietf.org From: Havard Eidnes In-Reply-To: <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 16:36:45 -0000 >> Secondly: can someone please explain to me why the idea of a >> "primary master" where the zone data originates from and where >> updates are performed is considered archaic? > = > I think the only in-protocol use of the MNAME field is to > specify the name to which UPDATE messages are sent. Really? I read the NOTIFY RFC (1996) so that if the MNAME name server is included in the NS set, it will by default be excluded from receiving NOTIFY messages from the other name servers when they reload the zone, ref. the definition of "Notify set" in RFC 1996. Unsurprisingly, BIND has code to do this: result =3D dns_name_dup(&soa.origin, zone->mctx, &master); ... /* * Process NS RRset to generate notifies. */ ... /* * Don't notify the master server unless explicitly * configured to do so. */ if (!DNS_ZONE_OPTION(zone, DNS_ZONEOPT_NOTIFYTOSOA) && dns_name_compare(&master, &ns.name) =3D=3D 0) { result =3D dns_rdataset_next(&nsrdset); continue; } Regards, - H=E5vard From nobody Thu Nov 23 08:48:11 2017 Return-Path: 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 B5D1C12EBB7 for ; Thu, 23 Nov 2017 08:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 qzkMVCz1S9Id for ; Thu, 23 Nov 2017 08:48:08 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCD412EBAC for ; Thu, 23 Nov 2017 08:48:07 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id x63so27113759ioe.6 for ; Thu, 23 Nov 2017 08:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iicMTLOeKjbpj78gfqHlCpm60lSZcZObEEzXfZGTaeI=; b=SxZ5O1KgVIVfrSHqXj0CdntZ/qXZp43mnWFtgGUrEcdg6wp71C65KEP9G6Qa52zkws 6RozOmgr1vjoPH7Ns13NLwE5rpM6dlhBpxtR7jKLRC14lcVf1lc3psFNSWcSULgKwsQm xZsx2D8KP5Kt5VG+l5NH1Pi+vY/e4DYk7XZIg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iicMTLOeKjbpj78gfqHlCpm60lSZcZObEEzXfZGTaeI=; b=keBIjAz4hYWmbuS8BAfG7YZ1OKSmQkVC663645Z990B5pZYY49Qoar+YlWdxWXmIfI 8TmIpfE3C+RiU7coQV+iSr9xrgno0/oVY3kxlyPZerdBGyznGxozBIqXgfp788FoXTti ez/PAR4Sz0FbSiAKHKzyZ2oiGAcDmA0wUw2+RqjhY3fPVK+3k8gUCBWA0DZAICvhynM+ jVS7aSDWhCmNlMcDkKsgDhOXqqA91BCNG+KgoIzrJecZVWGl9HTGYyOKPfkgfiFTgiiM I704IY0H2DXXvx7JCJZUq6A86Sc69jAbLOkCQz9elQEXPPqpauM0WN2FL/pB6f8tDuGm Li6g== X-Gm-Message-State: AJaThX7jSxuxIEHvwgmCwYIwsQUMoy4U4ZqrMMxqCg5QSRbwtqvNJz2R MLnSxLXrZCb5ow03rPFu0tHsM89khgE= X-Google-Smtp-Source: AGs4zMaTwVS87OgHhKCJ52v+6C3tWiUqxfYKJ7+mYl05y0DXMYLZjWSt1BqeXrwmNsmMmZAWHY2UcA== X-Received: by 10.107.84.1 with SMTP id i1mr12074083iob.261.1511455686069; Thu, 23 Nov 2017 08:48:06 -0800 (PST) Received: from ?IPv6:2607:f2c0:101:3:5d27:93f8:4cd8:b33c? ([2607:f2c0:101:3:5d27:93f8:4cd8:b33c]) by smtp.gmail.com with ESMTPSA id u127sm7894649ioe.28.2017.11.23.08.48.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Nov 2017 08:48:04 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (15B202) In-Reply-To: <20171123.173640.212705919866092469.he@uninett.no> Date: Thu, 23 Nov 2017 11:48:03 -0500 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <984203DA-C2FA-4971-906D-CD17399698F8@hopcount.ca> References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> <20171123.173640.212705919866092469.he@uninett.no> To: Havard Eidnes Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 16:48:10 -0000 Hi H=C3=A5vard, On Nov 23, 2017, at 11:36, Havard Eidnes wrote: >>> Secondly: can someone please explain to me why the idea of a >>> "primary master" where the zone data originates from and where >>> updates are performed is considered archaic? >>=20 >> I think the only in-protocol use of the MNAME field is to >> specify the name to which UPDATE messages are sent. >=20 > Really? I read the NOTIFY RFC (1996) so that if the MNAME name > server is included in the NS set, it will by default be excluded > from receiving NOTIFY messages from the other name servers when > they reload the zone, ref. the definition of "Notify set" in RFC > 1996. Oh, good catch! I did not even know that text was there. I stand corrected! That doesn't change the wider opinion I was trying to describe, though: in t= he modern/transfer graph scenario I was painting, NOTIFY configuration is fa= r more nuanced than as described in RFC1996 and in practice (in BIND parlanc= e) is an automatically-managed set of also-notify configuration. Joe= From nobody Thu Nov 23 09:44:55 2017 Return-Path: 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 BC3681300E8 for ; Thu, 23 Nov 2017 09:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 hmsW-XSVChn2 for ; Thu, 23 Nov 2017 09:44:52 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 202291300E7 for ; Thu, 23 Nov 2017 09:44:51 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:35558) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eHvYP-000iT4-2v (Exim 4.89) (return-path ); Thu, 23 Nov 2017 17:44:49 +0000 Date: Thu, 23 Nov 2017 17:44:49 +0000 From: Tony Finch To: Joe Abley cc: Havard Eidnes , dnsop@ietf.org In-Reply-To: <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> Message-ID: References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 17:44:54 -0000 Joe Abley wrote: > > In that sense the idea of using a single master (which I think is > implied by "primary master" and a name published in a single MNAME > field) is defensibly archaic. It's quite difficult to have multiple masters and DNSSEC and coherent copies of the zone from all masters - i.e. more effort than just spinning up parallel instances of BIND or Knot in automatic signing mode. The downstream xfer clients will get horribly muddled if you don't spend the effort to ensure the masters are generating the same zone data for the same serial numbers. Easier to have one primary master which can be replaced quickly. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fair Isle, Faeroes: Northwest 7 to severe gale 9, occasionally storm 10. Very rough or high. Squally wintry showers. Good, occasionally poor. From nobody Thu Nov 23 10:16:33 2017 Return-Path: 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 1810E124D6C for ; Thu, 23 Nov 2017 10:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IAzUWD0xlRvr for ; Thu, 23 Nov 2017 10:16:30 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E8C11200C5 for ; Thu, 23 Nov 2017 10:16:30 -0800 (PST) Received: from [172.31.98.14] (unknown [4.35.165.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id EF7AF61FA2; Thu, 23 Nov 2017 18:16:28 +0000 (UTC) Message-ID: <5A171079.8010401@redbarn.org> Date: Thu, 23 Nov 2017 10:16:25 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Joe Abley CC: dnsop@ietf.org References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> In-Reply-To: <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 18:16:32 -0000 Joe Abley wrote: > On Nov 23, 2017, at 06:19, Havard Eidnes wrote: >... > While a single slave sending zone transfer requests to a single > master is still a valid example of such a graph, I think it's more a > degenerate case than the usual case today. In that sense the idea of > using a single master (which I think is implied by "primary master" > and a name published in a single MNAME field) is defensibly archaic. you need to get out more. by zone count, the IETF methodolody dominates the field. microsoft's AD approach, and other multi-master approaches, are used by the big guys, but they do not handle most zones. > My perspective may not be universal, of course, but that's what I see. this mailing list demonstrates the same myopia on many topics, as if a lack of evidence is itself evidence of nonexistence. that's just not so. -- P Vixie From nobody Thu Nov 23 10:34:59 2017 Return-Path: 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 40D07129480 for ; Thu, 23 Nov 2017 10:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 LwxBlzBGFQjI for ; Thu, 23 Nov 2017 10:34:57 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD11E126C3D for ; Thu, 23 Nov 2017 10:34:56 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id c188so15446845lfd.5 for ; Thu, 23 Nov 2017 10:34:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=/r8EGT758toF+86Y87Zo9sa2tOezgerkla9jzO35LVE=; b=ZELCs6PcedMCfz74JEekg0EAanbfeOLnCGmbTt1ITeCTVfuySr18W/qN0/0+bHvOLo WxfoDzqtNDCSN+sDxGFUwWPsMC2pFjAQTiLFl3f0w1Td4neoJ1hWsGwJxLWdRud0rqCc vTHjyL2lcMpHjxEWj1GPAV8KUjrO9Y4lDX8/g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc; bh=/r8EGT758toF+86Y87Zo9sa2tOezgerkla9jzO35LVE=; b=gDspguMYRyhdJVj3BI9pLrfHWL610yQkZ+dtekXbxfKDkvPROYNwS5AkIxQQBtbBbh JCoCVbA0C+Lr3myAxWpM7p/L3SNdtdrYoGRkSHau373yfaa7p2S7paiNvC0r072Rk2dp 2SWGzEVklNyF+c/rc7DEpW+I2Bwwg0e7XRq973VWZtxcHhAoLUng0mCBn7VgmLM9XdEM XgaYHMC5+tE6aYTEz4mDfHncGlYwLk/xRLo/77jENP1R6VrWEKvGJTPV18UxLfDKvPs4 r4gpIplrF1jhZOxcpesj/BUhVdxu26+LgGW5goNh6N4auESvTk3U8c7+ZQcwM6IzuH+O UXwQ== X-Gm-Message-State: AJaThX5nFrcGu41o24F7MHnPhK7tG7RsQn13DvAA7ZTP/b47tvgmNwzm AasZFpBuVd27OX7zcZBq7doEmOWGcxhfr5foPj99Vg== X-Google-Smtp-Source: AGs4zMbEtBFtoAIso5G1zTEzFk77mTNwn+sCfsrWmssvb1IZ+SZQ97gPB6n3V4ED4cnRhjiJebURnYSuLPfCH52tWfk= X-Received: by 10.46.116.9 with SMTP id p9mr7951378ljc.28.1511462094988; Thu, 23 Nov 2017 10:34:54 -0800 (PST) From: Joe Abley Mime-Version: 1.0 (1.0) References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> In-Reply-To: Date: Thu, 23 Nov 2017 13:34:53 -0500 Message-ID: <5562271920774233970@unknownmsgid> To: Tony Finch Cc: Havard Eidnes , "dnsop@ietf.org" Content-Type: multipart/alternative; boundary="089e0827bc8c4379cf055eaab1a0" Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 18:34:58 -0000 --089e0827bc8c4379cf055eaab1a0 Content-Type: text/plain; charset="UTF-8" On Nov 23, 2017, at 12:44, Tony Finch wrote: Joe Abley wrote: In that sense the idea of using a single master (which I think is implied by "primary master" and a name published in a single MNAME field) is defensibly archaic. It's quite difficult to have multiple masters and DNSSEC and coherent copies of the zone from all masters - i.e. more effort than just spinning up parallel instances of BIND or Knot in automatic signing mode. Note that I wasn't talking about multiple signers; I was talking about (from the perspective of one particular slave) having multiple masters available to serve precisely the same zone. Feeding a large array of slaves (eg hundreds, including individual members if clusters) with large numbers of zones from a single master doesn't scale very well. Joe --089e0827bc8c4379cf055eaab1a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Nov 23, 2017, at 12:= 44, Tony Finch <dot@dotat.at> wro= te:


Joe Abley <jabley@hopcount.ca= > wrote:

In that sense the idea of using a single= master (which I think is
= implied by "primary master" and a name published in a singl= e MNAME
field) is de= fensibly archaic.

It's qu= ite difficult to have multiple masters and DNSSEC and coherent
copies of the zone from all masters - i.e. more effort than just spinni= ng
up parallel instances of BIND or Knot in automatic signi= ng mode.

Note that I wasn'= t talking about multiple signers; I was talking about (from the perspective= of one particular slave) having multiple masters available to serve precis= ely the same zone.

Feeding a large array of slaves= (eg hundreds, including individual members if clusters) with large numbers= of zones from a single master doesn't scale very well.

<= /div>

Joe
--089e0827bc8c4379cf055eaab1a0-- From nobody Thu Nov 23 10:49:03 2017 Return-Path: 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 7F2FB12948A for ; Thu, 23 Nov 2017 10:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RqSodjOKbc1m for ; Thu, 23 Nov 2017 10:49:01 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEAF129453 for ; Thu, 23 Nov 2017 10:49:01 -0800 (PST) Received: from [172.31.98.14] (unknown [4.35.165.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id E192F61FA2; Thu, 23 Nov 2017 18:48:59 +0000 (UTC) Message-ID: <5A171818.4080507@redbarn.org> Date: Thu, 23 Nov 2017 10:48:56 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Joe Abley CC: "dnsop@ietf.org" References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> <5562271920774233970@unknownmsgid> In-Reply-To: <5562271920774233970@unknownmsgid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 18:49:02 -0000 Joe Abley wrote: > ... > > Feeding a large array of slaves (eg hundreds, including individual > members if clusters) with large numbers of zones from a single master > doesn't scale very well. when i had to do this i fed 100 from one or two, where the two were HA using non-DNS tech such as NFS or sql mirroring. then i've fed 1000 from each of those hundred, choosing one as primary and one as backup. if you have a better way, using extant, open technology, to reach 100,000 zxfr/ixfr clients with secure coherent zone content with minimal delay, i'd like to hear more. when i had to feed hundreds of zones to large populations, i used MZ (see http://family.redbarn.org/~vixie/mz.pdf and perhaps also dotat.at/prog/nsnotifyd/metazone.5.pdf). if you have a better way, using extant, open technology, to propagate a moderate to large and dynamic catalogue of zones toward a cooperating set of secondary servers, i'd like to hear more. -- P Vixie From nobody Thu Nov 23 11:48:05 2017 Return-Path: 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 551C7126DFE for ; Thu, 23 Nov 2017 11:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xQ8UO1XCqlpg for ; Thu, 23 Nov 2017 11:48:03 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9164120727 for ; Thu, 23 Nov 2017 11:48:02 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 0A0197A3309 for ; Thu, 23 Nov 2017 19:48:02 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 23 Nov 2017 14:48:01 -0500 Content-Transfer-Encoding: 7bit Reply-To: dnsop@ietf.org Message-Id: <6F157313-0A2C-49A9-B77B-BBA133C16192@dukhovni.org> References: To: dnsop@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [DNSOP] DNSOP Digest, Vol 132, Issue 45 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 19:48:04 -0000 > On Nov 23, 2017, at 11:13 AM, dnsop-request@ietf.org wrote: > > Even so, I know that at least one CA has received enough complaints from > customers with REFUSED private domains that they have already updated > their implementation to permit certificates in unresolvable zones that > lack DNSSEC. It worked before CAA and I don't think there's any particular > advantage to breaking it. Supporting private domains that (really) fail to resolve makes things more complicated and perhaps needlessly so. Perhaps the onus should be on the operators of the zones in question to make appropriate changes. In the mean time, if REFUSED and the like also need to be supported, then the SOA lookup strategy can be modified to walk up the tree in the face of (real) lookup errors, to conclude that a subdomain is insecure once an ancestor domain is found insecure. It is unfortunate that we routinely jump through hoops to work-around poor practices by others, and keep finding more ways to do so as time goes by. Is it a good idea to enshrine such a private domains hack as standard practice? Or can we grow some spine and require domains that want certificates (say starting January 2019) to not fail public DNS lookups? That is, perhaps the present work-arounds should have a sunset date. -- Viktor. From nobody Fri Nov 24 05:53:07 2017 Return-Path: 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 289A212871F for ; Fri, 24 Nov 2017 05:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 j1aUpVFUuvAs for ; Fri, 24 Nov 2017 05:53:04 -0800 (PST) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (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 6E8951286B1 for ; Fri, 24 Nov 2017 05:53:04 -0800 (PST) Received: from [192.168.1.3] (j48230.upc-j.chello.nl [24.132.48.230]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 9FD708851; Fri, 24 Nov 2017 14:53:01 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1511531581; bh=ZK0BW6LU2MyIM2ppd+gWG+TYU6Lbe0Xf0a9QzRuBMmE=; h=Subject:To:References:From:Date:In-Reply-To; b=sVShWmUpBCtZpiYwGuNNSL1AQP/ko+0X2JxUIEC7aaQ0qO5CbFNTFgNSRF3YYxK11 0fc0G07j8MQbEusOY6InuUEkaSVo/+4VWQ6yZvf1XUvB1ct320lnCLI3R8aRnTdgok xku4Pq9goy0QfauYUZMuSCvpB+bd1zkLuMQ5k2ZE= To: tjw ietf , dnsop References: From: Benno Overeinder Message-ID: Date: Fri, 24 Nov 2017 14:53:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 13:53:06 -0000 I support adoption and will review the draft. -- Benno On 11/16/2017 09:23 AM, tjw ietf wrote: > All > > The author has rolled out a new version addressing comments from the > meeting on Monday, and we feel it’s ready to move this along. > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > The draft is available here: > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 30 November 2017 23:59 > > Thanks, > tim wicinski > DNSOP co-chair > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From nobody Fri Nov 24 08:41:14 2017 Return-Path: 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 E87A3128796 for ; Fri, 24 Nov 2017 08:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 CL_hoptt-e6n for ; Fri, 24 Nov 2017 08:41:13 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 ED6DA1275F4 for ; Fri, 24 Nov 2017 08:41:12 -0800 (PST) Received: from [10.32.60.74] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vAOGdeh3006223 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 24 Nov 2017 09:39:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.74] From: "Paul Hoffman" To: dnsop Date: Fri, 24 Nov 2017 08:41:08 -0800 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 16:41:14 -0000 I would like to see this draft adopted and worked on by the WG. Some of Ed's observations ring true for me as well, but I can see ways forward for all the ones that concern me. --Paul Hoffman From nobody Fri Nov 24 11:57:21 2017 Return-Path: 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 D06671205F0 for ; Fri, 24 Nov 2017 11:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 dFUA6XYL1jy0 for ; Fri, 24 Nov 2017 11:57:18 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15E61200C5 for ; Fri, 24 Nov 2017 11:57:17 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id 72so14762597itl.5 for ; Fri, 24 Nov 2017 11:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZqIErEJoJmc3FcrNO+HEhKe6SqzjFjjluOFQJ/iCV7c=; b=FC4B1ouBnKL65+TcJEfgukLn5KoGy5zp94kpyMKCGekJpbkMNRFgyvXf/sFbpCwAmL g3p3X9THp3aXflg7/YCa5dyXhL2/EaE8RUxEuFVpUHGC0HjWZ3HX0W9IpZ0dXqZF5vfA qnSUIjgoubQkJ172vOXEP1bb4qWAr+vHM3e9M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZqIErEJoJmc3FcrNO+HEhKe6SqzjFjjluOFQJ/iCV7c=; b=WeTO+OLyn441FZ8/QYoWJy8+B/iVP7pahEx/7k5eotNN/Dm/KCtiFtJz8vfne0/Jh3 qCXLFRHJFHmWoOj1JC0dpzp7ydY3/SZy2kl//AOXBrMBe8/lOhQmjj+HVYupu2BusSuZ TgzltpzhySdM95ipAUHOq1SikupcMCG/g2xUqSP+rmwHtH7+Sg8rTDKkccvMFHmOY1iT iv1OJW8qE82ScXa7O0jDFv/br3txzJAUC91TbfeXd0bl8cdXDwlXvmPxfzb63JFIaUzN hNibR6LS0N401a72V03XJCsZx9eSCZTTlG16D81cqrQJ/vjkGXYSB+H4Z4Mxg01GCtI5 P9KQ== X-Gm-Message-State: AJaThX40VcU9ByFyKIlqpG9GUKSg1DBR08rBflzN5O9JdJPY4xFCtlil YKVqEJUTLWDnqLhWkFxibgWHUw== X-Google-Smtp-Source: AGs4zMYj1QdAHV42UA01hxg3Z8sIMoo1iJTR9jATnQ70eGH7LeVD4hpjzWsmFYy8lcbGXhgc8d+Evg== X-Received: by 10.36.137.69 with SMTP id s66mr18014658itd.22.1511553437181; Fri, 24 Nov 2017 11:57:17 -0800 (PST) Received: from ?IPv6:2607:f2c0:101:202:29a1:4d83:365a:9ee4? ([2607:f2c0:101:202:29a1:4d83:365a:9ee4]) by smtp.gmail.com with ESMTPSA id e138sm957747itc.31.2017.11.24.11.57.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Nov 2017 11:57:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Joe Abley In-Reply-To: <5A171818.4080507@redbarn.org> Date: Fri, 24 Nov 2017 14:57:11 -0500 Cc: "dnsop@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8978397E-B39F-415C-9F72-F675818A41CC@hopcount.ca> References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> <5562271920774233970@unknownmsgid> <5A171818.4080507@redbarn.org> To: Paul Vixie X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 19:57:20 -0000 Hi Paul, On 23 Nov 2017, at 13:48, Paul Vixie wrote: > Joe Abley wrote: >> ... >>=20 >> Feeding a large array of slaves (eg hundreds, including individual >> members if clusters) with large numbers of zones from a single master >> doesn't scale very well. >=20 > when i had to do this i fed 100 from one or two, where the two were HA = using non-DNS tech such as NFS or sql mirroring. then i've fed 1000 from = each of those hundred, choosing one as primary and one as backup. >=20 > if you have a better way, using extant, open technology, to reach = 100,000 zxfr/ixfr clients with secure coherent zone content with minimal = delay, i'd like to hear more. I presume you mean existing, not extant. The DNS is a bit new for any of = its technology to become extinct or lost to the winds of history, unless = that's a na=C3=AFve comment because I'm insufficiently aware that I'm = unaware of the things I'm unaware of. Or perhaps this is a = trans-atlantic difference in vocabulary. The principal challenges I have seen using a non-trivial transfer graph = with NOTIFY and [AI]XFR are when a pair of candidate masters for a = particular slave each receive a new revision of a particular zone at a = different time. The one that receives it first sends NOTIFY messages to = its slaves; if slaves don't use the NOTIFY source to select the master = subsequently used to send SOA queries and [AI]XFR requests to (and it is = normal not to in many/most/all widely-used implementations) there is a = chance they will talk to the master that hasn't yet been updated and = hence not retrieve the new revision of the zone. Presumably all masters = update eventually, however, so normality will eventually be restored. Whether this is a problem depends on your tolerance for delay in = propagation of new zone data to the slaves, and the potential for = equivalent masters (equivalent to the slave) to be carrying different = revisions of the zone for a long time. It can work as-is; if it doesn't = meet the requirements then you have to think a little harder about how = you synchronise your masters or what client behaviour can be arranged = when they receive NOTIFY messages. It's nice when it works as-is, because a pure DNS solution avoids the = kind ofshared fate and monitoring/troubleshooting overhead that things = like load balancers and network filesystems can introduce. Every time I = have seen a failure directly caused by a problem in something that was = intended to provide high availability, it has made everybody involved = very sad. The state involved in processing NOTIFY messages, especially when = there's loss in a path somewhere which triggers timeouts, back-off and = retransfer, can be painful to manage at scale. I have seen some abuse of = the specification in the form of fire-and-forget NOTIFYs to avoid the = state problem (discard NOTIFY responses received and never attempt to = retry sending, assuming that if ours didn't get through a NOTIFY from = another master probably will). Davey Song described a scenario that played out in the Yeti project = where multiple masters each serving zones that were equivalent but = different caused problems to downstream IXFR clients. The zones were = equivalent in the sense that they only differed in RRSIGs -- each server = used a local ZSK, corresponding properly to an RR in the DNSKEY RRSet, = to sign all the non-DNSKEY RRSets -- but different in the sense that the = RRSIGs were different, so really they were different zones with the same = origin. IXFR clients got confused, which I think in retrospect was = probably to be expected. This feels like the kind of scenario that Tony = was talking about in his earlier message in this thread. > when i had to feed hundreds of zones to large populations, i used MZ = (see http://family.redbarn.org/~vixie/mz.pdf and perhaps also = dotat.at/prog/nsnotifyd/metazone.5.pdf). I used an earlier version of that back in the day, as you might = remember. Pretty much everything I've been involved in since then has = used out-of-band provisioning of zone targets though, using devopsy = automation tools (ansible, chef, puppet) or provisioning databases that = were replicated independently of the DNS. One notable exception used = supermasters in PowerDNS, which you could call in-band (but still a = different approach from metazones): = . Joe= From nobody Fri Nov 24 12:36:27 2017 Return-Path: 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 8B8FF129329 for ; Fri, 24 Nov 2017 12:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es 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 fw9pEnFLgztt for ; Fri, 24 Nov 2017 12:36:20 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F3D1289C3 for ; Fri, 24 Nov 2017 12:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511555777; x=1512160577; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=N8QCJDcY/K4KfCBo3DQtLep9h Le65IuilLFIcC7yQCk=; b=BTdoxyHyh6flfm+Kh7TNUXRTph3dPu+XWOqSFI2pl 7jo91NO1TncWcpq7iuk9mbXu/7hOeyIKmCRk1TVeDqiPOOvvI8EnZJeqH8xMP9fE Kc0whn/PXFzHseO5rno2VGl/PXcJEZrt1drK/jrObYQrxq3O1S9jDCgaKGQEmk+0 zo= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=cIfZSYBiNrp9kkfWF8J+Om3/75ATUeIdDJqY+ygyDJ+FnjTrDd+rUe0hv6i/ mUxJSTz5R8YrxiZCf1aU6pj8LZe2zVJM5stomV3c8WvGhUMt2KTMMIN4e tPS1ZLzkgW51Z2Eh9MEP0OXRMbys8/SdAg+WFzWJtGS2B3d2eswKjk=; X-MDAV-Processed: mail.consulintel.es, Fri, 24 Nov 2017 21:36:17 +0100 X-Spam-Processed: mail.consulintel.es, Fri, 24 Nov 2017 21:36:15 +0100 Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005637839.msg for ; Fri, 24 Nov 2017 21:36:15 +0100 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:171124:md50005637839::I98zg7IJG93NQ5kS:0000BZYT X-Return-Path: prvs=1501b83790=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: dnsop@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Fri, 24 Nov 2017 21:36:11 +0100 From: JORDI PALET MARTINEZ To: CC: , <6man@ietf.org>, Message-ID: Thread-Topic: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> In-Reply-To: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [DNSOP] FW: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 20:36:21 -0000 Hi, I=E2=80=99ve posted =E2=80=9CTowards a Worldwide IPv6-Ready DNS Infrastruct= ure=E2=80=9D https://datatracker.ietf.org/doc/draft-palet-sunset4-ipv6-ready-dns/ I believe this is covered by the charter of sunset4, however, it is very re= levant as well for a recent discussion in 6man and v6ops and of course, it = is relevant as well to dnsop. I will love to get some inputs. I order to avoid unnecessary noise in sever= al mail exploders, I will suggest responding only in sunset4. Regards, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: viernes, 24 de noviembre de 2017, 21:30 Para: Jordi Palet Martinez , Jordi Martinez= Asunto: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.= txt =20 A new version of I-D, draft-palet-sunset4-ipv6-ready-dns-00.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-sunset4-ipv6-ready-dns Revision: 00 Title: Towards a Worldwide IPv6-Ready DNS Infrastructure Document date: 2017-11-23 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-palet-sunset= 4-ipv6-ready-dns-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-sunset4-ip= v6-ready-dns/ Htmlized: https://tools.ietf.org/html/draft-palet-sunset4-ipv6-re= ady-dns-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-sunse= t4-ipv6-ready-dns-00 =20 =20 Abstract: This document defines the timing for implementing an IPv6-Ready global DNS infrastructure, worldwide, in order to allow the global IPv6-only deployment. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Fri Nov 24 12:47:44 2017 Return-Path: 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 522DC1293EC for ; Fri, 24 Nov 2017 12:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es 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 srlodKAL3lLu for ; Fri, 24 Nov 2017 12:47:41 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793501293E8 for ; Fri, 24 Nov 2017 12:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511556460; x=1512161260; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=vviGiOd48ye4ysI+uuDVxaZbi wUkxB109MI4gNsNhqs=; b=GcFJI1GsMyWLWxbabooBA22zz4E1E9fAxNh7ui/QO KV0ZrTrFdyks1TlxyGzoRSsEEzQE7tEFnkmxG/Air3Gtdsi9qV1LNf2XKh8r1SjQ h2SyBrCguSa7jImtNQ6J/3cV47g9cWT5LVZOFk8CHaR7gxVW9DbPO+CevK12QpSQ SM= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=IHpd/kh4jaBLyhTTAEANFbMzVstEttpq6ofKUjj4f5ZdSSzXFIULv2XP6PRe O/ITDUYqcIEqQuqoWb7Tiy3knsrU+4ths8+lokHaN2UsQlfjtwkQ1a3b8 FQXC/FtCoD1DM28nZOXrscKjFt2GTbisHIyzFVl8yDLTa/HMAcgZDY=; X-MDAV-Processed: mail.consulintel.es, Fri, 24 Nov 2017 21:47:39 +0100 X-Spam-Processed: mail.consulintel.es, Fri, 24 Nov 2017 21:47:39 +0100 Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005637852.msg for ; Fri, 24 Nov 2017 21:47:38 +0100 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:171124:md50005637852::6essIsU3pGeUobXg:00005CzT X-Return-Path: prvs=1501b83790=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: dnsop@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Fri, 24 Nov 2017 21:47:33 +0100 From: JORDI PALET MARTINEZ To: CC: , <6man@ietf.org>, Message-ID: <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> Thread-Topic: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 20:47:43 -0000 By the way, forgot to mention something else. I=E2=80=99ve started also to work in a policy proposal for ICANN in order t= o make sure that we get aligned. Regards, Jordi =20 -----Mensaje original----- De: JORDI PALET MARTINEZ Fecha: viernes, 24 de noviembre de 2017, 21:36 Para: CC: , <6man@ietf.org>, Asunto: FW: New Version Notification for draft-palet-sunset4-ipv6-ready-dns= -00.txt Hi, =20 I=E2=80=99ve posted =E2=80=9CTowards a Worldwide IPv6-Ready DNS Infrast= ructure=E2=80=9D =20 https://datatracker.ietf.org/doc/draft-palet-sunset4-ipv6-ready-dns/ =20 I believe this is covered by the charter of sunset4, however, it is ver= y relevant as well for a recent discussion in 6man and v6ops and of course,= it is relevant as well to dnsop. =20 I will love to get some inputs. I order to avoid unnecessary noise in s= everal mail exploders, I will suggest responding only in sunset4. =20 Regards, Jordi =20 =20 =20 -----Mensaje original----- De: Responder a: Fecha: viernes, 24 de noviembre de 2017, 21:30 Para: Jordi Palet Martinez , Jordi Mart= inez Asunto: New Version Notification for draft-palet-sunset4-ipv6-ready-dns= -00.txt =20 =20 A new version of I-D, draft-palet-sunset4-ipv6-ready-dns-00.txt has been successfully submitted by Jordi Palet Martinez and posted = to the IETF repository. =20 Name: draft-palet-sunset4-ipv6-ready-dns Revision: 00 Title: Towards a Worldwide IPv6-Ready DNS Infrastructure Document date: 2017-11-23 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-palet-su= nset4-ipv6-ready-dns-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-sunset= 4-ipv6-ready-dns/ Htmlized: https://tools.ietf.org/html/draft-palet-sunset4-ipv= 6-ready-dns-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-s= unset4-ipv6-ready-dns-00 =20 =20 Abstract: This document defines the timing for implementing an IPv6-Ready global DNS infrastructure, worldwide, in order to allow the glob= al IPv6-only deployment. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of s= ubmission until the htmlized version and diff are available at tools.ietf.org= . =20 The IETF Secretariat =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Fri Nov 24 15:52:00 2017 Return-Path: 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 89551129434 for ; Fri, 24 Nov 2017 15:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 I1sCJQoUbDCM for ; Fri, 24 Nov 2017 15:51:56 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E87129431 for ; Fri, 24 Nov 2017 15:51:56 -0800 (PST) Received: from [10.1.10.138] (50-255-33-26-static.hfc.comcastbusiness.net [50.255.33.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 46A1561FA2; Fri, 24 Nov 2017 23:51:56 +0000 (UTC) Message-ID: <5A18B098.3050100@redbarn.org> Date: Fri, 24 Nov 2017 15:51:52 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Joe Abley CC: "dnsop@ietf.org" References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> <5562271920774233970@unknownmsgid> <5A171818.4080507@redbarn.org> <8978397E-B39F-415C-9F72-F675818A41CC@hopcount.ca> In-Reply-To: <8978397E-B39F-415C-9F72-F675818A41CC@hopcount.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 23:51:58 -0000 Joe Abley wrote: > Hi Paul, > ... > I presume you mean existing, not extant. ... yes. thanks for understanding what i mean in spite of what i said. > The principal challenges I have seen using a non-trivial transfer > graph with NOTIFY and [AI]XFR are when a pair of candidate masters for a > particular slave each receive a new revision of a particular zone at a > different time. The one that receives it first sends NOTIFY messages to > its slaves; if slaves don't use the NOTIFY source to select the master > subsequently used to send SOA queries and [AI]XFR requests to (and it is > normal not to in many/most/all widely-used implementations) there is a > chance they will talk to the master that hasn't yet been updated and > hence not retrieve the new revision of the zone. Presumably all masters > update eventually, however, so normality will eventually be restored. first let's clarify that this can't happen between the PM and its DM's, because in my example, the PM was HA. i do know that not all NOTIFY responders will try-first the server who sent them the NOTIFY, and that this can result in not learning a new serial number after a NOTIFY. the BIND4 version of the NOTIFY code did this correctly, but i'm guessing that RFC 1996 was not as clear on this topic as it might have been. my preferred solution to this woe is to fix the NOTIFY responders, but as we know this is often outside our powers. my actual solutions to this have been to either delay all NOTIFY's for some amount of time that's long enough to get the DM's to all settle, and make sure that the settle-time is as short as i can make it. or better still, give the slave-operators only one address for "zone master", and anycast that one to get redundancy. as an aside, the computed random delay-before-notify was not specified as a way to get a longer settling time; it was just to prevent all of the recipients of a NOTIFY-burst from doing their AXFR's in parallel. this was damnfoolishness related to BIND4's "fork on AXFR" logic, and i deeply regret it. 1996 was my first RFC and it shows. > The state involved in processing NOTIFY messages, especially when > there's loss in a path somewhere which triggers timeouts, back-off and > retransfer, can be painful to manage at scale. I have seen some abuse of > the specification in the form of fire-and-forget NOTIFYs to avoid the > state problem (discard NOTIFY responses received and never attempt to > retry sending, assuming that if ours didn't get through a NOTIFY from > another master probably will). alas, many operators solve only the problem they know they're having, without regard to the ones they don't know about, and without regard for the problems their solutions might cause for others. "monkey DNA". > Davey Song described a scenario that played out in the Yeti project > where multiple masters each serving zones that were equivalent but > different caused problems to downstream IXFR clients. The zones were > equivalent in the sense that they only differed in RRSIGs -- each server > used a local ZSK, corresponding properly to an RR in the DNSKEY RRSet, > to sign all the non-DNSKEY RRSets -- but different in the sense that the > RRSIGs were different, so really they were different zones with the same > origin. IXFR clients got confused, which I think in retrospect was > probably to be expected. This feels like the kind of scenario that Tony > was talking about in his earlier message in this thread. yeti is probably a degenerate non-teaching corner case. since it deals with the root zone, we had to politicize the design -- there are three DM's whose only shared data is the IANA source zone they start with, and the KSK they sign ZSK's with. we had to avoid annointing any one party as having a special relationship to root-like zone data. this is unlikely to be a problem for anyone else or for any other zone. >>see http://family.redbarn.org/~vixie/mz.pdf ... > I used an earlier version of that back in the day, as you might > remember. Pretty much everything I've been involved in since then has > used out-of-band provisioning of zone targets though, using devopsy > automation tools (ansible, chef, puppet) or provisioning databases that > were replicated independently of the DNS. that's what a lot of the professionals do. however, i won't recommend technology that hasn't been documented and tested for interoperability, portability, and lack of IPR encumbrance. > One notable exception used > supermasters in PowerDNS, which you could call in-band (but still a > different approach from > metazones) MZ was influenced by BIND, and only implemented for BIND, but was meant to be name-server independent. i would like to see something like this gain broad industry traction, so that we can all spend our time solving things that somebody else hasn't already solved. -- P Vixie From nobody Fri Nov 24 19:01:00 2017 Return-Path: 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 01502129481 for ; Fri, 24 Nov 2017 19:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 vLWWcVXW-4Ov for ; Fri, 24 Nov 2017 19:00:55 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC03124B18 for ; Fri, 24 Nov 2017 19:00:55 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id l19so16383957pgo.2 for ; Fri, 24 Nov 2017 19:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S6OI+0sSkj+VRF/0aZv1/01O1ZBFJQD/4HzKrMP9hSQ=; b=CTp3bvf5/vvskRESUNJullTiOrucoUGin166WIcswbQiwhsBydFkeRUGcnAMipH6Ho Kelgou5BTsvEgRt7Kd30dQEhepDI0jDVOvSxVhL6D0ClyKNH/+g/pPR2Ej/zo6EuxtMA A6iXAzNV0N3p9VJNcEOI21HWRvMI2w+CbNGy3hUOLna3OBYJiRbJet31RvJPH3pTwnMF eqjdmHUqkOTNimWT3oNXDRGZ2iXDwV9Pcnl0wPdHEUXaJxUKvzDjlsFrr1O9bf+SU0bL vEnsw8AnSnqLf8xaYL7UN9McLpo6bkI4DtSmYOdFBK7jJpf7ZqWWsqFoSUgHiW5zC/Lm qiqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S6OI+0sSkj+VRF/0aZv1/01O1ZBFJQD/4HzKrMP9hSQ=; b=b4zpoH4eHa3vgpPyDaWnADmSjFISkkrHfQg4SVYxOOt25b3RF3/2U5bXBEfNXS1ETs kkx/An6aTc7TZx2cA6FVOUSTIFwk4EAKHCsuDGGhEKOuZfQdEtamwLmqhiDTFpa8cpij l7T1/55e/TtN8zMYu/5Fn82Q2VkqMTnTlPbhQvcRenI+ROWiiYZjlrgend+j58HhG7kf n8L0SoFO1t8ZQAg9pe8WQue52ufKOkmaNTTyiGJeCIh69Dc0V79YShvOMAa2PkF2v1tS 4qehapFwtIibPOHO/zDr4yxuoLSyFVeKyI3XflUwo2pe2FySY70n59a7fOWbtTHOwZyz 2vAQ== X-Gm-Message-State: AJaThX4Msa40k748zwy+qN9Sd36F/pK0wOHa/Gd/HvJXw2/uBDupqm4X Ja53d8/NmtmJA1EkFiSUf2HiT47crZ7ACyfz7Lg5DA== X-Google-Smtp-Source: AGs4zMaz8jY/YxvgWIW491duqWEOydasFY4T+rtQMlsNNIb7vN/IVMo2Pr1Q5QERt02sT5VwAK2nZc+UK/eAtGCFRb4= X-Received: by 10.101.82.76 with SMTP id q12mr29896243pgp.140.1511578854927; Fri, 24 Nov 2017 19:00:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.139.5 with HTTP; Fri, 24 Nov 2017 19:00:54 -0800 (PST) In-Reply-To: References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> From: Bob Harold Date: Fri, 24 Nov 2017 22:00:54 -0500 Message-ID: To: jordi.palet@consulintel.es Cc: sunset4@ietf.org, IETF DNSOP WG , 6man@ietf.org, v6sop@ietf.org Content-Type: multipart/alternative; boundary="f403043e6878b2bd67055ec5e0b5" Archived-At: Subject: Re: [DNSOP] FW: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Nov 2017 03:00:58 -0000 --f403043e6878b2bd67055ec5e0b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 24, 2017 at 3:36 PM, JORDI PALET MARTINEZ < jordi.palet@consulintel.es> wrote: > Hi, > > I=E2=80=99ve posted =E2=80=9CTowards a Worldwide IPv6-Ready DNS Infrastru= cture=E2=80=9D > > https://datatracker.ietf.org/doc/draft-palet-sunset4-ipv6-ready-dns/ > > I believe this is covered by the charter of sunset4, however, it is very > relevant as well for a recent discussion in 6man and v6ops and of course, > it is relevant as well to dnsop. > > I will love to get some inputs. I order to avoid unnecessary noise in > several mail exploders, I will suggest responding only in sunset4. > > Regards, > Jordi > > > > -----Mensaje original----- > De: > Responder a: > Fecha: viernes, 24 de noviembre de 2017, 21:30 > Para: Jordi Palet Martinez , Jordi > Martinez > Asunto: New Version Notification for draft-palet-sunset4-ipv6- > ready-dns-00.txt > > > A new version of I-D, draft-palet-sunset4-ipv6-ready-dns-00.txt > has been successfully submitted by Jordi Palet Martinez and posted to > the > IETF repository. > > Name: draft-palet-sunset4-ipv6-ready-dns > Revision: 00 > Title: Towards a Worldwide IPv6-Ready DNS Infrastructure > Document date: 2017-11-23 > Group: Individual Submission > Pages: 4 > URL: https://www.ietf.org/internet- > drafts/draft-palet-sunset4-ipv6-ready-dns-00.txt > Status: https://datatracker.ietf.org/ > doc/draft-palet-sunset4-ipv6-ready-dns/ > Htmlized: https://tools.ietf.org/html/draft-palet-sunset4-ipv6- > ready-dns-00 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-palet-sunset4-ipv6-ready-dns-00 > > > Abstract: > This document defines the timing for implementing an IPv6-Ready > global DNS infrastructure, worldwide, in order to allow the global > IPv6-only deployment. > > As much as I would like to see the transition happen, Realistically, IPv4 will continue to 'work', for a large number of users, for a very long time. If you multiply your times by 10 (or more) and work hard, you might be successful in phasing out most of IPv4 in DNS. But forcing users to change seems like a bad idea. I note issues like: - Cloud providers (Amazon, Google, Azure?) only provide a private IPv4 address to virtual machines. They use NAT to get an IPv6 address for incoming traffic. I don't know of any way to do IPv6 outgoing. (I could be wrong, still learning here.) - Android does not support DHCPv6. - DNS64 breaks DNSSEC. - There are probably a large number of legacy hardware devices and software programs that do not support IPv6, but will still be running 10 or 20 years from now. I expect there are many more, but those come to mind. --=20 Bob Harold --f403043e6878b2bd67055ec5e0b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Fri, Nov 24, 2017 at 3:36 PM, JORDI PALET MARTINEZ <= ;jordi.pale= t@consulintel.es> wrote:
Hi= ,

I=E2=80=99ve posted =E2=80=9CTowards a Worldwide IPv6-Ready DNS Infrastruct= ure=E2=80=9D

https://datatracker.ietf.org/doc/draft-palet-sunset4-ipv6-ready-dns/

I believe this is covered by the charter of sunset4, however, it is very re= levant as well for a recent discussion in 6man and v6ops and of course, it = is relevant as well to dnsop.

I will love to get some inputs. I order to avoid unnecessary noise in sever= al mail exploders, I will suggest responding only in sunset4.

Regards,
Jordi



-----Mensaje original-----
De: <internet-drafts@ietf.or= g>
Responder a: <internet-draft= s@ietf.org>
Fecha: viernes, 24 de noviembre de 2017, 21:30
Para: Jordi Palet Martinez <jordi.palet@theipv6company.com>, Jordi Martinez <jordi.palet@theipv6company.com>
Asunto: New Version Notification for draft-palet-sunset4-ipv6-ready-dn= s-00.txt


=C2=A0 =C2=A0 A new version of I-D, draft-palet-sunset4-ipv6-ready-dns= -00.txt
=C2=A0 =C2=A0 has been successfully submitted by Jordi Palet Martinez and p= osted to the
=C2=A0 =C2=A0 IETF repository.

=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d= raft-palet-sunset4-ipv6-ready-dns
=C2=A0 =C2=A0 Revision:=C2=A0 =C2=A000
=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Toward= s a Worldwide IPv6-Ready DNS Infrastructure
=C2=A0 =C2=A0 Document date:=C2=A0 =C2=A0 =C2=A0 2017-11-23
=C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indivi= dual Submission
=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4
=C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-dr= afts/draft-palet-sunset4-ipv6-ready-dns-00.txt
=C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-palet-su= nset4-ipv6-ready-dns/
=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-palet-sunset4-ipv6-ready-dns-00
=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-p= alet-sunset4-ipv6-ready-dns-00


=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document defines the timing for implementin= g an IPv6-Ready
=C2=A0 =C2=A0 =C2=A0 =C2=A0global DNS infrastructure, worldwide, in order t= o allow the global
=C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6-only deployment.


As much as I would like to see the tra= nsition happen,
Realistically, IPv4 will continue to 'wo= rk', for a large number of users, for a very long time.
If yo= u multiply your times by 10 (or more) and work hard, you might be successfu= l in phasing out most of IPv4 in DNS.
But forcing users to change= seems like a bad idea.

I note issues like:
- Cloud providers (Amazon, Google, Azure?) only provide a private I= Pv4 address to virtual machines.=C2=A0 They use NAT to get an IPv6 address = for incoming traffic.=C2=A0 I don't know of any way to do IPv6 outgoing= .=C2=A0 (I could be wrong, still learning here.)
- Android do= es not support DHCPv6.
- DNS64 breaks DNSSEC.
- There a= re probably a large number of legacy hardware devices and software programs= that do not support IPv6, but will still be running 10 or 20 years from no= w.
I expect there are many more, but those come to mind.
<= /div>

--
Bob Harold

<= div>=C2=A0
--f403043e6878b2bd67055ec5e0b5-- From nobody Sat Nov 25 09:41:18 2017 Return-Path: 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 A8E9512783A for ; Sat, 25 Nov 2017 09:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ykXqJmLxTpmn for ; Sat, 25 Nov 2017 09:41:15 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331151204DA for ; Sat, 25 Nov 2017 09:41:15 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id o130so16981561itg.0 for ; Sat, 25 Nov 2017 09:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=35EMMMxsymZONPzSpqICsqN/DLE65WhTX1KaicQOQ7E=; b=oZtfbMCluD8qpkYyvdABq/nTIra9mvoXdCN16Vv0HkjmrmXE5Is0JFdvLjgSD8IgZC 9nnrT7YDijWgVytZYnBbhxTmbpnq26zl1LFTCt+WAF7wEb809PgrFD03yUX1Q9T11vXM J9reyPSBAwoG/7KcFcnS1SxtvIJvPa6nVJ5iGSsJPKLxqNMvFlzIvVZ9Yz/MhKyz79wN ekM9pXxRRbEhtub9Dcnu4EDvj5x6/yvpGXwIWxPkp2vLO2jBvpFUOHNH6WdAS7Wb7gXR FCwaQWcYj87re2DP67TkM0lKnM4GkpXn4kAxuPhq8SRnWRJ/zc7gEq09tOtf6qzjUC+l sSUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=35EMMMxsymZONPzSpqICsqN/DLE65WhTX1KaicQOQ7E=; b=NRywfJ/Rn6GiZgg6bpPyKByXcwRj751iMB3nVwPKPDvUiwZlSzdpXsrk471v/Q7iHj W0euVYUF/2kFI+sQ1hrhRt8yQkEYpPpW4ErhpDnjMkzW2rsdX3PhAs7czIbyp0JygaUO +BD3QSMsVu/U2OkFJFDoLYcArQ4WpVTIyaThRLgbZa79B9C5bZZZESxv2G2PMWdPkVyR MB9RZhxEczqfSQUkO7aYMa+cWJX44THP4kVR2UCCx0EPpqz4rucHnAjgjbybsPc1YrQh kw1j/uQvr9I6mKQDUBOG2cvAtdbbohA9fzA3LJAqWq2m4MOrXT49Vt0wbHvVmgWPFn1L ZjYg== X-Gm-Message-State: AJaThX5qizJT2gZ2adggpbYLgy9bIMmtW157A4cuOeF4UAue00NWgHQg l8aXmb4oWmhiZ+4eRCmY9b6S7sbkgFMQWMUOeCgyj67g X-Google-Smtp-Source: AGs4zMazY2EM8jqRvv1uILutAGlhF8EEFCmbo018VNir7TQJQdE97zXyNyMGS825gsH6W+eULzrkvgZilThm1WZZ7aM= X-Received: by 10.36.31.212 with SMTP id d203mr20482667itd.48.1511631674272; Sat, 25 Nov 2017 09:41:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.69.73 with HTTP; Sat, 25 Nov 2017 09:41:13 -0800 (PST) From: Tariq Saraj Date: Sat, 25 Nov 2017 22:41:13 +0500 Message-ID: To: dnsop@ietf.org Content-Type: multipart/alternative; boundary="001a11446060f9f2e6055ed22c0b" Archived-At: Subject: [DNSOP] IVIPTR: New RR for DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Nov 2017 17:41:17 -0000 --001a11446060f9f2e6055ed22c0b Content-Type: text/plain; charset="UTF-8" Dear all, Please provide your valuable feedback on the newly uploaded draft. draft-tariq-dnsop-iviptr-00 *IVIPTR: Resource Record for DNS* -- Regards Tariq Saraj Riphah Institute of Systems Engineering, Islamabad --001a11446060f9f2e6055ed22c0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,
Please provide your valuable feed= back on the newly uploaded draft.=C2=A0
draft= -tariq-dnsop-iviptr-00 =20
IVIPTR: Resource Record for DNS =20


--
Regards
Tariq Saraj
Riphah Institute of Systems Engineering, Islamabad

--001a11446060f9f2e6055ed22c0b-- From bert@hubertnet.nl Sat Nov 25 10:51:46 2017 Return-Path: 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 6DBD4128854 for ; Sat, 25 Nov 2017 10:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 KaS_8EPIUJNe for ; Sat, 25 Nov 2017 10:51:44 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA25126DEE for ; Sat, 25 Nov 2017 10:51:44 -0800 (PST) Received: from server.ds9a.nl (ip565244ed.adsl-surfen.hetnet.nl [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id E9A679FB57; Sat, 25 Nov 2017 18:51:41 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 8DE05AC3D82; Sat, 25 Nov 2017 19:51:41 +0100 (CET) Date: Sat, 25 Nov 2017 19:51:41 +0100 From: bert hubert To: Tariq Saraj Cc: dnsop@ietf.org Message-ID: <20171125185141.GA17868@server.ds9a.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] IVIPTR: New RR for DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Nov 2017 19:00:10 -0000 On Sat, Nov 25, 2017 at 10:41:13PM +0500, Tariq Saraj wrote: > Please provide your valuable feedback on the newly uploaded draft. > draft-tariq-dnsop-iviptr-00 > > *IVIPTR: Resource Record for DNS* Hello Tariq, I have read through this draft and it left me pretty confused, both in terms of the motivation and the practicalities. If understand it correctly, the idea is to find the 'corresponding' IPv4 address to an IPv6 address? And that this could then be applied to transposing access control list rules from one protocol to the other? In other words, I could have something like 'allow from 192.0.2.1', and through an IVIPTR lookup, this could be mirrored to 'allow from 2001::db8::2:1'? Can you confirm that this is the intended goal? In terms of practicalities, I implement both resolving and authoritative nameservers, and your section 3 and 4 leave me confused if I have to do anything or not, except support the record format. The wording is very hard to follow and could do with a lot more whitespace and perhaps enumerated steps. If it turns out that resolvers or authoritative servers need to do something special, your draft should definitely talk about how to cope with servers that do not perform such special processing. Good luck! Bert > > > -- > Regards > Tariq Saraj > Riphah Institute of Systems Engineering, Islamabad > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Sat Nov 25 11:00:29 2017 Return-Path: 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 25C73128891; Sat, 25 Nov 2017 11:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9paqs2D-qo6W; Sat, 25 Nov 2017 11:00:26 -0800 (PST) Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B94E1288B8; Sat, 25 Nov 2017 11:00:24 -0800 (PST) Received: by mail-ot0-x244.google.com with SMTP id s12so21163295otc.0; Sat, 25 Nov 2017 11:00:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7FXK9Hbsy2NvXHbs21RXBKze0r25JhyaY220NVjBj5I=; b=H08aUilHx4bXp2Hh0gIcaZoj7DH4LEzaYRSrkUkaaJqq+8g9i9Eja7uui7aAOZcBPU zEqRo+Q0xKXVh0AYWwCaZWxB31HxQzhSxlkzbi6Ml1iM2hacw37UrqM1qZglp2PAd4Gg SN7HoXpsQ4XDQeJBJts3EjpcfjqrLdmz0biq8RtuB1mjeujp8XlN7x5DjVT5m8j7BbOx 6ThPnVJZ/f6hAixHRwZO4/aTJdOl/lS6aoO6M1r239okM123vyHUD01Jm+KmLiVWpjS7 UMGGw86fCqhfYTEic0BpUN0rPVpVKzbq5K50+VBi7dCt+CTL/w8Nl4ZuLYAUhWFj+pxn ht+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7FXK9Hbsy2NvXHbs21RXBKze0r25JhyaY220NVjBj5I=; b=JNVBpkRZMeM7+lSj1Z1UEtvPAMo9vMxrwqLSEArQx35wqS9WiTEBOXDMxJXlpnGWd9 F00NCzerxoMNdKSv3TLl9BSmnmyGO76xpAcEAlI/9+RcssLWWkcU+Cgm42XuPV44Uf2P ho7S6DYkjH3m13s/6OM45SYecJ6YQ8197q+aAjLTrp3+vZa5ThPCqbkE+4EvPcrvw/fP 5iHmsV5plG33yF1vTh30vfWP7ePaGgWJSE33lcTVY5y6UdDTa7K6D53vL3afix1CxN6T 5VFbKbu0An0XCTX5TeaA06x1LEdUW6qnedPYbbEbIh30+oMo8L5uaGP3F1RLnhqVBsHh XBDQ== X-Gm-Message-State: AJaThX6dd9F9DXJ96l0wOUIQXmFzDBzNupct/chou/PqSvChS+F0Veri HWzAxEXybOkRulE6jTYYWZ6aTkU/ X-Google-Smtp-Source: AGs4zMap2WjSCeEO/jMKuSU/gFUaQSpFW6ZlyMVAM2Twr+rhUsBEcgT83oV89mem4er0KDiZWw7j+A== X-Received: by 10.157.25.42 with SMTP id j42mr6903047ota.348.1511636423695; Sat, 25 Nov 2017 11:00:23 -0800 (PST) Received: from ?IPv6:2600:8802:5600:f7a::1019? ([2600:8802:5600:f7a::1019]) by smtp.gmail.com with ESMTPSA id j9sm6648182oth.31.2017.11.25.11.00.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Nov 2017 11:00:22 -0800 (PST) From: Fred Baker Message-Id: <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_560B97F8-4746-470D-A2C3-5112656EC11E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sat, 25 Nov 2017 11:00:19 -0800 In-Reply-To: <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> Cc: sunset4@ietf.org, dnsop@ietf.org, 6man@ietf.org, "v6ops@ietf.org WG" , Daniel Karrenberg To: JORDI PALET MARTINEZ References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Nov 2017 19:00:28 -0000 --Apple-Mail=_560B97F8-4746-470D-A2C3-5112656EC11E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 24, 2017, at 12:47 PM, JORDI PALET MARTINEZ = wrote: >=20 > I=E2=80=99ve started also to work in a policy proposal for ICANN in = order to make sure that we get aligned. One thing you might want to think about: the root servers are all = IPv6-capable today and serve requests using IPv6, and the 1541 TLDs are = all required by contract with ICANN to be IPv6-capable. I think you'll = find yourself holding the burden of proof that the infrastructure isn't = capable of IPv6-only operation today. RSO statistics are available from http://www.root-servers.org/. ICANN = TLDs are at https://data.iana.org/TLD/tlds-alpha-by-domain.txt. Reading through your draft, what I see that is probably not present = today is an IPv6 address for every SLD, which is to say names like = "example.com". What might be worth your while (I copy Daniel because he did a similar = study using RIPE Atlas not too long ago and can point you to relevant = documentation on how to do one yourself) would be to set up a RIPE Atlas = study that accesses the Root, ccTLD, and gTLD authoritative servers = using their IPv6 addresses and reports on the status of that from a wide = variety of locations. --Apple-Mail=_560B97F8-4746-470D-A2C3-5112656EC11E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAloZvcQACgkQEhdRnd2G P+B0HhAAjOpoPOzOOJXgAKPM0i+bCxze23Cgl90TFT2eAgiMRXCgEgKd+70ExW1J CPfwnQd2TL7iB9erucbaD9EnPyZMLatSUjxydKoGiX4E0Niq7teXlhFREG2a+VZS 3gCoTvQremntqZ9pO8yckaxPjh3BXKE5GCwTdqa4S+X0oPe8oafBnVkqBFy/xJso QGIsPad25z8tQW/sYSh3j4lE52Hwwts6+YzNtw/J7c9Qytm3gCI+YBJ6/wv1Zp7R esUN0kSja2Le21JxARNNkDygFx8tyxUq/FIjU/Gtca+AsFHHOdXxq/zR6RMcfAnM a3xIHTocm0QzjsbiTJBs6HalyY7Xb3EnllBW+L/nEe1UDeqkDP77rmkAhP5hBsVl wSyaA6reEkpURDNCHDbseRlL7Mt/erIrJe1TfJQCw3B0r3ooD843LqLHiFOPcxbB gG0eDipbG72SfitohFsgD7N5PGae0j7b3yazvy+meaQJoD4RFcZQoOUmwV+xq4be iYHGLtBvuuUVOA0Te0tqxAj/hUeuAb2jIdYZcCsyYFr/u33A6K9SM6rnAOeyujrh oxznyI022Jrs7MspncO9DqwDk3w9m2Bi89RfKSp/FrpPT5FVl8+CsitZDsW0cQl3 F5QMvWuPKB0N8GY5vt1fycTbRpCmtZzVQojBkaKOg8mG0G2J4s8= =REKM -----END PGP SIGNATURE----- --Apple-Mail=_560B97F8-4746-470D-A2C3-5112656EC11E-- From nobody Sat Nov 25 15:46:05 2017 Return-Path: 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 31175127B60 for ; Sat, 25 Nov 2017 15:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 j8lFxJpXHIMC for ; Sat, 25 Nov 2017 15:45:56 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658AB1243F3 for ; Sat, 25 Nov 2017 15:45:56 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id s37so21837955ioe.10 for ; Sat, 25 Nov 2017 15:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G68r27NadI28O8vYjtH//gET3CZW+SX2XoXu1ua3LRE=; b=CEtOEOTGignHqylyzb5I3+sdWFyLric1tR/xzVhR/XLCofdhRmjla3pb33GOtreXYt RL8bLkRskJFrnhY9hAHHm67ZYPvI5vxNoYZxWp2u0T0c2zYo1P6SfQtObk3BkkYANAJv MM8UzCvyHugcEiKaG6fAsisX4zsN4C8TiR20M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G68r27NadI28O8vYjtH//gET3CZW+SX2XoXu1ua3LRE=; b=Mq39SK6in0jtd0PzopnKFLl4NVZhO+6c73gWn+yxCfrMvTtyWm2FA9yvOD6WD5nlcW +G1uYZGO13jkgNvGdWYduMMCAcsoNpvzFj19Fba77stZOMnqNPiPvjJywTIRGesqgPYl bzB/oH+M3n8HoX40nrp4kjyhUx58yDHe1qgKVDIReo5R+k6GNLYnYy80BrUG4OMyKvIt V4BhUE82E0zfDJOAUI3aNtpcxiab15m8mhXLPYagYDG9kBycCj23OOZ35Ds+xu8ml4S5 nZ9PeKFfqYWK+BDqJypNWF6My56qiJo6+IYLq5/dxD7YUrzGVW3s91tKr7uyrqq8YCni NigQ== X-Gm-Message-State: AJaThX4TbMZlAlxLZPryVtb1ZIZmG98GRWo0eZMDndet3v08CXmGYn2T nbYm7MR3cGFHS+k5/9n2bpFlkg== X-Google-Smtp-Source: AGs4zMbuRuIyKP/D80dRHyhwqCglS6QhrQo/TjEnWpoLtqQlKH9iFxgSB1ppUYbpr6Ed2iGhafyx9Q== X-Received: by 10.107.198.84 with SMTP id w81mr37726401iof.151.1511653555568; Sat, 25 Nov 2017 15:45:55 -0800 (PST) Received: from ?IPv6:2607:f2c0:101:3:b07e:ddeb:fe18:44cf? (node-131dv5j4grjd2zso9b.ipv6.teksavvy.com. [2607:f2c0:101:3:b07e:ddeb:fe18:44cf]) by smtp.gmail.com with ESMTPSA id q6sm4972037ita.38.2017.11.25.15.45.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Nov 2017 15:45:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (15B202) In-Reply-To: <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> Date: Sat, 25 Nov 2017 18:45:52 -0500 Cc: JORDI PALET MARTINEZ , dnsop@ietf.org, 6man@ietf.org, Daniel Karrenberg , "v6ops@ietf.org WG" , sunset4@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> To: Fred Baker Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Nov 2017 23:45:58 -0000 Hi Fred, [I haven't read Jordi's draft; I'm just responding to what I've read in this= thread.] On Nov 25, 2017, at 14:00, Fred Baker wrote: > One thing you might want to think about: the root servers are all IPv6-cap= able today and serve requests using IPv6, and the 1541 TLDs are all required= by contract with ICANN to be IPv6-capable. I think you'll find yourself hol= ding the burden of proof that the infrastructure isn't capable of IPv6-only o= peration today. monster:~]% egrep -c '^[A-Z]' /usr/share/misc/iso3166=20 249 [monster:~]%=20 There are potentially 249 TLDs that are not operated under any such contract= with ICANN, although I agree that the majority of ccTLDs have at least one n= ameserver that is v6-capable (maybe all, but I haven't checked and I wouldn'= t want to assume). The important clients for all of these authoritative servers from the perspe= ctive of end-users are resolvers. I think it's uncontroversial to suggest wi= thout citation that not all resolvers used by end-users today are v6-capable= , or downstream from a resolver that is v6-capable. So we are not ready to t= urn off v4 today unless significant collateral damage is considered acceptab= le (and surely it's not). This is a relatively small problem to solve, though (note use of "relatively= "). I think it would actually be practical to announce a sunset for v4 on gT= LD and root servers at some suitable target date in the not too distant futu= re, the implementation of which could be mainly handled within the root zone= itself. Aside from the techno-political v6-deployment motivations, I think there wou= ld be good engineering reasons to sunset v4 in root and TLD servers. Such a move would open the door to the complete removal of v4 transport from= all of those servers which would eliminate them as viable amplifiers in att= acks against v4 targets. It would also provide greater motivation to deal wi= th any unreliability in v6 operations in the DNS or connecting networks, fra= gmentation-related transport issues, etc which will surely otherwise see min= imal attention so long as working v4 transport masks v6 problems. Joe= From nobody Sat Nov 25 17:13:40 2017 Return-Path: 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 A7FFA126BF6 for ; Sat, 25 Nov 2017 17:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ar93J5teJlgQ for ; Sat, 25 Nov 2017 17:13:36 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE7A1243F3 for ; Sat, 25 Nov 2017 17:13:36 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id y82so24109094wmg.1 for ; Sat, 25 Nov 2017 17:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ktfrhVDOCDc5UNpdF500nBpvjNYM2+I0vQ827QaYlNk=; b=uxC6TZX3kxNehGE/pCMQrsQuozfWbnZ8RVp7nC5OGBq0x9yBL/DSIBi+5VnflEBc+G qQtTmQ31VgU4alY4q6dpFfywNWPzS009Mr23gx0B1GULvYL4SnSwrhupe3/BqAlK4wRj qtaxy6iREdoEk6Qd3fRIRfWdjYH6QNLj+Jt9RQLdn1loE8YQgOjpRrn2uztq2wbLyIOV kPbqvN/DGTEQDCy1I99vlC5JvMab3Q0ZkjLTwQ+MHSquZJJMEAcvD9FjRCK/p2VNv+HO s9teUfyCMp0yFmgEylmAA6shNg7aJYdaP8FmDf+UcMwR6jnTu/Udr1SnFj/3F+dTlfya 1XMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ktfrhVDOCDc5UNpdF500nBpvjNYM2+I0vQ827QaYlNk=; b=Ore7i1/xoJa6J0ww9MzcLvXGyroc1hxCM6xFK9LcsnIdsAVpo/FXEddc3xGp7r0/KY 9ooKwfWB7J5vCE8bfgCGL/xiegmRacJeemn00lrZaFKjIFESxxhtA7O+HYLY/Jbk0omQ laSxZ9AbkFm/mpErI0/wUeAaf4pTcKzOdk/vU1gEx4c+yjEq+KXeNl7xaEOlezDeq+kC +MVk4xVR4g45F7eU+xOH5nstGM3IJCNOgrPnoWLAZX0gzFIOjuvBCVIvXjowmYz12GKE 8dPWSPoVRjDSNvl/xN5peR9K17EsF9PkVf6dvL8j4Fb6T62RRXPDBqQB678R/KH9pMZ7 9Duw== X-Gm-Message-State: AJaThX7ESeqpt9UL8xB+jG3VDTtTuRGlQ2MnDhC32tisOYpom+wij4BV rWJ0lAfoBnfy4IEe+wX/2/nruLwNnZ2gYbXVIUU= X-Google-Smtp-Source: AGs4zMYxUrpIfKVLKymlwYOUSvVLugNG6ho8dW/zTjruRsgGZHam+hJRlmL5fMFjJ1u8hkwTRyRmArvbZhlUqckYGPo= X-Received: by 10.28.87.78 with SMTP id l75mr14323918wmb.98.1511658814713; Sat, 25 Nov 2017 17:13:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.134.147 with HTTP; Sat, 25 Nov 2017 17:13:34 -0800 (PST) In-Reply-To: References: From: tjw ietf Date: Sat, 25 Nov 2017 20:13:34 -0500 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="001a1144267cac324d055ed87e52" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Nov 2017 01:13:38 -0000 --001a1144267cac324d055ed87e52 Content-Type: text/plain; charset="UTF-8" FYI, I'm taking notes of all the issues raised by folks in this thread (thank you!) and will hold the authors accountable in addressing them. tim On Fri, Nov 24, 2017 at 11:41 AM, Paul Hoffman wrote: > I would like to see this draft adopted and worked on by the WG. Some of > Ed's observations ring true for me as well, but I can see ways forward for > all the ones that concern me. > > --Paul Hoffman > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a1144267cac324d055ed87e52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI, =C2=A0I'm taking notes of all the issues raised b= y folks in this thread (thank you!) and will hold the authors accountable i= n addressing them.=C2=A0

tim

<= div class=3D"gmail_extra">
On Fri, Nov 24, 20= 17 at 11:41 AM, Paul Hoffman <paul.hoffman@vpnc.org> wro= te:
I would like to see this draft adopte= d and worked on by the WG. Some of Ed's observations ring true for me a= s well, but I can see ways forward for all the ones that concern me.

--Paul Hoffman


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--001a1144267cac324d055ed87e52-- From nobody Sat Nov 25 19:57:43 2017 Return-Path: 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 3C86D126DFB for ; Sat, 25 Nov 2017 19:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1o8Ejzhiz7PC for ; Sat, 25 Nov 2017 19:57:39 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DA581200E5 for ; Sat, 25 Nov 2017 19:57:39 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id j14so16930227uag.11 for ; Sat, 25 Nov 2017 19:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=69U2xI5p4sPO3o1PAeONO8LUiOohBxkq845XGkRwjng=; b=UW6iplyzsE/pV0LW26URR3dJYIYNLaxXyu2d7kGgcxPnDpRRS+xP94Nvear6cxtAEJ YwrVZB2dPI6yrye9DlzxeXFBCuiiu84D8jhT92eYht/lmoF0VrD8UnVVpl0B+0dDhDLY lk408l0U3Uj6cgnCcgoEPIfez1tdR8UYKqR+KR4L5eC+7g+6Czh/gSwgU4o7xszTtV/C xrFZOSd5EUlQAA1bBd1pMSKl+FmtJSUfgLXwHGhE01Ay+hINpDsBT51jYW47mvFskqAG 4fRLv1GYYm9dkBwzTZLk21D///1uyt8lqzMULsyoWRGJz6vMEbyrsgjQpUknU4xhb1+S megQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=69U2xI5p4sPO3o1PAeONO8LUiOohBxkq845XGkRwjng=; b=atQP4ypSJwNVYEYK3II82EbXpbbctraltaGNTiv1QVtOYrseDFPS8dJon5ZEv5VC4+ m4P02/KXLaohaNYpBHvss+B8v+kMkXmidLoMfuHJAo5fq7BsEjT2mHGJAkDgyv+KIdpZ lfs9giAxaLQmGPYv8T83HtSLeCyMJ/RIbvpxvOd8t74mblUg1CDbUKTb/YFXpgJwNuOL 6rg6oKQo6km4pPHI/Rwu95Lu+n7vVUWGYogziq3uEfoAjBimoyS9iIwsEj+jeZBgeBGI VMonb+nHU5rqdkVLD542ZGzIvgva8b9Dl4i97Ap34Jje2lBgkWHqNsvvfbIDQcAPoLbF 235Q== X-Gm-Message-State: AJaThX7YKDTPxhf4OwaYmHSqeQFx2JLZBfiFAjcN7jBMLWaQJEY+88uD Tqjl+fPa3zr7+SZHbKOSjxAQhPqg X-Google-Smtp-Source: AGs4zMaRPHHcpyxxp9rOOGcPcwanvaaTx1a8Q/Qym5jJK7BisD+fqJdo38eafLfsz6gIQ2LADz38VA== X-Received: by 10.176.20.143 with SMTP id d15mr20721190uae.52.1511668658564; Sat, 25 Nov 2017 19:57:38 -0800 (PST) Received: from MacBook-Pro-de-admin-alejandro.local ([190.142.54.95]) by smtp.gmail.com with ESMTPSA id t186sm4231457vkb.29.2017.11.25.19.57.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Nov 2017 19:57:38 -0800 (PST) To: dnsop@ietf.org References: <20171125185141.GA17868@server.ds9a.nl> From: Alejandro Acosta Message-ID: <47b40278-959a-1d0b-9eb1-8543087cdc16@gmail.com> Date: Sat, 25 Nov 2017 23:57:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171125185141.GA17868@server.ds9a.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: es-ES Archived-At: Subject: Re: [DNSOP] IVIPTR: New RR for DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Nov 2017 03:57:41 -0000 Hello there, El 25/11/17 a las 2:51 p.m., bert hubert escribió: > On Sat, Nov 25, 2017 at 10:41:13PM +0500, Tariq Saraj wrote: >> Please provide your valuable feedback on the newly uploaded draft. >> draft-tariq-dnsop-iviptr-00 >> >> *IVIPTR: Resource Record for DNS* > Hello Tariq, > > I have read through this draft and it left me pretty confused, both in terms > of the motivation and the practicalities.   The draft is very interesting but I do have exactly this very same question: motivation.    I think the authors have faced an issue that we don't know. Thanks, > > If understand it correctly, the idea is to find the 'corresponding' IPv4 > address to an IPv6 address? And that this could then be applied to > transposing access control list rules from one protocol to the other? > > In other words, I could have something like 'allow from 192.0.2.1', and > through an IVIPTR lookup, this could be mirrored to 'allow from > 2001::db8::2:1'? Can you confirm that this is the intended goal? > > In terms of practicalities, I implement both resolving and authoritative > nameservers, and your section 3 and 4 leave me confused if I have to do > anything or not, except support the record format. The wording is very hard > to follow and could do with a lot more whitespace and perhaps enumerated > steps. > > If it turns out that resolvers or authoritative servers need to do something > special, your draft should definitely talk about how to cope with servers > that do not perform such special processing. > > Good luck! > > Bert > > >> >> -- >> Regards >> Tariq Saraj >> Riphah Institute of Systems Engineering, Islamabad >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Sun Nov 26 00:03:46 2017 Return-Path: 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 CE285128DF3 for ; Sun, 26 Nov 2017 00:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ooGn_euXaMCk for ; Sun, 26 Nov 2017 00:03:43 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E28128DF2 for ; Sun, 26 Nov 2017 00:03:42 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id m191so17808068itg.2 for ; Sun, 26 Nov 2017 00:03:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NWsHa/WyJy7OzXGlvmhojfJTjP7et9FzAYorgdAia/o=; b=lwu1RQyjNYvrnLzFm6H4wgEQ4z5wuCt2XqEwHo5z+s4IsNhO047YEhY9WWJbmGKbXa hgmjk24M7jRT6CLQ9PSYbocGgorAV1Eho3c+E8MFBBwwOCQlf3uFdBOUN4R1sorToeQW +rwMDyK7WHv0jJDpDz3KsZl5go6SyvHw6s1TQtrvMjONwIqZV7jxFbRYp6rUEHw0UsY7 EnhfomCj0naEYTxV33Trp9EBbj9sFoIeW0AylnK3JlxA0LgoH0bRj3sWhTCZ5VgGOxE5 cCIU7rlEBpAzTvqjAd+h2xDRB3C2FWUrfWZCsjDrO5JPjo6Tefz422tPoXEcg9QjWBIa EbYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NWsHa/WyJy7OzXGlvmhojfJTjP7et9FzAYorgdAia/o=; b=X3ER75mKGb6tan5tZobPUhDbM4rN25mLjMLokTVe0WX1gz9DkaWaKMeJc++jJFfPlz GoJczmK5UTyAX1Z8ONGKWfp7b32BBYbQ0qnSH0gVqoIC3FMyBvv2l2GYcMQkU74pglu4 rm4U5qRxKR6GGWfAMoDu2fw0SmeGno0DFTl76Vk4WFjNAXyQg7zGjskLFew41AIOWpY4 nWFgw2LltptuMIAvmhCyOnGMGoj138TzDckjhK2abwSUH/r9U7Lh9IM7NxuatI+LjIEz TNiouaMIf8ftcJ47znrmrjO1dB1iFgRqQuW5Lb/ia4FdBS9qdz3xMrBBkEvtnGrvaI9m Zj4Q== X-Gm-Message-State: AJaThX5MGauz7eP0xhyFjZfXTuOXc+fLnmQIodaKCVRi/VettpYvBb9V 3OXxwAMFuYqkj3Tk6akztMKKceKDDU7BR2ObbtE= X-Google-Smtp-Source: AGs4zMZ/k7eY/8DK3fgEGIJx/ltnson1mCKJPePBc10T4lsghNZFWx4KuCo050TRpVEa8rXCrakLfhlwn2p3TGY4OLA= X-Received: by 10.36.182.2 with SMTP id g2mr18421009itf.34.1511683422136; Sun, 26 Nov 2017 00:03:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.69.73 with HTTP; Sun, 26 Nov 2017 00:03:41 -0800 (PST) In-Reply-To: <20171125185141.GA17868@server.ds9a.nl> References: <20171125185141.GA17868@server.ds9a.nl> From: Tariq Saraj Date: Sun, 26 Nov 2017 13:03:41 +0500 Message-ID: To: bert hubert Cc: dnsop@ietf.org Content-Type: multipart/alternative; boundary="089e08200cdc63ab8d055ede392b" Archived-At: Subject: Re: [DNSOP] IVIPTR: New RR for DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Nov 2017 08:03:45 -0000 --089e08200cdc63ab8d055ede392b Content-Type: text/plain; charset="UTF-8" Hello Bert, Thank you very much, yes you are 100% right about the intended goal of the IVIPTR RR. About Section 3 and 4, I totally agreed, and will explain it with more clarity specially the query processing. I am currently working on POC and in the next version of draft before uploading it I will resolve all the concerns on the mailing list. Once again thank you very much for your valuable time and response. On Sat, Nov 25, 2017 at 11:51 PM, bert hubert wrote: > On Sat, Nov 25, 2017 at 10:41:13PM +0500, Tariq Saraj wrote: > > Please provide your valuable feedback on the newly uploaded draft. > > draft-tariq-dnsop-iviptr-00 > > > > *IVIPTR: Resource Record for DNS* > > Hello Tariq, > > I have read through this draft and it left me pretty confused, both in > terms > of the motivation and the practicalities. > > If understand it correctly, the idea is to find the 'corresponding' IPv4 > address to an IPv6 address? And that this could then be applied to > transposing access control list rules from one protocol to the other? > > In other words, I could have something like 'allow from 192.0.2.1', and > through an IVIPTR lookup, this could be mirrored to 'allow from > 2001::db8::2:1'? Can you confirm that this is the intended goal? > > In terms of practicalities, I implement both resolving and authoritative > nameservers, and your section 3 and 4 leave me confused if I have to do > anything or not, except support the record format. The wording is very hard > to follow and could do with a lot more whitespace and perhaps enumerated > steps. > > If it turns out that resolvers or authoritative servers need to do > something > special, your draft should definitely talk about how to cope with servers > that do not perform such special processing. > > Good luck! > > Bert > > > > > > > > -- > > Regards > > Tariq Saraj > > Riphah Institute of Systems Engineering, Islamabad > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > -- Regards Tariq Saraj Riphah Institute of Systems Engineering, Islamabad --089e08200cdc63ab8d055ede392b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Bert,=C2=A0
Thank you very much, yes = you are 100% right about the intended goal of the IVIPTR RR.=C2=A0
About Section 3 and 4, I totally agreed, and will explain it with more cl= arity specially the query processing. I am currently working on POC and in = the next version of draft before uploading it I will resolve all the concer= ns on the mailing list.
Once again thank you very much for your v= aluable time and response.=C2=A0

=
On Sat, Nov 25, 2017 at 11:51 PM, bert hubert <bert.hubert@powerdns.com> wrote:
On Sat, Nov 25, 2017 at 10:41:13PM +0500, Tariq Saraj w= rote:
> Please provide your valuable feedback on the newly uploaded draft.
> draft-tariq-dnsop-iviptr-00
> <https://datatracker.ietf.o= rg/doc/draft-tariq-dnsop-iviptr/>
> *IVIPTR: Resource Record for DNS*

Hello Tariq,

I have read through this draft and it left me pretty confused, both in term= s
of the motivation and the practicalities.

If understand it correctly, the idea is to find the 'corresponding'= IPv4
address to an IPv6 address?=C2=A0 And that this could then be applied to transposing access control list rules from one protocol to the other?

In other words, I could have something like 'allow from 192.0.2.1',= and
through an IVIPTR lookup, this could be mirrored to 'allow from
2001::db8::2:1'? Can you confirm that this is the intended goal?

In terms of practicalities, I implement both resolving and authoritative nameservers, and your section 3 and 4 leave me confused if I have to do
anything or not, except support the record format. The wording is very hard=
to follow and could do with a lot more whitespace and perhaps enumerated steps.

If it turns out that resolvers or authoritative servers need to do somethin= g
special, your draft should definitely talk about how to cope with servers that do not perform such special processing.

Good luck!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bert


>
>
> --
> Regards
> Tariq Saraj
> Riphah Institute of Systems Engineering, Islamabad

> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop=




--
Regards
Tariq Saraj
Riphah Institute of Sy= stems Engineering, Islamabad

=
--089e08200cdc63ab8d055ede392b-- From nobody Mon Nov 27 01:32:16 2017 Return-Path: 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 54E3A124239 for ; Mon, 27 Nov 2017 01:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IN6QcI797vle for ; Mon, 27 Nov 2017 01:32:14 -0800 (PST) Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3DAB1200F3 for ; Mon, 27 Nov 2017 01:32:13 -0800 (PST) Received: from exit1.ipredator.se ([197.231.221.211] helo=[127.0.0.1]) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1eJFoJ-00013V-8B for dnsop@ietf.org; Mon, 27 Nov 2017 09:34:43 +0000 To: dnsop@ietf.org References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> From: Shane Kerr Message-ID: <57628d3a-93ef-567d-09ca-a2b37112a544@time-travellers.org> Date: Mon, 27 Nov 2017 09:32:00 +0000 MIME-Version: 1.0 In-Reply-To: <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 09:32:15 -0000 Joe, Joe Abley: > Hi Fred, > > [I haven't read Jordi's draft; I'm just responding to what I've read in this thread.] Me too. > On Nov 25, 2017, at 14:00, Fred Baker wrote: > >> One thing you might want to think about: the root servers are all IPv6-capable today and serve requests using IPv6, and the 1541 TLDs are all required by contract with ICANN to be IPv6-capable. I think you'll find yourself holding the burden of proof that the infrastructure isn't capable of IPv6-only operation today. > > monster:~]% egrep -c '^[A-Z]' /usr/share/misc/iso3166 > 249 > [monster:~]% > > There are potentially 249 TLDs that are not operated under any such contract with ICANN, although I agree that the majority of ccTLDs have at least one nameserver that is v6-capable (maybe all, but I haven't checked and I wouldn't want to assume). No, not all. I just ran a check, and there are 23 TLD without any name servers that support IPv6. (There is also one TLD which is timing out on most queries and returning SERVFAIL on the ones that are up.) Also note that ICANN IDN ccTLD are also excluded from any IPv6 requirement, as are "historical" TLD like .EDU and .GOV (although .MIL is the only such TLD without IPv6 support today). Personally I think it was a mistake to exclude IDN ccTLD from an IPv6 requirement, although I am assured that any such requirement was completely impossible due to political reasons. Incidentally I brought the idea that we should help get IPv6 for all ccTLD up a couple years ago on the OARC DNS operations list. I was was called an imperialist pig for making such a suggestion. *shrug* Cheers, -- Shane "not bitter at all" Kerr From nobody Mon Nov 27 01:44:06 2017 Return-Path: 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 15447127B73; Mon, 27 Nov 2017 01:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 jR3mSPTR7SJ0; Mon, 27 Nov 2017 01:44:01 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 B9FAE127B5A; Mon, 27 Nov 2017 01:44:01 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 5A09E280B8D; Mon, 27 Nov 2017 10:43:59 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 53274281DB4; Mon, 27 Nov 2017 10:43:59 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 4C216280B8D; Mon, 27 Nov 2017 10:43:59 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 48B086423520; Mon, 27 Nov 2017 10:43:59 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 3D50F40034; Mon, 27 Nov 2017 10:43:59 +0100 (CET) Date: Mon, 27 Nov 2017 10:43:59 +0100 From: Stephane Bortzmeyer To: JORDI PALET MARTINEZ Cc: sunset4@ietf.org, dnsop@ietf.org, 6man@ietf.org, v6sop@ietf.org Message-ID: <20171127094359.z3asfj72vvur27pr@nic.fr> References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000077, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.11.27.93316 Archived-At: Subject: Re: [DNSOP] FW: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 09:44:05 -0000 On Fri, Nov 24, 2017 at 09:36:11PM +0100, JORDI PALET MARTINEZ wrote a message of 54 lines which said: > I’ve posted “Towards a Worldwide IPv6-Ready DNS Infrastructure” > > https://datatracker.ietf.org/doc/draft-palet-sunset4-ipv6-ready-dns/ Besides the good remarks on ccTLDs that you already had (management of ccTLDs is not ICANN's business), a few remarks: > In general, that means having AAAA RRs in addition to A RRs, > ensuring that PMTUD works correctly and fragmentation is correctly > handled. The problem is that it is not entirely in the hands of the manager of the DNS authoritative server: the problem may be on the client side. And it is hard for the sysadmin of an authoritative DNS server to know if his clients received the fragments. > 1. Root and TLDs MUST be IPv6-Ready in 6 months. The ICANN root is IPv6-ready for a long time. Otherwise, the experience of Yeti draft-song-yeti-testbed-experience might be useful. > 2. Authoritative NS MUST be IPv6-Ready in 12 months. At every level in the DNS tree? Noble goal but which seems completely unrealistic. How will you convince Joe User, who manages the NS for foo.bar.example.com to act? From nobody Mon Nov 27 01:46:22 2017 Return-Path: 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 3B114127B5A; Mon, 27 Nov 2017 01:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 NKTG00pevSS8; Mon, 27 Nov 2017 01:46:10 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 41D24127B31; Mon, 27 Nov 2017 01:46:10 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id D3ADF280B8D; Mon, 27 Nov 2017 10:46:08 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id CC459281DB4; Mon, 27 Nov 2017 10:46:08 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id C566D280B8D; Mon, 27 Nov 2017 10:46:08 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id C1FB76423520; Mon, 27 Nov 2017 10:46:08 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id BBB9540034; Mon, 27 Nov 2017 10:46:08 +0100 (CET) Date: Mon, 27 Nov 2017 10:46:08 +0100 From: Stephane Bortzmeyer To: Bob Harold Cc: jordi.palet@consulintel.es, IETF DNSOP WG , 6man@ietf.org, v6sop@ietf.org, sunset4@ietf.org Message-ID: <20171127094608.2usyoujtzv2k5unx@nic.fr> References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000003, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.11.27.93916 Archived-At: Subject: Re: [DNSOP] FW: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 09:46:11 -0000 On Fri, Nov 24, 2017 at 10:00:54PM -0500, Bob Harold wrote a message of 203 lines which said: > - DNS64 breaks DNSSEC. That's not a fair summary. People should read RFC 6147 and 7050 before repeating this. From nobody Mon Nov 27 01:50:27 2017 Return-Path: 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 6AB1B127B31; Mon, 27 Nov 2017 01:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 W3Z5t_x6om7d; Mon, 27 Nov 2017 01:50:25 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 EBCF6127419; Mon, 27 Nov 2017 01:50:24 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 87349281E21; Mon, 27 Nov 2017 10:50:23 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 7ED78281E66; Mon, 27 Nov 2017 10:50:23 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 77DA9281E21; Mon, 27 Nov 2017 10:50:23 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 74B9D6423520; Mon, 27 Nov 2017 10:50:23 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 6E6BC40034; Mon, 27 Nov 2017 10:50:23 +0100 (CET) Date: Mon, 27 Nov 2017 10:50:23 +0100 From: Stephane Bortzmeyer To: Joe Abley Cc: Fred Baker , "v6ops@ietf.org WG" , 6man@ietf.org, Daniel Karrenberg , dnsop@ietf.org, sunset4@ietf.org Message-ID: <20171127095023.tv7bu2mmemj6su4d@nic.fr> References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.11.27.93916 Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 09:50:26 -0000 On Sat, Nov 25, 2017 at 06:45:52PM -0500, Joe Abley wrote a message of 28 lines which said: > I think it's uncontroversial to suggest without citation that not > all resolvers used by end-users today are v6-capable, See this experience . It was three years ago, we can re-run it but I'm afraid it will show that it is still the case. Quote: "As expected, the success rate with IPv6-only domain names (around two thirds) is much lower than with "mixed" domain names. We are not yet ready to switch off IPv4 . If you serve a domain name only on IPv6 name servers, you will get less traffic (and probably less spam, too)." From nobody Mon Nov 27 01:52:16 2017 Return-Path: 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 99271127B31 for ; Mon, 27 Nov 2017 01:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 k0bGx2uZfQrZ for ; Mon, 27 Nov 2017 01:52:13 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 ABA9D127419 for ; Mon, 27 Nov 2017 01:52:13 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 493B6281EAE; Mon, 27 Nov 2017 10:52:12 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 43086281F1B; Mon, 27 Nov 2017 10:52:12 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 3C3C7281EAE; Mon, 27 Nov 2017 10:52:12 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 397C36423520; Mon, 27 Nov 2017 10:52:12 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 3290040034; Mon, 27 Nov 2017 10:52:12 +0100 (CET) Date: Mon, 27 Nov 2017 10:52:12 +0100 From: Stephane Bortzmeyer To: Shane Kerr Cc: dnsop@ietf.org Message-ID: <20171127095212.dkdgl5dkqn56arvh@nic.fr> References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> <57628d3a-93ef-567d-09ca-a2b37112a544@time-travellers.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57628d3a-93ef-567d-09ca-a2b37112a544@time-travellers.org> X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.11.27.94216 Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 09:52:14 -0000 On Mon, Nov 27, 2017 at 09:32:00AM +0000, Shane Kerr wrote a message of 45 lines which said: > I just ran a check, and there are 23 TLD without any name servers > that support IPv6. Can you detail the methodology? For instance, did you measure what the root announces (the glue records), what the TLD announces (the authoritative AAAA records) or the reality (actual answers to DNS requets over IPv6). From nobody Mon Nov 27 02:31:38 2017 Return-Path: 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 B13D312714F for ; Mon, 27 Nov 2017 02:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 coPVWyTcS7E0 for ; Mon, 27 Nov 2017 02:31:34 -0800 (PST) Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8AFC1250B8 for ; Mon, 27 Nov 2017 02:31:34 -0800 (PST) Received: from exit-01a.noisetor.net ([173.254.216.66] helo=[127.0.0.1]) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1eJGjk-0001xm-6W; Mon, 27 Nov 2017 10:34:04 +0000 To: Stephane Bortzmeyer Cc: dnsop@ietf.org References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> <57628d3a-93ef-567d-09ca-a2b37112a544@time-travellers.org> <20171127095212.dkdgl5dkqn56arvh@nic.fr> From: Shane Kerr Message-ID: <5abc6b0f-face-a777-22c7-fe3d3afeea96@time-travellers.org> Date: Mon, 27 Nov 2017 10:31:00 +0000 MIME-Version: 1.0 In-Reply-To: <20171127095212.dkdgl5dkqn56arvh@nic.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 10:31:37 -0000 Stephane, Stephane Bortzmeyer: > On Mon, Nov 27, 2017 at 09:32:00AM +0000, > Shane Kerr wrote > a message of 45 lines which said: > >> I just ran a check, and there are 23 TLD without any name servers >> that support IPv6. > > Can you detail the methodology? For instance, did you measure what the > root announces (the glue records), what the TLD announces (the > authoritative AAAA records) or the reality (actual answers to DNS > requets over IPv6). I cleaned it up a bit and put it on GitHub: https://github.com/shane-kerr/tldIPv6 In the README.md: "Next it goes through each TLD and does an NS lookup to get the authoritative list of name servers. It then tries each name server returned until it finds one with an AAAA record. If none of the name servers for a TLD have an AAAA record, then it is reported as not supporting IPv6." It wouldn't be too difficult to add checks to see that IPv6 works for at least one of the AAAA returned, but I was mostly just looking to see if each TLD is trying to provide IPv6, not how good of a job they are doing at it (although the results file does log TLD that fail to resolve at all, but that's a side effect of the process). :) Cheers, -- Shane From nobody Mon Nov 27 03:31:55 2017 Return-Path: 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 D7C4C12711E for ; Mon, 27 Nov 2017 03:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 nGg7LYkbCWRB for ; Mon, 27 Nov 2017 03:31:53 -0800 (PST) Received: from smtp.mu.afrinic.net (smtp.afrinic.net [IPv6:2001:43f8:90:606::169]) (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 AE059120725 for ; Mon, 27 Nov 2017 03:31:52 -0800 (PST) Received: from [2001:43f8:90:250:1033:df6d:5be2:5f29] (port=60268) by smtp.mu.afrinic.net with esmtpsa (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1eJHdY-000APf-4S for dnsop@ietf.org; Mon, 27 Nov 2017 11:31:44 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Daniel Shaw In-Reply-To: <201711190950.vAJ9oDBB030859@atl4mhob09.registeredsite.com> X-Pgp-Fingerprint: F49E C21E C756 BAB4 111A A824 1054 DE1B 27FB F3D4 Date: Mon, 27 Nov 2017 15:31:43 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1A384FE2-0AC0-4309-9B28-0C81EBE1E1E6@afrinic.net> References: <201711190950.vAJ9oDBB030859@atl4mhob09.registeredsite.com> To: dnsop@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 11:31:55 -0000 On 19/11/2017, 13:50, JW typed: >=20 >=20 > This draft was released a couple weeks ago and includes what we feel = are some very noteworthy changes. >=20 > Please take another look when you have time, as always we look forward = to and welcome any questions/ comments. >=20 I have uses cases where this would be handy. I hope that this = progresses. I'd love to see all those smarter than me work on it, so support = adoption. Regards, Daniel From nobody Mon Nov 27 03:33:26 2017 Return-Path: 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 D2A86120725 for ; Mon, 27 Nov 2017 03:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 7OOGhT8x4O2J for ; Mon, 27 Nov 2017 03:33:18 -0800 (PST) Received: from smtp.mu.afrinic.net (smtp.afrinic.net [IPv6:2001:43f8:90:606::169]) (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 077EA12711E for ; Mon, 27 Nov 2017 03:33:15 -0800 (PST) Received: from [2001:43f8:90:250:1033:df6d:5be2:5f29] (port=60284) by smtp.mu.afrinic.net with esmtpsa (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1eJHew-000AWG-Rw for dnsop@ietf.org; Mon, 27 Nov 2017 11:33:10 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Daniel Shaw In-Reply-To: X-Pgp-Fingerprint: F49E C21E C756 BAB4 111A A824 1054 DE1B 27FB F3D4 Date: Mon, 27 Nov 2017 15:33:10 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <855571E9-0D67-45BF-91FD-B1F83B1E3606@afrinic.net> References: To: dnsop X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 11:33:25 -0000 On 16/11/2017, 12:23, tjw ietf typed: >=20 > All >=20 > The author has rolled out a new version addressing comments from the = meeting on Monday, and we feel it=E2=80=99s ready to move this along. >=20 > This starts a Call for Adoption for draft-huston-kskroll-sentinel Support adoption too. Thanks, Daniel From nobody Mon Nov 27 03:54:45 2017 Return-Path: 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 16311127A91 for ; Mon, 27 Nov 2017 03:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 xu15cFnce-cR for ; Mon, 27 Nov 2017 03:54:42 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ECA3124BFA for ; Mon, 27 Nov 2017 03:54:41 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id d125so31987113qkc.12 for ; Mon, 27 Nov 2017 03:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i0eQl3ZDj2eHDra/3EvYC7C4kSaiVXneY0TdMMN4pbo=; b=KGD1St6Rzr9DMc8MARZQx1CwzZrZLBCJpCTNwngf112NLUy4jEJTz7Cjl9BK5LSyO1 ni8Rn4WLf0eEu/ETeOaR1orTVMUfmbyizi/DVOYKG3OtixvLqie92geLJEBfPeLvoR34 H6TchSVOxT53P1I0Apsa4Jm3JXZJTc5477ud0Ufp2b+ZVY7huh6a3Q5n1njWVNOA2CGn cSKij68ri4FQvp+Vi5YXIqwkgntAsYbZq/O74pyNIB2tnfY6sVVvfyH0ok01PZhTvogT 6Q6hHaFAZqim4bYeN7pFNw7891Xwj/F82yCHBN8hdbI7gXFZSSaTRyrM+OON9+jYp3/l 2liA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i0eQl3ZDj2eHDra/3EvYC7C4kSaiVXneY0TdMMN4pbo=; b=j69Fd9TjEuAmb5MBe7sFjBfxemuKx+gnXKahQX5JblqfVTm0SnvypCrCKsw2Ay8OrU NE8pRkfIpqUH8LZBS0RpYOPNrgbXSlvQlXUjr6EeewbFaeGEJMSTxl5NJZUJNtEOHEIp rC+UTrWEVgMFufB3YhUv76CP7KWlx6AP80D0M6EwPifuRDxz24XE9z4iB3fglOGRyZ7R ECJIevX878r2TRaWPDZU/75wKFboPEnU6BcmaamlLB2C1KrbBNC9hcXqdZJKJ4v1auqz 86xWqiwpUO88i+mbfbk6McsO5omwkd9AvPJssRW9Ffr412X3wP53IA1W6rWyRqArRsE1 7g0g== X-Gm-Message-State: AJaThX6qvNVKHkNNp1h/Ue/rECdDTV+oekm9udBKVqUCCpXmyluAcIjy v2161+vhDJwR9O2Q/74EgOvv/g1vAmDBbY4L+nR661Di X-Google-Smtp-Source: AGs4zMY3yyW6TwiWisWL+sSOtVDwKpaGbqM1ajFB6ouF6oaYFGCYYzVMGXSKUfT9S4xcF75rzhd1leNM7haYPnttSX0= X-Received: by 10.55.175.70 with SMTP id y67mr14106590qke.173.1511783680665; Mon, 27 Nov 2017 03:54:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.6.146 with HTTP; Mon, 27 Nov 2017 03:54:20 -0800 (PST) In-Reply-To: References: <57BD04DF-B473-41B8-9ECD-D197232365FB@fugue.com> From: Mike West Date: Mon, 27 Nov 2017 12:54:20 +0100 Message-ID: To: Richard Barnes Cc: Ted Lemon , dnsop WG Content-Type: multipart/alternative; boundary="94eb2c06e78e445d24055ef5910c" Archived-At: Subject: Re: [DNSOP] `localhost` and DNS. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 11:54:44 -0000 --94eb2c06e78e445d24055ef5910c Content-Type: text/plain; charset="UTF-8" Post-{IETF,Thanksgiving} ping. Feedback (or further +1's!) would be appreciated. :) -mike On Thu, Nov 16, 2017 at 1:01 AM, Richard Barnes wrote: > > > On Thu, Nov 16, 2017 at 5:05 AM, Ted Lemon wrote: > >> On Nov 15, 2017, at 10:51 PM, Mike West wrote: >> >> Skimming through the recording of Monday's meeting >> (starting >> at around 53:56), it sounds to me as though there's at least loose >> agreement that signing a response for `localhost` is not what we'd like to >> recommend: all the folks who commented explicitly took that position for >> similar reasons. The current text in https://tools.ietf.org/html >> /draft-ietf-dnsop-let-localhost-be-localhost-01#section-4.2 reflects >> this position, and IMO it's what we should run with. >> >> >> Yes, the current text appears to me to be correct. >> > > +1 > > > >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> > --94eb2c06e78e445d24055ef5910c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Post-{IETF,Thanksgiving} ping. Feedback (or further +1'= ;s!) would be appreciated. :)

<= div>
-mike=

On Thu, Nov 16, 2017 at 1:01 AM, Richard Bar= nes <r= lb@ipv.sx> wrote:


On Thu, Nov 16, 2017 at 5:05 AM, Ted Lemon <mellon@fugue= .com> wrote:
On Nov 15, 2017, at 10:51 PM, Mike West <mkwst@google.com>= wrote:
Skimming through the=C2=A0recording of Monday's meeting= =C2=A0(starting at around 53:56), it sounds to me as though there's at = least loose agreement that signing a response for `localhost` is not what w= e'd like to recommend: all the folks who commented explicitly took that= position for similar reasons. The current text in=C2=A0https://tools.ietf.org/html/draft-ietf-dnsop-le= t-localhost-be-localhost-01#section-4.2=C2=A0reflects this po= sition, and IMO it's what we should run with.
<= /div>
Yes, the current text appears to me to be correct.

+1

<= /div>
=C2=A0


_______________________________= ________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop



--94eb2c06e78e445d24055ef5910c-- From nobody Mon Nov 27 04:28:24 2017 Return-Path: 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 6366A128961; Mon, 27 Nov 2017 04:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 PTWoYauQKwH6; Mon, 27 Nov 2017 04:28:20 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 6C330124D37; Mon, 27 Nov 2017 04:28:20 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:40409) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eJIWG-000LA0-1X (Exim 4.89) (return-path ); Mon, 27 Nov 2017 12:28:16 +0000 Date: Mon, 27 Nov 2017 12:28:16 +0000 From: Tony Finch To: Joe Abley cc: Fred Baker , "v6ops@ietf.org WG" , 6man@ietf.org, Daniel Karrenberg , dnsop@ietf.org, sunset4@ietf.org In-Reply-To: <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> Message-ID: References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] [v6ops] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 12:28:22 -0000 Joe Abley wrote: > > There are potentially 249 TLDs that are not operated under any such > contract with ICANN, although I agree that the majority of ccTLDs have > at least one nameserver that is v6-capable (maybe all, but I haven't > checked and I wouldn't want to assume). Quick root zone stats: zones 1542 servers 4216 Most servers are dual-stacked; 539 are v4-only, and 2 are v6-only (j.zdnscloud.com and i.zdnscloud.com). The 31 TLDs with no v6 nameservers: ai. bb. bh. ck. dj. fk. gf. hm. kp. mh. mil. mp. mq. mv. ni. pf. pk. sl. sr. st. to. uz. ws. xn--l1acc. xn--lgbbat1ad8j. xn--mgba3a4f16a. xn--mgbai9azgqp6j. xn--wgbh1c. xn--ygbi2ammx. ye. zw. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Biscay, Fitzroy: Variable 3 or 4 until later in south, otherwise westerly 5 or 6, veering northwesterly 4 or 5, except in south Fitzroy, becoming northeasterly 5 or 6 in southeast Fitzroy. Slight at first in south, ohterwise moderate or rough. Rain or squally showers. Moderate or good. From nobody Mon Nov 27 04:54:34 2017 Return-Path: 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 4747E128616 for ; Mon, 27 Nov 2017 04:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no 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 Zn6HiVbu_0ic for ; Mon, 27 Nov 2017 04:54:30 -0800 (PST) Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D42F12711E for ; Mon, 27 Nov 2017 04:54:30 -0800 (PST) Received: from [65.19.167.132] (helo=[127.0.0.1]) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1eJIy4-0003x3-BY; Mon, 27 Nov 2017 12:57:01 +0000 From: Shane Kerr To: Tony Finch Cc: dnsop@ietf.org References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> Message-ID: <287a9276-9e7a-5031-cded-55f4514d9bf6@time-travellers.org> Date: Mon, 27 Nov 2017 12:54:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] [v6ops] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 12:54:32 -0000 Tony, Tony Finch: > Joe Abley wrote: >> >> There are potentially 249 TLDs that are not operated under any such >> contract with ICANN, although I agree that the majority of ccTLDs have >> at least one nameserver that is v6-capable (maybe all, but I haven't >> checked and I wouldn't want to assume). > > Quick root zone stats: > > zones 1542 > servers 4216 > > Most servers are dual-stacked; 539 are v4-only, and 2 are v6-only > (j.zdnscloud.com and i.zdnscloud.com). > > The 31 TLDs with no v6 nameservers: > > ai. [ snippity ] > zw. Your list is missing bf., which does not appear to have any IPv6 name servers right now. It also counts quite a few more than my checks: gf. mq. mh. mv. ni. xn--lgbbat1ad8j. ye. zw. I'm not sure what your methodology is exactly, but I put mine on GitHub: https://github.com/shane-kerr/tldIPv6 My guess is that you just looked at the root zone itself, since I see that bf. has IPv6 glue: ;; AUTHORITY SECTION: bf. 172800 IN NS nahouri.onatel.bf. bf. 172800 IN NS ns-bf.afrinic.net. bf. 172800 IN NS censvrns0001.ird.fr. ;; ADDITIONAL SECTION: ns-bf.afrinic.net. 172800 IN AAAA 2001:43f8:120::34 nahouri.onatel.bf. 172800 IN A 206.82.130.196 ns-bf.afrinic.net. 172800 IN A 196.216.168.34 censvrns0001.ird.fr. 172800 IN A 91.203.32.147 Whereas zw. does not: zw. 172800 IN NS ns2.telone.co.zw. zw. 172800 IN NS ns3.telone.co.zw. zw. 172800 IN NS ns2.gip.net. zw. 172800 IN NS ns1.telone.co.zw. ;; ADDITIONAL SECTION: ns1.telone.co.zw. 172800 IN A 194.133.122.47 ns2.gip.net. 172800 IN A 204.59.1.222 ns2.telone.co.zw. 172800 IN A 194.133.122.42 ns3.telone.co.zw. 172800 IN A 194.133.122.34 Probably I should update my code to *ALSO* check whether or not a zone has some usable IPv6 path either through glue or a name server under a TLD that supports IPv6. I suppose it can verify glue at the same time. (I'm not sure what happens in a resolver to a zone like bf., when below the zone cut IPv6 is *not* supported but above the zone cut it *is*, due to mismatched glue.) Cheers, -- Shane From nobody Mon Nov 27 05:22:56 2017 Return-Path: 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 587DF1286B1 for ; Mon, 27 Nov 2017 05:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 56LQ-gE4aoau for ; Mon, 27 Nov 2017 05:22:53 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 B092F1243FE for ; Mon, 27 Nov 2017 05:22:53 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:41763) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eJJN5-000H8Y-1V (Exim 4.89) (return-path ); Mon, 27 Nov 2017 13:22:51 +0000 Date: Mon, 27 Nov 2017 13:22:51 +0000 From: Tony Finch To: Joe Abley cc: "dnsop@ietf.org" , Havard Eidnes In-Reply-To: <5562271920774233970@unknownmsgid> Message-ID: References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> <5562271920774233970@unknownmsgid> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 13:22:55 -0000 Joe Abley wrote: > On Nov 23, 2017, at 12:44, Tony Finch wrote: > > > It's quite difficult to have multiple masters and DNSSEC and coherent > > copies of the zone from all masters - i.e. more effort than just spinning > > up parallel instances of BIND or Knot in automatic signing mode. > > Note that I wasn't talking about multiple signers; I was talking about > (from the perspective of one particular slave) having multiple masters > available to serve precisely the same zone. A primary master is wrt a zone not a server - a zone's primary master is a server that's authoritative for a zone and which does not get the zone contents via axfr/ixfr, but instead from a master file and/or UPDATE (or a non-standard mechanism such as directly from a database). The term says nothing about the downstream xfer topology. You can very well having a primary master (plus backup(s)) feeding a cluster of distribution servers which in turn feed the public authoritative servers. The xfer topology doesn't have to be a tree, it doesn't even have to be an acyclic graph. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode German Bight, Humber: West becoming cyclonic 5 to 7, increasing gale 8 or severe gale 9 for a time. Moderate or rough, occasionally very rough. Rain or squally showers. Moderate or good, occasionally poor. From nobody Mon Nov 27 05:29:19 2017 Return-Path: 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 49860124D37 for ; Mon, 27 Nov 2017 05:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 UuKWOZvhwmEM for ; Mon, 27 Nov 2017 05:29:16 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811631243FE for ; Mon, 27 Nov 2017 05:29:16 -0800 (PST) Received: from [172.31.0.2] (unknown [222.128.198.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 5B19361FA2; Mon, 27 Nov 2017 13:29:13 +0000 (UTC) Date: Mon, 27 Nov 2017 13:29:06 +0000 User-Agent: K-9 Mail for Android In-Reply-To: References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> <5562271920774233970@unknownmsgid> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----FPSO2L29RZBYM0V8S7J67U94B9D44R" Content-Transfer-Encoding: 7bit To: dnsop@ietf.org,Tony Finch ,Joe Abley From: P Vix Message-ID: <28E91E70-1D56-404E-BE87-C17A49FB683B@redbarn.org> Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 13:29:18 -0000 ------FPSO2L29RZBYM0V8S7J67U94B9D44R Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Exactly=2E On November 27, 2017 9:22:51 PM GMT+08:00, Tony Finch wro= te: >Joe Abley wrote: >> On Nov 23, 2017, at 12:44, Tony Finch wrote: >> >> > It's quite difficult to have multiple masters and DNSSEC and >coherent >> > copies of the zone from all masters - i=2Ee=2E more effort than just >spinning >> > up parallel instances of BIND or Knot in automatic signing mode=2E >> >> Note that I wasn't talking about multiple signers; I was talking >about >> (from the perspective of one particular slave) having multiple >masters >> available to serve precisely the same zone=2E > >A primary master is wrt a zone not a server - a zone's primary master >is >a server that's authoritative for a zone and which does not get the >zone >contents via axfr/ixfr, but instead from a master file and/or UPDATE >(or >a non-standard mechanism such as directly from a database)=2E > >The term says nothing about the downstream xfer topology=2E You can very >well having a primary master (plus backup(s)) feeding a cluster of >distribution servers which in turn feed the public authoritative >servers=2E >The xfer topology doesn't have to be a tree, it doesn't even have to be >an >acyclic graph=2E > >Tony=2E >--=20 >f=2Eanthony=2En=2Efinch http://dotat=2Eat/ - I xn--z= r8h >punycode >German Bight, Humber: West becoming cyclonic 5 to 7, increasing gale 8 >or >severe gale 9 for a time=2E Moderate or rough, occasionally very rough=2E >Rain or >squally showers=2E Moderate or good, occasionally poor=2E > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dnsop --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------FPSO2L29RZBYM0V8S7J67U94B9D44R Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Exactly=2E

On No= vember 27, 2017 9:22:51 PM GMT+08:00, Tony Finch <dot@dotat=2Eat> wro= te:
Joe Abley <jabley@hopcount=2Eca> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; bord=
er-left: 1px solid #729fcf; padding-left: 1ex;"> On Nov 23, 2017, at 12:44,=
 Tony Finch <dot@dotat=2Eat> wrote:

 It's quite difficult to have multiple masters a=
nd DNSSEC and coherent
 copies of the zone from all masters - i=2Ee=2E=
 more effort than just spinning
 up parallel instances of BIND or Knot=
 in automatic signing mode=2E

 Note that I wasn't t=
alking about multiple signers; I was talking about
 (from the perspect=
ive of one particular slave) having multiple masters
 available to ser=
ve precisely the same zone=2E

A primary master is w= rt a zone not a server - a zone's primary master is
a server that's au= thoritative for a zone and which does not get the zone
contents via ax= fr/ixfr, but instead from a master file and/or UPDATE (or
a non-standa= rd mechanism such as directly from a database)=2E

The term says = nothing about the downstream xfer topology=2E You can very
well having= a primary master (plus backup(s)) feeding a cluster of
distribution s= ervers which in turn feed the public authoritative servers=2E
The xfer= topology doesn't have to be a tree, it doesn't even have to be an
acy= clic graph=2E

Tony=2E

--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------FPSO2L29RZBYM0V8S7J67U94B9D44R-- From nobody Mon Nov 27 05:32:49 2017 Return-Path: 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 37590120726 for ; Mon, 27 Nov 2017 05:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 07uTbbIFwLLm for ; Mon, 27 Nov 2017 05:32:46 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 269001243FE for ; Mon, 27 Nov 2017 05:32:46 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:42051) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eJJWe-000RBG-0i (Exim 4.89) (return-path ); Mon, 27 Nov 2017 13:32:44 +0000 Date: Mon, 27 Nov 2017 13:32:44 +0000 From: Tony Finch To: Shane Kerr cc: dnsop@ietf.org In-Reply-To: <287a9276-9e7a-5031-cded-55f4514d9bf6@time-travellers.org> Message-ID: References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> <287a9276-9e7a-5031-cded-55f4514d9bf6@time-travellers.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] [v6ops] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 13:32:48 -0000 Shane Kerr wrote: > > Your list is missing bf., which does not appear to have any IPv6 name > servers right now. My copy of the root zone has the following: bf. 172800 IN NS ns-bf.afrinic.net. ns-bf.afrinic.net. 172800 IN AAAA 2001:43f8:120::34 > I'm not sure what your methodology is exactly, As I said, quick :-) #!/usr/bin/perl use warnings; use strict; my %v4; my %v6; my %ns; my %z; for my $rr (qx(dig axfr .)) { next unless $rr =~ m{^(\S+)\s+\d+\s+IN\s+(A|AAAA|NS)\s+(\S+)$}; if ($2 eq 'NS') { $z{$1}{$3} = 1; $ns{$3} = 1; } elsif ($2 eq 'A') { $v4{$1} = 1; } else { $v6{$1} = 1; } } my @v4 = keys %v4; my @v6 = keys %v6; my %v4only = %v4; delete @v4only{@v6}; my %v6only = %v6; delete @v6only{@v4}; printf "zones %d\n", scalar keys %z; printf "servers %d\n", scalar keys %ns; printf "v4 %d\n", scalar @v4; printf "v6 %d\n", scalar @v6; printf "v4 only %d\n", scalar keys %v4only; printf "v6 only %d\n", scalar keys %v6only; print "v6-only servers\n"; print map "$_\n", keys %v6only; print "v4-only TLDs\n"; my $n = 0; for my $z (sort keys %z) { my $v4; my $v6; for my $ns (keys %{$z{$z}}) { $v4 = 1 if $v4{$ns}; $v6 = 1 if $v6{$ns}; } print "$z\n" unless $v6; ++$n unless $v6; } print "v4-only TLDs $n\n"; exit; Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode East Forties: Cyclonic, mainly westerly, veering northerly, 5 to 7, increasing gale 8 at times. Moderate or rough. Rain then squally showers. Moderate or good. From nobody Mon Nov 27 05:37:11 2017 Return-Path: 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 B81D9128B90 for ; Mon, 27 Nov 2017 05:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 7TT0EI-GHVOk for ; Mon, 27 Nov 2017 05:36:58 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 EAD95128B8F for ; Mon, 27 Nov 2017 05:36:51 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id C3BE0281FF8; Mon, 27 Nov 2017 14:36:49 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id BDA45282138; Mon, 27 Nov 2017 14:36:49 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id B6D7C281FF8; Mon, 27 Nov 2017 14:36:49 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id B41D0642A7A1; Mon, 27 Nov 2017 14:36:49 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id ACE7D40034; Mon, 27 Nov 2017 14:36:49 +0100 (CET) Date: Mon, 27 Nov 2017 14:36:49 +0100 From: Stephane Bortzmeyer To: Tony Finch Cc: Shane Kerr , dnsop@ietf.org Message-ID: <20171127133649.mt3k3nigs2aquf72@nic.fr> References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> <287a9276-9e7a-5031-cded-55f4514d9bf6@time-travellers.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.11.27.132716 Archived-At: Subject: Re: [DNSOP] [v6ops] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 13:37:10 -0000 On Mon, Nov 27, 2017 at 01:32:44PM +0000, Tony Finch wrote a message of 78 lines which said: > My copy of the root zone has the following: Precisely. This name server is in the root zone but not in the .bf zone itself. To summarize the discussion: depending on whether your script is "child-centric" or "parent-centric", you'll get different results. Hard to quantify IPv6 :-) From nobody Mon Nov 27 05:38:18 2017 Return-Path: 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 DD19C128B37 for ; Mon, 27 Nov 2017 05:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 mI8AhKqQPC_7 for ; Mon, 27 Nov 2017 05:38:10 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 91E5E126CF6 for ; Mon, 27 Nov 2017 05:38:10 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:42142) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eJJbs-000XAp-1Q (Exim 4.89) (return-path ); Mon, 27 Nov 2017 13:38:08 +0000 Date: Mon, 27 Nov 2017 13:38:08 +0000 From: Tony Finch To: bert hubert cc: Tariq Saraj , dnsop@ietf.org In-Reply-To: <20171125185141.GA17868@server.ds9a.nl> Message-ID: References: <20171125185141.GA17868@server.ds9a.nl> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] IVIPTR: New RR for DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 13:38:17 -0000 bert hubert wrote: > > If understand it correctly, the idea is to find the 'corresponding' IPv4 > address to an IPv6 address? Why not 57.57.111.131.in-addr.arpa. 3406 IN PTR grey.csi.cam.ac.uk. 57.57.111.131.in-addr.arpa. 3600 IN AAAA 2001:630:212:110::d:7a7 7.a.7.0.d.0.0.0.0.0.0.0.0.0.0.0.0.1.1.0.2.1.2.0.0.3.6.0.1.0.0.2.ip6.arpa. 3600 IN PTR grey.csi.cam.ac.uk. 7.a.7.0.d.0.0.0.0.0.0.0.0.0.0.0.0.1.1.0.2.1.2.0.0.3.6.0.1.0.0.2.ip6.arpa. 3600 IN A 131.111.57.57 Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Viking, North Utsire, South Utsire: Cyclonic becoming northerly 5 to 7, occasionally gale 8 except in South Utsire. Moderate or rough, occasionally very rough later except in South Utsire. Rain then squally showers. Moderate or good. From nobody Mon Nov 27 06:27:43 2017 Return-Path: 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 5FACB1242EA for ; Mon, 27 Nov 2017 06:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 ovZTa1_RTMpW for ; Mon, 27 Nov 2017 06:27:41 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 3F77C1200FC for ; Mon, 27 Nov 2017 06:27:41 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id AEB4A280883; Mon, 27 Nov 2017 15:27:39 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id A81CB280AD3; Mon, 27 Nov 2017 15:27:39 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id A16CE280883; Mon, 27 Nov 2017 15:27:39 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 9E3E8663D901; Mon, 27 Nov 2017 15:27:39 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 9875940034; Mon, 27 Nov 2017 15:27:39 +0100 (CET) Date: Mon, 27 Nov 2017 15:27:39 +0100 From: Stephane Bortzmeyer To: Tony Finch Cc: bert hubert , Tariq Saraj , dnsop@ietf.org Message-ID: <20171127142739.3a3w6yv5wsje5m4y@nic.fr> References: <20171125185141.GA17868@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.11.27.141816 Archived-At: Subject: Re: [DNSOP] IVIPTR: New RR for DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 14:27:42 -0000 On Mon, Nov 27, 2017 at 01:38:08PM +0000, Tony Finch wrote a message of 24 lines which said: > Why not Section 1 of the draft explains "why not" but I disagree with their assessment. I think the PTR way is indeed the right one. From nobody Mon Nov 27 06:45:20 2017 Return-Path: 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 4A6B512895E for ; Mon, 27 Nov 2017 06:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 kaMHNKUkqjRW for ; Mon, 27 Nov 2017 06:45:17 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 042E6126D85 for ; Mon, 27 Nov 2017 06:45:17 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 89E10282186; Mon, 27 Nov 2017 15:45:15 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 843CF282194; Mon, 27 Nov 2017 15:45:15 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 7D6DF282186; Mon, 27 Nov 2017 15:45:15 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 7A968663E720; Mon, 27 Nov 2017 15:45:15 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 6E9C140034; Mon, 27 Nov 2017 15:45:15 +0100 (CET) Date: Mon, 27 Nov 2017 15:45:15 +0100 From: Stephane Bortzmeyer To: Tariq Saraj Cc: dnsop@ietf.org Message-ID: <20171127144515.4ol63kkaptnwmemn@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000209, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.11.27.143616 Archived-At: Subject: Re: [DNSOP] IVIPTR: New RR for DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 14:45:18 -0000 On Sat, Nov 25, 2017 at 10:41:13PM +0500, Tariq Saraj wrote a message of 60 lines which said: > Please provide your valuable feedback on the newly uploaded draft. > draft-tariq-dnsop-iviptr-00 > > *IVIPTR: Resource Record for DNS* The only use case you describe (firewall configuration) is questionable. Most firewall configuration interfaces allow you to use domain names instead of IP addresses. So, if I want to allow port 443 to www.example.com (which has IPv4 and IP v6 addresses), I can. Note that many firewall administrators don't use this because, rightly or wrongly, they don't trust the DNS. They'll have the same issue with your proposal. By the way, that's why you _need_ to write something in the Security Considerations, probably mentioning DNSSEC. Otherwise, I'm not convinced by your argument against using PTR. If people don't configure PTRs to get the effect you want, it may be because: * they don't want to (so they don't need your proposal) * they're lazy or incompetent (so they'll ignore your proposal) From nobody Mon Nov 27 08:34:19 2017 Return-Path: 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 38F18126C3D for ; Mon, 27 Nov 2017 08:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 uP1NWEhHVQgP for ; Mon, 27 Nov 2017 08:34:16 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D877912420B for ; Mon, 27 Nov 2017 08:34:15 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id t1so4580940ite.5 for ; Mon, 27 Nov 2017 08:34:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iFjVOgl8Exen0Xg5m+p8u8RRH0tzScMesK3UMLuQ3Og=; b=YVpT3nqB7jG/cCQvJWxj4Uq00skXAPI9qcNbXL585c+efaLh/YNe5M8XK2X5K+I+f4 LflQn2rdexNjsb2RozUfaTKuQbn5BjUgHs9E5/ned4pD0UN3NGHVnrEOT+JE8a3f5MtJ lffgZt2xHTAT240hsJYIW2RleMhYa4mEooWFk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iFjVOgl8Exen0Xg5m+p8u8RRH0tzScMesK3UMLuQ3Og=; b=rT9rNcwe5nYiZs6OxBLvtv7bQu4pZAX0CZTbZSilo2WKLWQgiYocDJ+gcMXwc/xb1R cCbxTpEXmd3VFtzryK9Yzdo5NnaxW/eSU3h2o8cuP4QUcIQs4JD6b8QoTUZsfXqGff41 Ky89Thlo9d1up9D5a2Z6kUDAftuQkl3RaIGmCyBL/MJYKYthUJxtkbEVSDfcmar2KmQG 7DeDBs9yUVNo/Z6oqpwPx9VPWEv/B8tj8qH5Qhj/qyfj43rCSgz5HGJWtkhGB8dJaQ4q HNSeQNTZLF9TeHXVGQnTTi2biszC6odz3GdsivkqrFsTUyfSDf80Ux6/hJpP7UYrsrtF yeMQ== X-Gm-Message-State: AJaThX5Vs2w6I7nOXv3rZxvaCHJlUrhZNmir+B7ZG9YCg89iYkYqIAR0 +IzwfFPE3/WZdpNi7H6Lf+3Ia5ujtCk= X-Google-Smtp-Source: AGs4zMYbLid1llX1BXD5b47i7++xIFytC5Syw7RQFNYb/VwKkwMs6EqBZTOZtBg26+eAXOS8oqd3HQ== X-Received: by 10.36.105.66 with SMTP id e63mr31320092itc.46.1511800454701; Mon, 27 Nov 2017 08:34:14 -0800 (PST) Received: from ?IPv6:2607:f2c0:101:3:b07e:ddeb:fe18:44cf? ([2607:f2c0:101:3:b07e:ddeb:fe18:44cf]) by smtp.gmail.com with ESMTPSA id a69sm4373630itc.18.2017.11.27.08.34.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 08:34:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (15B202) In-Reply-To: Date: Mon, 27 Nov 2017 11:34:11 -0500 Cc: "dnsop@ietf.org" , Havard Eidnes Content-Transfer-Encoding: quoted-printable Message-Id: <180576EC-BC7C-47E1-B3F1-87062260C018@hopcount.ca> References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> <5562271920774233970@unknownmsgid> To: Tony Finch Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 16:34:17 -0000 Hi Tony, On Nov 27, 2017, at 08:22, Tony Finch wrote: > Joe Abley wrote: >>> On Nov 23, 2017, at 12:44, Tony Finch wrote: >>>=20 >>> It's quite difficult to have multiple masters and DNSSEC and coherent >>> copies of the zone from all masters - i.e. more effort than just spinnin= g >>> up parallel instances of BIND or Knot in automatic signing mode. >>=20 >> Note that I wasn't talking about multiple signers; I was talking about >> (from the perspective of one particular slave) having multiple masters >> available to serve precisely the same zone. >=20 > A primary master is wrt a zone not a server - a zone's primary master is > a server that's authoritative for a zone and which does not get the zone > contents via axfr/ixfr, but instead from a master file and/or UPDATE (or > a non-standard mechanism such as directly from a database). That's an alluringly clear definition, but I'm not sure it matches common un= derstanding of the term, which I think has more to do with "single source of= truth" than with the specifics of what transport is used to provision zone d= ata in a server. For example, W <------- A -------> X Suppose A is a source of truth for a particular zone, and that W and X obtai= n zone data from A. Are you saying that if the mechanism represented by the a= rrows is [AI]XFR then A is a primary master and W and X are not, whereas if t= hat mechanism is something else (perhaps it's rsync, with W, A and X all con= figured to be masters from local zone files) then W, A and X are all primary= masters? If A is not a nameserver but instead is a database, and the arrows represent= database replication, then W and X are primary masters but A is not? Joe= From nobody Mon Nov 27 09:15:38 2017 Return-Path: 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 B259C128B4E for ; Mon, 27 Nov 2017 09:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 vpeftiX1pGOH for ; Mon, 27 Nov 2017 09:15:30 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 C3B1512895E for ; Mon, 27 Nov 2017 09:15:30 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:47446) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eJN01-000VvK-0n (Exim 4.89) (return-path ); Mon, 27 Nov 2017 17:15:28 +0000 Date: Mon, 27 Nov 2017 17:15:17 +0000 From: Tony Finch To: Joe Abley cc: "dnsop@ietf.org" , Havard Eidnes In-Reply-To: <180576EC-BC7C-47E1-B3F1-87062260C018@hopcount.ca> Message-ID: References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> <5562271920774233970@unknownmsgid> <180576EC-BC7C-47E1-B3F1-87062260C018@hopcount.ca> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 17:15:38 -0000 Joe Abley wrote: > > A primary master is wrt a zone not a server - a zone's primary master is > > a server that's authoritative for a zone and which does not get the zone > > contents via axfr/ixfr, but instead from a master file and/or UPDATE (or > > a non-standard mechanism such as directly from a database). > > That's an alluringly clear definition, but I'm not sure it matches > common understanding of the term, which I think has more to do with > "single source of truth" than with the specifics of what transport is > used to provision zone data in a server. Hmm, I think I sort-of agree, but with caveats... I prefer to make a clear distinction between the standard DNS as specified in the RFCs versus any funky non-standard stuff that people might do with the DNS. The standard DNS protocols are closely fitted to a particular distributed architecture, in which a zone has a single source of truth that we call the primary master. You can, of course, implement a similar architecture using non-standard protocols, but if you do you should take care to make it clear how you are diverging from the standard - and be careful about how you use standard DNS terminology when talking about your non-standard system. > For example, > > W <------- A -------> X > > Suppose A is a source of truth for a particular zone, and that W and X > obtain zone data from A. Are you saying that if the mechanism > represented by the arrows is [AI]XFR then A is a primary master and W > and X are not, whereas if that mechanism is something else (perhaps it's > rsync, with W, A and X all configured to be masters from local zone > files) then W, A and X are all primary masters? In this case I would say A is a primary master and W and X are secondaries that use rsync instead of standard zone transfers. The part of the standard architecture that you have replaced is the zone transfer mechanism, so the primary master is architecturally unaffected, so it's OK to use the same name. (But you can't call rsync "ixfr" even though it is incrementally transferring zones, because that would be unreasonably confusing.) > If A is not a nameserver but instead is a database, and the arrows > represent database replication, then W and X are primary masters but A > is not? In this case I would be very proud of my high-availability multi-master system. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Shannon, Rockall, Malin, Hebrides, Bailey: North or northwest 5 to 7, occasionally gale 8 except in Shannon. Rough or very rough, occasionally moderate. Squally showers. Good. From nobody Mon Nov 27 09:49:24 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2070126557; Mon, 27 Nov 2017 09:49:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151180495773.30942.2986792598977230034@ietfa.amsl.com> Date: Mon, 27 Nov 2017 09:49:17 -0800 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 17:49:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Terminology Authors : Paul Hoffman Andrew Sullivan Kazunori Fujiwara Filename : draft-ietf-dnsop-terminology-bis-08.txt Pages : 44 Date : 2017-11-27 Abstract: The DNS is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document will be the successor to RFC 7719, and thus will obsolete RFC 7719. It will also update RFC 2308. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-08 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-terminology-bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 27 09:53:38 2017 Return-Path: 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 A696B128DE7 for ; Mon, 27 Nov 2017 09:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 CEfDjnrcP1Mt for ; Mon, 27 Nov 2017 09:53:35 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 03929128D44 for ; Mon, 27 Nov 2017 09:53:34 -0800 (PST) Received: from [10.32.60.165] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vARHq1PI095307 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 27 Nov 2017 10:52:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.165] From: "Paul Hoffman" To: dnsop@ietf.org Date: Mon, 27 Nov 2017 09:53:32 -0800 Message-ID: <7262E5E9-D844-4CBA-B406-C38B57440321@vpnc.org> In-Reply-To: <151180495773.30942.2986792598977230034@ietfa.amsl.com> References: <151180495773.30942.2986792598977230034@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 17:53:37 -0000 This draft closes out a bunch of issues. (As a reminder, we're tracking issues both here on the list and on the GitHub repo: https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis). We will be opening new issues in the coming weeks with the intention to be ready for WG Last Call by mid-January. --Paul Hoffman On 27 Nov 2017, at 9:49, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of > the IETF. > > Title : DNS Terminology > Authors : Paul Hoffman > Andrew Sullivan > Kazunori Fujiwara > Filename : draft-ietf-dnsop-terminology-bis-08.txt > Pages : 44 > Date : 2017-11-27 > > Abstract: > The DNS is defined in literally dozens of different RFCs. The > terminology used by implementers and developers of DNS protocols, > and > by operators of DNS systems, has sometimes changed in the decades > since the DNS was first defined. This document gives current > definitions for many of the terms used in the DNS in a single > document. > > This document will be the successor to RFC 7719, and thus will > obsolete RFC 7719. It will also update RFC 2308. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-08 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-terminology-bis-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-08 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 27 09:58:52 2017 Return-Path: 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 16C751292FC for ; Mon, 27 Nov 2017 09:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 qu7ovc6aGgcM for ; Mon, 27 Nov 2017 09:58:49 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AC6128D69 for ; Mon, 27 Nov 2017 09:58:48 -0800 (PST) X-Original-To: dnsop@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 389294412F for ; Mon, 27 Nov 2017 18:58:47 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 1F86341B96; Mon, 27 Nov 2017 18:58:47 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 10D791BFA7; Mon, 27 Nov 2017 18:58:47 +0100 (CET) Date: Mon, 27 Nov 2017 18:58:46 +0100 From: Gert Doering To: Tony Finch Cc: Joe Abley , "v6ops@ietf.org WG" , 6man@ietf.org, Daniel Karrenberg , dnsop@ietf.org, sunset4@ietf.org Message-ID: <20171127175846.GH45648@Space.Net> References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [DNSOP] [v6ops] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 17:58:51 -0000 Hi, On Mon, Nov 27, 2017 at 12:28:16PM +0000, Tony Finch wrote: > The 31 TLDs with no v6 nameservers: [..] > mil. Yay. Like, IPv6 mandate, and all that. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Nov 27 10:10:31 2017 Return-Path: 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 536041292FC for ; Mon, 27 Nov 2017 10:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 IViFZIz2C69J for ; Mon, 27 Nov 2017 10:10:27 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A401242F5 for ; Mon, 27 Nov 2017 10:10:26 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id w95so27364444wrc.2 for ; Mon, 27 Nov 2017 10:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+red65GJtPPlTUotObz1zCqTmQd+l3oSyeF/3iQNBzE=; b=wLVexjKVMe2UeUuVVh7atKl8F9yHpIrHXCVdUHhBoESvSiipJ2aKOt8rsal6WqtQKV x1P4khMWwWZPASid2V93PCheORSwCmneI6aYNYxj/jSF7qd43Uom5Zl+rzJ1btMU3wJ7 oLbsrCj9fWTSOoRDx1cwd5Shko8oWDOtHmQVqa+kOrt6bU34OyY81Y/Q1pGfmkcEIBbS h2yR9X7kThHAAn3K+ql5rII0HCpSDTVJ5+ENGJkKgeMTs+krO0iYZ6eoUQn27jCK/fl5 P0yWwMoKhx9yXJC9yqFqUfz9rL6FALZCJrGI51D3zEPewGody4HD7x5OlNfqrWEy4JkY SMcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+red65GJtPPlTUotObz1zCqTmQd+l3oSyeF/3iQNBzE=; b=Q0kYe3cForOr2Ja18T6JJhY19BThkJQMMWTqTkJndTQ3UCAsHn5DJsszkizRA7LBWw YX8taqVLjsUY+/2TZOXDJMtWFHxBSWBHfNmzTE1bk1D1coUVeIBsav3hefs2v2NQmHpo B3RhyF2djFqoFKznGFrqLgDWb5tBJcNB+FyXxbsQ1qFeREDprDOw2Vnft5k8HqMD8FYc PhjFlNqDDFHXWhLIQfteAFf5JU+GP7nUVvZnREPhcD37lUuqrsAhLhLhX3iw1g2awN7K LNroOJgoL/fM/3TrQwMOkxvJvNd3nGgq4ri787lWpK6oKGvOwj9vqHK8y+W95N6F0Uzf TQjg== X-Gm-Message-State: AJaThX5FGNLus6bwTW1t6XhcAPRVQrCx72lWYkrsxlZrUCsea6oPRj41 4TKmFaT/TpD2EwHlU+besKNCHjJVMinx7FWRfpBWYA== X-Google-Smtp-Source: AGs4zMYMo2l0isRrXOytDac9XpbZPK05m9T8iwTR9sREtUDav2skGzo1pMsDEW1SRNRGqJz4nlTE32ld0VOBFv7GrFI= X-Received: by 10.223.157.137 with SMTP id p9mr34575778wre.92.1511806225018; Mon, 27 Nov 2017 10:10:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.74 with HTTP; Mon, 27 Nov 2017 10:10:24 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Mon, 27 Nov 2017 13:10:24 -0500 Message-ID: To: George Michaelson Cc: tjw ietf , dnsop Content-Type: multipart/alternative; boundary="f403043a2794030bff055efad1a4" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 18:10:30 -0000 --f403043a2794030bff055efad1a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable George, you should know better than to claim that a mechanism that requires resolver updates will have "immediate benefit" :) I do not find this mechanism terribly compelling. It is not useful in the short run, as noted above. And it has the wrong architecture for the long run. What zone operators need, for KSK roll-overs and other evolution decisions, is telemetry about the capabilities of the resolvers they serve. In order for an approach like this to provide that telemetry, one would need a broad-scale client-side measurement system. While such systems exist (Geoff and George being expert practitioners), they have a lot of problems -- they're expensive to operate at scale; they're extremely limited in terms of what they can measure and how reliably; and they impose much more overhead than is needed here. We shouldn't be building a telemetry system for the DNS that has hard-coded assumptions about web ads or dedicated probes. It would be far better to build a telemetry mechanism that operated directly between resolvers and authoritative servers. There are a variety of ways you could do this. In today's world, you could have some record by which an authoritative server could advertise a telemetry submission point. In a DOH world, you could have the resolver provide a Link header telling the authoritative server where it could pick up information about resolver capabilities. None of these are hard to build (and they don't interfere with the "fast path" of the resolver) and they provide much more high quality information. If you need data for the KSK roll that we're already a decade late for, gather it in a way that doesn't require a resolver upgrade. (Deploy a dedicated temporary TLD if you need to.) If you're trying to solve the long-run telemetry problem, then build it properly. --Richard On Thu, Nov 16, 2017 at 3:34 AM, George Michaelson wrote= : > I support adoption of this work. Its a sensible, simple proposal which > has immediate benefit, and can be used by anyone to test the ability > of their nominated resolver to recognise specific keys, and their > trust state. > > I believe as a community, at large, we need code deployed into the > resolvers in the wild, and we need a document specifying the behaviour > we need deployed into those resolvers. We can use this to inform > ourselves of operational risk under keychange. We can know as > individuals, as organizations what we will see, if keys change. I > think this is quite powerful. compared to measurement of what > resolvers see, or what authoritatives or roots see, going back to > these service-providers themselves. This method informs the client > side of the transaction. Thats big. > > I'm not saying we shouldn't do other things, or measure. I'm saying > that this proposal has a qualitative aspect which I think is > different, and good. > > -George > > On Thu, Nov 16, 2017 at 4:23 PM, tjw ietf wrote: > > All > > > > The author has rolled out a new version addressing comments from the > meeting > > on Monday, and we feel it=E2=80=99s ready to move this along. > > > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > > > The draft is available here: > > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ > > > > Please review this draft to see if you think it is suitable for adoptio= n > by > > DNSOP, and comments to the list, clearly stating your view. > > > > Please also indicate if you are willing to contribute text, review, etc= . > > > > This call for adoption ends: 30 November 2017 23:59 > > > > Thanks, > > tim wicinski > > DNSOP co-chair > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --f403043a2794030bff055efad1a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
George, you should know better than to claim that a m= echanism that requires resolver updates will have "immediate benefit&q= uot; :)

I do not find this mechanism terribly comp= elling.=C2=A0 It is not useful in the short run, as noted above.=C2=A0 And = it has the wrong architecture for the long run.

What zone operators need, for KSK roll-overs and other evolution decision= s, is telemetry about the capabilities of the resolvers they serve.=C2=A0 I= n order for an approach like this to provide that telemetry, one would need= a broad-scale client-side measurement system.=C2=A0 While such systems exi= st (Geoff and George being expert practitioners), they have a lot of proble= ms -- they're expensive to operate at scale; they're extremely limi= ted in terms of what they can measure and how reliably; and they impose muc= h more overhead than is needed here.=C2=A0 We shouldn't be building a t= elemetry system for the DNS that has hard-coded assumptions about web ads o= r dedicated probes.

It would be far better to = build a telemetry mechanism that operated directly between resolvers and au= thoritative servers.=C2=A0 There are a variety of ways you could do this.= =C2=A0 In today's world, you could have some record by which an authori= tative server could advertise a telemetry submission point.=C2=A0 In a DOH = world, you could have the resolver provide a Link header telling the author= itative server where it could pick up information about resolver capabiliti= es.=C2=A0 None of these are hard to build (and they don't interfere wit= h the "fast path" of the resolver) and they provide much more hig= h quality information.

If you need data for th= e KSK roll that we're already a decade late for, gather it in a way tha= t doesn't require a resolver upgrade.=C2=A0 (Deploy a dedicated tempora= ry TLD if you need to.)=C2=A0 If you're trying to solve the long-run te= lemetry problem, then build it properly.

--Richard=


On Thu, Nov 16, 2017 at 3:34 AM, George Michaelson <ggm@alge= bras.org> wrote:
I suppor= t adoption of this work. Its a sensible, simple proposal which
has immediate benefit, and can be used by anyone to test the ability
of their nominated resolver to recognise specific keys, and their
trust state.

I believe as a community, at large,=C2=A0 we need code deployed into the resolvers in the wild, and we need a document specifying the behaviour
we need deployed into those resolvers. We can use this to inform
ourselves of operational risk under keychange. We can know as
individuals, as organizations what we will see, if keys change. I
think this is quite powerful. compared to measurement of what
resolvers see, or what authoritatives or roots see, going back to
these service-providers themselves. This method informs the client
side of the transaction. Thats big.

I'm not saying we shouldn't do other things, or measure. I'm sa= ying
that this proposal has a qualitative aspect which I think is
different, and good.

-George

On Thu, Nov 16, 2017 at 4:23 PM, tjw ietf <tjw.ietf@gmail.com> wrote:
> All
>
> The author has rolled out a new version addressing comments from the m= eeting
> on Monday, and we feel it=E2=80=99s ready to move this along.
>
> This starts a Call for Adoption for draft-huston-kskroll-sentinel
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/
>
> Please review this draft to see if you think it is suitable for adopti= on by
> DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, et= c.
>
> This call for adoption ends: 30 November 2017 23:59
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop=
>

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--f403043a2794030bff055efad1a4-- From nobody Mon Nov 27 10:28:10 2017 Return-Path: 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 ACCFC128D6F for ; Mon, 27 Nov 2017 10:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 IFQzYEf6YOZG for ; Mon, 27 Nov 2017 10:28:07 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 16798128B88 for ; Mon, 27 Nov 2017 10:28:07 -0800 (PST) Received: from [10.32.60.165] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vARIQXl3004064 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 27 Nov 2017 11:26:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.165] From: "Paul Hoffman" To: "dnsop WG" Date: Mon, 27 Nov 2017 10:28:04 -0800 Message-ID: <8CB86DAB-B80E-469A-9BDA-7F1361634933@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: [DNSOP] Please review in terminology-bis: X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 18:28:09 -0000 Greetings again. For the past many versions of the terminology-bis draft (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/), Section 2 has definitions of "Global DNS" and "Private DNS", based on the facets listed in "Naming system". This was discussed heavily on the list earlier, but it is also a pretty big change, so we want to be sure that it is what the WG wants. Please review these terms and comment on the list if you think the definitions should change. --Paul Hoffman From nobody Mon Nov 27 10:36:23 2017 Return-Path: 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 4E162128D6F for ; Mon, 27 Nov 2017 10:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 XfJtAgA8HV6E for ; Mon, 27 Nov 2017 10:36:20 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78392126CBF for ; Mon, 27 Nov 2017 10:36:19 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id s41so21964053wrc.7 for ; Mon, 27 Nov 2017 10:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/EnVLIZFHfdwQjO3TFRFAxpoDZ5kc64t/CIKdY7cML4=; b=OFnpQA1p3PYYLV1OEpZu6twfObUv7vJp/Px3BNc59PCkNi4SHRypfCdf74ElWLOcF1 4mg0Noo/3ivFoB0UloFOCQZALuowGkbgUPV6MCTRjHmUo/TfgFVdDqtlr/BEU4YSNdqY pSMwn5HNvUO2GeB+3g3oDzKik4frmQWsLt+mMNqMFjRdQo7tyQ4fa/xg9KFmp3ao0Gi6 kHN8mLV2MJApEWUKJXrzBjbqo/znXGD+LbDyJRR9d41zQCWxDIntQbtX9NY68BpH2B/R kVazcQbIGsnvuWqDLtwecMc+IdCQdNvriwokL72DzIMtq/VCNnK1wUjuBgI9oHyYi6Dq /LLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/EnVLIZFHfdwQjO3TFRFAxpoDZ5kc64t/CIKdY7cML4=; b=jK7LJRmPTx1ep5AvnHcJTRuUdWbI0xjAj4DXB6H7LUlblID/ohkBzzavpqtUeCnQZs VHjkSncEhx/N+7p2ajEBMkKtoL15WXcoKBGs4WTd9zQlxFTrJpLV4l90PO7V9tf4P/9P tQ4867HePf06q71gEKgT341ybgv4vLBMy6A13zVo1aveVLjqcqFe0igDn+8gryPwivjY RgPPEcgwP5MtfUAE56pdXwWe1xRzMHG0ZZ11iZycxldd5Mc3Ed5ab9Co2lde+E3ysxS5 xIk6W3D76SgnIXS+KWTNC660Le3bjC//AHsBwNw4XH+gDBWoDuoHctkrq++zWgg/T3D7 seBQ== X-Gm-Message-State: AJaThX641nShkNdKwKDgfjDcBAxyE7kq3Oyd4wPMG/ukBPkjFxvDtQXp YP1/OtCW61WFw129KjdJKE6snmJpVEiQ0FPbMM4akw== X-Google-Smtp-Source: AGs4zMaBX+FOtdHbK9OEDl/z7Ws1nXK1Il2GJPqd3aFKdhZ+QBC88M0CJQ/+M4U8+Bjoz3su9lioPKAizZpqC23WwVs= X-Received: by 10.223.141.134 with SMTP id o6mr31248513wrb.95.1511807777893; Mon, 27 Nov 2017 10:36:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.74 with HTTP; Mon, 27 Nov 2017 10:36:17 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Mon, 27 Nov 2017 13:36:17 -0500 Message-ID: To: George Michaelson Cc: tjw ietf , dnsop Content-Type: multipart/alternative; boundary="f403045f569a9202c4055efb2d98" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 18:36:21 -0000 --f403045f569a9202c4055efb2d98 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, that's what I get for providing drive-by feedback. Someone pointed me off-list to RFC 8145 and the operational issues with that. I still think that that calls for a better authoritative/resolver telemetry interface, not some client-side thing. On Mon, Nov 27, 2017 at 1:10 PM, Richard Barnes wrote: > George, you should know better than to claim that a mechanism that > requires resolver updates will have "immediate benefit" :) > > I do not find this mechanism terribly compelling. It is not useful in th= e > short run, as noted above. And it has the wrong architecture for the lon= g > run. > > What zone operators need, for KSK roll-overs and other evolution > decisions, is telemetry about the capabilities of the resolvers they > serve. In order for an approach like this to provide that telemetry, one > would need a broad-scale client-side measurement system. While such > systems exist (Geoff and George being expert practitioners), they have a > lot of problems -- they're expensive to operate at scale; they're extreme= ly > limited in terms of what they can measure and how reliably; and they impo= se > much more overhead than is needed here. We shouldn't be building a > telemetry system for the DNS that has hard-coded assumptions about web ad= s > or dedicated probes. > > It would be far better to build a telemetry mechanism that operated > directly between resolvers and authoritative servers. There are a variet= y > of ways you could do this. In today's world, you could have some record = by > which an authoritative server could advertise a telemetry submission > point. In a DOH world, you could have the resolver provide a Link header > telling the authoritative server where it could pick up information about > resolver capabilities. None of these are hard to build (and they don't > interfere with the "fast path" of the resolver) and they provide much mor= e > high quality information. > > If you need data for the KSK roll that we're already a decade late for, > gather it in a way that doesn't require a resolver upgrade. (Deploy a > dedicated temporary TLD if you need to.) If you're trying to solve the > long-run telemetry problem, then build it properly. > > --Richard > > > On Thu, Nov 16, 2017 at 3:34 AM, George Michaelson > wrote: > >> I support adoption of this work. Its a sensible, simple proposal which >> has immediate benefit, and can be used by anyone to test the ability >> of their nominated resolver to recognise specific keys, and their >> trust state. >> >> I believe as a community, at large, we need code deployed into the >> resolvers in the wild, and we need a document specifying the behaviour >> we need deployed into those resolvers. We can use this to inform >> ourselves of operational risk under keychange. We can know as >> individuals, as organizations what we will see, if keys change. I >> think this is quite powerful. compared to measurement of what >> resolvers see, or what authoritatives or roots see, going back to >> these service-providers themselves. This method informs the client >> side of the transaction. Thats big. >> >> I'm not saying we shouldn't do other things, or measure. I'm saying >> that this proposal has a qualitative aspect which I think is >> different, and good. >> >> -George >> >> On Thu, Nov 16, 2017 at 4:23 PM, tjw ietf wrote: >> > All >> > >> > The author has rolled out a new version addressing comments from the >> meeting >> > on Monday, and we feel it=E2=80=99s ready to move this along. >> > >> > This starts a Call for Adoption for draft-huston-kskroll-sentinel >> > >> > The draft is available here: >> > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ >> > >> > Please review this draft to see if you think it is suitable for >> adoption by >> > DNSOP, and comments to the list, clearly stating your view. >> > >> > Please also indicate if you are willing to contribute text, review, et= c. >> > >> > This call for adoption ends: 30 November 2017 23:59 >> > >> > Thanks, >> > tim wicinski >> > DNSOP co-chair >> > >> > _______________________________________________ >> > DNSOP mailing list >> > DNSOP@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnsop >> > >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > --f403045f569a9202c4055efb2d98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, that's what I get for providing drive-by fe= edback.=C2=A0 Someone pointed me off-list to RFC 8145 and the operational i= ssues with that.=C2=A0 I still think that that calls for a better authorita= tive/resolver telemetry interface, not some client-side thing.

On Mon, Nov 27= , 2017 at 1:10 PM, Richard Barnes <rlb@ipv.sx> wrote:
George, you should know better t= han to claim that a mechanism that requires resolver updates will have &quo= t;immediate benefit" :)

I do not find this me= chanism terribly compelling.=C2=A0 It is not useful in the short run, as no= ted above.=C2=A0 And it has the wrong architecture for the long run.

What zone operators need, for KSK roll-overs and oth= er evolution decisions, is telemetry about the capabilities of the resolver= s they serve.=C2=A0 In order for an approach like this to provide that tele= metry, one would need a broad-scale client-side measurement system.=C2=A0 W= hile such systems exist (Geoff and George being expert practitioners), they= have a lot of problems -- they're expensive to operate at scale; they&= #39;re extremely limited in terms of what they can measure and how reliably= ; and they impose much more overhead than is needed here.=C2=A0 We shouldn&= #39;t be building a telemetry system for the DNS that has hard-coded assump= tions about web ads or dedicated probes.

It wo= uld be far better to build a telemetry mechanism that operated directly bet= ween resolvers and authoritative servers.=C2=A0 There are a variety of ways= you could do this.=C2=A0 In today's world, you could have some record = by which an authoritative server could advertise a telemetry submission poi= nt.=C2=A0 In a DOH world, you could have the resolver provide a Link header= telling the authoritative server where it could pick up information about = resolver capabilities.=C2=A0 None of these are hard to build (and they don&= #39;t interfere with the "fast path" of the resolver) and they pr= ovide much more high quality information.

If y= ou need data for the KSK roll that we're already a decade late for, gat= her it in a way that doesn't require a resolver upgrade.=C2=A0 (Deploy = a dedicated temporary TLD if you need to.)=C2=A0 If you're trying to so= lve the long-run telemetry problem, then build it properly.

--Richard


On Thu, Nov 16, = 2017 at 3:34 AM, George Michaelson <ggm@algebras.org> wrote:<= br>
I support adoption of this work. Its a se= nsible, simple proposal which
has immediate benefit, and can be used by anyone to test the ability
of their nominated resolver to recognise specific keys, and their
trust state.

I believe as a community, at large,=C2=A0 we need code deployed into the resolvers in the wild, and we need a document specifying the behaviour
we need deployed into those resolvers. We can use this to inform
ourselves of operational risk under keychange. We can know as
individuals, as organizations what we will see, if keys change. I
think this is quite powerful. compared to measurement of what
resolvers see, or what authoritatives or roots see, going back to
these service-providers themselves. This method informs the client
side of the transaction. Thats big.

I'm not saying we shouldn't do other things, or measure. I'm sa= ying
that this proposal has a qualitative aspect which I think is
different, and good.

-George

On Thu, Nov 16, 2017 at 4:23 PM, tjw ietf <tjw.ietf@gmail.com> wrote:
> All
>
> The author has rolled out a new version addressing comments from the m= eeting
> on Monday, and we feel it=E2=80=99s ready to move this along.
>
> This starts a Call for Adoption for draft-huston-kskroll-sentinel
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/
>
> Please review this draft to see if you think it is suitable for adopti= on by
> DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, et= c.
>
> This call for adoption ends: 30 November 2017 23:59
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org=
> https://www.ietf.org/mailman/listinfo/dnsop=
>

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--f403045f569a9202c4055efb2d98-- From nobody Mon Nov 27 10:39:12 2017 Return-Path: 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 DC2971293DA for ; Mon, 27 Nov 2017 10:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 rRPollAHmI_1 for ; Mon, 27 Nov 2017 10:39:08 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7AA1293D8 for ; Mon, 27 Nov 2017 10:39:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=a9NAywjyUf1jEh8UGGathemGj0p2k3ROy9F6/vhZ87I=; b=X8asRvTYZS+4FYHUmyg0NOPHkctVgwBZBDws9XS8XrD8TOnkcPL47U5ggvDV8FnZj60I46iHJ3CPZtXfTmS9PzSFYBD1hFWP3u6yHfi9sil88vGhnFD2bg0LRD9UTeYorPrPfI8LhUkFScFxHNOSz5wBxLQz/lUPqbwzgIXiEOU=; Received: ; Mon, 27 Nov 2017 10:39:04 -0800 To: Mike West , Richard Barnes Cc: dnsop WG , Ted Lemon References: <57BD04DF-B473-41B8-9ECD-D197232365FB@fugue.com> From: Jacob Hoffman-Andrews Message-ID: <8e8757c5-f475-ff67-0e1c-e7fcaded3137@eff.org> Date: Mon, 27 Nov 2017 10:39:07 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1A9081567EB15970D4CE3C5F" Content-Language: en-US Archived-At: Subject: Re: [DNSOP] `localhost` and DNS. X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 18:39:11 -0000 This is a multi-part message in MIME format. --------------1A9081567EB15970D4CE3C5F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Looks good to me. On 11/27/2017 03:54 AM, Mike West wrote: > Post-{IETF,Thanksgiving} ping. Feedback (or further +1's!) would be > appreciated. :) > > -mike > > On Thu, Nov 16, 2017 at 1:01 AM, Richard Barnes > wrote: > > > > On Thu, Nov 16, 2017 at 5:05 AM, Ted Lemon > wrote: > > On Nov 15, 2017, at 10:51 PM, Mike West > wrote: >> Skimming through the recording of Monday's meeting >>  (starting >> at around 53:56), it sounds to me as though there's at least >> loose agreement that signing a response for `localhost` is >> not what we'd like to recommend: all the folks who commented >> explicitly took that position for similar reasons. The >> current text >> in https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-01#section-4.2 >>  reflects >> this position, and IMO it's what we should run with. > > Yes, the current text appears to me to be correct. > > > +1 > >   > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --------------1A9081567EB15970D4CE3C5F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Looks good to me.

On 11/27/2017 03:54 AM, Mike West wrote:
Post-{IETF,Thanksgiving} ping. Feedback (or further +1's!) would be appreciated. :)

-mike

On Thu, Nov 16, 2017 at 1:01 AM, Richard Barnes <rlb@ipv.sx> wrote:


On Thu, Nov 16, 2017 at 5:05 AM, Ted Lemon <mellon@fugue.com> wrote:
On Nov 15, 2017, at 10:51 PM, Mike West <mkwst@google.com> wrote:
Skimming through the recording of Monday's meeting (starting at around 53:56), it sounds to me as though there's at least loose agreement that signing a response for `localhost` is not what we'd like to recommend: all the folks who commented explicitly took that position for similar reasons. The current text in https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-01#section-4.2 reflects this position, and IMO it's what we should run with.
Yes, the current text appears to me to be correct.

+1

 


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop





_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--------------1A9081567EB15970D4CE3C5F-- From nobody Mon Nov 27 11:06:40 2017 Return-Path: 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 DB06D1270A3 for ; Mon, 27 Nov 2017 11:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 2XZjJ_zAjxFz for ; Mon, 27 Nov 2017 11:06:37 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41381126C83 for ; Mon, 27 Nov 2017 11:06:37 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id d21so15295601ioe.7 for ; Mon, 27 Nov 2017 11:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lIbdZCw8xTwvCzHVnI8BRntSy6g1rjF4BSQyUaoFW4c=; b=bzVtJihvMFTN9pITzQ1gkzeb8E3NAmy9QunWRI5i9PpXXrLP0JRisyRBLQkfrDTl37 S7It0uGJx+UuYi0yp6CVWPxYFBNbxwpbPn4Egz05e6ad9cIq7iNIWFXgiKaHZDv1Aypx OgL5YAcspRsiPCyJYgJpGghW7nMS9ZbxJCLFY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lIbdZCw8xTwvCzHVnI8BRntSy6g1rjF4BSQyUaoFW4c=; b=FA468B26/GgxRAwE0dO1dU00prw9sQoDdAueTtCVH1ymTIdYuY/VnvoNHp7rrhpsU/ 8H5HhGgyx089kRKyGa3CoZtct9T0k6LZebfHx4rIQGYDOzjsAdIusYF5HExlFj7zhiR1 k8F1J6iL0EO7xOssnotAeAal3Jn0O37A799gBdxBPZGNotZImfTAGAoetP7lVswZ8YpK guTbMBPVvbzbK+2D84p7NJSENpyGbpadT10xJm1BF2nSs4qcwfOxc8NlhRFpm4DbryuD e9TjRJdivLw7UMCWpjwW70yeTH5VWhpFbcOzEE7PN3PWDeXYUD3AM1m2NvEBBRYtFsSA rESA== X-Gm-Message-State: AJaThX4m2rHSiugD92CPkBC/3jto9Pb12Vb4f1TeN7X3JOxkuy4Eai8O lyCgZZxAZBqWX/2Mb1oxAYRQt0XoHws= X-Google-Smtp-Source: AGs4zMb3ayf8u1X1nCUvecBNj5/vsLhaISTUJcdgoC1yLgOUYkfzU6NNnfZQd3t8W/7AvOQzL08a7Q== X-Received: by 10.107.141.77 with SMTP id p74mr46825523iod.40.1511809596364; Mon, 27 Nov 2017 11:06:36 -0800 (PST) Received: from ?IPv6:2607:f2c0:101:202:c849:dad7:a94e:7c1e? ([2607:f2c0:101:202:c849:dad7:a94e:7c1e]) by smtp.gmail.com with ESMTPSA id k23sm7680596iti.22.2017.11.27.11.06.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 11:06:35 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Joe Abley In-Reply-To: Date: Mon, 27 Nov 2017 14:06:31 -0500 Cc: George Michaelson , tjw ietf , dnsop Content-Transfer-Encoding: quoted-printable Message-Id: <11C784A2-B8E1-4D63-81F9-B62AA148D9EE@hopcount.ca> References: To: Richard Barnes X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 19:06:39 -0000 As I imagine you've heard, part of the problem with = resolver-authoritative telemetry interfaces is that the deployed = infrastructure is not so simple; it also includes forwarders, changed = resolvers, caches, middleware that interferes with the query path and/or = drops queries that don't look normal... It's a jungle out there. Looking = at the closest tree from just outside the edge of the jungle is actually = much easier than speculating about what bizarre horrors lie within it. > On 27 Nov 2017, at 13:36, Richard Barnes wrote: >=20 > Well, that's what I get for providing drive-by feedback. Someone = pointed me off-list to RFC 8145 and the operational issues with that. I = still think that that calls for a better authoritative/resolver = telemetry interface, not some client-side thing. >=20 > On Mon, Nov 27, 2017 at 1:10 PM, Richard Barnes wrote: > George, you should know better than to claim that a mechanism that = requires resolver updates will have "immediate benefit" :) >=20 > I do not find this mechanism terribly compelling. It is not useful in = the short run, as noted above. And it has the wrong architecture for = the long run. >=20 > What zone operators need, for KSK roll-overs and other evolution = decisions, is telemetry about the capabilities of the resolvers they = serve. In order for an approach like this to provide that telemetry, = one would need a broad-scale client-side measurement system. While such = systems exist (Geoff and George being expert practitioners), they have a = lot of problems -- they're expensive to operate at scale; they're = extremely limited in terms of what they can measure and how reliably; = and they impose much more overhead than is needed here. We shouldn't be = building a telemetry system for the DNS that has hard-coded assumptions = about web ads or dedicated probes. >=20 > It would be far better to build a telemetry mechanism that operated = directly between resolvers and authoritative servers. There are a = variety of ways you could do this. In today's world, you could have = some record by which an authoritative server could advertise a telemetry = submission point. In a DOH world, you could have the resolver provide a = Link header telling the authoritative server where it could pick up = information about resolver capabilities. None of these are hard to = build (and they don't interfere with the "fast path" of the resolver) = and they provide much more high quality information. >=20 > If you need data for the KSK roll that we're already a decade late = for, gather it in a way that doesn't require a resolver upgrade. = (Deploy a dedicated temporary TLD if you need to.) If you're trying to = solve the long-run telemetry problem, then build it properly. >=20 > --Richard >=20 >=20 > On Thu, Nov 16, 2017 at 3:34 AM, George Michaelson = wrote: > I support adoption of this work. Its a sensible, simple proposal which > has immediate benefit, and can be used by anyone to test the ability > of their nominated resolver to recognise specific keys, and their > trust state. >=20 > I believe as a community, at large, we need code deployed into the > resolvers in the wild, and we need a document specifying the behaviour > we need deployed into those resolvers. We can use this to inform > ourselves of operational risk under keychange. We can know as > individuals, as organizations what we will see, if keys change. I > think this is quite powerful. compared to measurement of what > resolvers see, or what authoritatives or roots see, going back to > these service-providers themselves. This method informs the client > side of the transaction. Thats big. >=20 > I'm not saying we shouldn't do other things, or measure. I'm saying > that this proposal has a qualitative aspect which I think is > different, and good. >=20 > -George >=20 > On Thu, Nov 16, 2017 at 4:23 PM, tjw ietf wrote: > > All > > > > The author has rolled out a new version addressing comments from the = meeting > > on Monday, and we feel it=E2=80=99s ready to move this along. > > > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > > > The draft is available here: > > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ > > > > Please review this draft to see if you think it is suitable for = adoption by > > DNSOP, and comments to the list, clearly stating your view. > > > > Please also indicate if you are willing to contribute text, review, = etc. > > > > This call for adoption ends: 30 November 2017 23:59 > > > > Thanks, > > tim wicinski > > DNSOP co-chair > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon Nov 27 11:47:43 2017 Return-Path: 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 F3653127010 for ; Mon, 27 Nov 2017 11:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 X-N1hdPI1qRx for ; Mon, 27 Nov 2017 11:47:38 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0B51204DA for ; Mon, 27 Nov 2017 11:47:38 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id v186so37281277wma.2 for ; Mon, 27 Nov 2017 11:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y/DEHb6B9p4jzG+4eLqw9b3iRB4EuG7EGJ+NEfPEtYI=; b=P4nYJWS6W9uCN2CWImhRt5+8DZ6jo3ayx/R7fqQNSbliqgUeAvavwIeTOPcLR9uk69 3qi7Cgxi+qZmURkouPLv1X2/1urCPMOlAyT6Gko6wejHzeORKNu5gA+Yo5NMaf/XiNQc +Jd3FoXL+jLGnx+F/27yLjS09gkZ8o1IfKcqYrQ3QL0JZWP8VteEV5vpvLgXC9ePa4i9 J/+FQa61nZsdkI4RjyFZMuy/MLNL0CxRhaQIzZH1kpXIRBNcV7/Zr6lPxOUWzxFEhjjP cvp+1v9Z/ATYzZ8wzAMxdEXo8ueX2egLMzZmclH/ZuppsymcjF9EpzBqOs635ChjQwFJ 0zRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y/DEHb6B9p4jzG+4eLqw9b3iRB4EuG7EGJ+NEfPEtYI=; b=rv+1sYejQlnSjnp0vhIaJHvvvQtEgBnnOHqQ4zBempfpqDIvZF2FkKCYeiO9U5Yp+e 94PJrgi8sn/DbReCJN+4Y3S3fzeIlhQH642sWfTCnRwRwGJE6LvjLcjfxyLgY4Kcc7A2 T0/Q+vTXzv/y5VhN6TnLT4TrN2StLMX6c1+XT0ygY0pu6qKGM+ZvRJK7xEJwQ3uxmUA6 MrUa7ih1oWz5hTl6eGhEkH0toCjbwuzxesB78DN8TFyKw19VSF96F7fZmmPLf/KYrxKn ttWyQ4yF7xLSIEeJ0/tAeiNEbPeFkxFuHHvDWXUixto6jmf2K1tZWx/VPHanLOao05yc QAMg== X-Gm-Message-State: AJaThX5/3mP8dCW7dgOedQ+LcZfT02Qe7UE/DbyB6/SdrAJHv8mpFMfu ufLZDWVAXv/NROw41csED9Se1lk89cSVL1Ga4Ae1YA== X-Google-Smtp-Source: AGs4zMYNCYoQDmmWIpPhnNPRJePhMt6E6iT8FFLotFbe56NfyF4dIoDF/DIcS9yulSnrkKxRDYAPBUSF70y2ud0DMqk= X-Received: by 10.28.175.73 with SMTP id y70mr20035505wme.21.1511812056555; Mon, 27 Nov 2017 11:47:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.74 with HTTP; Mon, 27 Nov 2017 11:47:36 -0800 (PST) In-Reply-To: <11C784A2-B8E1-4D63-81F9-B62AA148D9EE@hopcount.ca> References: <11C784A2-B8E1-4D63-81F9-B62AA148D9EE@hopcount.ca> From: Richard Barnes Date: Mon, 27 Nov 2017 14:47:36 -0500 Message-ID: To: Joe Abley Cc: George Michaelson , tjw ietf , dnsop Content-Type: multipart/alternative; boundary="001a114436c4993b83055efc2c34" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 19:47:41 -0000 --001a114436c4993b83055efc2c34 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As tempting as it may be to do the easy thing, it's not always the best use of resources. Looking at the closest tree might be easy for one observer, but when you try to do it with enough observers to have a result that's useful for the King of the Jungle, you end up with similar tangles. I don't think that it make sense to infer from the failure of RFC 8145 that resolver/authoritative telemetry isn't possible -- just that it's not possible with the heavy-weight machinery in that mechanism. To the degree that the DNS still works at all, there must be some channel by which information can be faithfully passed from authoritative to resolver, which can presumably be used to bootstrap telemetry. Maybe it's a TXT record with an HTTP URL; maybe it's a funny CNAME. Maybe you can't build a road through the jungle, but there are still rivers that make it through, which can carry a message in a bottle. On Mon, Nov 27, 2017 at 2:06 PM, Joe Abley wrote: > As I imagine you've heard, part of the problem with resolver-authoritativ= e > telemetry interfaces is that the deployed infrastructure is not so simple= ; > it also includes forwarders, changed resolvers, caches, middleware that > interferes with the query path and/or drops queries that don't look > normal... It's a jungle out there. Looking at the closest tree from just > outside the edge of the jungle is actually much easier than speculating > about what bizarre horrors lie within it. > > > On 27 Nov 2017, at 13:36, Richard Barnes wrote: > > > > Well, that's what I get for providing drive-by feedback. Someone > pointed me off-list to RFC 8145 and the operational issues with that. I > still think that that calls for a better authoritative/resolver telemetry > interface, not some client-side thing. > > > > On Mon, Nov 27, 2017 at 1:10 PM, Richard Barnes wrote: > > George, you should know better than to claim that a mechanism that > requires resolver updates will have "immediate benefit" :) > > > > I do not find this mechanism terribly compelling. It is not useful in > the short run, as noted above. And it has the wrong architecture for the > long run. > > > > What zone operators need, for KSK roll-overs and other evolution > decisions, is telemetry about the capabilities of the resolvers they > serve. In order for an approach like this to provide that telemetry, one > would need a broad-scale client-side measurement system. While such > systems exist (Geoff and George being expert practitioners), they have a > lot of problems -- they're expensive to operate at scale; they're extreme= ly > limited in terms of what they can measure and how reliably; and they impo= se > much more overhead than is needed here. We shouldn't be building a > telemetry system for the DNS that has hard-coded assumptions about web ad= s > or dedicated probes. > > > > It would be far better to build a telemetry mechanism that operated > directly between resolvers and authoritative servers. There are a variet= y > of ways you could do this. In today's world, you could have some record = by > which an authoritative server could advertise a telemetry submission > point. In a DOH world, you could have the resolver provide a Link header > telling the authoritative server where it could pick up information about > resolver capabilities. None of these are hard to build (and they don't > interfere with the "fast path" of the resolver) and they provide much mor= e > high quality information. > > > > If you need data for the KSK roll that we're already a decade late for, > gather it in a way that doesn't require a resolver upgrade. (Deploy a > dedicated temporary TLD if you need to.) If you're trying to solve the > long-run telemetry problem, then build it properly. > > > > --Richard > > > > > > On Thu, Nov 16, 2017 at 3:34 AM, George Michaelson > wrote: > > I support adoption of this work. Its a sensible, simple proposal which > > has immediate benefit, and can be used by anyone to test the ability > > of their nominated resolver to recognise specific keys, and their > > trust state. > > > > I believe as a community, at large, we need code deployed into the > > resolvers in the wild, and we need a document specifying the behaviour > > we need deployed into those resolvers. We can use this to inform > > ourselves of operational risk under keychange. We can know as > > individuals, as organizations what we will see, if keys change. I > > think this is quite powerful. compared to measurement of what > > resolvers see, or what authoritatives or roots see, going back to > > these service-providers themselves. This method informs the client > > side of the transaction. Thats big. > > > > I'm not saying we shouldn't do other things, or measure. I'm saying > > that this proposal has a qualitative aspect which I think is > > different, and good. > > > > -George > > > > On Thu, Nov 16, 2017 at 4:23 PM, tjw ietf wrote: > > > All > > > > > > The author has rolled out a new version addressing comments from the > meeting > > > on Monday, and we feel it=E2=80=99s ready to move this along. > > > > > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > > > > > The draft is available here: > > > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ > > > > > > Please review this draft to see if you think it is suitable for > adoption by > > > DNSOP, and comments to the list, clearly stating your view. > > > > > > Please also indicate if you are willing to contribute text, review, > etc. > > > > > > This call for adoption ends: 30 November 2017 23:59 > > > > > > Thanks, > > > tim wicinski > > > DNSOP co-chair > > > > > > _______________________________________________ > > > DNSOP mailing list > > > DNSOP@ietf.org > > > https://www.ietf.org/mailman/listinfo/dnsop > > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > --001a114436c4993b83055efc2c34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As tempting as it may be to do the easy thing, it'= ;s not always the best use of resources.=C2=A0 Looking at the closest tree = might be easy for one observer, but when you try to do it with enough obser= vers to have a result that's useful for the King of the Jungle, you end= up with similar tangles.

I don't think th= at it make sense to infer from the failure of RFC 8145 that resolver/author= itative telemetry isn't possible -- just that it's not possible wit= h the heavy-weight machinery in that mechanism.=C2=A0 To the degree that th= e DNS still works at all, there must be some channel by which information c= an be faithfully passed from authoritative to resolver, which can presumabl= y be used to bootstrap telemetry.=C2=A0 Maybe it's a TXT record with an= HTTP URL; maybe it's a funny CNAME.

Maybe= you can't build a road through the jungle, but there are still rivers = that make it through, which can carry a message in a bottle.

On Mon, Nov 27, = 2017 at 2:06 PM, Joe Abley <jabley@hopcount.ca> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">As I imagine you've heard, part of the pr= oblem with resolver-authoritative telemetry interfaces is that the deployed= infrastructure is not so simple; it also includes forwarders, changed reso= lvers, caches, middleware that interferes with the query path and/or drops = queries that don't look normal... It's a jungle out there. Looking = at the closest tree from just outside the edge of the jungle is actually mu= ch easier than speculating about what bizarre horrors lie within it.

> On 27 Nov 2017, at 13:36, Richard Barnes <rlb@ipv.sx> wrote:
>
> Well, that's what I get for providing drive-by feedback.=C2=A0 Som= eone pointed me off-list to RFC 8145 and the operational issues with that.= =C2=A0 I still think that that calls for a better authoritative/resolver te= lemetry interface, not some client-side thing.
>
> On Mon, Nov 27, 2017 at 1:10 PM, Richard Barnes <rlb@ipv.sx> wro= te:
> George, you should know better than to claim that a mechanism that req= uires resolver updates will have "immediate benefit" :)
>
> I do not find this mechanism terribly compelling.=C2=A0 It is not usef= ul in the short run, as noted above.=C2=A0 And it has the wrong architectur= e for the long run.
>
> What zone operators need, for KSK roll-overs and other evolution decis= ions, is telemetry about the capabilities of the resolvers they serve.=C2= =A0 In order for an approach like this to provide that telemetry, one would= need a broad-scale client-side measurement system.=C2=A0 While such system= s exist (Geoff and George being expert practitioners), they have a lot of p= roblems -- they're expensive to operate at scale; they're extremely= limited in terms of what they can measure and how reliably; and they impos= e much more overhead than is needed here.=C2=A0 We shouldn't be buildin= g a telemetry system for the DNS that has hard-coded assumptions about web = ads or dedicated probes.
>
> It would be far better to build a telemetry mechanism that operated di= rectly between resolvers and authoritative servers.=C2=A0 There are a varie= ty of ways you could do this.=C2=A0 In today's world, you could have so= me record by which an authoritative server could advertise a telemetry subm= ission point.=C2=A0 In a DOH world, you could have the resolver provide a L= ink header telling the authoritative server where it could pick up informat= ion about resolver capabilities.=C2=A0 None of these are hard to build (and= they don't interfere with the "fast path" of the resolver) a= nd they provide much more high quality information.
>
> If you need data for the KSK roll that we're already a decade late= for, gather it in a way that doesn't require a resolver upgrade.=C2=A0= (Deploy a dedicated temporary TLD if you need to.)=C2=A0 If you're try= ing to solve the long-run telemetry problem, then build it properly.
>
> --Richard
>
>
> On Thu, Nov 16, 2017 at 3:34 AM, George Michaelson <ggm@algebras.org> wrote:
> I support adoption of this work. Its a sensible, simple proposal which=
> has immediate benefit, and can be used by anyone to test the ability > of their nominated resolver to recognise specific keys, and their
> trust state.
>
> I believe as a community, at large,=C2=A0 we need code deployed into t= he
> resolvers in the wild, and we need a document specifying the behaviour=
> we need deployed into those resolvers. We can use this to inform
> ourselves of operational risk under keychange. We can know as
> individuals, as organizations what we will see, if keys change. I
> think this is quite powerful. compared to measurement of what
> resolvers see, or what authoritatives or roots see, going back to
> these service-providers themselves. This method informs the client
> side of the transaction. Thats big.
>
> I'm not saying we shouldn't do other things, or measure. I'= ;m saying
> that this proposal has a qualitative aspect which I think is
> different, and good.
>
> -George
>
> On Thu, Nov 16, 2017 at 4:23 PM, tjw ietf <tjw.ietf@gmail.com> wrote:
> > All
> >
> > The author has rolled out a new version addressing comments from = the meeting
> > on Monday, and we feel it=E2=80=99s ready to move this along.
> >
> > This starts a Call for Adoption for draft-huston-kskroll-sentinel=
> >
> > The draft is available here:
> > https://datatracker.ietf.or= g/doc/draft-huston-kskroll-sentinel/
> >
> > Please review this draft to see if you think it is suitable for a= doption by
> > DNSOP, and comments to the list, clearly stating your view.
> >
> > Please also indicate if you are willing to contribute text, revie= w, etc.
> >
> > This call for adoption ends: 30 November 2017 23:59
> >
> > Thanks,
> > tim wicinski
> > DNSOP co-chair
> >
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnso= p
> >
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop=
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop=


--001a114436c4993b83055efc2c34-- From nobody Mon Nov 27 12:00:00 2017 Return-Path: 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 B939A128854 for ; Mon, 27 Nov 2017 11:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 UIKu-PTgyK1Y for ; Mon, 27 Nov 2017 11:59:57 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3DF21275C5 for ; Mon, 27 Nov 2017 11:59:56 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id x13so22581966iti.4 for ; Mon, 27 Nov 2017 11:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AQPH3UfOT5sKwppbM8S2Q7HwzBq4zOXqqckZBjpYUfE=; b=nRiOXLaFHQpUM1DU7AjDIJNvUF27ilhyo3tRhHwAMRnfnCvq+AFqT7cie2ZGZ3MJ3N kAYiwBfX/E7m7cMCjl0VbBsi9UuK3mR5YuSvyY9fOchOMwOtOjAmVbIUuECQ1X9gTpxD zzGu4F6pjuMCWzPgH8ki52Y0NgzjtIznh2Fg0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AQPH3UfOT5sKwppbM8S2Q7HwzBq4zOXqqckZBjpYUfE=; b=F5kygXnZr3zObqpJ5KZAi0jZFlfpXXO/bzSSPuhRoffRQ0XS3DLDHMTyCaGJkxCbX2 UBrjtxx/7aaJO8crsZArzW2qIQwL6lVZ+noUMiViQ3EWpWuT4KRsD4NwRC9hdhQeZpuF 7tl1+3IXXaYd7Bv9lx8Hau8Gygl+bBkXI12s3WGvSUmy9xEvrD3YKa/ga4lY/tlV1WqH Ga4B+RauTqvfzHObd/jt7VQ0TJg8ZKZ4c406BjAuFn2J+iPDpiZ4rteR9lqlVU/dwt8/ HntaVufq6ZIRibmDrhlWIiLfzRHOZUiMf8WAZPPFjTF0lJ9ERD0/jfkQp+tuR94+H+04 soHw== X-Gm-Message-State: AJaThX5VJuXZDRRMDL/ebhKTIZ758T2osie73Teb4ktdaF8iG+5tnCan WdauirnZLHQfVBKtcO/uLIhGSw== X-Google-Smtp-Source: AGs4zMaFtRdIOCgwGS9GPLSUxQOjoA/M8hM679+xMHwQzuGjw7P3V63ZO3weQpVulOO4bFWtpIq5dQ== X-Received: by 10.36.124.197 with SMTP id a188mr30272212itd.63.1511812795992; Mon, 27 Nov 2017 11:59:55 -0800 (PST) Received: from ?IPv6:2607:f2c0:101:202:c849:dad7:a94e:7c1e? ([2607:f2c0:101:202:c849:dad7:a94e:7c1e]) by smtp.gmail.com with ESMTPSA id m72sm11927119ioe.40.2017.11.27.11.59.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 11:59:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Joe Abley In-Reply-To: Date: Mon, 27 Nov 2017 14:59:50 -0500 Cc: George Michaelson , tjw ietf , dnsop Content-Transfer-Encoding: quoted-printable Message-Id: <14790688-9023-4D64-8752-1C9859A82C43@hopcount.ca> References: <11C784A2-B8E1-4D63-81F9-B62AA148D9EE@hopcount.ca> To: Richard Barnes X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 19:59:59 -0000 On 27 Nov 2017, at 14:47, Richard Barnes wrote: > As tempting as it may be to do the easy thing, it's not always the = best use of resources. Looking at the closest tree might be easy for = one observer, but when you try to do it with enough observers to have a = result that's useful for the King of the Jungle, you end up with similar = tangles. >=20 > I don't think that it make sense to infer from the failure of RFC 8145 = that resolver/authoritative telemetry isn't possible -- just that it's = not possible with the heavy-weight machinery in that mechanism. To the = degree that the DNS still works at all, there must be some channel by = which information can be faithfully passed from authoritative to = resolver, which can presumably be used to bootstrap telemetry. Maybe = it's a TXT record with an HTTP URL; maybe it's a funny CNAME. In the case of the root zone, the additional complications include the = procedural difficulty in installing experimental records in the zone = itself, the amount of effort which has gone into reducing legitimate = reasons for resolvers to send queries to the root servers at all, e.g. = through the use of aggressive negative caching and even the TTLs on = delegation NS sets, and the effort required to do data collection on the = root servers, whose twelve operators manage many hundreds of instances. = The existence of caching (and the degree to which people take liberties = with what they can or should cache) also adds complication, not all of = which is deterministic. Although it is intuitively obvious that collecting data from millions of = end-users is harder than collecting data on hundreds of root server = instances, it turns out that there is a whole industry that more or less = exists to collect data from end-users already and no corresponding = mechanism for authority servers. Also counter-intuitively, some root = server operators view the traffic they receive as containing PII whilst = the privacy concerns with kskroll-sentinel seem benign. When it comes down to it, you can more often rely upon an end-user's = query being sent and a response being generated by a recursive server = than you can rely upon queries and responses being exchanged within a = (potentially complex) graph of resolvers and authority servers. That = potential complexity means that understanding whatever data you do = collect can be difficult. > Maybe you can't build a road through the jungle, but there are still = rivers that make it through, which can carry a message in a bottle. You might see a river go in and a river come out and be tempted to = assume that the bit in the middle is river-shaped, or that the two parts = you can see are connected, but you won't always be right. Joe= From nobody Mon Nov 27 13:47:08 2017 Return-Path: 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 4835A12702E for ; Mon, 27 Nov 2017 13:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com 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 ElDduJJXMy4O for ; Mon, 27 Nov 2017 13:47:06 -0800 (PST) Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B3F126C26 for ; Mon, 27 Nov 2017 13:47:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=374; q=dns/txt; s=VRSN; t=1511819226; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=/2ufHkpBNOtu0t6L0NpSOaNgXvT6Yl87CUzIxBQyG4o=; b=eL1TR+4MWRQ060CWhm4BsLOlul50jbGsDzMSMai5PfNVqJ2ceYZKTi1c K1F9dHpJY+NmqmD2ChnG+Xdt0iXUuKz3BFa5GFlPhNAIcv+SBKLHzL0Zs +QU625VjFQJ+N0U+naOzVJ473sbPBU+gB/O8Kk9gZKajA218cR8ytcZZq M75Bg/NDvKO31I6wSg8KhWXBdtDesTJEDWFki2j/FC+R8GLaz79KjMfPw 5g7QZPOMVevPSeAZKUBiFsxq97aUHrLHhVjU6KH8sBED0J/1x2Oyip7/2 H599CB9VHLe/s7vgTT4HM6cU0fEENtQhOJmir1Y8kdiHvFYueC+axBmpi Q==; X-IronPort-AV: E=Sophos;i="5.44,465,1505779200"; d="scan'208";a="3250355" IronPort-PHdr: =?us-ascii?q?9a23=3A3coQ7hNTeH/GxzbZ1L4l6mtUPXoX/o7sNwtQ0KIM?= =?us-ascii?q?zox0Iv35rarrMEGX3/hxlliBBdydsKMUzbKO+4nbGkU4qa6bt34DdJEeHzQksu?= =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1?= =?us-ascii?q?Ov71GonPhMiryuy+4ZPebgFLiTanfb9+MAi9oBnMuMURnYZsMLs6xAHTontPde?= =?us-ascii?q?RWxGdoKkyWkh3h+Mq+/4Nt/jpJtf45+MFOTav1f6IjTbxFFzsmKHw65NfqtRbY?= =?us-ascii?q?UwSC4GYXX3gMnRpJBwjF6wz6Xov0vyDnuOdxxDWWMMvrRr0yRD+s7bpkSAXwhS?= =?us-ascii?q?kHKTA37X3XhMJzgqJVoh2hpgBwzYHbb4yOKPp+Z6bdcc8GSWZdQMpcUTFKDIOm?= =?us-ascii?q?b4sICuoMJehUoInjqFsVthuxGw2sBPj3xjRViHH2wLc10+I/Hg3IwQctGM8BsX?= =?us-ascii?q?rKo9XuL6cdT+S1zLLTwDXdcfxWwzb96JPJchAup/GAR65/cc3UyUQ2EQ7Ok1ae?= =?us-ascii?q?qZT9Mj+IyugBqXWX4uhuWO61lmIqqw98riKxysojioTFnp8Zxkze+Slkwos5Oc?= =?us-ascii?q?e0RFN0bNOnCpdcqiKXOo1rSc04WW5oojw1yrgetJ6+eygF1YooygbEa/yCb4iI?= =?us-ascii?q?+hXjVPuNITtghHJqZra/hxGq/Ee70O38UNS40FJFrypAiNbMt3QN1xvO6sibVv?= =?us-ascii?q?dx4F2t2SiR2ADJ6+FEOkE0laXdK5I73rEwkZ8TvVzCHi/whkr2kLebelg49uSy?= =?us-ascii?q?9ujqYLvrqoWBO4J0hAzyKLoil8O/DOggNwgBRWmb+eCy1L35+k35Ra1HgeA4k6?= =?us-ascii?q?bHq5DaPtoUpqqiAwJOzIYs9Qy/Dza90NQZknkHKkhJdw6Aj4jsI13OOuz3De+j?= =?us-ascii?q?g1Swlzdm3+3JPrv6ApXKNnjOi7bhcqhh605S0gYzyspf551MALEbPP3zQlPxtM?= =?us-ascii?q?DfDhIhKQy0x/3oBc581oMGR2KDGLSZMayB+WOPs9guKOmFfoNdkj/nLfU+r6r0?= =?us-ascii?q?iXURmEcDO7K5i8g5cne9S75ZLl6CbH73xp8tDG4Ms0B2GOD1hUaZXDpIT2i/Ra?= =?us-ascii?q?Mn5z49TomhCNGQFciWnLWd0XLjTdVtbWdcBwXUHA=3D=3D?= X-IPAS-Result: =?us-ascii?q?A2FtAQBghhxa//WZrQpdGQEBAQEBAQEBAQEBAQcBAQEBAYU?= =?us-ascii?q?3B58qmH4KhTsChTcUAQEBAQEBAQEBAQKBEII4IoJGAQEBAQIBHR0/BQsCAQgNA?= =?us-ascii?q?QoeEDIlAgQOBYoaqTGKegEBAQEBAQEDAQEBAQEBAQEBAQEdgzqDXYIRgwKFHIN?= =?us-ascii?q?GgjIFokAGApcHAZFQlg0CBAsCGQGBOjaBc28VYwGBfoRVd4kXgRQBAQE?= Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id vARLl4B6013737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Nov 2017 16:47:04 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Mon, 27 Nov 2017 16:47:11 -0500 From: "Wessels, Duane" To: Richard Barnes CC: dnsop Thread-Topic: [EXTERNAL] [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel Thread-Index: AQHTZ8lHwca6neO6AEKOHsyrYpz6zw== Date: Mon, 27 Nov 2017 21:47:10 +0000 Message-ID: <8E8606DF-C134-4A81-8C6B-21BF8FA6EF31@verisign.com> References: <11C784A2-B8E1-4D63-81F9-B62AA148D9EE@hopcount.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 21:47:07 -0000 > On Nov 27, 2017, at 11:47 AM, Richard Barnes wrote: >=20 > I don't think that it make sense to infer from the failure of RFC 8145 ..= . Do you really think RFC 8145 is a failure (even having only recently learne= d about its existence)? No doubt there are complications and implementation hiccups but I think fai= lure is a bit harsh. DW = From nobody Mon Nov 27 14:12:58 2017 Return-Path: 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 13860127058 for ; Mon, 27 Nov 2017 14:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 smSL-GcQS0Nz for ; Mon, 27 Nov 2017 14:12:53 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA3751200C5 for ; Mon, 27 Nov 2017 14:12:52 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 27 Nov 2017 14:12:50 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Mon, 27 Nov 2017 14:12:50 -0800 From: Edward Lewis To: Richard Barnes , George Michaelson CC: tjw ietf , dnsop Thread-Topic: [Ext] Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel Thread-Index: AQHTXrWvP1ONuzm4NUCZOKbWpbl/f6MpHq4A//+9n4A= Date: Mon, 27 Nov 2017 22:12:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.28.0.171108 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3594636769_486981918" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 22:12:56 -0000 --B_3594636769_486981918 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit A couple of reactions to this message: On 11/27/17, 10:10, "DNSOP on behalf of Richard Barnes" wrote: > [one] should know better than to claim that a mechanism that requires resolver updates will have "immediate benefit" :) I have been impressed by the impact of "Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)". Although the document was published in April, it seems that it has worked its way into operating servers quite quickly. I see this as a testament to operators being able to pull off tech-refreshes more quickly as time progresses. That is one aspect of this I am walking away with. But "benefit."? One can debate the benefit of the quickly adopted mechanism. There's a lot of uncertainty in what is being seen, that is what I mean. Not meaning to demean the new mechanism, it does raise concerns about new proposals - which may also come with uncertainty. I recall a conversation from early in 2015, when I lamented the lack of feedback related to Automated Updates (RFC 5011's mechanism). I was told that if we had something, given a lack of a baseline, we would get confused with the results. Later, the "Signaling Trust Anchor Knowledge..." effort (RFC 8145) began and, well, that prophecy has been fulfilled. That's not a failure, just a learning curve. I'd not label it a failure as it hasn't lessened where we are, it has helped lead more investigation even if it hasn't given us something we fully understand yet. >wrong architecture for the long run. I'm unsure of that. I commented earlier that having the query/response mechanism be something the operator of the trust anchor store (connected to a DNSSEC validator that is part of a DNS cache, etc.) can use is a good first step. In the constrained use case of "me owning the test target" (by owning, I mean credentials to access the configuration files of the target) there's a lot we can get from a query/response mechanism. With that, whatever can be generalized for a replying party to glean and then report via a higher-layer test would be good. A (as opposed to "the") test harness (the higher-layer) could then be designed a few different ways. Describing the one the draft has in mind is a good idea, what I mean is that there could be other ways. I can understand reluctance to accept a particular way to perform the test, but to throw out the under layer with that bathwater isn't the best way to go. I had originally set out to agree with the "wrong architecture" for this reason though - I'd wish that there was a better description of managing secure entry points and trust anchors along the lines of a three-way handshake protocol. This begins with - how does a trust anchor manager know that it should be managing (pinning) keys for a domain, etc.? I'm not sure we can get there though. --B_3594636769_486981918 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 AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSdvsJdtNQ8trpjxfgEe8PA4Lf/8jAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMjcyMjEyNDlaMA0GCSqGSIb3 DQEBAQUABIIBAI4NaiccszI9+PM7u3cnia8Am79sUB7aZH2jBegkHMyxPu3TrQEWX4zgCY98 z7U0kWYBqzT+9PBU74nFmkG71cSci8XfHZt+gy7hLoei2jdR4nrlhC1Xjx+dPPHqq8nus7RQ pVStXXYFMIVymM7ITZ/szgKDmondNrFvtqdTQYb6JjPYPrY2g61IdJjrpyb5rJsUub82qSEB 2Uqop+yV+v4tjsuCeumPeBwDsNc37OkGLU+IWTrH3RyKpm+Jc/ASgYVTctXakOc5H5LrQT6O uCk3deT38NZKGW0DIB8f1WT38ADd65l5OKDx0Pb0GEGlSL4AtF+AA8JincgAss+6c+U= --B_3594636769_486981918-- From nobody Mon Nov 27 14:30:08 2017 Return-Path: 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 9D380127077; Mon, 27 Nov 2017 14:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 KH2S5UzUOr9Z; Mon, 27 Nov 2017 14:29:59 -0800 (PST) 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 25D081200C5; Mon, 27 Nov 2017 14:29:59 -0800 (PST) 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 E7B8C3B9A22; Mon, 27 Nov 2017 22:29:56 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A758E160048; Mon, 27 Nov 2017 22:29:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8FC53160070; Mon, 27 Nov 2017 22:29:56 +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 8uek7jRJZ179; Mon, 27 Nov 2017 22:29:56 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 9A94C160048; Mon, 27 Nov 2017 22:29:54 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <20171127094608.2usyoujtzv2k5unx@nic.fr> Date: Tue, 28 Nov 2017 09:29:51 +1100 Cc: Bob Harold , IETF DNSOP WG , 6man@ietf.org, v6sop@ietf.org, sunset4@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <04ECB158-1EF1-4CEF-937F-65048B10F2F5@isc.org> References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> <20171127094608.2usyoujtzv2k5unx@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 22:30:01 -0000 DNS64 requires EVERY validating client to support DNS64 prefix discover = and implement DNS64. If that isn=E2=80=99t breaks DNSSEC I don=E2=80=99t = know what is. > On 27 Nov 2017, at 8:46 pm, Stephane Bortzmeyer = wrote: >=20 > On Fri, Nov 24, 2017 at 10:00:54PM -0500, > Bob Harold wrote=20 > a message of 203 lines which said: >=20 >> - DNS64 breaks DNSSEC. >=20 > That's not a fair summary. People should read RFC 6147 and 7050 > before repeating this. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Nov 27 14:42:08 2017 Return-Path: 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 CAF8F129405 for ; Mon, 27 Nov 2017 14:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 G-sdz46R7GTC for ; Mon, 27 Nov 2017 14:42:06 -0800 (PST) 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 503F0127735 for ; Mon, 27 Nov 2017 14:42:06 -0800 (PST) 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 3B6C73B9A73; Mon, 27 Nov 2017 22:42:04 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id F4033160070; Mon, 27 Nov 2017 22:42:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E1319160048; Mon, 27 Nov 2017 22:42:03 +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 Fx78PmpzaBHx; Mon, 27 Nov 2017 22:42:03 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 22947160074; Mon, 27 Nov 2017 22:42:02 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <20171127095212.dkdgl5dkqn56arvh@nic.fr> Date: Tue, 28 Nov 2017 09:42:00 +1100 Cc: Shane Kerr , dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> <57628d3a-93ef-567d-09ca-a2b37112a544@time-travellers.org> <20171127095212.dkdgl5dkqn56arvh@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 22:42:08 -0000 > On 27 Nov 2017, at 8:52 pm, Stephane Bortzmeyer = wrote: >=20 > On Mon, Nov 27, 2017 at 09:32:00AM +0000, > Shane Kerr wrote=20 > a message of 45 lines which said: >=20 >> I just ran a check, and there are 23 TLD without any name servers >> that support IPv6. >=20 > Can you detail the methodology? For instance, did you measure what the > root announces (the glue records), what the TLD announces (the > authoritative AAAA records) or the reality (actual answers to DNS > requets over IPv6). https://ednscomp.isc.org/compliance/tld-report.html show TLD servers that are not answering (IPv4 and IPv6) as viewed from ISC=E2=80=99s = perspective. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Nov 27 16:30:11 2017 Return-Path: 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 E8FF8129439 for ; Mon, 27 Nov 2017 16:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZRuiVRrBjcEd for ; Mon, 27 Nov 2017 16:30:09 -0800 (PST) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF4D129435 for ; Mon, 27 Nov 2017 16:30:07 -0800 (PST) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id B783020658; Mon, 27 Nov 2017 16:30:06 -0800 (PST) From: Wes Hardaker To: tjw ietf Cc: dnsop References: Date: Mon, 27 Nov 2017 16:30:05 -0800 In-Reply-To: (tjw ietf's message of "Thu, 16 Nov 2017 16:23:32 +0800") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 00:30:10 -0000 tjw ietf writes: > The author has rolled out a new version addressing comments from the > meeting on Monday, and we feel it=E2=80=99s ready to move this along. FYI, I hate this document. I hate the idea of introducing yet another magic keyword into the DNS protocol that requires special handling. That being said, even with the above grumpiness, I DO SUPPORT the creation of the document (believe it or not) as I realize we don't have much of a choice in order to solve the very-important signaling problem we're current stuck with. I'll review (already have; comments coming later). --=20 Wes Hardaker USC/ISI From nobody Mon Nov 27 18:44:39 2017 Return-Path: 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 2ACBE129439 for ; Mon, 27 Nov 2017 18:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 OSfO0jZ-YYIk for ; Mon, 27 Nov 2017 18:44:37 -0800 (PST) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 10B6F129427 for ; Mon, 27 Nov 2017 18:44:36 -0800 (PST) Received: from lxomp90v.corp.intranet (lxomp90v.corp.intranet [151.117.203.59]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id vAS2iOXC040095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 27 Nov 2017 20:44:25 -0600 Received: from lxomp90v.corp.intranet (localhost [127.0.0.1]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id vAS2iJv0002389; Mon, 27 Nov 2017 20:44:19 -0600 Received: from lxdnp32k.corp.intranet (lxomp81v.corp.intranet [151.117.18.14]) by lxomp90v.corp.intranet (8.14.8/8.14.8) with ESMTP id vAS2iJ3m002385 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NO); Mon, 27 Nov 2017 20:44:19 -0600 Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id vAS2iJNd063190; Mon, 27 Nov 2017 19:44:19 -0700 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id vAS2iIQc063185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Nov 2017 19:44:19 -0700 Received: from PODCWMBXEX501.ctl.intranet ([169.254.1.216]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0339.000; Mon, 27 Nov 2017 20:44:18 -0600 From: "Woodworth, John R" To: "'Daniel Shaw'" , "dnsop@ietf.org" CC: "Woodworth, John R" Thread-Topic: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt Thread-Index: AQHTYRvan/iKFaAXSU2coiu3/nPrHqMoiPaAgACY7RA= Date: Tue, 28 Nov 2017 02:44:17 +0000 Message-ID: References: <201711190950.vAJ9oDBB030859@atl4mhob09.registeredsite.com> <1A384FE2-0AC0-4309-9B28-0C81EBE1E1E6@afrinic.net> In-Reply-To: <1A384FE2-0AC0-4309-9B28-0C81EBE1E1E6@afrinic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 02:44:38 -0000 > -----Original Message----- > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Daniel Shaw > > I have uses cases where this would be handy. I hope that this progresses. > Hi Daniel, Thank you for taking the time to look over our I-D and your kind words. Thanks, John > > I'd love to see all those smarter than me work on it, so support adoption= . > > Regards, > Daniel > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Tue Nov 28 09:59:10 2017 Return-Path: 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 44F93128896 for ; Tue, 28 Nov 2017 09:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized-org.20150623.gappssmtp.com 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 xvig8niUktR9 for ; Tue, 28 Nov 2017 09:59:07 -0800 (PST) Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9322D12420B for ; Tue, 28 Nov 2017 09:59:07 -0800 (PST) Received: by mail-pl0-x236.google.com with SMTP id g2so370241pli.8 for ; Tue, 28 Nov 2017 09:59:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=2yGlsHUU5A7fwp+Tx0zui6ibPcsVF0huThMeeJGpUbg=; b=QKPyKNrSVSheoAbmsSGBf4KYa4KgDIb+AKn5AeJBVKxAM/EU2zHuJiH5Wz23ThPmsY IyGJmaKleLPl6yiB9A2sBWiYtDZYXG5AcBxjWjpN8FgM5tAw0aCzk4qD/0NO3lkym/aj 3zE4mGtx9YEyF55LrJdRYIuRewrkE6QJFVSZ2RFtKu9UsmIMjOYVEc5buY7L/vcyBlkV XaPPNR9k3QXyYYVYnbcuH5ELRDSydKWTNq7PKTmnu7LunIFPY6DFxyMCh/2twZ1uoSdn I21Q8erDko2DUlPCtpGde4OcPfSXkZDB2E41UzmVZ74G88m/PujTixz4KlhZYpUwjwcF swQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=2yGlsHUU5A7fwp+Tx0zui6ibPcsVF0huThMeeJGpUbg=; b=JAxfWlFBoxr9sbWsnwxsLpme9ncBnctaAuLvShF1KKQPRyR5xjOqXp9A1q4qbmhycC M/Yq1qMKRQDu3IDuyUnjEiZ1cXCPEqEaCN8oFX+UhOKiP3QbCwgW3WIjlz005Ld846KI Rk3d45pqNGOKHPnGdHYHywUq46iSqi7p8HrNpTLBhUF4tG5mTBIpTj5fO719ycYaOpkW KMkAt1XJTN8Og6ureenrY2BhFKq2EopRPlGjR9WMDii47coRcTRCAhvEnXQZcCrKBOds c0B5vLjqqGtHS6P168PgHN7DuvJZVZboVVYKO1F4DfbYgKiZ8ga5qRw+6RDL81G5rd/u m96w== X-Gm-Message-State: AJaThX4YTh8SEeqvD3w33Htk2O5oi95NleOxLYtKycDTHkbN9NcBtq7b gxnV5Rpk+sOvC41qTlrkO0nyQA== X-Google-Smtp-Source: AGs4zMY9VWENn0i14OfwmYyWNhF/6zoK6a0eN4XI+z9myqBHJz+M7E145uf89b45cIyCNxCfeokQ0A== X-Received: by 10.159.198.1 with SMTP id f1mr5095621plo.450.1511891947215; Tue, 28 Nov 2017 09:59:07 -0800 (PST) Received: from [2620:0:2d0:110:400::] ([2620:0:2d0:110:911f:c272:33b1:59d9]) by smtp.gmail.com with ESMTPSA id h69sm55399239pfk.166.2017.11.28.09.59.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 09:59:06 -0800 (PST) Date: Tue, 28 Nov 2017 09:48:24 -0800 From: David Conrad To: Joe Abley , Richard Barnes Cc: tjw ietf , dnsop , George Michaelson Message-ID: <8883eb76-672e-45f3-953c-64a1b3a22b2e@Spark> In-Reply-To: References: <11C784A2-B8E1-4D63-81F9-B62AA148D9EE@hopcount.ca> X-Readdle-Message-ID: 8883eb76-672e-45f3-953c-64a1b3a22b2e@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5a1da3e9_19495cff_8b5" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 17:59:09 -0000 --5a1da3e9_19495cff_8b5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Nov 27, 2017, 11:47 AM -0800, Richard Barnes , wrote: > I don't think that it make sense to infer from the failure of R=46C 814= 5 that resolver/authoritative telemetry isn't possible Huh=3F R=46C 8145 wasn=E2=80=99t a failure =E2=80=94 it was stunningly su= ccessful. Within a few months of publication it provided us insights we h= adn=E2=80=99t before had into how the infrastructure was actually working= . =C2=A0This was unexpected. > To the degree that the DNS still works at all, there must be some chann= el by which information can be faithfully passed from authoritative to re= solver, which can presumably be used to bootstrap telemetry.=C2=A0 Maybe = it's a TXT record with an HTTP URL; maybe it's a funny CNAME. Maybe it is, and when we see another viable channel, we=E2=80=99ll undoub= tedly make use of it. Until then, adding something like sentinel would se= em to be a useful way of gathering information about the state of reality= . > Maybe you can't build a road through the jungle, but there are still ri= vers that make it through, which can carry a message in a bottle. I don=E2=80=99t want to let the perfect be the enemy of the =E2=80=A6 wel= l, perhaps not good, but functional. Regards, -drc --5a1da3e9_19495cff_8b5 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On Nov 27, 2017,= 11:47 AM -0800, Richard Barnes <rlb=40ipv.sx>, wrote:

I don't think that it make sense to infer from the failure of R=46C = 8145 that resolver/authoritative telemetry isn't possible

Huh=3F R=46C 8145 wasn=E2=80=99t a failure =E2=80=94 it was stunning= ly successful. Within a few months of publication it provided us insights= we hadn=E2=80=99t before had into how the infrastructure was actually wo= rking. &=23160;This was unexpected.

To the degree that the DNS still works at all, there must be some ch= annel by which information can be faithfully passed from authoritative to= resolver, which can presumably be used to bootstrap telemetry.&=23160; M= aybe it's a TXT record with an HTTP URL; maybe it's a funny CNAME.&=23160= ;

Maybe it is, and when we see another viable channel, we=E2=80=99ll u= ndoubtedly make use of it. Until then, adding something like sentinel wou= ld seem to be a useful way of gathering information about the state of re= ality.

Maybe you can't build a road through the jungle, but there are still= rivers that make it through, which can carry a message in a bottle.&=231= 60;

I don=E2=80=99t want to let the perfect be the enemy of the =E2=80=A6= well, perhaps not good, but functional.

Regards,
-drc

--5a1da3e9_19495cff_8b5-- From nobody Tue Nov 28 11:50:32 2017 Return-Path: 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 A04CB1200CF for ; Tue, 28 Nov 2017 11:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Yz7dwYQE; dkim=pass (1024-bit key) header.d=yitter.info header.b=Rc8U5sE8 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 c9fjvyskn4t2 for ; Tue, 28 Nov 2017 11:50:29 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4F3128B88 for ; Tue, 28 Nov 2017 11:50:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 19545C06D0 for ; Tue, 28 Nov 2017 19:50:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511898628; bh=SZqygspf426Pi/9UzmOWIeU+5VQe8BBTGdyI3h5MguU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Yz7dwYQE1gIFNCTaC3//VFI0b5wd0ZR9l4JYdRtMrb9RhvPBE4tYLcsmrhSvvq0Ar S3KOakj/qsj8OpvUfUfDrT6+VBJVqYv/oRvD7+RO/pFcgjitKNTMtK8wqo0monPvs1 QwYxiOfuP6mgsfrl26QUBTHFr82mP57/AnHfFjxc= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wC9TO5c38ztp for ; Tue, 28 Nov 2017 19:50:26 +0000 (UTC) Date: Tue, 28 Nov 2017 14:50:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511898626; bh=SZqygspf426Pi/9UzmOWIeU+5VQe8BBTGdyI3h5MguU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Rc8U5sE8Taukl5RUaxPA8iftzYwurCmn1EOrIBgehWA+Kah9ps2yACwChCtiAFv4U WEXFwSgdFy+3Xa2W9usPuQAs75r9NcLQwXrsqh5soU09hEguhbeczxYtm0UpmWngQm GC6vOkomz1XlxvH8SVQ9+5fMH8we0vvO/Hdz0H5k= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 19:50:30 -0000 Dear colleagues, Joe Abley and I have just submitted a draft (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/) that is intended to capture the discussion here about referrals and how to describe them. It is intended for BCP, and it discourages upward referrals by authoritative servers. That leaves the task of the referrals definition. I have some new text below: ---%<---cut here--- Referral: A type of response in which a server, signalling that it is not authoritative for an answer, provides the querying resolver with an alternative place to send its query. A referral contains an empty answer section. It contains the NS RRset for the referred-to zone in the authority section. It may contain RRs that provide addresses in the additional section. The AA bit is clear. There are two types of referral response. The first is a downward referral (sometimes described as "delegation response"), where the server is authoritative for some portion of the QNAME. The Authority section RRset's RDATA contains the name servers specified at the referred-to zone cut. In normal DNS operation, this kind of response is required in order to find names beneath a delegation. The second is an upward referral (sometimes described as "root referral" or just "referral response", as distinct from the delegation response above), where the server is not authoritative for any portion of the QNAME. When this happens, the referred-to zone in the Authority section is usually the root zone (.). In normal DNS operation, this kind of response is not strictly speaking required to work, and in practice some authoritative server operators will not return referral responses beyond those required for delegation. [optional: see draft-sullivan-dnsop-refer-down-00 or whatever. We'll only include this reference if the other draft reaches WG consensus before terminology-bis] ---cut here--->%--- Comments, please. Also, Joe and I solicit comments on the referrals draft proper, but it would be nice to put that in a different thread. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Nov 28 12:40:10 2017 Return-Path: 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 A4F57127078 for ; Tue, 28 Nov 2017 12:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 2VWaODlQ6ci2 for ; Tue, 28 Nov 2017 12:40:07 -0800 (PST) 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 6245E124239 for ; Tue, 28 Nov 2017 12:40:07 -0800 (PST) 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 736CF3ABB53; Tue, 28 Nov 2017 20:39:44 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2E8DC16007A; Tue, 28 Nov 2017 20:39:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2190B160079; Tue, 28 Nov 2017 20:39:43 +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 NDzbJOY1N9uF; Tue, 28 Nov 2017 20:39:43 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 43A46160047; Tue, 28 Nov 2017 20:39:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> Date: Wed, 29 Nov 2017 07:39:42 +1100 Cc: dnsop@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 20:40:08 -0000 The AA bit may or may not be set depending upon whether the response contains a CNAME/DNAME or not. > On 29 Nov 2017, at 6:50 am, Andrew Sullivan wrote: > > Dear colleagues, > > Joe Abley and I have just submitted a draft > (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/) > that is intended to capture the discussion here about referrals and > how to describe them. It is intended for BCP, and it discourages > upward referrals by authoritative servers. > > That leaves the task of the referrals definition. I have some new > text below: > > ---%<---cut here--- > > Referral: A type of response in which a server, signalling that it is > not authoritative for an answer, provides the querying resolver with > an alternative place to send its query. A referral contains an empty > answer section. It contains the NS RRset for the referred-to zone in > the authority section. It may contain RRs that provide addresses in > the additional section. The AA bit is clear. > > There are two types of referral response. The first is a downward > referral (sometimes described as "delegation response"), where the > server is authoritative for some portion of the QNAME. The Authority > section RRset's RDATA contains the name servers specified at the > referred-to zone cut. In normal DNS operation, this kind of response > is required in order to find names beneath a delegation. > > The second is an upward referral (sometimes described as "root > referral" or just "referral response", as distinct from the delegation > response above), where the server is not authoritative for any portion > of the QNAME. When this happens, the referred-to zone in the > Authority section is usually the root zone (.). In normal DNS > operation, this kind of response is not strictly speaking required to > work, and in practice some authoritative server operators will not > return referral responses beyond those required for delegation. > > [optional: see draft-sullivan-dnsop-refer-down-00 or whatever. We'll > only include this reference if the other draft reaches WG consensus > before terminology-bis] > > ---cut here--->%--- > > Comments, please. Also, Joe and I solicit comments on the referrals > draft proper, but it would be nice to put that in a different thread. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Nov 28 15:19:04 2017 Return-Path: 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 1FA65128B44 for ; Tue, 28 Nov 2017 15:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 nSq-kqIJG9bD for ; Tue, 28 Nov 2017 15:19:01 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A202B126C26 for ; Tue, 28 Nov 2017 15:19:01 -0800 (PST) Received: from [172.31.1.47] (unknown [222.128.198.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 7FAC961FA2; Tue, 28 Nov 2017 23:19:00 +0000 (UTC) Message-ID: <5A1DEEE1.3070809@redbarn.org> Date: Tue, 28 Nov 2017 15:18:57 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Andrew Sullivan CC: dnsop@ietf.org References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> In-Reply-To: <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 23:19:03 -0000 Andrew Sullivan wrote: > Dear colleagues, > > Joe Abley and I have just submitted a draft > (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/) > that is intended to capture the discussion here about referrals and > how to describe them. It is intended for BCP, and it discourages > upward referrals by authoritative servers. > > That leaves the task of the referrals definition. I have some new > text below: > > ---%<---cut here--- > > ... > > The second is an upward referral (sometimes described as "root > referral" or just "referral response", as distinct from the delegation > response above), where the server is not authoritative for any portion > of the QNAME. When this happens, the referred-to zone in the > Authority section is usually the root zone (.). In normal DNS > operation, this kind of response is not strictly speaking required to > work, and in practice some authoritative server operators will not > return referral responses beyond those required for delegation. > > ... > > ---cut here--->%--- > > Comments, please. Also, Joe and I solicit comments on the referrals > draft proper, but it would be nice to put that in a different thread. what would "to work" mean in the above text? if you ask some authority server a question, it is either authoritative for some part of it in which case you'll get NOERROR and either an answer or a referral, or it is not authoritative and nothing it can tell you will help in any way other than some kind of "i am not authoritative for any part of the question you have asked me". that an upward referral could "work" in the above-reference sense seems to imply that the authority server you've queried, knows more about where the zone really is, than you could learn by walking down from the root. that's a walking talking nonsequitur. could you tell me what you really mean by "to work" since it can't possibly be that? -- P Vixie From nobody Tue Nov 28 17:17:42 2017 Return-Path: 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 D2EA1120724 for ; Tue, 28 Nov 2017 17:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=a/9KUlHI; dkim=pass (1024-bit key) header.d=yitter.info header.b=Be+byHkv 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 Exj0HKhyhAAu for ; Tue, 28 Nov 2017 17:17:39 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1894612025C for ; Tue, 28 Nov 2017 17:17:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 5AF38C06D1; Wed, 29 Nov 2017 01:17:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511918258; bh=CY+1V76Ip9/ce4jHuZIxyEJEGsQ8Dr4OKo9xV6706xQ=; h=From:To:CC:Date:In-Reply-To:References:Subject:From; b=a/9KUlHIVNOPgDH0fdgW5Ri8OwzDc1pBwV9dq0EJz8qMriuy/ARlzX4Jgoi3YLyXb 2zQUZFBBeHgVX23pVOo412yOWWLgGfdBmMBkAYzcB1CtWM7DT1YTn9qKs/FNCBR2xX 6U9zm417jO5AiWTHmregNbA66SEq5AMSfXq2Bg8s= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qek3xx6755FU; Wed, 29 Nov 2017 01:17:36 +0000 (UTC) From: Andrew Sullivan DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511918256; bh=CY+1V76Ip9/ce4jHuZIxyEJEGsQ8Dr4OKo9xV6706xQ=; h=From:To:CC:Date:In-Reply-To:References:Subject:From; b=Be+byHkv1sfxPaKOHPEJQMc19KaGGgAWlKzDNl8RR50BmwpkmjLElC7yeJU9qMb3Z GIsjv3rAOG15p4Un71rQm+jgWy3SgmS4oRv+bgxb2iwjI0VuGoGgg1+aU+10mHAhgi 7z/hZyiDuo5VkkB+iwFvzdJPsYWDjBWqEHUkHfWk= To: Mark Andrews CC: Date: Tue, 28 Nov 2017 20:17:34 -0500 Message-ID: <1600559b7b0.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> In-Reply-To: References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 01:17:41 -0000 Excellent point! Thanks. -- Please excuse my clumbsy thums ---------- On November 28, 2017 15:40:14 Mark Andrews wrote: > The AA bit may or may not be set depending upon whether the response contains > a CNAME/DNAME or not. > >> On 29 Nov 2017, at 6:50 am, Andrew Sullivan wrote: >> >> Dear colleagues, >> >> Joe Abley and I have just submitted a draft >> (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/) >> that is intended to capture the discussion here about referrals and >> how to describe them. It is intended for BCP, and it discourages >> upward referrals by authoritative servers. >> >> That leaves the task of the referrals definition. I have some new >> text below: >> >> ---%<---cut here--- >> >> Referral: A type of response in which a server, signalling that it is >> not authoritative for an answer, provides the querying resolver with >> an alternative place to send its query. A referral contains an empty >> answer section. It contains the NS RRset for the referred-to zone in >> the authority section. It may contain RRs that provide addresses in >> the additional section. The AA bit is clear. >> >> There are two types of referral response. The first is a downward >> referral (sometimes described as "delegation response"), where the >> server is authoritative for some portion of the QNAME. The Authority >> section RRset's RDATA contains the name servers specified at the >> referred-to zone cut. In normal DNS operation, this kind of response >> is required in order to find names beneath a delegation. >> >> The second is an upward referral (sometimes described as "root >> referral" or just "referral response", as distinct from the delegation >> response above), where the server is not authoritative for any portion >> of the QNAME. When this happens, the referred-to zone in the >> Authority section is usually the root zone (.). In normal DNS >> operation, this kind of response is not strictly speaking required to >> work, and in practice some authoritative server operators will not >> return referral responses beyond those required for delegation. >> >> [optional: see draft-sullivan-dnsop-refer-down-00 or whatever. We'll >> only include this reference if the other draft reaches WG consensus >> before terminology-bis] >> >> ---cut here--->%--- >> >> Comments, please. Also, Joe and I solicit comments on the referrals >> draft proper, but it would be nice to put that in a different thread. >> >> Best regards, >> >> A >> >> -- >> Andrew Sullivan >> ajs@anvilwalrusden.com >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue Nov 28 17:45:15 2017 Return-Path: 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 7165C129329 for ; Tue, 28 Nov 2017 17:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Qrq82eEL; dkim=pass (1024-bit key) header.d=yitter.info header.b=cZAbhZ37 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 LXhHMRDWBhbx for ; Tue, 28 Nov 2017 17:45:10 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968E01293DA for ; Tue, 28 Nov 2017 17:45:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id E98E9C06D0 for ; Wed, 29 Nov 2017 01:44:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511919879; bh=jL0HMSCEBrvfEqtC6mik8hJq1jKqTOYaw7wZ+05eU2E=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Qrq82eELzkyER6tHgEPfQTvcnMs86Shm6aELWst0dLi1xHg2sgwVH2JIjknXTYHp2 m2SGN4SZ3b4L4xDZS5aZsZKdGlk+9bivJEqjiGyHcnXvNVRZ+wPhywiluc5mI/65Ak W+RVT0ZVl5E2Mao7/TdNxZ+BvgV5NLA/7laXe/Ww= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZqYQtyhWMv4 for ; Wed, 29 Nov 2017 01:44:38 +0000 (UTC) Date: Tue, 28 Nov 2017 20:44:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511919878; bh=jL0HMSCEBrvfEqtC6mik8hJq1jKqTOYaw7wZ+05eU2E=; h=Date:From:To:Subject:References:In-Reply-To:From; b=cZAbhZ37YBaMT40mXdRGIh3JgWNjWBCyEFslnOjDmRKVM7M5KuL/qNEZAwlz1RbyJ YOwG5SQ2yHiq33wFOEW2EYMhXYhoqmE190URL9hby1txbzqXSCXyU4LJfhmsLCYiQc Fuh8Wlh9yZbGhXxpEMn8XMoGlEsFcOzyWy4yn2h4= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 01:45:14 -0000 Hi, On Wed, Nov 29, 2017 at 07:39:42AM +1100, Mark Andrews wrote: > The AA bit may or may not be set depending upon whether the response contains > a CNAME/DNAME or not. > I replied with an enthusiastic "thanks" because this struck me as obviously correct, but then I though I'd better look at the algorithm again. And now I have a problem. 3.a is the CNAME case, but it's not a referral in the 1035 sense. 3.b takes us out of the authoritative data, so AA should not be set. Now, in RFC 6672 the DNAME processing happens at step 3.C, which undertakes the DNAME processing. The resulting answer goes into the answer section and processing continues. None of these steps seems to provide the case where a referral happens but the AA bit is set. So, while I feel like I agree that in some cases the AA bit should be set and not clear in case the response contains a CNAME or DNAME, I'm trying to figure out whether such responses are really referrals or else just intermediate steps. RFC 6672 doesn't call them referrals. Maybe this is a bit of informal jargon that needs clarifying? Thanks for the contribution, and best regards, A > > On 29 Nov 2017, at 6:50 am, Andrew Sullivan wrote: > > > > Dear colleagues, > > > > Joe Abley and I have just submitted a draft > > (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/) > > that is intended to capture the discussion here about referrals and > > how to describe them. It is intended for BCP, and it discourages > > upward referrals by authoritative servers. > > > > That leaves the task of the referrals definition. I have some new > > text below: > > > > ---%<---cut here--- > > > > Referral: A type of response in which a server, signalling that it is > > not authoritative for an answer, provides the querying resolver with > > an alternative place to send its query. A referral contains an empty > > answer section. It contains the NS RRset for the referred-to zone in > > the authority section. It may contain RRs that provide addresses in > > the additional section. The AA bit is clear. > > > > There are two types of referral response. The first is a downward > > referral (sometimes described as "delegation response"), where the > > server is authoritative for some portion of the QNAME. The Authority > > section RRset's RDATA contains the name servers specified at the > > referred-to zone cut. In normal DNS operation, this kind of response > > is required in order to find names beneath a delegation. > > > > The second is an upward referral (sometimes described as "root > > referral" or just "referral response", as distinct from the delegation > > response above), where the server is not authoritative for any portion > > of the QNAME. When this happens, the referred-to zone in the > > Authority section is usually the root zone (.). In normal DNS > > operation, this kind of response is not strictly speaking required to > > work, and in practice some authoritative server operators will not > > return referral responses beyond those required for delegation. > > > > [optional: see draft-sullivan-dnsop-refer-down-00 or whatever. We'll > > only include this reference if the other draft reaches WG consensus > > before terminology-bis] > > > > ---cut here--->%--- > > > > Comments, please. Also, Joe and I solicit comments on the referrals > > draft proper, but it would be nice to put that in a different thread. > > > > Best regards, > > > > A > > > -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Nov 28 17:47:37 2017 Return-Path: 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 3E877127005 for ; Tue, 28 Nov 2017 17:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 h2zfEfrgyqqY for ; Tue, 28 Nov 2017 17:47:32 -0800 (PST) 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 819F6126E7A for ; Tue, 28 Nov 2017 17:47:32 -0800 (PST) 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 0AA193B5F58; Wed, 29 Nov 2017 01:46:11 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C873A160047; Wed, 29 Nov 2017 01:46:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id ABD9E160051; Wed, 29 Nov 2017 01:46:10 +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 omug8gWCc5Tf; Wed, 29 Nov 2017 01:46:10 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id D9645160047; Wed, 29 Nov 2017 01:46:09 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> Date: Wed, 29 Nov 2017 12:46:07 +1100 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 01:47:34 -0000 GO READ STD13! > On 29 Nov 2017, at 12:44 pm, Andrew Sullivan = wrote: >=20 > Hi, >=20 > On Wed, Nov 29, 2017 at 07:39:42AM +1100, Mark Andrews wrote: >> The AA bit may or may not be set depending upon whether the response = contains >> a CNAME/DNAME or not. =20 >>=20 >=20 > I replied with an enthusiastic "thanks" because this struck me as > obviously correct, but then I though I'd better look at the algorithm > again. And now I have a problem. >=20 > 3.a is the CNAME case, but it's not a referral in the 1035 sense. >=20 > 3.b takes us out of the authoritative data, so AA should not be set. >=20 > Now, in RFC 6672 the DNAME processing happens at step 3.C, which > undertakes the DNAME processing. The resulting answer goes into the > answer section and processing continues. >=20 > None of these steps seems to provide the case where a referral happens > but the AA bit is set. So, while I feel like I agree that in some > cases the AA bit should be set and not clear in case the response > contains a CNAME or DNAME, I'm trying to figure out whether such > responses are really referrals or else just intermediate steps. RFC > 6672 doesn't call them referrals. Maybe this is a bit of informal > jargon that needs clarifying? >=20 > Thanks for the contribution, and best regards, >=20 > A >=20 >>> On 29 Nov 2017, at 6:50 am, Andrew Sullivan = wrote: >>>=20 >>> Dear colleagues, >>>=20 >>> Joe Abley and I have just submitted a draft >>> (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/) >>> that is intended to capture the discussion here about referrals and >>> how to describe them. It is intended for BCP, and it discourages >>> upward referrals by authoritative servers. >>>=20 >>> That leaves the task of the referrals definition. I have some new >>> text below: >>>=20 >>> ---%<---cut here--- >>>=20 >>> Referral: A type of response in which a server, signalling that it = is >>> not authoritative for an answer, provides the querying resolver with >>> an alternative place to send its query. A referral contains an = empty >>> answer section. It contains the NS RRset for the referred-to zone = in >>> the authority section. It may contain RRs that provide addresses in >>> the additional section. The AA bit is clear. >>>=20 >>> There are two types of referral response. The first is a downward >>> referral (sometimes described as "delegation response"), where the >>> server is authoritative for some portion of the QNAME. The = Authority >>> section RRset's RDATA contains the name servers specified at the >>> referred-to zone cut. In normal DNS operation, this kind of = response >>> is required in order to find names beneath a delegation. >>>=20 >>> The second is an upward referral (sometimes described as "root >>> referral" or just "referral response", as distinct from the = delegation >>> response above), where the server is not authoritative for any = portion >>> of the QNAME. When this happens, the referred-to zone in the >>> Authority section is usually the root zone (.). In normal DNS >>> operation, this kind of response is not strictly speaking required = to >>> work, and in practice some authoritative server operators will not >>> return referral responses beyond those required for delegation. >>>=20 >>> [optional: see draft-sullivan-dnsop-refer-down-00 or whatever. = We'll >>> only include this reference if the other draft reaches WG consensus >>> before terminology-bis] >>>=20 >>> ---cut here--->%--- >>>=20 >>> Comments, please. Also, Joe and I solicit comments on the referrals >>> draft proper, but it would be nice to put that in a different = thread. >>>=20 >>> Best regards, >>>=20 >>> A >>>=20 >>=20 >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Nov 28 17:47:57 2017 Return-Path: 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 57938129329 for ; Tue, 28 Nov 2017 17:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=IIGlCZ0N; dkim=pass (1024-bit key) header.d=yitter.info header.b=dnxPKBBw 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 GBp-vZ2S8-rm for ; Tue, 28 Nov 2017 17:47:52 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA99B1293E0 for ; Tue, 28 Nov 2017 17:47:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 518F9C06D0 for ; Wed, 29 Nov 2017 01:47:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511920070; bh=t0EMAUST7/zLOXHW9uscCFBXmqg5j4i6BDp/gN4UCcY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=IIGlCZ0N2X6VhsCqXKYJb4wF5wtWxzTneebOKWqCOjsIRJm4s64+uKwa1Uwdy7IRG toc1SOwgzSa1CiCnDOC01G9tBYLHQyN5S2UQTBMP9LS4XzKPeO7rkJzQ0/anYghoZ4 uWzcnc2Fen28mYZee55LwWVEB5XJlo3PKeN5/eLM= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vesKsrAgzehl for ; Wed, 29 Nov 2017 01:47:49 +0000 (UTC) Date: Tue, 28 Nov 2017 20:47:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511920069; bh=t0EMAUST7/zLOXHW9uscCFBXmqg5j4i6BDp/gN4UCcY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=dnxPKBBwgOVs92m0kbei8mk6MDoTbioraqzyw+scGJcr0b1VGzfN00rEknjt/p8IQ jUyy+eNBpnITSWUZTv/oPhvf1GNk328YWpOeVksDN0coNbiPgpTvzEGcBxu7ggd9YI uhvmCDGGrcmrCuSyFTqNOG1xGMJ4DqF6Je/oBqUg= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <5A1DEEE1.3070809@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A1DEEE1.3070809@redbarn.org> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 01:47:56 -0000 On Tue, Nov 28, 2017 at 03:18:57PM -0800, Paul Vixie wrote: > what would "to work" mean in the above text? "Not strictly speaking required to work" was intended to observe that, if you didn't get a referral under this condition, nothing ought to break (or, if it did, it was already broken). The point is in contrast to the downward referrals case, which _must_ work or delegation doesn't. I'm nervous about someone running off saying, "IETF says referrals don't work," which is clearly not the point. > that an upward referral could "work" in the above-reference sense seems to > imply that the authority server you've queried, knows more about where the > zone really is, than you could learn by walking down from the root. that's a > walking talking nonsequitur. could you tell me what you really mean by "to > work" since it can't possibly be that? Indeed, it is not that. Suggestions on how to make this clearer are welcome. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Nov 28 17:50:17 2017 Return-Path: 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 7BCF81286D6 for ; Tue, 28 Nov 2017 17:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 oRP2FQK7ODta for ; Tue, 28 Nov 2017 17:49:54 -0800 (PST) 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 AA79D126E7A for ; Tue, 28 Nov 2017 17:49:54 -0800 (PST) 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 06D3F3B5F58; Wed, 29 Nov 2017 01:49:52 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D609B160047; Wed, 29 Nov 2017 01:49:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BFDA8160051; Wed, 29 Nov 2017 01:49:51 +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 G0JdHjRUBMvu; Wed, 29 Nov 2017 01:49:51 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id EA7FE160047; Wed, 29 Nov 2017 01:49:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> Date: Wed, 29 Nov 2017 12:49:48 +1100 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7EA7E605-5375-4D13-B525-6F097512E5E9@isc.org> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> To: Andrew Sullivan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 01:50:16 -0000 AA Authoritative Answer - this bit is valid in responses, and specifies that the responding name server is an authority for the domain name in question section. Note that the contents of the answer section may have multiple owner names because of aliases. The AA bit corresponds to the name which matches the query name, or the first owner name in the answer section. > On 29 Nov 2017, at 12:46 pm, Mark Andrews wrote: >=20 > GO READ STD13! >=20 >> On 29 Nov 2017, at 12:44 pm, Andrew Sullivan = wrote: >>=20 >> Hi, >>=20 >> On Wed, Nov 29, 2017 at 07:39:42AM +1100, Mark Andrews wrote: >>> The AA bit may or may not be set depending upon whether the response = contains >>> a CNAME/DNAME or not. =20 >>>=20 >>=20 >> I replied with an enthusiastic "thanks" because this struck me as >> obviously correct, but then I though I'd better look at the algorithm >> again. And now I have a problem. >>=20 >> 3.a is the CNAME case, but it's not a referral in the 1035 sense. >>=20 >> 3.b takes us out of the authoritative data, so AA should not be set. >>=20 >> Now, in RFC 6672 the DNAME processing happens at step 3.C, which >> undertakes the DNAME processing. The resulting answer goes into the >> answer section and processing continues. >>=20 >> None of these steps seems to provide the case where a referral = happens >> but the AA bit is set. So, while I feel like I agree that in some >> cases the AA bit should be set and not clear in case the response >> contains a CNAME or DNAME, I'm trying to figure out whether such >> responses are really referrals or else just intermediate steps. RFC >> 6672 doesn't call them referrals. Maybe this is a bit of informal >> jargon that needs clarifying? >>=20 >> Thanks for the contribution, and best regards, >>=20 >> A >>=20 >>>> On 29 Nov 2017, at 6:50 am, Andrew Sullivan = wrote: >>>>=20 >>>> Dear colleagues, >>>>=20 >>>> Joe Abley and I have just submitted a draft >>>> (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/) >>>> that is intended to capture the discussion here about referrals and >>>> how to describe them. It is intended for BCP, and it discourages >>>> upward referrals by authoritative servers. >>>>=20 >>>> That leaves the task of the referrals definition. I have some new >>>> text below: >>>>=20 >>>> ---%<---cut here--- >>>>=20 >>>> Referral: A type of response in which a server, signalling that it = is >>>> not authoritative for an answer, provides the querying resolver = with >>>> an alternative place to send its query. A referral contains an = empty >>>> answer section. It contains the NS RRset for the referred-to zone = in >>>> the authority section. It may contain RRs that provide addresses = in >>>> the additional section. The AA bit is clear. >>>>=20 >>>> There are two types of referral response. The first is a downward >>>> referral (sometimes described as "delegation response"), where the >>>> server is authoritative for some portion of the QNAME. The = Authority >>>> section RRset's RDATA contains the name servers specified at the >>>> referred-to zone cut. In normal DNS operation, this kind of = response >>>> is required in order to find names beneath a delegation. >>>>=20 >>>> The second is an upward referral (sometimes described as "root >>>> referral" or just "referral response", as distinct from the = delegation >>>> response above), where the server is not authoritative for any = portion >>>> of the QNAME. When this happens, the referred-to zone in the >>>> Authority section is usually the root zone (.). In normal DNS >>>> operation, this kind of response is not strictly speaking required = to >>>> work, and in practice some authoritative server operators will not >>>> return referral responses beyond those required for delegation. >>>>=20 >>>> [optional: see draft-sullivan-dnsop-refer-down-00 or whatever. = We'll >>>> only include this reference if the other draft reaches WG consensus >>>> before terminology-bis] >>>>=20 >>>> ---cut here--->%--- >>>>=20 >>>> Comments, please. Also, Joe and I solicit comments on the = referrals >>>> draft proper, but it would be nice to put that in a different = thread. >>>>=20 >>>> Best regards, >>>>=20 >>>> A >>>>=20 >>>=20 >>=20 >> --=20 >> Andrew Sullivan >> ajs@anvilwalrusden.com >>=20 >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Nov 28 17:53:08 2017 Return-Path: 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 2490B127076 for ; Tue, 28 Nov 2017 17:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Xjmu7cb+; dkim=pass (1024-bit key) header.d=yitter.info header.b=DYdgSE1o 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 mNhajJgYtbdj for ; Tue, 28 Nov 2017 17:53:06 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8EA126E7A for ; Tue, 28 Nov 2017 17:53:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 67FECC06D0 for ; Wed, 29 Nov 2017 01:53:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511920385; bh=PcXJjAy1H91tLZ48a7BuZ1YnaxnxkBdqPu79JoR6mLE=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Xjmu7cb+Ec+zLPYnISkYmKaAz2sm7PbhUZqJVGQs3MjaTzFSXnPjIFY/l+3FbG0KQ p+Edlcx+OFPw3MBDI9czrXSGd+xWtSNY6IXZwcSUDiuL+PZ4o+Sb5c5ds56mFeAXNs VUvCSot2AeilMyZY9KWOBnf4goUL6w2JmQk/gaWc= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CNowsjIwmey for ; Wed, 29 Nov 2017 01:53:04 +0000 (UTC) Date: Tue, 28 Nov 2017 20:53:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511920384; bh=PcXJjAy1H91tLZ48a7BuZ1YnaxnxkBdqPu79JoR6mLE=; h=Date:From:To:Subject:References:In-Reply-To:From; b=DYdgSE1oVy3yzya5QaSN/fgSR0D0xldDprUxXTFrQ6MfmYDTdyLSiPTn1P5m62nq4 WeQQPpBsq0c7rTPyNbncyzcPwfH4fpfYnsvrXddqUdjMJqajZ8m/rTY3C/fJOAEW8f impnWrWpdokanKRW0W6vphkq+INa3DcmohLdmDQE= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 01:53:07 -0000 On Wed, Nov 29, 2017 at 12:46:07PM +1100, Mark Andrews wrote: > GO READ STD13! I thought I had, and I thought indeed that I was quoting it to you (or at least making references). I _suspect_ that you're referring to 4.1.1 in 1035 which describes AA. But that says that it "that the responding name server is an authority for the domain name in question section." This does not seem to me to line up clearly with the cases called a "referral" in 1034. I'm not trying to be religious about this or claim that I have the right answer. I'm just trying to write down the historical lore, so that future people don't have to be this bored again. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Nov 28 17:55:04 2017 Return-Path: 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 9D48F127419 for ; Tue, 28 Nov 2017 17:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=QpuyttjX; dkim=pass (1024-bit key) header.d=yitter.info header.b=RarmGqIR 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 InJqZ9KwyFNd for ; Tue, 28 Nov 2017 17:54:59 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDC5126E7A for ; Tue, 28 Nov 2017 17:54:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 445BFC06D0 for ; Wed, 29 Nov 2017 01:54:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511920469; bh=CanJJTcQqacaCVRY6/YVB8UfOJUi40Tn7E5nSErEONQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=QpuyttjXB8b+dBqZdf0UY1xsV8eMG5KtreclUtVNMTfNFNwwSDxcVH2522uL6L0TK 1Yw89VaBW87bdeRFS84umd+XNsqD81mTZ/7JI0kaR3spkwWsOj4XlMCDA48TSxllfW 0yu6cf0gudqC2QY9Z2q+m8Mg89XXVFKL/f4r4phE= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_Wd7HMduz8x for ; Wed, 29 Nov 2017 01:54:27 +0000 (UTC) Date: Tue, 28 Nov 2017 20:54:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511920467; bh=CanJJTcQqacaCVRY6/YVB8UfOJUi40Tn7E5nSErEONQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RarmGqIRtMY47U5a9ogcVyztAJda0Uqj2HIlV1CqGnfMqcnjs/R3ZP9rCVbDgBMml YIGrEGdppyTfbGBJRr+8FMnIeMBy3KfQ36xxUHu+HQawfw701ZJ1GuAIk4xlvLYDMD JzwsVldsBAAzzHr9d4bJuAkkdpQaIgx5zGbT2mJ4= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171129015427.ugawieq6pgysbj62@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <7EA7E605-5375-4D13-B525-6F097512E5E9@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7EA7E605-5375-4D13-B525-6F097512E5E9@isc.org> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 01:55:02 -0000 Yes, what I just sent. So how does one end up in 3.b with the AA bit and still have a "referral" according to 1034, section 4.3.2? A On Wed, Nov 29, 2017 at 12:49:48PM +1100, Mark Andrews wrote: > AA Authoritative Answer - this bit is valid in responses, > and specifies that the responding name server is an > authority for the domain name in question section. > > Note that the contents of the answer section may have > multiple owner names because of aliases. The AA bit > corresponds to the name which matches the query name, or > the first owner name in the answer section. > > > On 29 Nov 2017, at 12:46 pm, Mark Andrews wrote: > > > > GO READ STD13! > > > >> On 29 Nov 2017, at 12:44 pm, Andrew Sullivan wrote: > >> > >> Hi, > >> > >> On Wed, Nov 29, 2017 at 07:39:42AM +1100, Mark Andrews wrote: > >>> The AA bit may or may not be set depending upon whether the response contains > >>> a CNAME/DNAME or not. > >>> > >> > >> I replied with an enthusiastic "thanks" because this struck me as > >> obviously correct, but then I though I'd better look at the algorithm > >> again. And now I have a problem. > >> > >> 3.a is the CNAME case, but it's not a referral in the 1035 sense. > >> > >> 3.b takes us out of the authoritative data, so AA should not be set. > >> > >> Now, in RFC 6672 the DNAME processing happens at step 3.C, which > >> undertakes the DNAME processing. The resulting answer goes into the > >> answer section and processing continues. > >> > >> None of these steps seems to provide the case where a referral happens > >> but the AA bit is set. So, while I feel like I agree that in some > >> cases the AA bit should be set and not clear in case the response > >> contains a CNAME or DNAME, I'm trying to figure out whether such > >> responses are really referrals or else just intermediate steps. RFC > >> 6672 doesn't call them referrals. Maybe this is a bit of informal > >> jargon that needs clarifying? > >> > >> Thanks for the contribution, and best regards, > >> > >> A > >> > >>>> On 29 Nov 2017, at 6:50 am, Andrew Sullivan wrote: > >>>> > >>>> Dear colleagues, > >>>> > >>>> Joe Abley and I have just submitted a draft > >>>> (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/) > >>>> that is intended to capture the discussion here about referrals and > >>>> how to describe them. It is intended for BCP, and it discourages > >>>> upward referrals by authoritative servers. > >>>> > >>>> That leaves the task of the referrals definition. I have some new > >>>> text below: > >>>> > >>>> ---%<---cut here--- > >>>> > >>>> Referral: A type of response in which a server, signalling that it is > >>>> not authoritative for an answer, provides the querying resolver with > >>>> an alternative place to send its query. A referral contains an empty > >>>> answer section. It contains the NS RRset for the referred-to zone in > >>>> the authority section. It may contain RRs that provide addresses in > >>>> the additional section. The AA bit is clear. > >>>> > >>>> There are two types of referral response. The first is a downward > >>>> referral (sometimes described as "delegation response"), where the > >>>> server is authoritative for some portion of the QNAME. The Authority > >>>> section RRset's RDATA contains the name servers specified at the > >>>> referred-to zone cut. In normal DNS operation, this kind of response > >>>> is required in order to find names beneath a delegation. > >>>> > >>>> The second is an upward referral (sometimes described as "root > >>>> referral" or just "referral response", as distinct from the delegation > >>>> response above), where the server is not authoritative for any portion > >>>> of the QNAME. When this happens, the referred-to zone in the > >>>> Authority section is usually the root zone (.). In normal DNS > >>>> operation, this kind of response is not strictly speaking required to > >>>> work, and in practice some authoritative server operators will not > >>>> return referral responses beyond those required for delegation. > >>>> > >>>> [optional: see draft-sullivan-dnsop-refer-down-00 or whatever. We'll > >>>> only include this reference if the other draft reaches WG consensus > >>>> before terminology-bis] > >>>> > >>>> ---cut here--->%--- > >>>> > >>>> Comments, please. Also, Joe and I solicit comments on the referrals > >>>> draft proper, but it would be nice to put that in a different thread. > >>>> > >>>> Best regards, > >>>> > >>>> A > >>>> > >>> > >> > > > -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Nov 28 17:57:36 2017 Return-Path: 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 DB820126E7A for ; Tue, 28 Nov 2017 17:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 DvJRGFDXaB9u for ; Tue, 28 Nov 2017 17:57:34 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 54BB4128BB7 for ; Tue, 28 Nov 2017 17:57:34 -0800 (PST) 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 C7FB53B5F69; Wed, 29 Nov 2017 01:57:29 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 92ABE160047; Wed, 29 Nov 2017 01:57:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6FECF160051; Wed, 29 Nov 2017 01:57:29 +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 exH5ZnGS1eyl; Wed, 29 Nov 2017 01:57:29 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id C856D160047; Wed, 29 Nov 2017 01:57:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> Date: Wed, 29 Nov 2017 12:57:26 +1100 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 01:57:36 -0000 You can answer only responses, you can have referral only responses, you can partial answer + referral responses. > On 29 Nov 2017, at 12:53 pm, Andrew Sullivan = wrote: >=20 > On Wed, Nov 29, 2017 at 12:46:07PM +1100, Mark Andrews wrote: >> GO READ STD13! >=20 > I thought I had, and I thought indeed that I was quoting it to you (or > at least making references). >=20 > I _suspect_ that you're referring to 4.1.1 in 1035 which describes AA. > But that says that it "that the responding name server is an authority > for the domain name in question section." This does not seem to me to > line up clearly with the cases called a "referral" in 1034. >=20 > I'm not trying to be religious about this or claim that I have the > right answer. I'm just trying to write down the historical lore, so > that future people don't have to be this bored again. >=20 > Thanks, >=20 > A >=20 >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Nov 28 18:03:54 2017 Return-Path: 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 42B03128CFF for ; Tue, 28 Nov 2017 18:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=e6I8Mlw8; dkim=pass (1024-bit key) header.d=yitter.info header.b=daa5grN2 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 K9uayevIIIby for ; Tue, 28 Nov 2017 18:03:50 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 125E2126E7A for ; Tue, 28 Nov 2017 18:03:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 59AD8C06D0 for ; Wed, 29 Nov 2017 02:03:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511921029; bh=A/vAHL4wnogd25Zk8mctTKRnab0pGD62vaxREz/w994=; h=Date:From:To:Subject:References:In-Reply-To:From; b=e6I8Mlw8bKhjLXR7XMTAek9BVobZxYIRXzBBGnluMTn4I0T0VC4EBt2WPwByGI6dP I2aYxSptPaBVt5+dttZ+PLoE6yZiFBhu9st783hKGHyg+F2hSrDfq8aCvScwNC32hP R7WY6pn7Y+Hkqn5k342w/tyY6eNb0amymB4HagMM= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1HCmsF5TISG for ; Wed, 29 Nov 2017 02:03:48 +0000 (UTC) Date: Tue, 28 Nov 2017 21:03:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511921028; bh=A/vAHL4wnogd25Zk8mctTKRnab0pGD62vaxREz/w994=; h=Date:From:To:Subject:References:In-Reply-To:From; b=daa5grN2stR1cPriuPlv9pxucCdTkmV9AH1pKW4pzJsy30iI++hFAlGi6Wb2S2CpX RypXa3jGjdPNE+RTaBu9RpW1kf7wGnEVTNmPMy7KJbwuIoAYHCP0ZRjq4Nnz3x8W9S mGMMBTd0T7zuZ70hn7Fr6TnVdRZ1UB0xGapTDmHY= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 02:03:51 -0000 Hi Mark, On Wed, Nov 29, 2017 at 12:57:26PM +1100, Mark Andrews wrote: > You can answer only responses, you can have referral only responses, > you can partial answer + referral responses. Where in the algorithm in section 4.3.2 of 1034 (or other, derived cases like DNAME) is this "partial answer + referral responses" described? If this is well-defined somewhere, I want to refer to it. If it is not, I wish to describe it clearly, because it seems pretty obvious given the amount of discussion we've had on this topic that the notion of referral is nowhere near as clear as people seem to think it is. I'm not sure I understand your cryptic remark above, but I am certain I can't make it more comprehensible to others without you telling me that I'm wrong and need to do it over. So I'm appealing to you to try to make your view as clear as possible. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Nov 28 18:05:02 2017 Return-Path: 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 2E3801293E0 for ; Tue, 28 Nov 2017 18:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 OVGe4iHiFJgi for ; Tue, 28 Nov 2017 18:04:59 -0800 (PST) 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 D460D1293DF for ; Tue, 28 Nov 2017 18:04:59 -0800 (PST) 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 241EC3B5FBA; Wed, 29 Nov 2017 02:04:23 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 03C03160047; Wed, 29 Nov 2017 02:04:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E771E160051; Wed, 29 Nov 2017 02:04:22 +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 62CqZa46LEBY; Wed, 29 Nov 2017 02:04:22 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 090C1160047; Wed, 29 Nov 2017 02:04:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: Date: Wed, 29 Nov 2017 13:04:19 +1100 Cc: IETF DNSOP WG Content-Transfer-Encoding: quoted-printable Message-Id: <32ACBBB9-A6E6-4009-9AB3-5626222AFEA0@isc.org> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 02:05:01 -0000 And you can have partial answer and with no referral data responses which are confusable with NOERROR NODATA. We really should do EDNS(1) and add NXRRSET to the list of rcodes for QUERY.=20 > On 29 Nov 2017, at 12:57 pm, Mark Andrews wrote: >=20 > You can answer only responses, you can have referral only responses, > you can partial answer + referral responses. >=20 >> On 29 Nov 2017, at 12:53 pm, Andrew Sullivan = wrote: >>=20 >> On Wed, Nov 29, 2017 at 12:46:07PM +1100, Mark Andrews wrote: >>> GO READ STD13! >>=20 >> I thought I had, and I thought indeed that I was quoting it to you = (or >> at least making references). >>=20 >> I _suspect_ that you're referring to 4.1.1 in 1035 which describes = AA. >> But that says that it "that the responding name server is an = authority >> for the domain name in question section." This does not seem to me = to >> line up clearly with the cases called a "referral" in 1034. >>=20 >> I'm not trying to be religious about this or claim that I have the >> right answer. I'm just trying to write down the historical lore, so >> that future people don't have to be this bored again. >>=20 >> Thanks, >>=20 >> A >>=20 >>=20 >> --=20 >> Andrew Sullivan >> ajs@anvilwalrusden.com >>=20 >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Nov 28 18:14:23 2017 Return-Path: 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 207E9126E7A for ; Tue, 28 Nov 2017 18:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 keEMfjeEWV10 for ; Tue, 28 Nov 2017 18:14:20 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 2FB7F12783A for ; Tue, 28 Nov 2017 18:14:19 -0800 (PST) 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 17FBF3B5FFB; Wed, 29 Nov 2017 02:14:17 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DE6CB160047; Wed, 29 Nov 2017 02:14:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CF981160051; Wed, 29 Nov 2017 02:14:16 +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 mLNYGEUSqOVI; Wed, 29 Nov 2017 02:14:16 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 3A0E3160047; Wed, 29 Nov 2017 02:14:16 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> Date: Wed, 29 Nov 2017 13:14:13 +1100 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 02:14:22 -0000 When the CNAME refers to a name that is out of zone and the target zone = is below a zone that the server serves you will have CNAME (DNAME) + referral. =20 4.3.2 loops. pass 1 -> 3a (adds CNAME, AA is set as it matches the question = section, QNAME is updated). pass 2 -> 3b (we have a partial match with a bottom of zone cut = which adds the referral). > On 29 Nov 2017, at 1:03 pm, Andrew Sullivan = wrote: >=20 > Hi Mark, >=20 > On Wed, Nov 29, 2017 at 12:57:26PM +1100, Mark Andrews wrote: >> You can answer only responses, you can have referral only responses, >> you can partial answer + referral responses. >=20 > Where in the algorithm in section 4.3.2 of 1034 (or other, derived > cases like DNAME) is this "partial answer + referral responses" > described? If this is well-defined somewhere, I want to refer to it. > If it is not, I wish to describe it clearly, because it seems pretty > obvious given the amount of discussion we've had on this topic that > the notion of referral is nowhere near as clear as people seem to > think it is. I'm not sure I understand your cryptic remark above, but > I am certain I can't make it more comprehensible to others without > you telling me that I'm wrong and need to do it over. So I'm > appealing to you to try to make your view as clear as possible. >=20 > Best regards, >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Nov 28 18:39:01 2017 Return-Path: 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 31F321287A5 for ; Tue, 28 Nov 2017 18:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 jZM0nH38bj7t for ; Tue, 28 Nov 2017 18:38:58 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 1758712783A for ; Tue, 28 Nov 2017 18:38:57 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id BE9923B60BA; Wed, 29 Nov 2017 02:37:20 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id A90CE216C1C; Wed, 29 Nov 2017 02:37:20 +0000 (UTC) Date: Wed, 29 Nov 2017 02:37:20 +0000 From: Evan Hunt To: Andrew Sullivan Cc: dnsop@ietf.org Message-ID: <20171129023720.GA99800@isc.org> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <5A1DEEE1.3070809@redbarn.org> <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 02:39:00 -0000 > "Not strictly speaking required to work" was intended to observe that, > if you didn't get a referral under this condition, nothing ought to > break (or, if it did, it was already broken). I think the phrasing is unclear because "this response is not required to work" is ambiguous. The response *itself* doesn't have to work? Or the resolver can get along without this response? I took it to mean the latter, but I see how it could be confusing. I'd suggest something like "this response is not strictly speaking necessary, as it provides no information the resolver didn't already have; resolution can succeed without it." -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Tue Nov 28 19:08:08 2017 Return-Path: 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 B6C0912706D for ; Tue, 28 Nov 2017 19:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WWMHDf2ccqTa for ; Tue, 28 Nov 2017 19:08:05 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B7E1200C1 for ; Tue, 28 Nov 2017 19:08:05 -0800 (PST) Received: from [192.168.43.106] (unknown [223.104.3.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id F303C61FA2 for ; Wed, 29 Nov 2017 03:08:04 +0000 (UTC) Message-ID: <5A1E2491.9070805@redbarn.org> Date: Tue, 28 Nov 2017 19:08:01 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: dnsop@ietf.org References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <5A1DEEE1.3070809@redbarn.org> <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> In-Reply-To: <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 03:08:07 -0000 Andrew Sullivan wrote: > On Tue, Nov 28, 2017 at 03:18:57PM -0800, Paul Vixie wrote: > >> what would "to work" mean in the above text? > > "Not strictly speaking required to work" was intended to observe that, > if you didn't get a referral under this condition, nothing ought to > break (or, if it did, it was already broken). that's fatally unclear. > ... The point is in contrast to the downward referrals case, which > _must_ work or delegation doesn't. I'm nervous about someone running > off saying, "IETF says referrals don't work," which is clearly not > the point. then the thing to say would be "a referral should always be downward, and if a non-downward referral is received, it should be treated as a network data configuration error". >> that an upward referral could "work" in the above-reference sense >> seems to imply that the authority server you've queried, knows more >> about where the zone really is, than you could learn by walking >> down from the root. that's a walking talking nonsequitur. could you >> tell me what you really mean by "to work" since it can't possibly >> be that? > > Indeed, it is not that. Suggestions on how to make this clearer are > welcome. Evan Hunt wrote: > I'd suggest something like "this response is not strictly speaking > necessary, as it provides no information the resolver didn't already > have; resolution can succeed without it." i don't think we can walk this path without touching the "should" fire. -- P Vixie From nobody Wed Nov 29 03:16:34 2017 Return-Path: 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 44193124319 for ; Wed, 29 Nov 2017 03:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 3mWEw7TiSsvP for ; Wed, 29 Nov 2017 03:16:32 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 07A691205F1 for ; Wed, 29 Nov 2017 03:16:31 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:49956) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eK0Ls-000XwR-2G (Exim 4.89) (return-path ); Wed, 29 Nov 2017 11:16:28 +0000 Date: Wed, 29 Nov 2017 11:16:28 +0000 From: Tony Finch To: Andrew Sullivan cc: dnsop@ietf.org In-Reply-To: <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> Message-ID: References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 11:16:34 -0000 Andrew Sullivan wrote: > > Joe Abley and I have just submitted a draft > (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/) > that is intended to capture the discussion here about referrals and > how to describe them. It is intended for BCP, and it discourages > upward referrals by authoritative servers. > > That leaves the task of the referrals definition. I have some new > text below: Regarding the definition of referrals from older RFCs, see my terminology review from May 2015: https://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html As far as I can tell, RFC 1034 uses the term "referral" for downward referrals. For instance, section 4.2.1: To fix this problem, a zone contains "glue" RRs which are not part of the authoritative data, and are address RRs for the servers. These RRs are only necessary if the name server's name is "below" the cut, and are only used as part of a referral response. Section 4.3.1: A referral to name servers which have zones which are closer ancestors to the name than the server sending the reply. I think that quote implies that other less formal uses of "closer" specifically mean downward in the DNS tree. The downward meaning is most clear in the algorithm in section 4.3.2. Step 3 deals with authoritative data, and says: b. If a match would take us out of the authoritative data, we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone. Step 4 is where upward referrals come from (when the cache only contains root hints and no authoritative zone matches the qname), but it does NOT use the term "referral": 4. Start matching down in the cache. If QNAME is found in the cache, copy all RRs attached to it that match QTYPE into the answer section. If there was no delegation from authoritative data, look for the best one from the cache, and put it in the authority section. Go to step 6. So I think unqualified "referral" means "downward referral" (from authoritative data); it's OK to use the term "upward referral" to mean a response from the cache that looks like a referral but doesn't help to answer the query. I have also seen the term "implicit referral" meaning the authority section from a recursive response, since the idea was that a downstream cache might use those records to answer future queries more efficiently (though doing that is no longer considered safe). Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fisher: Northerly 3 or 4, increasing 5 or 6, then becoming cyclonic later. Moderate, occasionally rough in west. Showers, wintry later. Good, occasionally poor later. From nobody Wed Nov 29 04:11:37 2017 Return-Path: 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 15DE81270AE for ; Wed, 29 Nov 2017 04:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=ARnUYRay; dkim=pass (1024-bit key) header.d=yitter.info header.b=TMG14E09 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 06ORGShh-gCj for ; Wed, 29 Nov 2017 04:11:33 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6301B1200F3 for ; Wed, 29 Nov 2017 04:11:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 45F35BD337 for ; Wed, 29 Nov 2017 12:11:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511957492; bh=/BBncJHVBQZWWFPkPWv+Uc+VWo6VoOHOciptz5qESqI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ARnUYRayK0VGk+Ue6WpsSHJgcVUVaPlT4yBUYSKY6B4Z4TCrrkjSfds8XBzAPwBlW VAYpU9WnJTggEOhcvDwX77nUktSrmfdRnyOi3G5gjnbT4rOjLDQg/wJq9fZlpy+eLY BLR6TWLBRjVIvXXsLwwA6mvJsdtXnmaXLexijfj4= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TZTRKFalHar for ; Wed, 29 Nov 2017 12:11:30 +0000 (UTC) Date: Wed, 29 Nov 2017 07:11:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511957490; bh=/BBncJHVBQZWWFPkPWv+Uc+VWo6VoOHOciptz5qESqI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=TMG14E09Pf9aVVYwX3guPWp2JFxzNG4TOIlIJQYww60DgLC5HlXH0pY1Ya72hhJ36 CUVjFZZjyQ0bwo6azk1ShwmdaXS4/5rtvF8NUZ1Z9odbj6/dOzxznaUkEqnknUQ3gm 88UuPURiW045kdwTpE3sZKUORFmc8hAsFV32f3Hg= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171129121129.sci5zrknavayotog@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 12:11:36 -0000 Hi, On Wed, Nov 29, 2017 at 11:16:28AM +0000, Tony Finch wrote: > > Regarding the definition of referrals from older RFCs, see my > terminology review from May 2015: > https://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html Yes, it's your review that has caused this issue :) > I think that quote implies that other less formal uses of "closer" > specifically mean downward in the DNS tree. That's plausible. > So I think unqualified "referral" means "downward referral" (from > authoritative data) I'm not totally convinced, but I can certainly see the argument. If we added to the text I proposed something like, "Many people use the unqualified term 'referral' to mean only a downward referral," would that help? > answer the query. I have also seen the term "implicit referral" meaning > the authority section from a recursive response, since the idea was that a > downstream cache might use those records to answer future queries more > efficiently (though doing that is no longer considered safe). Hmm. It seems like we ought to add that point about implicit referral. I wonder how this is related to the "partial referral" Mark is talking about (see elsewhere in this thread). Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 29 04:17:46 2017 Return-Path: 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 690B4127201 for ; Wed, 29 Nov 2017 04:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=gTmZPyzv; dkim=pass (1024-bit key) header.d=yitter.info header.b=lmH6n9b5 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 xs8NwQN4eOWj for ; Wed, 29 Nov 2017 04:17:43 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6B6120725 for ; Wed, 29 Nov 2017 04:17:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 8F759BD337 for ; Wed, 29 Nov 2017 12:17:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511957832; bh=dW8rY7xwPFOMtF0xzngKdOvINWY6fxs9KWC6t6TREwM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=gTmZPyzvad1GCTl51/RlADQIgdi4TVU69ashy2eVZi3HzXCwZnwgL/D3748bvw78Y qajRplcxVVH76RX9a7VgMa1qTf/r8FW0BKLuh/khDk057Zm1rteUn1udwm9lCST8I5 3uZdjw/FhDc1FC+/m7xNjjZckGyDunxm5cLJgHbo= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvRGvTt3UMjq for ; Wed, 29 Nov 2017 12:17:06 +0000 (UTC) Date: Wed, 29 Nov 2017 07:17:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511957826; bh=dW8rY7xwPFOMtF0xzngKdOvINWY6fxs9KWC6t6TREwM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=lmH6n9b5cZbpcKk/zZ4j/+JE/IvWVf0+s/812AnWeR3Obrn3h/wfJMXa761VgRy5B wGwIv1LuLGQeo0eDlN3s9XWmDPkZfNNCB5v+o5s2Gi2OBoFD1flfm2JBLPGzFagIpn qNvdqLUgZ2QCsPOjCvTzz1/n+cs+8jxVmLOcicwU= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 12:17:44 -0000 On Wed, Nov 29, 2017 at 01:14:13PM +1100, Mark Andrews wrote: > When the CNAME refers to a name that is out of zone and the target zone is below > a zone that the server serves you will have CNAME (DNAME) + referral. > > 4.3.2 loops. This part I got. > pass 1 -> 3a (adds CNAME, AA is set as it matches the question section, QNAME is updated). This is the CNAME response, yes, ok. > pass 2 -> 3b (we have a partial match with a bottom of zone cut which adds the referral). > Right, and the authoritative server can't proceed, but the referral is necessary. Good, this is helpful, thanks. This also means, of course, that in such a response the answer section isn't empty. Is this why you call it a "partial referral"? Best regards, A > > On 29 Nov 2017, at 1:03 pm, Andrew Sullivan wrote: > > > > Hi Mark, > > > > On Wed, Nov 29, 2017 at 12:57:26PM +1100, Mark Andrews wrote: > >> You can answer only responses, you can have referral only responses, > >> you can partial answer + referral responses. > > > > Where in the algorithm in section 4.3.2 of 1034 (or other, derived > > cases like DNAME) is this "partial answer + referral responses" > > described? If this is well-defined somewhere, I want to refer to it. > > If it is not, I wish to describe it clearly, because it seems pretty > > obvious given the amount of discussion we've had on this topic that > > the notion of referral is nowhere near as clear as people seem to > > think it is. I'm not sure I understand your cryptic remark above, but > > I am certain I can't make it more comprehensible to others without > > you telling me that I'm wrong and need to do it over. So I'm > > appealing to you to try to make your view as clear as possible. > > > > Best regards, > > > > A > > > -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 29 04:21:37 2017 Return-Path: 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 EE4991270AE for ; Wed, 29 Nov 2017 04:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=mwslBl7F; dkim=pass (1024-bit key) header.d=yitter.info header.b=KnRcSinG 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 0pAno6Jsad8j for ; Wed, 29 Nov 2017 04:21:34 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73C4120725 for ; Wed, 29 Nov 2017 04:21:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 579BDBD337 for ; Wed, 29 Nov 2017 12:21:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511958063; bh=TI7VLKFVEEhbQ0QgOlRzR80FlmQgLxFrE0qvzZp14gw=; h=Date:From:To:Subject:References:In-Reply-To:From; b=mwslBl7FJConHWdmTNVAOFqbYmRPwRdhm14j5LAioppiCaUGgTNJFaz8mL3lb7li6 fschTW8d0bNZOW3d38Ls0CyGL+b33F8vdl/Z4fC5oQDN6gHJDC4kCSQWipj8obWMTX EqGiacskQBSQi5qT0sI2mqr6sRShHv3OE1uD85TQ= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVO7bJlpNiOC for ; Wed, 29 Nov 2017 12:21:02 +0000 (UTC) Date: Wed, 29 Nov 2017 07:21:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511958062; bh=TI7VLKFVEEhbQ0QgOlRzR80FlmQgLxFrE0qvzZp14gw=; h=Date:From:To:Subject:References:In-Reply-To:From; b=KnRcSinGV5CPwAixpy4yZnIrifMVPqdvgp4HXxOVJTx7nrOFA1mPBTq4hpmpbb7S8 BoCrmaGz8iDIvihP6yenXshAkAlfLxydhgA0nqNfS2AVGdvlDF06ccOgWYCRpgX/Ew fhH4xBFVHZVZvPcbaqufGqbsLlhj5IGNlbQXeIiU= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171129122101.mv7zlc6kdqe3ojnv@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <5A1DEEE1.3070809@redbarn.org> <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> <5A1E2491.9070805@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A1E2491.9070805@redbarn.org> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 12:21:35 -0000 On Tue, Nov 28, 2017 at 07:08:01PM -0800, Paul Vixie wrote: > that's fatally unclear. So I gather :) > then the thing to say would be "a referral should always be downward, and if > a non-downward referral is received, it should be treated as a network data > configuration error". No, that is attempting to define away other kinds of referrals, which is precisely the discussion we were previously having (and why Joe and I wrote that other draft). The terminology draft should not, in my opinion, attempt to change any RFC; and, IMO, 1034 defines referrals in such a way that someone _could_ think that upward referrals are sometimes a normal part of operation. If we want to change the advice of what to do there, I think a different document is needed. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 29 04:23:45 2017 Return-Path: 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 CFB7F1270AE for ; Wed, 29 Nov 2017 04:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 wAu62dAMsQHI for ; Wed, 29 Nov 2017 04:23:42 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB254120725 for ; Wed, 29 Nov 2017 04:23:41 -0800 (PST) Received: from [172.31.1.84] (unknown [222.128.198.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 7D54461FA2; Wed, 29 Nov 2017 12:23:40 +0000 (UTC) Date: Wed, 29 Nov 2017 12:23:36 +0000 User-Agent: K-9 Mail for Android In-Reply-To: <20171129122101.mv7zlc6kdqe3ojnv@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <5A1DEEE1.3070809@redbarn.org> <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> <5A1E2491.9070805@redbarn.org> <20171129122101.mv7zlc6kdqe3ojnv@mx4.yitter.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----UHV3ITPJ7WHA9WWOMA1LHOAVPGGHMF" Content-Transfer-Encoding: 7bit To: dnsop@ietf.org,Andrew Sullivan From: P Vix Message-ID: <13A36237-CA11-44F3-BA80-69302F7D14F9@redbarn.org> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 12:23:44 -0000 ------UHV3ITPJ7WHA9WWOMA1LHOAVPGGHMF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 1034 cannot be reasonably read that way=2E I am asking for a clarification = not a rule change=2E=20 On November 29, 2017 8:21:01 PM GMT+08:00, Andrew Sullivan wrote: >On Tue, Nov 28, 2017 at 07:08:01PM -0800, Paul Vixie wrote: >> that's fatally unclear=2E > >So I gather :) > >> then the thing to say would be "a referral should always be downward, >and if >> a non-downward referral is received, it should be treated as a >network data >> configuration error"=2E > >No, that is attempting to define away other kinds of referrals, which >is precisely the discussion we were previously having (and why Joe and >I wrote that other draft)=2E The terminology draft should not, in my >opinion, attempt to change any RFC; and, IMO, 1034 defines referrals >in such a way that someone _could_ think that upward referrals are >sometimes a normal part of operation=2E If we want to change the advice >of what to do there, I think a different document is needed=2E > >Best regards, > >A > >--=20 >Andrew Sullivan >ajs@anvilwalrusden=2Ecom > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dnsop --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------UHV3ITPJ7WHA9WWOMA1LHOAVPGGHMF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 1034 cannot be reasonably read that way=2E I am as= king for a clarification not a rule change=2E

On November 29, 2017 8:21:01 PM GMT+08:00, Andrew Sullivan <ajs@an= vilwalrusden=2Ecom> wrote:
On Tue, Nov 28, 2017 at 07:08:01PM -0800, Paul Vixie=
 wrote:
 that's fatal=
ly unclear=2E

So I gather :)

 then the thing to say would be "=
;a referral should always be downward, and if
 a non-downward referral=
 is received, it should be treated as a network data
 configuration er=
ror"=2E

No, that is attempting to define away = other kinds of referrals, which
is precisely the discussion we were pr= eviously having (and why Joe and
I wrote that other draft)=2E The ter= minology draft should not, in my
opinion, attempt to change any RFC; a= nd, IMO, 1034 defines referrals
in such a way that someone _could_ thi= nk that upward referrals are
sometimes a normal part of operation=2E = If we want to change the advice
of what to do there, I think a differe= nt document is needed=2E

Best regards,

A
<= /blockquote>

--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------UHV3ITPJ7WHA9WWOMA1LHOAVPGGHMF-- From nobody Wed Nov 29 04:25:07 2017 Return-Path: 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 2DAC412762F for ; Wed, 29 Nov 2017 04:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 vMuZWFo4losc for ; Wed, 29 Nov 2017 04:25:03 -0800 (PST) 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 0F0F51270AE for ; Wed, 29 Nov 2017 04:25:03 -0800 (PST) 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 BBA433ABF03; Wed, 29 Nov 2017 12:24:31 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 68C32160072; Wed, 29 Nov 2017 12:24:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5B49C160055; Wed, 29 Nov 2017 12:24:30 +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 ObyrDm53MZkY; Wed, 29 Nov 2017 12:24:30 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 9E651160053; Wed, 29 Nov 2017 12:24:29 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info> Date: Wed, 29 Nov 2017 23:24:27 +1100 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <414CA6BA-092D-48C0-859C-834A1B326145@isc.org> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org> <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 12:25:06 -0000 > On 29 Nov 2017, at 11:17 pm, Andrew Sullivan = wrote: >=20 > On Wed, Nov 29, 2017 at 01:14:13PM +1100, Mark Andrews wrote: >> When the CNAME refers to a name that is out of zone and the target = zone is below >> a zone that the server serves you will have CNAME (DNAME) + referral. >>=20 >> 4.3.2 loops. >=20 > This part I got. >=20 >> pass 1 -> 3a (adds CNAME, AA is set as it matches the question = section, QNAME is updated). >=20 > This is the CNAME response, yes, ok. >=20 >> pass 2 -> 3b (we have a partial match with a bottom of zone cut = which adds the referral). >>=20 >=20 > Right, and the authoritative server can't proceed, but the referral is > necessary. Good, this is helpful, thanks. This also means, of > course, that in such a response the answer section isn't empty. Is > this why you call it a "partial referral=E2=80=9D? =20 I said =E2=80=9Cpartial answer + referral=E2=80=9D, and yes. > Best regards, >=20 > A >=20 >>> On 29 Nov 2017, at 1:03 pm, Andrew Sullivan = wrote: >>>=20 >>> Hi Mark, >>>=20 >>> On Wed, Nov 29, 2017 at 12:57:26PM +1100, Mark Andrews wrote: >>>> You can answer only responses, you can have referral only = responses, >>>> you can partial answer + referral responses. >>>=20 >>> Where in the algorithm in section 4.3.2 of 1034 (or other, derived >>> cases like DNAME) is this "partial answer + referral responses" >>> described? If this is well-defined somewhere, I want to refer to = it. >>> If it is not, I wish to describe it clearly, because it seems pretty >>> obvious given the amount of discussion we've had on this topic that >>> the notion of referral is nowhere near as clear as people seem to >>> think it is. I'm not sure I understand your cryptic remark above, = but >>> I am certain I can't make it more comprehensible to others without >>> you telling me that I'm wrong and need to do it over. So I'm >>> appealing to you to try to make your view as clear as possible. >>>=20 >>> Best regards, >>>=20 >>> A >>>=20 >>=20 >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Nov 29 04:25:57 2017 Return-Path: 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 991471270AE for ; Wed, 29 Nov 2017 04:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=GHlxJo9u; dkim=pass (1024-bit key) header.d=yitter.info header.b=gCXBAWtZ 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 mESyz2LpRJeJ for ; Wed, 29 Nov 2017 04:25:55 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62900127005 for ; Wed, 29 Nov 2017 04:25:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id CE2F4BD337 for ; Wed, 29 Nov 2017 12:25:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511958354; bh=NX6C05QucjxJfz/6D0PtqG2mCq1r06GnS7x/5myMuws=; h=Date:From:To:Subject:References:In-Reply-To:From; b=GHlxJo9uKLd9sYgaD9R7Drl+6Nwt11Wfg1LJ5mVw4l2LNfZ0zrynQNXpfL7UooBGc Ji+E0KaLAFuhInb1q6Ux7RnQJCAWHNj3SoKwr0uvWg1MPhvdu146h1+SWmj+sapI0j nfaO9SUKqYsAsnuVIwL4bB7tY4jJ1yez5N7jJw58= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hflbClCwdqH for ; Wed, 29 Nov 2017 12:25:53 +0000 (UTC) Date: Wed, 29 Nov 2017 07:25:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511958353; bh=NX6C05QucjxJfz/6D0PtqG2mCq1r06GnS7x/5myMuws=; h=Date:From:To:Subject:References:In-Reply-To:From; b=gCXBAWtZ6cm1chZ0NL11+TLWfK/qYzcq1nSbdFk5cb+FLZQ2V0vtyTZ5cr7NT075m DKzoemh8+xEK6IWln+BNapFqRErbrZC5cH20jV7Ou/BCsmpsakj2sEelkpU5vlmIVG PXsV25N/RVfv98lqZPzyZnHazQ2j3VvKTtMjjRgo= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171129122553.oyx5ftqoifbnkw7h@anvilwalrusden.com> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <5A1DEEE1.3070809@redbarn.org> <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> <20171129023720.GA99800@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171129023720.GA99800@isc.org> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 12:25:56 -0000 On Wed, Nov 29, 2017 at 02:37:20AM +0000, Evan Hunt wrote: > > I think the phrasing is unclear because "this response is not required to > work" is ambiguous. The response *itself* doesn't have to work? Or the > resolver can get along without this response? I took it to mean the > latter, but I see how it could be confusing. Yep, got it. > I'd suggest something like "this response is not strictly speaking > necessary, as it provides no information the resolver didn't already > have; resolution can succeed without it." How about, "This kind of response is not required for resolution or for correctly answering any query, and in practice some authoritative server operators will not return referral responses beyond those required for delegation"? Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 29 04:28:16 2017 Return-Path: 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 CEB2E127005 for ; Wed, 29 Nov 2017 04:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=bksTDkdF; dkim=pass (1024-bit key) header.d=yitter.info header.b=aWtk7h8x 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 A8Wp1AMIVIxi for ; Wed, 29 Nov 2017 04:28:13 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80813120725 for ; Wed, 29 Nov 2017 04:28:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id EC299BD337 for ; Wed, 29 Nov 2017 12:28:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511958492; bh=IYaKSSnIPxzUlCVl+uUSt5Or8TI+wQeq3m0FTUfVSx8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=bksTDkdFhIAdkwRNIsrG+bFOXebi5I0k3e8ruDoPCwoh2T9C3XR7a1Nj4OrIU2a4y WZtPVsIKSn/9a5rFT1CKWCylL1Nat90JGvBTivtO+D3xO46aVAPsn4lAGji8mXcoy7 nD7gJyGIyk7f2LEDCK78UhlPkAW5rnDyCiFCnwNk= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SbeNmsUo9ZT for ; Wed, 29 Nov 2017 12:28:11 +0000 (UTC) Date: Wed, 29 Nov 2017 07:28:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511958491; bh=IYaKSSnIPxzUlCVl+uUSt5Or8TI+wQeq3m0FTUfVSx8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=aWtk7h8xBX12Q0Jurzzo30sMzz+diBHcFP/vXoPnm3jWNpXjMgidqIJSWY9CUURXd NImu+e3YnJvjANu5TToxRH1HHH4ouDSb9FfZb5aBDCJ3RiI79ObAFVpCuBWcMh9buH 03cu6P3mlj99T4Fj1wgFhCfNvWBSEkcGRnLneFZY= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171129122811.bydl23dadf53yzkd@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <5A1DEEE1.3070809@redbarn.org> <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> <5A1E2491.9070805@redbarn.org> <20171129122101.mv7zlc6kdqe3ojnv@mx4.yitter.info> <13A36237-CA11-44F3-BA80-69302F7D14F9@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13A36237-CA11-44F3-BA80-69302F7D14F9@redbarn.org> Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 12:28:15 -0000 On Wed, Nov 29, 2017 at 12:23:36PM +0000, P Vix wrote: > 1034 cannot be reasonably read that way. Sure it can. See the discussion in draft-sullivan-dnsop-refer-down and on the list not two weeks ago for how. I think it should _not_ be read that way, but an honest reader could read it that way, and the terminology document is not the place to rule on the way people should read a text. We're supposed to be doing description, not prescription. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 29 04:32:37 2017 Return-Path: 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 BD9E6126BF0 for ; Wed, 29 Nov 2017 04:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 yTa5DAjsAnpd for ; Wed, 29 Nov 2017 04:32:35 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 0089A120725 for ; Wed, 29 Nov 2017 04:32:34 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:51715) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eK1XU-000n77-0W (Exim 4.89) (return-path ); Wed, 29 Nov 2017 12:32:32 +0000 Date: Wed, 29 Nov 2017 12:32:32 +0000 From: Tony Finch To: Andrew Sullivan cc: dnsop@ietf.org In-Reply-To: <20171129121129.sci5zrknavayotog@mx4.yitter.info> Message-ID: References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129121129.sci5zrknavayotog@mx4.yitter.info> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 12:32:37 -0000 Andrew Sullivan wrote: > > I'm not totally convinced, but I can certainly see the argument. If > we added to the text I proposed something like, "Many people use the > unqualified term 'referral' to mean only a downward referral," would > that help? Well, I would say, s/many people/Paul Mockapetris/ :-) > > answer the query. I have also seen the term "implicit referral" meaning > > the authority section from a recursive response, since the idea was that a > > downstream cache might use those records to answer future queries more > > efficiently (though doing that is no longer considered safe). > > Hmm. It seems like we ought to add that point about implicit > referral. Oh, actually, (now I re-read my old definition properly) that term is used in RFC 2308 section 6. > I wonder how this is related to the "partial referral" Mark > is talking about (see elsewhere in this thread). They look similar but have different AA bits, if I understand correctly. An implicit referral comes from the cache whereas Mark's CNAME plus referral comes from authoritative data. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode North Utsire, South Utsire: Northerly or northeasterly 5 or 6, decreasing 4 at times. Moderate or rough. Wintry showers. Good occasionally poor. From nobody Wed Nov 29 05:55:43 2017 Return-Path: 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 E5E5D127369 for ; Wed, 29 Nov 2017 05:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 MSXpzZnU689G for ; Wed, 29 Nov 2017 05:55:40 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73CE0120724 for ; Wed, 29 Nov 2017 05:55:40 -0800 (PST) Received: from [100.71.116.250] (139.sub-174-214-8.myvzw.com [174.214.8.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C9A5661FA2; Wed, 29 Nov 2017 13:55:36 +0000 (UTC) Date: Wed, 29 Nov 2017 13:55:29 +0000 User-Agent: K-9 Mail for Android In-Reply-To: <20171129122811.bydl23dadf53yzkd@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <5A1DEEE1.3070809@redbarn.org> <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> <5A1E2491.9070805@redbarn.org> <20171129122101.mv7zlc6kdqe3ojnv@mx4.yitter.info> <13A36237-CA11-44F3-BA80-69302F7D14F9@redbarn.org> <20171129122811.bydl23dadf53yzkd@mx4.yitter.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----326GI9CM6K7CPKILN21PPENLKCGEI9" Content-Transfer-Encoding: 7bit To: dnsop@ietf.org,Andrew Sullivan From: P Vix Message-ID: Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 13:55:42 -0000 ------326GI9CM6K7CPKILN21PPENLKCGEI9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable No, sir=2E Closer means downward=2E Nobody believes otherwise=2E Not even y= ou, or Joe=2E The only person ever to get it wrong was me, and I have recan= ted=2E Please do not write anything that blurs or softens the clear languag= e of downwards-ness in 1034=2E If you can't keep the clear spirit and inten= t of the existing document then please write nothing at all=2E On November 29, 2017 8:28:11 PM GMT+08:00, Andrew Sullivan wrote: >On Wed, Nov 29, 2017 at 12:23:36PM +0000, P Vix wrote: >> 1034 cannot be reasonably read that way=2E > >Sure it can=2E See the discussion in draft-sullivan-dnsop-refer-down >and on the list not two weeks ago for how=2E I think it should _not_ be >read that way, but an honest reader could read it that way, and the >terminology document is not the place to rule on the way people should >read a text=2E We're supposed to be doing description, not prescription= =2E > >Best regards, > >A > > >--=20 >Andrew Sullivan >ajs@anvilwalrusden=2Ecom > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dnsop --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------326GI9CM6K7CPKILN21PPENLKCGEI9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable No, sir=2E Closer means downward=2E Nobody believe= s otherwise=2E Not even you, or Joe=2E The only person ever to get it wrong= was me, and I have recanted=2E Please do not write anything that blurs or = softens the clear language of downwards-ness in 1034=2E If you can't ke= ep the clear spirit and intent of the existing document then please write n= othing at all=2E

On November 29, 2017 8:2= 8:11 PM GMT+08:00, Andrew Sullivan <ajs@anvilwalrusden=2Ecom> wrote:<= blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; bord= er-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 
On Wed, Nov 29, 2017 at 12:23:36PM +0000, P Vix wrot=
e:
 1034 cannot be re=
asonably read that way=2E

Sure it can=2E  See the d=
iscussion in draft-sullivan-dnsop-refer-down
and on the list not two w=
eeks ago for how=2E  I think it should _not_ be
read that way, but an =
honest reader could read it that way, and the
terminology document is =
not the place to rule on the way people should
read a text=2E  We're s=
upposed to be doing description, not prescription=2E

Best regard=
s,

A


--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------326GI9CM6K7CPKILN21PPENLKCGEI9-- From nobody Wed Nov 29 05:56:06 2017 Return-Path: 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 DE6E11275C5 for ; Wed, 29 Nov 2017 05:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NEUTRAL=0.779] autolearn=no 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 Hwh-3z5pHehR for ; Wed, 29 Nov 2017 05:56:04 -0800 (PST) Received: from smtp77.ord1c.emailsrvr.com (smtp77.ord1c.emailsrvr.com [108.166.43.77]) (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 22D381250B8 for ; Wed, 29 Nov 2017 05:56:04 -0800 (PST) Received: from smtp26.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 74FFFE03D9; Wed, 29 Nov 2017 08:55:59 -0500 (EST) X-Auth-ID: matt@kahlerlarson.org Received: by smtp26.relay.ord1c.emailsrvr.com (Authenticated sender: matt-AT-kahlerlarson.org) with ESMTPSA id 42D8BE01E4; Wed, 29 Nov 2017 08:55:59 -0500 (EST) X-Sender-Id: matt@kahlerlarson.org Received: from [192.168.1.48] (pool-96-255-43-12.washdc.fios.verizon.net [96.255.43.12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:465 (trex/5.7.12); Wed, 29 Nov 2017 08:55:59 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Matt Larson In-Reply-To: Date: Wed, 29 Nov 2017 08:55:54 -0500 Cc: dnsop X-Mao-Original-Outgoing-Id: 533656554.046817-f33c89e67f2b8550e067b6776a719be5 Content-Transfer-Encoding: 7bit Message-Id: <1DA60CC3-2A05-4A9B-AD2C-484B1CB66F5A@kahlerlarson.org> References: To: tjw ietf X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 13:56:05 -0000 > On Nov 16, 2017, at 3:23 AM, tjw ietf wrote: > > This starts a Call for Adoption for draft-huston-kskroll-sentinel I support the document and will review and provide comments. Matt From nobody Wed Nov 29 06:08:14 2017 Return-Path: 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 0DAFF120724 for ; Wed, 29 Nov 2017 06:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=j7dwpFs4; dkim=pass (1024-bit key) header.d=yitter.info header.b=CHpNDvrd 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 1Koq1OK2s6hQ for ; Wed, 29 Nov 2017 06:08:12 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B52127369 for ; Wed, 29 Nov 2017 06:08:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 43E84BD337 for ; Wed, 29 Nov 2017 14:08:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511964491; bh=Dlefu1v8gSHmJvR910CFnAl8VH3gdSPOk3/QrSbeEAc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=j7dwpFs4gTbRH6FN9Pcy0alnC+PNNlrx2744bRJ0fW1bpY1FCZCgUI2o6woJ50DKH ixE6hKjma9ioxZ0+URNwVVzeI1MUd3vsqJayAQ52rp246PSiwgvlNHJxjkBymfOieR K3ABdZQ7tHMv4HnrUhZDm/QC7dCT0HxC8IvOUldY= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLbU31mY04Ky for ; Wed, 29 Nov 2017 14:08:05 +0000 (UTC) Date: Wed, 29 Nov 2017 09:08:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511964485; bh=Dlefu1v8gSHmJvR910CFnAl8VH3gdSPOk3/QrSbeEAc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=CHpNDvrdpxiWRBFtPWgiS+c1U3z45415Bk9q1I5HtE/Bg1UKBfFzd2gJadx5/EwAZ 4wF9FCIuIpuCeTKngECmWkOJ/ZtHY/Yd1oOfZjaUl6X3gH9aBz2xlEJ/t+3vExHpou NR8qqN9/BE4rTarL39QxcQXe79TqbDQsmXtyo5uQ= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171129140806.fz2zzcltbd7bgjbz@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <5A1DEEE1.3070809@redbarn.org> <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> <5A1E2491.9070805@redbarn.org> <20171129122101.mv7zlc6kdqe3ojnv@mx4.yitter.info> <13A36237-CA11-44F3-BA80-69302F7D14F9@redbarn.org> <20171129122811.bydl23dadf53yzkd@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 14:08:13 -0000 On Wed, Nov 29, 2017 at 01:55:29PM +0000, P Vix wrote: > Please do not write anything that blurs or softens the clear language of downwards-ness in 1034. If you can't keep the clear spirit and intent of the existing document then please write nothing at all. > I don't believe 1034 is anywhere near as clear as you are insisting it is; and the empirical evidence of that lack of clarity is the very thing you feel the need to recant. If the WG believes otherwise, then I think it is free to write the definition as it wishes, but only if it removes me as an editor of the terminology document. I do wish to make the definition clear, and I have no complaint where the definition might note that not every operator agrees about providing upward referrals (the text proffered already says that, I think). But I shall not include a change to the definition of referrals such that upward referrals are defined away. They exist, today, all over the Internet, and it would be extremely foolish lexicography to attempt to hide that. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 29 07:06:13 2017 Return-Path: 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 799901275C5 for ; Wed, 29 Nov 2017 07:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 OnsyT4xLhLCd for ; Wed, 29 Nov 2017 07:06:10 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 00C2D127775 for ; Wed, 29 Nov 2017 07:06:04 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:55404) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eK3w2-000Gqk-1g (Exim 4.89) (return-path ); Wed, 29 Nov 2017 15:06:02 +0000 Date: Wed, 29 Nov 2017 15:06:02 +0000 From: Tony Finch To: Andrew Sullivan cc: dnsop@ietf.org In-Reply-To: <20171129140806.fz2zzcltbd7bgjbz@mx4.yitter.info> Message-ID: References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <5A1DEEE1.3070809@redbarn.org> <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> <5A1E2491.9070805@redbarn.org> <20171129122101.mv7zlc6kdqe3ojnv@mx4.yitter.info> <13A36237-CA11-44F3-BA80-69302F7D14F9@redbarn.org> <20171129122811.bydl23dadf53yzkd@mx4.yitter.info> <20171129140806.fz2zzcltbd7bgjbz@mx4.yitter.info> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 15:06:12 -0000 Andrew Sullivan wrote: > But I shall not include a change to the definition of referrals such > that upward referrals are defined away. They exist, today, all over the > Internet, and it would be extremely foolish lexicography to attempt to > hide that. Upward referrals exist, but bare "referral" is short for "downward referral". Other things that look like referrals (such as upward referrals or implicit referrals) have to have a qualifier. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Shannon, Rockall, Malin, Hebrides: North 5 to 7. Moderate or rough. Showers, but fair for a time later. Good, occasionally moderate. From nobody Wed Nov 29 07:18:21 2017 Return-Path: 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 8F9C312762F for ; Wed, 29 Nov 2017 07:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 c-DO0jeF7amI for ; Wed, 29 Nov 2017 07:18:19 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 322E0127843 for ; Wed, 29 Nov 2017 07:18:17 -0800 (PST) Received: from [10.20.30.101] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vATFGR4N052180 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Nov 2017 08:16:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.20.30.101] From: "Paul Hoffman" To: "Tony Finch" Cc: "Andrew Sullivan" , dnsop@ietf.org Date: Wed, 29 Nov 2017 07:17:59 -0800 Message-ID: In-Reply-To: References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <5A1DEEE1.3070809@redbarn.org> <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> <5A1E2491.9070805@redbarn.org> <20171129122101.mv7zlc6kdqe3ojnv@mx4.yitter.info> <13A36237-CA11-44F3-BA80-69302F7D14F9@redbarn.org> <20171129122811.bydl23dadf53yzkd@mx4.yitter.info> <20171129140806.fz2zzcltbd7bgjbz@mx4.yitter.info> MIME-Version: 1.0 X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 15:18:20 -0000 On 29 Nov 2017, at 7:06, Tony Finch wrote: > Andrew Sullivan wrote: > >> But I shall not include a change to the definition of referrals such >> that upward referrals are defined away. They exist, today, all over the >> Internet, and it would be extremely foolish lexicography to attempt to >> hide that. > > Upward referrals exist, but bare "referral" is short for "downward > referral". Other things that look like referrals (such as upward > referrals or implicit referrals) have to have a qualifier. Yes, please. This is good formulation for our definitional problems. --Paul Hoffman From nobody Wed Nov 29 11:31:08 2017 Return-Path: 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 5F4C6126C22 for ; Wed, 29 Nov 2017 11:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 6DX4LaZ4Fe00 for ; Wed, 29 Nov 2017 11:31:03 -0800 (PST) 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 A8D3D12896F for ; Wed, 29 Nov 2017 11:31:03 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id AF7FE3B1B29; Wed, 29 Nov 2017 19:30:46 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 97750216C1C; Wed, 29 Nov 2017 19:30:46 +0000 (UTC) Date: Wed, 29 Nov 2017 19:30:46 +0000 From: Evan Hunt To: Tony Finch Cc: Andrew Sullivan , dnsop@ietf.org Message-ID: <20171129193046.GA35419@isc.org> References: <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <5A1DEEE1.3070809@redbarn.org> <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> <5A1E2491.9070805@redbarn.org> <20171129122101.mv7zlc6kdqe3ojnv@mx4.yitter.info> <13A36237-CA11-44F3-BA80-69302F7D14F9@redbarn.org> <20171129122811.bydl23dadf53yzkd@mx4.yitter.info> <20171129140806.fz2zzcltbd7bgjbz@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 19:31:06 -0000 On Wed, Nov 29, 2017 at 03:06:02PM +0000, Tony Finch wrote: > Upward referrals exist, but bare "referral" is short for "downward > referral". Other things that look like referrals (such as upward > referrals or implicit referrals) have to have a qualifier. +1 -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Wed Nov 29 11:38:35 2017 Return-Path: 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 27CC1128954 for ; Wed, 29 Nov 2017 11:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 FrsbIwaAdeYJ for ; Wed, 29 Nov 2017 11:38:32 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 E8F4E126C22 for ; Wed, 29 Nov 2017 11:38:31 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id B9EE73B1E28; Wed, 29 Nov 2017 19:37:31 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id A20BE216C1C; Wed, 29 Nov 2017 19:37:31 +0000 (UTC) Date: Wed, 29 Nov 2017 19:37:31 +0000 From: Evan Hunt To: Andrew Sullivan Cc: dnsop@ietf.org Message-ID: <20171129193731.GB35419@isc.org> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <5A1DEEE1.3070809@redbarn.org> <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> <20171129023720.GA99800@isc.org> <20171129122553.oyx5ftqoifbnkw7h@anvilwalrusden.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171129122553.oyx5ftqoifbnkw7h@anvilwalrusden.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 19:38:33 -0000 On Wed, Nov 29, 2017 at 07:25:53AM -0500, Andrew Sullivan wrote: > How about, "This kind of response is not required for resolution or > for correctly answering any query, and in practice some authoritative > server operators will not return referral responses beyond those > required for delegation"? Up to the comma looks fine. The part after the comma strikes me as over-wordy, and I suggest "and there is no requirement that authoritative servers send them". -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Wed Nov 29 13:19:29 2017 Return-Path: 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 E1D65128B4E for ; Wed, 29 Nov 2017 13:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KH6qfR7bz1vT for ; Wed, 29 Nov 2017 13:19:22 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9191275F4 for ; Wed, 29 Nov 2017 13:19:21 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id f140so8656911wmd.2 for ; Wed, 29 Nov 2017 13:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=APGrBN4nDjkPjG8n4AU+Xz+4hABSjK3zXnJekvjDU9M=; b=NtgvHsZNgx2Hi8Rh0mMAmzIx/A1X9R+OUMwa5VtjArgEdIYZukd1K6xzIsoHuagkP2 +UUdHBvG5sq8StiiC8SiaIF9/ipfXmviCDxV9/l7gIejitcifikeOYFC4cz2VQ7Qv3rq iin3lojiD59rOUezvFEKtQ007+cBzMpyCxriTsuKjvV+twMhSQbuX3meYSn4AYgt2Jpd 13aDiR7zPy+XAu9yqLobONZE3MJmyHmnvFgCXWakS84ZyQ2aPI99qLnTqZXWc4CVsFvJ 6S8I6EoeOcA2VaEh7kguImiSuhyjNkHVfh2Jc3fRM+MgcFYI8LTZbCdgkgTcvjhr3DRK /oHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=APGrBN4nDjkPjG8n4AU+Xz+4hABSjK3zXnJekvjDU9M=; b=qriY5S5EeYCuHpicZk3wT3+q60d6d3KnyV/OwdW6GUnicbaG/yQaCGey2Tw6JAkMoo g20WRxa/8TJ37yt52ekAMczdvD8mq7QRvwasWBQxz1aNM804oeDFdoXVtQh5AynrMLsA qAgvxebpFPPQ65d9gVAjzsfyGiZd3H8bOG3O3tqq5qXvlQVaPcTt8eV5uSh5RYx6BFwR I/1bTztUc2WNXXW5hp/8ym6ygaf8XSBnrmE6NRFsr2xygNcLATumgngNyyb9Bv2KtawJ dVBijGmvWV41qb2gygawRUsvF8gsMTYgWI781OqgffRYpclwSnhdjONHgWM+a3b/YRfu q+7w== X-Gm-Message-State: AJaThX6B2nO1NYTMOI3bZjYrrzAbhmkjtIJwjRG3cLd2J0Pj1iWAikgP wd0wQquJ/wBhpECcq0K5I5RuBatcap4ngsSha74= X-Google-Smtp-Source: AGs4zMYVilnLnerwmWrycMtaugNTce8Jtg7sxSrE3ZdvTKiNn4tMOc6pM8stHmCDU8kE5dRvKFreX0Ryxf2cChcp3iM= X-Received: by 10.28.120.2 with SMTP id t2mr133345wmc.5.1511990360032; Wed, 29 Nov 2017 13:19:20 -0800 (PST) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.223.151.197 with HTTP; Wed, 29 Nov 2017 13:18:39 -0800 (PST) In-Reply-To: <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org> <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info> From: Dick Franks Date: Wed, 29 Nov 2017 21:18:39 +0000 X-Google-Sender-Auth: hUar0UVlpH9dPF9LcorLm4pBvd4 Message-ID: To: Andrew Sullivan Cc: IETF DNSOP WG Content-Type: multipart/alternative; boundary="089e082f98bc5047ea055f25b083" Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 21:19:28 -0000 --089e082f98bc5047ea055f25b083 Content-Type: text/plain; charset="UTF-8" On 29 November 2017 at 12:17, Andrew Sullivan wrote: > On Wed, Nov 29, 2017 at 01:14:13PM +1100, Mark Andrews wrote: > > When the CNAME refers to a name that is out of zone and the target zone > is below > > a zone that the server serves you will have CNAME (DNAME) + referral. > > > > 4.3.2 loops. > > This part I got. > > > pass 1 -> 3a (adds CNAME, AA is set as it matches the question > section, QNAME is updated). > > This is the CNAME response, yes, ok. > > > pass 2 -> 3b (we have a partial match with a bottom of zone cut > which adds the referral). > > > > Right, and the authoritative server can't proceed, but the referral is > necessary. Good, this is helpful, thanks. This also means, of > course, that in such a response the answer section isn't empty. Is > this why you call it a "partial referral"? > And said referral could be to an arbitrary node in the DNS tree, i.e. possibly "upward"? Or am I missing something? > > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --089e082f98bc5047ea055f25b083 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 29 November 2017 at 12:17, Andrew Sulliva= n <ajs@anvilwalrusden.com> wrote:
On Wed, Nov 29, 2017 at 01:14:13PM +1100, Ma= rk Andrews wrote:
> When the CNAME refers to a name that is out of zone and the target zon= e is below
> a zone that the server serves you will have CNAME (DNAME) + referral.<= br> >
> 4.3.2 loops.

This part I got.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0pass 1 -> 3a=C2=A0 (adds CNAME, AA is set= as it matches the question section, QNAME is updated).

This is the CNAME response, yes, ok.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0pass 2 -> 3b=C2=A0 (we have a partial mat= ch with a bottom of zone cut which adds the referral).
>

Right, and the authoritative server can't proceed, but the refer= ral is
necessary.=C2=A0 Good, this is helpful, thanks.=C2=A0 This also means, of course, that in such a response the answer section isn't empty.=C2=A0 I= s
this why you call it a "partial referral"?

And said referral could be to an arbitrary= node in the DNS tree,=C2=A0 i.e. possibly "upward"?

Or am I missing something?


=C2=A0

DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--089e082f98bc5047ea055f25b083-- From nobody Wed Nov 29 13:24:43 2017 Return-Path: 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 DD12C1270A7 for ; Wed, 29 Nov 2017 13:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=C1fgtLYf; dkim=pass (1024-bit key) header.d=yitter.info header.b=kH+2vE2p 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 ygaE5C7I_UVA for ; Wed, 29 Nov 2017 13:24:40 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039F51200CF for ; Wed, 29 Nov 2017 13:24:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 46EE4BD337 for ; Wed, 29 Nov 2017 21:23:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511990636; bh=afwgjNzXQaUzPvvk+nRo1Do5VW/OPCCG3974KIvg6zg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=C1fgtLYft77Q/AczBOAieKnkNEW6UtsVZm2WcAAoV8uQGi6y7LejpevoadK26UCiP l7e9HqpyoE8k/nexVFeE/HEvHOOjPSkWnw9Nm0XApgLVa4Yk6KVKPTm/ZR3rx1Fstm nDYxLFU8ok4RZkDXVWmWhWuaAsLjoU0LAN0Jgj/Y= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZpByNLtNfuo for ; Wed, 29 Nov 2017 21:23:55 +0000 (UTC) Date: Wed, 29 Nov 2017 16:23:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1511990634; bh=afwgjNzXQaUzPvvk+nRo1Do5VW/OPCCG3974KIvg6zg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=kH+2vE2psFcbEFcfTlLek6y5VnkFW17yyiWPrkvm2h9kM5Z/gZKFfxp37uXpx4pN/ WZmyH17U/2oHV8NPhkBBEm2iqrLWIyRnym/ka4CVi5KkU2DJ/SHRPwZl+wqrdKUK5o +uQdMasRtQGDbukz0YxV6IHOzRY8dd7yxJ/1iX6A= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171129212354.vu4zmki3pi3qnhzz@mx4.yitter.info> References: <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org> <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 21:24:42 -0000 On Wed, Nov 29, 2017 at 09:18:39PM +0000, Dick Franks wrote: > > And said referral could be to an arbitrary node in the DNS tree, i.e. > possibly "upward"? > > Or am I missing something? That depends on whether you believe the later part of the algorithm in RFC 1034 (where it says to do things from the cache) is part of the "referral" part, particularly in a mixed-mode server where it has received a query with RD=0. The list appears to have strong feelings about that. It's why Joe and I wrote draft-sullivan-dnsop-refer-down. As I've said many times, I don't believe that settling that question is appropriate for the terminology document. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 29 14:14:10 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C44126D3F; Wed, 29 Nov 2017 14:14:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151199364931.4845.3034001091375154653@ietfa.amsl.com> Date: Wed, 29 Nov 2017 14:14:09 -0800 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 22:14:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Security Considerations for RFC5011 Publishers Authors : Wes Hardaker Warren Kumari Filename : draft-ietf-dnsop-rfc5011-security-considerations-08.txt Pages : 18 Date : 2017-11-29 Abstract: This document extends the RFC5011 rollover strategy with timing advice that must be followed in order to maintain security. Specifically, this document describes the math behind the minimum time-length that a DNS zone publisher must wait before signing exclusively with recently added DNSKEYs. It contains much math and complicated equations, but the summary is that the key rollover / revocation time is much longer than intuition would suggest. If you are not both publishing a DNSSEC DNSKEY, and using RFC5011 to advertise this DNSKEY as a new Secure Entry Point key for use as a trust anchor, you probably don't need to read this document. This document also describes the minimum time-length that a DNS zone publisher must wait after publishing a revoked DNSKEY before assuming that all active RFC5011 resolvers should have seen the revocation- marked key and removed it from their list of trust anchors. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-08 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 29 14:15:35 2017 Return-Path: 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 011D8126D3F for ; Wed, 29 Nov 2017 14:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rirr969-kxBq for ; Wed, 29 Nov 2017 14:15:32 -0800 (PST) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B977124BE8 for ; Wed, 29 Nov 2017 14:15:32 -0800 (PST) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 8AA5023156; Wed, 29 Nov 2017 14:15:30 -0800 (PST) From: Wes Hardaker To: Michael StJohns Cc: Wes Hardaker , IETF DNSOP WG References: <53d210a2-b4dc-f2ce-33a8-4964cba64c4c@nthpermutation.com> Date: Wed, 29 Nov 2017 14:15:30 -0800 In-Reply-To: <53d210a2-b4dc-f2ce-33a8-4964cba64c4c@nthpermutation.com> (Michael StJohns's message of "Mon, 20 Nov 2017 14:47:48 -0500") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] 5011-security-considerations and the safetyMargin X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 22:15:34 -0000 Michael StJohns writes: > Ok - after thinking about it, it turns out to be fairly simple. Thanks for the math and text. Based on your text, I've added (back) the section on safetyMargin. Can you check the -08 version to see if I mis-spoke you at all? Note that I added a few more lines and rounded all the numbers up, since resolvers won't query in a fraction of an increment. -- Wes Hardaker USC/ISI From nobody Wed Nov 29 14:24:20 2017 Return-Path: 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 70BD5124234 for ; Wed, 29 Nov 2017 14:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DRbE58TbsSbd for ; Wed, 29 Nov 2017 14:24:17 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC47120721 for ; Wed, 29 Nov 2017 14:24:16 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id y82so38147229wmg.1 for ; Wed, 29 Nov 2017 14:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5aTiteDyEBCL0Il4cGyyCQDvD33pkBZ/O05Bl8YTGt8=; b=FGoJbPGL2BBG5La2isqH5x/ya2OHzXpI2EXS65LYFSiQ4g0B8LzjfhW98ZI1UluBkP Qhety6Qyd/BsM4ZbPs7UnlPfOsvDaJZNoNjW0l+VIf2tn/ZEOagsKXlmHWgvqArsbGZk RhzwB7R694oTp9pOAMm4kmPCk5Ao9UW1aygVkjhUfZtGDmRoLDD6FAxnMRg+EzgDWIkP FBuJu5KVHXd3JhXniI7tJ7zxyN1Rbfg0ItuU7tSboNqPzjAF5S6GCgEksJFA4dyAE8Om 8GFiP+/Fkml6YUcEmHTGjJJWuJVaMj8OnIy/X4FAbgS8bvb7cKiKk5XlSzU0PNSiSnd8 HZcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5aTiteDyEBCL0Il4cGyyCQDvD33pkBZ/O05Bl8YTGt8=; b=hHG9YmUE09IxoiYk2sib2wOO/WXts8IuVM+8/p8NpJ6q2qASg9+vvzxDy/lw9kJwss +VxWnJQACy5ta4EbOZzheGYEcteSD8poD2kMoPHbsumSLbOY96pVb51DdXc/+iQk8mD4 UuzlBGX3VpVInNGFtw60RemV4GBr+kF2udohpKD4c2eDrGjhj+6StywD408HpvJVpkPz vsYXoFV1VkpzU56YZSAQ2/kNQIImnvMcIwr4gXmF2HPZQGgY2PpZKmcWEzL8dSys5YAH 8rz/g2F/p7RmEl2RgpbQqZt9jVEMA13lrmAkcXFAMcpdm1jTKU4rwthxVXMpMK58pqAQ ztaA== X-Gm-Message-State: AJaThX76LuZdgetbwaXENVfZsedQsgBtuECO/1hXeJQIVdNdzQ3eDFNU LTaFY3lK+w+7fzXRNbYcXM/QyDIK7nuFK5r+Yd8= X-Google-Smtp-Source: AGs4zMZOWyImtIGNyonZlfnSaXX42E7p7dfhJD7Obh2CYs8nZJmVyybCW4q0gpO/t2HEVZvRCi9artbRtM3J9Jjofts= X-Received: by 10.28.141.211 with SMTP id p202mr197548wmd.61.1511994255507; Wed, 29 Nov 2017 14:24:15 -0800 (PST) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.223.151.197 with HTTP; Wed, 29 Nov 2017 14:23:34 -0800 (PST) In-Reply-To: <20171129212354.vu4zmki3pi3qnhzz@mx4.yitter.info> References: <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org> <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info> <20171129212354.vu4zmki3pi3qnhzz@mx4.yitter.info> From: Dick Franks Date: Wed, 29 Nov 2017 22:23:34 +0000 X-Google-Sender-Auth: AqcgjMP3_d_rvatyZqz7G-VQ7u4 Message-ID: To: Andrew Sullivan Cc: IETF DNSOP WG Content-Type: multipart/alternative; boundary="001a114709ea8086c7055f2698c7" Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 22:24:19 -0000 --001a114709ea8086c7055f2698c7 Content-Type: text/plain; charset="UTF-8" On 29 November 2017 at 21:23, Andrew Sullivan wrote: > On Wed, Nov 29, 2017 at 09:18:39PM +0000, Dick Franks wrote: > > > > And said referral could be to an arbitrary node in the DNS tree, i.e. > > possibly "upward"? > > > > Or am I missing something? > > That depends on whether you believe the later part of the algorithm in > RFC 1034 (where it says to do things from the cache) is part of the > "referral" part, particularly in a mixed-mode server where it has > received a query with RD=0. The list appears to have strong feelings > about that. It's why Joe and I wrote draft-sullivan-dnsop-refer-down. > Mark's example involved two unrelated (which I mistakenly referred to as arbitrary) zones, and a server having authoritative data for both. Cached data not involved. Until Mark's intervention, I was convinced that referrals were downwards only. I was trying to establish if this creates a counter-example, which might require me to unconvince myself. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a114709ea8086c7055f2698c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 29 November 2017 at 21:23, Andrew Sulliva= n <ajs@anvilwalrusden.com> wrote:
On Wed, Nov 29, 2017 at 09:18:39PM +0000, Di= ck Franks wrote:
>
> And said referral could be to an arbitrary node in the DNS tree,=C2=A0= i.e.
> possibly "upward"?
>
> Or am I missing something?

That depends on whether you believe the later part of the algorithm = in
RFC 1034 (where it says to do things from the cache) is part of the
"referral" part, particularly in a mixed-mode server where it has=
received a query with RD=3D0.=C2=A0 The list appears to have strong feeling= s
about that.=C2=A0 It's why Joe and I wrote draft-sullivan-dnsop-refer-<= wbr>down.

Mark's example involved t= wo unrelated (which I mistakenly referred to as
arbitrary) zones, and a = server having authoritative data for both.
Cached data not involved.
=
Until Mark's intervention, I was convinced that referral= s were downwards only.
I was trying to establish if this crea= tes a counter-example, which might require
me to unconvince myself.
<= /div>


=C2=A0
=C2=A0
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--001a114709ea8086c7055f2698c7-- From nobody Wed Nov 29 14:29:28 2017 Return-Path: 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 5D89E126B6D; Wed, 29 Nov 2017 14:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xoozGeJaCy-d; Wed, 29 Nov 2017 14:29:25 -0800 (PST) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F51120721; Wed, 29 Nov 2017 14:29:25 -0800 (PST) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 6AE7223175; Wed, 29 Nov 2017 14:29:25 -0800 (PST) From: Wes Hardaker To: internet-drafts@ietf.org Cc: dnsop@ietf.org References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> Date: Wed, 29 Nov 2017 14:29:24 -0800 In-Reply-To: <151199364931.4845.3034001091375154653@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Wed, 29 Nov 2017 14:14:09 -0800") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 22:29:27 -0000 internet-drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Domain Name System > Operations WG of the IETF. FYI, this contains the restructuring talked about during IETF100/dnsop as well the new safetyMargin concepts proposed by MSJ. I haven't done a complete double check on all my restructuring yet, so for the chairs especially: there will likely be a -09 very soon ready for second WGLC, but not this one. -- Wes Hardaker USC/ISI From nobody Wed Nov 29 15:13:13 2017 Return-Path: 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 9F5A51201FA for ; Wed, 29 Nov 2017 15:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com 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 h1KcV106eR6j for ; Wed, 29 Nov 2017 15:13:09 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D911D127A90 for ; Wed, 29 Nov 2017 15:13:08 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 51F95209D1; Wed, 29 Nov 2017 18:13:08 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 29 Nov 2017 18:13:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=r6jg01 0epxf+2If6vqBxaUDzmOioXcI+y5r+41uMo6g=; b=VpeR8KzyJInU0Ymg3nvox4 yXEu7aJoI6IwaZGK/jkkZI+uLPuwz7U2j9Ef5k7ZejnmXd5h//5lVI5LpKyiOKrK iIgrio75hp6dtTv+nGQaQy8vxKc6GRY3bCjTYavDNbgb0y1kLD2UnGKbWAhvFvDl VILLkq21KO3An6GeQTuzOz5GVil6kK27AjoOhww+nNWGLNonNB90BEHF/2tl5ZM6 No53US+D84sieorhbVad5ipqxItzppyUKqBFCRg8wagsDy8bf+aZUhhjMMKwC/AF 35Eh7J5z1ABuePWuj2N7TPIxdHLZ1ZUezAjHcyw1XshJe9VXVSR9rOVdTX5MVAPw == X-ME-Sender: Received: from [192.168.1.128] (unknown [195.147.34.210]) by mail.messagingengine.com (Postfix) with ESMTPA id DC2F924751; Wed, 29 Nov 2017 18:13:07 -0500 (EST) Content-Type: multipart/alternative; boundary=Apple-Mail-39F49EBD-7EA4-4060-8FD5-3D8CA3CCD577 Mime-Version: 1.0 (1.0) From: Tony Finch X-Mailer: iPhone Mail (15B202) In-Reply-To: Date: Wed, 29 Nov 2017 23:13:06 +0000 Cc: Andrew Sullivan , IETF DNSOP WG Content-Transfer-Encoding: 7bit Message-Id: <8CA9C8EB-F117-4797-810F-DEF047F110BB@dotat.at> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org> <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info> To: Dick Franks Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 23:13:11 -0000 --Apple-Mail-39F49EBD-7EA4-4060-8FD5-3D8CA3CCD577 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 29 Nov 2017, at 21:18, Dick Franks wrote: >> On 29 November 2017 at 12:17, Andrew Sullivan wr= ote: >>=20 >> Right, and the authoritative server can't proceed, but the referral is >> necessary. Good, this is helpful, thanks. This also means, of >> course, that in such a response the answer section isn't empty. Is >> this why you call it a "partial referral"? >=20 > And said referral could be to an arbitrary node in the DNS tree, i.e. pos= sibly "upward"? >=20 > Or am I missing something? In this case we=E2=80=99re dealing with an authoritative answer containing a= CNAME pointing out of the server=E2=80=99s authoritative data. If the server is authoritative only, then there are three cases: (1) the CNA= ME points to a child zone, so the authority section contains a referral - th= is is the partial answer plus referral case that Mark described; (2) the CNA= ME points to a different non-child zone and the server provides full answers= , in which case the authority section contains the apex records of the zone c= ontaining the CNAME owner; or (3) same as (2) but the server sends minimal a= nswers with an empty authority section. If it is a 1034 hybrid rec+auth server, the 4.3.2 algorithm step 4 requires t= he same referral in case (1) because there is a =E2=80=9Cdelegation from aut= horitative data=E2=80=9D; in case (2) you get an implicit referral from the c= ache (which can be upwards). Tony. --=20 f.anthony.n.finch http://dotat.at= --Apple-Mail-39F49EBD-7EA4-4060-8FD5-3D8CA3CCD577 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 29 Nov 2017, at 21:1= 8, Dick Franks <rwfranks@acm.org&= gt; wrote:
On 29 November 2017 at 12:17, A= ndrew Sullivan <ajs@anvilwalrusden.com> wrote:
Right, and the authoritative server can't proceed, but the referral i= s
necessary.  Good, this is helpful, thanks.  This also means, of course, that in such a response the answer section isn't empty.  Is
= this why you call it a "partial referral"?

And said referral could be to an arbitrary n= ode in the DNS tree,  i.e. possibly "upward"?

Or am I= missing something?

In th= is case we=E2=80=99re dealing with an authoritative answer containing a CNAM= E pointing out of the server=E2=80=99s authoritative data.

If the server is authoritative only, then there are three cases: (1)= the CNAME points to a child zone, so the authority section contains a refer= ral - this is the partial answer plus referral case that Mark described; (2)= the CNAME points to a different non-child zone and the server provides full= answers, in which case the authority section contains the apex records of t= he zone containing the CNAME owner; or (3) same as (2) but the server sends m= inimal answers with an empty authority section.

If i= t is a 1034 hybrid rec+auth server, the 4.3.2 algorithm step 4 requires the s= ame referral in case (1) because there is a =E2=80=9Cdelegation from authori= tative data=E2=80=9D; in case (2) you get an implicit referral from the cach= e (which can be upwards).

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at
= --Apple-Mail-39F49EBD-7EA4-4060-8FD5-3D8CA3CCD577-- From nobody Wed Nov 29 15:29:04 2017 Return-Path: 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 15E2012700F for ; Wed, 29 Nov 2017 15:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Lo0Kn1oAz8GC for ; Wed, 29 Nov 2017 15:29:01 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8C21286CA for ; Wed, 29 Nov 2017 15:28:59 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id y82so38298400wmg.1 for ; Wed, 29 Nov 2017 15:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GQuZ7DbMbUko/Ci9BbhbNkxkMjQIl+QckjBUhO644uw=; b=IOu+r04kygnBjeb9bt04HIw+LeVBt9ufFcK6EmSrLcMvzPIUQ655xJQGrPSwR95IAs C/TjVzMLqzJHLwcqBZG8nIDjCuFOUdFKQ9hiM+/nKNoIPlanlwMc6wD2hl2hzeFqJkXt AVz03tcsDT3hVLcfaj93SRIOjMRHmmQbthHelaZtSWwaxRwPpYhdwVhsoNn548r4p03R S302xEYqt0W4FmupysyM748VKGCakgbZyQxRFG6ORwzSSTekmnFcNp9i0MiU++IqY7Jn xC1wHcbmM7f4/9YiOww7lwxpFioT9Xcv/CJstKT8ofOTGqHzZRDBQL4qfcvbd/HR+3La LC3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GQuZ7DbMbUko/Ci9BbhbNkxkMjQIl+QckjBUhO644uw=; b=nPndDx00+BOjIqFqmY6JnOUw0Uf9es3fbUqXFaQadxm1sgUk90tb/PJEQYmGDujpao 94P86T7FCq7pQ/iuv9D+JOsK+TE+06piDzKTsp9t2PxhACFXeN9rF2rhzE3J2JbSt3ib DKU2h4NpVfiYVpbRXebEaaL06ZK4ecyiId4RVvC+xoa0yX7juveTuZDPe0ExvVylr/2b NoZPUdrmA6hvMLMYKuY9wlMlorHYap/iDGbqDXJtRXWHb7MoH66FM12Ar4XMK5gRbLYS cdOXHm6k8X1APLvVxYMj+2AVqX1DD+ZOgoSJeHxmfBNjqsLroZOFCNFC6Ie7aOX0jM0c 0t/A== X-Gm-Message-State: AJaThX6Hjrdolbh8P5Y2TK5s8J0iQ5G5sVB4wEe0w46VLD/2iKeVyEvN QurbyheGRxBPTfAhLNKPbUznul56CqBf/G4efOQ= X-Google-Smtp-Source: AGs4zMbK3bciNlwekxTREGh3KInaFf3irfzdLZmxRmUei8WzSepVtnyhaBRKvURJ//di43blcQmxdbdWPCmE0XOfioo= X-Received: by 10.28.35.4 with SMTP id j4mr276325wmj.55.1511998138364; Wed, 29 Nov 2017 15:28:58 -0800 (PST) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.223.151.197 with HTTP; Wed, 29 Nov 2017 15:28:17 -0800 (PST) In-Reply-To: <8CA9C8EB-F117-4797-810F-DEF047F110BB@dotat.at> References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org> <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info> <8CA9C8EB-F117-4797-810F-DEF047F110BB@dotat.at> From: Dick Franks Date: Wed, 29 Nov 2017 23:28:17 +0000 X-Google-Sender-Auth: ImvsKGGCSigpNqZtNVFLC3Yra6c Message-ID: To: Tony Finch Cc: Andrew Sullivan , IETF DNSOP WG Content-Type: multipart/alternative; boundary="001a113ea466f036c7055f277fcc" Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 23:29:03 -0000 --001a113ea466f036c7055f277fcc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 29 November 2017 at 23:13, Tony Finch wrote: > > > On 29 Nov 2017, at 21:18, Dick Franks wrote: > > On 29 November 2017 at 12:17, Andrew Sullivan > wrote: >> >> >> Right, and the authoritative server can't proceed, but the referral is >> necessary. Good, this is helpful, thanks. This also means, of >> course, that in such a response the answer section isn't empty. Is >> this why you call it a "partial referral"? >> > > And said referral could be to an arbitrary node in the DNS tree, i.e. > possibly "upward"? > > Or am I missing something? > > > In this case we=E2=80=99re dealing with an authoritative answer containin= g a CNAME > pointing out of the server=E2=80=99s authoritative data. > > If the server is authoritative only, then there are three cases: (1) the > CNAME points to a child zone, so the authority section contains a referra= l > - this is the partial answer plus referral case that Mark described; (2) > the CNAME points to a different non-child zone and the server provides fu= ll > answers, in which case the authority section contains the apex records of > the zone containing the CNAME owner; or (3) same as (2) but the server > sends minimal answers with an empty authority section. > > If it is a 1034 hybrid rec+auth server, the 4.3.2 algorithm step 4 > requires the same referral in case (1) because there is a =E2=80=9Cdelega= tion from > authoritative data=E2=80=9D; in case (2) you get an implicit referral fro= m the > cache (which can be upwards). > I get the picture. Many thanks --001a113ea466f036c7055f277fcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 29 November 2017 at 23:13, Tony Finch <dot@do= tat.at> wrote:


On 29 Nov 2017, at 21:18, Di= ck Franks <rwfrank= s@acm.org> wrote:
On 29 November 2017 at 12:17, Andrew Sullivan &= lt;ajs@anvilwal= rusden.com> wrote:

Right, and the authoritative server can't proceed, but the refer= ral is
necessary.=C2=A0 Good, this is helpful, thanks.=C2=A0 This also means, of course, that in such a response the answer section isn't empty.=C2=A0 I= s
this why you call it a "partial referral"?

And said referral could be to an arbitrary= node in the DNS tree,=C2=A0 i.e. possibly "upward"?

Or am I missing something?

In this case we=E2=80=99re dealing with an authoritative an= swer containing a CNAME pointing out of the server=E2=80=99s authoritative = data.

If the server is authoritative only, then th= ere are three cases: (1) the CNAME points to a child zone, so the authority= section contains a referral - this is the partial answer plus referral cas= e that Mark described; (2) the CNAME points to a different non-child zone a= nd the server provides full answers, in which case the authority section co= ntains the apex records of the zone containing the CNAME owner; or (3) same= as (2) but the server sends minimal answers with an empty authority sectio= n.

If it is a 1034 hybrid rec+auth server, the 4.3= .2 algorithm step 4 requires the same referral in case (1) because there is= a =E2=80=9Cdelegation from authoritative data=E2=80=9D; in case (2) you ge= t an implicit referral from the cache (which can be upwards).
=C2=A0
I get the picture= .=C2=A0 Many thanks
--001a113ea466f036c7055f277fcc-- From nobody Wed Nov 29 15:34:19 2017 Return-Path: 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 CAFE312700F for ; Wed, 29 Nov 2017 15:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com 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 x9i4Hejx-czU for ; Wed, 29 Nov 2017 15:34:16 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286431201FA for ; Wed, 29 Nov 2017 15:34:16 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E2413209AE; Wed, 29 Nov 2017 18:34:14 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 29 Nov 2017 18:34:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=P5brRI 1HJRhG0+P4RdVF8VXx22OAcTHtE41+emth/gw=; b=FvTk1SsSJ0kQP+/Ah19q4z DNZIcXi7r9ffWVFikAOqliEeF6SomcJNfsS6JCd5AyjOKXumsqM4IAlk7II1y9b8 Ix3G781fji1he7GuYHVCZXHqe/TKffMAsrSiOMnBawFWLNaX8qTID5VsUXjUMoho JzLQPbdD3oIQQlld0wuW47XRDe0nfN5AEfSMmNJpoCl6sWo0mAIdKfxUBw9L2EYa /ZxeNwC9P+5M7OjRBrpxsxOyahTFIgLJ+X/Lo8ejl13+dklHEe44iuZ/Px1QDrNR tBw0RTc557jh5uU5FO50CK9a+wfjiuZ0ZgMP8AP5pdntsCktemNdEAJi9IYp9LKQ == X-ME-Sender: Received: from [192.168.1.128] (unknown [195.147.34.210]) by mail.messagingengine.com (Postfix) with ESMTPA id 9241E243F9; Wed, 29 Nov 2017 18:34:14 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Tony Finch X-Mailer: iPhone Mail (15B202) In-Reply-To: <8CA9C8EB-F117-4797-810F-DEF047F110BB@dotat.at> Date: Wed, 29 Nov 2017 23:34:12 +0000 Cc: IETF DNSOP WG , Andrew Sullivan Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org> <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info> <8CA9C8EB-F117-4797-810F-DEF047F110BB@dotat.at> To: Dick Franks Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 23:34:18 -0000 > On 29 Nov 2017, at 23:13, Tony Finch wrote: > ... you get an implicit referral from the cache (which can be upwards). I just realised this might be a useful point. Normal (downward) referrals come from authoritative data, and indicate the s= erver is saying to the client, you need to ask here next; on the other hand t= hese special kinds of referrals come from the cache. An implicit referral co= mes in a full-fat RD=3D1 RA=3D1 answer, and indicates the server is telling t= he client where the answer came from; if RD=3D0 or RA=3D0 you can get an upw= ard referral, which indicates the server is telling the client where the ser= ver would ask next in order to fill its cache. Normal (downward) referrals are instructions to iterative resolvers; implici= t referrals and upward referrals are supposed to be cache-filling gossip (in= the distributed systems sense of gossip protocols). Tony. --=20 f.anthony.n.finch http://dotat.at= From nobody Wed Nov 29 17:59:37 2017 Return-Path: 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 59D581287A3 for ; Wed, 29 Nov 2017 17:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=BETYr7Tc; dkim=pass (1024-bit key) header.d=yitter.info header.b=WHNUEA4Z 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 6573c_1KaLJU for ; Wed, 29 Nov 2017 17:59:36 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1787127136 for ; Wed, 29 Nov 2017 17:59:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 85138BD337 for ; Thu, 30 Nov 2017 01:59:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1512007144; bh=p/Rtz3TBbf4gb5I/s0ZqW6zoRemIdd4m71fjIFHRJgQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=BETYr7TcTD4GXjKRCWuOdwBJJIL2ZErn+o9o9P4ZSQZWOL2uw1Pk8VA3mPakEYWr4 Wgc56FYdczPqCG8dPsyvvnKdpjkF7pswU3oEx/xYwBR1+7Uam1/JFa/B4EweG6vyio QNCdGkcz/77cUrzMpKx+/5OyCTcGBcVJI7dTKipw= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sCqvcWKT0it for ; Thu, 30 Nov 2017 01:59:02 +0000 (UTC) Date: Wed, 29 Nov 2017 20:59:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1512007142; bh=p/Rtz3TBbf4gb5I/s0ZqW6zoRemIdd4m71fjIFHRJgQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=WHNUEA4ZvQwkeBUK6noanUuS9emey2VVwCm+BR/9boTD+QiJaoVuUw28ToC1T+bEj sAhqv2hRmwGoO1bV0MJGr6oGtaZf6ZjlriG/4S45GcbUJnNDKPwGMPDuU5Ew041MdM TBGVfcElBl7s8s/vjW4mZwRlC4WP4dV+6waITgSY= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171130015900.vtd2wf7kysibctbj@mx4.yitter.info> References: <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org> <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info> <8CA9C8EB-F117-4797-810F-DEF047F110BB@dotat.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 01:59:37 -0000 On Wed, Nov 29, 2017 at 11:34:12PM +0000, Tony Finch wrote: > > Normal (downward) referrals come from authoritative data, and indicate the server is saying to the client, you need to ask here next; on the other hand these special kinds of referrals come from the cache. An implicit referral comes in a full-fat RD=1 RA=1 answer, and indicates the server is telling the client where the answer came from; if RD=0 or RA=0 you can get an upward referral, which indicates the server is telling the client where the server would ask next in order to fill its cache. > I think that's correct. But what is not plain to me in my reading, insistent noises on the list notwithstanding, is whether the second ¶ in step 3.b of the algorithm in section 4.3.2 of RFC 1034 is still part of what "a referral" means. The ordinary English meaning, as far as I can tell, of that 3.b subsection is that everything one does as part of step 3.b is a referral response. The problem is that "Go to step 4" is part of that last ¶, not a new ¶, and so what I think is obscure in the algorithm text is whether the stuff you're copying into the response in step 4. I tend to agree that the other parts of STD 13 argues in favour of at least "upward referrals are a degenerate case" and maybe even "upward referrals are _not_ referrals in the bare word sense." But while I find that reading persuasive, there are two important facts to consider: for a long time, that was not actually the reading people adhered to, and there does not seem to have been a lot of complaining about it (indeed, even djb's remarks about DNS barely suggest this is a fault of the server, and AFAICT he thought that BIND was responsible for bubonic plague when he wrote those notes). Second, we should not expect, in fairness, an earnest reader to do the same synoptic reading that others have done, or to reach the same conclusion. It's at least as likely that such a reader will conclude that RFCs 1034 and 1035 are written with a certain lack of terminological rigour -- which is perhaps borne out by the effort we apparently need to make to clarify a term as fundamental as "referral". I don't think anyone in this discussion disagrees about how things _ought_ to operate. But in the terminology document, I think we have tried to preserve the meanings that persist on the Internet. I find it very hard to convince myself either that upward referrals are dead, or even that lots of people don't use "referral response" to mean "referral to the root". I encounter both of these ways of speaking with some regularity. Maybe my sample is really skewed; but I think it is at least as plausible that people who are clued into the DNS think that upward referrals are bad and that therefore all referrals must be down. > implicit referrals and upward referrals are supposed to be cache-filling gossip (in the distributed systems sense of gossip protocols). > I like this observation. Thanks. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 29 18:44:00 2017 Return-Path: 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 7AD45124BFA for ; Wed, 29 Nov 2017 18:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aSiVeEBxWb3D for ; Wed, 29 Nov 2017 18:43:58 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027DC120454 for ; Wed, 29 Nov 2017 18:43:57 -0800 (PST) Received: from [172.31.0.163] (unknown [222.128.198.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id CAABF61FA2; Thu, 30 Nov 2017 02:43:55 +0000 (UTC) Message-ID: <5A1F7067.3090400@redbarn.org> Date: Wed, 29 Nov 2017 18:43:51 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Andrew Sullivan CC: dnsop@ietf.org References: <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org> <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info> <8CA9C8EB-F117-4797-810F-DEF047F110BB@dotat.at> <20171130015900.vtd2wf7kysibctbj@mx4.yitter.info> In-Reply-To: <20171130015900.vtd2wf7kysibctbj@mx4.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 02:43:59 -0000 andrew, et al, i see that the discussion continued overnight (i'm here in beijing) and i hope you can reach a consensus on the matter. here's my input to the terminology of referrals. --- According to RFC 1034 section 4.3.2 step 3 substep B, a referral "happens when we encounter a node with NS RRs marking cuts along the bottom of a zone" and is constructed by copying "the NS RRs for the subzone into the authority section of the reply" and putting "whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache." By this definition, an answer whose answer section is empty and whose authority section contains an NS RR set, is only a "referral" if the NS RRs refer to a subzone of an authority server's zone data. === in other words, we need not argue about what a supposedly reasonable person may be able to understand or misunderstand from the RFC 1034 text and then rephrase it in some way that may raise or lower the risk of misunderstanding, or change the results of understanding. all we need to is quote the actual 1034 text and hope that whatever supposedly reasonable person reads this document, will come to the same conclusions they came to when reading 1034. vixie From nobody Thu Nov 30 03:14:33 2017 Return-Path: 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 695F21271DF for ; Thu, 30 Nov 2017 03:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 GNIWwTmkSy7v for ; Thu, 30 Nov 2017 03:14:29 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93CE129431 for ; Thu, 30 Nov 2017 03:14:29 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6693E356FF; Thu, 30 Nov 2017 11:14:29 +0000 (UTC) Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D0DF75D6A9; Thu, 30 Nov 2017 11:14:28 +0000 (UTC) To: Andrew Sullivan , dnsop@ietf.org References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> From: Florian Weimer Message-ID: <3eb246b2-59bd-ecc3-51f8-98d7e0a5b078@redhat.com> Date: Thu, 30 Nov 2017 12:14:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 30 Nov 2017 11:14:29 +0000 (UTC) Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 11:14:32 -0000 On 11/28/2017 08:50 PM, Andrew Sullivan wrote: > That leaves the task of the referrals definition. I have some new > text below: > > ---%<---cut here--- > > Referral: A type of response in which a server, signalling that it is > not authoritative for an answer, provides the querying resolver with > an alternative place to send its query. A referral contains an empty > answer section. It contains the NS RRset for the referred-to zone in > the authority section. It may contain RRs that provide addresses in > the additional section. The AA bit is clear. Is the goal to describe behavior of current (and perhaps past) implementations, or what the behavior should be under ideal circumstances? Thanks, Florian From nobody Thu Nov 30 04:24:21 2017 Return-Path: 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 D0B93126DFE for ; Thu, 30 Nov 2017 04:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 VLRdh6w9KTdh for ; Thu, 30 Nov 2017 04:24:16 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 8F43F12708C for ; Thu, 30 Nov 2017 04:24:16 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:57546) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eKNt0-000t0X-1L (Exim 4.89) (return-path ); Thu, 30 Nov 2017 12:24:14 +0000 Date: Thu, 30 Nov 2017 12:24:14 +0000 From: Tony Finch To: Andrew Sullivan cc: dnsop@ietf.org In-Reply-To: <20171130015900.vtd2wf7kysibctbj@mx4.yitter.info> Message-ID: References: <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org> <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info> <8CA9C8EB-F117-4797-810F-DEF047F110BB@dotat.at> <20171130015900.vtd2wf7kysibctbj@mx4.yitter.info> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870841-1564930901-1512044654=:22895" Archived-At: Subject: Re: [DNSOP] Clarifying referrals (#35) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 12:24:20 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870841-1564930901-1512044654=:22895 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Andrew Sullivan wrote: > > I think that's correct. But what is not plain to me in my reading, > insistent noises on the list notwithstanding, is whether the second =C2= =B6 > in step 3.b of the algorithm in section 4.3.2 of RFC 1034 is still > part of what "a referral" means. The ordinary English meaning, as far > as I can tell, of that 3.b subsection is that everything one does as > part of step 3.b is a referral response. Yes. =C2=B62 tells you how to construct a referral. > The problem is that "Go to step 4" is part of that last =C2=B6, not a new > =C2=B6, and so what I think is obscure in the algorithm text is whether t= he > stuff you're copying into the response in step 4. I think you're missing a word or two here :-) but the key part of step 4 wrt referrals is "If there was no delegation from authoritative data", i.e. if we already have a referral, don't overwrite it. The "go to step 4" is a switch from serving authoritative data to gossiping cached data, when the auth data can only provide part of the answer. (There's also more gossiping in step 6.) > It's at least as likely that such a reader will conclude that RFCs 1034 > and 1035 are written with a certain lack of terminological rigour -- > which is perhaps borne out by the effort we apparently need to make to > clarify a term as fundamental as "referral". It seems to me that these RFCs were written with a great deal of care, but their informality makes them appear less precise than they are - you have to read between the lines to work out the implicit meanings of the technical terms. But I don't think the terms are used inconsistently. > I don't think anyone in this discussion disagrees about how things > _ought_ to operate. But in the terminology document, I think we have > tried to preserve the meanings that persist on the Internet. I think it's worth being precriptive, but carefully. That is, telling readers of the terminology RFC that if they are using a term precisely in a document they are writing, they should only use it with the preferred meaning - but some people use it with these different meanings so readers need to be aware of these variations. e.g. for referrals, saying something like "the term referral is sometimes used in a way that also covers implicit referrals and upward referrals (qv) but precise writing should only use referral to mean a downward referral from authoritative data". Tony. --=20 f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Fitzroy, Sole: Northerly or northeasterly 5 or 6, occasionally 7 in east. Moderate or rough. Showers. Good. --1870870841-1564930901-1512044654=:22895-- From nobody Thu Nov 30 04:36:08 2017 Return-Path: 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 39EF412943E for ; Thu, 30 Nov 2017 04:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=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 XwGiFzQmWR20 for ; Thu, 30 Nov 2017 04:36:04 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 8E59812708C for ; Thu, 30 Nov 2017 04:36:03 -0800 (PST) Received: from grisu.home.partim.org (unknown [IPv6:2a04:b900:0:1:de53:60ff:fe07:b3e0]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 32AC581B7 for ; Thu, 30 Nov 2017 13:36:01 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=opennetlabs.com Date: Thu, 30 Nov 2017 13:36:00 +0100 From: Martin Hoffmann To: dnsop@ietf.org Message-ID: <20171130133600.447a2904@grisu.home.partim.org> Organization: Open Netlabs X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 12:36:07 -0000 Hi, the following is a review of draft-ietf-dnsop-terminology-bis-08. It represents a reading of the document front-to-back as a sort of whirlwind introduction to the depths of DNS and assumes that such a reading is intended and there is a narrative. Even if that wasn=E2=80=99t t= he original intention, the arrangement of the terms seems to imply it and I really like this form of introduction by short definition and pointers to further details. The review turned out to be quite a bit longer than expected. That notwithstanding, I really like the document. It is extremely helpful and serves its purpose well. Most of the comments are of an editorial nature, pointing out wording that might be unclear or the use of terms that haven=E2=80=99t been defined yet. I understand that the purpose of this bis was to only update RFC 7719 to new developments, but I hope the following will be helpful to the editors, anyway. Because most comments are very short, I decided to collect everything in this one message rather then creating issues on Github. If the editors would have preferred that or any other form more helpful, I am happy to transform the message accordingly. With that in mind, here goes: ------ %< ------ 1. INTRODUCTION | (See Section 2 for a fuller definition.) Section 2 doesn=E2=80=99t actually provide a definition for Domain Name Sys= tem. It does introduce Naming Systems and the Global DNS, but not the DNS as such. DOMAIN NAME | [RFC1034] defines the "domain name space" using [...], and the definition | in [RF1034] has the same practical result Repetition, replace with "...and this definition has the same ..."? | ... a domain name is a list of labels identifying a portion along one edge | of a directed acyclic graph. I keep struggling with this sentence, not being able to decide whether there is some error in it or whether I just am not familiar with the phrase =E2=80=98portion along one edge.=E2=80=99 Neither is optimal, though= , so I would propose to rather follow RFC 1034 and speak simply of a =E2=80=98path=E2=80= =99 through the graph? One realisation I had while thinking too much about this sentence is that my intuition (apparently backed up by RFC 1034) was to stick the labels to the nodes in the tree, but that it might actually be a better model to attach them to the edges and identify a node through the domain name leading up to it. Maybe that is what the sentence is trying to express? | A domain name can be relative to other parts of the tree [...] Proposal: Strike =E2=80=98other=E2=80=99 as there was no previous =E2=80=98= this part=E2=80=99 it could refer to? GLOBAL DNS -- FORMAT OF NAMES | Names in the common display format are normally written such that the | directionality of the writing system presents labels by decreasing | distance from the root (so, in both English and C the first label in the | ordered list is right-most; but in Arabic it may be left-most, depending | on local conventions). The first sentence makes it sound as if right-to-left languages would normally write =E2=80=98com.example=E2=80=99 which is not the case. Yes, th= ings get difficult once IDNs enter the scene, but the definition of the common display format (=E2=80=98same as presentation format=E2=80=99) only allows = ASCII characters and under these circumstances the name will always be in the =E2=80=98usual=E2=80=99 order. GLOBAL DNS -- ADMINISTRATION OF NAMES | (see the definition of to "delegation" in Section 6) Extra "to". | names operational community I am not sure if people outside of the immediate ICANN sphere have ever heard that term. Perhaps enclose it in quotes to indicate that this is a jargon introduced here? In general, I am not sure if this rapid sequence of terms and organizations surrounding the root zone is necessary here. Maybe it would fit better and in somewhat more detail in section 7? The important point for DNS seems to be that each zone administers its own names and that administration can be transferred via delegation? PRIVATE DNS | A system can use both the global DNS and one or more private DNS systems; | for example, see "Split DNS" in Section 7. Split DNS is actually defined in section 5. FULLY QUALIFIED DOMAIN NAME (FQDN): The discussion of the missing final dot probably predates the introduction of representation format and common display formats for domain names in the definition of Global DNS. It can either be dropped entirely or replaced with a short reminder that there are two slightly different textual formats. | [...] partially qualified domain names, which are names where one or more | of the earliest labels in the ordered list are omitted (for example, | "www"). I am not sure the term =E2=80=99earliest label=E2=80=99 is clear enough. Th= e example doesn=E2=80=99t help, since it isn=E2=80=99t clear whether it is the omitte= d labels (my first reading) or a partially qualified name (following my internal definition of the term). HOST NAME Perhaps mention the concrete rules for the labels? Particular since the paragraph already mentions specifically how they have been relaxed later. Also, would be it be worthwhile to mention the use of non-host names as a means to embed additional information in a query, i.e., the whole business of =E2=80=98underscore labels?=E2=80=99 TLD | most of them are also delegation-centric zones Add a reference to the definition of delegation-centric zone in section 6? ALIAS, CANONICAL NAME, and CNAME These three definitions use a bunch of terms that haven=E2=80=99t been defi= ned (or even mentioned) yet. Perhaps they should be moved to section 4? I suppose it is here because of the definition of QNAME, but, well, see there. Also, the definitions of alias and canonical name feel a bit cyclic. PUBLIC SUFFIX Perhaps this should be moved to section 7, given that is talks about registries. Also, the uncommented mention of HTTP cookies was a bit of a =E2=80=98Huh?=E2=80=99 moment. That might deserve an extra sentence. 3. DNS HEADER AND RESPONSE CODES After defining the header, the section suddenly talks about QNAME which isn=E2=80=99t part of the header at all. It concludes with Referral which doesn=E2=80=99t have much to do with the header either. Given that the section also occasionally uses terms from section 4, a proposal would be to rename it into something like "DNS Transactions" and move it to after current section 4. THE THREE MEANINGS OF QNAME Would it be too preposterous for the document to actually introduce these three meanings as actual terms, e.g., define =E2=80=98Original QNAME= =E2=80=99? The definition for =E2=80=99QNAME (effective)=E2=80=99 isn=E2=80=99t quite = clear. Does it mean the =E2=80=98final=E2=80=99 QNAME in a response that doesn=E2=80=99t fully = resolve a CNAME chain? FURTHER IN SECTION 3 | All of the RCODEs are listed at | http://www.iana.org/assignments/dns-parameters, [...] Should this be a reference? In particular, because [IANA_Resource_Registry] is one. A motivation, why those particular RCODEs have been included and not others might be good. The teaser for NXRRSET made me feel dumb for not remembering what it actually is. (As an aside, the whole UPDATE business isn=E2=80=99t mentioned anywhere. T= he term Dynamic DNS in particular might be worth defining.) 4. RESOURCE RECORDS Does the term =E2=80=98resource record=E2=80=99 itself warrant a definition= ? It does have a drive-by introduction in Global DNS, but it=E2=80=99s a bit indirect. RRSET I think it would be better to paraphrase RFC 2181=E2=80=99s definition and = use the precise term =E2=80=98owner name=E2=80=99 here (even though it still ha= sn=E2=80=99t been defined at this point--perhaps pull that up before RRset?) and then point out the somewhat rebellious use of the term =E2=80=99label=E2=80=99 i= n 2181 (and perhaps even the irony that a document entitled =E2=80=98Clarifications to = the DNS Specification=E2=80=99 needs a clarification). MASTER FILE A very common alternative term for master files that may be worth pointing out is =E2=80=98zone files.=E2=80=99 The distinction to a master f= ile as per RFC 1035 may or may not be that a zone file contains the records for a single zone. SOA FIELD NAMES This is an aside, but at various points the document speaks of "an SOA record" (or similar). I have only ever heard SOA used as an acronym and pronounced as =E2=80=98soah.=E2=80=99 Is the pronunciation as =E2=80=98ess = oh ah=E2=80=99 indicated by the use of =E2=80=99an=E2=80=99 indeed common? TTL Here, RFC 2181 seems to swing the other way and provide an overly precise definition. Would anyone really shift the TTL value one bit to the left for wire formatting? I think paraphrasing would be better. Did RFC 2181 introduce the 31 bit thing to deal with the error in RFC 1035 without the need to update it? If so, this might be worth pointing out. Beyond that, RFC 1035 specifically mentions the case of a TTL of zero. Should this case, its consequences, and uses be discussed here? RESOLVER | "The resolver is located on the same machine as the program that requests | the resolver's services, [...]" [...] In practice, the term is usually | referring to some specific type of resolver I think the main difference in practice to that quote from RFC 1034 is that a resolver is often meant as a DNS server that provides the resolution function and whose clients may very well be on different machines. The quote should either be dropped or its conflict with common usage be pointed out specifically. ITERATIVE MODE Further down is a definition for =E2=80=98iterative resolution=E2=80=99 whi= ch provides a more in-depth explanation. Perhaps these two should be merged? PRIMING This comes a bit suddenly. Maybe it should start with a short introduction a la =E2=80=98In order to operate in recursive mode, a resolver needs to know the address of at least one root server.=E2=80=99 ROOT HINTS It sounds like this is the configuration mentioned in =E2=80=98priming.=E2= =80=99 If that is so, that should probably be pointed out. ZONE TRANSFER I think this and all the following related definitions belong in section 6 after the whole concept of zones has been introduced. SECONDARY SERVERS The final sentence might better be included in the normal text. For instance, instead of the second sentence: =E2=80=98Secondary server are discussed initially in [RFC1034] and described in detail in [RFC2182].=E2= =80=99 Ditto for PRIMARY SERVERS STEALTH SERVER and HIDDEN MASTER A stealth server is defined as a secondary server and a hidden master (which should probably be a =E2=80=99hidden primary=E2=80=99 for consistenc= y) as a stealth server which it can=E2=80=99t be on account of being a primary serv= er. FORWARDING | [RFC5625] does not give a specific definition for forwarding, but | describes in detail what features a system that forwards need to | support. s/need/needs/ FORWARDER The quoted text from RFC 2308 defines the forwarder as the upstream server used by a resolver that only forwards queries. This definition runs somewhat counter to the construct=E2=80=99s usual meaning in English w= here a forwarder would be =E2=80=99someone who forwards.=E2=80=99 This is partic= ularly grating after the previous definition of what =E2=80=98forwarding=E2=80=99 = means takes away the argument that it is a forwarder because it relays (=E2=80=98forwar= ds=E2=80=99) my queries. Which is to say, there maybe should be an acknowledgement of this discrepancy. PASSIVE DNS | A mechanism to collect DNS data by storing DNS transactions from name | servers. Some of these systems also collect the DNS queries associated | with the responses. I don=E2=80=99t think it has been defined yet, but the term =E2=80=98transa= ction=E2=80=99 commonly refers to a pair of a query and its response (plus possibly any re-sent queries or responses due to packet loss). With this in mind, the second sentence doesn=E2=80=99t quite make sense. SPLIT DNS This seems to be a play on the term =E2=80=98view=E2=80=99 defined earlier = and should be described in tandem with it. It might be worthwhile pointing out where the two differ. CHILD | "The entity on record that has the delegation of the domain from the | Parent." There is probably a better term than =E2=80=98entity=E2=80=99 which hasn=E2= =80=99t been used anywhere before and is a very generic term. PARENT I=E2=80=99m not sure the quotes from an RFC obsoleted thirty years ago add = any value to the understanding of the term. GLUE RECORDS Given that the definition refers to authoritative data, that term=E2=80=99s definition should perhaps be moved up before this one. IN-BAILIWICK The three definitions here are very confusing. I think what isn=E2=80=99t becoming clear is that the zone origin that the name server is =E2=80=98subordinate (etc., etc.) to=E2=80=99 is that of the parent zone o= f the delegation and that the definitions of the two types switch that subordinate to the child zone=E2=80=99s apex. The latter is mentioned via =E2=80=99owner name of the NS record=E2=80=99 but this should probably be m= ade more clear. Also, on behalf on non-native speakers, a short explanation of the origin of the term would perhaps be nice. AUTHORITATIVE DATA I can=E2=80=99t quite see how the definition from RFC 1034 would allow delegation NS records to be part of the authoritative data, as these records are attached to nodes _below_ the cuts. Even if there is any doubt left, RFC 1034 very clearly calls out that they are NOT, two paragraphs on. Consequently, I also don=E2=80=99t see the ambiguity. It may be worth point= ing out (and perhaps this is the perceived ambiguity) that there is data that is part of a zone but not authoritative, specifically those delegation NS records and all the glue. Of course, there then are DS records but they aren=E2=80=99t mentioned in t= he document at all. WILDCARD Perhaps pull the last sentence up as a consequence of the first: =E2=80=98[RFC1034] defined wildards, but in a way that turned out to be confusing to implementers, so [RFC4592] provides an extended discussion [...]=E2=80=99 It might still be good to mention why exactly they are confu= sing in RFC1034 since that may not be obvious for a casual reader. Further, this could probably be tied together with the definition of asterisk label and wildcard domain name. ASTERISK LABEL I think it would be better to paraphrase this definition since label types (quite rightfully) haven=E2=80=99t been mentioned anywhere yet and the length octet earlier has been introduced as part of the wire-format representation of the label and not the label itself. So, something along the lines of =E2=80=99A single-octet label consisting merely of the A= SCII representation of the =E2=80=9C*=E2=80=9D character. But I am not sure if this term is important enough to warrant an entire entry instead of just mentioning it en passant during the definition of wildcard (domain name). CLOSEST ENCLOSER and following These should probably called out to be only relevant for wildcard processing. (Which makes me think that maybe adding another level of sectioning might be helpful for grouping terms generally.) OCCLUDED NAME Dynamic update has never been introduced and DNAME only mentioned. Without understanding these, the definition is impossible to make sense of. INFRASTRUCTURE DOMAIN The term =E2=80=99domain=E2=80=99 has never been defined. Its use is quite = vague. The quoted RFC 3172 seems to use it as a synonym for TLD. Given that the term =E2=80=99infrastructure domain=E2=80=99 was specifically only created = for arpa, I am not sure it should be a separate item here but rather be mentioned as part of the definition of arpa. SUBORDINATE AND SUPERORDINATE This should probably be way, way up in section 2. Also (continuing from the last point), domain here seems to mean domain name. Or does it? GENERAL DNSSEC I think it would be good to define DNSSEC and mention what it does and, more importantly, what it does not do. There seems to be quite a bit of confusion around that. This could perhaps be done by pulling up section 9 and starting it by that DNSSEC definition. VALIDATION | Validation, in the context of DNSSEC, refers to the following: For clarity: =E2=80=98one of the following=E2=80=99 or =E2=80=98all of the = following=E2=80=99? ZONE SIGNING KEY | Note that the roles KSK and ZSK are not mutually exclusive [...] This note is unnecessary given the following definition of a CSK. HARDWARE SECURITY MODULES | [...] and to create the RRSIG records at periodic intervals. Technically, the HSM only creates the signatures that are part of the RRSIG records. The distinction is important to avoid implying that HSMs are somehow DNS-aware rather than them having only been appropriated for DNSSEC. SIGNING SOFTWARE | Authoritative DNS servers that supports DNSSEC often contains software | [...] support and contain sans the =E2=80=98s=E2=80=99. 9. DNSSEC STATES Given how important these states are and that the consequences of =E2=80=98bogus=E2=80=99 and =E2=80=98insecure=E2=80=99 can easily be miss-i= nterpreted by only looking at the words, I am not sure I like the rather hand wavy tone of this section. One improvement would be to contrast the definitions directly be placing them next to each other for each term. ------ %< ------ Kind regards, Martin