From joe.gersch@secure64.com Tue Oct 2 16:41:48 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4107721F8643 for ; Tue, 2 Oct 2012 16:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZev4CEiOn3I for ; Tue, 2 Oct 2012 16:41:47 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 4139F21F861F for ; Tue, 2 Oct 2012 16:41:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 957F4B861C for ; Tue, 2 Oct 2012 17:41:46 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSdfRbslCpWu; Tue, 2 Oct 2012 17:41:45 -0600 (MDT) Received: from [10.138.15.50] (unknown [192.168.254.4]) by zimbra.secure64.com (Postfix) with ESMTPSA id 95879B85B2 for ; Tue, 2 Oct 2012 17:41:44 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1349221305; bh=N/a8sCw0CoQqjjwgbALldrfK4P4lkBxHsL6RKWikBJM=; h=From:Content-Type:Subject:Date:References:To:Message-Id: Mime-Version; b=kfAFuNm2AeBaBbcUhQBpaRkNWrUYcyowej89v1cC9qj1fqRFz9 noUgzjp08a1DR1CJvXq0AzQJ0B1wxI+vc6X7tfjkxPi4jMrQuZN5jdq+l8LqYUO+aOp aXQyXLP2zUDS2uC2/TwyWL5mmA5frybqtKKAFKypqS23Y0T+qXg/JY= From: Joseph Gersch Content-Type: multipart/signed; boundary="Apple-Mail=_58E218AB-54EB-4F4C-B826-540E206946FD"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 2 Oct 2012 17:41:42 -0600 References: <20121002233322.15962.41423.idtracker@ietfa.amsl.com> To: dnsop@ietf.org Message-Id: <882EA012-EB46-4B6E-99E0-4289BD77E169@secure64.com> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [DNSOP] Fwd: New Version Notification for draft-gersch-dnsop-revdns-cidr-03.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 23:41:48 -0000 --Apple-Mail=_58E218AB-54EB-4F4C-B826-540E206946FD Content-Type: multipart/alternative; boundary="Apple-Mail=_0F3C7F5B-7C53-4D4E-A2A6-E9B15349E0CF" --Apple-Mail=_0F3C7F5B-7C53-4D4E-A2A6-E9B15349E0CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii DNSOP group, We have submitted a 3rd draft of the reverse-DNS naming convention = for CIDR address blocks. The new draft has added material to augment = and clarify issues raised during discussions on the mailing list, at the = IETF and at other meetings, as well as providing a historical context = with RFC's 1101 and 2317. =20 =20 This document was first submitted at the Paris IETF meeting and was = voted as being relevant to the DNSOP working group. We would like to = continue the discussion on the mailing list and also at the upcoming = Atlanta IETF meeting. We appreciate any feedback and comments, and = would like to propose evolving this document from draft status to a = working group document during our discussions in Atlanta. Best regards, - Joe Gersch and Dan Massey=20 =09 Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-gersch-dnsop-revdns-cidr-03.txt > Date: October 2, 2012 5:33:22 PM MDT > To: joe.gersch@secure64.com > Cc: dan@makaalanetworks.com, cathie@cs.colostate.edu, = eosterweil@verisign.com >=20 >=20 > A new version of I-D, draft-gersch-dnsop-revdns-cidr-03.txt > has been successfully submitted by Joe Gersch and posted to the > IETF repository. >=20 > Filename: draft-gersch-dnsop-revdns-cidr > Revision: 03 > Title: Reverse DNS Naming Convention for CIDR Address = Blocks > Creation date: 2012-10-02 > WG ID: Individual Submission > Number of pages: 31 > URL: = http://www.ietf.org/internet-drafts/draft-gersch-dnsop-revdns-cidr-03.txt > Status: = http://datatracker.ietf.org/doc/draft-gersch-dnsop-revdns-cidr > Htmlized: = http://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-gersch-dnsop-revdns-cidr-03 >=20 > Abstract: > This draft proposes a naming convention for encoding CIDR address > blocks into the reverse DNS namespace. The reverse DNS naming = method > is commonly used to specify a complete IP address. This document > describes how to encode an IPv4 or IPv6 CIDR address block such as > 129.82.0.0/16. By defining a common naming convention, one can > associate information with a prefix. The convention builds on past > work in RFC 1101 that associates network names with prefixes. > However, this previous work pre-dated the introduction of CIDR and > has several critical ambiguities. This convention corrects the > ambiguities and enables new applications ranging from routing > information to geolocation. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 --Apple-Mail=_0F3C7F5B-7C53-4D4E-A2A6-E9B15349E0CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii DNSOP = group,

     We have submitted a 3rd draft of = the reverse-DNS naming convention for CIDR address blocks.  The new = draft has added material to augment and clarify issues raised during = discussions on the mailing list, at the IETF and at other meetings, as = well as providing a historical context with RFC's 1101 and 2317. =  
 
     This document was = first submitted at the Paris IETF meeting and was voted as being = relevant to the DNSOP working group.  We would like to continue the = discussion on the mailing list and also at the upcoming Atlanta IETF = meeting.   We appreciate any feedback and comments, and would = like to propose evolving this document from draft status to a working = group document during our discussions in = Atlanta.

Best regards,
   - = Joe Gersch and Dan Massey 

=

Begin forwarded message:

Subject: New Version Notification for = draft-gersch-dnsop-revdns-cidr-03.txt
Date: October 2, 2012 = 5:33:22 PM MDT


A new version of I-D, = draft-gersch-dnsop-revdns-cidr-03.txt
has been successfully submitted = by Joe Gersch and posted to the
IETF = repository.

Filename: = draft-gersch-dnsop-revdns-cidr
Revision: 03
Title: Reverse = DNS Naming Convention for CIDR Address Blocks
Creation date: = 2012-10-02
WG ID: Individual Submission
Number = of pages: 31
URL: =             http://www.ietf.org/internet-drafts/draft-gersch-dnsop-revdns-cid= r-03.txt
Status: =          ht= tp://datatracker.ietf.org/doc/draft-gersch-dnsop-revdns-cidr
Htmliz= ed:        http= ://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-03
Diff: =            http://www.ietf.org/rfcdiff?url2=3Ddraft-gersch-dnsop-revdns-cidr-03

Abstract:
  This draft proposes a naming = convention for encoding CIDR address
  blocks into the = reverse DNS namespace.  The reverse DNS naming method
=   is commonly used to specify a complete IP address. =  This document
  describes how to encode an IPv4 or = IPv6 CIDR address block such as
  129.82.0.0/16.  By = defining a common naming convention, one can
  associate = information with a prefix.  The convention builds on past
=   work in RFC 1101 that associates network names with = prefixes.
  However, this previous work pre-dated the = introduction of CIDR and
  has several critical = ambiguities.  This convention corrects the
=   ambiguities and enables new applications ranging from = routing
  information to = geolocation.




The IETF = Secretariat


= --Apple-Mail=_0F3C7F5B-7C53-4D4E-A2A6-E9B15349E0CF-- --Apple-Mail=_58E218AB-54EB-4F4C-B826-540E206946FD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwOLbTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDExNjExMjQ1M1oXDTEzMDExNjA2MzIwOFowZTEZMBcGA1UEDRMQeGNUczFWNjI3NzhS M1FtZTEgMB4GA1UEAwwXam9lLmdlcnNjaEBzZWN1cmU2NC5jb20xJjAkBgkqhkiG9w0BCQEWF2pv ZS5nZXJzY2hAc2VjdXJlNjQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAySJC Vtd1lVWJkfjw7a/YRt30WoQvBBW0NGzbtrAKwO0TZUkJ44LxFfiWS4tAg1zQc5HIHhH98jXKVwFQ 3dX3EPGg3Kr1wMYlLVjnaZocqWpRFMfE+HgI6ggoUqya3rZUb/wfDndDCgJ4P+0FocAAWWEfrEU4 wHXP2pXQk0h1C8ryS9B61SXZ7Rl7bF7krVsPfIn8nnpOqQ7mGrMJhu3pmRG5U32Hxc4rLKAH/q4q CiIn2LFKiKs4geG7rYGT/ptO+3zvrXlgVWjua58DZ4sPXwjQ+zpTpyfTVbn+LUwHVwnkm7Gw+Uy4 uJhFeuGkjvM5PCS21hsmiqdqoYlZoBVbWQIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSZ5oXQDfnQsADV TOckHXx4mSqRhTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdq b2UuZ2Vyc2NoQHNlY3VyZTY0LmNvbTCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAIlgjMImn2osQlyPbchRP1iBsCXvDzJfilZ/ LgXAJhg/LRzm6uGyvBoz0/sgW+HTeKpcEqDYxMehbUjo0U/RE2gvovRbBWGtH4Wqf2k8Nf0WLyuX 5QTVl0FZDqyTNodfn3twutkmiuNM5qhxbucOA6raxJc+UfoHEjOYSYZ6O6GmGn0eF5NlZsK2+jND kuopFPkLNl2xb+nvhHHI48nqY5FLoBfhhTopyTpkux1t1q0lW8YaufqK/FkMMpdQ4M0fzOCtlzJ5 hMIrLNrv3FQFgyrhImwZPrPOa36zKoSiQJj6mgPFenTJTkvd6p8PxJ7bDKKh5UJsVLeWCBpj7TXV UWwwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgMDi20wCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDAyMjM0MTQyWjAjBgkqhkiG9w0BCQQxFgQUCN8IJphg C7nKNZAIPS2nKs74xAkwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgMDi20wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwOLbTANBgkqhkiG9w0BAQEFAASCAQCy5Wef+qU4VNx3FfMpxj839ekin6mB8TMYA6Qp GY70MXV7SQei/exmsuf/X666DqxDLNPjGMOjNPhYEv4btIZS+hbw5eaMt0HYcuaDhsps7gTUi9Bu 5ur0TxNrzR9LDqDYoFWRvrD262Mjo4ugLsmXdj2XyEVbDCYHuvObEXAtDp2KaYSec3EjQt5/XWcN fm4Kzd3wNZ2o+eT4vgj2kjKKc6qp3hMxR2wbbEBlOiZv3mWjC33jypyB+p9eEEgLI8/Pr57+rFS3 rWl4ykXTuaNYdaJaBZ/pz0woXPNlO8g1iMcqed9m7c71007wEQOabs9TWYKdfWhhjMrV/NBCdH3n AAAAAAAA --Apple-Mail=_58E218AB-54EB-4F4C-B826-540E206946FD-- From rafiee@hpi.uni-potsdam.de Wed Oct 3 10:03:56 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7938F21F85A1 for ; Wed, 3 Oct 2012 10:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgBGEji22PhY for ; Wed, 3 Oct 2012 10:03:56 -0700 (PDT) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id B469521F85C3 for ; Wed, 3 Oct 2012 10:03:55 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id 7975CD2C95 for ; Wed, 3 Oct 2012 19:03:51 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Wed, 3 Oct 2012 19:03:51 +0200 From: "Rafiee, Hosnieh" To: "DNSOP@ietf.org" Date: Wed, 3 Oct 2012 19:03:47 +0200 Thread-Topic: draft-rafiee-cga-tsig-00 - request for comments Thread-Index: Ac2hiQXKnXZ+GspkRJ6N8oLgvD0ccA== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924CD4EAD2F8MXMA1Rhpiuni_" MIME-Version: 1.0 Subject: [DNSOP] draft-rafiee-cga-tsig-00 - request for comments X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 17:03:56 -0000 --_000_EA738325B0580041A50A364F5F76B68924CD4EAD2F8MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have submitted an RFC draft to the follow link: http://www.ietf.org/inter= net-drafts/draft-rafiee-cga-tsig-00.txt. Please take a look at it and share= you comments so that I might improve it. As the DNSEXT will be closing soon, I would like to know whether possible t= o adopt it in this working group. Thanks, Hosnieh Filename: draft-rafiee-cga-tsig Revision: 00 Title: Transaction SIGnature (TSIG) using CGA Algorith= m in IPv6 Creation date: 2012-09-30 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-rafiee-cga-tsig-= 00.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-cga-tsig Htmlized: http://tools.ietf.org/html/draft-rafiee-cga-tsig-00 --_000_EA738325B0580041A50A364F5F76B68924CD4EAD2F8MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I have submitted an RFC draft to the follow= link: http://www.ietf.org/internet-drafts/draft-rafiee-cga-tsig-00.txt. Please take a look at it and share you comments so that I might improve= it.

As the DNSEXT will be closing so= on, I would like to know whether possible to adopt it in this working group= .

 

Thanks,

Hosnieh<= /p>

 

Filena= me:            draf= t-rafiee-cga-tsig

Revision: &nbs= p;            00

Title:     &nb= sp;            =     Transaction SIGnature (TSIG) using CGA Algorithm in IPv= 6

Creation date:   2012-09= -30

WG ID:    &nb= sp;            = Individual Submission

Number of pag= es: 13

URL:    &n= bsp;        http://www.ietf.org/intern= et-drafts/draft-rafiee-cga-tsig-00.txt

Status:          http://datatrack= er.ietf.org/doc/draft-rafiee-cga-tsig

Htmlized:        http://tools.ietf.org/html/dr= aft-rafiee-cga-tsig-00

 

 

 

= --_000_EA738325B0580041A50A364F5F76B68924CD4EAD2F8MXMA1Rhpiuni_-- From fanf2@hermes.cam.ac.uk Mon Oct 8 06:58:19 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683FD21F84F0 for ; Mon, 8 Oct 2012 06:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roZ2KHXHzVv6 for ; Mon, 8 Oct 2012 06:58:18 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id B903721F84C2 for ; Mon, 8 Oct 2012 06:58:18 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:36825) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1TLDqX-0000ZH-YP (Exim 4.72) (return-path ); Mon, 08 Oct 2012 14:58:13 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TLDqX-00059q-Cz (Exim 4.72) (return-path ); Mon, 08 Oct 2012 14:58:13 +0100 Date: Mon, 8 Oct 2012 14:58:13 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John Gilmore In-Reply-To: Message-ID: References: <201210051834.q95IYMk7028421@new.toad.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: David Blacka , pk@DENIC.DE, Paul Wouters , dnsop@ietf.org Subject: Re: [DNSOP] [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 13:58:19 -0000 > On Fri, 5 Oct 2012, John Gilmore wrote: > > > [Sounds like somebody should tell the Patent Office that this > > "invention" is obvious to anyone skilled in the field, before > > those lovely monopolists at Verisign find themselves with yet > > another government-granted monopoly.] > > > > http://domainnamewire.com/2012/10/05/verisign-files-patent-application-for-way-of-transfering-hosting-on-dnssec-domains/ > > > > Verisign files patent application for way of transfering > > hosting on DNSSEC Domains Prior art: http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-01 Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From Ted.Lemon@nominum.com Mon Oct 8 07:13:37 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452D521F84EA for ; Mon, 8 Oct 2012 07:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.472 X-Spam-Level: X-Spam-Status: No, score=-106.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOSIDnd4xyUI for ; Mon, 8 Oct 2012 07:13:36 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5719D21F84D5 for ; Mon, 8 Oct 2012 07:13:36 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUHLfj8jUQeeghXU0oO/PkCNTuJqStLID@postini.com; Mon, 08 Oct 2012 07:13:36 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8901C1B8237 for ; Mon, 8 Oct 2012 07:13:35 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7C5DB19005C; Mon, 8 Oct 2012 07:13:35 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Mon, 8 Oct 2012 07:13:28 -0700 From: Ted Lemon To: Tony Finch Thread-Topic: [DNSOP] [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains Thread-Index: AQHNpVz9sAUgxhbsDkSiWvR2y9zGeJev6MqA Date: Mon, 8 Oct 2012 14:13:28 +0000 Message-ID: References: <201210051834.q95IYMk7028421@new.toad.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , David Blacka , "" , Paul Wouters , John Gilmore Subject: Re: [DNSOP] [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 14:13:37 -0000 On Oct 8, 2012, at 9:58 AM, Tony Finch wrote: > Prior art: > http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-01 Interesting timing: the Verisign patent was filed two weeks after this draf= t was published. From Ray.Bellis@nominet.org.uk Mon Oct 8 07:35:38 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F0021F87DC for ; Mon, 8 Oct 2012 07:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tshAqzIQ4DG1 for ; Mon, 8 Oct 2012 07:35:36 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB1121F87D7 for ; Mon, 8 Oct 2012 07:35:35 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: MIME-Version; b=47ui1m8U6h4PRUk2Ez8aXVEyjXVIK400fe9lYy/olUuwf2+EBuYKV6ME OyBfwPOh8C4WnR/LYM+g7ii5Zp0tkhUXTDkR8rufDfalFx0mighKSXWuS I2YvCEBGLWYUES/; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1349706936; x=1381242936; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[DNSOP]=20[dane]=20FYI:=20Verisign=20fi les=20patent=20application=20for=20way=0D=0A=20of=20trans fering=20hosting=20on=20DNSSEC=20Domains|Date:=20Mon,=208 =20Oct=202012=2014:35:32=20+0000|Message-ID:=20<85626367- 21F0-49F0-85F5-5DAC32F56207@nominet.org.uk>|To:=20Ted=20L emon=20|CC:=20Tony=20Finch=20,=20"dnsop@ietf.org"=20,=20David =20Blacka=0D=0A=09,=20Peter=20Koch =20,=20Paul=20Wouters=0D=0A=09,=20John=20Gilmore=20|MIME-Version:=201.0 |In-Reply-To:=20|References:=20<201210051834.q95IYMk7028421@new. toad.com>=0D=0A=20=0D=0A=20=0D=0A=20; bh=JVK1w5iqBv5UwRTakUgQFM/dp+9iWRFjuSIeiDt0w0M=; b=dg+wfn3paS8k5doWYEgAqdTX8YjPKLBZFBF0u+/uRLe2bfj3nRMw0RHr A30oG65+9lMBRfKlI97TJlLxUxFfTY59OaG6zywvSleEDtqZx9jH9Qq/3 xs6AlqzIgxNPgXd; X-IronPort-AV: E=Sophos;i="4.80,554,1344207600"; d="scan'208,217";a="43732927" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx3.nominet.org.uk with ESMTP; 08 Oct 2012 15:35:34 +0100 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%17]) with mapi; Mon, 8 Oct 2012 15:35:33 +0100 From: Ray Bellis To: Ted Lemon Thread-Topic: [DNSOP] [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains Thread-Index: AQHNpV0ImmaGi0SBCEKgIljsBOSt7pevYq8AgAAGKgA= Date: Mon, 8 Oct 2012 14:35:32 +0000 Message-ID: <85626367-21F0-49F0-85F5-5DAC32F56207@nominet.org.uk> References: <201210051834.q95IYMk7028421@new.toad.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_8562636721F049F085F55DAC32F56207nominetorguk_" MIME-Version: 1.0 Cc: Tony Finch , "dnsop@ietf.org" , John Gilmore , David Blacka , Peter Koch , Paul Wouters Subject: Re: [DNSOP] [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 14:35:38 -0000 --_000_8562636721F049F085F55DAC32F56207nominetorguk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 8 Oct 2012, at 15:13, Ted Lemon > wrote: On Oct 8, 2012, at 9:58 AM, Tony Finch > = wrote: Prior art: http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-01 Interesting timing: the Verisign patent was filed two weeks after this draf= t was published. Also from April 2011: I'm pretty sure that an earlier version of this was presented at the DNSSEC= Deployment Workshop held in Reston in October 2008. Ray --_000_8562636721F049F085F55DAC32F56207nominetorguk_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On 8 Oct 2012, at 15:13= , Ted Lemon <Ted.Lemon@nominum.= com> wrote:

On Oct 8, 2012, at 9:58 AM, Tony Finch <dot@dotat.at> wrote:
Pri= or art:
http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operat= or-change-01

Interesting timing: the Verisign paten= t was filed two weeks after this draft was published.

Also from April 2011:


I'm pretty sure that an earlier version = of this was presented at the DNSSEC Deployment Workshop held in Reston in O= ctober 2008.

Ray

= --_000_8562636721F049F085F55DAC32F56207nominetorguk_-- From sm@resistor.net Mon Oct 8 08:28:34 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1028C21F84F5 for ; Mon, 8 Oct 2012 08:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v79Bnc723nrV for ; Mon, 8 Oct 2012 08:28:33 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1552A21F84F2 for ; Mon, 8 Oct 2012 08:28:33 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q98FMTqj017908; Mon, 8 Oct 2012 08:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1349709765; bh=osZueLvRgMpdE9MNZBnDEIuZgLkX8OkxjDCewHaKoXA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TSr281kKTxWtAAySZ+ea3Sd0U+0oxfXpr1R+HGBzNSSYu3DFX3k1MlVukpDnkMhUD b0hZVtE4UZuiaofMGQHVkmdFOgKGdTt0wvFf88EWki+mAhn7st6oCJRM9eUYbtpl3O zQ7lRppGwl+DsiDlzE4WdhojB1hCbYHBvAOiT9e8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1349709765; i=@resistor.net; bh=osZueLvRgMpdE9MNZBnDEIuZgLkX8OkxjDCewHaKoXA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=y02kbCEiq1U0ZGsqCsCCezLz8Et2bFBgBZM5CdocbxruqqYlqqdLwJwKlp3ojoUZU bl9HhRTjI6S4+iXb9R1Yuudd3i6gkRSiDUW6ctJTvRL84I8ojN1N4Pu3pgqD7WpDAG UpM3xydDzNy7N273XKO7aPfb3Yx/vm15/3xjYz18= Message-Id: <6.2.5.6.2.20121008075852.09f19eb8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 08 Oct 2012 08:08:47 -0700 To: Tony Finch From: SM In-Reply-To: References: <201210051834.q95IYMk7028421@new.toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pk@DENIC.DE, Paul Wouters , dnsop@ietf.org, John Gilmore Subject: Re: [DNSOP] [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 15:28:34 -0000 At 06:58 08-10-2012, Tony Finch wrote: >Prior art: >http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-01 Does this affect draft-ietf-dnsop-rfc4641bis (currently in the RFC Editor queue)? Regards, -sm From ahu@xs.powerdns.com Mon Oct 8 12:53:12 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7EA1F041C for ; Mon, 8 Oct 2012 12:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[AWL=-3.201, BAYES_40=-0.185, FRT_STOCK2=3.988, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUkEwTqKS1TG for ; Mon, 8 Oct 2012 12:53:08 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0A021F87C0 for ; Mon, 8 Oct 2012 12:53:07 -0700 (PDT) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1TLJNw-0007Zo-Co for dnsop@ietf.org; Mon, 08 Oct 2012 21:53:04 +0200 Date: Mon, 8 Oct 2012 21:53:04 +0200 From: bert hubert To: "dnsop@ietf.org" Message-ID: <20121008195304.GB23376@xs.powerdns.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [DNSOP] some implementation notes: binding to all IP addresses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 19:53:12 -0000 Hi, This message is slightly offtopic, but this is the best list for reaching all DNS implementors I think. And I need your help! After ten years of nagging, PowerDNS Authoritative Server implemented 'automatic binding to ALL IPv4 and IPv6 addresses'. We do so using the setsockopt/sendmsg/recvmsg flags that allow for the capturing of the 'real' destination address of a packet received in 0.0.0.0 or ::. In attempting to implement this, we found missing documentation, wrong documentation and odd #defines that are required on some platforms. I've bundled the whole story in a blogpost on http://bert-hubert.blogspot.com/2012/10/on-binding-datagram-udp-sockets-to-any.html My question is: do any of the implementors have anything to add to this page? Especially DNS relevant things. The post is currently short on details for Solaris and Windows. If you have clues, please share! Thanks. -- PowerDNS Website: http://www.powerdns.com/ PowerDNS Community Website: http://wiki.powerdns.com/ PowerDNS is supported and developed by Netherlabs: http://www.netherlabs.nl From paul@cypherpunks.ca Mon Oct 8 13:05:31 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5192521F87E1 for ; Mon, 8 Oct 2012 13:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[AWL=-1.639, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqnA1L7LIvpt for ; Mon, 8 Oct 2012 13:05:30 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id B85EC21F87E0 for ; Mon, 8 Oct 2012 13:05:30 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 4853582B21; Mon, 8 Oct 2012 16:05:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3BC9682A5B; Mon, 8 Oct 2012 16:05:26 -0400 (EDT) Date: Mon, 8 Oct 2012 16:05:26 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: bert hubert In-Reply-To: <20121008195304.GB23376@xs.powerdns.com> Message-ID: References: <20121008195304.GB23376@xs.powerdns.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] some implementation notes: binding to all IP addresses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 20:05:31 -0000 On Mon, 8 Oct 2012, bert hubert wrote: > 'automatic binding to ALL IPv4 and IPv6 addresses'. We do so using the > setsockopt/sendmsg/recvmsg flags that allow for the capturing of the 'real' > destination address of a packet received in 0.0.0.0 or ::. > > In attempting to implement this, we found missing documentation, wrong > documentation and odd #defines that are required on some platforms. > > I've bundled the whole story in a blogpost on > http://bert-hubert.blogspot.com/2012/10/on-binding-datagram-udp-sockets-to-any.html > > My question is: do any of the implementors have anything to add to this > page? Especially DNS relevant things. It seems you implemented pretty much what openswan has been doing for a long time, which was based on work done for freeradius by Miquel van Smoorenburg. http://git.openswan.org/cgi-bin/cgit/openswan/tree/lib/libopenswan/udpfromto.c but perhaps read through the code to compare? Perhaps this code should be put into a library we can all use independantly, as people seem to copy this functionality over and over again. I did not know about __APPLE_USE_RFC_3542, which I've just added to my tree. Thanks for sharing, Paul From fanf2@hermes.cam.ac.uk Mon Oct 8 13:28:03 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B71F21F881D for ; Mon, 8 Oct 2012 13:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACriY6OxxZvj for ; Mon, 8 Oct 2012 13:28:02 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5E321F8814 for ; Mon, 8 Oct 2012 13:28:02 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from host86-148-122-76.range86-148.btcentralplus.com ([86.148.122.76]:58664 helo=[192.168.1.66]) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1TLJvl-0002IA-re (Exim 4.72) (return-path ); Mon, 08 Oct 2012 21:28:01 +0100 References: <201210051834.q95IYMk7028421@new.toad.com> <85626367-21F0-49F0-85F5-5DAC32F56207@nominet.org.uk> In-Reply-To: <85626367-21F0-49F0-85F5-5DAC32F56207@nominet.org.uk> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-A7D6522D-1DD8-44C5-A587-4776A2C896C0 Message-Id: <08452767-B90E-438C-8AEE-7F05E105A290@dotat.at> X-Mailer: iPhone Mail (9B206) From: Tony Finch Date: Mon, 8 Oct 2012 21:27:59 +0100 To: Ray Bellis Sender: Tony Finch Cc: "dnsop@ietf.org" Subject: [DNSOP] how not to do an operator transfer, was Re: [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 20:28:03 -0000 --Apple-Mail-A7D6522D-1DD8-44C5-A587-4776A2C896C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 8 Oct 2012, at 15:35, Ray Bellis wrote: >=20 > That procedure is incorrect: it is missing a wait step between updating the D= S and DNSKEY RRsets and updating the NS RRsets. A validator might fetch data= from the new operator and try (and fail) to validate it against an old cach= ed keys. Tony. -- f.anthony.n.finch http://dotat.at/= --Apple-Mail-A7D6522D-1DD8-44C5-A587-4776A2C896C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 8 Oct 2012, at 15:35, Ra= y Bellis <Ray.Bellis@nominet= .org.uk> wrote:

T= hat procedure is incorrect: it is missing a wait step between updating the D= S and DNSKEY RRsets and updating the NS RRsets. A validator might fetch data= from the new operator and try (and fail) to validate it against an old cach= ed keys.

Tony.
--
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
= --Apple-Mail-A7D6522D-1DD8-44C5-A587-4776A2C896C0-- From fanf2@hermes.cam.ac.uk Mon Oct 8 13:34:15 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61E611E80E6 for ; Mon, 8 Oct 2012 13:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNw8+OTgXAsy for ; Mon, 8 Oct 2012 13:34:15 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id D48FE11E80F0 for ; Mon, 8 Oct 2012 13:34:14 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from host86-148-122-76.range86-148.btcentralplus.com ([86.148.122.76]:58684 helo=[192.168.1.66]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1TLK1l-0006Ck-X3 (Exim 4.72) (return-path ); Mon, 08 Oct 2012 21:34:13 +0100 References: <201210051834.q95IYMk7028421@new.toad.com> <6.2.5.6.2.20121008075852.09f19eb8@resistor.net> In-Reply-To: <6.2.5.6.2.20121008075852.09f19eb8@resistor.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Tony Finch Date: Mon, 8 Oct 2012 21:34:10 +0100 To: SM Sender: Tony Finch Cc: "pk@DENIC.DE" , Paul Wouters , "dnsop@ietf.org" , John Gilmore Subject: Re: [DNSOP] [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 20:34:15 -0000 On 8 Oct 2012, at 16:08, SM wrote: >=20 > Does this affect draft-ietf-dnsop-rfc4641bis (currently in the RFC Editor q= ueue)? It's section on change-of-operator was added in revision -03 dated July 2010= . Sadly it is buggy. http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-03#section-4.3.5 Tony. -- f.anthony.n.finch http://dotat.at/= From marka@isc.org Mon Oct 8 14:58:11 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D69011E80FF for ; Mon, 8 Oct 2012 14:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[AWL=-1.779, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ped3uK3tx+j for ; Mon, 8 Oct 2012 14:58:10 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id BDC3111E80D1 for ; Mon, 8 Oct 2012 14:58:10 -0700 (PDT) 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)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id F1757C948E; Mon, 8 Oct 2012 21:58:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id BB551216C7B; Mon, 8 Oct 2012 21:58:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4E52028EFDC2; Tue, 9 Oct 2012 08:57:59 +1100 (EST) To: Paul Wouters From: Mark Andrews References: <20121008195304.GB23376@xs.powerdns.com> In-reply-to: Your message of "Mon, 08 Oct 2012 16:05:26 EDT." Date: Tue, 09 Oct 2012 08:57:59 +1100 Message-Id: <20121008215759.4E52028EFDC2@drugs.dv.isc.org> Cc: "dnsop@ietf.org" , bert hubert Subject: Re: [DNSOP] some implementation notes: binding to all IP addresses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 21:58:11 -0000 In message , Paul Wouters w rites: > On Mon, 8 Oct 2012, bert hubert wrote: > > > 'automatic binding to ALL IPv4 and IPv6 addresses'. We do so using the > > setsockopt/sendmsg/recvmsg flags that allow for the capturing of the 'real' > > destination address of a packet received in 0.0.0.0 or ::. > > > > In attempting to implement this, we found missing documentation, wrong > > documentation and odd #defines that are required on some platforms. > > > > I've bundled the whole story in a blogpost on > > http://bert-hubert.blogspot.com/2012/10/on-binding-datagram-udp-sockets-to- > any.html > > > > My question is: do any of the implementors have anything to add to this > > page? Especially DNS relevant things. > > It seems you implemented pretty much what openswan has been doing for > a long time, which was based on work done for freeradius by Miquel van > Smoorenburg. > > http://git.openswan.org/cgi-bin/cgit/openswan/tree/lib/libopenswan/udpfromto. > c > > but perhaps read through the code to compare? Perhaps this code should > be put into a library we can all use independantly, as people seem to > copy this functionality over and over again. > > I did not know about __APPLE_USE_RFC_3542, which I've just added to my tree. It tells the compiler which version of the advanced API to use as of Lion from memory. You also have similar magic on Linux as the advanced socket API is not available by default. Named has been using it for years. > Thanks for sharing, > > Paul > _______________________________________________ > 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 jinmei@isc.org Mon Oct 8 23:01:59 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B584021F8833 for ; Mon, 8 Oct 2012 23:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.751 X-Spam-Level: X-Spam-Status: No, score=0.751 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw4YUuVxQSJG for ; Mon, 8 Oct 2012 23:01:59 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 328A921F8831 for ; Mon, 8 Oct 2012 23:01:59 -0700 (PDT) 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)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 603C05F994B; Tue, 9 Oct 2012 06:01:49 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 67F78216C83; Tue, 9 Oct 2012 06:01:47 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Mon, 08 Oct 2012 23:01:46 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bert hubert In-Reply-To: <20121008195304.GB23376@xs.powerdns.com> References: <20121008195304.GB23376@xs.powerdns.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] some implementation notes: binding to all IP addresses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 06:01:59 -0000 At Mon, 8 Oct 2012 21:53:04 +0200, bert hubert wrote: > The post is currently short on details for Solaris and Windows. If you have > clues, please share! As far as I know Windows doesn't support RFC 3542. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From ahu@xs.powerdns.com Tue Oct 9 00:33:32 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F7221F8484 for ; Tue, 9 Oct 2012 00:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=1.601, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJmG5fVC-Fiz for ; Tue, 9 Oct 2012 00:33:31 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6B321F8496 for ; Tue, 9 Oct 2012 00:33:24 -0700 (PDT) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1TLUJX-0002Wi-I8; Tue, 09 Oct 2012 09:33:15 +0200 Date: Tue, 9 Oct 2012 09:33:15 +0200 From: bert hubert To: Mark Andrews Message-ID: <20121009073315.GA8606@xs.powerdns.com> References: <20121008195304.GB23376@xs.powerdns.com> <20121008215759.4E52028EFDC2@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121008215759.4E52028EFDC2@drugs.dv.isc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "dnsop@ietf.org" , Paul Wouters Subject: Re: [DNSOP] some implementation notes: binding to all IP addresses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 07:33:32 -0000 On Tue, Oct 09, 2012 at 08:57:59AM +1100, Mark Andrews wrote: > > I did not know about __APPLE_USE_RFC_3542, which I've just added to my tree. > > It tells the compiler which version of the advanced API to use as > of Lion from memory. You also have similar magic on Linux as the > advanced socket API is not available by default. These days it is, it appears? I did not have to do a #define at least on the platforms I compile on. Paul, the MiquelS sample you mentioned no longer compiles (or at least doesn't work), which is why I decided to do a writeup. I know I did not invent anything, I only wanted to document it all in one place. Regarding RFCs, there is also http://www.ietf.org/rfc/rfc5014.txt which provides an API for selecting temporary IPv6 addresses etc, this might be interesting for resolvers. Regarding Windows, it has been noted here that they don't implement RFC 3542, but they do have IP_PKTINFO since Windows 2003 it appears: http://msdn.microsoft.com/en-us/library/windows/desktop/hh285668(v=vs.85).aspx Regarding Solaris, I find that 'recent versions' do have IP_PKTINFO. I also see people mention that it supports RFC 3542, but have not checked. If anyone can confirm that it works well in production, please let me know and I'll update the blog post. Thanks! > > Named has been using it for years. > > > Thanks for sharing, > > > > Paul > > _______________________________________________ > > 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 rafiee@hpi.uni-potsdam.de Tue Oct 9 04:13:42 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB1921F84F0; Tue, 9 Oct 2012 04:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNGaPDApEs1w; Tue, 9 Oct 2012 04:13:41 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id F349F21F84F1; Tue, 9 Oct 2012 04:13:38 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 6B774169E7B; Tue, 9 Oct 2012 13:13:33 +0200 (CEST) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Tue, 9 Oct 2012 13:13:33 +0200 From: "Rafiee, Hosnieh" To: "dnsext@ietf.org" Date: Tue, 9 Oct 2012 13:13:32 +0200 Thread-Topic: [dnsext] draft-rafiee-cga-tsig-00 - call for more comments Thread-Index: Ac2lkN6YCNqEW9kdTEm8XD7GV2kI9AAfe1VA Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "DNSOP@ietf.org" , "Int-area@ietf.org" , "v6ops@ietf.org" , "ipv6@ietf.org" , "saag@ietf.org" Subject: Re: [DNSOP] [dnsext] draft-rafiee-cga-tsig-00 - call for more comments X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 11:13:42 -0000 More ideas and comments would be greatly apprecitated as I want to upload a= new version of my draft RFC in which I will incorporate applicable comment= s. -----Original Message----- From: Rafiee, Hosnieh=20 Sent: Thursday, October 04, 2012 9:28 AM To: 'Mark Andrews' Cc: dnsext@ietf.org Subject: RE: [dnsext] draft-rafiee-cga-tsig-00 - request for comments Thank you, I will change it and move the whole CGA-TSIG DATA inside the Other DATA. -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 Sent: Thursday, October 04, 2012 9:15 AM To: Rafiee, Hosnieh Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments In message , "Rafiee, Hosnieh" writes: > Hello Mark, > Thank you for your comment. Yes can be,=3D20 But the reason is the TSIG= =20 > parsers need to be adapted with this new algori=3D thm and it is not=20 > different whether to put it in Other DATA or after Other =3D DATA field.= =20 > Because Other Data has variable length too like the CGA-TSIG DA=3D TA. > If I missed something please advise. It is different. Examine the behaviour of CGA-TSIG client talking to a non= CGA-TSIG aware server. The response to using a unknown algorithm should b= e BADKEY not FORMERR because the server couldn't parse the TSIG record. Mark > Thank you. > Hosnieh > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org]=3D20 > Sent: Thursday, October 04, 2012 8:45 AM > To: Rafiee, Hosnieh > Cc: dnsext@ietf.org > Subject: Re: [dnsext] draft-rafiee-cga-tsig-00 - request for comments >=20 >=20 > Why are the CGA parameters not part of other data? That field was=20 > added to=3D TSIG to hold stuff similar to CGA parameters. By making it= =20 > a seperate fie=3D ld you break all existing TSIG parsers. The CGA=20 > parameters could just be d=3D efined to be the initial part of other data= . >=20 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Antoin.Verschuren@sidn.nl Tue Oct 9 08:13:39 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220F121F85F4 for ; Tue, 9 Oct 2012 08:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8NZJQTW-UTW for ; Tue, 9 Oct 2012 08:13:33 -0700 (PDT) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0010421F85B8 for ; Tue, 9 Oct 2012 08:13:32 -0700 (PDT) Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by arn2-kamx.sidn.nl with ESMTP id q99FDVsd013572-q99FDVsf013572 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Tue, 9 Oct 2012 17:13:31 +0200 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn01.SIDN.local (192.168.2.73) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 9 Oct 2012 17:13:30 +0200 Received: from [94.198.156.18] (94.198.156.18) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 9 Oct 2012 17:13:30 +0200 Message-ID: <50743F1A.5010506@sidn.nl> Date: Tue, 9 Oct 2012 17:13:30 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: References: <201210051834.q95IYMk7028421@new.toad.com> <6.2.5.6.2.20121008075852.09f19eb8@resistor.net> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.156.18] Subject: Re: [DNSOP] [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:13:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08-10-12 22:34, Tony Finch wrote: > On 8 Oct 2012, at 16:08, SM wrote: >> >> Does this affect draft-ietf-dnsop-rfc4641bis (currently in the >> RFC Editor queue)? > > It's section on change-of-operator was added in revision -03 dated > July 2010. Sadly it is buggy. > > http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-03#section-4.3.5 I > discovered the issue after a DNSSEC workshop by NLNetLabs for SIDN in 2008, and published about it's remedy internally and on mailinglists and tried to get a chapter about it in 4641bis. The first public presentation was made By Olafur in Amsterdam during the OARC workshop: https://www.dns-oarc.net/files/workshop-200905/gudmundsson.pdf to get consencus. So enough prior art. Question is more if we need action and if so what. I don't have any knowledge about the US patent system, or any patent system as a matter of fact. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQdD8JAAoJEDqHrM883AgnCEkH/3m9E1173xk+17nXQa8fVuDE tEe77peJH5nDWiH2fmacX4ogbUWjq1B7j3EXojydZDxjf//ESL99f7Yuc25tCtCX iMo7ldL5cuxOrW88ncnf0/VfhDb+xTUGDI4Wad9fO8g4Hbk/SG5ZJD+jH/Sa+U5E BLOeGSyQG5AIkqJy+tuC+2tXIZqDjSXcFAGRcpnWmHKdcRS+xYCQZPzHgiMeSQvX tyCCRRc77v/IVkFvDjlnJBHE7YULzSgwSVCjHVTGS5grGGMjVMsajIVAAhKImb86 m/IHWHfo+l31YlAyDFdRYrA3GNT0b7MUQae3Evu64vMRVdaVCI74AKk8gHk8/JU= =WzFn -----END PGP SIGNATURE----- From christopher.morrow@gmail.com Tue Oct 9 08:27:25 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB9621F8530 for ; Tue, 9 Oct 2012 08:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rD-A5tNSlgwv for ; Tue, 9 Oct 2012 08:27:25 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC35221F8495 for ; Tue, 9 Oct 2012 08:27:24 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so7642943vcb.31 for ; Tue, 09 Oct 2012 08:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=62Dq9PLg6i65eXjsyeThqSTsViYmGjJGWYx6/hiLVFo=; b=0LjDCIcZky/EXEqaxdyEcKqTm2qmEJraO9ApBuqwfRueEIBGaanHkUNm7ZoS9SBYuP VGSB2naDlCf0bNCuLfVbU7kHNRKYOZhn2wjbvHG3+F0L4RDHGKSO/lwoZD5rGnqiG/zJ m4FnH160ng+Lo9RO3uJEJhPKwAB10PFOS7rYbqOScW0CQ1fNMZMiPJivUNyBYgBxORMa gIwm+p2aRbDjd0jDQLLyW6P6ZgUiAFHobt/nRBdLNXkrUHYgDYsKL6Wl7+kW7uvdfqVi 9Vtt587yD9/gqSsJyz9mlIaaU7dJYSW295OaeFGhLjt9uAWhu9JEYkOz60/VKs/J2Tzp U2tQ== MIME-Version: 1.0 Received: by 10.52.180.40 with SMTP id dl8mr5730722vdc.51.1349796444211; Tue, 09 Oct 2012 08:27:24 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.58.216.42 with HTTP; Tue, 9 Oct 2012 08:27:24 -0700 (PDT) In-Reply-To: <50743F1A.5010506@sidn.nl> References: <201210051834.q95IYMk7028421@new.toad.com> <6.2.5.6.2.20121008075852.09f19eb8@resistor.net> <50743F1A.5010506@sidn.nl> Date: Tue, 9 Oct 2012 11:27:24 -0400 X-Google-Sender-Auth: UFWa5F7eUQ3W7lFn9RTMhhICevg Message-ID: From: Christopher Morrow To: Antoin Verschuren Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsop@ietf.org Subject: Re: [DNSOP] [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:27:25 -0000 On Tue, Oct 9, 2012 at 11:13 AM, Antoin Verschuren wrote: > So enough prior art. > Question is more if we need action and if so what. > I don't have any knowledge about the US patent system, or any patent > system as a matter of fact. perhaps the questions to ask are: 1) does it hurt the filing entity to file a claim? (verisign in this case) 2) does it hurt people using the 'prior art' today? (ietf users of the technology I suppose) 3) what remediation is verisign expecting today (or ever)? 4) what's the cost to fight the claim? I think for 1 there's very little cost (none maybe), so the rest don't really matter... file all the patent applications!! (there's a meme about this...) From marka@isc.org Tue Oct 9 18:56:31 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3069921F86C3 for ; Tue, 9 Oct 2012 18:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GIlnTPcyz8p for ; Tue, 9 Oct 2012 18:56:30 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id ADB6621F86C2 for ; Tue, 9 Oct 2012 18:56:30 -0700 (PDT) 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)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 94D045F9957 for ; Wed, 10 Oct 2012 01:56:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B2770216C84 for ; Wed, 10 Oct 2012 01:56:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D1337298EFCC for ; Wed, 10 Oct 2012 12:56:18 +1100 (EST) To: dnsop@ietf.org From: Mark Andrews Date: Wed, 10 Oct 2012 12:56:18 +1100 Message-Id: <20121010015618.D1337298EFCC@drugs.dv.isc.org> Subject: [DNSOP] draft-andrews-dnsop-rfc6598-rfc6303 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 01:56:31 -0000 Please review draft-andrews-dnsop-rfc6598-rfc6303 Abstract [RFC6598] specified that: "reverse DNS queries for 100.64/10 MUST NOT be forwarded to the global DNS infrastructure". This document formally requests that IANA add the associated zones to the "Locally-Served DNS Zones" to prevent such queries accidently leaking to the global DNS infrastructure. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From wmaton@ottix.net Wed Oct 10 05:23:37 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00DB21F84A2 for ; Wed, 10 Oct 2012 05:23:37 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDXbj4Xz4e2F for ; Wed, 10 Oct 2012 05:23:37 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) by ietfa.amsl.com (Postfix) with ESMTP id 23E5221F849C for ; Wed, 10 Oct 2012 05:23:37 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.5/8.14.5) with ESMTP id q9ACNTaB013353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Oct 2012 08:23:30 -0400 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.5/8.14.3/Submit) with ESMTP id q9ACNTZ3013349 for ; Wed, 10 Oct 2012 08:23:29 -0400 Date: Wed, 10 Oct 2012 08:23:29 -0400 (EDT) From: "William F. Maton Sotomayor" To: dnsop@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [DNSOP] draft-andrews-dnsop-rfc6598-rfc6303 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 12:23:37 -0000 > Please review draft-andrews-dnsop-rfc6598-rfc6303 I've read this draft and would support it, in lieu of the omniscient- darft should that not proceed any further. (I expect that if omniscient- went through then the registry in 6303 would become deprecated or adapted for another purpose not yet foreseen.) wfms From joe.abley@icann.org Wed Oct 10 06:39:55 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0229121F8582 for ; Wed, 10 Oct 2012 06:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpEs2jkMsaVI for ; Wed, 10 Oct 2012 06:39:54 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3EC21F8568 for ; Wed, 10 Oct 2012 06:39:54 -0700 (PDT) Received: from [199.212.90.45] (199.212.90.45) by smtpx.exc.icann.org (64.78.22.244) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 10 Oct 2012 06:39:53 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_7066ECD8-39F4-4A15-B378-594C813ECAC4"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: <20121010015618.D1337298EFCC@drugs.dv.isc.org> Date: Wed, 10 Oct 2012 09:39:51 -0400 Message-ID: References: <20121010015618.D1337298EFCC@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1499) Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] draft-andrews-dnsop-rfc6598-rfc6303 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 13:39:55 -0000 --Apple-Mail=_7066ECD8-39F4-4A15-B378-594C813ECAC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012-10-09, at 21:56, Mark Andrews wrote: > Please review draft-andrews-dnsop-rfc6598-rfc6303 OK! The idea is good. Reverse queries for addresses in 100.64.0.0/10 have = been observed in the wild. I agree that this document should proceed. RFC 6303 did not specify the requirements for updating the IPv4 = Locally-Served DNS Zone Registry, but I see the registry is marked "IETF = Review" at the IANA, which seems compatible with an Informational = document. > Abstract >=20 > [RFC6598] specified that: "reverse DNS queries for 100.64/10 MUST = NOT > be forwarded to the global DNS infrastructure". I seem to think that references are not allowed in abstract text. Spell = out 100.64.0.0/10, since 100.64 is ambiguous (it's 100.0.0.64 according = to BSD libc, for example). > This document formally requests that IANA add the associated zones = to > the "Locally-Served DNS Zones" to prevent such queries accidently > leaking to the global DNS infrastructure. The word "registry" is missing. The registry is actually called "IPv4 = Locally-Served DNS Zone Registry" (see = ). > 1. Introduction >=20 > This is a formal request to add the reverse zones for the address > space allocated in RFC6598 to the "IPv4 Locally-Served DNS Zone" > registry estabilished by [RFC6303]. By the time this document is processed by the IANA it will be an = RFC-to-be, and hence it's giving direction rather than making a request = (formal or otherwise). You're also missing the direction from 6598 that = you mentioned in the abstract. I suggest replacing this paragraph with: '[RFC6598] specified that "reverse DNS queries for 100.64/10 MUST NOT be = forwarded to the global DNS infrastructure". [RFC6303] provides guidance = on handling such queries. 'This document directs the IANA to add the IPv4 reverse zones = corresponding to 100.64.0.0/10, a netblock reserved in [RFC6598], to the = IPv4 Locally-Served DNS Zone Registry established in [RFC6303].' > 2. Changes to Locally-Served DNS Zones >=20 > To add the following zone listed in RFC6598 Zones (Section 2.1) to > the "IPv4 Locally-Served DNS Zone" registry. >=20 > 2.1. RFC6598 Zones I suggesting moving all of the content of section 2 to the IANA = Considerations section. > 3. IANA Considerations >=20 > This document recommends that IANA the zones listed in RFC6598 = Zones > to the "IPv4 Locally-Served DNS Zone" registry. See above. This placeholder text can be replaced with the actual = direction. > 4. Security Considerations >=20 > As with any other Locally-Served DNS zone, reverse lookups of = RFC6598 > zones will require non-default configuration to return anything = other > than NXDOMAIN. This is a weird sentence. I would replace it with "This document is = thought to present no additional security risks to the Internet." You'll need an Acknowledgements section. Joe= --Apple-Mail=_7066ECD8-39F4-4A15-B378-594C813ECAC4 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINwTCCBsIw ggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyB n+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cx SIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPt P77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2 zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYI KwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9 bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJl cG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAA dABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAg AGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMA UAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABB AGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkA dAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBp AG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUH AQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNV HSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQq tbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F 2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqg qKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMr lSBOKs+WYHr4LIDwlVLOKZaBYjCCBvcwggXfoAMCAQICEAPfgdmmiPyfC1aLEU/4udowDQYJKoZI hvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMB4XDTEy MDQxMDAwMDAwMFoXDTE1MDMyNzEyMDAwMFowgaYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRcwFQYDVQQHEw5NYXJpbmEgZGVsIFJleTE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9y YXRpb24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZCBOdW1iZXJzMRcwFQYDVQQLEw5ETlMgT3BlcmF0 aW9uczESMBAGA1UEAxMJSm9lIEFibGV5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA x4LpgTuNwYrQ6up4l/bQszwAXqpPpYaiWFSBo8p9sFJM1gRtT33Yv+IRpi+2eHpyJTdd/ECCGTL3 7ig/SBpgvCquV/wLW0go48x7ZSUa0QNgCEnpAFGOmDpYietFYZIMwTUmLNqTksB9VjMRb7i7IOp7 aYidL6gPkIEOPaB2NggiypmiePfHXZ5Fiy2wrcZ6LpDm/f+me5XfWc31MrgwV9/2sWTAa7vBPCd+ 576spsXAL6LepBy0q69rzyPBtF02ve+ZYpWwRu018JZqE/N1rdW7BWKjzL2c45s0KmwIN1QCxMbp 5ldbdtd9UELWI/475mnR5iIhIJuNwp+s9DsrnQIDAQABo4IDYjCCA14wHwYDVR0jBBgwFoAUFQAS KxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFPfglsX6YK0WUka9fWfEx78ZEbLGMB4GA1UdEQQX MBWBE2pvZS5hYmxleUBpY2Fubi5vcmcwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjB9BgNVHR8EdjB0MDigNqA0hjJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDA4oDagNIYyaHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwggHFBgNVHSAEggG8MIIBuDCCAbQGCmCGSAGG/WwE AQIwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9z aXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMHcGCCsGAQUFBwEBBGswaTAkBggrBgEFBQcwAYYY aHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEEGCCsGAQUFBzAChjVodHRwOi8vY2FjZXJ0cy5kaWdp Y2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBQUAA4IBAQAiQol79jbbcuM4zgC/3QpxLvGBEl5HQQfcGVGi3I/KWPMHxUOcKhoit0fATvuB nb/qLCfvOLYzKavBs3XiB8oK57NDJTtxxOt2JBoWIoP/FDdeFcxrRZoUaKYSCopWvxHZKHqIsXhR N2ePtxklW84yQws3hm+9I87IEUAzgOjTQWYflZyw5S8eWoaEhF2M1qVbHhurkk082rxZCopADsV2 H++UYkYNEy26ublCOVFFuyfYYUbxOwUmhM74UM8iyScS3+qeCw52DE9bTArQ9fjfMYKo6nCTRxWL sOxpYiJdCsKWWDPvHvSCBYDuASiIOIA+wJrBanYwt0wpK/+OaREFMYIDEDCCAwwCAQEwdjBiMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTECEAPfgdmmiPyfC1aLEU/4udow CQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTIxMDEwMTMzOTUyWjAjBgkqhkiG9w0BCQQxFgQUmZLyU0jIYNb1Ilykxh2IoS7EZBswgYUGCSsG AQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UE CxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD 34HZpoj8nwtWixFP+LnaMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGln aUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD34HZpoj8nwtWixFP+LnaMA0GCSqGSIb3DQEBAQUABIIB ACj+NP7JzrPQjsGEvkatoLijy8m18UYt4dSMIR1DGx39FDfRY8qvnT2Hp6/ui+7CiwgBkj088txO QOckjYaGxuOe5BseTg0qk3HxIW+KxEvDMVE9sPEde9MygV8E+micufU0lIeQn+KcsurXFPljEacK mxXWFo0rpiOmByxOJ45H4FWxD1JwEh7nIE2cIWZ+Thu53duVsKNdgc3ptOmJwH47GI/J6mSM75qj cE5hiV2sWgu/qIWU1HRh2H7Y+OS4cOJr/SF4eGlgBw3P8d8aGr2VwhBd7UeN8/p5DbzPuPi+x90y m3saVX0PLiXfv1SzPqujMO62E9NJuHI89icd6rcAAAAAAAA= --Apple-Mail=_7066ECD8-39F4-4A15-B378-594C813ECAC4-- From joe.abley@icann.org Wed Oct 10 06:42:35 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A74321F8582 for ; Wed, 10 Oct 2012 06:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVxsu692dM4F for ; Wed, 10 Oct 2012 06:42:34 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id A6BC321F8568 for ; Wed, 10 Oct 2012 06:42:34 -0700 (PDT) Received: from [199.212.90.45] (199.212.90.45) by smtpx.exc.icann.org (64.78.22.244) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 10 Oct 2012 06:42:34 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_0F7879DD-76F8-42CA-9FBB-5A2E25776942"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: Date: Wed, 10 Oct 2012 09:42:32 -0400 Message-ID: References: To: "William F. Maton Sotomayor" X-Mailer: Apple Mail (2.1499) Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] draft-andrews-dnsop-rfc6598-rfc6303 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 13:42:35 -0000 --Apple-Mail=_0F7879DD-76F8-42CA-9FBB-5A2E25776942 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012-10-10, at 08:23, "William F. Maton Sotomayor" = wrote: >=20 >> Please review draft-andrews-dnsop-rfc6598-rfc6303 >=20 > I've read this draft and would support it, in lieu of the omniscient-=20= > darft should that not proceed any further. I don't understand the logic in the sentence above. > (I expect that if omniscient-=20 > went through then the registry in 6303 would become deprecated or = adapted=20 > for another purpose not yet foreseen.) I don't expect that would happen. I think it's sensible to specify both that (a) these zones should be = served locally, and (b) because we expect not everybody to follow that = advice, for corresponding queries to be soaked up in AS112-like = infrastructure. Joe= --Apple-Mail=_0F7879DD-76F8-42CA-9FBB-5A2E25776942 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINwTCCBsIw ggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyB n+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cx SIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPt P77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2 zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYI KwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9 bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJl cG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAA dABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAg AGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMA UAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABB AGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkA dAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBp AG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUH AQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRB c3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNl cnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNV HSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQq tbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F 2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqg qKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMr lSBOKs+WYHr4LIDwlVLOKZaBYjCCBvcwggXfoAMCAQICEAPfgdmmiPyfC1aLEU/4udowDQYJKoZI hvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMB4XDTEy MDQxMDAwMDAwMFoXDTE1MDMyNzEyMDAwMFowgaYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxp Zm9ybmlhMRcwFQYDVQQHEw5NYXJpbmEgZGVsIFJleTE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9y YXRpb24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZCBOdW1iZXJzMRcwFQYDVQQLEw5ETlMgT3BlcmF0 aW9uczESMBAGA1UEAxMJSm9lIEFibGV5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA x4LpgTuNwYrQ6up4l/bQszwAXqpPpYaiWFSBo8p9sFJM1gRtT33Yv+IRpi+2eHpyJTdd/ECCGTL3 7ig/SBpgvCquV/wLW0go48x7ZSUa0QNgCEnpAFGOmDpYietFYZIMwTUmLNqTksB9VjMRb7i7IOp7 aYidL6gPkIEOPaB2NggiypmiePfHXZ5Fiy2wrcZ6LpDm/f+me5XfWc31MrgwV9/2sWTAa7vBPCd+ 576spsXAL6LepBy0q69rzyPBtF02ve+ZYpWwRu018JZqE/N1rdW7BWKjzL2c45s0KmwIN1QCxMbp 5ldbdtd9UELWI/475mnR5iIhIJuNwp+s9DsrnQIDAQABo4IDYjCCA14wHwYDVR0jBBgwFoAUFQAS KxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFPfglsX6YK0WUka9fWfEx78ZEbLGMB4GA1UdEQQX MBWBE2pvZS5hYmxleUBpY2Fubi5vcmcwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjB9BgNVHR8EdjB0MDigNqA0hjJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDA4oDagNIYyaHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwggHFBgNVHSAEggG8MIIBuDCCAbQGCmCGSAGG/WwE AQIwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9z aXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMHcGCCsGAQUFBwEBBGswaTAkBggrBgEFBQcwAYYY aHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEEGCCsGAQUFBzAChjVodHRwOi8vY2FjZXJ0cy5kaWdp Y2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBQUAA4IBAQAiQol79jbbcuM4zgC/3QpxLvGBEl5HQQfcGVGi3I/KWPMHxUOcKhoit0fATvuB nb/qLCfvOLYzKavBs3XiB8oK57NDJTtxxOt2JBoWIoP/FDdeFcxrRZoUaKYSCopWvxHZKHqIsXhR N2ePtxklW84yQws3hm+9I87IEUAzgOjTQWYflZyw5S8eWoaEhF2M1qVbHhurkk082rxZCopADsV2 H++UYkYNEy26ublCOVFFuyfYYUbxOwUmhM74UM8iyScS3+qeCw52DE9bTArQ9fjfMYKo6nCTRxWL sOxpYiJdCsKWWDPvHvSCBYDuASiIOIA+wJrBanYwt0wpK/+OaREFMYIDEDCCAwwCAQEwdjBiMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENBLTECEAPfgdmmiPyfC1aLEU/4udow CQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTIxMDEwMTM0MjMzWjAjBgkqhkiG9w0BCQQxFgQUgVak1BxNWeeYa5Aqz4XWjzuThlEwgYUGCSsG AQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UE CxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD 34HZpoj8nwtWixFP+LnaMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGln aUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAD34HZpoj8nwtWixFP+LnaMA0GCSqGSIb3DQEBAQUABIIB ABevw6VFoU40rK5MvI//W0M+pPjVRF0d3N3czx+ysSL17yCYlqRz1dKTSEUWESQ12ESH87GHc04N otHyZFpYIqPOlnOesh4ugj23YzA7F2RMdHLr7uOkDZXG+OUvNrYYiXWhoeiKEXUzJV+JTS5eU9EI tdOWWi8BjqzqX+HujxK16MHg3HCMfO262DCs8pSq4v6O9sYQzDslXKindW+rFJdGelIxY1/0KlnU XM+LpE44vhiYsaFdp5iAPxa/TdbOVZJkEugb2tBFgQE+CzadT68o37khHsQ/E7xaSaM3BXlGYzFN CW24/BKZ90K+9hoWytI4Y/YLmNTVf7v3kxyAvYAAAAAAAAA= --Apple-Mail=_0F7879DD-76F8-42CA-9FBB-5A2E25776942-- From wmaton@ottix.net Wed Oct 10 07:00:40 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF8C21F865F for ; Wed, 10 Oct 2012 07:00:40 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJRVogRptjMC for ; Wed, 10 Oct 2012 07:00:40 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) by ietfa.amsl.com (Postfix) with ESMTP id 36F6021F8647 for ; Wed, 10 Oct 2012 07:00:38 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.5/8.14.5) with ESMTP id q9AE0Dtj025377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2012 10:00:13 -0400 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.5/8.14.3/Submit) with ESMTP id q9AE0Cbe025374; Wed, 10 Oct 2012 10:00:12 -0400 Date: Wed, 10 Oct 2012 10:00:12 -0400 (EDT) From: "William F. Maton Sotomayor" To: Joe Abley In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] draft-andrews-dnsop-rfc6598-rfc6303 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 14:00:40 -0000 On Wed, 10 Oct 2012, Joe Abley wrote: > > On 2012-10-10, at 08:23, "William F. Maton Sotomayor" wrote: > >> >>> Please review draft-andrews-dnsop-rfc6598-rfc6303 >> >> I've read this draft and would support it, in lieu of the omniscient- >> darft should that not proceed any further. > > I don't understand the logic in the sentence above. That my young friend is called a senior moment! :) >> (I expect that if omniscient- >> went through then the registry in 6303 would become deprecated or adapted >> for another purpose not yet foreseen.) > > I don't expect that would happen. > > I think it's sensible to specify both that (a) these zones should be >served locally, and (b) because we expect not everybody to follow that >advice, for corresponding queries to be soaked up in AS112-like >infrastructure. +1 wfms From marka@isc.org Wed Oct 10 15:39:04 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D05711E808D for ; Wed, 10 Oct 2012 15:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E50KSyHX9uDo for ; Wed, 10 Oct 2012 15:39:04 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id CBBDF11E808A for ; Wed, 10 Oct 2012 15:39:03 -0700 (PDT) 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)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id B19F65F9960; Wed, 10 Oct 2012 22:38:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DDB45216C7B; Wed, 10 Oct 2012 22:38:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 3C74B2994D32; Thu, 11 Oct 2012 09:38:49 +1100 (EST) To: Joe Abley From: Mark Andrews References: <20121010015618.D1337298EFCC@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 10 Oct 2012 09:39:51 EDT." Date: Thu, 11 Oct 2012 09:38:49 +1100 Message-Id: <20121010223849.3C74B2994D32@drugs.dv.isc.org> Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] draft-andrews-dnsop-rfc6598-rfc6303 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 22:39:04 -0000 In message , Joe Abley writes: > > > On 2012-10-09, at 21:56, Mark Andrews wrote: > > > Please review draft-andrews-dnsop-rfc6598-rfc6303 > > OK! > > The idea is good. Reverse queries for addresses in 100.64.0.0/10 have = > been observed in the wild. I agree that this document should proceed. > > RFC 6303 did not specify the requirements for updating the IPv4 = > Locally-Served DNS Zone Registry, but I see the registry is marked "IETF = > Review" at the IANA, which seems compatible with an Informational = > document. Actually it did, see IANA Considerations. -01 posted and thanks Joe. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sa.morris7@googlemail.com Fri Oct 12 07:32:32 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E38521F85B4 for ; Fri, 12 Oct 2012 07:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blQMcFwzyEs8 for ; Fri, 12 Oct 2012 07:32:31 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B15521F8617 for ; Fri, 12 Oct 2012 07:32:31 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so1541532bkc.31 for ; Fri, 12 Oct 2012 07:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=Oz1GlpKsJePBa1SoHC17KOVgy4bMCxmuR3iApcVhXCs=; b=ddGscv83q4UMfIWoVho6Ad/EOdO0Z+DEv9n657a+zUrWKj3VtcvLdk7SECWpHstKJl ZXiVrJKK7JO8HBOf0esk2IJEgMxKv3hbPkSUPX/XJRSIBBMJgCLQZMsSCvp3i0yJf2yp kiCnyONdQEyPqc1Fz4wMC9QT6OoffCtEXwE48leVSklJunFP9HQ6hIGF3UshORdhHm2E 9v2U3g0Hzd4Wyk13WD7CaD9Zs8/kvOGiWKcbjKdkJK1aqxIEDv8hKTVjsFNPyrqx6RWC BHXgHcryHkf3KVbetBigI5VTHeUBubuWZz6nsAFIPFkk08UGkp/DIB90mo+LUWPkM3V1 FUnw== Received: by 10.204.155.133 with SMTP id s5mr1467513bkw.112.1350052350235; Fri, 12 Oct 2012 07:32:30 -0700 (PDT) Received: from [192.168.1.102] ([217.155.47.50]) by mx.google.com with ESMTPS id r15sm5940063bkw.9.2012.10.12.07.32.21 (version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 07:32:26 -0700 (PDT) Message-ID: <507829F4.4040307@googlemail.com> Date: Fri, 12 Oct 2012 15:32:20 +0100 From: Stephen Morris User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: dnsop@ietf.org X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [DNSOP] No meeting in Atlanta [Re: Whether to meet at IETF-85 in Atlanta] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:32:32 -0000 On 24/09/12 14:18, Stephen Morris wrote: > We'd like to make a final decision no later than 12:00 UTC Tuesday > 2 October, so please help by posting your thoughts to the list > before then. The bulk of discussion on the list since the last meeting has been: * Comments on the key timing last call * Discussion on 4641bis and DPS framework documents An evaluation of the last call comments on key timing is pending. 4641bis and DPS framework are both with the IESG, and we will post a report on their progress to the list. Although we held on beyond 2 October before making a final decision, there was no response to our original email and little discussion beyond the topics above. Your chairs reached the conclusion that there was little demand for a face to face meeting, therefore decided to cancel the slot we had provisionally secured. Stephen and Peter From joe.gersch@secure64.com Fri Oct 12 08:20:33 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1979E21F8685 for ; Fri, 12 Oct 2012 08:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kg8mNe-4ata1 for ; Fri, 12 Oct 2012 08:20:27 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id A562C21F85B4 for ; Fri, 12 Oct 2012 08:20:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id CB923B85DA; Fri, 12 Oct 2012 09:20:26 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmTcJ8k-vkMN; Fri, 12 Oct 2012 09:20:26 -0600 (MDT) Received: from [10.138.15.10] (unknown [192.168.254.4]) by zimbra.secure64.com (Postfix) with ESMTPSA id 5D411B8563; Fri, 12 Oct 2012 09:20:25 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1350055226; bh=d/vGc0eZgX18qlh+f48+8FJe65E+TCK+GV3T4ddoscw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=wXyHb16uhKOAQIZqjeFn0LyU84GcIqEdZqNRLi GOvcVXtopl4efvgg5fu4yoLUo2p1SUnKzxz2KhSmPl7nAVVlItUIRc/7tlrzhhEsNte FH2wnQr40OVqN3sgdMFsKvh0fZz6TlYNxYnMLFCBr/uO2QjeD8glCEvbYnjdOU/glM= Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_89D56C06-0B02-405B-9256-37AD8437C752"; protocol="application/pkcs7-signature"; micalg=sha1 From: Joseph Gersch In-Reply-To: <507829F4.4040307@googlemail.com> Date: Fri, 12 Oct 2012 09:20:26 -0600 Message-Id: <88122F77-9616-4125-9587-B4115E4423C7@secure64.com> References: <507829F4.4040307@googlemail.com> To: Stephen Morris X-Mailer: Apple Mail (2.1283) Cc: dnsop@ietf.org Subject: Re: [DNSOP] No meeting in Atlanta [Re: Whether to meet at IETF-85 in Atlanta] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 15:20:33 -0000 --Apple-Mail=_89D56C06-0B02-405B-9256-37AD8437C752 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We had posted an updated draft on the reverse-DNS naming convention for = CIDR address blocks and asked to discuss this at the Atlanta meeting. = Did you miss this request? - Joe Gersch On Oct 12, 2012, at 8:32 AM, Stephen Morris wrote: > On 24/09/12 14:18, Stephen Morris wrote: >=20 >> We'd like to make a final decision no later than 12:00 UTC Tuesday=20 >> 2 October, so please help by posting your thoughts to the list=20 >> before then. >=20 > The bulk of discussion on the list since the last meeting has been: >=20 > * Comments on the key timing last call > * Discussion on 4641bis and DPS framework documents >=20 > An evaluation of the last call comments on key timing is pending. > 4641bis and DPS framework are both with the IESG, and we will post a > report on their progress to the list. >=20 > Although we held on beyond 2 October before making a final decision, > there was no response to our original email and little discussion > beyond the topics above. Your chairs reached the conclusion that > there was little demand for a face to face meeting, therefore decided > to cancel the slot we had provisionally secured. >=20 >=20 > Stephen and Peter > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop Joseph Gersch Chief Operating Officer Secure64 Software Corporation --Apple-Mail=_89D56C06-0B02-405B-9256-37AD8437C752 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwOLbTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDExNjExMjQ1M1oXDTEzMDExNjA2MzIwOFowZTEZMBcGA1UEDRMQeGNUczFWNjI3NzhS M1FtZTEgMB4GA1UEAwwXam9lLmdlcnNjaEBzZWN1cmU2NC5jb20xJjAkBgkqhkiG9w0BCQEWF2pv ZS5nZXJzY2hAc2VjdXJlNjQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAySJC Vtd1lVWJkfjw7a/YRt30WoQvBBW0NGzbtrAKwO0TZUkJ44LxFfiWS4tAg1zQc5HIHhH98jXKVwFQ 3dX3EPGg3Kr1wMYlLVjnaZocqWpRFMfE+HgI6ggoUqya3rZUb/wfDndDCgJ4P+0FocAAWWEfrEU4 wHXP2pXQk0h1C8ryS9B61SXZ7Rl7bF7krVsPfIn8nnpOqQ7mGrMJhu3pmRG5U32Hxc4rLKAH/q4q CiIn2LFKiKs4geG7rYGT/ptO+3zvrXlgVWjua58DZ4sPXwjQ+zpTpyfTVbn+LUwHVwnkm7Gw+Uy4 uJhFeuGkjvM5PCS21hsmiqdqoYlZoBVbWQIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSZ5oXQDfnQsADV TOckHXx4mSqRhTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdq b2UuZ2Vyc2NoQHNlY3VyZTY0LmNvbTCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAIlgjMImn2osQlyPbchRP1iBsCXvDzJfilZ/ LgXAJhg/LRzm6uGyvBoz0/sgW+HTeKpcEqDYxMehbUjo0U/RE2gvovRbBWGtH4Wqf2k8Nf0WLyuX 5QTVl0FZDqyTNodfn3twutkmiuNM5qhxbucOA6raxJc+UfoHEjOYSYZ6O6GmGn0eF5NlZsK2+jND kuopFPkLNl2xb+nvhHHI48nqY5FLoBfhhTopyTpkux1t1q0lW8YaufqK/FkMMpdQ4M0fzOCtlzJ5 hMIrLNrv3FQFgyrhImwZPrPOa36zKoSiQJj6mgPFenTJTkvd6p8PxJ7bDKKh5UJsVLeWCBpj7TXV UWwwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgMDi20wCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDEyMTUyMDI2WjAjBgkqhkiG9w0BCQQxFgQUdBX+Ra5F iUZ7QmeWCvxZzV5p+zMwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgMDi20wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwOLbTANBgkqhkiG9w0BAQEFAASCAQAkNdEBHwNrUe5FVd6c2T4pDNWYkSLtZg8NCveT AYS84+eKhCi16EIb2KN1uUDp/c0CACphx8eo8QVSh52FeqeGwcUcG2FuLz/p5qR205Hl+/VcEqWp jBnIa6kORS9XpVO7GAqo4HgOQvZ6+8787t3WGgiVoBAz0HwjigYAZ66ayCSWh9MmLI7rK9TFaGXZ DNCfSAh1YmzlYod/9+FDdVyvh0NWnPFvEfFQT3O1zO7JmlQzP6hD55rR/8WUFxCFOVMnnsSKLK21 sTK0OyIOnlRvllnjEv8eCDUK5bKEq3GMu/S9f6DWsJkWGp8IGA7wtyr6y8z/0hfCKPS0ZFKxfwAs AAAAAAAA --Apple-Mail=_89D56C06-0B02-405B-9256-37AD8437C752-- From joe.abley@icann.org Fri Oct 12 08:27:33 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134CD21F8672 for ; Fri, 12 Oct 2012 08:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxNiFUY0nFbx for ; Fri, 12 Oct 2012 08:27:32 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCDD21F866E for ; Fri, 12 Oct 2012 08:27:32 -0700 (PDT) Received: from [199.212.90.45] (199.212.90.45) by smtpx.exc.icann.org (64.78.22.243) with Microsoft SMTP Server (TLS) id 8.3.245.1; Fri, 12 Oct 2012 08:27:31 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: <88122F77-9616-4125-9587-B4115E4423C7@secure64.com> Date: Fri, 12 Oct 2012 11:27:30 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <43ABE07B-9A86-40F0-8D18-06DB62AAB1F2@icann.org> References: <507829F4.4040307@googlemail.com> <88122F77-9616-4125-9587-B4115E4423C7@secure64.com> To: Joseph Gersch X-Mailer: Apple Mail (2.1499) Cc: dnsop@ietf.org, Stephen Morris Subject: Re: [DNSOP] No meeting in Atlanta [Re: Whether to meet at IETF-85 in Atlanta] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 15:27:33 -0000 On 2012-10-12, at 11:20, Joseph Gersch wrote: > We had posted an updated draft on the reverse-DNS naming convention = for CIDR address blocks and asked to discuss this at the Atlanta = meeting. Did you miss this request? I didn't actually reply, but there are some aspects of trust anchor = publication and retrieval that could use some momentum. It sounds like = the decision on the meeting is final, but if for some reason it goes = ahead anyway, count me in. http://tools.ietf.org/html/draft-jabley-dnsop-validator-bootstrap-00 http://tools.ietf.org/html/draft-jabley-dnssec-trust-anchor-05 Joe= From sa.morris7@googlemail.com Fri Oct 12 09:32:02 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFDC21F8694 for ; Fri, 12 Oct 2012 09:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93YpP0W0fMXr for ; Fri, 12 Oct 2012 09:32:02 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B487621F86DC for ; Fri, 12 Oct 2012 09:32:01 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so1599719bkc.31 for ; Fri, 12 Oct 2012 09:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=QnIccInWzTqUH7JCjlTXN1aMNKn7XzNZb5Z717kIX8o=; b=oEVFdKyGksqQcjcQivjvHz17jwcZE4mojf9TJ+CEpOoiRiekux6BajcL1Yhh+6oFeS +mEiR8N4iBbFQ4XFaopc+D8t5DWbb+iegCm9Ul3MzwRcqRzaASz2pGvhprenE6XNCIy0 b5UManLxaQj0MSaUK8XLXujWyILevB2DxyPvaKCT7n6Jpzfzp52hMxzIGA1hIq5+QwWC 9NL3tNDc+kxAcpAWjhwj+ixgoMCS3Lp38LonuCeDocLNEx3UYN3SoShP3GbP7pQgSNxd FeuXjH2biQPwQiHFwTqgCt31MaakVDUtz1con91n4AWet6DU5zKovehdW38Tr3Z4oj7k 3/FQ== Received: by 10.204.147.153 with SMTP id l25mr1469305bkv.109.1350059520783; Fri, 12 Oct 2012 09:32:00 -0700 (PDT) Received: from [192.168.1.102] ([217.155.47.50]) by mx.google.com with ESMTPS id 1sm6187410bks.3.2012.10.12.09.31.58 (version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 09:31:59 -0700 (PDT) Message-ID: <507845FD.8060209@googlemail.com> Date: Fri, 12 Oct 2012 17:31:57 +0100 From: Stephen Morris User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Joseph Gersch References: <507829F4.4040307@googlemail.com> <88122F77-9616-4125-9587-B4115E4423C7@secure64.com> In-Reply-To: <88122F77-9616-4125-9587-B4115E4423C7@secure64.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] No meeting in Atlanta [Re: Whether to meet at IETF-85 in Atlanta] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 16:32:02 -0000 On 12/10/12 16:20, Joseph Gersch wrote: > We had posted an updated draft on the reverse-DNS naming > convention for CIDR address blocks and asked to discuss this at the > Atlanta meeting. Did you miss this request? - Joe Gersch Yes we saw it. The principal place for discussion is the mailing list, and ideally the WG meeting should be reserved for topics that have previously been discussed on the list but would benefit from a face to face discussion. Admittedly we don't always adhere to that principle, but it does guide our decision. The decision whether or not to have a meeting is always finely balanced. We have to book a slot quite far in advance of the IETF, which we always do. But before the publication of the final IETF agenda, we have to make a judgement as to whether we have the suitable topics for a meeting or whether suitable topics are likely to arise between then and the date of the meeting. What we don't want is to either cancel the meeting once announced in the final agenda, or to have a ridiculously short meeting because of lack of material. In this case, we looked at what had been discussed since the last meeting and the feedback we got from the working group in response to our request for topics, and decided that we didn't have enough suitable material to justify a meeting this time. Stephen From joe.gersch@secure64.com Fri Oct 12 10:13:24 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FF621F86DF for ; Fri, 12 Oct 2012 10:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtry50pWV+Cn for ; Fri, 12 Oct 2012 10:13:23 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id AC11721F869C for ; Fri, 12 Oct 2012 10:13:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 0C6D5B85DA; Fri, 12 Oct 2012 11:13:23 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-mFPg0cnqwL; Fri, 12 Oct 2012 11:13:22 -0600 (MDT) Received: from [10.138.15.10] (unknown [192.168.254.4]) by zimbra.secure64.com (Postfix) with ESMTPSA id 2E3BAB8563; Fri, 12 Oct 2012 11:13:22 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1350062002; bh=K1l40C/ODtVsxmBVvEIj/G4gPXzT31OygQthlHrgPQ0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=XaBpnhhlvv4ft+w34Qmod/zZSbFSz5ghW+LiLs Qpo0+7wwRa6VY2hOzMsDl8h4ihoKyESLwwrsbZRLJxiFdxgsJr/rg8dEPsjsKCoTMjT EJydfx8YlsjhYmYxK+E88jhLwymytBMuxnw2Yed7wT8To7ShJThThhjTpGmwT4q9JM= Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_961CAE6B-4EED-439B-9269-E5E9836ACBC3"; protocol="application/pkcs7-signature"; micalg=sha1 From: Joseph Gersch In-Reply-To: <507845FD.8060209@googlemail.com> Date: Fri, 12 Oct 2012 11:13:20 -0600 Message-Id: <2A5EC01A-C15C-4413-B12A-C16AC4881FA9@secure64.com> References: <507829F4.4040307@googlemail.com> <88122F77-9616-4125-9587-B4115E4423C7@secure64.com> <507845FD.8060209@googlemail.com> To: Stephen Morris X-Mailer: Apple Mail (2.1283) Cc: dnsop@ietf.org Subject: Re: [DNSOP] No meeting in Atlanta [Re: Whether to meet at IETF-85 in Atlanta] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 17:13:24 -0000 --Apple-Mail=_961CAE6B-4EED-439B-9269-E5E9836ACBC3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 fair enough. Thanks for the clarification. - Joe On Oct 12, 2012, at 10:31 AM, Stephen Morris wrote: > On 12/10/12 16:20, Joseph Gersch wrote: >> We had posted an updated draft on the reverse-DNS naming >> convention for CIDR address blocks and asked to discuss this at the >> Atlanta meeting. Did you miss this request? - Joe Gersch > > Yes we saw it. > > The principal place for discussion is the mailing list, and ideally > the WG meeting should be reserved for topics that have previously been > discussed on the list but would benefit from a face to face > discussion. Admittedly we don't always adhere to that principle, but > it does guide our decision. > > The decision whether or not to have a meeting is always finely > balanced. We have to book a slot quite far in advance of the IETF, > which we always do. But before the publication of the final IETF > agenda, we have to make a judgement as to whether we have the suitable > topics for a meeting or whether suitable topics are likely to arise > between then and the date of the meeting. What we don't want is to > either cancel the meeting once announced in the final agenda, or to > have a ridiculously short meeting because of lack of material. > > In this case, we looked at what had been discussed since the last > meeting and the feedback we got from the working group in response to > our request for topics, and decided that we didn't have enough > suitable material to justify a meeting this time. > > Stephen Joseph Gersch Chief Operating Officer Secure64 Software Corporation --Apple-Mail=_961CAE6B-4EED-439B-9269-E5E9836ACBC3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPDTCCByMw ggYLoAMCAQICAwOLbTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEyMDExNjExMjQ1M1oXDTEzMDExNjA2MzIwOFowZTEZMBcGA1UEDRMQeGNUczFWNjI3NzhS M1FtZTEgMB4GA1UEAwwXam9lLmdlcnNjaEBzZWN1cmU2NC5jb20xJjAkBgkqhkiG9w0BCQEWF2pv ZS5nZXJzY2hAc2VjdXJlNjQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAySJC Vtd1lVWJkfjw7a/YRt30WoQvBBW0NGzbtrAKwO0TZUkJ44LxFfiWS4tAg1zQc5HIHhH98jXKVwFQ 3dX3EPGg3Kr1wMYlLVjnaZocqWpRFMfE+HgI6ggoUqya3rZUb/wfDndDCgJ4P+0FocAAWWEfrEU4 wHXP2pXQk0h1C8ryS9B61SXZ7Rl7bF7krVsPfIn8nnpOqQ7mGrMJhu3pmRG5U32Hxc4rLKAH/q4q CiIn2LFKiKs4geG7rYGT/ptO+3zvrXlgVWjua58DZ4sPXwjQ+zpTpyfTVbn+LUwHVwnkm7Gw+Uy4 uJhFeuGkjvM5PCS21hsmiqdqoYlZoBVbWQIDAQABo4IDsjCCA64wCQYDVR0TBAIwADALBgNVHQ8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSZ5oXQDfnQsADV TOckHXx4mSqRhTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAiBgNVHREEGzAZgRdq b2UuZ2Vyc2NoQHNlY3VyZTY0LmNvbTCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIw ggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9u IHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZv ciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBTZWUg c2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5 LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20v c3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAIlgjMImn2osQlyPbchRP1iBsCXvDzJfilZ/ LgXAJhg/LRzm6uGyvBoz0/sgW+HTeKpcEqDYxMehbUjo0U/RE2gvovRbBWGtH4Wqf2k8Nf0WLyuX 5QTVl0FZDqyTNodfn3twutkmiuNM5qhxbucOA6raxJc+UfoHEjOYSYZ6O6GmGn0eF5NlZsK2+jND kuopFPkLNl2xb+nvhHHI48nqY5FLoBfhhTopyTpkux1t1q0lW8YaufqK/FkMMpdQ4M0fzOCtlzJ5 hMIrLNrv3FQFgyrhImwZPrPOa36zKoSiQJj6mgPFenTJTkvd6p8PxJ7bDKKh5UJsVLeWCBpj7TXV UWwwggfiMIIFyqADAgECAgENMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQy MTAxNTRaFw0xMjEwMjIyMTAxNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP 6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu 2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyU GHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmt xWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMB AAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHmCAQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2Vy dC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYB BQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMw JxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmls aXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRD FkFTdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENl cnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAqprh4FuMzh0b/B3GLDAgoLeTJv3xArbNESi/ Kf/HMM//gf8FzwUUNOCglH6dfYuLQQ/dTtOyMb4JoiL3T7xiVKEAOmQ+t+b/xLOMa0m18zoRqW4k 6Glyoyvc7LMrdpgYk/lEh5nq8tPd9BoNmwiiheXphIVH/QelTgUkNzTC7IVpmYVsKuNOnxE1jJFZ NNfqZZK/5Oto7C6PfOut11KmBQSLZarAz0b/mjghdBsYfHuhdO8vrOvD0g5g7dA4pkOAU2Ed4pSC owBSItyD/5aFwZ75ji6Yq7GCG3BpiyAP9st8h+inc0L+7kmrAMJaLMAmu6GZs5Xgsbzn0wUJvbD9 h5jnnMM9UaZDcxl2uLB04quGUWM6NiKGabbxQc680PYbeQrQu+e6J4uqNAxzoa5RxkBA5a/3qlbg F9uJBekCqJswx5vQ9khJrs8UTMaIFzbEC5VGQziQH3/6KJ4DUP85OJEnCx/quShWA6w318LDnba3 M6a5V+KoNLhsVi/TSxf90UbBqwdRR/cOwuGkNJh16NvvhIqO26osMg64CbZsDVrEDr7uSMV40ieB JTo49Iyt77ECOhz/pyhowa2EUP6aKav+L/wXzAPB3LNqzujGR0K1pbyFWKvyYmdungJtySWUMw+R 5DqpA2bFIOE56pfWPLHZxOL+8+r79PLFX+y2V6ExggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp ZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgMDi20wCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDEyMTcxMzIxWjAjBgkqhkiG9w0BCQQxFgQU2fmvc5g+ 9FYrWloS60aly6DmsaEwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgMDi20wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwOLbTANBgkqhkiG9w0BAQEFAASCAQCzbdkI56777yuPWgGOa2TcvsoMV4ZbMsYUKCh5 IaRWxzGtiWRy3qLhpNjQm9MdC26hgMJq4+9/8jYlbggXfqTfXGRTpmHy1Bj3CG3KNqmLm26i9KRY cPwtmR9spMC8SjeO+l1pIZFnMHBphRrjA2R70lXKEBYELEPzO3HNzg/1WBRdCjF+62aJbvrl0RIx YUdhokB7Sxr9kRfelD1i5iMt7c76Q4cLIjI5neNGoAoNw/8tzMiV3efFTwByQbRYTP8DJFXnUh2p TbtBSBRRXUO5HD4C22+gCr9HWjjnW6g/1ybOMdTU3BXz9fhoZ4CkmagUDG1nc/3ldmI29moBAsi6 AAAAAAAA --Apple-Mail=_961CAE6B-4EED-439B-9269-E5E9836ACBC3-- From paul@cypherpunks.ca Fri Oct 12 11:22:46 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C502921F8787 for ; Fri, 12 Oct 2012 11:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MK6ON9T9tbsx for ; Fri, 12 Oct 2012 11:22:46 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4F13721F8772 for ; Fri, 12 Oct 2012 11:22:46 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 3CB7880504; Fri, 12 Oct 2012 14:22:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2F84380453 for ; Fri, 12 Oct 2012 14:22:45 -0400 (EDT) Date: Fri, 12 Oct 2012 14:22:45 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: "dnsop@ietf.org" Message-ID: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [DNSOP] Adopted glue - what to do with RRSIG? (bind vs ods) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 18:22:46 -0000 I ran into a corner case where opendnssec and bind showed different behaviour. There was a domain that expired that had glue records. These records got signed after the NS records were removed. A few days later, the owner restored the domain, making the glue "adopted" again. The RRSIGs were not removed by bind (dnssec-signzone with feeding old RRSIGS back to it for filtering). They were removed by opendnssec. Which approach is more correct"? I am leaning towards opendnssec. (and if there are bind/opendnssec devs here, how to I get these two signers to behave the same regarding this issue, to avoid hitting a false positive of a broken signer engine) Paul From Ed.Lewis@neustar.biz Tue Oct 16 04:56:06 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B7D21F8889 for ; Tue, 16 Oct 2012 04:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.466 X-Spam-Level: X-Spam-Status: No, score=-101.466 tagged_above=-999 required=5 tests=[AWL=2.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXpsC8OfOZdU for ; Tue, 16 Oct 2012 04:56:05 -0700 (PDT) Received: from smtp141.ord.emailsrvr.com (smtp141.ord.emailsrvr.com [173.203.6.141]) by ietfa.amsl.com (Postfix) with ESMTP id A2F9E21F8887 for ; Tue, 16 Oct 2012 04:56:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp18.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 31F6C300B1; Tue, 16 Oct 2012 07:56:05 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp18.relay.ord1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id C6363300B0; Tue, 16 Oct 2012 07:56:04 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 16 Oct 2012 07:56:00 -0400 To: Paul Wouters From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Adopted glue - what to do with RRSIG? (bind vs ods) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 11:56:06 -0000 At 14:22 -0400 10/12/12, Paul Wouters wrote: >Which approach is more correct"? I am leaning towards opendnssec. Using the choices above, opendnssec is correct. Once the NS set returns, the address records are demoted from authoritative data to glue. (Akin to occluded records arising from dynamic update adding a DNAME or NS set.) The software tools performing the signing function ought to detect this demotion and decide to remove the signature records for what has become glue. >(and if there are bind/opendnssec devs here, how to I get these two > signers to behave the same regarding this issue, to avoid hitting > a false positive of a broken signer engine) I suppose (not speaking as a developer of the tools) if you were to force a "batch" signing of the zone in BIND, including manually removing all signatures the glue records would not get signatures. This solution doesn't scale well though, as you might imagine. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From matthijs@nlnetlabs.nl Tue Oct 16 06:38:33 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7821A21F849A for ; Tue, 16 Oct 2012 06:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqvAmaVrYsor for ; Tue, 16 Oct 2012 06:38:31 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D15C421F84D2 for ; Tue, 16 Oct 2012 06:38:30 -0700 (PDT) Received: from [213.154.224.18] (zoidberg.nlnetlabs.nl [213.154.224.18]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q9GDcIC0070499 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Oct 2012 15:38:18 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q9GDcIC0070499 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1350394702; bh=Je9N+rJYH1/3By9SMAfzxFr4cKBU/xTqEynqX0U9B/Q=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=hE8EZVFbU5iU53qtc40M8kPbf/osBOJ+p9spG+5eSDokhC3l67dcm3UAELY7zar5F 2wQszrm/C2JXbe5tZqAP3ZDFkHATH1NuoWHX1vmbB8d2CGijrDUEq1O/cILEVxfRL4 pHuBnEf3Dh+ebgeenI5oFIPBSSi6ZuxgGG6NSXiI= Message-ID: <507D634A.7080009@nlnetlabs.nl> Date: Tue, 16 Oct 2012 15:38:18 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Tony Finch References: <5056E9BC.1030803@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA162F5D587F7226877BBBAD2" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Tue, 16 Oct 2012 15:38:21 +0200 (CEST) Cc: Ronald Bonica , dnsop@ietf.org Subject: Re: [DNSOP] Error in rfc4641bis - change of operator X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 13:38:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA162F5D587F7226877BBBAD2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, On 09/17/2012 12:42 PM, Tony Finch wrote: > Matthijs Mekking wrote: >> >> I think you are right, this situation can happen in the drawn scenario= =2E >> However, I guess a sane validator would try the other name server (NS_= A) >> if it would receive a validation failure from NS_B. >=20 > I think BIND will do that, but I'm less sure about Unbound and Vantio -= > see for instance a recent discussion on the dns-operations list: > https://lists.dns-oarc.net/pipermail/dns-operations/2012-September/0087= 25.html I am not sure what is going on exactly there, but when responses come back with unsigned NSEC, it seems to me that Unbound is correctly returning a SERVFAIL. >=20 > Duane Wessels's stunt authoritative nameservers are intended to detect > validating resolvers. It alternately serves signed and unsigned version= s > of a zone and notices when the resolvers retry after a validation > failure. In practice not all resolvers are persistent enough. >=20 >> Would this be fixed by just removing the pre-published NS_B from the >> losing operator version of the zone? Probably, except for sticky resol= vers. >=20 > Yes, the way to fix it is not to change the child NS RRset at the old > provider A until redelegation time, which is when you are sure resolver= s > no longer have the old chain of trust cached and are able to validate t= he > zone at the new provider B. >=20 > There are a couple of ways to deal with sticky resolvers: >=20 > (1) Change the NS RRset at A to NS_B after redelegation. >=20 > (2) Reconfigure the zone at A to slave from B. >=20 > There is a second bug in the draft which leads to lameness rather than > validation failures. After redelegation, the draft says provider A shou= ld > serve both NS_A and NS_B, so a sticky resolver will continue to send > queries to A after the zone is deconfigured there in the post-migration= > phase. >=20 >> Since I sense that there is a general consensus that using a Double-DS= >> method is a simpler way to handle a change between DNS operators in >> comparison with the Pre-Publication method, I would like to propose th= e >> following: >> >> - Remove the text on the Pre-publication style of changing DNS operato= rs. >> - Move the figure from Appendix D to the section of changing DNS opera= tors. >=20 > That's probably the right direction. However, I just looked at appendix= D > properly. It has errors too :-( Yes, I mentioned that in the previous mail: ... (although until now it includes unnecessary signatures over the DNSKEY RRsets and still has the faulty pre-publication of NS_B in the losing operator version of the zone). >=20 > Section 4.3.5.1 says: >=20 > The requirement to exchange signatures has a couple of drawbacks. I= t > requires more operational overhead, because not only the operators > have to exchange public keys, they also have to exchange the > signatures of the new DNSKEY RRset. This drawback does not exist if= > the Double Signature KSK rollover is replaced with a Double-DS KSK > rollover. See Figure 15 in Appendix D for the diagram. >=20 > But the figure in Appendix D shows that signatures HAVE been exchanged,= so > it doesn't have the simplification implied by this text. >=20 > Figure 15 also changes the NS RRset at A too soon, so it doesn't fix th= e > bug I found on Friday. As I mentioned... >=20 > A minor niggle: It has a "new DS" phase rather than an initial phase, > which is not necessary: you can publish the new DS at the same time as = the > new DNSKEY RRs. That is, you can do the "new DS" phase of the double-DS= > KSK rollover at the same time as the "pre-publish" phase of the ZSK > rollover. Ok, adjusted the figure. > After all that here is what I think are the minimal changes necessary: >=20 >=20 > To correct figure 10: >=20 > Remove NS_B from the "Child at A" column in the pre-publish phase. >=20 > Remove NS_A from the "Child at A" column in the redelegation phase. I think we should remove this overly complex rollover with too many drawbacks. > The second paragraph of the explanatory text should read: >=20 >> The zone is initially delegated from the parent to the name servers of= >> operator A. Operator A uses his own ZSK and KSK to sign the zone. The >> cooperating operator A will pre-publish the ZSK and KSK of operator B,= >> including the RRSIG over the DNSKEY RRset generated by the KSK of B. >> Operator B needs to publish the same DNSKEY RRset. When the old DNSKE= Y >> RRset has expired from the caches, the re-delegation can be made, whic= h >> involves adjusting the NS and DS records in the parent zone to point t= o >> operator B. To ensure resolvers switch from A to B, operator A should >> also change its NS records to point to operator B. And after all RRSIG= >> records related to A have expired from the caches (apart from the DNSK= EY >> RRSIG), operator B can stop publishing the keys and signatures belongi= ng >> to operator A. Well, that is just the paragraph as it is now right? So it seems that text should be adjusted. But if we are going to remove this rollover, this text will be removed too. Here is the suggested text for the explanatory text that goes with the other approach: The zone is initially delegated from the parent to the name servers of operator A. Operator A uses his own ZSK and KSK to sign the zone. In the second stage, 'new DS and pre-publish', the cooperating operator A will pre-publish the ZSK of operator B, while the new operator B publishes the ZSK of operator A. Both operators sign their zone with their own ZSKs and KSKs. At the same time, operator B can pre-publish the new DS record, DS_B, that delegates to the KSK of operator B. When the old DNSKEY and DS RRsets have expired from the caches, i.e. all the resolvers are still using the delegation of the old operator but are prepared to trust the delegation to the new operator, the re-delegation can be made. This involves adjusting the NS RRset in the parent zone to point to operator B. To ensure resolvers switch from A to B, operator A should also change its NS records to point to operator B. In the post migration stage, when all RRSIG records related to A have expired from the caches, operator B can stop publishing the keys belonging to operator A and the DS record belonging to operator A, DS_A, can be removed from the parent zone. >=20 >=20 > To correct figure 15: >=20 > Change the first column from "new DS" to "initial" and remove DS_B. Sure. >=20 > In the "Child at A" column of the pre-publish phase, remove NS_B and > RRSIG_K_B(DNSKEY). Yes. >=20 > In the "Child at B" column of the pre-publish phase, remove > RRSIG_K_A(DNSKEY). Yes. >=20 > Change the name of the pre-publish phase to "new DS and pre-publish". Sure. >=20 > In the "Child at A" column of the redelegation phase, remove NS_A. Yes. All done in the work in progress document. Best regards, Matthijs >=20 >=20 > Tony. >=20 --------------enigA162F5D587F7226877BBBAD2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQfWNNAAoJEA8yVCPsQCW50m4H/1ovpEPAx1W9m1yRae8CFFbu cyUsH0f03k0qvmCy4DTStlaCgHzmdmN7RVttj3ypkyx+NOBKJyUItvAHPC3twn3d 5J/FGy1YMyheVDQj3fC7rRXePocmkQoRGRullRYS75QDV+lLmF862D3Clup1AwGo oY7sf6RJ5/AsdJF00JfvICpAHGablQvLn6mzT9pX13UuG/DG53T4opDl91JAcWGF mqywzdVdCeKncpuA7VVRQx71MuAPCN1UGens1gMDyjK8FYfotqkOam0w0gj7MnRg WEpiWnWuWUOpzQIKTnJQM4RS7HTu+vYcjhJQDVfTqB90ToZpRmaj+hBV4hKclBo= =Jkt9 -----END PGP SIGNATURE----- --------------enigA162F5D587F7226877BBBAD2-- From matthijs@nlnetlabs.nl Tue Oct 16 06:38:35 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D01521F870A for ; Tue, 16 Oct 2012 06:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koAil86SNZj3 for ; Tue, 16 Oct 2012 06:38:35 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 963E221F849A for ; Tue, 16 Oct 2012 06:38:34 -0700 (PDT) Received: from [213.154.224.18] (zoidberg.nlnetlabs.nl [213.154.224.18]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q9GDcRcT070506 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Oct 2012 15:38:27 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q9GDcRcT070506 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1350394708; bh=gSsqwHfhutoT7oadLjMFsuNyXAFIJAIAq8Uclu0NhWs=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=BNoSerK7QboMFjJ8jDOGy2fptFU6eReo2dCMvDNbk3dLmbs5vp+a4kpB5WUbvWUKj Z5bUvMdTDzjLrnTNALCls7Nw0yJnL8yemeVx8ugwBuLuzfGkg83NfQdj1SSgut7dVr DPxBCpfuC02Glq2JnEdP2LWw8aX4cHshQINLYUq8= Message-ID: <507D6356.10707@nlnetlabs.nl> Date: Tue, 16 Oct 2012 15:38:30 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Tony Finch References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2313D5236141BE2E8B44FD52" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Tue, 16 Oct 2012 15:38:28 +0200 (CEST) Cc: rbonica@juniper.net, dnsop@ietf.org, miek.gieben@sidn.nl Subject: Re: [DNSOP] rfc4641bis - single key rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 13:38:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2313D5236141BE2E8B44FD52 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Correct, applied your corrected text to the work in progress document. Best regards, Matthijs On 09/18/2012 01:55 PM, Tony Finch wrote: > Section 4.1.3. This description of a variant rollover is dangerous: the= > new key must sign the DNSKEY RRset before the DS change, even if signin= g > the rest of the zone is delayed. >=20 > This rollover has the drawback that it introduces double signatures > over all data of the zone. Taking these zone size considerations > into account, it is possible to not introduce the signatures made > with DNSKEY_S_2 at the "new DNSKEY" step. Instead, signatures of > DNSKEY_S_1 are replaced with signatures of DNSKEY_S_2 in an > additional stage between the "DS change" and "DNSKEY removal" step: > After the DS RRset containing DS_S_1 has expired from distant caches= , > the signatures can be swapped. Only after the new signatures made > with DNSKEY_S_2 have been propagated, the old public key DNSKEY_S_1 > can be removed from the DNSKEY RRset. >=20 > Corrected text: >=20 > This rollover has the drawback that it introduces double signatures > over all data of the zone. Taking these zone size considerations > into account, it is possible to not introduce the signatures made > with DNSKEY_S_2 at the "new DNSKEY" step, except for the signature > over the DNSKEY RRset. Instead, signatures of DNSKEY_S_1 in the res= t > of the zone are replaced with signatures of DNSKEY_S_2 in an > additional stage between the "DS change" and "DNSKEY removal" step: > After the DS RRset containing DS_S_1 has expired from distant caches= , > the signatures can be swapped. Only after the new signatures made > with DNSKEY_S_2 have been propagated, the old public key DNSKEY_S_1 > can be removed from the DNSKEY RRset. >=20 > Tony. >=20 --------------enig2313D5236141BE2E8B44FD52 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQfWNXAAoJEA8yVCPsQCW5MMgH/3bj4AEC8EzUk8uKNPPfLHxB MVn6yxFjez4jXfTDyEuGn5DpNWzwkPVy67G323v3yBi5MiK+2ONRHP7ENRQ1OP9l rvMt+js5cYvfDLQHM1YazTghD7LO8y7HmsbfYoqxFfmL5pXmyz1QDnerz1cmmAFW CkL5Rc7GvrShp8YZywa8G58XcWoBwK5n2LTgfERpP3QTiF50smgIS3s/uzCfc/7z QqrP25LGGGk4aYuvZMAyOhJwteAced9QuSnbaSl+Zspor1lk4Cm1Q0oK7OApHbi3 Y+XuzCl2CSem0X0XYLvY/Fr5ZDoaYFjM2PPaZPVe0Ph4pgBu2fbM2CO11eKLLv8= =Dax6 -----END PGP SIGNATURE----- --------------enig2313D5236141BE2E8B44FD52-- From matthijs@nlnetlabs.nl Tue Oct 16 06:38:40 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72A021F8755 for ; Tue, 16 Oct 2012 06:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y290CrCqqr7S for ; Tue, 16 Oct 2012 06:38:39 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A59C521F8737 for ; Tue, 16 Oct 2012 06:38:38 -0700 (PDT) Received: from [213.154.224.18] (zoidberg.nlnetlabs.nl [213.154.224.18]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q9GDcV01070514 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Oct 2012 15:38:31 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q9GDcV01070514 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1350394712; bh=xWvd6WaBiskoMkzbK4wKSgwU4wYByCNT/SkCHT6/l6A=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=OuHBzwvSTdNowFmdwE7MYYWC4FJwY0io7aVN/ki9xJQt9eEJoGGFcwYGmBuWXCS1+ 56ffZNwPCGfbr/H3uuF4rkddY+XB5dxgfbdi5ey8Vd1lpiiWUDNWTxfR0WdjA1Ws85 sWOMNHUbcH/T6ZABy32nT2UveK8Mwu8Dm6HtgX+Y= Message-ID: <507D635A.9080602@nlnetlabs.nl> Date: Tue, 16 Oct 2012 15:38:34 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Tony Finch References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1F210BC729572E602ED99357" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Tue, 16 Oct 2012 15:38:32 +0200 (CEST) Cc: rbonica@juniper.net, dnsop@ietf.org, miek.gieben@sidn.nl Subject: Re: [DNSOP] another error in rfc4641bis - KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 13:38:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1F210BC729572E602ED99357 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Correct, applied your fixed text to the work in progress document. Best regards, Matthijs On 09/18/2012 01:25 PM, Tony Finch wrote: > Section 4.1.2, explanatory text: >=20 > initial: Initial version of the zone. The parental DS points to > DNSKEY_K_1. Before the rollover starts, the child will have to > verify what the TTL is of the DS RR that points to DNSKEY_K_1 -- > it is needed during the rollover and we refer to the value as > TTL_DS. >=20 > new DNSKEY: During the "new DNSKEY" phase, the zone administrator > generates a second KSK, DNSKEY_K_2. The key is provided to the > parent, and the child will have to wait until a new DS RR has bee= n > generated that points to DNSKEY_K_2. After that DS RR has been > published on all servers authoritative for the parent's zone, the= > zone administrator has to wait at least TTL_DS to make sure that > the old DS RR has expired from caches. >=20 > DS change: The parent replaces DS_K_1 with DS_K_2. >=20 > This is missing a necessary wait: the old DNSKEY RRset must expire from= > caches before the parent to replaces the DS RR. >=20 > Fixed text: >=20 > new DNSKEY: During the "new DNSKEY" phase, the zone administrator > generates a second KSK, DNSKEY_K_2, introduces it into the key > set, and signs the new key set with both the old and new KSKs. > The minimum duration of this phase is the time it takes for > the data to propagate to the authoritative servers, plus TTL valu= e > of the key set. >=20 > DS change: The new key is provided to the parent. The child will > have to wait until the parent replaces DS_K_1 with DS_K_2. After= > the new DS RR has been published on all servers authoritative for= > the parent's zone, the zone administrator has to wait at least > TTL_DS to make sure that the old DS RR has expired from caches. >=20 > Tony. >=20 --------------enig1F210BC729572E602ED99357 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQfWNaAAoJEA8yVCPsQCW5XqYH/iWV/M4jIZB2XBdKklqGnzIx sBcwm5+jgQueDyCyTq1RsiAUNqjcPQQ98hfnt3FMWnMIj0WIaxevK4OsQ9FAyDzo cg85deJEjSh7JczN6q8oqNAFVoACsCtTOzLiXVk1JU2PBldCyd8meAFzyHO0E6dS 349DFep2uZVqPthcWvLxagUhwgTd94fIRgs6utrqz70X4xaxTjO8bCS7z4DankH6 P3DSiDLgTQpMa+C2JEXi6mMker+rAXlo1GhspRO5IihZOqohkBVOda2taasXpdZB iQAofewwGfW86PxF8EuMOBs/uD1440Jp/byNcl/KZC7VZ0hbH52Nnbl8iUP+GU8= =Ds0n -----END PGP SIGNATURE----- --------------enig1F210BC729572E602ED99357-- From matthijs@nlnetlabs.nl Tue Oct 16 07:03:27 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF3F21F8873 for ; Tue, 16 Oct 2012 07:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lcm7VkCTLH6z for ; Tue, 16 Oct 2012 07:03:25 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7737721F873A for ; Tue, 16 Oct 2012 07:03:19 -0700 (PDT) Received: from [213.154.224.18] (zoidberg.nlnetlabs.nl [213.154.224.18]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q9GE3ABt009810 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Oct 2012 16:03:11 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q9GE3ABt009810 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1350396194; bh=D7DHZNgqbtP/qdPZl1BVAIOo1LaPPkmkSjd5Jnpxon4=; h=Date:From:To:CC:Subject; b=wq/NtFnLLlHgTTC4+9UAYMBQjjyQfS/Py27yyLx/Mc5FPE6U5v16XhWuGj8gRi+xE el1S+3yBwNaG13h0N7JRYMTtWQfJxoOcC2THYX9QxOO3bl6Sg1zV2Yp64m7r7UFOY1 ilGPLaAE/ydwJbaiZ3ZMz/q6F4r5Z5OsHLsWNtHk= Message-ID: <507D691F.9000404@nlnetlabs.nl> Date: Tue, 16 Oct 2012 16:03:11 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: dnsop@ietf.org X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA11AA4F89E559048A97F57C4" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Tue, 16 Oct 2012 16:03:12 +0200 (CEST) Cc: Ronald Bonica , Peter Koch , Miek Gieben , bclaise@cisco.com, Stephen Morris Subject: [DNSOP] Changes since draft-ietf-dnsop-rfc4641bis-13 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 14:03:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA11AA4F89E559048A97F57C4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, The document draft-ietf-dnsop-rfc464bis-13 has seen some issues while being in AUTH and RCF-EDITOR state. This e-mail will list all the suggested changes to address those issues. * Issue in section 4.1.2. Key Signing Key Rollovers There is a missing necessary wait: The old DNSKEY RRset must expire from caches before the parent can change the DS RRset. Old text: new DNSKEY: During the "new DNSKEY" phase, the zone administrator generates a second KSK, DNSKEY_K_2. The key is provided to the parent, and the child will have to wait until a new DS RR has been generated that points to DNSKEY_K_2. After that DS RR has been published on all servers authoritative for the parent's zone, the zone administrator has to wait at least TTL_DS to make sure that the old DS RR has expired from caches. DS change: The parent replaces DS_K_1 with DS_K_2. New text: new DNSKEY: During the "new DNSKEY" phase, the zone administrator generates a second KSK, DNSKEY_K_2, introduces it into the key set, and signs the new key set with both the old and new KSKs. The minimum duration of this phase is the time it takes for the data to propagate to the authoritative servers, plus TTL value of the key set. DS change: The new key is provided to the parent. The child will have to wait until the parent replaces DS_K_1 with DS_K_2. After the new DS RR has been published on all servers authoritative for the parent's zone, the zone administrator has to wait at least TTL_DS to make sure that the old DS RR has expired from caches. * Issue in section 4.1.3. Single Type Signing Scheme Key Rollover Not all signatures can skip pre-publication, the new key must sign the DNSKEY RRset before the DS change, even if signing the rest of the zone is delayed. Old text: This rollover has the drawback that it introduces double signatures over all data of the zone. Taking these zone size considerations into account, it is possible to not introduce the signatures made with DNSKEY_S_2 at the "new DNSKEY" step. Instead, signatures of DNSKEY_S_1 are replaced with signatures of DNSKEY_S_2 in an additional stage between the "DS change" and "DNSKEY removal" step: After the DS RRset containing DS_S_1 has expired from distant caches, the signatures can be swapped. Only after the new signatures made with DNSKEY_S_2 have been propagated, the old public key DNSKEY_S_1 can be removed from the DNSKEY RRset. New text: This rollover has the drawback that it introduces double signatures over all data of the zone. Taking these zone size considerations into account, it is possible to not introduce the signatures made with DNSKEY_S_2 at the "new DNSKEY" step, except for the signature over the DNSKEY RRset. Instead, signatures of DNSKEY_S_1 in the rest of the zone are replaced with signatures of DNSKEY_S_2 in an additional stage between the "DS change" and "DNSKEY removal" step: After the DS RRset containing DS_S_1 has expired from distant caches, the signatures can be swapped. Only after the new signatures made with DNSKEY_S_2 have been propagated, the old public key DNSKEY_S_1 can be removed from the DNSKEY RRset. * Issue on Section 4.3.5.1. Cooperating DNS operators The decision is to handle only one scenario, the alternative approach from the appendix, and remove the utterly complex, drawback heavy scenario that is now described first in the document. I'll post the old and new contents of the section below (warning: it is a bit long). In addition, Appendix D. Transition Figure for Changing DNS Operators is removed. Old text: In this scenario, it is assumed that the losing operator will not pass any private key material to the gaining operator (that would constitute a trivial case) but is otherwise fully cooperative. In this environment, the change could be made with a Pre-Publish ZSK rollover whereby the losing operator pre-publishes the ZSK of the gaining operator, combined with a Double Signature KSK rollover where the two registrars exchange public keys and independently generate a signature over those key sets that they combine and both publish in their copy of the zone. Once that is done they can use their own private keys to sign any of their zone content during the transfer. ------------------------------------------------------------ initial | pre-publish | ------------------------------------------------------------ Parent: NS_A NS_A DS_A DS_A ------------------------------------------------------------ Child at A: Child at A: Child at B: SOA_A0 SOA_A1 SOA_B0 RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) NS_A NS_A NS_B RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS) RRSIG_Z_A(NS) DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_B DNSKEY_Z_B DNSKEY_K_A DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B DNSKEY_K_B RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) ------------------------------------------------------------ ------------------------------------------------------------ redelegation | post migration | ------------------------------------------------------------ Parent: NS_B NS_B DS_B DS_B ------------------------------------------------------------ Child at A: Child at B: Child at B: SOA_A1 SOA_B0 SOA_B1 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA) NS_A NS_B NS_B NS_B RRSIG_Z_B(NS) RRSIG_Z_B(NS) RRSIG_Z_A(NS) DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B DNSKEY_K_B DNSKEY_K_B RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) ------------------------------------------------------------ Figure 10: Rollover for cooperating operators In this figure A denotes the losing operator and B the gaining operator. RRSIG_Z is the RRSIG produced by a ZSK, RRSIG_K is produced with a KSK, the appended A or B indicates the producers of the key pair. "Child at A" is how the zone content is represented by the losing DNS operator and "Child at B" is how the zone content is represented by the gaining DNS operator. The zone is initially delegated from the parent to the name servers of operator A. Operator A uses his own ZSK and KSK to sign the zone. The cooperating operator A will pre-publish the new NS record and the ZSK and KSK of operator B, including the RRSIG over the DNSKEY RRset generated by the KSK of B. Operator B needs to publish the same DNSKEY RRset. When that DNSKEY RRset has populated the caches, the re-delegation can be made, which involves adjusting the NS and DS records in the parent zone to point to operator B. And after all DNSSEC records related to A have expired from the caches, operator B can stop publishing the keys and signatures belonging to operator A and vice versa. The requirement to exchange signatures has a couple of drawbacks. It requires more operational overhead, because not only the operators have to exchange public keys, they also have to exchange the signatures of the new DNSKEY RRset. This drawback does not exist if the Double Signature KSK rollover is replaced with a Double-DS KSK rollover. See Figure 15 in Appendix D for the diagram. Thus, if the registry and registrars allow DS records to be published that do not point to a published DNSKEY in the child zone, the Double-DS KSK rollover is preferred (see Figure 5), in combination with the Pre-Publish ZSK rollover. This does not require sharing the KSK signatures between the operators, but both operators still have to publish each others ZSKs. New text: In this scenario, it is assumed that the losing operator will not pass any private key material to the gaining operator (that would constitute a trivial case) but is otherwise fully cooperative. In this environment, the change could be made with a Pre-Publish ZSK rollover whereby the losing operator pre-publishes the ZSK of the gaining operator, combined with a Double-DS KSK rollover. Once that is done they can use their own private keys to sign any of their zone content during the transfer. ------------------------------------------------------------ initial | new DS and pre-publish | ------------------------------------------------------------ Parent: NS_A NS_A DS_A DS_A DS_B ------------------------------------------------------------ Child at A: Child at A: Child at B: SOA_A0 SOA_A1 SOA_B0 RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) NS_A NS_A NS_B RRSIG_Z_A(NS) RRSIG_Z_A(NS) RRSIG_Z_B(NS) DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_B DNSKEY_Z_B DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) ------------------------------------------------------------ ------------------------------------------------------------ re-delegation | post migration | ------------------------------------------------------------ Parent: NS_B NS_B DS_A DS_B DS_B ------------------------------------------------------------ Child at A: Child at B: Child at B: SOA_A1 SOA_B0 SOA_B1 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA) NS_B NS_B NS_B RRSIG_Z_A(NS) RRSIG_Z_B(NS) RRSIG_Z_B(NS) DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B DNSKEY_K_A DNSKEY_K_B DNSKEY_K_B RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) ------------------------------------------------------------ Figure 10: Rollover for cooperating operators In this figure A denotes the losing operator and B the gaining operator. RRSIG_Z is the RRSIG produced by a ZSK, RRSIG_K is produced with a KSK, the appended A or B indicates the producers of the key pair. "Child at A" is how the zone content is represented by the losing DNS operator and "Child at B" is how the zone content is represented by the gaining DNS operator. The zone is initially delegated from the parent to the name servers of operator A. Operator A uses his own ZSK and KSK to sign the zone. In the second stage, 'new DS and pre-publish', the cooperating operator A will pre-publish the ZSK of operator B, while the new operator B publishes the ZSK of operator A. Both operators sign their zone with their own ZSKs and KSKs. At the same time, operator B can pre-publish the new DS record, DS_B, that delegates to the KSK of operator B. When the old DNSKEY and DS RRsets have expired from the caches, i.e. all the resolvers are still using the delegation of the old operator but are prepared to trust the delegation to the new operator, the re-delegation can be made. This involves adjusting the NS RRset in the parent zone to point to operator B. To ensure resolvers switch from A to B, operator A should also change its NS records to point to operator B. In the post migration stage, when all RRSIG records related to A have expired from the caches, operator B can stop publishing the keys belonging to operator A and the DS record belonging to operator A, DS_A, can be removed from the parent zone. --------------enigA11AA4F89E559048A97F57C4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQfWkiAAoJEA8yVCPsQCW5iiYIAKNhsFzu3+a9xV9nPgFe+bdl u3J1rPwTJtCUnY3pSCYtJS1t4cjE15nftuZ6ManpiVVRYTd24qEQ0dVozGfViAZe y8/6nOOUj1S9fxJlrBoB7tat1tTRXpdnzRCi9ZsRvvUO/DwZ2QK51A8gzM91AQUZ yiyyD4fZBWyEQja6EJ/13mBfZa82NenBoDYKAdMLlWJcNP9qz/qIu3mTWVB2L6Io 8N/3iHq2cHGnHVTVng6A7ybH+kZSnXoTDmOs9d/Rw8IRE3x6x7DMQN1VcNqrR4RJ aTuBkuSg52cZng8mudJaA7+d47Bq+OeeX7VagbpIffmViv/4EINb1nZAjYdVyRw= =Mqcq -----END PGP SIGNATURE----- --------------enigA11AA4F89E559048A97F57C4-- From fanf2@hermes.cam.ac.uk Wed Oct 17 08:41:57 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F4021F8678 for ; Wed, 17 Oct 2012 08:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.832 X-Spam-Level: X-Spam-Status: No, score=-4.832 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-XwuXbBVcR3 for ; Wed, 17 Oct 2012 08:41:56 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 640BB21F8671 for ; Wed, 17 Oct 2012 08:41:56 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:51965) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1TOVko-0004t3-SE (Exim 4.72) (return-path ); Wed, 17 Oct 2012 16:41:54 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TOVko-0002aZ-Np (Exim 4.72) (return-path ); Wed, 17 Oct 2012 16:41:54 +0100 Date: Wed, 17 Oct 2012 16:41:54 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Matthijs Mekking In-Reply-To: <507D691F.9000404@nlnetlabs.nl> Message-ID: References: <507D691F.9000404@nlnetlabs.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Tony Finch , Ronald Bonica , dnsop@ietf.org, Peter Koch , Miek Gieben , bclaise@cisco.com, Stephen Morris Subject: Re: [DNSOP] Changes since draft-ietf-dnsop-rfc4641bis-13 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:41:57 -0000 Matthijs Mekking wrote: > > The document draft-ietf-dnsop-rfc464bis-13 has seen some issues while > being in AUTH and RCF-EDITOR state. This e-mail will list all the > suggested changes to address those issues. I have reviewed the changes and they look good to me. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From marka@isc.org Thu Oct 18 16:18:04 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EFA21F85B3 for ; Thu, 18 Oct 2012 16:18:04 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2TnP0ltRIRx for ; Thu, 18 Oct 2012 16:18:04 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 34F8721F85B0 for ; Thu, 18 Oct 2012 16:18:04 -0700 (PDT) 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)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 49D62C967D; Thu, 18 Oct 2012 23:17:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c501:27de:9a78:48f1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0E97E216C43; Thu, 18 Oct 2012 23:17:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 252712A01915; Fri, 19 Oct 2012 10:17:56 +1100 (EST) To: Edward Lewis From: Mark Andrews References: In-reply-to: Your message of "Tue, 16 Oct 2012 07:56:00 EDT." Date: Fri, 19 Oct 2012 10:17:56 +1100 Message-Id: <20121018231756.252712A01915@drugs.dv.isc.org> Cc: "dnsop@ietf.org" , Paul Wouters Subject: Re: [DNSOP] Adopted glue - what to do with RRSIG? (bind vs ods) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 23:18:04 -0000 In message , Edward Lewis writes: > At 14:22 -0400 10/12/12, Paul Wouters wrote: > > >Which approach is more correct"? I am leaning towards opendnssec. > > Using the choices above, opendnssec is correct. Once the NS set > returns, the address records are demoted from authoritative data to > glue. (Akin to occluded records arising from dynamic update adding a > DNAME or NS set.) > > The software tools performing the signing function ought to detect > this demotion and decide to remove the signature records for what has > become glue. There is nothing wrong with the signature remaining. Authoratitive servers are supposed to ignore them when generating responses to QUERIES other than AXFR/IXFR the same as they ignore all other types other than A and AAAA. > >(and if there are bind/opendnssec devs here, how to I get these two > > signers to behave the same regarding this issue, to avoid hitting > > a false positive of a broken signer engine) > > I suppose (not speaking as a developer of the tools) if you were to > force a "batch" signing of the zone in BIND, including manually > removing all signatures the glue records would not get signatures. > This solution doesn't scale well though, as you might imagine. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > 2012...time to reuse those 1984 calendars! > _______________________________________________ > 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 paul@cypherpunks.ca Thu Oct 18 19:56:28 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA0C1F0C4C for ; Thu, 18 Oct 2012 19:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9eCdnbfzNpN for ; Thu, 18 Oct 2012 19:56:28 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 14A751F0425 for ; Thu, 18 Oct 2012 19:56:28 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id C444082B2B; Thu, 18 Oct 2012 22:56:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B712682B28; Thu, 18 Oct 2012 22:56:06 -0400 (EDT) Date: Thu, 18 Oct 2012 22:56:06 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Mark Andrews In-Reply-To: <20121018231756.252712A01915@drugs.dv.isc.org> Message-ID: References: <20121018231756.252712A01915@drugs.dv.isc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dnsop@ietf.org" , Edward Lewis Subject: Re: [DNSOP] Adopted glue - what to do with RRSIG? (bind vs ods) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 02:56:28 -0000 On Fri, 19 Oct 2012, Mark Andrews wrote: >> The software tools performing the signing function ought to detect >> this demotion and decide to remove the signature records for what has >> become glue. > > There is nothing wrong with the signature remaining. Authoratitive > servers are supposed to ignore them when generating responses to > QUERIES other than AXFR/IXFR the same as they ignore all other types > other than A and AAAA. Will dnssec-signzone's behaviour be modified to ensure these RRSIGs are removed from the zone, or is it going to leave that up to the name server? For those of us using multiple engines, the difference is a problem, even if the nameserver would not actually serve the records. Paul From Ed.Lewis@neustar.biz Fri Oct 19 06:33:49 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47A121F8602 for ; Fri, 19 Oct 2012 06:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.721 X-Spam-Level: X-Spam-Status: No, score=-102.721 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jmx4lT3-xHe1 for ; Fri, 19 Oct 2012 06:33:49 -0700 (PDT) Received: from smtp155.dfw.emailsrvr.com (smtp155.dfw.emailsrvr.com [67.192.241.155]) by ietfa.amsl.com (Postfix) with ESMTP id 8754F21F85F7 for ; Fri, 19 Oct 2012 06:33:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp15.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 03541301744; Fri, 19 Oct 2012 09:33:44 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp15.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 76AE030173A; Fri, 19 Oct 2012 09:33:43 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <20121018231756.252712A01915@drugs.dv.isc.org> References: <20121018231756.252712A01915@drugs.dv.isc.org> Date: Fri, 19 Oct 2012 09:33:39 -0400 To: Mark Andrews From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "dnsop@ietf.org" , Paul Wouters , Edward Lewis Subject: Re: [DNSOP] Adopted glue - what to do with RRSIG? (bind vs ods) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:33:50 -0000 At 10:17 +1100 10/19/12, Mark Andrews wrote: >There is nothing wrong with the signature remaining. Authoratitive >servers are supposed to ignore them when generating responses to >QUERIES other than AXFR/IXFR the same as they ignore all other types >other than A and AAAA. There's the principle of "be liberal in what you accept and conservative in what you send", which that tack violates. By including the extraneous signatures you aren't being conservative. My expectation of a DNSSEC signer is that it would produce a properly signed zone. If a signer tool included signatures for which it is not authorized to make, even if they were just leftovers, I'd report a bug because that would not meet expectations. What happens when a validator sees a non-authorized signature on data? What happens when a validator sees that on glue? There's no specific defined behavior there, so I would assert that the signer ought to be conservative. But - that is just an opinion of mine. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From Antoin.Verschuren@sidn.nl Tue Oct 23 04:32:51 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6AF021F86AD for ; Tue, 23 Oct 2012 04:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFfKXZdohwW4 for ; Tue, 23 Oct 2012 04:32:49 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4951521F868B for ; Tue, 23 Oct 2012 04:32:48 -0700 (PDT) Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id q9NBWftO027105-q9NBWftW027105 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Tue, 23 Oct 2012 13:32:47 +0200 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn01.SIDN.local (192.168.2.73) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 23 Oct 2012 13:32:38 +0200 Received: from [94.198.156.18] (94.198.156.18) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 23 Oct 2012 13:32:38 +0200 Message-ID: <50868055.6030809@sidn.nl> Date: Tue, 23 Oct 2012 13:32:37 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: References: <507D691F.9000404@nlnetlabs.nl> In-Reply-To: <507D691F.9000404@nlnetlabs.nl> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.156.18] Subject: Re: [DNSOP] Changes since draft-ietf-dnsop-rfc4641bis-13 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:32:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16-10-12 16:03, Matthijs Mekking wrote: > Hi all, > > The document draft-ietf-dnsop-rfc464bis-13 has seen some issues > while being in AUTH and RCF-EDITOR state. This e-mail will list all > the suggested changes to address those issues. While reading the proposed changes and the whole document again, I noticed another paragraph that is no longer desired. My question is that now that we do make some changes, it is advised that this paragraph is also adjusted to fit current day practices. The paragraph is 4.3.2. The advice in this paragraph, which hasn't changed since 2009 when it was first written down, has been overtaken by new insight and practices. It advises registries to store only DS in stead of DNSKEY material in their database. This has proven to be impractical when deploying DNSSEC on a large scale: 1. Current practice proves that the majority of DNSSEC domains in the world today is provisioned by sending a DNSKEY record to te registry, and not DS. Running code for the majority of DNSSEC domains uses DNSKEY. 2. The old advice is based on the assumption that less errors are being made when cutting and pasting a DS in a webinterface or reading it since it is smaller than a DNSKEY. Current practice today however is that this is all automated, and while provisioning 1.3 M DNSSEC domains, we have not seen such errors. 3. With more algorithms used for DNSSEC today, and some no longer advised, registries want to hash the DNSKEY to DS themselves so they don't need to go through a "contacting every child" nightmare when an algorithm is no longer supported. The DS is owned by the parent, not the child. Our practice shows that hashing is a minor operation by the parent. It takes no real effort whatsoever in computation or time. 4. The most important motivation for us to use DNSKEY is consistancy with new processes that did not exist in 2009. DNSSEC secure transfers (http://tools.ietf.org/id/draft-koch-dnsop-dnssec-operator-change-04.txt) is the most important one. In a DNS-operator change, the operator initiating the change needs to send his new KSK (DNSKEY/DS) to the registry AND needs to relay his ZSK (DNSKEY). It is confusing that in bootstrapping a delegation a DS needs to be sent, but when transfering a DS AND ZSK DNSKEY needs to be sent. It is better to use DNSKEY in both processes so a child operator is never burdened with calculating a DS or having to think about 2 different fields in EPP that do not have the same meaning. So our advise is to use DNSKEY syntax for both KSK and ZSK when transfering to your parent. So my advise is to either delete paragraph 4.3.2 since it is bad advice (there is no convincing motivation given in this paragraph anyway), or use the motivation given above to advise for using DNSKEY over DS. If needed, I'm willing to write text. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQhoBVAAoJEDqHrM883AgngBMH/1e5LxpQrZNLJ/lV5kp2OJFx WWsKM2joRSSpW+fc/CMp6gQ5kMs32TqjAk3SLGcUEnKKU1L4zBOPIPzHNfyryqEp +Mckt+LGtC9/OngjTtfKGvfejLmUormu0zmwSTW5hJqUi16lz4chHosJtvI3JNpZ s73gDUW11zAxomyJw3bkBOQQgPklpV+7IOAGMeRkxXPUWvhMaPYsGwppZFI4nX49 Bw5zYytnL9YbfdK+LzY7DY5j3ZoEVV6056w7Gn2U4or8IBTQxquR9rpA0XHmrYPv C07lSeDdwu7jGrv4Qt2ORcZwjvSVYmDD5q3q84w8ZAe7/LU7JAiRaTPIrOBHmoc= =HVX8 -----END PGP SIGNATURE----- From miekg@atoom.net Tue Oct 23 06:29:58 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CD021F86FA for ; Tue, 23 Oct 2012 06:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLRsarc-0w-7 for ; Tue, 23 Oct 2012 06:29:57 -0700 (PDT) Received: from elektron.atoom.net (elektron.atoom.net [85.223.71.124]) by ietfa.amsl.com (Postfix) with ESMTP id A726721F86F8 for ; Tue, 23 Oct 2012 06:29:57 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id DA6933FF49; Tue, 23 Oct 2012 15:29:55 +0200 (CEST) Date: Tue, 23 Oct 2012 15:29:55 +0200 From: Miek Gieben To: dnsop@ietf.org Message-ID: <20121023132955.GH21418@miek.nl> Mail-Followup-To: dnsop@ietf.org References: <507D691F.9000404@nlnetlabs.nl> <50868055.6030809@sidn.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82evfD9Ogz2JrdWZ" Content-Disposition: inline In-Reply-To: <50868055.6030809@sidn.nl> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [DNSOP] Changes since draft-ietf-dnsop-rfc4641bis-13 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 13:29:58 -0000 --82evfD9Ogz2JrdWZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "Re: [DNSOP] Changes since draft-i= et..." ] > The paragraph is 4.3.2. > The advice in this paragraph, which hasn't changed since 2009 when it =2E.. so you couldn't have sent in a change sooner? ;-) > was first written down, has been overtaken by new insight and practices. > It advises registries to store only DS in stead of DNSKEY material in > their database.=20 The paragraph is a *suggestion* in a *bcp*. With the central point=20 being that a child can choose its hash. I think this is a too minor point to (again) stop the AUTH48 process. Regards, --=20 Miek Gieben http://miek.nl --82evfD9Ogz2JrdWZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlCGm9MACgkQJYuFzziA0PZC9wCg5svTDyhZeCGwbDZfLg0ciFxb hH8AoNGEeTABR0sc4jGZCJyT8Yj6n9W4 =qGZw -----END PGP SIGNATURE----- --82evfD9Ogz2JrdWZ-- From Niall.oReilly@ucd.ie Tue Oct 23 06:46:21 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D04221F8645 for ; Tue, 23 Oct 2012 06:46:21 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ5R6dQEj4Me for ; Tue, 23 Oct 2012 06:46:20 -0700 (PDT) Received: from mx4.ucd.ie (mx4.ucd.ie [137.43.231.112]) by ietfa.amsl.com (Postfix) with ESMTP id 389C821F8633 for ; Tue, 23 Oct 2012 06:46:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,636,1344207600"; d="scan'208";a="29013133" Received: from dhcp-c101a88b.ucd.ie ([193.1.168.139]) by smtp.ucd.ie with ESMTP/TLS/AES128-SHA; 23 Oct 2012 14:46:19 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Niall O'Reilly In-Reply-To: <20121023132955.GH21418@miek.nl> Date: Tue, 23 Oct 2012 14:46:18 +0100 Content-Transfer-Encoding: 7bit Message-Id: <311AADB4-956F-499B-971A-AE0D8BB3921B@ucd.ie> References: <507D691F.9000404@nlnetlabs.nl> <50868055.6030809@sidn.nl> <20121023132955.GH21418@miek.nl> To: Miek Gieben X-Mailer: Apple Mail (2.1085) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Changes since draft-ietf-dnsop-rfc4641bis-13 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 13:46:21 -0000 On 23 Oct 2012, at 14:29, Miek Gieben wrote: > The paragraph is a *suggestion* in a *bcp*. I don't see what point you're trying to make with this remark. Indeed, if the suggestion is not congruent with current practice, it seems to me that it very much ought not to belong in a so-called "Best Current Practice". You seem to be emphasizing Antoin's position; but then you object to it. ATB /Niall From ogud@ogud.com Tue Oct 23 07:00:44 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC8821F86AA for ; Tue, 23 Oct 2012 07:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.262 X-Spam-Level: X-Spam-Status: No, score=-103.262 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYkcbQqhftwH for ; Tue, 23 Oct 2012 07:00:44 -0700 (PDT) Received: from smtp195.iad.emailsrvr.com (smtp195.iad.emailsrvr.com [207.97.245.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB6921F8694 for ; Tue, 23 Oct 2012 07:00:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp59.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id A6FA33F0565; Tue, 23 Oct 2012 10:00:43 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp59.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 7EAEF3F05D8; Tue, 23 Oct 2012 10:00:42 -0400 (EDT) Message-ID: <5086A308.80202@ogud.com> Date: Tue, 23 Oct 2012 10:00:40 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <507D691F.9000404@nlnetlabs.nl> <50868055.6030809@sidn.nl> <20121023132955.GH21418@miek.nl> <311AADB4-956F-499B-971A-AE0D8BB3921B@ucd.ie> In-Reply-To: <311AADB4-956F-499B-971A-AE0D8BB3921B@ucd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] Changes since draft-ietf-dnsop-rfc4641bis-13 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 14:00:44 -0000 On 23/10/2012 09:46, Niall O'Reilly wrote: > > On 23 Oct 2012, at 14:29, Miek Gieben wrote: > >> The paragraph is a *suggestion* in a *bcp*. > > I don't see what point you're trying to make with this remark. > > Indeed, if the suggestion is not congruent with current practice, > it seems to me that it very much ought not to belong in a so-called > "Best Current Practice". You seem to be emphasizing Antoin's > position; but then you object to it. > > ATB > /Niall > As I disagree with the general applicability of Antion's proposal and consider it a paternalistic overreach I think rfc4641bis should go forward w/o change. While I think the idea of passing keys though the registry between operator has some merit I do not see it as viable alternative outside few cc'tld's thus it it does not deserve to be included in a BCP without full debate. Olafur From Ed.Lewis@neustar.biz Tue Oct 23 07:35:56 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3AA21F8673 for ; Tue, 23 Oct 2012 07:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.134 X-Spam-Level: X-Spam-Status: No, score=-103.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGAOnDSj5RH0 for ; Tue, 23 Oct 2012 07:35:55 -0700 (PDT) Received: from smtp185.iad.emailsrvr.com (smtp185.iad.emailsrvr.com [207.97.245.185]) by ietfa.amsl.com (Postfix) with ESMTP id B32D421F8659 for ; Tue, 23 Oct 2012 07:35:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp58.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 0603B30829A; Tue, 23 Oct 2012 10:35:55 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp58.relay.iad1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPA id 1165C308BFD; Tue, 23 Oct 2012 10:35:53 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <50868055.6030809@sidn.nl> References: <507D691F.9000404@nlnetlabs.nl> <50868055.6030809@sidn.nl> Date: Tue, 23 Oct 2012 09:34:18 -0500 To: Antoin Verschuren From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: dnsop@ietf.org Subject: Re: [DNSOP] Changes since draft-ietf-dnsop-rfc4641bis-13 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 14:35:56 -0000 At 13:32 +0200 10/23/12, Antoin Verschuren wrote: >1. Current practice proves that the majority of DNSSEC domains in the >world today is provisioned by sending a DNSKEY record to te registry, >and not DS. Running code for the majority of DNSSEC domains uses DNSKEY. Do you have any proof of this? I say this in the spirit that outside of .NL, I am not aware of any other TLD that takes the key. I am sure there are others, and I am not measuring this factor. But given what I know, I am surprised at the assertion made here. >2. The old advice is based on the assumption that less errors are >being made when cutting and pasting a DS in a webinterface or reading >it since it is smaller than a DNSKEY. Current practice today however >is that this is all automated, and while provisioning 1.3 M DNSSEC >domains, we have not seen such errors. OTOH, we haven't seen problems with the other approach. We don't have 1.3M DNSSEC zones though so I can conclude nothing. What would be meaningful is to find an example on par, size-wise, with your example that opts to accept only key records and show that it encounters errors (in significant numbers). >3. With more algorithms used for DNSSEC today, and some no longer >advised, registries want to hash the DNSKEY to DS themselves so they >don't need to go through a "contacting every child" nightmare when an >algorithm is no longer supported. The DS is owned by the parent, not >the child. Our practice shows that hashing is a minor operation by the >parent. It takes no real effort whatsoever in computation or time. Hashing was never the question. The rationale behind the suggestion to just take DS records was based on liability concerns and the thought that a registry is just about mapping information (from object to entity) and not about producing information. >4. The most important motivation for us to use DNSKEY is consistancy >with new processes that did not exist in 2009. DNSSEC secure transfers >(http://tools.ietf.org/id/draft-koch-dnsop-dnssec-operator-change-04.txt) >is the most important one. In a DNS-operator change, the operator >initiating the change needs to send his new KSK (DNSKEY/DS) to the >registry AND needs to relay his ZSK (DNSKEY). It is confusing that in >bootstrapping a delegation a DS needs to be sent, but when transfering >a DS AND ZSK DNSKEY needs to be sent. It is better to use DNSKEY in >both processes so a child operator is never burdened with calculating >a DS or having to think about 2 different fields in EPP that do not >have the same meaning. So our advise is to use DNSKEY syntax for both >KSK and ZSK when transfering to your parent. There is a discussion to be had, no doubt, but even here you are citing a document that is "just" an internet draft as a basis. >So my advise is to either delete paragraph 4.3.2 since it is bad >advice (there is no convincing motivation given in this paragraph >anyway), or use the motivation given above to advise for using DNSKEY >over DS. You'd have to demonstrate that it is "bad advice." You've only justified why you have opted to design your operations to accept keys and not limit the input to DS records. Not that your choice is wrong or invalid, but an example of one doesn't indicate consensus. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From Antoin.Verschuren@sidn.nl Tue Oct 23 07:39:23 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4997221F8653 for ; Tue, 23 Oct 2012 07:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.204 X-Spam-Level: X-Spam-Status: No, score=-4.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mg9rbcpQBvGQ for ; Tue, 23 Oct 2012 07:39:22 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEC221F855A for ; Tue, 23 Oct 2012 07:39:22 -0700 (PDT) Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id q9NEdLMF012233-q9NEdLMH012233 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Tue, 23 Oct 2012 16:39:21 +0200 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 23 Oct 2012 16:39:20 +0200 Received: from [94.198.156.18] (94.198.156.18) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 23 Oct 2012 16:39:20 +0200 Message-ID: <5086AC18.1030902@sidn.nl> Date: Tue, 23 Oct 2012 16:39:20 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: References: <507D691F.9000404@nlnetlabs.nl> <50868055.6030809@sidn.nl> <20121023132955.GH21418@miek.nl> <311AADB4-956F-499B-971A-AE0D8BB3921B@ucd.ie> <5086A308.80202@ogud.com> In-Reply-To: <5086A308.80202@ogud.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.156.18] Subject: Re: [DNSOP] Changes since draft-ietf-dnsop-rfc4641bis-13 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 14:39:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23-10-12 16:00, Olafur Gudmundsson wrote: > While I think the idea of passing keys though the registry between > operator has some merit I do not see it as viable alternative > outside few cc'tld's thus it it does not deserve to be included in > a BCP without full debate. I gave 4 reasons, not one. Running code and current practice being important ones for the IETF. But most of all, I fail to see the motivation for the current advice in the document. If there is no motivation but just an opinion, I think the advice should be deleted from the document. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQhqwYAAoJEDqHrM883AgnEcMIAI0wvqBbWwHiC5G6pJ2PjyOd ejdQ2F/VeA2AqE6IAsQ7nkhTgaeKwg5JNEMQXFNagZgwPLxKT8XAuFW7+WsbTivy zEqNbgNV/sDSPLjmW3qJ7Lh4PZArOsgrv5I/bDLOnZI6PPCHBb4j7LnN5pMZMy3R A71P8A/WhPUo+1GK1rpz97kS9gcr+2B1LoLsm1dSnrJn4sFk8s+zHa6b4KhjpgWE NtStUf7D44ffBcZUrdhK63KqQ4RY1sLxSXMyFZMU3WOVBJ+SnUTCLIe+GVM1d0T9 /zeBl0G3ohuVAWKj3IG3bSlUfzN6rdMi9sW82dGx+Grb9g1VUMr1ywSN5d16eMw= =2P9F -----END PGP SIGNATURE----- From matthijs@nlnetlabs.nl Wed Oct 24 07:36:51 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A984E21F8A07 for ; Wed, 24 Oct 2012 07:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgDTVa5xRKiq for ; Wed, 24 Oct 2012 07:36:50 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6455E21F89F6 for ; Wed, 24 Oct 2012 07:36:50 -0700 (PDT) Received: from [213.154.224.18] (zoidberg.nlnetlabs.nl [213.154.224.18]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q9OEadWH078868 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 24 Oct 2012 16:36:40 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q9OEadWH078868 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1351089404; bh=kWNBodfL/1KFE4hsrGM7Rof/rwiMjmv1ZY3hiTQV+6I=; h=Date:From:To:Subject:References:In-Reply-To; b=bPQy17N1eeM3sHPML91mSaMdUk3HbuZtXal5AImebzowEsFsjzPg9aSUx2EwrKB6+ 76oorTtdThs0zttv6eam3XgyVITJWvV97dDMuYckzTozNVPK8CWeL+fu709LcT8Bkx RjBpeeXWVL1Z3xOQoZZphxj6ZD1KDL2TniziGFsk= Message-ID: <5087FCF8.4020704@nlnetlabs.nl> Date: Wed, 24 Oct 2012 16:36:40 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <507D691F.9000404@nlnetlabs.nl> <50868055.6030809@sidn.nl> In-Reply-To: <50868055.6030809@sidn.nl> X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDC45CC227C24F048316F18AF" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 24 Oct 2012 16:36:40 +0200 (CEST) Subject: Re: [DNSOP] Changes since draft-ietf-dnsop-rfc4641bis-13 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 14:36:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDC45CC227C24F048316F18AF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I am against changing the suggestion in Section 4.3.2, even though you provide practices that in one legitimate case DNSKEY is preferred over DS. Such a change would in my opinion have to go through the working group and reach consensus there and I am afraid it is way too late for that. I would not be surprised that after publication, we come up with even more considerations that are also legit and could have been in the incorporated into the document. But at this moment I would not like to discuss changes that delay publication, unless there is detected something fundamentally wrong with the document. Also note that this is to be an informational RFC, not a BCP. The document is not claiming that one approach is better than the other. It merely provides considerations and provides arguments that can help operators to make a well-thought decision. Best regards, Matthijs On 10/23/2012 01:32 PM, Antoin Verschuren wrote: > On 16-10-12 16:03, Matthijs Mekking wrote: >> Hi all, >=20 >> The document draft-ietf-dnsop-rfc464bis-13 has seen some issues >> while being in AUTH and RCF-EDITOR state. This e-mail will list all >> the suggested changes to address those issues. >=20 > While reading the proposed changes and the whole document again, I > noticed another paragraph that is no longer desired. > My question is that now that we do make some changes, it is advised > that this paragraph is also adjusted to fit current day practices. >=20 > The paragraph is 4.3.2. > The advice in this paragraph, which hasn't changed since 2009 when it > was first written down, has been overtaken by new insight and practices= =2E > It advises registries to store only DS in stead of DNSKEY material in > their database. This has proven to be impractical when deploying > DNSSEC on a large scale: >=20 > 1. Current practice proves that the majority of DNSSEC domains in the > world today is provisioned by sending a DNSKEY record to te registry, > and not DS. Running code for the majority of DNSSEC domains uses DNSKEY= =2E >=20 > 2. The old advice is based on the assumption that less errors are > being made when cutting and pasting a DS in a webinterface or reading > it since it is smaller than a DNSKEY. Current practice today however > is that this is all automated, and while provisioning 1.3 M DNSSEC > domains, we have not seen such errors. >=20 > 3. With more algorithms used for DNSSEC today, and some no longer > advised, registries want to hash the DNSKEY to DS themselves so they > don't need to go through a "contacting every child" nightmare when an > algorithm is no longer supported. The DS is owned by the parent, not > the child. Our practice shows that hashing is a minor operation by the > parent. It takes no real effort whatsoever in computation or time. >=20 > 4. The most important motivation for us to use DNSKEY is consistancy > with new processes that did not exist in 2009. DNSSEC secure transfers > (http://tools.ietf.org/id/draft-koch-dnsop-dnssec-operator-change-04.tx= t) > is the most important one. In a DNS-operator change, the operator > initiating the change needs to send his new KSK (DNSKEY/DS) to the > registry AND needs to relay his ZSK (DNSKEY). It is confusing that in > bootstrapping a delegation a DS needs to be sent, but when transfering > a DS AND ZSK DNSKEY needs to be sent. It is better to use DNSKEY in > both processes so a child operator is never burdened with calculating > a DS or having to think about 2 different fields in EPP that do not > have the same meaning. So our advise is to use DNSKEY syntax for both > KSK and ZSK when transfering to your parent. >=20 > So my advise is to either delete paragraph 4.3.2 since it is bad > advice (there is no convincing motivation given in this paragraph > anyway), or use the motivation given above to advise for using DNSKEY > over DS. >=20 > If needed, I'm willing to write text. >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 --------------enigDC45CC227C24F048316F18AF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQh/z7AAoJEA8yVCPsQCW5SvYH/3oDOSbFnB/W7jr8v7APj2GM Hr3s8pu9/O83lJUeCE8eQIF0977yaTpsAd3RR9+JIcymvq/GeLCdwtx5be71rhSo ZWWR07LwogMLnbSfrF8UFKMGymv7Z7S0+1aB1xdDpX+k0YvoHqFIURyow10TLmSn ltKAZ8AUzUZiM2pa/QAIqljh+PRNXsJ4hQYYWijCmulNkqrZZK9HDwt0ouJSkgl7 Ryudi9W01hOdbpqH0gQqn9ieoIkGNzkI1mdOuEpvzzQZS0CQzrKHrlcq9X1oOWFu WbZmmxnY+WYiFoz2nDsS7BDH/67WuAjiMoSEfO3rK830ADGbCH309/vCcq6zrwo= =fLWL -----END PGP SIGNATURE----- --------------enigDC45CC227C24F048316F18AF-- From peter.van.dijk@netherlabs.nl Fri Oct 26 05:54:41 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF81C21F86E3 for ; Fri, 26 Oct 2012 05:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LDHd4r7RXAW for ; Fri, 26 Oct 2012 05:54:41 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF50C21F84C0 for ; Fri, 26 Oct 2012 05:54:39 -0700 (PDT) Received: from [IPv6:2001:980:906e:1:e008:f489:ceeb:93a4] (unknown [IPv6:2001:980:906e:1:e008:f489:ceeb:93a4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 7A58D1BB53; Fri, 26 Oct 2012 14:54:36 +0200 (CEST) From: Peter van Dijk Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Oct 2012 14:54:36 +0200 To: dnsop@ietf.org Message-Id: <54B9D70A-8A29-4778-B054-E0CF4407A7AD@netherlabs.nl> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [DNSOP] RFC2308/6604 violation in NSD and BIND? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 12:54:42 -0000 Hello, first of all, let me say that I could be wrong. Both NSD and BIND = violating an RFC in the same way does not sound like the most likely scenario to me. However, I want to be sure. For a CNAME pointing to a non-existing name in the same zone, BIND and = NSD return NOERROR, and do not include a SOA record in the AUTHORITY = section. According to my reading of RFC2308 section 1 (definition of QNAME) and = section 2.1, they should return NXDOMAIN and include the SOA. RFC6604 (which updates 2308) section 3 restates, according to my = reading, the same. Given a zone example.com with the usual records (SOA, couple of NSes) at = the apex, plus these records: ns1 IN A 192.168.1.1 ns2 IN A 192.168.1.2 nxd IN CNAME nxdomain.example.com. BIND returns: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49021 ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3 ;; QUESTION SECTION: ;nxd.example.com. IN ANY ;; ANSWER SECTION: nxd.example.com. 120 IN CNAME nxdomain.example.com. ;; AUTHORITY SECTION: example.com. 120 IN NS ns2.example.com. example.com. 120 IN NS ns1.example.com. ;; ADDITIONAL SECTION: ns1.example.com. 120 IN A 192.168.1.1 ns2.example.com. 120 IN A 192.168.1.2 NSD returns the same minus the ra flag. PowerDNS, however, returns: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34897 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 2800 ;; QUESTION SECTION: ;nxd.example.com. IN A ;; ANSWER SECTION: nxd.example.com. 120 IN CNAME nxdomain.example.com. ;; AUTHORITY SECTION: example.com. 86400 IN SOA ns1.example.com. = ahu.example.com. 2000081501 28800 7200 604800 86400 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#5300(127.0.0.1) ;; WHEN: Fri Oct 26 13:06:46 2012 ;; MSG SIZE rcvd: 111 The relevant difference here is NXDOMAIN instead of NOERROR, and the = addition of the SOA. PowerDNS not including the NS records plus their IPs is inconsequential to the issue, as far as I can tell. On a sidenote, NSD does include an NSEC3 denying existence of nxdomain.example.com when DNSSEC+NSEC3 are enabled. I did not verify = this for BIND. PowerDNS currently does not generate this NSEC3 but this will be = fixed shortly. Opinions welcome! Kind regards, --=20 Peter van Dijk Netherlabs Computer Consulting BV - http://www.netherlabs.nl/ From marka@isc.org Fri Oct 26 06:13:11 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CB021F8574 for ; Fri, 26 Oct 2012 06:13:11 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5HzeTMFRFfs for ; Fri, 26 Oct 2012 06:13:10 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id AC3A721F8676 for ; Fri, 26 Oct 2012 06:13:10 -0700 (PDT) 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)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 80778C94E4; Fri, 26 Oct 2012 13:13:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:1c7a:745f:337c:ef4c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3E9EF216C3D; Fri, 26 Oct 2012 13:13:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id EF1C92A51FBD; Sat, 27 Oct 2012 00:12:56 +1100 (EST) To: Peter van Dijk From: Mark Andrews References: <54B9D70A-8A29-4778-B054-E0CF4407A7AD@netherlabs.nl> In-reply-to: Your message of "Fri, 26 Oct 2012 14:54:36 +0200." <54B9D70A-8A29-4778-B054-E0CF4407A7AD@netherlabs.nl> Date: Sat, 27 Oct 2012 00:12:56 +1100 Message-Id: <20121026131256.EF1C92A51FBD@drugs.dv.isc.org> Cc: dnsop@ietf.org Subject: Re: [DNSOP] RFC2308/6604 violation in NSD and BIND? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 13:13:11 -0000 In message <54B9D70A-8A29-4778-B054-E0CF4407A7AD@netherlabs.nl>, Peter van Dijk writes: > Hello, > > first of all, let me say that I could be wrong. Both NSD and BIND violating an > RFC in the same way does not sound like the most likely scenario to me. > However, I want to be sure. > > For a CNAME pointing to a non-existing name in the same zone, BIND and NSD > return NOERROR, and do not include a SOA record in the AUTHORITY section. > According to my reading of RFC2308 section 1 (definition of QNAME) and section > 2.1, they should return NXDOMAIN and include the SOA. > > RFC6604 (which updates 2308) section 3 restates, according to my reading, the > same. > > Given a zone example.com with the usual records (SOA, couple of NSes) at the > apex, plus these records: > > ns1 IN A 192.168.1.1 > ns2 IN A 192.168.1.2 > nxd IN CNAME nxdomain.example.com. > > BIND returns: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49021 > ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3 > > ;; QUESTION SECTION: > ;nxd.example.com. IN ANY > > ;; ANSWER SECTION: > nxd.example.com. 120 IN CNAME nxdomain.example.com. > > ;; AUTHORITY SECTION: > example.com. 120 IN NS ns2.example.com. > example.com. 120 IN NS ns1.example.com. > > ;; ADDITIONAL SECTION: > ns1.example.com. 120 IN A 192.168.1.1 > ns2.example.com. 120 IN A 192.168.1.2 You asked a ANY query. ANY and CNAME have different processing rules. The query is NOT restarted with the target of the CNAME. See RFC 1034. > NSD returns the same minus the ra flag. > > PowerDNS, however, returns: You asked a different question (A != ANY). If you want to compare answers you need to ask IDENTICAL questions. > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34897 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 2800 > ;; QUESTION SECTION: > ;nxd.example.com. IN A > > ;; ANSWER SECTION: > nxd.example.com. 120 IN CNAME nxdomain.example.com. > > ;; AUTHORITY SECTION: > example.com. 86400 IN SOA ns1.example.com. ahu.example.com. 2000081501 28800 7200 604800 86400 > > ;; Query time: 1 msec > ;; SERVER: 127.0.0.1#5300(127.0.0.1) > ;; WHEN: Fri Oct 26 13:06:46 2012 > ;; MSG SIZE rcvd: 111 > > > The relevant difference here is NXDOMAIN instead of NOERROR, and the addition > of the SOA. PowerDNS not including the NS records plus their IPs is > inconsequential to the issue, as far as I can tell. > > On a sidenote, NSD does include an NSEC3 denying existence of > nxdomain.example.com when DNSSEC+NSEC3 are enabled. I did not verify this for > BIND. PowerDNS currently does not generate this NSEC3 but this will be fixed > shortly. > > Opinions welcome! > > Kind regards, > -- > Peter van Dijk > Netherlabs Computer Consulting BV - http://www.netherlabs.nl/ > > _______________________________________________ > 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 paul@nohats.ca Fri Oct 26 06:18:21 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8997721F85C6 for ; Fri, 26 Oct 2012 06:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cddt2Zx705mC for ; Fri, 26 Oct 2012 06:18:21 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1256C21F8599 for ; Fri, 26 Oct 2012 06:18:21 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 2504E82A2D; Fri, 26 Oct 2012 09:17:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1732F8051A; Fri, 26 Oct 2012 09:17:43 -0400 (EDT) Date: Fri, 26 Oct 2012 09:17:43 -0400 (EDT) From: Paul Wouters To: Peter van Dijk In-Reply-To: <54B9D70A-8A29-4778-B054-E0CF4407A7AD@netherlabs.nl> Message-ID: References: <54B9D70A-8A29-4778-B054-E0CF4407A7AD@netherlabs.nl> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] RFC2308/6604 violation in NSD and BIND? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 13:18:21 -0000 On Fri, 26 Oct 2012, Peter van Dijk wrote: > nxd IN CNAME nxdomain.example.com. > PowerDNS currently does not generate this NSEC3 but this will be fixed shortly. You would return an NSEC3 record for a record that actually exists? That would be a very inconsistent nsec/nsec3 chain. How would offline signers deal with this? Pregenerate nsec records for data that _is_ in the zone? It would also create a really odd behaviour difference between CNAMEs pointing to non-existing in-zone, versus non-existint out-of-zone destinations. So my feeling, without having read the RFCs you quote, would be to say that bind and nsd are correct in their behaviour, and that this might be (or shoudl be) an errata to the RFCs. Paul From peter.van.dijk@netherlabs.nl Fri Oct 26 06:25:31 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2CA21F85EB for ; Fri, 26 Oct 2012 06:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wkzi7o0N3W7r for ; Fri, 26 Oct 2012 06:25:30 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) by ietfa.amsl.com (Postfix) with ESMTP id B693E21F85E8 for ; Fri, 26 Oct 2012 06:25:30 -0700 (PDT) Received: from [IPv6:2001:980:906e:1:e008:f489:ceeb:93a4] (unknown [IPv6:2001:980:906e:1:e008:f489:ceeb:93a4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 07F781BB53; Fri, 26 Oct 2012 15:25:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Peter van Dijk In-Reply-To: <20121026131256.EF1C92A51FBD@drugs.dv.isc.org> Date: Fri, 26 Oct 2012 15:25:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <347ABF7A-8184-4CE4-B087-C057441F5F52@netherlabs.nl> References: <54B9D70A-8A29-4778-B054-E0CF4407A7AD@netherlabs.nl> <20121026131256.EF1C92A51FBD@drugs.dv.isc.org> To: dnsop@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [DNSOP] RFC2308/6604 violation in NSD and BIND? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 13:25:31 -0000 Hello Mark, Thank you for your swift and accurate response. On Oct 26, 2012, at 15:12 , Mark Andrews wrote: >=20 > You asked a ANY query. ANY and CNAME have different processing rules. > The query is NOT restarted with the target of the CNAME. See RFC = 1034. >=20 >> NSD returns the same minus the ra flag. >>=20 >> PowerDNS, however, returns: >=20 > You asked a different question (A !=3D ANY). If you want to compare > answers you need to ask IDENTICAL questions. My mistake. NSD: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34556 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;nxd.example.com. IN A ;; ANSWER SECTION: nxd.example.com. 120 IN CNAME nxdomain.example.com. BIND, PowerDNS (same except for ra flag) ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4382 ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;nxd.example.com. IN A ;; ANSWER SECTION: nxd.example.com. 120 IN CNAME nxdomain.example.com. ;; AUTHORITY SECTION: example.com. 86400 IN SOA ns1.example.com. = ahu.example.com. 2000081501 28800 7200 604800 86400 To be complete:=20 - for the A query, BIND and PowerDNS return NXDOMAIN+SOA, NSD returns = NOERROR. - for the ANY query, NSD and BIND return NOERROR, PowerDNS returns NXDOMAIN+SOA. Then, as far as I can tell, BIND and PowerDNS do the right thing for the = A query. NSD and BIND do the right thing for the ANY query, going from = Mark's interpretation of the RFCs. However, 2308 and 6604 totally ignore the ANY exception to following = CNAME chains, and one might argue that thus, 2308 and 6604 still mean that = QNAME is the end of the CNAME chain in the response, and the RCODE thus should be NXDOMAIN. I think this argument could go either way. Unless conflicting opinions come in, I will fix PowerDNS to do the right = thing for ANY, and will report the A query issue to the NSD developers. Kind regards, --=20 Peter van Dijk Netherlabs Computer Consulting BV - http://www.netherlabs.nl/ From peter.van.dijk@netherlabs.nl Fri Oct 26 06:27:43 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0313A21F8606 for ; Fri, 26 Oct 2012 06:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao+qps-B8jDt for ; Fri, 26 Oct 2012 06:27:42 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E3021F8633 for ; Fri, 26 Oct 2012 06:27:42 -0700 (PDT) Received: from [IPv6:2001:980:906e:1:e008:f489:ceeb:93a4] (unknown [IPv6:2001:980:906e:1:e008:f489:ceeb:93a4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id CDED21BB53; Fri, 26 Oct 2012 15:27:41 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Peter van Dijk In-Reply-To: Date: Fri, 26 Oct 2012 15:27:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54B9D70A-8A29-4778-B054-E0CF4407A7AD@netherlabs.nl> To: dnsop@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [DNSOP] RFC2308/6604 violation in NSD and BIND? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 13:27:43 -0000 Hello Paul, On Oct 26, 2012, at 15:17 , Paul Wouters wrote: > On Fri, 26 Oct 2012, Peter van Dijk wrote: >=20 >> nxd IN CNAME nxdomain.example.com. >=20 >> PowerDNS currently does not generate this NSEC3 but this will be = fixed shortly. >=20 > You would return an NSEC3 record for a record that actually > exists? That would be a very inconsistent nsec/nsec3 chain. nxdomain.example.com does not exist. > How would offline signers deal with this? Pregenerate nsec records > for data that _is_ in the zone? Offline signers would already have generated the NSEC(3) that denies = existence of nxdomain.example.com, simply by virtue of the name not existing in = the zone. Kind regards, --=20 Peter van Dijk Netherlabs Computer Consulting BV - http://www.netherlabs.nl/ From ogud@ogud.com Fri Oct 26 06:53:54 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7DD21F84A2 for ; Fri, 26 Oct 2012 06:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.296 X-Spam-Level: X-Spam-Status: No, score=-103.296 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7x4rQpQMmba for ; Fri, 26 Oct 2012 06:53:54 -0700 (PDT) Received: from smtp155.iad.emailsrvr.com (smtp155.iad.emailsrvr.com [207.97.245.155]) by ietfa.amsl.com (Postfix) with ESMTP id 266AE21F84A6 for ; Fri, 26 Oct 2012 06:53:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp25.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 3AFB9300CF3; Fri, 26 Oct 2012 09:53:53 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp25.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id AC0F3300CCB; Fri, 26 Oct 2012 09:53:51 -0400 (EDT) Message-ID: <508A95ED.2020501@ogud.com> Date: Fri, 26 Oct 2012 09:53:49 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <54B9D70A-8A29-4778-B054-E0CF4407A7AD@netherlabs.nl> <20121026131256.EF1C92A51FBD@drugs.dv.isc.org> <347ABF7A-8184-4CE4-B087-C057441F5F52@netherlabs.nl> In-Reply-To: <347ABF7A-8184-4CE4-B087-C057441F5F52@netherlabs.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [DNSOP] RFC2308/6604 violation in NSD and BIND? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 13:53:54 -0000 Strictly speaking this is dnsext fodder not dnsop as the RFC's quoted are under DNSEXT change control. Please move the discussion there. On 26/10/2012 09:25, Peter van Dijk wrote: > Hello Mark, > > Thank you for your swift and accurate response. > > On Oct 26, 2012, at 15:12 , Mark Andrews wrote: > >> >> You asked a ANY query. ANY and CNAME have different processing rules. >> The query is NOT restarted with the target of the CNAME. See RFC 1034. >> >>> NSD returns the same minus the ra flag. >>> >>> PowerDNS, however, returns: >> >> You asked a different question (A != ANY). If you want to compare >> answers you need to ask IDENTICAL questions. > > My mistake. > > NSD: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34556 > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; QUESTION SECTION: > ;nxd.example.com. IN A > > ;; ANSWER SECTION: > nxd.example.com. 120 IN CNAME nxdomain.example.com. This is perfectly OK as NSD in this case is not performing the optional server side CNAME processing. The cname exists thus this is a valid answer and valid RCODE. A recursive resolver now has to ask for nxdomain.example.com and will get the no name error. > > BIND, PowerDNS (same except for ra flag) > > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4382 > ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 > ;; QUESTION SECTION: > ;nxd.example.com. IN A > > ;; ANSWER SECTION: > nxd.example.com. 120 IN CNAME nxdomain.example.com. > > ;; AUTHORITY SECTION: > example.com. 86400 IN SOA ns1.example.com. ahu.example.com. 2000081501 28800 7200 604800 86400 > This is fine as well but harder to understand :-) as the RCODE refers to the target of the CNAME not the qname. > > To be complete: > > - for the A query, BIND and PowerDNS return NXDOMAIN+SOA, NSD returns NOERROR. > - for the ANY query, NSD and BIND return NOERROR, PowerDNS returns > NXDOMAIN+SOA. > > Then, as far as I can tell, BIND and PowerDNS do the right thing for the A > query. NSD and BIND do the right thing for the ANY query, going from Mark's > interpretation of the RFCs. > > However, 2308 and 6604 totally ignore the ANY exception to following CNAME > chains, and one might argue that thus, 2308 and 6604 still mean that QNAME is > the end of the CNAME chain in the response, and the RCODE thus should be > NXDOMAIN. I think this argument could go either way. > s > Unless conflicting opinions come in, I will fix PowerDNS to do the right thing > for ANY, and will report the A query issue to the NSD developers. > In the case of ANY IMHO no CNAME processing should take place. And I encourage you to file errata against the RFC's that we can discuss on the dnsext mailing list, before it is approved. > Kind regards, > Good observations. thanks Olafur From paul@nohats.ca Fri Oct 26 07:02:01 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FAC21F84C4 for ; Fri, 26 Oct 2012 07:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QA3LhdUin+c6 for ; Fri, 26 Oct 2012 07:02:00 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 787C621F84E6 for ; Fri, 26 Oct 2012 07:02:00 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 493CE82A2D; Fri, 26 Oct 2012 10:01:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 418878051A; Fri, 26 Oct 2012 10:01:24 -0400 (EDT) Date: Fri, 26 Oct 2012 10:01:24 -0400 (EDT) From: Paul Wouters To: Peter van Dijk In-Reply-To: Message-ID: References: <54B9D70A-8A29-4778-B054-E0CF4407A7AD@netherlabs.nl> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] RFC2308/6604 violation in NSD and BIND? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 14:02:01 -0000 On Fri, 26 Oct 2012, Peter van Dijk wrote: > On Oct 26, 2012, at 15:17 , Paul Wouters wrote: > >> On Fri, 26 Oct 2012, Peter van Dijk wrote: >> >>> nxd IN CNAME nxdomain.example.com. >> >>> PowerDNS currently does not generate this NSEC3 but this will be fixed shortly. >> >> You would return an NSEC3 record for a record that actually >> exists? That would be a very inconsistent nsec/nsec3 chain. > > nxdomain.example.com does not exist. > >> How would offline signers deal with this? Pregenerate nsec records >> for data that _is_ in the zone? > > Offline signers would already have generated the NSEC(3) that denies existence > of nxdomain.example.com, simply by virtue of the name not existing in the > zone. But wouldn't the chain be built based on LHS? Let's check opendnssec: [root@nohats signed]# ldns-nsec3-hash cname.nohats.ca. -t 5 javgjvs1ictdbmts0fcjome4s37kndg0. [root@nohats signed]# grep javg nohats.ca javgjvs1ictdbmts0fcjome4s37kndg0.nohats.ca. 3600 IN NSEC3 1 0 5 - jn89c3qpvavcumn3cv172r7gbu8h6ffs CNAME RRSIG javgjvs1ictdbmts0fcjome4s37kndg0.nohats.ca. 3600 IN RRSIG NSEC3 8 3 3600 20121109223118 20121026121347 52368 nohats.ca. zjkB06zMPYIAdtGnWoA3wRqe2Fg5y4Y7R21qaQovhqXtijwMQJfukhKA4OWO4oj5DVL/v0WTZRJII64XuAUzVs9RZMAcCuDceR0BdAT5CgjbkvEwgq08/PI06hXvScTjPzFSRPPfRJ3ViAinFDPd2JZHgMkTO9Wen0KkVPH/vhc= ioukpqjt07l1b83ppfd1grdcc57864ja.nohats.ca. 3600 IN NSEC3 1 0 5 - javgjvs1ictdbmts0fcjome4s37kndg0 A RRSIG So cname.nohats.ca is part of the nsec3 chain. So in some sense, the record "exists". I guess validators would have to be very careful handling the NXDOMAIN, they might decide it is spoofed because they have an existing NSEC/NSEC3 entry for it. Odd corner case. Paul