From owner-namedroppers@ops.ietf.org Thu Oct 1 00:45:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B533A67D1; Thu, 1 Oct 2009 00:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31Xx6hnvg-wt; Thu, 1 Oct 2009 00:45:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F09DA3A67A1; Thu, 1 Oct 2009 00:45:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtGI8-000L1c-Ou for namedroppers-data0@psg.com; Thu, 01 Oct 2009 07:41:32 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtGHy-000L0h-UT for namedroppers@ops.ietf.org; Thu, 01 Oct 2009 07:41:30 +0000 Received: from [IPv6:2001:610:719:1:221:5dff:fe1e:113a] (unknown [IPv6:2001:610:719:1:221:5dff:fe1e:113a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id DB707E601E for ; Thu, 1 Oct 2009 07:41:21 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item From: Shane Kerr To: namedroppers In-Reply-To: References: <200909291910.VAA21152@TR-Sys.de> <1254304337.6754.7867.camel@shane-asus-laptop> <61143.1254313657@nsa.vix.com> <76575.1254333207@nsa.vix.com> Content-Type: text/plain Organization: ISC Date: Thu, 01 Oct 2009 09:41:18 +0200 Message-Id: <1254382878.14707.490.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: All, On Wed, 2009-09-30 at 11:06 -0700, Matthew Dempsky wrote: > On Wed, Sep 30, 2009 at 10:53 AM, Paul Vixie wrote: > >> Date: Wed, 30 Sep 2009 10:31:57 -0700 > >> From: Matthew Dempsky > >> > >> Is your concern that these newly suggested records shouldn't be stored > >> under example.com but instead under ns{1,2,3,...}.example.com, or that > >> parent servers should not need to know about or serve these new records? > > > > both, though i'd say that if we have a new NSCAP RR located adjacent to > > the A/AAAA RRs, then this should be returned as glue in delegations, so > > as to prevent anybody from having to look up these new RRsets. in that > > sense, there is a change in behaviour at the parent, even though it's in > > the nameserver behaviour and not in the zone content itself. > > Okay, I concur with this then. Me too. I didn't intend that any additional records "live" in the parent, like DS records. I still think it would be nice to have a way for glue (or DS records) to be automatically updated somehow. -- Shane From owner-namedroppers@ops.ietf.org Thu Oct 1 00:46:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8573A67F2; Thu, 1 Oct 2009 00:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEmM-ttbb6wT; Thu, 1 Oct 2009 00:46:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D6933A67D1; Thu, 1 Oct 2009 00:46:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtGM4-000LO5-BQ for namedroppers-data0@psg.com; Thu, 01 Oct 2009 07:45:36 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtGLq-000LMz-3w for namedroppers@ops.ietf.org; Thu, 01 Oct 2009 07:45:34 +0000 Received: from [IPv6:2001:7b8:206:1:226:b0ff:fee2:a770] ([IPv6:2001:7b8:206:1:226:b0ff:fee2:a770]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n917jGk7093739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Oct 2009 09:45:16 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-5--949474208; protocol="application/pkcs7-signature"; micalg=sha1 From: Olaf Kolkman In-Reply-To: <76575.1254333207@nsa.vix.com> Date: Thu, 1 Oct 2009 09:45:16 +0200 Cc: namedroppers Message-Id: <065B6A34-5557-4BA7-AE09-2FDE2518A9AC@NLnetLabs.nl> References: <200909291910.VAA21152@TR-Sys.de> <1254304337.6754.7867.camel@shane-asus-laptop> <61143.1254313657@nsa.vix.com> <76575.1254333207@nsa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 01 Oct 2009 09:45:16 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --Apple-Mail-5--949474208 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On Sep 30, 2009, at 7:53 PM, Paul Vixie wrote: > > both, though i'd say that if we have a new NSCAP RR located adjacent > to > the A/AAAA RRs, then this should be returned as glue in delegations, > so > as to prevent anybody from having to look up these new RRsets. in > that > sense, there is a change in behaviour at the parent, even though > it's in > the nameserver behaviour and not in the zone content itself. Hmm, If you follow this path the provisioner of the zone would need to obtain up-to-date data from the name server operator's environment and keep it consistent. I haven't been talking to some of my secondary server operators for years and I am sure they upgraded the nameserver software, nameservers's OS, firewalls and other network components. --Olaf ________________________________________________________ Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam --Apple-Mail-5--949474208 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMTCCBS0w ggMVoAMCAQICAwbqdTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA1MjUwODQ4MTJaFw0x MTA1MjUwODQ4MTJaMDkxFTATBgNVBAMTDE9sYWYgS29sa21hbjEgMB4GCSqGSIb3DQEJARYRb2xh ZkBubG5ldGxhYnMubmwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxtZNngmuLgcf rto+Uax1WhonECqb5W8US2Z+ZPw/ASKsjKEF8Wa3Nnispys6Gj9Sl7C1X0/2pH//qauLpBqA+lHW L9mgdGW1T9KU1Fb8Odqw0PBnIIhbLNQzecZL+BchEetcrubplQWzDOpROCJ00IwXksusBiKqhew4 u7X2QoraW+z32Knj5ogajIhdkAeBHUy1pwXsk/mDnV8cIEdz1MhaZWDSn7kJUQtRMVCpFBjVoiXh ToXMJfiMvn0CKaeFxFm72dcdzvFsw906Ndafd2MOfdP7QSsTVP6sG9am790AOgkzxT5CM77IDPbD zxZlQ8jTdhcp/WtUrFWIU4QBAgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRw Oi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3 CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZo dHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW9sYWZAbmxuZXRsYWJzLm5sMA0GCSqG SIb3DQEBBQUAA4ICAQCLpawAoUQAxivf6blyMswVokRmDl2JGEbtmEu8j0h1BVOlGh6hlI8WaeWy 3x2jJ9uun3VK6oYnHy45ez+dUDjBLjOZdAgwFg225lm1OPdmisghDDVwCIiEogHPqmJtvKYMFoPF 3iFUambJDoQF8DeVeg8ctDvsxsaVGjA8OrMpo0K4I11vnNbCLv7mWCjnaZWt/6Y6TD8ErHQl5dmI rpsHmEZx1/nsocdPkZGRA4QVf1omYHUNs79DtxpYdGKHoorpBNzlzIIjpceiqeOeykoDeYLTZX2G c7Mh4Gdj2MHFqZucxV1cHibb8XKv8ebaGltMV5SrciqRn8yFXmiyTvmId6myNXLiOx+VJiGbLSS3 TltM/kf7UejXeEHulEKufU6Ya6EfH7W2/spTayYCauyLljOjE2Ey5A4oIoJV9eY64OCDuLF2nmGR jOh3JB9nGkZIPhmTUwGZnMELLhzKz+eOZoulM4tXH6KEubed1shQEq1dkJ+tFtRS3Lm+vLCKWvVo 1iZScqPaQf9riPApAVrL+3Wat0p/jtCk5gLBF02uTiWvT2t4ZfSHMEBXR7CvVm58etRQuyZSMHyz UQC4wkDvCeVawNRCZjq6wWdvx5hmr2JeDSkkRtSZ/Fa1WXf26b3BZugI75p5JXafbWdOTRpNc8M5 YMk7tx29ZG3u0qODgDGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMG6nUwCQYFKw4DAhoFAKCCAYcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMDAxMDc0NTE2WjAj BgkqhkiG9w0BCQQxFgQU0SJRwEyM5PDLh1M2d1U/i6Ulz6UwgZEGCSsGAQQBgjcQBDGBgzCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDBup1MIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBB dXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBup1MA0GCSqGSIb3 DQEBAQUABIIBAF4PhaZgT31xVCVUnyOdSg0izWCkThc83CUXankAualuUENRGjWyAtI9qwy28Zsm PA61EKYTm3ksuADXTdkK04mLTrS0T1IWWdekxVDzbDiVuDZ0Eyigco1NeC2LOlJMO/P88cEDqcQ/ NclmhJRi/FnqU3R0LsGAH5q6hFr9VJB0TFHAVbJfeyU1bsY7nznlFb4dTzVMBZQjXJn4bcWwSdBt 2XQIr/mh8/KikApUXe0nt6j/Wmi1B8J4IOrZnJQDTgz3JGI3FRyQYhzKVciC1YXL+PH7cqJZG6Mj T/zhiAFpWLY4VSKddFscr4UdEZHdRxwH6XqynlFHwwrWVmtyFqEAAAAAAAA= --Apple-Mail-5--949474208-- From owner-namedroppers@ops.ietf.org Thu Oct 1 03:41:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9977728C107; Thu, 1 Oct 2009 03:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.25 X-Spam-Level: **** X-Spam-Status: No, score=4.25 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7NCWxyFihOU; Thu, 1 Oct 2009 03:41:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4DB2928C101; Thu, 1 Oct 2009 03:41:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtJ1k-000615-Lv for namedroppers-data0@psg.com; Thu, 01 Oct 2009 10:36:48 +0000 Received: from [195.188.213.8] (helo=smtp-out5.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtJ1a-00060I-E1 for namedroppers@ops.ietf.org; Thu, 01 Oct 2009 10:36:46 +0000 Received: from [172.23.170.138] (helo=anti-virus01-09) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1MtJ1F-0007Uw-8Y; Thu, 01 Oct 2009 11:36:17 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MtJ1E-0005FV-3F; Thu, 01 Oct 2009 11:36:16 +0100 Message-ID: <43D49700AEC84BB0B8D1E7431AA5692A@localhost> From: "George Barwood" To: "Olaf Kolkman" , "Paul Vixie" Cc: "namedroppers" References: <200909291910.VAA21152@TR-Sys.de> <1254304337.6754.7867.camel@shane-asus-laptop> <61143.1254313657@nsa.vix.com> <76575.1254333207@nsa.vix.com> <065B6A34-5557-4BA7-AE09-2FDE2518A9AC@NLnetLabs.nl> Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item Date: Thu, 1 Oct 2009 11:36:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk9sYWYgS29sa21hbiIgPG9s YWZATkxuZXRMYWJzLm5sPg0KVG86ICJQYXVsIFZpeGllIiA8dml4aWVAaXNjLm9yZz4NCkNjOiAi bmFtZWRyb3BwZXJzIiA8bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5 LCBPY3RvYmVyIDAxLCAyMDA5IDg6NDUgQU0NClN1YmplY3Q6IFJlOiBbZG5zZXh0XSBkcmFmdC1i YXJ3b29kLWRuc2V4dC1kbnMtdHJhbnNwb3J0LXNpZ25hbC0wMCB0byBXRyB3b3JrIGl0ZW0gDQoN Cg0KPiANCj4gT24gU2VwIDMwLCAyMDA5LCBhdCA3OjUzIFBNLCBQYXVsIFZpeGllIHdyb3RlOg0K PiANCj4+DQo+PiBib3RoLCB0aG91Z2ggaSdkIHNheSB0aGF0IGlmIHdlIGhhdmUgYSBuZXcgTlND QVAgUlIgbG9jYXRlZCBhZGphY2VudCAgDQo+PiB0bw0KPj4gdGhlIEEvQUFBQSBSUnMsIHRoZW4g dGhpcyBzaG91bGQgYmUgcmV0dXJuZWQgYXMgZ2x1ZSBpbiBkZWxlZ2F0aW9ucywgIA0KPj4gc28N Cj4+IGFzIHRvIHByZXZlbnQgYW55Ym9keSBmcm9tIGhhdmluZyB0byBsb29rIHVwIHRoZXNlIG5l dyBSUnNldHMuICBpbiAgDQo+PiB0aGF0DQo+PiBzZW5zZSwgdGhlcmUgaXMgYSBjaGFuZ2UgaW4g YmVoYXZpb3VyIGF0IHRoZSBwYXJlbnQsIGV2ZW4gdGhvdWdoICANCj4+IGl0J3MgaW4NCj4+IHRo ZSBuYW1lc2VydmVyIGJlaGF2aW91ciBhbmQgbm90IGluIHRoZSB6b25lIGNvbnRlbnQgaXRzZWxm Lg0KPiANCj4gDQo+IA0KPiBIbW0sICBJZiB5b3UgZm9sbG93IHRoaXMgcGF0aCB0aGUgcHJvdmlz aW9uZXIgb2YgdGhlIHpvbmUgd291bGQgbmVlZCAgDQo+IHRvIG9idGFpbiB1cC10by1kYXRlIGRh dGEgZnJvbSB0aGUgbmFtZSBzZXJ2ZXIgb3BlcmF0b3IncyBlbnZpcm9ubWVudCAgDQo+IGFuZCBr ZWVwIGl0IGNvbnNpc3RlbnQuIEkgaGF2ZW4ndCBiZWVuIHRhbGtpbmcgdG8gc29tZSBvZiBteSBz ZWNvbmRhcnkgIA0KPiBzZXJ2ZXIgb3BlcmF0b3JzIGZvciB5ZWFycyBhbmQgSSBhbSBzdXJlIHRo ZXkgdXBncmFkZWQgdGhlIG5hbWVzZXJ2ZXIgIA0KPiBzb2Z0d2FyZSwgbmFtZXNlcnZlcnMncyBP UywgZmlyZXdhbGxzIGFuZCBvdGhlciBuZXR3b3JrIGNvbXBvbmVudHMuDQoNClRoZSBub3JtYWwg c2l0dWF0aW9uIHdoZXJlIHlvdSBhcmUgdXNpbmcgYSBuYW1lIHNlcnZlciBub3QgdW5kZXINCnlv dXIgZGlyZWN0IGNvbnRyb2wgaXMgZm9yIHRoZSBuYW1lIHNlcnZlciB0byBiZSBvdXQtb2Ytem9u ZSwgYW5kIHRoZXJlZm9yZQ0KZ2x1ZSBBLCBBQUFBIGFuZCBUUE9SVCByZWNvcmRzIGRvIG5vdCBh cHBseS4gVGhlIHBhcmVudCB6b25lIGhhcw0KDQpleGFtcGxlLmNvbS4gTlMgbnMxLmV4YW1wbGUu bmV0Lg0KDQpJZiB0aGUgbmFtZSBzZXJ2ZXIgaXMgaW4tem9uZSwgdGhlbiBpdCBzaG91bGQgYmUg dW5kZXIgeW91ciBjb250cm9sLA0KYW5kIHlvdSBhcmUgcmVzcG9uc2libGUgZm9yIHN1cHBseWlu ZyBhbmQgbWFpbnRhaW5pbmcgY29ycmVjdCBnbHVlDQppbiB0aGUgcGFyZW50IHpvbmUuIFRoZSBw YXJlbnQgem9uZSBoYXMNCg0KZXhhbXBsZS5jb20uIE5TIG5zMS5leGFtcGxlLmNvbS4NCmV4YW1w bGUuY29tLiBBICAgIDE5Mi4wLjIuNQ0KZXhhbXBsZS5jb20uIFRQT1JUIFVEUCBUQ1AgUVJQIFND VFANCg0KT25seSBuYW1lIHNlcnZlciBvcGVyYXRvcnMgaGF2ZSB0byBiZSBjb25jZXJuZWQgd2l0 aCB0aGlzIHN0dWZmLg0KU28gSSBkb24ndCB0aGluayB0aGVyZSBpcyBhIHByb2JsZW0gaGVyZSwg dW5sZXNzIEkgaGF2ZSBtaXMtdW5kZXJzdG9vZCB5b3UuDQpIVEgsDQpHZW9yZ2UNCg0KPiAtLU9s YWYNCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gDQo+IE9sYWYgTS4gS29sa21hbiAgICAgICAgICAgICAgICAg ICAgICAgIE5MbmV0IExhYnMNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgU2NpZW5jZSBQYXJrIDE0MCwNCj4gaHR0cDovL3d3dy5ubG5ldGxhYnMubmwvICAgICAgICAg ICAgICAgMTA5OCBYRyBBbXN0ZXJkYW0NCj4gDQo+ From owner-namedroppers@ops.ietf.org Thu Oct 1 04:04:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6C528C114; Thu, 1 Oct 2009 04:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[AWL=-0.162, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luekP8lwgWmF; Thu, 1 Oct 2009 04:04:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6158228C0F6; Thu, 1 Oct 2009 04:04:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtJQw-000Bfw-1E for namedroppers-data0@psg.com; Thu, 01 Oct 2009 11:02:50 +0000 Received: from [195.54.233.70] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtJQm-000Bf2-Si for namedroppers@ops.ietf.org; Thu, 01 Oct 2009 11:02:48 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by hutch.rfc1035.com (Postfix) with ESMTP id 731C8154283B; Thu, 1 Oct 2009 12:02:36 +0100 (BST) From: Jim Reid To: George Barwood In-Reply-To: <8F0B2F9E393C4B72B74BC1855C3EA5FE@localhost> Subject: Re: [dnsext] draft-ietf-dnsext-rfc2671bis-edns0 X-Priority: 3 References: <8F0B2F9E393C4B72B74BC1855C3EA5FE@localhost> Message-Id: <54838189-6A9C-4D27-90CE-3E1385BDA913@rfc1035.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Oct 2009 12:02:36 +0100 Cc: X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 1 Oct 2009, at 07:27, George Barwood wrote: > The limit must not be higher than 4096 bytes. Why not 4095 or 4097? Justify your choice of 4096. It's nonsense anyway. Suppose some response is 6K. The client does a lookup saying it can accept up to 8K over EDNS. The server can handle an 8K EDNS response. Under your scheme, it wouldn't be allowed to do that. The 6K reply would not be sent, even though both parties can handle it. That would result in a truncated response and TCP retry, which is stupid. The current Security Considerations of the draft are fine as they are. Your suggested changes are not helpful or relevant. Language about DNS amplification attacks (yawn) does not belong in this draft/RFC. That should go in a draft to dnsop, if it goes in a draft at all. From owner-namedroppers@ops.ietf.org Thu Oct 1 04:06:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F161028C0F6; Thu, 1 Oct 2009 04:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbqJbQzhJuCf; Thu, 1 Oct 2009 04:06:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E9383A6890; Thu, 1 Oct 2009 04:06:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtJPy-000BO4-9b for namedroppers-data0@psg.com; Thu, 01 Oct 2009 11:01:50 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtJNw-000Anq-8G for namedroppers@ops.ietf.org; Thu, 01 Oct 2009 10:59:52 +0000 Received: from dhcp-15.nlnetlabs.nl (dhcp-15.nlnetlabs.nl [213.154.224.78]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n91AxWbT010671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Oct 2009 12:59:32 +0200 (CEST) (envelope-from olaf@nlnetlabs.nl) Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-13--937818314; protocol="application/pkcs7-signature"; micalg=sha1 From: Olaf Kolkman X-Priority: 3 In-Reply-To: <154CCCC1933F48789B247B2A0C2B263B@localhost> Date: Thu, 1 Oct 2009 12:59:32 +0200 Cc: "Paul Vixie" , "namedroppers" Message-Id: <4B356546-0F9D-4144-A343-48CB732E3EB4@nlnetlabs.nl> References: <154CCCC1933F48789B247B2A0C2B263B@localhost> To: "George Barwood" X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [213.154.224.1]); Thu, 01 Oct 2009 12:59:32 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --Apple-Mail-13--937818314 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On Oct 1, 2009, at 12:39 PM, George Barwood wrote: >> >> example.com. NS ns1.example.com. >> example.com. A 192.0.2.5 >> example.com. TPORT UDP TCP QRP SCTP > > Of course that should be > > ns1.example.com. NS ns1.example.com. > ns1.example.com. A 192.0.2.5 > ns1.example.com. TPORT UDP TCP QRP SCTP That still does not make sense. example.com. NS ns1.example.com. ns1.example.com. A 192.0.2.5 ns1.example.com. TPORT UDP TCP QRP SCTP is most probably what you mean. You also wrote: > The normal situation where you are using a name server not under > your direct control is for the name server to be out-of-zone, and > therefore > glue A, AAAA and TPORT records do not apply. The parent zone has The naming of machines does not really tell anything about who has them under control (as an example a-m.root-servers.net, are all servers). My point is really about making the coupling between provisioning and serving stronger than it already is. The information we are talking about is in essence control plane data and while we are used to putting some control plane data in the DNS (NS, SOA, DNSSEC data) we also know from operational experience that that leads to problems (lameness). Having to put machine capabilities in the parent DNS will most probably give rise to similar problems (capability lameness). I believe that if we have to signal capabilities we should try to do that in a way where the machine operator has direct and instant control over what data is communicated (EDNS does this) and preferably not use an indirection through 3 parties (2 in this case: zone owner and parent). --Olaf ________________________________________________________ Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam --Apple-Mail-13--937818314 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMTCCBS0w ggMVoAMCAQICAwbqdTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA1MjUwODQ4MTJaFw0x MTA1MjUwODQ4MTJaMDkxFTATBgNVBAMTDE9sYWYgS29sa21hbjEgMB4GCSqGSIb3DQEJARYRb2xh ZkBubG5ldGxhYnMubmwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxtZNngmuLgcf rto+Uax1WhonECqb5W8US2Z+ZPw/ASKsjKEF8Wa3Nnispys6Gj9Sl7C1X0/2pH//qauLpBqA+lHW L9mgdGW1T9KU1Fb8Odqw0PBnIIhbLNQzecZL+BchEetcrubplQWzDOpROCJ00IwXksusBiKqhew4 u7X2QoraW+z32Knj5ogajIhdkAeBHUy1pwXsk/mDnV8cIEdz1MhaZWDSn7kJUQtRMVCpFBjVoiXh ToXMJfiMvn0CKaeFxFm72dcdzvFsw906Ndafd2MOfdP7QSsTVP6sG9am790AOgkzxT5CM77IDPbD zxZlQ8jTdhcp/WtUrFWIU4QBAgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRw Oi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3 CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZo dHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW9sYWZAbmxuZXRsYWJzLm5sMA0GCSqG SIb3DQEBBQUAA4ICAQCLpawAoUQAxivf6blyMswVokRmDl2JGEbtmEu8j0h1BVOlGh6hlI8WaeWy 3x2jJ9uun3VK6oYnHy45ez+dUDjBLjOZdAgwFg225lm1OPdmisghDDVwCIiEogHPqmJtvKYMFoPF 3iFUambJDoQF8DeVeg8ctDvsxsaVGjA8OrMpo0K4I11vnNbCLv7mWCjnaZWt/6Y6TD8ErHQl5dmI rpsHmEZx1/nsocdPkZGRA4QVf1omYHUNs79DtxpYdGKHoorpBNzlzIIjpceiqeOeykoDeYLTZX2G c7Mh4Gdj2MHFqZucxV1cHibb8XKv8ebaGltMV5SrciqRn8yFXmiyTvmId6myNXLiOx+VJiGbLSS3 TltM/kf7UejXeEHulEKufU6Ya6EfH7W2/spTayYCauyLljOjE2Ey5A4oIoJV9eY64OCDuLF2nmGR jOh3JB9nGkZIPhmTUwGZnMELLhzKz+eOZoulM4tXH6KEubed1shQEq1dkJ+tFtRS3Lm+vLCKWvVo 1iZScqPaQf9riPApAVrL+3Wat0p/jtCk5gLBF02uTiWvT2t4ZfSHMEBXR7CvVm58etRQuyZSMHyz UQC4wkDvCeVawNRCZjq6wWdvx5hmr2JeDSkkRtSZ/Fa1WXf26b3BZugI75p5JXafbWdOTRpNc8M5 YMk7tx29ZG3u0qODgDGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMG6nUwCQYFKw4DAhoFAKCCAYcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMDAxMTA1OTMyWjAj BgkqhkiG9w0BCQQxFgQUqiNQ7gYH6mIjyLVmSm1p54NG9eswgZEGCSsGAQQBgjcQBDGBgzCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDBup1MIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBB dXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBup1MA0GCSqGSIb3 DQEBAQUABIIBAAJemXdVQPofyOu9osNTgtRnSe2TTEA2ysdxPn7KNrA/Z+JkEcoMOkP9FDsEiaIS 7GMxr4EhbvQJTvI1WFUsgXLMS90wcXO624jK/XGBPqCyUbTfTsNRhMakwWNWPdEQ8Nt5BLfHmkc5 vUwT+VUa910QjaA7qcgSgWIEOVdouF9OLxXGlCbpCa0PQVBq3HGS3CGh2HOAOrccTJh1kgM9N5nC DpjcGmPhDCbuK9MpvSswviUuWuRe2EsHLRtvOI8siyxyym/p2p96D3LrysoGrlVpu36ItRycEunf aSKh6v+8W746U/3zeBoWV6rR1/cJJJSkrRXQgR6vGMRoi5912HIAAAAAAAA= --Apple-Mail-13--937818314-- From owner-namedroppers@ops.ietf.org Thu Oct 1 04:09:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4183A686A; Thu, 1 Oct 2009 04:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[AWL=-0.156, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41tp6HGmzp4K; Thu, 1 Oct 2009 04:09:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7C2A63A67FB; Thu, 1 Oct 2009 04:09:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtJVR-000CHX-Nj for namedroppers-data0@psg.com; Thu, 01 Oct 2009 11:07:29 +0000 Received: from [195.54.233.70] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtJVI-000CGM-4l for namedroppers@ops.ietf.org; Thu, 01 Oct 2009 11:07:27 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by hutch.rfc1035.com (Postfix) with ESMTP id 2F551154283B; Thu, 1 Oct 2009 12:07:18 +0100 (BST) From: Jim Reid To: "George Barwood" In-Reply-To: <43D49700AEC84BB0B8D1E7431AA5692A@localhost> Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item X-Priority: 3 References: <200909291910.VAA21152@TR-Sys.de> <1254304337.6754.7867.camel@shane-asus-laptop> <61143.1254313657@nsa.vix.com> <76575.1254333207@nsa.vix.com> <065B6A34-5557-4BA7-AE09-2FDE2518A9AC@NLnetLabs.nl> <43D49700AEC84BB0B8D1E7431AA5692A@localhost> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Oct 2009 12:07:17 +0100 Cc: "Olaf Kolkman" , "Paul Vixie" , "namedroppers" X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 1 Oct 2009, at 11:36, George Barwood wrote: > The normal situation where you are using a name server not under > your direct control is for the name server to be out-of-zone, and > therefore glue A, AAAA and TPORT records do not apply. Rubbish! It is very common to have in-bailwick names for a zone's name servers, even when few or any of them are under the direct control of the zone owner. > The parent zone has > > example.com. NS ns1.example.com. > example.com. A 192.0.2.5 > example.com. TPORT UDP TCP QRP SCTP This suggested use of TPORT is a bad idea because it further complicates zone cut semantics. From owner-namedroppers@ops.ietf.org Thu Oct 1 04:14:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06963A65A6; Thu, 1 Oct 2009 04:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=0.093, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqXQu2OmnTcW; Thu, 1 Oct 2009 04:14:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD4E73A6859; Thu, 1 Oct 2009 04:14:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtJal-000DVl-G8 for namedroppers-data0@psg.com; Thu, 01 Oct 2009 11:12:59 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtJaa-000DUZ-N9 for namedroppers@ops.ietf.org; Thu, 01 Oct 2009 11:12:57 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 72F62C2DA7; Thu, 1 Oct 2009 12:12:46 +0100 (BST) Date: Thu, 01 Oct 2009 12:12:41 +0100 From: Alex Bligh Reply-To: Alex Bligh To: George Barwood , Olaf Kolkman , Paul Vixie cc: namedroppers , Alex Bligh Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item Message-ID: <000E2A49329081B590123D20@Ximines.local> In-Reply-To: <154CCCC1933F48789B247B2A0C2B263B@localhost> References: <154CCCC1933F48789B247B2A0C2B263B@localhost> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 1 October 2009 11:39:12 +0100 George Barwood wrote: >> example.com. NS ns1.example.com. >> example.com. A 192.0.2.5 >> example.com. TPORT UDP TCP QRP SCTP > > Of course that should be > > ns1.example.com. NS ns1.example.com. > ns1.example.com. A 192.0.2.5 > ns1.example.com. TPORT UDP TCP QRP SCTP I think it should actually be: example.com. IN NS ns1.example.com. ns1.example.com. IN A 192.0.2.5 ns1.example.com. IN TPORT UDP TCP QRP SCTP (1st line has no 'ns1', plus "IN"). All this aside, to the extent that there is a requirement for signaling transport support for DNS (making it clear UDP and TCP are compulsory would appear to minimise this requirement given current transport deployments), is there not an equal if not greater need for such signaling between stub resolvers and recursive caching servers? Given these are normally known by IP address only to start off with, how are these meant to be supported? TPORT in in-addr.arpa.? Reverse lookup then forward lookup? But if you really want to do this, why not just do: example.com. IN NS ns1.example.com. ns1.example.com. IN A 192.0.2.5 _dns._tcp.ns1.example.com. 86400 IN SRV 0 5 5060 ns1.example.com. _dns._udp.ns1.example.com. 86400 IN SRV 0 5 5060 ns1.example.com. And for a recursive server: 6.2.0.192.in-addr.arpa. IN PTR rdns.example.com. rdns.example.com. IN A 192.0.2.6 _dns._tcp.rdns.example.com. 86400 IN SRV 0 5 5060 ns1.example.com. _dns._udp.rdns.example.com. 86400 IN SRV 0 5 5060 ns1.example.com. (note this gives you a slight chicken and egg problem in establishing how to query your recursive server to determine what protocols it supports, but we know UDP is compulsory) No new records needed. The absence of the _udp record indicates no SRV records are there (i.e. that the absence of a _tcp record does not indicate a lack of support for TCP). -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Oct 1 04:18:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 626BC28C0F6; Thu, 1 Oct 2009 04:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=0.090, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iSCZAfSmuVM; Thu, 1 Oct 2009 04:18:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E5613A68E8; Thu, 1 Oct 2009 04:18:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtJe5-000EA1-Dp for namedroppers-data0@psg.com; Thu, 01 Oct 2009 11:16:25 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtJds-000E8Z-Ud for namedroppers@ops.ietf.org; Thu, 01 Oct 2009 11:16:20 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 2CFF3C2DAB; Thu, 1 Oct 2009 12:16:11 +0100 (BST) Date: Thu, 01 Oct 2009 12:16:05 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Alex Bligh , George Barwood , Olaf Kolkman , Paul Vixie cc: namedroppers , Alex Bligh Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item Message-ID: <32EC975509359E25BB87A7C7@Ximines.local> In-Reply-To: <000E2A49329081B590123D20@Ximines.local> References: <154CCCC1933F48789B247B2A0C2B263B@localhost> <000E2A49329081B590123D20@Ximines.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 1 October 2009 12:12:41 +0100 Alex Bligh wrote: > But if you really want to do this, why not just do: > > example.com. IN NS ns1.example.com. > ns1.example.com. IN A 192.0.2.5 > _dns._tcp.ns1.example.com. 86400 IN SRV 0 5 5060 ns1.example.com. > _dns._udp.ns1.example.com. 86400 IN SRV 0 5 5060 ns1.example.com. > > And for a recursive server: > > 6.2.0.192.in-addr.arpa. IN PTR rdns.example.com. > rdns.example.com. IN A 192.0.2.6 > _dns._tcp.rdns.example.com. 86400 IN SRV 0 5 5060 ns1.example.com. > _dns._udp.rdns.example.com. 86400 IN SRV 0 5 5060 ns1.example.com. Um, my turn to get stuff wrong: s/5060/53/g -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Oct 1 05:32:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C5328C0FC; Thu, 1 Oct 2009 05:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R+BoIwX7YSB; Thu, 1 Oct 2009 05:32:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C2F4B28C39A; Thu, 1 Oct 2009 05:23:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtKf4-0004FS-HT for namedroppers-data0@psg.com; Thu, 01 Oct 2009 12:21:30 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtKet-0004E1-3Y for namedroppers@ops.ietf.org; Thu, 01 Oct 2009 12:21:28 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5FB31C98F1; Thu, 1 Oct 2009 12:21:18 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "George Barwood" cc: "Olaf Kolkman" , "namedroppers" Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item In-Reply-To: Your message of "Thu, 01 Oct 2009 13:14:00 +0100." <429A16A13D774231B7370A5D961A862A@localhost> References: <154CCCC1933F48789B247B2A0C2B263B@localhost> <4B356546-0F9D-4144-A343-48CB732E3EB4@nlnetlabs.nl> <429A16A13D774231B7370A5D961A862A@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 01 Oct 2009 12:21:18 +0000 Message-ID: <23970.1254399678@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: "George Barwood" > Date: Thu, 1 Oct 2009 13:14:00 +0100 > > > Having to put machine capabilities in the parent DNS will most > > probably give rise to similar problems (capability lameness). agreed. i think it's a bad idea, but if we're going to have it then we should put it next to the A/AAAA RRs not next to the delegation NS RRsets. > I should say that I don't propose to put "capabilities" in general in. > The new DNS Transport protocols should be very limited in number. > Actually just 1 more would be ideal, but maybe 2 is ok. i'm against anything like this. initiators should self-discover, always. not just because of inevitable "capability lameness" but also because not all protocols will work from all locations (firewalls, middleboxes, host network stacks). From owner-namedroppers@ops.ietf.org Thu Oct 1 06:10:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DEA23A6953; Thu, 1 Oct 2009 06:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.645 X-Spam-Level: X-Spam-Status: No, score=-0.645 tagged_above=-999 required=5 tests=[AWL=-0.150, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCBqPDQQxlHC; Thu, 1 Oct 2009 06:10:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 736B73A691A; Thu, 1 Oct 2009 06:10:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtLOz-000IOL-5n for namedroppers-data0@psg.com; Thu, 01 Oct 2009 13:08:57 +0000 Received: from [195.54.233.70] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtLOp-000INn-Mw for namedroppers@ops.ietf.org; Thu, 01 Oct 2009 13:08:55 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by hutch.rfc1035.com (Postfix) with ESMTP id BBF83154283B; Thu, 1 Oct 2009 14:08:45 +0100 (BST) From: Jim Reid To: "George Barwood" In-Reply-To: <3D6988556075421B9C6FA389484AA5FD@localhost> Subject: Re: [dnsext] draft-ietf-dnsext-rfc2671bis-edns0 X-Priority: 3 References: <8F0B2F9E393C4B72B74BC1855C3EA5FE@localhost> <54838189-6A9C-4D27-90CE-3E1385BDA913@rfc1035.com> <3D6988556075421B9C6FA389484AA5FD@localhost> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Oct 2009 14:08:45 +0100 Cc: X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 1 Oct 2009, at 13:44, George Barwood wrote: >> Language about DNS amplification attacks (yawn) does not belong in >> this draft/RFC. That should go in a draft to dnsop, if it goes in a >> draft at all. > > That seems completely inconsistent with RFC 3552 Nope. See above. From owner-namedroppers@ops.ietf.org Thu Oct 1 11:58:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87F43A6946; Thu, 1 Oct 2009 11:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlMC4aNRVKiV; Thu, 1 Oct 2009 11:58:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D57163A6842; Thu, 1 Oct 2009 11:58:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtQle-000OIV-6g for namedroppers-data0@psg.com; Thu, 01 Oct 2009 18:52:42 +0000 Received: from [209.85.222.198] (helo=mail-pz0-f198.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtQlU-000OHU-Ry for namedroppers@ops.ietf.org; Thu, 01 Oct 2009 18:52:40 +0000 Received: by pzk36 with SMTP id 36so460412pzk.5 for ; Thu, 01 Oct 2009 11:52:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.103.29 with SMTP id f29mr2545429wam.222.1254423151213; Thu, 01 Oct 2009 11:52:31 -0700 (PDT) In-Reply-To: <000E2A49329081B590123D20@Ximines.local> References: <154CCCC1933F48789B247B2A0C2B263B@localhost> <000E2A49329081B590123D20@Ximines.local> Date: Thu, 1 Oct 2009 11:52:31 -0700 Message-ID: Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item From: Matthew Dempsky To: Alex Bligh Cc: namedroppers Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Oct 1, 2009 at 4:12 AM, Alex Bligh wrote: > All this aside, to the extent that there is a requirement for > signaling transport support for DNS (making it clear UDP and > TCP are compulsory would appear to minimise this requirement > given current transport deployments), is there not an equal if not > greater need for such signaling between stub resolvers > and recursive caching servers? Given these are normally > known by IP address only to start off with, how are these > meant to be supported? TPORT in in-addr.arpa.? Reverse > lookup then forward lookup? Why can't clients get this information through DHCP (or whatever they're using) just like how they get the name servers' IP addresses already? From ordinationsff62@Ycd19.y.pppool.de Thu Oct 1 15:31:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D1B3A67B3 for ; Thu, 1 Oct 2009 15:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -77.568 X-Spam-Level: X-Spam-Status: No, score=-77.568 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FM_SCHOOLING=5.657, HELO_EQ_DE=0.35, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_SUB_GET_PAID=0.899, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u39S+IcnmzEv for ; Thu, 1 Oct 2009 15:31:17 -0700 (PDT) Received: from Ycd19.y.pppool.de (Ycd19.y.pppool.de [89.60.205.25]) by core3.amsl.com (Postfix) with ESMTP id 3AFDB3A679F for ; Thu, 1 Oct 2009 15:31:16 -0700 (PDT) Message-ID: <01ca42ef$78d03b50$19cd3c59@ordinationsff62> From: "Albert W. Joachim" To: Subject: Less work get paid more. Date: Thu, 1 Oct 2009 23:32:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam: Not detected Now you can obtain a degree in just 4-5 weeks on the base of your professional career We provide the following programs:- Masters, Bachelors and PhD Give us a call now. 1-816-292-2839 Leave a msg, with your full name and contact number so we can call you back. From owner-namedroppers@ops.ietf.org Thu Oct 1 16:30:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98563A6916; Thu, 1 Oct 2009 16:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.407 X-Spam-Level: X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[AWL=0.088, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZVm7liki-0e; Thu, 1 Oct 2009 16:30:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1EBF03A68F9; Thu, 1 Oct 2009 16:30:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtV15-0007gR-HE for namedroppers-data0@psg.com; Thu, 01 Oct 2009 23:24:55 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtV0w-0007fm-6J for namedroppers@ops.ietf.org; Thu, 01 Oct 2009 23:24:53 +0000 Received: from [192.168.100.90] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id C9270C2DA7; Fri, 2 Oct 2009 00:24:42 +0100 (BST) Date: Fri, 02 Oct 2009 00:25:56 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Matthew Dempsky cc: namedroppers , Alex Bligh Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item Message-ID: In-Reply-To: References: <154CCCC1933F48789B247B2A0C2B263B@localhost> <000E2A49329081B590123D20@Ximines.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 1 October 2009 11:52:31 -0700 Matthew Dempsky wrote: > Why can't clients get this information through DHCP (or whatever > they're using) just like how they get the name servers' IP addresses > already? Presumably they could if there were a DCHP option to specify it. Right now, they assume UDP. -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Oct 1 17:24:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14A2D3A683B; Thu, 1 Oct 2009 17:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmSLyZa6Ioy1; Thu, 1 Oct 2009 17:24:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8686A3A67E2; Thu, 1 Oct 2009 17:24:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtVtt-000P4h-FP for namedroppers-data0@psg.com; Fri, 02 Oct 2009 00:21:33 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtVti-000P3w-TK for namedroppers@ops.ietf.org; Fri, 02 Oct 2009 00:21:30 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id F31C6E609F; Fri, 2 Oct 2009 00:21:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n920LGBL035086; Fri, 2 Oct 2009 10:21:18 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200910020021.n920LGBL035086@drugs.dv.isc.org> To: "George Barwood" Cc: "Jim Reid" , namedroppers@ops.ietf.org From: Mark Andrews References: <8F0B2F9E393C4B72B74BC1855C3EA5FE@localhost> <54838189-6A9C-4D27-90CE-3E1385BDA913@rfc1035.com> <3D6988556075421B9C6FA389484AA5FD@localhost> Subject: Re: [dnsext] draft-ietf-dnsext-rfc2671bis-edns0 In-reply-to: Your message of "Thu, 01 Oct 2009 15:10:44 +0100." Date: Fri, 02 Oct 2009 10:21:16 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , "George Barwood" write s: > > ----- Original Message ----- > From: "Jim Reid" > To: "George Barwood" > Cc: > Sent: Thursday, October 01, 2009 2:08 PM > Subject: Re: [dnsext] draft-ietf-dnsext-rfc2671bis-edns0 > > > > On 1 Oct 2009, at 13:44, George Barwood wrote: > > > >>> Language about DNS amplification attacks (yawn) does not belong in > >>> this draft/RFC. That should go in a draft to dnsop, if it goes in a > >>> draft at all. > >> > >> That seems completely inconsistent with RFC 3552 > > > > Nope. See above. > > > > I don't get it at all. > > Are you suggesting draft-ietf-dnsext-rfc2671bis-edns0 is somehow > exempt from the provisions of RFC 3552? > > Where does this exemption come from? > I can find no provisions for known threats to be deferred to some other document. George, please go lobby your local goverment officials to introduce regulations that require ISP's operating in their juristictions to block spoofed traffic. i.e. put some bite into the BCPs. That will be far more effective than worrying about protocols that return bigger responses. The problem isn't with the protocols it is with the spoofed traffic. This will level the playing field by ensuring that no player is unfairly disavantaged by doing the right thing. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Fri Oct 2 00:48:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8AFA3A6847; Fri, 2 Oct 2009 00:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxaLJfO2YGvr; Fri, 2 Oct 2009 00:48:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8E77A3A6A1D; Fri, 2 Oct 2009 00:48:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mtcpv-0007yo-3W for namedroppers-data0@psg.com; Fri, 02 Oct 2009 07:45:55 +0000 Received: from [209.85.216.171] (helo=mail-px0-f171.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mtcpm-0007yK-8h for namedroppers@ops.ietf.org; Fri, 02 Oct 2009 07:45:53 +0000 Received: by pxi1 with SMTP id 1so929808pxi.33 for ; Fri, 02 Oct 2009 00:45:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.101.20 with SMTP id d20mr3485036wam.192.1254469545948; Fri, 02 Oct 2009 00:45:45 -0700 (PDT) In-Reply-To: References: <154CCCC1933F48789B247B2A0C2B263B@localhost> <000E2A49329081B590123D20@Ximines.local> Date: Fri, 2 Oct 2009 00:45:45 -0700 Message-ID: Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item From: Matthew Dempsky To: Ray.Bellis@nominet.org.uk Cc: namedroppers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, Oct 2, 2009 at 12:43 AM, wrote: > Those gateways almost always point the client at the home gateway's own > (usually disfunctional) DNS proxy. =A0Almost all such proxies _only_ supp= ort > UDP. Right. So those broken gateways don't have any extra capabilities to advertise, so clients that don't receive extra capability notifications fallback to current behavior. From owner-namedroppers@ops.ietf.org Fri Oct 2 00:48:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3433C3A6847; Fri, 2 Oct 2009 00:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.736 X-Spam-Level: X-Spam-Status: No, score=-105.736 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuTjLDZyOG46; Fri, 2 Oct 2009 00:48:23 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 8E79A3A6A24; Fri, 2 Oct 2009 00:48:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtcnK-00071U-Jm for namedroppers-data0@psg.com; Fri, 02 Oct 2009 07:43:14 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtcnA-00070E-SZ for namedroppers@ops.ietf.org; Fri, 02 Oct 2009 07:43:12 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=fpqq2zYdcojmsbeCgeIvksv89hTa9NKGq2LZi6Kz3ytRSLQGgkn4V09z OWIcLLGTnkjxaBMDPdUFvoRB1ASZmDONKjKNpoVdhOfxggP0AyQOcX5mw 0u1DHW9d0epkmd8; 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=1254469384; x=1286005384; 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.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20draft-barwood-dnsext-dns-transport-signal-00=20to =20WG=20work=20=09item|Date:=20Fri,=202=20Oct=202009=2008 :43:01=20+0100|Message-ID:=20|To:=20Matt hew=20Dempsky=20|Cc:=20namedroppers =20|MIME-Version:=201.0 |In-Reply-To:=20|References:=20<154CCCC1933F48789B247 B2A0C2B263B@localhost>=09=20<000E2A49329081B590123D20@Xim ines.local>=20; bh=7+kIOVd+lxG+ocYcXIMYX7eH0+X3fPoviNsckZq165c=; b=QK2//Y4bK0mfeOkGRF5WSicb+ac0SP9ovnj1yTSs6QWf8i6QH7e5ieiJ E2+ZobQxHr8TNcc+04psHb+w87D/CfO028hQ1VSMcvDoiku/7qM1dweyW CouttGoya4ocOEc; X-IronPort-AV: E=Sophos;i="4.44,493,1249254000"; d="scan'208";a="18188873" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 02 Oct 2009 08:43:02 +0100 In-Reply-To: References: <154CCCC1933F48789B247B2A0C2B263B@localhost> <000E2A49329081B590123D20@Ximines.local> To: Matthew Dempsky Cc: namedroppers Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 2 Oct 2009 08:43:01 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 02/10/2009 08:43:02 AM, Serialize complete at 02/10/2009 08:43:02 AM Content-Type: multipart/alternative; boundary="=_alternative 002A63FD80257643_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 002A63FD80257643_= Content-Type: text/plain; charset="US-ASCII" > Why can't clients get this information through DHCP (or whatever > they're using) just like how they get the name servers' IP addresses > already? Because the vast majority of consumers get their DNS settings from their home gateway. Those gateways almost always point the client at the home gateway's own (usually disfunctional) DNS proxy. Almost all such proxies _only_ support UDP. Ray --=_alternative 002A63FD80257643_= Content-Type: text/html; charset="US-ASCII"
> Why can't clients get this information through DHCP (or whatever
> they're using) just like how they get the name servers' IP addresses
> already?
Because the vast majority of consumers get their DNS settings from their home gateway.

Those gateways almost always point the client at the home gateway's own (usually disfunctional) DNS proxy.  Almost all such proxies _only_ support UDP.

Ray


--=_alternative 002A63FD80257643_=-- From owner-namedroppers@ops.ietf.org Fri Oct 2 04:19:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064673A67B3; Fri, 2 Oct 2009 04:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.693 X-Spam-Level: *** X-Spam-Status: No, score=3.693 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxrFdFeQ9x11; Fri, 2 Oct 2009 04:19:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB3F33A67AB; Fri, 2 Oct 2009 04:19:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mtg72-000Nxb-IJ for namedroppers-data0@psg.com; Fri, 02 Oct 2009 11:15:48 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mtg6r-000NwY-Uk for namedroppers@ops.ietf.org; Fri, 02 Oct 2009 11:15:46 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA161892090; Fri, 2 Oct 2009 13:14:50 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA27218; Fri, 2 Oct 2009 13:14:49 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910021114.NAA27218@TR-Sys.de> Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item To: alex@alex.org.uk, namedroppers@ops.ietf.org Date: Fri, 2 Oct 2009 13:14:48 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 01 Oct 2009 12:16:05 +0100 Alex Bligh wrote: > --On 1 October 2009 12:12:41 +0100 Alex Bligh wrote: > > But if you really want to do this, why not just do: > > example.com. IN NS ns1.example.com. > ns1.example.com. IN A 192.0.2.5 > _dns._tcp.ns1.example.com. 86400 IN SRV 0 5 5060 ns1.example.com. > _dns._udp.ns1.example.com. 86400 IN SRV 0 5 5060 ns1.example.com. > > And for a recursive server: > > 6.2.0.192.in-addr.arpa. IN PTR rdns.example.com. > rdns.example.com. IN A 192.0.2.6 > _dns._tcp.rdns.example.com. 86400 IN SRV 0 5 5060 ns1.example.com. > _dns._udp.rdns.example.com. 86400 IN SRV 0 5 5060 ns1.example.com. > > > Um, my turn to get stuff wrong: > s/5060/53/g > > -- > Alex Bligh Why not going one step further for the forward zone? I suggest filing these SRV RRs for the domain being served, not for the specific name server(s); that would more closely correspond to the spirit (and text!) of the SRV specification, reduce the number of queries needed when collection info about all authoritative name servers for a domain, and it might also help escape certain administrative/authority conflicts: example.com. IN NS ns1.example.com. IN NS ns2.example.com. ns1.example.com. IN A 192.0.2.5 ns2.example.com. IN A 192.0.2.101 _dns._tcp.example.com. 86400 IN SRV 0 5 53 ns1.example.com. 86400 IN SRV 1 5 53 ns2.example.com. _dns._udp.example.com. 86400 IN SRV 0 5 53 ns1.example.com. 86400 IN SRV 1 5 53 ns2.example.com. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From owner-namedroppers@ops.ietf.org Fri Oct 2 05:11:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38F463A65A6; Fri, 2 Oct 2009 05:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[AWL=0.086, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ximNixKd1s+I; Fri, 2 Oct 2009 05:11:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3F15328C0E3; Fri, 2 Oct 2009 05:11:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mtgve-000EzT-DQ for namedroppers-data0@psg.com; Fri, 02 Oct 2009 12:08:06 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtgvU-000Epr-QO for namedroppers@ops.ietf.org; Fri, 02 Oct 2009 12:08:04 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id B4168C2DA3; Fri, 2 Oct 2009 13:07:54 +0100 (BST) Date: Fri, 02 Oct 2009 13:07:46 +0100 From: Alex Bligh Reply-To: Alex Bligh To: "Alfred H?nes" , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item Message-ID: <176A7653DBAD669BD7516921@Ximines.local> In-Reply-To: <200910021114.NAA27218@TR-Sys.de> References: <200910021114.NAA27218@TR-Sys.de> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 2 October 2009 13:14:48 +0200 "Alfred H?nes" wrote: > I suggest filing these SRV RRs for the domain being served, > not for the specific name server(s); that would more closely > correspond to the spirit (and text!) of the SRV specification, > reduce the number of queries needed when collection info about > all authoritative name servers for a domain, and it might also > help escape certain administrative/authority conflicts: > > example.com. IN NS ns1.example.com. > IN NS ns2.example.com. > ns1.example.com. IN A 192.0.2.5 > ns2.example.com. IN A 192.0.2.101 > _dns._tcp.example.com. 86400 IN SRV 0 5 53 ns1.example.com. > 86400 IN SRV 1 5 53 ns2.example.com. > _dns._udp.example.com. 86400 IN SRV 0 5 53 ns1.example.com. > 86400 IN SRV 1 5 53 ns2.example.com. > Indeed. I had mistakenly thought this would complicate zone cut issues, but it doesn't. I note "_domain" is already used for some form of DNS discovery, though it is not immediately clear to me quite what. -- Alex Bligh From owner-namedroppers@ops.ietf.org Fri Oct 2 05:30:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40FDB28C107; Fri, 2 Oct 2009 05:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.713 X-Spam-Level: *** X-Spam-Status: No, score=3.713 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4I6Lz9d-OlA; Fri, 2 Oct 2009 05:30:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AD8DE28C104; Fri, 2 Oct 2009 05:30:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MthEd-000MEd-EM for namedroppers-data0@psg.com; Fri, 02 Oct 2009 12:27:43 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MthET-000MCG-3x for namedroppers@ops.ietf.org; Fri, 02 Oct 2009 12:27:41 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA162256410; Fri, 2 Oct 2009 14:26:50 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA27315; Fri, 2 Oct 2009 14:26:49 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910021226.OAA27315@TR-Sys.de> Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item To: alex@alex.org.uk Date: Fri, 2 Oct 2009 14:26:48 +0200 (MESZ) Cc: namedroppers@ops.ietf.org In-Reply-To: <176A7653DBAD669BD7516921@Ximines.local> from Alex Bligh at Oct "2," 2009 "01:07:46" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Alex Bligh just wrote: > --On 2 October 2009 13:14:48 +0200 wrote: > >> I suggest filing these SRV RRs for the domain being served, >> not for the specific name server(s); that would more closely >> correspond to the spirit (and text!) of the SRV specification, >> reduce the number of queries needed when collection info about >> all authoritative name servers for a domain, and it might also >> help escape certain administrative/authority conflicts: >> >> example.com. IN NS ns1.example.com. >> IN NS ns2.example.com. >> ns1.example.com. IN A 192.0.2.5 >> ns2.example.com. IN A 192.0.2.101 >> _dns._tcp.example.com. 86400 IN SRV 0 5 53 ns1.example.com. >> 86400 IN SRV 1 5 53 ns2.example.com. >> _dns._udp.example.com. 86400 IN SRV 0 5 53 ns1.example.com. >> 86400 IN SRV 1 5 53 ns2.example.com. >> > > Indeed. I had mistakenly thought this would complicate zone cut issues, > but it doesn't. I note "_domain" is already used for some form > of DNS discovery, though it is not immediately clear to me quite what. > > -- > Alex Bligh Ah! You got me! Back to square 1! Indeed, the IANA Port Numbers registry lists the Service Name "domain" for the registered service offered at the well-known port 53 over UDP and TCP. If we get enough support for http://tools.ietf.org/id/draft-gudmundsson-dns-srv-iana-registry-03.txt, "_domain" would be a canonical candidate for Service Label registration under the SRV Service Prefix IANA registry proposed therein. (Comments on that draft would be welcome as well!) Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From owner-namedroppers@ops.ietf.org Fri Oct 2 05:56:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379FB3A6983; Fri, 2 Oct 2009 05:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqPdidWvr7Tp; Fri, 2 Oct 2009 05:56:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 44E163A67F7; Fri, 2 Oct 2009 05:56:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MthcR-0006pS-Pv for namedroppers-data0@psg.com; Fri, 02 Oct 2009 12:52:19 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MthcC-0006Xc-36 for namedroppers@ops.ietf.org; Fri, 02 Oct 2009 12:52:17 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0KQW007010RQ0V00@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Fri, 02 Oct 2009 13:52:02 +0100 (IST) Received: from [10.0.1.177] ([83.141.81.52]) by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTPSA id <0KQW00A1P12OOLI0@cali.ucd.ie>; Fri, 02 Oct 2009 13:52:01 +0100 (IST) Date: Fri, 02 Oct 2009 13:52:00 +0100 From: Niall O'Reilly Subject: [dnsext] draft-gudmundsson-dns-srv-iana-registry-03 In-reply-to: <200910021226.OAA27315@TR-Sys.de> To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= Cc: alex@alex.org.uk, namedroppers@ops.ietf.org Message-id: <4AC5F770.90602@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT References: <200910021226.OAA27315@TR-Sys.de> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Alfred � wrote: > If we get enough support for Count me in as a supporter. > http://tools.ietf.org/id/draft-gudmundsson-dns-srv-iana-registry-03.txt, > "_domain" would be a canonical candidate for Service Label > registration under the SRV Service Prefix IANA registry proposed > therein. (Comments on that draft would be welcome as well!) I've scanned it quickly; It looks useful to me. I'll try to make some less trivial comment after a careful reading. 0,02 /Niall From owner-namedroppers@ops.ietf.org Fri Oct 2 06:24:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 899B93A68A8; Fri, 2 Oct 2009 06:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+tq7RFefdJR; Fri, 2 Oct 2009 06:24:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0AA243A6765; Fri, 2 Oct 2009 06:24:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mti4T-000HcG-4R for namedroppers-data0@psg.com; Fri, 02 Oct 2009 13:21:17 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mti4B-000HNV-CT for namedroppers@ops.ietf.org; Fri, 02 Oct 2009 13:21:11 +0000 Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n92DL4J0032408 for ; Fri, 2 Oct 2009 09:21:04 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Fri, 2 Oct 2009 09:20:50 -0400 From: "Rose, Scott W." To: "namedroppers@ops.ietf.org" Date: Fri, 2 Oct 2009 09:20:48 -0400 Subject: [dnsext] comment about the IANA registry discussion in draft-ietf-dnsext-dnssec-algo-allocation Thread-Topic: comment about the IANA registry discussion in draft-ietf-dnsext-dnssec-algo-allocation Thread-Index: AcpDYyetDLsXuO5G6UKXiWNIPqGJ6w== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I have a rather minor suggestion for the DNSSEC algorithm registry from the discussion in Section 3 and 4 in draft-ietf-dnsext-dnssec-algo-allocation. The sections describe the changes to be made to the DNSSEC algorithm registry but I think it might be better to include the status (i.e. MANDATORY, OPTIONAL, etc.) of each algorithm, not just the reference. Currently, only the RSA/MD5 allocation gives a direct indication that it is deprecated in the registry table, unlike the DS digest registry table. Implementers would have to check the references to insure the current state of all the algorithms. Would it make more sense to add another column to the registry with the current status? The status of non-standards track algorithms should be OPTIONAL by default, with a status change to MANDATORY only done via a standards track doc. Does this seem like a good idea, or makes the registry more complicated? Scott =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scottr@nist.gov ph: +1 301-975-8439 http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-namedroppers@ops.ietf.org Fri Oct 2 06:45:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5873A6951; Fri, 2 Oct 2009 06:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[AWL=0.084, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPQOgmH8m1eh; Fri, 2 Oct 2009 06:45:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2BD2B3A6810; Fri, 2 Oct 2009 06:45:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtiF1-000MTn-C7 for namedroppers-data0@psg.com; Fri, 02 Oct 2009 13:32:11 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtiEo-000MAc-Uw for namedroppers@ops.ietf.org; Fri, 02 Oct 2009 13:32:09 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id B00EDC2DA3; Fri, 2 Oct 2009 14:31:53 +0100 (BST) Date: Fri, 02 Oct 2009 14:31:45 +0100 From: Alex Bligh Reply-To: Alex Bligh To: "Alfred H?nes" cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item Message-ID: <7CAC2B6A5C780A07DAED7976@Ximines.local> In-Reply-To: <200910021226.OAA27315@TR-Sys.de> References: <200910021226.OAA27315@TR-Sys.de> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 2 October 2009 14:26:48 +0200 "Alfred H?nes" wrote: >> Indeed. I had mistakenly thought this would complicate zone cut issues, >> but it doesn't. I note "_domain" is already used for some form >> of DNS discovery, though it is not immediately clear to me quite what. >> >> -- >> Alex Bligh > > Ah! You got me! Back to square 1! > > Indeed, the IANA Port Numbers registry lists the Service Name > "domain" for the registered service offered at the well-known > port 53 over UDP and TCP. It should be "_domain", however Stuart Cheshire's document here http://www.dns-sd.org/ServiceTypes.html suggests it might be already be used (possibly for something else), hence I suggested "_dns". An extract from his document is appended below. I'm interest to know what "Now advertised and browsed-for by numerous independent server and client implementations" means. As far as I know, RFC2782 does not specify how "_domain" should work - i.e. is this advertising a recursive or an authoritative DNS server, or something else? -- Alex Bligh dns-llq DNS Long-Lived Queries Kiren Sekar Protocol description: DNS Long-Lived Queries Primary Transport Protocol: UDP Discovery Protocol: RFC 2782 dns-sd DNS Service Discovery Stuart Cheshire , Marc Krochmal Not a service type. Special name reserved for DNS-SD meta queries. dns-update DNS Dynamic Update Service Kiren Sekar DNS Dynamic Update Service for a given domain may not necessarily be provided by the principal name servers as advertised by the domain's "NS" records, and may not necessarily always be provided on port 53. The "_dns-update._udp.." SRV record gives the target host and port where DNS Dynamic Update Service is provided for the named domain. Protocol description: RFC 2136, RFC 3007, and others. Primary Transport Protocol: UDP Discovery Protocol: RFC 2782 domain Domain Name Server Service name originally allocated for Paul Mockapetris Now advertised and browsed-for by numerous independent server and client implementations. Protocol description: RFC 1034, RFC 1035, and others. Primary Transport Protocol: UDP Discovery Protocol: RFC 2782 From owner-namedroppers@ops.ietf.org Fri Oct 2 06:56:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3733328C0FA; Fri, 2 Oct 2009 06:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.731 X-Spam-Level: *** X-Spam-Status: No, score=3.731 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqXOa9hx+UYO; Fri, 2 Oct 2009 06:56:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E9C7128C0E9; Fri, 2 Oct 2009 06:56:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtiaZ-0004jh-IY for namedroppers-data0@psg.com; Fri, 02 Oct 2009 13:54:27 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtiaL-0004g7-Eu for namedroppers@ops.ietf.org; Fri, 02 Oct 2009 13:54:25 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA162681610; Fri, 2 Oct 2009 15:53:30 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA27443; Fri, 2 Oct 2009 15:53:29 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910021353.PAA27443@TR-Sys.de> Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00 to WG work item To: alex@alex.org.uk, namedroppers@ops.ietf.org Date: Fri, 2 Oct 2009 15:53:29 +0200 (MESZ) In-Reply-To: <7CAC2B6A5C780A07DAED7976@Ximines.local> from Alex Bligh at Oct "2," 2009 "02:31:45" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Alex Bligh just wrote: > --On 2 October 2009 14:26:48 +0200 wrote: > >>> Indeed. I had mistakenly thought this would complicate zone cut issues, >>> but it doesn't. I note "_domain" is already used for some form >>> of DNS discovery, though it is not immediately clear to me quite what. >>> >>> -- >>> Alex Bligh >> >> Ah! You got me! Back to square 1! >> >> Indeed, the IANA Port Numbers registry lists the Service Name >> "domain" for the registered service offered at the well-known >> port 53 over UDP and TCP. > > It should be "_domain", however Stuart Cheshire's document here > http://www.dns-sd.org/ServiceTypes.html > suggests it might be already be used (possibly for something else), > hence I suggested "_dns". An extract from his document is appended below. The front-up investigations Olafur had performed for the srv-iana-regitry draft did not provide evidence of "_domain" being used in the wild. Therefore, this Service Label has been omitted from the proposed initial content for the registry. The other three entries you have mentioned below, however, have found their way into our draft (preferring the "-tls" variant of "dns-llq", which had been observed in the wild. > I'm interest to know what "Now advertised and browsed-for by > numerous independent server and client implementations" means. > As far as I know, RFC2782 does not specify how "_domain" should > work - i.e. is this advertising a recursive or an authoritative > DNS server, or something else? Good question(s), and perhaps another reason for _not_ including this (potential) use of SRV in our proposal for the initial content of the SRV Servcie Prefix registry, without enough unambiguous documentation to ensure interoperability! This is a very good example for one of the reasons I have opposed to the attempt in draft-ietf-tsvwg-iana-ports-02 to automatically and blindly register all present entries in the Port Number registry for DNS SRV use as well, cf. > -- > Alex Bligh > > > dns-llq DNS Long-Lived Queries > Kiren Sekar > Protocol description: DNS Long-Lived Queries > Primary Transport Protocol: UDP > Discovery Protocol: RFC 2782 > > dns-sd DNS Service Discovery > Stuart Cheshire , > Marc Krochmal > Not a service type. Special name reserved for DNS-SD > meta queries. > > dns-update DNS Dynamic Update Service > Kiren Sekar > DNS Dynamic Update Service for a given domain may not > necessarily be provided by the principal name servers > as advertised by the domain's "NS" records, and may not > necessarily always be provided on port 53. > The "_dns-update._udp.." SRV record gives > the target host and port where DNS Dynamic Update Service > is provided for the named domain. > Protocol description: RFC 2136, RFC 3007, and others. > Primary Transport Protocol: UDP > Discovery Protocol: RFC 2782 > > domain Domain Name Server > Service name originally allocated for Paul Mockapetris > > Now advertised and browsed-for by numerous independent > server and client implementations. > Protocol description: RFC 1034, RFC 1035, and others. > Primary Transport Protocol: UDP > Discovery Protocol: RFC 2782 Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From owner-namedroppers@ops.ietf.org Fri Oct 2 07:07:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89A883A683F; Fri, 2 Oct 2009 07:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.675 X-Spam-Level: X-Spam-Status: No, score=-0.675 tagged_above=-999 required=5 tests=[AWL=-1.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVTsCs0kSB9O; Fri, 2 Oct 2009 07:07:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A7F7D3A6810; Fri, 2 Oct 2009 07:07:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtilN-0008X4-8N for namedroppers-data0@psg.com; Fri, 02 Oct 2009 14:05:37 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtilE-0008WJ-9U for namedroppers@ops.ietf.org; Fri, 02 Oct 2009 14:05:35 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D54A82FE8CA1 for ; Fri, 2 Oct 2009 14:05:23 +0000 (UTC) Date: Fri, 2 Oct 2009 10:05:21 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] comment about the IANA registry discussion in draft-ietf-dnsext-dnssec-algo-allocation Message-ID: <20091002140521.GD9699@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: No hat. On Fri, Oct 02, 2009 at 09:20:48AM -0400, Rose, Scott W. wrote: > Does this seem like a good idea, or makes the registry more complicated? "Yes". In fact, change the "or" to "and". Just because it makes the registry more complicated does not make it a good idea -- in this case, it increases maintenance cost for the considerable benefit of making the registry much easier to use. I think it makes sense. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Oct 2 07:44:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C36F3A6A6B; Fri, 2 Oct 2009 07:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[AWL=-0.611, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 176e7kzcZkHG; Fri, 2 Oct 2009 07:44:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E94253A6A62; Fri, 2 Oct 2009 07:44:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtjIs-000Lvb-Rr for namedroppers-data0@psg.com; Fri, 02 Oct 2009 14:40:14 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtjIe-000LdH-V9 for namedroppers@ops.ietf.org; Fri, 02 Oct 2009 14:40:11 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n92Edw7C054495 for ; Fri, 2 Oct 2009 10:39:59 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200910021439.n92Edw7C054495@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 02 Oct 2009 10:39:17 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: [dnsext] IETF-75 Hiroshima agenda requests and deadlines Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Please send us requests for agenda slots soon via dnsext-chairs at tools.ietf.org Important deadlines: (all deadlines are 17:00 PDT or 240:00 UTC) 2009-10-12 (Monday): Working Group Chair approval for initial document (Version -00) submissions 2009-10-19 (Monday): Internet Draft Cut-off for initial document (-00) submission 2009-10-26 (Monday): Internet Draft final submission cut-off 2009-10-28 (Wednesday): Draft Working Group agendas due 2009-10-30 (Friday): Early Bird registration and payment cut-off Olafur From owner-namedroppers@ops.ietf.org Fri Oct 2 09:26:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91DA93A6A77; Fri, 2 Oct 2009 09:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptOuJ8fdibKv; Fri, 2 Oct 2009 09:26:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE9EB3A6405; Fri, 2 Oct 2009 09:26:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtktP-0005mQ-FK for namedroppers-data0@psg.com; Fri, 02 Oct 2009 16:22:03 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtktF-0005ko-Ds for namedroppers@ops.ietf.org; Fri, 02 Oct 2009 16:22:01 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id 6AE7A3A6A6E; Fri, 2 Oct 2009 09:20:23 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , dnsext mailing list , dnsext chair Subject: [dnsext] Protocol Action: 'Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC' to Proposed Standard Message-Id: <20091002162023.6AE7A3A6A6E@core3.amsl.com> Date: Fri, 2 Oct 2009 09:20:23 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: The IESG has approved the following document: - 'Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC ' as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-14.txt Technical Summary This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). Working Group Summary The DNS Extensions Working Group had consensus to publish the document. Document Quality The document received thorough review, and it is expected that vendors supporting DNSSEC will implement SHA-2 once the document is published. During Working Group Last Call, there were objections that an earlier approach, which tied SHA-2 to implementation of NSEC3, would be a barrier for adoption by some vendors, so the specification was changed to avoid the link. Personnel Andrew Sullivan (ajs@shinkuro.com) is the Document Shepherd. Ralph Droms (rdroms@cisco.com) is the Responsible AD. From astridef9@213-227-219-58.static.vega-ua.net Fri Oct 2 09:49:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0623A6405 for ; Fri, 2 Oct 2009 09:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -71.701 X-Spam-Level: X-Spam-Status: No, score=-71.701 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_SCHOOLING=5.657, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SPAMMY_XMAILER=2.337, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2Joi2gMjspR for ; Fri, 2 Oct 2009 09:49:49 -0700 (PDT) Received: from 213-227-219-58.static.vega-ua.net (213-227-219-58.static.vega-ua.net [213.227.219.58]) by core3.amsl.com (Postfix) with ESMTP id 656053A69AB for ; Fri, 2 Oct 2009 09:49:47 -0700 (PDT) Received: from 213.227.219.58 by mail.redgale.com; Fri, 2 Oct 2009 18:51:16 +0200 Date: Fri, 2 Oct 2009 18:51:16 +0200 From: "Enoch F. Shifflett" X-Mailer: The Bat! (v2.00.2) Business Reply-To: astridef9@213-227-219-58.static.vega-ua.net X-Priority: 3 (Normal) Message-ID: <945266842.38649561340870@213-227-219-58.static.vega-ua.net> To: dnsext-archive@lists.ietf.org Subject: Get more for your work MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Now you can obtain a degree in just 4-5 weeks on the base of your professional career We provide the following programs:- Masters, Bachelors and PhD Give us a call now. 1-816-292-2839 Leave a msg, with your full name and contact number so we can call you back. From owner-namedroppers@ops.ietf.org Fri Oct 2 10:16:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBCDC3A69FE; Fri, 2 Oct 2009 10:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.421 X-Spam-Level: X-Spam-Status: No, score=-4.421 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpafVceqdUxr; Fri, 2 Oct 2009 10:16:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EDF533A68B3; Fri, 2 Oct 2009 10:16:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtlhU-000P0z-01 for namedroppers-data0@psg.com; Fri, 02 Oct 2009 17:13:48 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtlhE-000Oze-Tv for namedroppers@ops.ietf.org; Fri, 02 Oct 2009 17:13:44 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n92HDUNH007753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Oct 2009 10:13:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20091002140521.GD9699@shinkuro.com> References: <20091002140521.GD9699@shinkuro.com> Date: Fri, 2 Oct 2009 10:13:28 -0700 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] comment about the IANA registry discussion in draft-ietf-dnsext-dnssec-algo-allocation Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 10:05 AM -0400 10/2/09, Andrew Sullivan wrote: >No hat. > >On Fri, Oct 02, 2009 at 09:20:48AM -0400, Rose, Scott W. wrote: >> Does this seem like a good idea, or makes the registry more complicated? > >"Yes". In fact, change the "or" to "and". Just because it makes the >registry more complicated does not make it a good idea -- in this >case, it increases maintenance cost for the considerable benefit of >making the registry much easier to use. I think it makes sense. +1 --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Fri Oct 2 17:17:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B2C3A6903; Fri, 2 Oct 2009 17:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.531 X-Spam-Level: X-Spam-Status: No, score=-4.531 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZgfV4dsM8h9; Fri, 2 Oct 2009 17:17:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6689D3A67DD; Fri, 2 Oct 2009 17:17:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtsE5-000FqZ-Hp for namedroppers-data0@psg.com; Sat, 03 Oct 2009 00:11:53 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtsDr-000Fpy-4C for namedroppers@ops.ietf.org; Sat, 03 Oct 2009 00:11:51 +0000 Received: from sjc-office-nat-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 72333A9443C; Sat, 3 Oct 2009 00:11:36 +0000 (UTC) Message-ID: <4AC696B8.6080203@mail-abuse.org> Date: Fri, 02 Oct 2009 17:11:36 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Mark Andrews CC: George Barwood , Jim Reid , namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-rfc2671bis-edns0 References: <8F0B2F9E393C4B72B74BC1855C3EA5FE@localhost> <54838189-6A9C-4D27-90CE-3E1385BDA913@rfc1035.com> <3D6988556075421B9C6FA389484AA5FD@localhost> <200910020021.n920LGBL035086@drugs.dv.isc.org> In-Reply-To: <200910020021.n920LGBL035086@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 10/1/09 5:21 PM, Mark Andrews wrote: > In message, "George > Barwood" write [] >> Are you suggesting draft-ietf-dnsext-rfc2671bis-edns0 is somehow >> exempt from the provisions of RFC 3552? >> >> Where does this exemption come from? I can find no provisions for >> known threats to be deferred to some other document. > > George, please go lobby your local goverment officials to introduce > regulations that require ISP's operating in their juristictions to > block spoofed traffic. i.e. put some bite into the BCPs. That will > be far more effective than worrying about protocols that return > bigger responses. The problem isn't with the protocols it is with > the spoofed traffic. > > This will level the playing field by ensuring that no player is > unfairly disavantaged by doing the right thing. Mark, While it is fine to promote BCP 38, this rhetoric is misleading, since the problem is with the protocol. Whether or not BCP 38 is applied locally does not preclude reflected DNS amplifications attacks. Reflections can occur off of millions of non-local servers. As network sources increase their complexity with mobility, multi-homing, and asymmetrical routing, the rigorous use of BCP 38 grows less practical and more complex, which might diminish currently inadequate adoption. Adhering to advice given in RFC 3552 provides complete protection from amplified reflected attack _without_ dependence upon BCP 38 or access control lists. Large DNS responses over UDP can create a level of amplification able to disable 30Gb/s connections, as discussed by teamcymru in: http://www.youtube.com/watch?v=XhSTlqYIQnI With DNSSEC, authoritative servers, in addition to open resolvers, become potential (unfair per RFC 3552) high gain sources. However, unlike open resolvers, authoritative servers can not be shielded with access control lists. -Doug From owner-namedroppers@ops.ietf.org Sat Oct 3 06:32:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA213A68E5; Sat, 3 Oct 2009 06:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.094 X-Spam-Level: X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[AWL=-0.599, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+1VtVatMXbp; Sat, 3 Oct 2009 06:32:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 06BAF3A68D4; Sat, 3 Oct 2009 06:32:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mu4b0-00060b-EF for namedroppers-data0@psg.com; Sat, 03 Oct 2009 13:24:22 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mu4aq-0005yU-Hh for namedroppers@ops.ietf.org; Sat, 03 Oct 2009 13:24:20 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n93DOBb2001377 for ; Sat, 3 Oct 2009 09:24:11 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200910031324.n93DOBb2001377@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 03 Oct 2009 09:23:52 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson/DNSEXT chair Subject: [dnsext] RSA/SHA256 assignments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, FYI, IESG approved yesterday RSA/SHA256 draft for publication, IANA has performed the allocation actions. See: http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml RFC will show up in about 8 weeks (delay due to appeals window more than anything else) Olafur From owner-namedroppers@ops.ietf.org Sun Oct 4 01:19:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD773A63EC; Sun, 4 Oct 2009 01:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.245 X-Spam-Level: X-Spam-Status: No, score=0.245 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBThdWIMQIQe; Sun, 4 Oct 2009 01:19:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF23A3A68DA; Sun, 4 Oct 2009 01:19:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuMDt-00028M-Pi for namedroppers-data0@psg.com; Sun, 04 Oct 2009 08:13:41 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuMDk-00027k-6c for namedroppers@ops.ietf.org; Sun, 04 Oct 2009 08:13:40 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MuMDf-0003IZ-Ab; Sun, 04 Oct 2009 10:13:27 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MuMDe-0007kN-Qq; Sun, 04 Oct 2009 08:13:26 +0000 From: Florian Weimer To: "George Barwood" Cc: Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00.txt - WG item References: <835E5B3A3A314D0E9E47CB3C4F9BC412@localhost> <0BB1C903022546B381AA1ACAD3B19A47@localhost> Date: Sun, 04 Oct 2009 08:13:26 +0000 In-Reply-To: <0BB1C903022546B381AA1ACAD3B19A47@localhost> (George Barwood's message of "Sat, 3 Oct 2009 21:02:31 +0100") Message-ID: <878wfr8tll.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * George Barwood: > I have updated the draft to try to reflect the comments made. > > http://www.ietf.org/id/draft-barwood-dnsext-dns-transport-signal-01.txt | The TPORT record for a domain, if it exists, SHOULD be added to the | Additional Section of a DNS response whenever an A or AAAA record for | the domain is sent. This is likely to break backwards compatiblity. Could you make TPORT a special DS algorithm instead, extend the algorithm number to 16 bits, and add some per-server parameters? That is, the following data would be stored in the digest part of a DS: +-----------------------------------------+ | name server domain (variable length) | +-----------------------------------------+ | transport protocol 1 (16 bit) | +-----------------------------------------+ | transport parameter length 1 (16 bit) | +-----------------------------------------+ | transport parameter 1 (variable length) | +-----------------------------------------+ | transport protocol 2 (16 bit) | +-----------------------------------------+ | transport parameter length 2 (16 bit) | +-----------------------------------------+ | transport parameter 2 (variable length) | +-----------------------------------------+ : : For TCP and UDP, the transport parameter shall be the IP addresses of the servers if glue record is present. The transport parameter length is used to disambiguate IPv4 and IPv6 addresses. If present, this information overrides the (unsigned) glue, but only for the owner name of the DS record. (Perhaps the name server name should be omitted to force this behavior.) A future Dnscurve-like transport would put the server's public key into the transport parameter. From owner-namedroppers@ops.ietf.org Sun Oct 4 11:44:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A4E28C0F0; Sun, 4 Oct 2009 11:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.284 X-Spam-Level: X-Spam-Status: No, score=0.284 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCJJ8yKf8AmF; Sun, 4 Oct 2009 11:44:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 99AED28C0DC; Sun, 4 Oct 2009 11:44:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuW0U-0006PV-Uz for namedroppers-data0@psg.com; Sun, 04 Oct 2009 18:40:30 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuW0L-0006Oo-MT for namedroppers@ops.ietf.org; Sun, 04 Oct 2009 18:40:29 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MuW0E-0007dG-Vq; Sun, 04 Oct 2009 20:40:15 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MuW0E-0002qm-6G; Sun, 04 Oct 2009 18:40:14 +0000 From: Florian Weimer To: gson@araneus.fi Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-rfc3597-bis-00 References: <200909231901.VAA06003@TR-Sys.de> Date: Sun, 04 Oct 2009 18:40:14 +0000 In-Reply-To: <200909231901.VAA06003@TR-Sys.de> ("Alfred =?iso-8859-1?Q?H?= =?iso-8859-1?Q?=F6nes=22's?= message of "Wed, 23 Sep 2009 21:01:25 +0200 (MESZ)") Message-ID: <87r5tjt33l.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Alfred H=F6nes: > Andreas, > after a first glance at draft-ietf-dnsext-rfc3597-bis-00 : I've got a request, too: Could you please mention that RRsets of unknown type (and perhaps class?) must be ignored in all sections? Thanks. From owner-namedroppers@ops.ietf.org Mon Oct 5 00:02:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4043A6874; Mon, 5 Oct 2009 00:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEEflw2OyhGA; Mon, 5 Oct 2009 00:02:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E83BE3A67A7; Mon, 5 Oct 2009 00:02:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuhVn-000LyD-HF for namedroppers-data0@psg.com; Mon, 05 Oct 2009 06:57:35 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuhVa-000LwB-Tk for namedroppers@ops.ietf.org; Mon, 05 Oct 2009 06:57:33 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n956vHfO014837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2009 08:57:18 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4AC998CD.4050908@nlnetlabs.nl> Date: Mon, 05 Oct 2009 08:57:17 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3 MIME-Version: 1.0 To: Florian Weimer CC: gson@araneus.fi, namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-rfc3597-bis-00 References: <200909231901.VAA06003@TR-Sys.de> <87r5tjt33l.fsf@mid.deneb.enyo.de> In-Reply-To: <87r5tjt33l.fsf@mid.deneb.enyo.de> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 05 Oct 2009 08:57:18 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/04/2009 08:40 PM, Florian Weimer wrote: > I've got a request, too: Could you please mention that RRsets of > unknown type (and perhaps class?) must be ignored in all sections? > Thanks. I disagree, for the answer section. There you expect the answer type. Ignore RRsets of unknown type in the answer section when qtype=ANY. Otherwise, you'd expect only data that you requested there, or CNAMEs, DNAMEs and that kind of interesting types. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkrJmM0ACgkQkDLqNwOhpPggAgCgl5Vbw/rVCKNtSDpD9a6f0PoN TygAnRvLlFkrDonnCis0PG3vi5L92wor =W/hF -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Oct 5 00:20:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6973A6837; Mon, 5 Oct 2009 00:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.988 X-Spam-Level: X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64yPARQDSIUt; Mon, 5 Oct 2009 00:20:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA1963A67A7; Mon, 5 Oct 2009 00:20:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Muhps-000OcE-KV for namedroppers-data0@psg.com; Mon, 05 Oct 2009 07:18:20 +0000 Received: from [83.145.227.89] (helo=gusev.araneus.fi) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Muhpj-000Oax-HB for namedroppers@ops.ietf.org; Mon, 05 Oct 2009 07:18:18 +0000 Received: from guava.gson.org (guava.gson.org [83.145.227.105]) by gusev.araneus.fi (Postfix) with ESMTP id 1685691C1C; Mon, 5 Oct 2009 10:17:47 +0300 (EEST) Received: by guava.gson.org (Postfix, from userid 101) id C5B9675F44; Mon, 5 Oct 2009 10:18:09 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19145.40369.687275.295680@guava.gson.org> Date: Mon, 5 Oct 2009 10:18:09 +0300 To: Florian Weimer Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-rfc3597-bis-00 In-Reply-To: <87r5tjt33l.fsf@mid.deneb.enyo.de> References: <200909231901.VAA06003@TR-Sys.de> <87r5tjt33l.fsf@mid.deneb.enyo.de> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Andreas Gustafsson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Florian Weimer wrote: > I've got a request, too: Could you please mention that RRsets of > unknown type (and perhaps class?) must be ignored in all sections? Could you be more specific as to what situations this would apply in? Clearly, you can't just always "ignore" RRsets of unknown type, because that would conflict with the requirement to transparently transmit them. Or do you actually mean "Unexpected RRsets received in any section of a DNS response must be ignored"? If so, I agree with the requirement, but I think it is outside the scope of the document because it applies equally to known and unknown types. For example, if you were to receive an RP record in the authority section, you should ignore it even if RP is a known type. -- Andreas Gustafsson, gson@araneus.fi From owner-namedroppers@ops.ietf.org Mon Oct 5 10:39:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5903A6A03; Mon, 5 Oct 2009 10:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.317 X-Spam-Level: X-Spam-Status: No, score=0.317 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neAnRSi2BR0m; Mon, 5 Oct 2009 10:39:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4796F3A6977; Mon, 5 Oct 2009 10:39:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MurRD-0009JH-BW for namedroppers-data0@psg.com; Mon, 05 Oct 2009 17:33:31 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MurQu-0009Hs-6w for namedroppers@ops.ietf.org; Mon, 05 Oct 2009 17:33:29 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MurQr-0001Om-98; Mon, 05 Oct 2009 19:33:09 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MurQq-0005zf-MT; Mon, 05 Oct 2009 17:33:08 +0000 From: Florian Weimer To: Andreas Gustafsson Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-rfc3597-bis-00 References: <200909231901.VAA06003@TR-Sys.de> <87r5tjt33l.fsf@mid.deneb.enyo.de> <19145.40369.687275.295680@guava.gson.org> Date: Mon, 05 Oct 2009 17:33:08 +0000 In-Reply-To: <19145.40369.687275.295680@guava.gson.org> (Andreas Gustafsson's message of "Mon, 5 Oct 2009 10:18:09 +0300") Message-ID: <87my454ugb.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Andreas Gustafsson: > Florian Weimer wrote: >> I've got a request, too: Could you please mention that RRsets of >> unknown type (and perhaps class?) must be ignored in all sections? > > Could you be more specific as to what situations this would apply in? > Clearly, you can't just always "ignore" RRsets of unknown type, > because that would conflict with the requirement to transparently > transmit them. Clearly, I was a bit confused yesterday. > Or do you actually mean "Unexpected RRsets received in any section of > a DNS response must be ignored"? That's probably the best way of putting it, thanks. > If so, I agree with the requirement, but I think it is outside the > scope of the document because it applies equally to known and > unknown types. For example, if you were to receive an RP record in > the authority section, you should ignore it even if RP is a known > type. But can you still claim you know its purpose and semnatics if it appears in the wrong section, or with the wrong owner name? But the reference to the owner name clearly indicates that this is not in scope. Perhaps it's possible to extend the scope of 3597 just a little bit? From owner-namedroppers@ops.ietf.org Mon Oct 5 11:16:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E9B3A6A30; Mon, 5 Oct 2009 11:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2QdbBfMmkvc; Mon, 5 Oct 2009 11:16:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B77733A6A2E; Mon, 5 Oct 2009 11:16:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mus4t-000FMc-Gl for namedroppers-data0@psg.com; Mon, 05 Oct 2009 18:14:31 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mus4h-000FKI-97 for namedroppers@ops.ietf.org; Mon, 05 Oct 2009 18:14:29 +0000 Received: from [10.20.30.163] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n95IEC54038359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2009 11:14:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 5 Oct 2009 11:14:11 -0700 To: "Rose, Scott W." , "namedroppers@ops.ietf.org" From: Paul Hoffman Subject: Re: [dnsext] comment about the IANA registry discussion in draft-ietf-dnsext-dnssec-algo-allocation Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 9:20 AM -0400 10/2/09, Rose, Scott W. wrote: >I have a rather minor suggestion for the DNSSEC algorithm registry from the >discussion in Section 3 and 4 in draft-ietf-dnsext-dnssec-algo-allocation. >The sections describe the changes to be made to the DNSSEC algorithm >registry but I think it might be better to include the status (i.e. >MANDATORY, OPTIONAL, etc.) of each algorithm, not just the reference. Just to be clear on my previous "+1": I think this is a good idea for the registry, but *not* for draft-ietf-dnsext-dnssec-algo-allocation. That is, the draft should have the single focus of what level of RFC is needed for the registry. A side-effect of that was the discussion that the registry should track the standards level of the RFCs that cause the registration. This is quite different than tracking the status of an algorithm. In order to determine the latter, you have to choose which RFCs get to be definitive, and that opens a whole new can of worms. If someone wants to write a new draft saying how the IANA registry should mark the requirements levels for algorithms, that's great: I just don't think it should be in draft-ietf-dnsext-dnssec-alg-allocation. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Mon Oct 5 11:35:38 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A6DE3A69A4; Mon, 5 Oct 2009 11:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ-2whsvQkl8; Mon, 5 Oct 2009 11:35:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8AD4A3A69AC; Mon, 5 Oct 2009 11:35:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MusNQ-000Hzr-PB for namedroppers-data0@psg.com; Mon, 05 Oct 2009 18:33:40 +0000 Received: from [83.145.227.89] (helo=gusev.araneus.fi) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MusNH-000HxE-9j for namedroppers@ops.ietf.org; Mon, 05 Oct 2009 18:33:38 +0000 Received: from guava.gson.org (guava.gson.org [83.145.227.105]) by gusev.araneus.fi (Postfix) with ESMTP id 66BF391C0A; Mon, 5 Oct 2009 21:33:06 +0300 (EEST) Received: by guava.gson.org (Postfix, from userid 101) id B1FBD75E40; Mon, 5 Oct 2009 21:33:28 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19146.15351.747757.360505@guava.gson.org> Date: Mon, 5 Oct 2009 21:33:27 +0300 To: Florian Weimer CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-rfc3597-bis-00 In-Reply-To: <87my454ugb.fsf@mid.deneb.enyo.de> References: <200909231901.VAA06003@TR-Sys.de> <87r5tjt33l.fsf@mid.deneb.enyo.de> <19145.40369.687275.295680@guava.gson.org> <87my454ugb.fsf@mid.deneb.enyo.de> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Andreas Gustafsson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Florian Weimer wrote: > > Or do you actually mean "Unexpected RRsets received in any section of > > a DNS response must be ignored"? > > That's probably the best way of putting it, thanks. > > > If so, I agree with the requirement, but I think it is outside the > > scope of the document because it applies equally to known and > > unknown types. For example, if you were to receive an RP record in > > the authority section, you should ignore it even if RP is a known > > type. > > But can you still claim you know its purpose and semnatics if it > appears in the wrong section, or with the wrong owner name? You can't; that's one of the reasons why you ignore it. > But the reference to the owner name clearly indicates that this is > not in scope. > > Perhaps it's possible to extend the scope of 3597 just a little bit? I'd really rather not. Getting a draft through the IETF process is hard enough as it is, and every additional topic discussed is one more potential point of contention and blockage. -- Andreas Gustafsson, gson@araneus.fi From owner-namedroppers@ops.ietf.org Mon Oct 5 11:58:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA013A6A2F; Mon, 5 Oct 2009 11:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8xti1GKn2MB; Mon, 5 Oct 2009 11:58:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EFCFB3A6A2C; Mon, 5 Oct 2009 11:57:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MusiK-000Kzx-3t for namedroppers-data0@psg.com; Mon, 05 Oct 2009 18:55:16 +0000 Received: from [209.85.222.198] (helo=mail-pz0-f198.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Musi7-000KyK-6I for namedroppers@ops.ietf.org; Mon, 05 Oct 2009 18:55:13 +0000 Received: by pzk36 with SMTP id 36so406646pzk.5 for ; Mon, 05 Oct 2009 11:55:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.61.16 with SMTP id o16mr607173wak.15.1254768902917; Mon, 05 Oct 2009 11:55:02 -0700 (PDT) In-Reply-To: <87my454ugb.fsf@mid.deneb.enyo.de> References: <200909231901.VAA06003@TR-Sys.de> <87r5tjt33l.fsf@mid.deneb.enyo.de> <19145.40369.687275.295680@guava.gson.org> <87my454ugb.fsf@mid.deneb.enyo.de> Date: Mon, 5 Oct 2009 11:55:02 -0700 Message-ID: Subject: Re: [dnsext] draft-ietf-dnsext-rfc3597-bis-00 From: Matthew Dempsky To: Florian Weimer Cc: Andreas Gustafsson , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Oct 5, 2009 at 10:33 AM, Florian Weimer wrote: > * Andreas Gustafsson: >> Or do you actually mean "Unexpected RRsets received in any section of >> a DNS response must be ignored"? > > That's probably the best way of putting it, thanks. Would you mind clarifying what you mean here by 'ignore'? In particular, are resolvers still allowed to cache unexpected in-bailiwick RRsets as long as it doesn't affect how they otherwise treat the response (i.e., nxdomain, nodata, referral, answer, whatever)? E.g., if a DNAME-ignorant cache receives a response with a DNAME record and a synthesized CNAME record in response to an A-type query, is it allowed to cache the DNAME record still? If an AAAA-ignorant cache receives a response with AAAA glue records, is it allowed to cache the AAAA record still? From owner-namedroppers@ops.ietf.org Mon Oct 5 12:14:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BC83A691A; Mon, 5 Oct 2009 12:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.091 X-Spam-Level: * X-Spam-Status: No, score=1.091 tagged_above=-999 required=5 tests=[AWL=-1.148, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aId3DDgkptwk; Mon, 5 Oct 2009 12:14:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E66003A6811; Mon, 5 Oct 2009 12:13:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuswH-000MSq-Hl for namedroppers-data0@psg.com; Mon, 05 Oct 2009 19:09:41 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Musw8-000MR6-90 for namedroppers@ops.ietf.org; Mon, 05 Oct 2009 19:09:39 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1Musw5-0003Eu-5j; Mon, 05 Oct 2009 21:09:29 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1Musw4-0006ih-8n; Mon, 05 Oct 2009 19:09:28 +0000 From: Florian Weimer To: Matthew Dempsky Cc: Andreas Gustafsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-rfc3597-bis-00 References: <200909231901.VAA06003@TR-Sys.de> <87r5tjt33l.fsf@mid.deneb.enyo.de> <19145.40369.687275.295680@guava.gson.org> <87my454ugb.fsf@mid.deneb.enyo.de> Date: Mon, 05 Oct 2009 19:09:28 +0000 In-Reply-To: (Matthew Dempsky's message of "Mon, 5 Oct 2009 11:55:02 -0700") Message-ID: <87fx9x3bfb.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Matthew Dempsky: > On Mon, Oct 5, 2009 at 10:33 AM, Florian Weimer wrote: >> * Andreas Gustafsson: >>> Or do you actually mean "Unexpected RRsets received in any section of >>> a DNS response must be ignored"? >> >> That's probably the best way of putting it, thanks. > > Would you mind clarifying what you mean here by 'ignore'? In > particular, are resolvers still allowed to cache unexpected > in-bailiwick RRsets as long as it doesn't affect how they otherwise > treat the response (i.e., nxdomain, nodata, referral, answer, > whatever)? E.g., if a DNAME-ignorant cache receives a response with a > DNAME record and a synthesized CNAME record in response to an A-type > query, is it allowed to cache the DNAME record still? It should not be returned to the client in response to a subsequent query for the DNAME record at its owner name. It probably should be stripped from respones for the original question, too, but that may be subject to debate. > If an AAAA-ignorant cache receives a response with AAAA glue > records, is it allowed to cache the AAAA record still? No, certainly not. This touches forgery resilience, too. It's hard to see how this would be observable anyway---the RRset can't be used for the resolution process itself, it can't be promoted to an answer section, and section 8 of RFC 3597 states that no additional section processing is to be performed for unknown records, so you won't see it there, either. From owner-namedroppers@ops.ietf.org Mon Oct 5 12:21:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3669D28C137; Mon, 5 Oct 2009 12:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=-1.433, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_53=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwKPGBLR1VBu; Mon, 5 Oct 2009 12:21:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6048528C0F2; Mon, 5 Oct 2009 12:21:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mut6P-000NSN-S5 for namedroppers-data0@psg.com; Mon, 05 Oct 2009 19:20:09 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mut6G-000NRC-8h for namedroppers@ops.ietf.org; Mon, 05 Oct 2009 19:20:07 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1B5A72FE8CA1 for ; Mon, 5 Oct 2009 19:19:59 +0000 (UTC) Date: Mon, 5 Oct 2009 15:19:57 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-rfc3597-bis-00 Message-ID: <20091005191956.GN25543@shinkuro.com> References: <200909231901.VAA06003@TR-Sys.de> <87r5tjt33l.fsf@mid.deneb.enyo.de> <4AC998CD.4050908@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AC998CD.4050908@nlnetlabs.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Oct 05, 2009 at 08:57:17AM +0200, W.C.A. Wijngaards wrote: > I disagree, for the answer section. There you expect the answer type. > Ignore RRsets of unknown type in the answer section when qtype=ANY. > Otherwise, you'd expect only data that you requested there, > or CNAMEs, DNAMEs and that kind of interesting types. Are you suggesting, then, that a new "interesting" type (were one to be invented) that required additional processing of this sort would necessarily have to return a synthesized answer of the relevant type for "old" clients? (I think that's what you mean, and I think I agree, but I want to be specific since this affects the position the draft takes on this question.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Oct 5 12:22:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8277E28C280; Mon, 5 Oct 2009 12:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0oiIUa-M3ai; Mon, 5 Oct 2009 12:22:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 979D028C27E; Mon, 5 Oct 2009 12:22:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mut7o-000Nb0-Ph for namedroppers-data0@psg.com; Mon, 05 Oct 2009 19:21:36 +0000 Received: from [209.85.222.198] (helo=mail-pz0-f198.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mut7f-000NZy-Hf for namedroppers@ops.ietf.org; Mon, 05 Oct 2009 19:21:34 +0000 Received: by pzk36 with SMTP id 36so426473pzk.5 for ; Mon, 05 Oct 2009 12:21:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.165.35 with SMTP id n35mr582434wae.183.1254770487293; Mon, 05 Oct 2009 12:21:27 -0700 (PDT) In-Reply-To: <87fx9x3bfb.fsf@mid.deneb.enyo.de> References: <200909231901.VAA06003@TR-Sys.de> <87r5tjt33l.fsf@mid.deneb.enyo.de> <19145.40369.687275.295680@guava.gson.org> <87my454ugb.fsf@mid.deneb.enyo.de> <87fx9x3bfb.fsf@mid.deneb.enyo.de> Date: Mon, 5 Oct 2009 12:21:27 -0700 Message-ID: Subject: Re: [dnsext] draft-ietf-dnsext-rfc3597-bis-00 From: Matthew Dempsky To: Florian Weimer Cc: Andreas Gustafsson , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Oct 5, 2009 at 12:09 PM, Florian Weimer wrote: > * Matthew Dempsky: >> E.g., if a DNAME-ignorant cache receives a response with a >> DNAME record and a synthesized CNAME record in response to an A-type >> query, is it allowed to cache the DNAME record still? > > It should not be returned to the client in response to a subsequent > query for the DNAME record at its owner name. What's your reasoning for this? >> If an AAAA-ignorant cache receives a response with AAAA glue >> records, is it allowed to cache the AAAA record still? > > No, certainly not. =A0This touches forgery resilience, too. Your wording implies there are reasons other than forgery resilience that the AAAA glue records should be discarded. Is this the same as the DNAME case, or are there additional reasons here? > it can't be promoted to an answer section, In practice, additional section records are regularly promoted to the answer section. E.g., A and AAAA records returned in the additional section in response to an MX or SRV query. > and section 8 of RFC 3597 states that no additional section > processing is to be performed for unknown records, so you won't see it > there, either. This seems irrelevant to me: the issue I was suggesting isn't whether an unknown record causes additional section processing or not, but whether an unknown record type is added because of additional section processing. Maybe you're assuming a cache that goes to extra effort to associate additional section records with the answer/authority records that were processed to add them? If so, even in this case, caches might receive a query for a SRV2 record which may include address records in the additional records section; it would be sensible to be prepared to save these, even if the cache itself is unaware of SRV2 records. Thanks. From owner-namedroppers@ops.ietf.org Mon Oct 5 12:23:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D239428C285; Mon, 5 Oct 2009 12:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.658 X-Spam-Level: X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMi8gGePbqUv; Mon, 5 Oct 2009 12:23:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0D86828C280; Mon, 5 Oct 2009 12:23:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mut93-000NkI-VK for namedroppers-data0@psg.com; Mon, 05 Oct 2009 19:22:53 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mut8t-000Nic-Cu for namedroppers@ops.ietf.org; Mon, 05 Oct 2009 19:22:51 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 68C4D2FE8CA1 for ; Mon, 5 Oct 2009 19:22:42 +0000 (UTC) Date: Mon, 5 Oct 2009 15:22:39 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] comment about the IANA registry discussion in draft-ietf-dnsext-dnssec-algo-allocation Message-ID: <20091005192239.GO25543@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Oct 05, 2009 at 11:14:11AM -0700, Paul Hoffman wrote: > > If someone wants to write a new draft saying how the IANA registry > should mark the requirements levels for algorithms, that's great: I > just don't think it should be in > draft-ietf-dnsext-dnssec-alg-allocation. That sounds like a nice suggestion for a housekeeping draft. Any volunteers? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Oct 5 13:11:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECECA3A6975; Mon, 5 Oct 2009 13:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.418 X-Spam-Level: X-Spam-Status: No, score=0.418 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-WZGk-G37Xn; Mon, 5 Oct 2009 13:11:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 052413A681A; Mon, 5 Oct 2009 13:11:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mutqa-0002ED-IC for namedroppers-data0@psg.com; Mon, 05 Oct 2009 20:07:52 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MutqK-0002Bg-VR for namedroppers@ops.ietf.org; Mon, 05 Oct 2009 20:07:44 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MutqE-0003yP-If; Mon, 05 Oct 2009 22:07:30 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MutqD-0007AD-Lj; Mon, 05 Oct 2009 20:07:29 +0000 From: Florian Weimer To: Matthew Dempsky Cc: Andreas Gustafsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-rfc3597-bis-00 References: <200909231901.VAA06003@TR-Sys.de> <87r5tjt33l.fsf@mid.deneb.enyo.de> <19145.40369.687275.295680@guava.gson.org> <87my454ugb.fsf@mid.deneb.enyo.de> <87fx9x3bfb.fsf@mid.deneb.enyo.de> Date: Mon, 05 Oct 2009 20:07:29 +0000 In-Reply-To: (Matthew Dempsky's message of "Mon, 5 Oct 2009 12:21:27 -0700") Message-ID: <87pr91wqny.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Matthew Dempsky: > On Mon, Oct 5, 2009 at 12:09 PM, Florian Weimer wrote: >> * Matthew Dempsky: >>> E.g., if a DNAME-ignorant cache receives a response with a >>> DNAME record and a synthesized CNAME record in response to an A-type >>> query, is it allowed to cache the DNAME record still? >> >> It should not be returned to the client in response to a subsequent >> query for the DNAME record at its owner name. > > What's your reasoning for this? Mainly the observation that it would deliver incomplete RRsets for RRSIG queries today if we didn't have DO. Future interesting records could show similar behavior. >>> If an AAAA-ignorant cache receives a response with AAAA glue >>> records, is it allowed to cache the AAAA record still? >> >> No, certainly not. =A0This touches forgery resilience, too. > > Your wording implies there are reasons other than forgery resilience > that the AAAA glue records should be discarded. Is this the same as > the DNAME case, or are there additional reasons here? You don't really know to which section the additional data is related, and if the RRset is complete (as in the RRSIG case). >> it can't be promoted to an answer section, > > In practice, additional section records are regularly promoted to the > answer section. E.g., A and AAAA records returned in the additional > section in response to an MX or SRV query. Let's just say that BIND is buggy in this regard, okay? >> and section 8 of RFC 3597 states that no additional section >> processing is to be performed for unknown records, so you won't see it >> there, either. > > This seems irrelevant to me: the issue I was suggesting isn't whether > an unknown record causes additional section processing or not, but > whether an unknown record type is added because of additional section > processing. You need two records to end up with additional section processing, so it's at best unclear to me if this applies or not. > Maybe you're assuming a cache that goes to extra effort to associate > additional section records with the answer/authority records that were > processed to add them? I'm worried about BIND 8 style caches which pass through unchecked information of unknown provence, causing correctness issues further downstream. From owner-namedroppers@ops.ietf.org Mon Oct 5 13:36:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56E183A6A35; Mon, 5 Oct 2009 13:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18FaUQBxDrR7; Mon, 5 Oct 2009 13:36:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 79E2A3A67ED; Mon, 5 Oct 2009 13:36:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuuGf-0004di-Gk for namedroppers-data0@psg.com; Mon, 05 Oct 2009 20:34:49 +0000 Received: from [209.85.222.198] (helo=mail-pz0-f198.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuuGW-0004ct-GT for namedroppers@ops.ietf.org; Mon, 05 Oct 2009 20:34:47 +0000 Received: by pzk36 with SMTP id 36so478203pzk.5 for ; Mon, 05 Oct 2009 13:34:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.134.5 with SMTP id l5mr752242wan.70.1254774879054; Mon, 05 Oct 2009 13:34:39 -0700 (PDT) In-Reply-To: <87pr91wqny.fsf@mid.deneb.enyo.de> References: <200909231901.VAA06003@TR-Sys.de> <87r5tjt33l.fsf@mid.deneb.enyo.de> <19145.40369.687275.295680@guava.gson.org> <87my454ugb.fsf@mid.deneb.enyo.de> <87fx9x3bfb.fsf@mid.deneb.enyo.de> <87pr91wqny.fsf@mid.deneb.enyo.de> Date: Mon, 5 Oct 2009 13:34:38 -0700 Message-ID: Subject: Re: [dnsext] draft-ietf-dnsext-rfc3597-bis-00 From: Matthew Dempsky To: Florian Weimer Cc: Andreas Gustafsson , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Oct 5, 2009 at 1:07 PM, Florian Weimer wrote: > Mainly the observation that it would deliver incomplete RRsets for > RRSIG queries today if we didn't have DO. =A0Future interesting records > could show similar behavior. This is why partial RRSIG RRsets can only be sent to clients that understand them (i.e., ones that set DO=3D1). Future record types need to be similarly designed to not cause compatibilities issues. Most new types being introduced don't require partial RRsets, and I don't think the majority of new types should be punished because some new types might have a use case for sending partial sets. > You don't really know to which section the additional data is related, Sorry, I don't follow why a cache needs to know this. > and if the RRset is complete (as in the RRSIG case). RRSIG is exceptional; see above. >> In practice, additional section records are regularly promoted to the >> answer section. =A0E.g., A and AAAA records returned in the additional >> section in response to an MX or SRV query. > > Let's just say that BIND is buggy in this regard, okay? I disagree. I think the spec is buggy for not adequately documenting how DNS works in practice. Otherwise, if caches aren't allowed to include additional section records in the answer section, then authoritative servers should stop performing additional section processing on MX and SRV records. Is there any production MTA/XMPP/whatever software whose stub resolver looks at records in the additional records section? From owner-namedroppers@ops.ietf.org Mon Oct 5 14:48:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562D228C0F3; Mon, 5 Oct 2009 14:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.352 X-Spam-Level: X-Spam-Status: No, score=-98.352 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7WvCORFXiPz; Mon, 5 Oct 2009 14:48:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 53DC33A6407; Mon, 5 Oct 2009 14:48:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuvMF-000EFx-EB for namedroppers-data0@psg.com; Mon, 05 Oct 2009 21:44:39 +0000 Received: from [58.68.145.64] (helo=people.com.cn) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuvKt-000E3z-Sh for namedroppers@ops.ietf.org; Mon, 05 Oct 2009 21:43:23 +0000 Received: from people.com.cn([192.168.12.38]) by people.com.cn(AIMC 4.0.0.0) with SMTP id jm44acaa9b7; Tue, 06 Oct 2009 04:55:47 +0800 Received: from mail.ietf.org([127.0.0.1]) by people.com.cn(AIMC 4.0.0.0) with SMTP id jme4aa65c68; Tue, 08 Sep 2009 21:04:31 +0800 Received: from mail.ietf.org([64.170.98.32]) by aisp.com(AIMC 3.2.0.0) with SMTP id AISP action; Tue, 08 Sep 2009 21:04:31 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BE2828C13B; Tue, 8 Sep 2009 06:50:02 -0700 (PDT) X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4507228C136; Tue, 8 Sep 2009 06:49:59 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Subject: [dnsext] Last Call: draft-ietf-dnsext-dnssec-rsasha256 (Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC) to Proposed Standard Message-Id: <20090908135000.4507228C136@core3.amsl.com> Date: Tue, 8 Sep 2009 06:50:00 -0700 (PDT) Cc: namedroppers@ops.ietf.org X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: ietf@ietf.org List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-Msg-ID: vpWXAlWB X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-14.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14237&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From owner-namedroppers@ops.ietf.org Mon Oct 5 22:59:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7BB28C2C9; Mon, 5 Oct 2009 22:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.437 X-Spam-Level: X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Qk8VsIgtKyA; Mon, 5 Oct 2009 22:59:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1CD8428C2D5; Mon, 5 Oct 2009 22:59:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mv2zi-00092A-2o for namedroppers-data0@psg.com; Tue, 06 Oct 2009 05:53:54 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mv2zY-00090p-Dk for namedroppers@ops.ietf.org; Tue, 06 Oct 2009 05:53:51 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1Mv2zS-0000Ql-If; Tue, 06 Oct 2009 07:53:38 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1Mv2zR-00028Y-W3; Tue, 06 Oct 2009 05:53:38 +0000 From: Florian Weimer To: Matthew Dempsky Cc: Andreas Gustafsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-rfc3597-bis-00 References: <200909231901.VAA06003@TR-Sys.de> <87r5tjt33l.fsf@mid.deneb.enyo.de> <19145.40369.687275.295680@guava.gson.org> <87my454ugb.fsf@mid.deneb.enyo.de> <87fx9x3bfb.fsf@mid.deneb.enyo.de> <87pr91wqny.fsf@mid.deneb.enyo.de> Date: Tue, 06 Oct 2009 05:53:37 +0000 In-Reply-To: (Matthew Dempsky's message of "Mon, 5 Oct 2009 13:34:38 -0700") Message-ID: <877hv9oyou.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Matthew Dempsky: > On Mon, Oct 5, 2009 at 1:07 PM, Florian Weimer wrote: >> Mainly the observation that it would deliver incomplete RRsets for >> RRSIG queries today if we didn't have DO. =A0Future interesting records >> could show similar behavior. > > This is why partial RRSIG RRsets can only be sent to clients that > understand them (i.e., ones that set DO=3D1). It seems to me that the DO bit was specified for SIG and others. It was re-used for RRSIG later, so the behavior i described could actually happen with RRSIG. > Future record types need to be similarly designed to not cause > compatibilities issues. But RRSIG wasn't, and this is exactly my point. Why should future RR types behave differently from RRSIG? >>> In practice, additional section records are regularly promoted to the >>> answer section. =A0E.g., A and AAAA records returned in the additional >>> section in response to an MX or SRV query. >> >> Let's just say that BIND is buggy in this regard, okay? > > I disagree. I think the spec is buggy for not adequately documenting > how DNS works in practice. BIND 9 was written after RFC 2181 was published. Even today, it is not entirely safe to configure BIND 9 as a forwarder to anything which isn't BIND 9 itself (and which might pass additional section data unfiltered). To bring this back to 3597bis, my concern is that past incidents show that unclear responsibilities for additional section processing between forwarders. As a result, I think that records of unknown type should not be blindly copied into reponses because their effect is unknown. > Otherwise, if caches aren't allowed to include additional section > records in the answer section, then authoritative servers should > stop performing additional section processing on MX and SRV records. Not performing additional section processing is becoming more and more common. It also helps cut down response size for signed zones. > Is there any production MTA/XMPP/whatever software whose stub resolver > looks at records in the additional records section? Exim tried to do this, but turned out to be too difficult to implement correctly for too little gain, so the code was removed. From justin@absi-usa.com Mon Oct 5 23:42:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC67B28C0E9 for ; Mon, 5 Oct 2009 23:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.405 X-Spam-Level: X-Spam-Status: No, score=-16.405 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZXXO87SQ58j for ; Mon, 5 Oct 2009 23:42:53 -0700 (PDT) Received: from pc-199-92-164-190.cm.vtr.net (pc-199-92-164-190.cm.vtr.net [190.164.92.199]) by core3.amsl.com (Postfix) with SMTP id F068D28C0ED for ; Mon, 5 Oct 2009 23:42:51 -0700 (PDT) To: Subject: Your order #173914 From: Priscilla Arthur MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091006064251.F068D28C0ED@core3.amsl.com> Date: Mon, 5 Oct 2009 23:42:51 -0700 (PDT)
Click here to view as a web page.

View image in browser now
Unsubscribe | Change e-mail address | Privacy Policy | About Us

Copyright © 2009 wowqr Inc. All rights reserved.
From kvmq@2ndthoughts.co.uk Tue Oct 6 01:57:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8630C28C146 for ; Tue, 6 Oct 2009 01:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.64 X-Spam-Level: X-Spam-Status: No, score=-9.64 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PnCW6hrMyhe for ; Tue, 6 Oct 2009 01:57:30 -0700 (PDT) Received: from 202-176-90-74.static.asianet.co.th (202-176-90-74.static.asianet.co.th [202.176.90.74]) by core3.amsl.com (Postfix) with SMTP id 5830D28C144 for ; Tue, 6 Oct 2009 01:57:28 -0700 (PDT) To: Subject: Re: Order status #494652 From: Sonja Dupree MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091006085729.5830D28C144@core3.amsl.com> Date: Tue, 6 Oct 2009 01:57:28 -0700 (PDT)
Click here to view as a web page.

View image in browser now
Unsubscribe | Change e-mail address | Privacy Policy | About Us

Copyright © 2009 wowqr Inc. All rights reserved.
From owner-namedroppers@ops.ietf.org Tue Oct 6 05:05:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D183A6807; Tue, 6 Oct 2009 05:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4e5Cj964dzHL; Tue, 6 Oct 2009 05:05:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A0AE23A67B2; Tue, 6 Oct 2009 05:05:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mv8ib-000Lp7-DX for namedroppers-data0@psg.com; Tue, 06 Oct 2009 12:00:37 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mv8iJ-000LkP-IU for namedroppers@ops.ietf.org; Tue, 06 Oct 2009 12:00:32 +0000 Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n96C06w8024648; Tue, 6 Oct 2009 08:00:06 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Tue, 6 Oct 2009 08:00:06 -0400 From: "Rose, Scott W." To: Andrew Sullivan , "namedroppers@ops.ietf.org" Date: Tue, 6 Oct 2009 08:00:05 -0400 Subject: Re: [dnsext] comment about the IANA registry discussion in draft-ietf-dnsext-dnssec-algo-allocation Thread-Topic: [dnsext] comment about the IANA registry discussion in draft-ietf-dnsext-dnssec-algo-allocation Thread-Index: AcpF8f2qC+pLNE4KQWKCJ+u3VBy3EAAio0BE Message-ID: In-Reply-To: <20091005192239.GO25543@shinkuro.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Well I brought it up, so I guess I should volunteer. I'll try and beat the deadline for -00 drafts. Scott On 10/5/09 3:22 PM, "Andrew Sullivan" wrote: > On Mon, Oct 05, 2009 at 11:14:11AM -0700, Paul Hoffman wrote: >>=20 >> If someone wants to write a new draft saying how the IANA registry >> should mark the requirements levels for algorithms, that's great: I >> just don't think it should be in >> draft-ietf-dnsext-dnssec-alg-allocation. >=20 > That sounds like a nice suggestion for a housekeeping draft. Any > volunteers? >=20 > A >=20 > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. >=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scottr@nist.gov ph: +1 301-975-8439 http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-namedroppers@ops.ietf.org Tue Oct 6 06:51:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68E93A694F; Tue, 6 Oct 2009 06:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=-1.069, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhQAESprSEfb; Tue, 6 Oct 2009 06:51:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 340373A693F; Tue, 6 Oct 2009 06:51:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvAOc-000ApB-Tb for namedroppers-data0@psg.com; Tue, 06 Oct 2009 13:48:06 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvAOS-000AoA-LU for namedroppers@ops.ietf.org; Tue, 06 Oct 2009 13:48:04 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3EBCE2FE8CA1 for ; Tue, 6 Oct 2009 13:47:52 +0000 (UTC) Date: Tue, 6 Oct 2009 09:47:50 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] comment about the IANA registry discussion in draft-ietf-dnsext-dnssec-algo-allocation Message-ID: <20091006134749.GE27462@shinkuro.com> References: <20091005192239.GO25543@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Oct 06, 2009 at 08:00:05AM -0400, Rose, Scott W. wrote: > > Well I brought it up, so I guess I should volunteer. I'll try and beat > the deadline for -00 drafts. Thanks! A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Oct 6 07:18:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20C23A6925; Tue, 6 Oct 2009 07:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.325 X-Spam-Level: X-Spam-Status: No, score=-0.325 tagged_above=-999 required=5 tests=[AWL=-1.325, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm8QmX8mFuHt; Tue, 6 Oct 2009 07:18:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE5E53A6884; Tue, 6 Oct 2009 07:18:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvApb-000Dwj-3P for namedroppers-data0@psg.com; Tue, 06 Oct 2009 14:15:59 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvApN-000DuY-CA for namedroppers@ops.ietf.org; Tue, 06 Oct 2009 14:15:53 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 40E622FE8CA1 for ; Tue, 6 Oct 2009 14:15:43 +0000 (UTC) Date: Tue, 6 Oct 2009 10:15:40 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] DNSEXT session at IETF 76 Message-ID: <20091006141540.GH27462@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, The DNS Extensions WG has a session scheduled for IETF 76 in Hiroshima. We are currently slotted for Tuesday afternoon, from 13:00-15:00. Here's what else is in that slot: Acacia 1 APP hybi BiDirectional or Server-Initiated HTTP BOF Orchid 3 INT dnsext DNS Extensions WG Camellia INT mip4 Mobility for IPv4 WG Orchid 1 OPS v6ops IPv6 Operations WG Orchid 2 RAI mmusic Multiparty Multimedia Session Control WG Acacia 2 RTG idr Inter-Domain Routing WG Cattleya 2 SEC pkix Public-Key Infrastructure (X.509) WG Cattleya 1 TSV ippm IP Performance Metrics WG Please let Olafur and me know if there is a conflict here such that you need us to request a rescheduling of the session. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Oct 6 10:15:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A423A67E9; Tue, 6 Oct 2009 10:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.455 X-Spam-Level: X-Spam-Status: No, score=0.455 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqVfMXijU1mQ; Tue, 6 Oct 2009 10:15:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD9D328C0EF; Tue, 6 Oct 2009 10:15:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvDYC-0009rC-4W for namedroppers-data0@psg.com; Tue, 06 Oct 2009 17:10:12 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvDY0-0009mp-1F for namedroppers@ops.ietf.org; Tue, 06 Oct 2009 17:10:07 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MvDXx-0005Et-1U; Tue, 06 Oct 2009 19:09:57 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MvDXw-000636-Ii; Tue, 06 Oct 2009 17:09:56 +0000 From: Florian Weimer To: "George Barwood" Cc: Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00.txt - WG item References: <835E5B3A3A314D0E9E47CB3C4F9BC412@localhost> <0BB1C903022546B381AA1ACAD3B19A47@localhost> <878wfr8tll.fsf@mid.deneb.enyo.de> <027C131A5B8948F6B5E97E3305F129C2@localhost> Date: Tue, 06 Oct 2009 17:09:56 +0000 In-Reply-To: <027C131A5B8948F6B5E97E3305F129C2@localhost> (George Barwood's message of "Tue, 6 Oct 2009 08:46:08 +0100") Message-ID: <87r5tgh2jf.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * George Barwood: >> This is likely to break backwards compatiblity. > > Florian explained to me off-list that following the introduction of > the AAAA record, some operational problems were encountered, > and apparently these broken resolvers are still deployed quite widely > in parts of Europe. This sems odd, considering that AAAA > records are sent in response to the priming query and many TLDs > now have AAAA records. In view of this, I don't expect such problems > to be serious, but will include something in the security section when > I update the draft. AAAA is a bad example. But the original DNSSEC records were causing problems, eventually leading to the DO flag. It seems that resolvers which send DO=1 queries can be expected to be more tolerant (NSEC3 proves that for the authority section at least). From owner-namedroppers@ops.ietf.org Tue Oct 6 11:22:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2126328C1E9; Tue, 6 Oct 2009 11:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsNm-DBLXRYx; Tue, 6 Oct 2009 11:22:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A39828C1DD; Tue, 6 Oct 2009 11:22:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvEam-000KK6-L8 for namedroppers-data0@psg.com; Tue, 06 Oct 2009 18:16:56 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvEaX-000KIV-7b for namedroppers@ops.ietf.org; Tue, 06 Oct 2009 18:16:53 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id EF9443A67F4; Tue, 6 Oct 2009 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091006181501.EF9443A67F4@core3.amsl.com> Date: Tue, 6 Oct 2009 11:15:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Transport over TCP Author(s) : R. Bellis Filename : draft-ietf-dnsext-dns-tcp-requirements-00.txt Pages : 8 Date : 2009-10-06 This document updates the requirements for the support of the TCP protocol for the transport of DNS traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-tcp-requirements-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-dns-tcp-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-06110611.I-D@ietf.org> --NextPart-- From owner-namedroppers@ops.ietf.org Tue Oct 6 12:17:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3645428C218; Tue, 6 Oct 2009 12:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.111 X-Spam-Level: X-Spam-Status: No, score=0.111 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmDRYt+alVVq; Tue, 6 Oct 2009 12:17:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E41F28C21A; Tue, 6 Oct 2009 12:17:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvFUD-0000Dv-7C for namedroppers-data0@psg.com; Tue, 06 Oct 2009 19:14:13 +0000 Received: from [209.85.221.174] (helo=mail-qy0-f174.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvFSf-000Px9-6S for namedroppers@ops.ietf.org; Tue, 06 Oct 2009 19:13:32 +0000 Received: by qyk4 with SMTP id 4so3698591qyk.33 for ; Tue, 06 Oct 2009 12:12:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.96.100 with SMTP id g36mr1689680qan.384.1254856356202; Tue, 06 Oct 2009 12:12:36 -0700 (PDT) In-Reply-To: <20091006181501.EF9443A67F4@core3.amsl.com> References: <20091006181501.EF9443A67F4@core3.amsl.com> Date: Tue, 6 Oct 2009 12:12:36 -0700 Message-ID: Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-00.txt From: Matthew Dempsky To: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I have a two comments on section 4 of this draft. First, regarding the list of conditions under which a server may opt to disable TCP support: is there a reason why DNSSEC specifically requires TCP? I assume the main rationale for this is because DNSSEC responses will frequently be larger than 512 bytes, but this more general condition is already listed. I would rather suggest removing the DNSSEC condition from the list, and separately adding an informative comment pointing out that supporting DNSSEC will likely require >512 byte responses. Rationale: Current DNSSEC signature/key algorithms and record formats frequently require large responses, but if new algorithms and formats later allow smaller responses, I don't see a reason TCP support should be required then. Second, regarding the relaxation of requiring UDP before TCP: I'm not opposed to this, but I think it should be again mentioned that some servers may not support TCP (as permitted earlier in the section) and it's the client's responsibility to ensure this doesn't cause problems. Rationale: The current RFCs (and even this draft) allow some servers to not support TCP and currently clients are required to try UDP before TCP; it's the responsibility of new clients that have differing behavior to be compatible with existing servers. Otherwise, I like the draft right now. From owner-namedroppers@ops.ietf.org Tue Oct 6 12:34:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4568D3A687E; Tue, 6 Oct 2009 12:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.413 X-Spam-Level: X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5 tests=[AWL=0.082, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXNDyjHq+rVN; Tue, 6 Oct 2009 12:34:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0CB9B3A6833; Tue, 6 Oct 2009 12:34:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvFkt-000254-HB for namedroppers-data0@psg.com; Tue, 06 Oct 2009 19:31:27 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvFkg-000245-L0 for namedroppers@ops.ietf.org; Tue, 06 Oct 2009 19:31:22 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 728C4C2DA5; Tue, 6 Oct 2009 20:31:12 +0100 (BST) Date: Tue, 06 Oct 2009 20:30:51 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ray Bellis cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-00.txt Message-ID: <58730CF87FB0584289BCBCBD@Ximines.local> In-Reply-To: <20091006181501.EF9443A67F4@core3.amsl.com> References: <20091006181501.EF9443A67F4@core3.amsl.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 6 October 2009 11:15:01 -0700 Internet-Drafts@ietf.org wrote: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-tcp-requirement > s-00.txt I support this draft. Comments 1. Section 4. I think you should a clear section of mandatory support. IE start the section with "all DNS servers and clients MUST support both UDP and TCP transports, except as set out below". I know this is partly handled within section 1, but I think given the lack of clarity to date, it is worth spelling out. 2. Section 4 > A proprietary stub resolver implementation MAY omit support for TCP > if it is operating in an environment where truncation will not occur, > or if it is prepared to accept a DNS lookup failure should truncation > occur. At the least, I would suggest making this "where truncation can never occur" (as opposed to "will not"), and thus also applying this only to proprietary stub resolvers that do not support DNSSEC, because in practice it seems impossible to guarantee truncation won't occur with DNSSEC and or have truncated responses be considered acceptable (i.e. presumably the same reason you carved out DNSSEC supporting servers). By "truncation will not occur" do you mean "transactions will never exceed 512 bytes" (the criterion you applied to servers) or do you mean that if the stub resolver can guarantee its path MTU is >512, and the recursive server supports EDNS0, and it supports EDNS0, then otherwise guaranteeing that truncation won't occur is OK? It just seems a little bit peculiar to have one rule for the server and one for the client. I'm also slightly concerned about the apparent need for psychic powers on the client's side. However, my preference would be to make your carve-out apply only "if the resolver can guarantee that any response to its query can be expressed in a response of fewer than 512 bytes (or where truncation to 512 bytes would be acceptable in all circumstances), and where no queries are made with DO set". 3. Section 6 Before you get to re-ordering, you should consider pipelining. I'm not sure there is yet a MUST for support for a second query to be issued on a TCP connection before the first one is answered (I am prepared to be proved wrong here); previous namedroppers dialog suggests at least some servers support it, and at least some clients support it. I think if the server isn't going to support it, it should close the connection. It seems to me that we need something like: * Having sent one or more queries on a TCP connection, the client MAY, if the TCP connection remains open, send further queries before receiving responses to outstanding queries. * The client MUST NOT (?) close the TCP connection whilst responses remain outstanding unless [timeout occurs] * The server MAY close the TCP connection at any time when no response is outstanding, or MAY leave the connection open allowing the client to close it. Nits: 4. End of section 3: > The future that was anticipated in RFC 1123 is now here, and the only "now" is not a good word to use, as at the time of reading many years in the future, "now" will mean something different. Suggest replacing paragraph by: "The new record types needed by (inter alia) DNSSEC thus require, as predicted by RFC 1123, universal support for TCP transport". -- Alex Bligh From owner-namedroppers@ops.ietf.org Tue Oct 6 13:12:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8480D3A69DA; Tue, 6 Oct 2009 13:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.055 X-Spam-Level: X-Spam-Status: No, score=-5.055 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4Pqcgpqm6Sf; Tue, 6 Oct 2009 13:12:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F7153A6997; Tue, 6 Oct 2009 13:12:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvGMG-000667-VE for namedroppers-data0@psg.com; Tue, 06 Oct 2009 20:10:04 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvGM7-00064S-GJ for namedroppers@ops.ietf.org; Tue, 06 Oct 2009 20:10:02 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n96K9sFV013067; Tue, 6 Oct 2009 13:09:54 -0700 (PDT) From: Nicholas Weaver Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: [dnsext] Why ZSK rollover is a Bad Idea (tm) Date: Tue, 6 Oct 2009 16:09:53 -0400 Message-Id: <1C586E51-D77C-406C-9B89-47276A9B41B2@ICSI.Berkeley.EDU> Cc: Nicholas Weaver To: "namedroppers@ops.ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Eric Rescorla has an explanation why the zone signing key rollover mechanism in DNSSEC for the root is a bad idea: It doesn't improve security and only makes things more complicated: http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html > The more general lesson here is that changing keys rapidly is nearly > useless as a method of preventing analytic attacks. It's almost > never practical to change keys frequently enough to have a > significant impact on the attacker's required level of effort. If > you're that close to the edge of a successful attack, what you need > is a stronger key, not to change your weak keys more frequently. In > the specific case of DNSSEC, just expanding the size of the packet > by 10 bytes or so would have as much if not more security impact at > a far lower system complexity cost. From owner-namedroppers@ops.ietf.org Tue Oct 6 14:06:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462CD28C14B; Tue, 6 Oct 2009 14:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCxyQEhrFp6r; Tue, 6 Oct 2009 14:06:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3035628C14E; Tue, 6 Oct 2009 14:06:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvHBa-000Asd-Pn for namedroppers-data0@psg.com; Tue, 06 Oct 2009 21:03:06 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvHBQ-000ApV-Gr for namedroppers@ops.ietf.org; Tue, 06 Oct 2009 21:03:04 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n96L2qJw037429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Oct 2009 14:02:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1C586E51-D77C-406C-9B89-47276A9B41B2@ICSI.Berkeley.EDU> References: <1C586E51-D77C-406C-9B89-47276A9B41B2@ICSI.Berkeley.EDU> Date: Tue, 6 Oct 2009 14:02:49 -0700 To: Nicholas Weaver , "namedroppers@ops.ietf.org WG" From: Paul Hoffman Subject: Re: [dnsext] Why ZSK rollover is a Bad Idea (tm) Cc: Eric Rescorla Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 4:09 PM -0400 10/6/09, Nicholas Weaver wrote: >Eric Rescorla has an explanation why the zone signing key rollover mechanism in DNSSEC for the root is a bad idea: It doesn't improve security and only makes things more complicated: > >http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html > >>The more general lesson here is that changing keys rapidly is nearly useless as a method of preventing analytic attacks. It's almost never practical to change keys frequently enough to have a significant impact on the attacker's required level of effort. If you're that close to the edge of a successful attack, what you need is a stronger key, not to change your weak keys more frequently. In the specific case of DNSSEC, just expanding the size of the packet by 10 bytes or so would have as much if not more security impact at a far lower system complexity cost. I won't speak for Ekr, but I see his argument being against ZSKs in general, not just at the root. It's the same argument I have tried to make in DNSOP. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Tue Oct 6 14:32:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E875128C0EF; Tue, 6 Oct 2009 14:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[AWL=-0.887, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzFgTC8jzpbu; Tue, 6 Oct 2009 14:32:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC2223A6967; Tue, 6 Oct 2009 14:32:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvHbL-000DIC-24 for namedroppers-data0@psg.com; Tue, 06 Oct 2009 21:29:43 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvHbB-000DHd-3V for namedroppers@ops.ietf.org; Tue, 06 Oct 2009 21:29:41 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n96LTVhk034123 for ; Tue, 6 Oct 2009 17:29:31 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n96LTV8N034122 for namedroppers@ops.ietf.org; Tue, 6 Oct 2009 17:29:31 -0400 (EDT) (envelope-from namedroppers) Received: from [209.85.217.209] (helo=mail-gx0-f209.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvHGg-000BSj-Vx for namedroppers@ops.ietf.org; Tue, 06 Oct 2009 21:08:33 +0000 Received: by gxk1 with SMTP id 1so5570726gxk.19 for ; Tue, 06 Oct 2009 14:08:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.144.16 with SMTP id w16mr975331agn.21.1254863296885; Tue, 06 Oct 2009 14:08:16 -0700 (PDT) In-Reply-To: References: <1C586E51-D77C-406C-9B89-47276A9B41B2@ICSI.Berkeley.EDU> Date: Tue, 6 Oct 2009 14:08:16 -0700 Message-ID: Subject: Re: [dnsext] Why ZSK rollover is a Bad Idea (tm) From: Eric Rescorla To: Paul Hoffman Cc: Nicholas Weaver , "namedroppers@ops.ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On Tue, Oct 6, 2009 at 2:02 PM, Paul Hoffman wrote: > At 4:09 PM -0400 10/6/09, Nicholas Weaver wrote: >>Eric Rescorla has an explanation why the zone signing key rollover mechan= ism in DNSSEC for the root is a bad idea: =A0It doesn't improve security an= d only makes things more complicated: >> >>http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.h= tml >> >>>The more general lesson here is that changing keys rapidly is nearly use= less as a method of preventing analytic attacks. It's almost never practica= l to change keys frequently enough to have a significant impact on the atta= cker's required level of effort. If you're that close to the edge of a succ= essful attack, what you need is a stronger key, not to change your weak key= s more frequently. In the specific case of DNSSEC, just expanding the size = of the packet by 10 bytes or so would have as much if not more security imp= act at a far lower system complexity cost. > > I won't speak for Ekr, but I see his argument being against ZSKs in gener= al, not just at the root. It's the same > argument I have tried to make in DNSOP. I don't have a general position on ZSKs--perhaps it's a good idea for some other reason--but I don't think that rolling the keys over at high rates provides any significant security benefit, no matter where in the hierarchy you're doing it. -Ekr From owner-namedroppers@ops.ietf.org Wed Oct 7 01:29:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD5128C118; Wed, 7 Oct 2009 01:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-CljrIK1Teg; Wed, 7 Oct 2009 01:29:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 75ADF28C1C1; Wed, 7 Oct 2009 01:28:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvRoP-000M11-GX for namedroppers-data0@psg.com; Wed, 07 Oct 2009 08:23:53 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvRoA-000Lyy-5b for namedroppers@ops.ietf.org; Wed, 07 Oct 2009 08:23:48 +0000 Received: from [IPv6:2001:67c:64:42:226:bbff:fe0e:7cc7] ([IPv6:2001:67c:64:42:226:bbff:fe0e:7cc7]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n978NJ8K004266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Oct 2009 10:23:20 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Subject: Re: [dnsext] Why ZSK rollover is a Bad Idea (tm) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-11--428792406; protocol="application/pkcs7-signature"; micalg=sha1 From: Olaf Kolkman In-Reply-To: Date: Wed, 7 Oct 2009 09:23:18 +0100 Cc: Paul Hoffman , Nicholas Weaver , "namedroppers@ops.ietf.org WG" Message-Id: References: <1C586E51-D77C-406C-9B89-47276A9B41B2@ICSI.Berkeley.EDU> To: Eric Rescorla , dnsop@ietf.org X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Wed, 07 Oct 2009 10:23:28 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --Apple-Mail-11--428792406 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On Oct 6, 2009, at 10:08 PM, Eric Rescorla wrote: > [ Moderators note: Post was moderated, either because it was posted by > a non-subscriber, or because it was over 20K. > With the massive amount of spam, it is easy to miss and therefore > delete relevant posts by non-subscribers. > Please fix your subscription addresses. ] > > On Tue, Oct 6, 2009 at 2:02 PM, Paul Hoffman > wrote: >> At 4:09 PM -0400 10/6/09, Nicholas Weaver wrote: >>> Eric Rescorla has an explanation why the zone signing key rollover >>> mechanism in DNSSEC for the root is a bad idea: It doesn't >>> improve security and only makes things more complicated: >>> >>> http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html >>> >>>> The more general lesson here is that changing keys rapidly is >>>> nearly useless as a method of preventing analytic attacks. It's >>>> almost never practical to change keys frequently enough to have a >>>> significant impact on the attacker's required level of effort. If >>>> you're that close to the edge of a successful attack, what you >>>> need is a stronger key, not to change your weak keys more >>>> frequently. In the specific case of DNSSEC, just expanding the >>>> size of the packet by 10 bytes or so would have as much if not >>>> more security impact at a far lower system complexity cost. >> >> I won't speak for Ekr, but I see his argument being against ZSKs in >> general, not just at the root. It's the same >> argument I have tried to make in DNSOP. > > > I don't have a general position on ZSKs--perhaps it's a good idea for > some other reason--but I don't > think that rolling the keys over at high rates provides any > significant security benefit, no matter > where in the hierarchy you're doing it. Really this is an DNSOP issues, more specifically an issue for RFC4641bis. [I've added dnsop, please remove namedroppers when replying to this note] RFC4641 argues for frequent ZSK rollovers, the argument therein is based on operational arguments that are (implicitly) based on operator acces to private keys and/or the timeline in which changes in which the (zone) operator may need to be replaced. EKRs argument is based on cryptographic strength and argues another view. The current considerations need to be made more explicit. I've added this as an issue to the issue tracker. See (http://www.nlnetlabs.nl//svn/I-D-dnsop-rfc4641bis/trunk/open-issues/ ) I hope I can address a few of the issues before Yokohama. --Olaf ________________________________________________________ Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam --Apple-Mail-11--428792406 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMTCCBS0w ggMVoAMCAQICAwbqdTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA1MjUwODQ4MTJaFw0x MTA1MjUwODQ4MTJaMDkxFTATBgNVBAMTDE9sYWYgS29sa21hbjEgMB4GCSqGSIb3DQEJARYRb2xh ZkBubG5ldGxhYnMubmwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxtZNngmuLgcf rto+Uax1WhonECqb5W8US2Z+ZPw/ASKsjKEF8Wa3Nnispys6Gj9Sl7C1X0/2pH//qauLpBqA+lHW L9mgdGW1T9KU1Fb8Odqw0PBnIIhbLNQzecZL+BchEetcrubplQWzDOpROCJ00IwXksusBiKqhew4 u7X2QoraW+z32Knj5ogajIhdkAeBHUy1pwXsk/mDnV8cIEdz1MhaZWDSn7kJUQtRMVCpFBjVoiXh ToXMJfiMvn0CKaeFxFm72dcdzvFsw906Ndafd2MOfdP7QSsTVP6sG9am790AOgkzxT5CM77IDPbD zxZlQ8jTdhcp/WtUrFWIU4QBAgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRw Oi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3 CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZo dHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW9sYWZAbmxuZXRsYWJzLm5sMA0GCSqG SIb3DQEBBQUAA4ICAQCLpawAoUQAxivf6blyMswVokRmDl2JGEbtmEu8j0h1BVOlGh6hlI8WaeWy 3x2jJ9uun3VK6oYnHy45ez+dUDjBLjOZdAgwFg225lm1OPdmisghDDVwCIiEogHPqmJtvKYMFoPF 3iFUambJDoQF8DeVeg8ctDvsxsaVGjA8OrMpo0K4I11vnNbCLv7mWCjnaZWt/6Y6TD8ErHQl5dmI rpsHmEZx1/nsocdPkZGRA4QVf1omYHUNs79DtxpYdGKHoorpBNzlzIIjpceiqeOeykoDeYLTZX2G c7Mh4Gdj2MHFqZucxV1cHibb8XKv8ebaGltMV5SrciqRn8yFXmiyTvmId6myNXLiOx+VJiGbLSS3 TltM/kf7UejXeEHulEKufU6Ya6EfH7W2/spTayYCauyLljOjE2Ey5A4oIoJV9eY64OCDuLF2nmGR jOh3JB9nGkZIPhmTUwGZnMELLhzKz+eOZoulM4tXH6KEubed1shQEq1dkJ+tFtRS3Lm+vLCKWvVo 1iZScqPaQf9riPApAVrL+3Wat0p/jtCk5gLBF02uTiWvT2t4ZfSHMEBXR7CvVm58etRQuyZSMHyz UQC4wkDvCeVawNRCZjq6wWdvx5hmr2JeDSkkRtSZ/Fa1WXf26b3BZugI75p5JXafbWdOTRpNc8M5 YMk7tx29ZG3u0qODgDGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMG6nUwCQYFKw4DAhoFAKCCAYcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMDA3MDgyMzE4WjAj BgkqhkiG9w0BCQQxFgQU6uk6NmK5BnPCJ/lVIZC52w4fxAowgZEGCSsGAQQBgjcQBDGBgzCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDBup1MIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBB dXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBup1MA0GCSqGSIb3 DQEBAQUABIIBACc8LCfcIv9eoY1UIkQ+5G1Wc1rVJdYVr4zCEnib1LWFVPOmHFmiYprgauUmYEKF iVNAF4cUvmv6qd23Dox7jFExpBjrz9qtaVAWiU4JLsSxmy3nudNomXcuduhbzD7DS/lI7RhQqne1 fkTu0nFvFkVJG4mgTB/YvbNot+CHBr0yL3IaXXBrLa5FfWEmwv5U1soxFi2uEBrDdl1qb5P8QPgK vMHQGz2C2Rz8cxtAi8GxKf+cdmFNn6zCANHQYcuvi8gGwYvr8chsz7xklSpDOTBD91hRbKzqB6sX 4SSXo6hl8Iq943JpK8wrXgEQmYl0QNTKgGWedzdNO+iMVtlK5QkAAAAAAAA= --Apple-Mail-11--428792406-- From owner-namedroppers@ops.ietf.org Wed Oct 7 02:37:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221463A6A6E; Wed, 7 Oct 2009 02:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpwER7TWBHFT; Wed, 7 Oct 2009 02:37:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D573C3A6A6C; Wed, 7 Oct 2009 02:36:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvStv-0003j1-Kw for namedroppers-data0@psg.com; Wed, 07 Oct 2009 09:33:39 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvStf-0003gL-4W for namedroppers@ops.ietf.org; Wed, 07 Oct 2009 09:33:35 +0000 Received: from [IPv6:2001:67c:64:42:226:bbff:fe0e:7cc7] ([IPv6:2001:67c:64:42:226:bbff:fe0e:7cc7]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n979XFLM051735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Oct 2009 11:33:16 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Subject: Re: [dnsext] Why ZSK rollover is a Bad Idea (tm) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-16--424595061; protocol="application/pkcs7-signature"; micalg=sha1 From: Olaf Kolkman In-Reply-To: Date: Wed, 7 Oct 2009 10:33:15 +0100 Cc: Eric Rescorla , dnsop@ietf.org, Paul Hoffman , Nicholas Weaver , "namedroppers@ops.ietf.org WG" Message-Id: <327852D7-C702-4E05-B954-25F66D8DFFE6@NLnetLabs.nl> References: <1C586E51-D77C-406C-9B89-47276A9B41B2@ICSI.Berkeley.EDU> To: Olaf Kolkman X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Wed, 07 Oct 2009 11:33:17 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --Apple-Mail-16--424595061 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed On Oct 7, 2009, at 9:23 AM, Olaf Kolkman wrote: > hope I can address a few of the issues before Yokohama. s/Yokohama/Hiroshima/ Should I call my travel office? ;-) --Olaf ________________________________________________________ Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam --Apple-Mail-16--424595061 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMTCCBS0w ggMVoAMCAQICAwbqdTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA1MjUwODQ4MTJaFw0x MTA1MjUwODQ4MTJaMDkxFTATBgNVBAMTDE9sYWYgS29sa21hbjEgMB4GCSqGSIb3DQEJARYRb2xh ZkBubG5ldGxhYnMubmwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxtZNngmuLgcf rto+Uax1WhonECqb5W8US2Z+ZPw/ASKsjKEF8Wa3Nnispys6Gj9Sl7C1X0/2pH//qauLpBqA+lHW L9mgdGW1T9KU1Fb8Odqw0PBnIIhbLNQzecZL+BchEetcrubplQWzDOpROCJ00IwXksusBiKqhew4 u7X2QoraW+z32Knj5ogajIhdkAeBHUy1pwXsk/mDnV8cIEdz1MhaZWDSn7kJUQtRMVCpFBjVoiXh ToXMJfiMvn0CKaeFxFm72dcdzvFsw906Ndafd2MOfdP7QSsTVP6sG9am790AOgkzxT5CM77IDPbD zxZlQ8jTdhcp/WtUrFWIU4QBAgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRw Oi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3 CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZo dHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW9sYWZAbmxuZXRsYWJzLm5sMA0GCSqG SIb3DQEBBQUAA4ICAQCLpawAoUQAxivf6blyMswVokRmDl2JGEbtmEu8j0h1BVOlGh6hlI8WaeWy 3x2jJ9uun3VK6oYnHy45ez+dUDjBLjOZdAgwFg225lm1OPdmisghDDVwCIiEogHPqmJtvKYMFoPF 3iFUambJDoQF8DeVeg8ctDvsxsaVGjA8OrMpo0K4I11vnNbCLv7mWCjnaZWt/6Y6TD8ErHQl5dmI rpsHmEZx1/nsocdPkZGRA4QVf1omYHUNs79DtxpYdGKHoorpBNzlzIIjpceiqeOeykoDeYLTZX2G c7Mh4Gdj2MHFqZucxV1cHibb8XKv8ebaGltMV5SrciqRn8yFXmiyTvmId6myNXLiOx+VJiGbLSS3 TltM/kf7UejXeEHulEKufU6Ya6EfH7W2/spTayYCauyLljOjE2Ey5A4oIoJV9eY64OCDuLF2nmGR jOh3JB9nGkZIPhmTUwGZnMELLhzKz+eOZoulM4tXH6KEubed1shQEq1dkJ+tFtRS3Lm+vLCKWvVo 1iZScqPaQf9riPApAVrL+3Wat0p/jtCk5gLBF02uTiWvT2t4ZfSHMEBXR7CvVm58etRQuyZSMHyz UQC4wkDvCeVawNRCZjq6wWdvx5hmr2JeDSkkRtSZ/Fa1WXf26b3BZugI75p5JXafbWdOTRpNc8M5 YMk7tx29ZG3u0qODgDGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMG6nUwCQYFKw4DAhoFAKCCAYcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkxMDA3MDkzMzE1WjAj BgkqhkiG9w0BCQQxFgQUHxc6XKW8ejwXSyhd8E3gP5BzYk0wgZEGCSsGAQQBgjcQBDGBgzCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDBup1MIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBB dXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBup1MA0GCSqGSIb3 DQEBAQUABIIBAJ5TVhKduONWrXBOs+z5Rgso595LMRkEjOFsNshdhZtGvEkcCs3PS5Y+SBIWjCGo 430SiBlCaGC+8ymP0oqa0VcdPA6vZeebiDb6Cmm5N33gsnsup/t21284iD9VsDCPBJUBOWVsFWrS FzXNHixeM3KQRi7FZRDQ+SgaEdhNPsFDr/zbVBT/bIj+MPB3mMKtFF2YmcV2+QeY/ejhakGqwZGW 3oJkDoenz7+TsC7+AS4LcQm8OlIrxPbzg25ypbP7c8JziNvUWbAcuMT5FbspyajyvC8GYf7c0S/v +00G/1AO67hASibmjyyMnrDEIbic8UezOEV1uiqsbiNIuO8DJZcAAAAAAAA= --Apple-Mail-16--424595061-- From owner-namedroppers@ops.ietf.org Wed Oct 7 05:35:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5CD3A6822; Wed, 7 Oct 2009 05:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.841 X-Spam-Level: **** X-Spam-Status: No, score=4.841 tagged_above=-999 required=5 tests=[AWL=-1.709, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxX3zCqb78dS; Wed, 7 Oct 2009 05:35:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 33CC73A67EA; Wed, 7 Oct 2009 05:35:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvVfb-000MPV-Jq for namedroppers-data0@psg.com; Wed, 07 Oct 2009 12:31:03 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvVfO-000MN4-LX for namedroppers@ops.ietf.org; Wed, 07 Oct 2009 12:31:01 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA190858605; Wed, 7 Oct 2009 14:30:05 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA08233; Wed, 7 Oct 2009 14:29:56 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910071229.OAA08233@TR-Sys.de> Subject: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 To: ray.bellis@nominet.org.uk Date: Wed, 7 Oct 2009 14:29:56 +0200 (MESZ) Cc: namedroppers@ops.ietf.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Ray, all, I have looked at draft-ietf-dnsext-dns-tcp-requirements-00 and have a few suggestions for improvement, and would like to contribute to the discussion of open topics. Following a linear walk-through of the draft: (1) Front matter -- nit I'd prefer to list the Updated RFCs in ascending RFC number order: Updates: 1123, 1035 (if approved) October 6, 2009 --- Updates: 1035, 1123 (if approved) October 6, 2009 (2) Section 1, 1st para -- discussion / improvement Most DNS [RFC1035] transactions take place over the UDP [RFC0792] protocol. The TCP [RFC0793] protocol is used for zone transfers and | is supported by some implementations for the transfer of other packets which exceed the protocol's original 512 byte packet-size limit. "some implementations" (in the 3rd line) seems to be too vague and pessimistic. According to recent reports, it looks like only a few implementations do not support TCP for DNS transport. So perhaps "many implementations" or even "most implementations" would be more appropriate -- keep in mind the sentence refers to *implementations*, not counts of installations of authoritative DNS servers with TCP _enabled_ by their adminitrators. (3) Section 3, 2nd para -- nit I suggest to balance the use of commas, by inserting another one: However, whilst RFC 1123 predates the current RFC 2119 terminology | document it uses exactly the same text: --- However, whilst RFC 1123 predates the current RFC 2119 terminology | document, it uses exactly the same text: ^ (4) Section 3, 8th para -- nit Once again, I suggest to place another comma, and also to add a pair of parentheses for clarity and readability: | Since the original core specifications for DNS were written the | Extension Mechanisms for DNS EDNS0 [RFC2671] have been introduced. [...] --- v | Since the original core specifications for DNS were written, the | Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced. [...] ^ ^ (5) Section 5 -- important DISCUSS Do you / we really want to update RFC 793 (TCP) and RFC 1122 as well, in a significant way? That's what the current text attempts without saying so. I fear a lot of guys in TCPM wouldn't appreciate that very much! The TCP connection state machine (RFC 793, pg. 23 ff.) specifies that the party first performing an active CLOSE for a TCP connection has eventually to transition through the TIME_WAIT state, awaiting a timeout of twice the Maximum Segment Lifetime (MSL) of the Internet. (For the sake of exactness: "first" more precisely means "before having itself received a FIN segment".) MSL is defined as 2 minutes, confirmed in RFC 1122. This is a very important feature for security purposes, and obeyance to that long timeout has become even more important after the introduction of wireless link technologies with their inherent risk of uncontrolled long packet delays, e.g. during a handover. Thus, the party performing the active CLOSE carries the burden to keep TCP connection state for 4 more minutes. Therefore, it does not significantly reduce the state load of a DNS server if it actively closes a TCP connection after a very short period (as recommended by the current text in the penultimate paragraph of Section 5), under normal operating conditions. It generally only makes sense for a TCP server to close connections idle for a period of time comparable to, or exceeding 2*MSL (4 min), in order to have a massive effect on the amount of connection state to be held. Notwithstanding that, emergency behavior (for periods of ongoing connection state DoS attacks) contrary to the TCP RFCs will perhaps be sanctioned even by some purists. However, I'd like to draw your attention to the new TCP User Timeout Option (UTO, RFC 5482) as a means to signal the idle timeout strategy intended by the communicating TCP endpoints. Such indication carried from the DNS client to the server could provide good hints for an advanced connection management scheme in a DNS server. Using the UTO, the server can be aware of the time the client wants to hold an idle connection open, and vice versa. For instance, if the server signals a short UTO and the client does not accept that, such client not closing the idle connection after that time span might become regarded by the server as 'hostile', and the connection becoming a high priority candidate of server-side CLOSE. It should be explored whether the use of TCP UTO should be recommended for new/updated DNS implementations. As an incentive for client-side support of TCP UTO, DNS servers could offer preferential treatment to connections with negotiated UTO, with regard to the server-side connection state cleanup strategy. Also, it might be worth giving a few hints on appropriate performance 'knobs': suppressing the Nagle algorithm, setting PSH in TCP segments, to accommodate the message oriented TCP payload (as opposed to the byte stream paradigm inherent in TCP), thus expediting sending and receive processing, respectively, based on DNS packet boundaries. (6) Section 6 a) You are asking for the specs. Here are two snippets: RFC 1035, Section 4.1.1 (page 26): | ID A 16 bit identifier assigned by the program that | generates any kind of query. This identifier is copied | the corresponding reply and can be used by the requester ^^^^^^^^^^^^^^^^^^^^^ | to match up replies to outstanding queries. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ RFC 1035, Section 4.2.1 (page 32): | [...]. Queries or their responses may be reordered | by the network, or by processing in name servers, so resolvers should | not depend on them being returned in order. This appears in the section on UDP transport, but this sentence is clearly not dedicated to UDP (which is explicitely mentioned in all sentences above and afterwards there specific to UDP) and it indeed _is_ applicable to any transport. b) Most DNS clients already support parallel queries over UDP. The responses can arrive in any order in this case as well (see above). So why should "streamed" (pseudo-parallel) queries over a TCP connection pose any problem, if the client follows the specs for correlating responses to open queries in STD 13, STD 3, RFC 2181, and (last but not least) RFC 5452 ? Thus, any resolver supporting parallel queries to the same server over UDP should not have any problems to perform query "streaming" over a TCP connection as well. I consider the ability to correlate responses to open queries a MUST for resolvers, independent of transport. The DNS server code also should not have trouble in any case; if it does not support parallel query processing, it simply will not read again from the TCP (or UDP) socket before having sent the answer to the last query read. If the server does support parallel query processing, it will do that in independent execution streams, and any obligation to sequence responses would make the processing unnecessarily complicated; I do not expect that any server implementation does perform such ordering of responses, parallel to the order of queries received. Note: The axfr-clarify draft closes an underspecification in STD 13, requesting the standard use of the ID field for the multi-packet AXFR responses as well, and thus even assures the ability (if desired by the DNS client) to perform standard DNS queries interleaved with an ongoing AXFR transaction. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From owner-namedroppers@ops.ietf.org Wed Oct 7 05:46:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D39C3A6808; Wed, 7 Oct 2009 05:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.713 X-Spam-Level: *** X-Spam-Status: No, score=3.713 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzaW5EIC9HSY; Wed, 7 Oct 2009 05:46:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 99AFD3A6807; Wed, 7 Oct 2009 05:46:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvVsZ-000NgQ-M7 for namedroppers-data0@psg.com; Wed, 07 Oct 2009 12:44:27 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvVsO-000NeH-Mw for namedroppers@ops.ietf.org; Wed, 07 Oct 2009 12:44:24 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA190919410; Wed, 7 Oct 2009 14:43:30 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA08255; Wed, 7 Oct 2009 14:43:29 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910071243.OAA08255@TR-Sys.de> Subject: Re: [dnsext] Why ZSK rollover is a Bad Idea To: namedroppers@ops.ietf.org Date: Wed, 7 Oct 2009 14:43:29 +0200 (MESZ) Cc: dnsop@ietf.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I already have posted a response to the original analysis by EKR, which has much overlap with the comments sent to this list by Olaf. Please see the original URL for the thread there, including my reasoning about operational impact and human factors: http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html [[ Now switching to DNSOP as well. ]] Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From owner-namedroppers@ops.ietf.org Wed Oct 7 06:20:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AAB63A6939; Wed, 7 Oct 2009 06:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.793 X-Spam-Level: X-Spam-Status: No, score=0.793 tagged_above=-999 required=5 tests=[AWL=-1.126, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGzvqcWcUgwQ; Wed, 7 Oct 2009 06:20:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AFBE33A68EA; Wed, 7 Oct 2009 06:20:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvWP3-0001IH-UV for namedroppers-data0@psg.com; Wed, 07 Oct 2009 13:18:01 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvWOq-0001H7-Tz for namedroppers@ops.ietf.org; Wed, 07 Oct 2009 13:17:56 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 498B9C2DA5; Wed, 7 Oct 2009 14:17:46 +0100 (BST) Date: Wed, 07 Oct 2009 14:17:23 +0100 From: Alex Bligh Reply-To: Alex Bligh To: "Alfred H?nes" , ray.bellis@nominet.org.uk cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 Message-ID: <3E74A46F4EF7CD4636979B0D@Ximines.local> In-Reply-To: <200910071229.OAA08233@TR-Sys.de> References: <200910071229.OAA08233@TR-Sys.de> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 7 October 2009 14:29:56 +0200 "Alfred H?nes" wrote: > (5) Section 5 -- important DISCUSS > > Do you / we really want to update RFC 793 (TCP) and RFC 1122 as well, > in a significant way? > That's what the current text attempts without saying so. > I fear a lot of guys in TCPM wouldn't appreciate that very much! > > The TCP connection state machine (RFC 793, pg. 23 ff.) specifies > that the party first performing an active CLOSE for a TCP > connection has eventually to transition through the TIME_WAIT > state, awaiting a timeout of twice the Maximum Segment Lifetime > (MSL) of the Internet. (For the sake of exactness: "first" more > precisely means "before having itself received a FIN segment".) > MSL is defined as 2 minutes, confirmed in RFC 1122. I think there is some talking at cross purposes here. RFC793 specifies that TIME_WAIT at 2xMSL occurs *after* the connection close has begun (i.e. once at least one packet with FIN set has been transmitted). RFC1025 says: > - If the server needs to close a dormant connection to reclaim > resources, it should wait until the connection has been idle > for a period on the order of two minutes. In particular, the > server should allow the SOA and AXFR request sequence (which > begins a refresh operation) to be made on a single connection. > Since the server would be unable to answer queries anyway, a > unilateral close or reset may be used instead of a graceful > close. This is talking about waiting 2 minutes *before* the initiation of the close, i.e. before sending the first packet with a FIN bit. So there are (at least) 2 delays, the RFC1025 2 minute delay, then the RFC793 2xMSL delay. If I have understood this right, Roy's draft proposes removing the first of these, but not the second, so doesn't affect RFC793/1122. Or have I read this wrong? I /think/ this is orthogonal to UTO (at least in the absence of keepalives). -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Oct 7 07:24:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15AA23A691C; Wed, 7 Oct 2009 07:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.472 X-Spam-Level: **** X-Spam-Status: No, score=4.472 tagged_above=-999 required=5 tests=[AWL=-1.267, BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dH+oCh95ftC; Wed, 7 Oct 2009 07:24:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF2B63A659C; Wed, 7 Oct 2009 07:24:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvXN1-00080R-5a for namedroppers-data0@psg.com; Wed, 07 Oct 2009 14:19:59 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvXMq-0007zQ-15 for namedroppers@ops.ietf.org; Wed, 07 Oct 2009 14:19:56 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA191405144; Wed, 7 Oct 2009 16:19:04 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA08336; Wed, 7 Oct 2009 16:19:03 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910071419.QAA08336@TR-Sys.de> Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 To: alex@alex.org.uk Date: Wed, 7 Oct 2009 16:19:02 +0200 (MESZ) Cc: namedroppers@ops.ietf.org In-Reply-To: <3E74A46F4EF7CD4636979B0D@Ximines.local> from Alex Bligh at Oct "7," 2009 "02:17:23" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Thanks Alex for your response. >> (5) Section 5 -- important DISCUSS >> >> Do you / we really want to update RFC 793 (TCP) and RFC 1122 as well, >> in a significant way? >> That's what the current text attempts without saying so. >> I fear a lot of guys in TCPM wouldn't appreciate that very much! >> >> The TCP connection state machine (RFC 793, pg. 23 ff.) specifies >> that the party first performing an active CLOSE for a TCP >> connection has eventually to transition through the TIME-WAIT >> state, awaiting a timeout of twice the Maximum Segment Lifetime >> (MSL) of the Internet. (For the sake of exactness: "first" more >> precisely means "before having itself received a FIN segment".) >> MSL is defined as 2 minutes, confirmed in RFC 1122. > > I think there is some talking at cross purposes here. > > RFC793 specifies that TIME-WAIT at 2xMSL occurs *after* the connection > close has begun (i.e. once at least one packet with FIN set has > been transmitted). More precisely: Once the first FIN has been sent, it has been ACKed by the peer, and the peer's FIN has also been received (and ACKed). FYI: These secondary events can occur in different order; the ACK for the first FIN can arrive before or after the peer's FIN, and it can be piggy-backed to it in the same TCP segment; the intermediate TCP states needed to account for that are FIN-WAIT-1 and FIN-WAIT-2, and CLOSING, respectively. > RFC1025 says: Did you mean RFC 1035 ? :-) >> - If the server needs to close a dormant connection to reclaim >> resources, it should wait until the connection has been idle >> for a period on the order of two minutes. In particular, the >> server should allow the SOA and AXFR request sequence (which >> begins a refresh operation) to be made on a single connection. >> Since the server would be unable to answer queries anyway, a >> unilateral close or reset may be used instead of a graceful >> close. > > This is talking about waiting 2 minutes *before* the initiation of > the close, i.e. before sending the first packet with a FIN bit. > So there are (at least) 2 delays, the RFC1025 2 minute delay, (again, 1035, isn't it?) > then the RFC793 2xMSL delay. If I have understood this right, Yep! > Roy's draft proposes removing the first of these, but not the > second, so doesn't affect RFC793/1122. Or have I read this wrong? This way, you only are able to reduce the connection-related resource consumption by roughly 33% (6 min --> 4 min 4 sec; maybe a bit more, if the stack is able to free partial resources for connections in TIME-WAIT state). That alone is not worth the change, IMHO. The 2 minutes User Timeout are of the same order of magnitude as 2*MSL -- a balanced design, as you can see. BTW: Network problems causing retries for the FIN/ACK handshake, an irresponsive client, or a purposely misbehaving client can add to the waiting period, by causing the server to be stalled in the abovementioned intermediate states for another full User Timeout each. (Similar delays can happen at the server for client-initiated CLOSE, in the intermediate states CLOSE-WAIT and LAST-ACK.) The draft quotes tuned HTTP servers as examples (3rd-to-last para in Section 5), and reportedly, highly specialized HTTP servers also aggressively reduce the effective MSL value assumed in order to obtain a significant benefit from quickly closing conections considered idle. This behavior is highly controversial, but this kind of 'TCP tuning' is nevertheless supported by major OS vendors and documented in their Performance Tuning Guides. >From the reference to the HTTP server example I concluded that the spirit of the draft was to sublimely also propose to adopt that behavior for DNS servers, and my introducing question aimed at challenging that assumption. The background material should help the reader to better understand the context, and I see it did so (for you). :-) > I /think/ this is orthogonal to UTO (at least in the absence of > keepalives). It *is* orthogonal, but as sketched, I envision that the use of TCP UTO might allow to implement better resource management strategies for high-load DNS servers -- better both for the server and its non-hostile DNS clients -- without a stringent need to change the User Timeout recommendation of 2min from RFC 1034. That certainly will need much discussion to be worked out in detail. Since the draft is not entitled "TCP Transport for DNS Mandatory" but "DNS Transport over TCP", a discussion of UTO (and/or other relevant topics -- I already have mentioned Nagle suppression / PSH -- should be within scope of the draft. > > -- > Alex Bligh Kind regards, Alfred. From owner-namedroppers@ops.ietf.org Wed Oct 7 08:02:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ADE13A6AC3; Wed, 7 Oct 2009 08:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=-0.547, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4IHXR280mxX; Wed, 7 Oct 2009 08:02:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 590F13A6AC1; Wed, 7 Oct 2009 08:02:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvXzT-000EcR-Bx for namedroppers-data0@psg.com; Wed, 07 Oct 2009 14:59:43 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvXzK-000EaO-4h for namedroppers@ops.ietf.org; Wed, 07 Oct 2009 14:59:41 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n97ExVoK041341; Wed, 7 Oct 2009 10:59:31 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200910071459.n97ExVoK041341@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 07 Oct 2009 10:59:13 -0400 To: Matthew Dempsky , namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-00.txt In-Reply-To: References: <20091006181501.EF9443A67F4@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 15:12 06/10/2009, Matthew Dempsky wrote: >Second, regarding the relaxation of requiring UDP before TCP: I'm not >opposed to this, but I think it should be again mentioned that some >servers may not support TCP (as permitted earlier in the section) and >it's the client's responsibility to ensure this doesn't cause >problems. > >Rationale: The current RFCs (and even this draft) allow some servers >to not support TCP and currently clients are required to try UDP >before TCP; it's the responsibility of new clients that have differing >behavior to be compatible with existing servers. Matthew, In my mind there are two cases to consider, "First" query to a server in this case yes UDP is required before TCP Is "Subsequent" query different ? For example every time someone asks for a non existent .gov name the answer is 1700+ bytes. Can a resolver that has detected lots of TC's from a server for .gov to just ask all future queries over TCP ? (This is a resolver behind a pipe that restricts answers to 1500 bytes). >Otherwise, I like the draft right now. Glad to hear it. Ray generated this 00 draft in about 24 hours. Olafur From owner-namedroppers@ops.ietf.org Wed Oct 7 08:10:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3E223A6848; Wed, 7 Oct 2009 08:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.539 X-Spam-Level: X-Spam-Status: No, score=0.539 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4GkoxCoEeyn; Wed, 7 Oct 2009 08:10:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 177163A69D3; Wed, 7 Oct 2009 08:10:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvY8W-000G74-KO for namedroppers-data0@psg.com; Wed, 07 Oct 2009 15:09:04 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvY8E-000G59-Je for namedroppers@ops.ietf.org; Wed, 07 Oct 2009 15:09:02 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id B2614C2DA5; Wed, 7 Oct 2009 16:08:44 +0100 (BST) Date: Wed, 07 Oct 2009 16:08:21 +0100 From: Alex Bligh Reply-To: Alex Bligh To: "Alfred H?nes" cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 Message-ID: <53725F265BFE44DBC8506D59@Ximines.local> In-Reply-To: <200910071419.QAA08336@TR-Sys.de> References: <200910071419.QAA08336@TR-Sys.de> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 7 October 2009 16:19:02 +0200 "Alfred H?nes" wrote: >> Roy's draft proposes removing the first of these, but not the >> second, so doesn't affect RFC793/1122. Or have I read this wrong? > > This way, you only are able to reduce the connection-related resource > consumption by roughly 33% (6 min --> 4 min 4 sec; maybe a bit more, > if the stack is able to free partial resources for connections in > TIME-WAIT state). Note that it is quite possible starting the close is sufficient to free a pile of resources (e.g. SNDBUF/RCVBUF, which I /think/ you no longer need after going into FINWAIT1/FINWAIT2, i.e. for that 2xMSL period), though my TCP stack knowledge is no doubt far rustier than yours. Subject to that, I agree, absent of any changes to TCP usage, but ... > That alone is not worth the change, IMHO. ... the changes to TCP that would need to go with it are themselves outside the remit of this w/g, so I think we are limited to a reference to other RFCs (e.g. UTO) that might help. I see no harm in removing the requirement to wait 2 minutes before starting to close the connection, and (perhaps) pointing out that further freeing up resources is going to require something else to be done to the TCP stack. > The draft quotes tuned HTTP servers as examples (3rd-to-last para > in Section 5), and reportedly, highly specialized HTTP servers also > aggressively reduce the effective MSL value assumed in order to > obtain a significant benefit from quickly closing conections > considered idle. This behavior is highly controversial, but this > kind of 'TCP tuning' is nevertheless supported by major OS vendors > and documented in their Performance Tuning Guides. > > From the reference to the HTTP server example I concluded that > the spirit of the draft was to sublimely also propose to adopt > that behavior for DNS servers, and my introducing question aimed > at challenging that assumption. > > The background material should help the reader to better understand > the context, and I see it did so (for you). :-) Yes (& thanks :-). I think the draft should at least be clarified as to what its intent is here. If your point was that the draft should not tacitly endorse behaviour that is outside the specific behaviour described (i.e. removing the 2 minute timeout), I agree; it should either be explicit (and considered here), or not be in there. >> I /think/ this is orthogonal to UTO (at least in the absence of >> keepalives). > > It *is* orthogonal, but as sketched, I envision that the use of > TCP UTO might allow to implement better resource management > strategies for high-load DNS servers -- better both for the server > and its non-hostile DNS clients -- without a stringent need to > change the User Timeout recommendation of 2min from RFC 1034. > That certainly will need much discussion to be worked out in detail. > > Since the draft is not entitled "TCP Transport for DNS Mandatory" > but "DNS Transport over TCP", a discussion of UTO (and/or other > relevant topics -- I already have mentioned Nagle suppression / PSH -- > should be within scope of the draft. Yes to your second para above; I agree that considerations (like UTO) that change TCP parameters / how TCP are used are in scope. But in relation to your first para, even if UTO was recommended and used, if the 1034 requirement for not initiating a close until 2 minutes of idle session has elapsed, then I don't think you gain much do you? -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Oct 7 08:10:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FBF83A695A; Wed, 7 Oct 2009 08:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.958 X-Spam-Level: X-Spam-Status: No, score=-3.958 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sz5-Mh2bE20h; Wed, 7 Oct 2009 08:10:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 040DD3A6848; Wed, 7 Oct 2009 08:10:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvY5N-000Fj4-Sa for namedroppers-data0@psg.com; Wed, 07 Oct 2009 15:05:49 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvY4S-000FZS-FW for namedroppers@ops.ietf.org; Wed, 07 Oct 2009 15:05:29 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=MwTbtpQDHEjghQxfrGvp3IGkgycWLtjfH9LWp4+Ld71/OCLRez6L5p9a ZdfFwNa6DWMtoFlQjwaGnn/6SaATc14ga/81yZtLJOQiQtNE5q1xSdybl XnEe5Bc1zei6cN0; 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=1254927892; x=1286463892; 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.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20draft-ietf-dnsext-dns-tcp-requirements-00|Date:=20W ed,=207=20Oct=202009=2016:04:50=20+0100|Message-ID:=20|To:=20Alfred=20=3D?ISO-8859-1?Q?H=3DF6nes? =3D=20|Cc:=20alex@alex.org.uk,=0D=0A=09name droppers@ops.ietf.org|MIME-Version:=201.0|In-Reply-To:=20 <200910071419.QAA08336@TR-Sys.de>|References:=20<3E74A46F 4EF7CD4636979B0D@Ximines.local>=20from=20Alex=20Bligh=20a t=20Oct=20"7,"=202009=20"02:17:23"=20pm=0D=0A=20<20091007 1419.QAA08336@TR-Sys.de>; bh=QXAGlsyp8AGB4bE86rWi9SHzQDkV7paTo7myD+LhX1k=; b=YFJMGxAKu42GasbFsraDhcpvT7kfXHu8mfnpicc9z9TEw7q4JvmjpE3G LiNIgwEjCWf3RhbOaZzKZGTY33sb8VxuVv9vfLeV9kMTfYJbJyS4Tevoc aFbxZA/dz6e6w//; X-IronPort-AV: E=Sophos;i="4.44,519,1249254000"; d="scan'208";a="13488692" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 07 Oct 2009 16:04:51 +0100 In-Reply-To: <200910071419.QAA08336@TR-Sys.de> References: <3E74A46F4EF7CD4636979B0D@Ximines.local> from Alex Bligh at Oct "7," 2009 "02:17:23" pm <200910071419.QAA08336@TR-Sys.de> To: Alfred =?ISO-8859-1?Q?H=F6nes?= Cc: alex@alex.org.uk, namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 7 Oct 2009 16:04:50 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 07/10/2009 04:04:51 PM, Serialize complete at 07/10/2009 04:04:51 PM Content-Type: multipart/alternative; boundary="=_alternative 0052D73F80257648_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 0052D73F80257648_= Content-Type: text/plain; charset="US-ASCII" > From the reference to the HTTP server example I concluded that > the spirit of the draft was to sublimely also propose to adopt > that behavior for DNS servers, and my introducing question aimed > at challenging that assumption. If only I were that clever. No, the point of the example was to show that _application level_ two minute timeouts are very excessive. TBH I had forgotten about the TCP MSL limits, although I shall now read up on how the high performance web servers are tweaking MSL to achieve this sort of throughput :) cheers, Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 0052D73F80257648_= Content-Type: text/html; charset="US-ASCII"
> From the reference to the HTTP server example I concluded that
> the spirit of the draft was to sublimely also propose to adopt
> that behavior for DNS servers, and my introducing question aimed
> at challenging that assumption.
If only I were that clever.

No, the point of the example was to show that _application level_ two minute timeouts are very excessive.

TBH I had forgotten about the TCP MSL limits, although I shall now read up on how the high performance web servers are tweaking MSL to achieve this sort of throughput :)

cheers,

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211
 --=_alternative 0052D73F80257648_=-- From ontrose@aa4df.com Wed Oct 7 09:42:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06C33A689B for ; Wed, 7 Oct 2009 09:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdVcVin8lNwF for ; Wed, 7 Oct 2009 09:42:28 -0700 (PDT) Received: from 200-206-167-104.dsl.telesp.net.br (200-206-167-104.dsl.telesp.net.br [200.206.167.104]) by core3.amsl.com (Postfix) with SMTP id D49D43A6966 for ; Wed, 7 Oct 2009 09:42:25 -0700 (PDT) To: Subject: Invoice from itunes.com From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 090531-0, 31/05/2009), Outbound message X-Antivirus-Status: Clean Message-Id: <20091007164226.D49D43A6966@core3.amsl.com> Date: Wed, 7 Oct 2009 09:42:25 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.streetappear.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://streetappear.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 7, B141. 806 Clements Road. London. SE89 0DG

© 2009 AMAZON, Ltd. All Rights Reserved

From owner-namedroppers@ops.ietf.org Thu Oct 8 18:43:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90AE3A68D8; Thu, 8 Oct 2009 18:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxac8kd4D21b; Thu, 8 Oct 2009 18:43:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 55A8B3A6818; Thu, 8 Oct 2009 18:43:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mw4Ph-000JWH-A6 for namedroppers-data0@psg.com; Fri, 09 Oct 2009 01:36:57 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mw4PL-000JRk-OA for namedroppers@ops.ietf.org; Fri, 09 Oct 2009 01:36:43 +0000 Received: from sjc-office-nat-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 409DCA9443B; Fri, 9 Oct 2009 01:36:35 +0000 (UTC) Message-ID: <4ACE93A1.80304@mail-abuse.org> Date: Thu, 08 Oct 2009 18:36:33 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= CC: ray.bellis@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 References: <200910071229.OAA08233@TR-Sys.de> In-Reply-To: <200910071229.OAA08233@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 10/7/09 5:29 AM, Alfred � wrote: > Ray, all, > > I have looked at draft-ietf-dnsext-dns-tcp-requirements-00 > and have a few suggestions for improvement, and would like to > contribute to the discussion of open topics. > > Following a linear walk-through of the draft: > > > (1) Front matter -- nit > > I'd prefer to list the Updated RFCs in ascending RFC number order: > > Updates: 1123, 1035 (if approved) October 6, 2009 > --- > Updates: 1035, 1123 (if approved) October 6, 2009 > > > (2) Section 1, 1st para -- discussion / improvement > > Most DNS [RFC1035] transactions take place over the UDP [RFC0792] > protocol. The TCP [RFC0793] protocol is used for zone transfers and > | is supported by some implementations for the transfer of other > packets which exceed the protocol's original 512 byte packet-size > limit. > > "some implementations" (in the 3rd line) seems to be too vague > and pessimistic. According to recent reports, it looks like only > a few implementations do not support TCP for DNS transport. > > So perhaps "many implementations" or even "most implementations" > would be more appropriate -- keep in mind the sentence refers to > *implementations*, not counts of installations of authoritative > DNS servers with TCP _enabled_ by their administrators. Perhaps the important perspective to keep would be the number of implementations that actively employ the TCP protocol for query traffic. Being able to enable TCP does not mean an implementation is robust enough to support TCP without having it interfere with the UDP service. Perhaps it would be better to exchange the word "supported" with "employed" instead. > (3) Section 3, 2nd para -- nit > > I suggest to balance the use of commas, by inserting another one: > > However, whilst RFC 1123 predates the current RFC 2119 terminology > | document it uses exactly the same text: > --- > However, whilst RFC 1123 predates the current RFC 2119 terminology > | document, it uses exactly the same text: > ^ > > (4) Section 3, 8th para -- nit > > Once again, I suggest to place another comma, and also to add > a pair of parentheses for clarity and readability: > > | Since the original core specifications for DNS were written the > | Extension Mechanisms for DNS EDNS0 [RFC2671] have been introduced. > [...] > --- v > | Since the original core specifications for DNS were written, the > | Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced. > [...] ^ ^ > > > (5) Section 5 -- important DISCUSS > > Do you / we really want to update RFC 793 (TCP) and RFC 1122 as well, > in a significant way? > That's what the current text attempts without saying so. > I fear a lot of guys in TCPM wouldn't appreciate that very much! Agreed. > The TCP connection state machine (RFC 793, pg. 23 ff.) specifies > that the party first performing an active CLOSE for a TCP > connection has eventually to transition through the TIME_WAIT > state, awaiting a timeout of twice the Maximum Segment Lifetime > (MSL) of the Internet. (For the sake of exactness: "first" more > precisely means "before having itself received a FIN segment".) > MSL is defined as 2 minutes, confirmed in RFC 1122. > > This is a very important feature for security purposes, and obeyance > to that long timeout has become even more important after the > introduction of wireless link technologies with their inherent > risk of uncontrolled long packet delays, e.g. during a handover. > > Thus, the party performing the active CLOSE carries the burden to > keep TCP connection state for 4 more minutes. > > Therefore, it does not significantly reduce the state load of a > DNS server if it actively closes a TCP connection after a very > short period (as recommended by the current text in the penultimate > paragraph of Section 5), under normal operating conditions. > It generally only makes sense for a TCP server to close connections > idle for a period of time comparable to, or exceeding 2*MSL (4 min), > in order to have a massive effect on the amount of connection state > to be held. > Notwithstanding that, emergency behavior (for periods of ongoing > connection state DoS attacks) contrary to the TCP RFCs will perhaps > be sanctioned even by some purists. So to reduce TCP security, one only needs to cause excessive loads on the server? Perhaps the easiest way to bring down DNS over TCP would be to request large answers and never acknowledge their receipt. In-flight buffers would thereby increase the amount of per connection data expected of the server. Dumping buffers during excessive loads would likely aggravate the problem to further reduce the service stability. > However, I'd like to draw your attention to the new TCP User Timeout > Option (UTO, RFC 5482) as a means to signal the idle timeout strategy > intended by the communicating TCP endpoints. Such indication carried > from the DNS client to the server could provide good hints for an > advanced connection management scheme in a DNS server. > Using the UTO, the server can be aware of the time the client wants > to hold an idle connection open, and vice versa. For instance, > if the server signals a short UTO and the client does not accept > that, such client not closing the idle connection after that time > span might become regarded by the server as 'hostile', and the > connection becoming a high priority candidate of server-side CLOSE. This option runs somewhat afoul of the use of SYN cookies (RFC4987). This is described in section 3 where UTO information is not recorded, and the connection needs to repeat the option once a connection is established. How many implementations provide this ability? > It should be explored whether the use of TCP UTO should be > recommended for new/updated DNS implementations. It would seem RFC4987 would represent a more important recommendation. Holding in-flight data, even for shorter periods, still leaves the server exposed, even with abbreviated timeouts. > As an incentive for client-side support of TCP UTO, DNS servers could > offer preferential treatment to connections with negotiated UTO, > with regard to the server-side connection state cleanup strategy. > > Also, it might be worth giving a few hints on appropriate performance > 'knobs': suppressing the Nagle algorithm, setting PSH in TCP segments, > to accommodate the message oriented TCP payload (as opposed to the > byte stream paradigm inherent in TCP), thus expediting sending and > receive processing, respectively, based on DNS packet boundaries. Don't expect message packets will remain aligned with packets even when using the PSH technique. Perhaps one of the questions that should be answered would be how should DNS servers handle unacknowledged TCP data? Packet alignment does not help in answering this problem, as it would be a mistake to assume a packet offers a message boundary. > (6) Section 6 > > a) > You are asking for the specs. Here are two snippets: > > RFC 1035, Section 4.1.1 (page 26): > > | ID A 16 bit identifier assigned by the program that > | generates any kind of query. This identifier is copied > | the corresponding reply and can be used by the requester > ^^^^^^^^^^^^^^^^^^^^^ > | to match up replies to outstanding queries. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > RFC 1035, Section 4.2.1 (page 32): > > | [...]. Queries or their responses may be reordered > | by the network, or by processing in name servers, so resolvers should > | not depend on them being returned in order. > > This appears in the section on UDP transport, but this sentence is > clearly not dedicated to UDP (which is explicitely mentioned in all > sentences above and afterwards there specific to UDP) and it > indeed _is_ applicable to any transport. > > b) > Most DNS clients already support parallel queries over UDP. > The responses can arrive in any order in this case as well > (see above). > > So why should "streamed" (pseudo-parallel) queries over a TCP > connection pose any problem, if the client follows the specs > for correlating responses to open queries in STD 13, STD 3, > RFC 2181, and (last but not least) RFC 5452 ? Perhaps an implementation might depend upon port-tuples to multiplex conversations. This could be easily done with UDP, but less so for persistent TCP connections returning unordered responses. Dealing with unordered responses should be a requirement however. -Doug From owner-namedroppers@ops.ietf.org Mon Oct 12 16:20:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C896028B797; Mon, 12 Oct 2009 16:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.851 X-Spam-Level: *** X-Spam-Status: No, score=3.851 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyBmiWorgVWu; Mon, 12 Oct 2009 16:20:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E45C03A677E; Mon, 12 Oct 2009 16:20:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxU43-000Ge8-J3 for namedroppers-data0@psg.com; Mon, 12 Oct 2009 23:12:27 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxU3q-000GdI-DM for namedroppers@ops.ietf.org; Mon, 12 Oct 2009 23:12:22 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA220899080; Tue, 13 Oct 2009 01:11:20 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA21677; Tue, 13 Oct 2009 01:11:19 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910122311.BAA21677@TR-Sys.de> Subject: [dnsext] Re: draft-iab-idn-encoding-00 To: namedroppers@ops.ietf.org, dnsop@ietf.org Date: Tue, 13 Oct 2009 01:11:19 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [[ Sorry for cross-posting. ]] All, in July the IAB has posted an I-D on "IAB Thoughts on Encodings for Internationalized Domain Names", draft-iab-idn-encoding-00, and solicited feedback. That draft is closely related to the DNS related WGs as well. After very quickly skimming over that memo, it looks like the description of DNS labels and the resulting restrictions is incomplete in several respect, for instance: - No distinction is made between the 'normal' labels from STD 13 and other label types (currently there aren't other label types supported by active standards, but the future might change that). - No mention is made of case-insensitive treatment of DNS labels of standard type in resolvers and authorities. - No mention is made of the 0x20 hack, the deployment of which (be it standardized or not) will prohibit future deviation from the ASCII-only case-insensitive label regime we have, e.g. when potentially allowing full UTF-8 or UTF-16. - The impact of potential normalization needs (as an extension of case-insensitive comparison of ASCII labels to Unicode) of authoritative server and recursive resolver behavior is not discussed. I got the impression that the DNS related text in this IAB draft might deserve detailed review from DNS experts -- both on dnsop and namedroppers, but I have not found any discussion on that memo. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From owner-namedroppers@ops.ietf.org Mon Oct 12 16:20:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD043A6978; Mon, 12 Oct 2009 16:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.337 X-Spam-Level: * X-Spam-Status: No, score=1.337 tagged_above=-999 required=5 tests=[AWL=-1.222, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmHhOZYHARYc; Mon, 12 Oct 2009 16:20:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 323B43A677E; Mon, 12 Oct 2009 16:20:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxU7f-000Gv6-Hm for namedroppers-data0@psg.com; Mon, 12 Oct 2009 23:16:11 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxU7V-000GuN-9g for namedroppers@ops.ietf.org; Mon, 12 Oct 2009 23:16:09 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1E9262FE8CE3; Mon, 12 Oct 2009 23:16:00 +0000 (UTC) Date: Mon, 12 Oct 2009 19:15:52 -0400 From: Andrew Sullivan To: Alfred =?utf-8?B?SMO2bmVz?= Cc: namedroppers@ops.ietf.org, dnsop@ietf.org Subject: [dnsext] Re: [DNSOP] draft-iab-idn-encoding-00 Message-ID: <20091012231552.GI92861@shinkuro.com> References: <200910122311.BAA21677@TR-Sys.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200910122311.BAA21677@TR-Sys.de> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Oct 13, 2009 at 01:11:19AM +0200, Alfred Hönes wrote: > for Internationalized Domain Names", draft-iab-idn-encoding-00, > I got the impression that the DNS related text in this IAB draft > might deserve detailed review from DNS experts -- both on dnsop > and namedroppers, but I have not found any discussion on that memo. It certainly can use review. I am informed by someone who ought to know that -01 is near to release, so if you haven't looked at -00 and want to comment (and I urge you to do so), I counsel waiting until -01 is out. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Oct 14 08:33:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751343A6892; Wed, 14 Oct 2009 08:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKm6ZWTqBtzN; Wed, 14 Oct 2009 08:33:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8200A28C158; Wed, 14 Oct 2009 08:33:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1My5jR-000Cif-LQ for namedroppers-data0@psg.com; Wed, 14 Oct 2009 15:25:41 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1My5jH-000Chu-Fd for namedroppers@ops.ietf.org; Wed, 14 Oct 2009 15:25:39 +0000 Received: from [IPv6:2001:610:719:1:221:5dff:fe1e:113a] (unknown [IPv6:2001:610:719:1:221:5dff:fe1e:113a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 666DCE6056; Wed, 14 Oct 2009 15:25:29 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00.txt - WG item From: Shane Kerr To: George Barwood Cc: namedroppers@ops.ietf.org In-Reply-To: <0BB1C903022546B381AA1ACAD3B19A47@localhost> References: <835E5B3A3A314D0E9E47CB3C4F9BC412@localhost> <0BB1C903022546B381AA1ACAD3B19A47@localhost> Content-Type: text/plain Organization: ISC Date: Wed, 14 Oct 2009 17:25:21 +0200 Message-Id: <1255533922.24744.1748.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Sat, 2009-10-03 at 21:02 +0100, George Barwood wrote: > I have updated the draft to try to reflect the comments made. > > http://www.ietf.org/id/draft-barwood-dnsext-dns-transport-signal-01.txt > > I have not changed the resource record name (TPORT), because I think the > current name is best, and any allusion to ports is not damaging - transport > and port are closely related concepts in any case. Okay, this mystifies me and for the record I think it is unnecessarily confusing, but it's your baby. :) > I have also not included any means by which name servers can dynamically > advertise the DNS transport protocols they support. While acknowleging that > static configuration mistakes can occur, I don't think that name servers attempting > to dynamically ascertain their own capability is wise. For example even if the > capability exists in the software, firewalls may not have been configured to > allow incoming requests, or there may be operational or policy reasons why a > transport is not to be used. IMO, the decision on which transports are to be used > should rest with the domain owner (zone administrator), not the server software. > There is the principle "Data belongs in the database". I have included a note in > the security section on this topic. Sorry if I missed the discussion, but why use a separate registry for TPORT protocol numbers? We already have a registry of such things: http://www.iana.org/assignments/protocol-numbers/ One less piece of information to maintain and track, I think. Also, maybe it should be mentioned that this changes DNS from explicitly requiring UDP (and probably TCP, although not everyone agrees) to a protocol that supports any arbitrary set of transports. Finally, maybe it should be mentioned that if a client wants to be sure than it can use DNSSEC to query for the TPORT record directly? It's an extra query, so probably not useful in all cases, but possibly worthwhile mentioning. -- Shane From mataras@abaddon4tk.de Wed Oct 14 09:16:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE4628C1E4 for ; Wed, 14 Oct 2009 09:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.222 X-Spam-Level: X-Spam-Status: No, score=-15.222 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLBXzjd6HUWU for ; Wed, 14 Oct 2009 09:16:35 -0700 (PDT) Received: from aegon-cnooc.com (unknown [125.162.201.60]) by core3.amsl.com (Postfix) with SMTP id AD7CF28C1D3 for ; Wed, 14 Oct 2009 09:16:30 -0700 (PDT) To: Subject: Great Finds From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20091014161632.AD7CF28C1D3@core3.amsl.com> Date: Wed, 14 Oct 2009 09:16:30 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.wingvalue.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://wingvalue.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 8, B493. 547 Clements Road. London. SE83 6DG

© 2009 AMAZON, Ltd. All Rights Reserved

From owner-namedroppers@ops.ietf.org Wed Oct 14 11:20:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336853A6767; Wed, 14 Oct 2009 11:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.276 X-Spam-Level: X-Spam-Status: No, score=-102.276 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRmNt17zV9HF; Wed, 14 Oct 2009 11:20:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B04A63A6A2E; Wed, 14 Oct 2009 11:20:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1My8Nk-0003va-C0 for namedroppers-data0@psg.com; Wed, 14 Oct 2009 18:15:28 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1My8NO-0003tc-Gk for namedroppers@ops.ietf.org; Wed, 14 Oct 2009 18:15:15 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id A5F2F3A6901; Wed, 14 Oct 2009 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-registry-fixes-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091014181501.A5F2F3A6901@core3.amsl.com> Date: Wed, 14 Oct 2009 11:15:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security (DNSSEC) DNSKEY IANA Registry Algorithm Status Addition Author(s) : S. Rose Filename : draft-ietf-dnsext-dnssec-registry-fixes-00.txt Pages : 6 Date : 2009-10-14 The DNS Security Extensions (DNSSEC) has an IANA registry to allocate cryptographic algorithm suites for use in generating digital signatures over DNS data. Newly introduced cryptographic algorithms to DNSSEC mean implementors need to know which algorithms need to be implmented, which are optional, and which are obsolete. This document adds a column to the IANA registry table for Domain Name System Security (DNSSEC) Algorithm Numbers to list their status for use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-fixes-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-registry-fixes-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-14111415.I-D@ietf.org> --NextPart-- From owner-namedroppers@ops.ietf.org Wed Oct 14 11:24:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573A03A694E; Wed, 14 Oct 2009 11:24:15 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1crERg6E9--I; Wed, 14 Oct 2009 11:24:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 875D93A68ED; Wed, 14 Oct 2009 11:24:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1My8Sv-0004NS-G9 for namedroppers-data0@psg.com; Wed, 14 Oct 2009 18:20:49 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1My8Sf-0004L8-6d for namedroppers@ops.ietf.org; Wed, 14 Oct 2009 18:20:42 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id CD1D6CB1CB for ; Wed, 14 Oct 2009 18:20:32 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-barwood-dnsext-dns-transport-signal-00.txt - WG item In-Reply-To: Your message of "Wed, 14 Oct 2009 18:30:57 +0100." References: <835E5B3A3A314D0E9E47CB3C4F9BC412@localhost> <0BB1C903022546B381AA1ACAD3B19A47@localhost> <1255533922.24744.1748.camel@shane-asus-laptop> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 14 Oct 2009 18:20:32 +0000 Message-ID: <94080.1255544432@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: "George Barwood" > Date: Wed, 14 Oct 2009 18:30:57 +0100 > > >> http://www.ietf.org/id/draft-barwood-dnsext-dns-transport-signal-01.txt > > confusing, but it's your baby. :) > Well I would like it to be the IETF's baby, ... -1. From owner-namedroppers@ops.ietf.org Wed Oct 14 11:49:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58D6928C1DD; Wed, 14 Oct 2009 11:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.632 X-Spam-Level: **** X-Spam-Status: No, score=4.632 tagged_above=-999 required=5 tests=[AWL=-1.107, BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61I7T+hWC2+N; Wed, 14 Oct 2009 11:49:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 572FC28C1A2; Wed, 14 Oct 2009 11:49:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1My8oO-0006On-H8 for namedroppers-data0@psg.com; Wed, 14 Oct 2009 18:43:00 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1My8oA-0006MS-BV for namedroppers@ops.ietf.org; Wed, 14 Oct 2009 18:42:57 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA232145707; Wed, 14 Oct 2009 20:41:47 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA25186; Wed, 14 Oct 2009 20:41:46 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910141841.UAA25186@TR-Sys.de> Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward To: tuexen@fh-muenster.de, namedroppers@ops.ietf.org Date: Wed, 14 Oct 2009 20:41:45 +0200 (MESZ) Cc: fernando@gont.com.ar In-Reply-To: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Dear all, > > sorry for answering late, but I was traveling... > Some comments in-line. > > After looking at > draft-ietf-dnsext-dns-tcp-requirements-00 > I think you want to use an unmodified TCP. So deployment > of the transport stack is not an issue. Am I right? > > More comments in-line. > > Best regards > Michael > > ...[snip]... Michael, Andrew, all, Focusing on draft-ietf-dnsext-dns-tcp-requirements-00, I would like to reinforce that I had never proposed to include discussion of 'other DNS transports' into that document. My suggestion was to elaborate on TCP properties for several reasons (see below), and for the WG to obtain support from transport protocol experts in pursuing its chartered work item to evaluate existing and consider new transports for DNS. I admit that the nearby publication of the above draft and George Barwoods DNS transport related drafts, as well as the rechartering of the WG may have lead to comments with a Subject not totally encompassing some ideas contained in the message that had been cross-fertilized by these (natively independent) events. So let's focus on TCP. I fully support the idea of the draft, as already indicated. And I fully support Michael in that we want to use "unmodified TCP". But TCP has a lot of Options, and perhaps all commercial and open-source TCP stack implementations have a lot of tuning knobs to adjust parameters, enable/disable options and mechanisms, etc. -- that's particularly interesting for DNS server/resolver operators. Furthermore, the TCP (socket) API contains features that allow programmatic access to particular features, mechanisms and options of TCP -- how to best make use thereof is highly interesting for implementers of DNS software. The main reason for having this draft is the perceived unwillingness of various parties to implement/support/allow TCP as it was intended, a mandatory transport for DNS in case UDP does not suffice, in particular for packet size / fragmentation reasons. We (or many of us) want to convince those parties posing obstacles to this use of TCP that their opposition is not justified, and that IMO cannot be done by a simple normative statement of "MUST" for TCP. No, we need to provide arguments and show ways to mitigate the raised concerns! Exploring the effects of TCP options and parameters and giving recommendations to implementers and operators of how to use TCP in the best possible manner seems the right way to achieve this goal. This should include concrete arguments for implementors and vendors of middleboxes that DNS over TCP is not evil. If we can agree on this strategy, the draft has a chance to be amended and turned into a valuable document that gives enough concrete guidance to both implementers and operators to actually overcome the observed reservedness against the TCP support for DNS transactions as specified in STD 13 and STD 3. Such exploration and elaboration should also better educate the WG on aspects of DNS transport, allowing it to perform -- in a second step then -- a more targeted evaluation of proposals for alternate DNS transport(s), and eventually make better informed decisions on how to proceed with new proposals to this end. N.B.: The priority of dealing with possible signalling of Transport (and/or other feature) support in DNS servers may very well be made dependent on the outcome of the first steps above. Can wee agree on this way forward? Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From owner-namedroppers@ops.ietf.org Wed Oct 14 11:49:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6B9728C1A2; Wed, 14 Oct 2009 11:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.047 X-Spam-Level: X-Spam-Status: No, score=-5.047 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uacbVPQNOgCa; Wed, 14 Oct 2009 11:49:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81FA328C1B4; Wed, 14 Oct 2009 11:49:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1My8oL-0006OS-7p for namedroppers-data0@psg.com; Wed, 14 Oct 2009 18:42:57 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1My8nz-0006LM-Jk for namedroppers@ops.ietf.org; Wed, 14 Oct 2009 18:42:51 +0000 Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n9EIgK15009009 for ; Wed, 14 Oct 2009 14:42:23 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Wed, 14 Oct 2009 14:42:21 -0400 From: "Rose, Scott W." To: "namedroppers@ops.ietf.org" Date: Wed, 14 Oct 2009 14:42:20 -0400 Subject: [dnsext] FW: New Version Notification for draft-crocker-dnssec-algo-signal-04 Thread-Topic: New Version Notification for draft-crocker-dnssec-algo-signal-04 Thread-Index: AcpM/SvB7Y11fsHdQV+9uQmz1n7wQwAAOPM5 Message-ID: In-Reply-To: <20091014180541.DC03F3A6814@core3.amsl.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6FB93CC81D0scottrosenistgov_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --_000_C6FB93CC81D0scottrosenistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI - new version posted. This version incorporates many of the comments a= nd suggestions received from the last version posted before the Stockholm I= ETF meeting. The biggest change is the server processing text has been rem= oved. Scott =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scottr@nist.gov ph: +1 301-975-8439 http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------ Forwarded Message From: IETF I-D Submission Tool Date: Wed, 14 Oct 2009 14:05:41 -0400 To: "Rose, Scott W." Cc: Steve Crocker Subject: New Version Notification for draft-crocker-dnssec-algo-signal-04 A new version of I-D, draft-crocker-dnssec-algo-signal-04.txt has been succ= essfuly submitted by Scott Rose and posted to the IETF repository. Filename: draft-crocker-dnssec-algo-signal Revision: 04 Title: Signaling Cryptographic Algorithm Understanding in DNSSEC Creation_date: 2009-10-14 WG ID: Independent Submission Number_of_pages: 7 Abstract: The DNS Security Extensions (DNSSEC) was developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms they support. The IETF Secretariat. ------ End of Forwarded Message --_000_C6FB93CC81D0scottrosenistgov_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: New Version Notification for draft-crocker-dnssec-algo-signal-04= FYI – new version posted.  This version incorporates many = of the comments and suggestions received from the last version posted befor= e the Stockholm IETF meeting.  The biggest change is the server proces= sing text has been removed.   

Scott
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Scott Rose
NIST
scottr@nist.gov
ph: +1 301-975-8439
http://www-x.antd.nist.gov/dn= ssec
http://www.dnsops.gov/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


------ Forwarded Message
From: IETF I-D Submission Tool <idsubmission@ietf.org>
Date: Wed, 14 Oct 2009 14:05:41 -0400
To: "Rose, Scott W." <s= cott.rose@nist.gov>
Cc: Steve Crocker <steve@shinkuro.= com>
Subject: New Version Notification for draft-crocker-dnssec-algo-sign= al-04



A new version of I-D, draft-crocker-dnssec-algo-signal-04.txt has been succ= essfuly submitted by Scott Rose and posted to the IETF repository.

Filename:        draft-crocker-dnssec-al= go-signal
Revision:        04
Title:           Signalin= g Cryptographic Algorithm Understanding in DNSSEC
Creation_date:   2009-10-14
WG ID:           Independ= ent Submission
Number_of_pages: 7

Abstract:
The DNS Security Extensions (DNSSEC) was developed to provide origin
authentication and integrity protection for DNS data by using digital
signatures.  These digital signatures can be generated using
different algorithms.  This draft sets out to specify a way for
validating end-system resolvers to signal to a server which
cryptographic algorithms they support.
            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


The IETF Secretariat.




------ End of Forwarded Message
 --_000_C6FB93CC81D0scottrosenistgov_-- From owner-namedroppers@ops.ietf.org Wed Oct 14 12:20:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 668C028C0CF; Wed, 14 Oct 2009 12:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu9jUNTKEDpf; Wed, 14 Oct 2009 12:20:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4AFC63A6825; Wed, 14 Oct 2009 12:20:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1My9Kf-0009ZJ-Me for namedroppers-data0@psg.com; Wed, 14 Oct 2009 19:16:21 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1My9KU-0009YP-Cq for namedroppers@ops.ietf.org; Wed, 14 Oct 2009 19:16:18 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=tpdsiYIYF8ho8UXXmxPc33/fv/ozSotpgp+lpULAzajPkqo4exUdj6OK IAi7Ez+uGyUWt2RHlMM5gaZKkMcpudmPAz7K9p1lNAtjyR5ehGI+ic948 FxII1J9M4k7mO0a; 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=1255547770; x=1287083770; 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.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20draft-ietf-dnsext-dns-tcp-requirements-00=20/=20a =20way=20forward|Date:=20Wed,=2014=20Oct=202009=2020:16:0 6=20+0100|Message-ID:=20|To:=20Alfred=20 =3D?ISO-8859-1?Q?H=3DF6nes?=3D=20|Cc:=20fer nando@gont.com.ar,=0D=0A=09namedroppers@ops.ietf.org,=0D =0A=09tuexen@fh-muenster.de|MIME-Version:=201.0 |In-Reply-To:=20<200910141841.UAA25186@TR-Sys.de> |References:=20<48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-m uenster.de>=20from=20Michael=20Tuexen=0D=0A=20at=20Oct=20 "14,"=202009=20"07:22:32"=20pm=20<200910141841.UAA25186@T R-Sys.de>; bh=QlHKncVI146THQ0CwRCU0V4x+anaXyNOIqxs/NabWso=; b=zU31S6JCTtb6bZjwXxDWRnInSQRlMx9oeS/zpIjFKHSJ0ysHsZ5ipvn3 GbBLIfL6ltj32zuHFqM4nbSJIEC8SHQMHucGF57GJIVEkrOlCGkCb2XtZ 0Dc+LerY0UezUAe; X-IronPort-AV: E=Sophos;i="4.44,560,1249254000"; d="scan'208";a="18601147" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 14 Oct 2009 20:16:08 +0100 In-Reply-To: <200910141841.UAA25186@TR-Sys.de> References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> To: Alfred =?ISO-8859-1?Q?H=F6nes?= Cc: fernando@gont.com.ar, namedroppers@ops.ietf.org, tuexen@fh-muenster.de Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 14 Oct 2009 20:16:06 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 14/10/2009 08:16:07 PM, Serialize complete at 14/10/2009 08:16:07 PM Content-Type: multipart/alternative; boundary="=_alternative 0069D7BE8025764F_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 0069D7BE8025764F_= Content-Type: text/plain; charset="US-ASCII" > So let's focus on TCP. > > I fully support the idea of the draft, as already indicated. > > And I fully support Michael in that we want to use "unmodified TCP". Indeed - modifying TCP itself is not (as far as I'm concerned) on the table. > But TCP has a lot of Options, and perhaps all commercial and > open-source TCP stack implementations have a lot of tuning knobs > to adjust parameters, enable/disable options and mechanisms, etc. > -- that's particularly interesting for DNS server/resolver operators. > Furthermore, the TCP (socket) API contains features that allow > programmatic access to particular features, mechanisms and options > of TCP -- how to best make use thereof is highly interesting for > implementers of DNS software. It certainly is. FWIW, yesterday I performed some benchmark tests against Bind 9.6. Over TCP/IP I was able to do 3000 qps. That was with a brand new TCP connection for each query, with no parallelisation. The client code was literally: while (1) { socket(...); connect(...); write(2 byte len); write(request) read(2 byte len); read(response); close(); } The same server will do about 23000 qps over UDP. Personally I think that TCP performance is pretty good. I expect that with more queries in flight at the same time the effective performance might be double that at least. [BTW, the TCP stack on the _server_ didn't suffer at all, as it was the client end that was actively closing the connection. However the client very rapidly ran out of ephemeral ports because of the quantity that were in TIME_WAIT state]. > The main reason for having this draft is the perceived unwillingness > of various parties to implement/support/allow TCP as it was intended, > a mandatory transport for DNS in case UDP does not suffice, in > particular for packet size / fragmentation reasons. Exactly, yes. > We (or many of us) want to convince those parties posing obstacles > to this use of TCP that their opposition is not justified, and that > IMO cannot be done by a simple normative statement of "MUST" for TCP. > No, we need to provide arguments and show ways to mitigate the raised > concerns! Exploring the effects of TCP options and parameters and > giving recommendations to implementers and operators of how to use TCP > in the best possible manner seems the right way to achieve this goal. > This should include concrete arguments for implementors and vendors > of middleboxes that DNS over TCP is not evil. This is what I've attempted to do already, but I accept that it needs more work. Mostly what I'd like to be able to do is dispel (or at least mitigate) the FUD about TCP as a transport mechanism for DNS. > If we can agree on this strategy, the draft has a chance to be > amended and turned into a valuable document that gives enough > concrete guidance to both implementers and operators to actually > overcome the observed reservedness against the TCP support for > DNS transactions as specified in STD 13 and STD 3. > > Such exploration and elaboration should also better educate the > WG on aspects of DNS transport, allowing it to perform -- in a > second step then -- a more targeted evaluation of proposals for > alternate DNS transport(s), and eventually make better informed > decisions on how to proceed with new proposals to this end. > > N.B.: The priority of dealing with possible signalling of Transport > (and/or other feature) support in DNS servers may very well be made > dependent on the outcome of the first steps above. > > Can wee agree on this way forward? This sounds sensible, although I would like to take the counsel of those wiser to the ways of the IETF than I am. At the very least, the idea of having a real expert on TCP advise is very sensible. kind regards, Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 0069D7BE8025764F_= Content-Type: text/html; charset="US-ASCII"
> So let's focus on TCP.
>
> I fully support the idea of the draft, as already indicated.
>
> And I fully support Michael in that we want to use "unmodified TCP".
Indeed - modifying TCP itself is not (as far as I'm concerned) on the table.

> But TCP has a lot of Options, and perhaps all commercial and
> open-source TCP stack implementations have a lot of tuning knobs
> to adjust parameters, enable/disable options and mechanisms, etc.
> -- that's particularly interesting for DNS server/resolver operators.
> Furthermore, the TCP (socket) API contains features that allow
> programmatic access to particular features, mechanisms and options
> of TCP -- how to best make use thereof is highly interesting for
> implementers of DNS software.
It certainly is.

FWIW, yesterday I performed some benchmark tests against Bind 9.6.

Over TCP/IP I was able to do 3000 qps.  That was with a brand new TCP connection for each query, with no parallelisation.  The client code was literally:

while (1) {
  socket(...);
  connect(...);
  write(2 byte len);
  write(request)
  read(2 byte len);
  read(response);
  close();
}

The same server will do about 23000 qps over UDP.

Personally I think that TCP performance is pretty good.  I expect that with more queries in flight at the same time the effective performance might be double that at least.

[BTW, the TCP stack on the _server_ didn't suffer at all, as it was the client end that was actively closing the connection.  However the client very rapidly ran out of ephemeral ports because of the quantity that were in TIME_WAIT state].

> The main reason for having this draft is the perceived unwillingness
> of various parties to implement/support/allow TCP as it was intended,
> a mandatory transport for DNS in case UDP does not suffice, in
> particular for packet size / fragmentation reasons.
Exactly, yes.

> We (or many of us) want to convince those parties posing obstacles
> to this use of TCP that their opposition is not justified, and that
> IMO cannot be done by a simple normative statement of "MUST" for TCP.
> No, we need to provide arguments and show ways to mitigate the raised
> concerns!  Exploring the effects of TCP options and parameters and
> giving recommendations to implementers and operators of how to use TCP
> in the best possible manner seems the right way to achieve this goal.
> This should include concrete arguments for implementors and vendors
> of middleboxes that DNS over TCP is not evil.
This is what I've attempted to do already, but I accept that it needs more work.

Mostly what I'd like to be able to do is dispel (or at least mitigate) the FUD about TCP as a transport mechanism for DNS.

> If we can agree on this strategy, the draft has a chance to be
> amended and turned into a valuable document that gives enough
> concrete guidance to both implementers and operators to actually
> overcome the observed reservedness against the TCP support for
> DNS transactions as specified in STD 13 and STD 3.
>
> Such exploration and elaboration should also better educate the
> WG on aspects of DNS transport, allowing it to perform -- in a
> second step then -- a more targeted evaluation of proposals for
> alternate DNS transport(s), and eventually make better informed
> decisions on how to proceed with new proposals to this end.
>
> N.B.: The priority of dealing with possible signalling of Transport
> (and/or other feature) support in DNS servers may very well be made
> dependent on the outcome of the first steps above.
>
> Can wee agree on this way forward?
This sounds sensible, although I would like to take the counsel of those wiser to the ways of the IETF than I am.

At the very least, the idea of having a real expert on TCP advise is very sensible.

kind regards,

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211
 --=_alternative 0069D7BE8025764F_=-- From owner-namedroppers@ops.ietf.org Wed Oct 14 13:18:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE2773A6814; Wed, 14 Oct 2009 13:18:30 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBTg4yI6nudl; Wed, 14 Oct 2009 13:18:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6CD328C10E; Wed, 14 Oct 2009 13:18:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyACx-000E2c-C5 for namedroppers-data0@psg.com; Wed, 14 Oct 2009 20:12:27 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyACm-000E1s-Ou for namedroppers@ops.ietf.org; Wed, 14 Oct 2009 20:12:24 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 615C4CB1FE for ; Wed, 14 Oct 2009 20:12:16 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward In-Reply-To: Your message of "Wed, 14 Oct 2009 20:16:06 +0100." References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 14 Oct 2009 20:12:16 +0000 Message-ID: <99095.1255551136@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Ray.Bellis@nominet.org.uk > Date: Wed, 14 Oct 2009 20:16:06 +0100 > > ... - modifying TCP itself is not (as far as I'm concerned) on the table. for the purpose of this draft i think that's a safe assumption. > FWIW, yesterday I performed some benchmark tests against Bind 9.6. > > Over TCP/IP I was able to do 3000 qps. That was with a brand new TCP > connection for each query, with no parallelisation. The client code was > literally: > > while (1) { > socket(...); > connect(...); > write(2 byte len); > write(request) > read(2 byte len); > read(response); > close(); > } > > The same server will do about 23000 qps over UDP. > > Personally I think that TCP performance is pretty good. I expect that > with more queries in flight at the same time the effective performance > might be double that at least. what would the performance be if the server stopped receiving client FINs? > Mostly what I'd like to be able to do is dispel (or at least mitigate) > the FUD about TCP as a transport mechanism for DNS. "bring it on." :-) From owner-namedroppers@ops.ietf.org Wed Oct 14 13:35:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5073A68C0; Wed, 14 Oct 2009 13:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.979 X-Spam-Level: *** X-Spam-Status: No, score=3.979 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDQBrPHWgz82; Wed, 14 Oct 2009 13:35:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 51B973A67D9; Wed, 14 Oct 2009 13:35:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyAUw-000FWu-Vj for namedroppers-data0@psg.com; Wed, 14 Oct 2009 20:31:03 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyAUm-000FW3-2N for namedroppers@ops.ietf.org; Wed, 14 Oct 2009 20:30:59 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA232932205; Wed, 14 Oct 2009 22:30:05 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA25633; Wed, 14 Oct 2009 22:30:04 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910142030.WAA25633@TR-Sys.de> Subject: [dnsext] Significant typo (I hope) in draft-ietf-dnsext-dnssec-registry-fixes-00 To: scott.rose@nist.gov Date: Wed, 14 Oct 2009 22:30:03 +0200 (MESZ) Cc: namedroppers@ops.ietf.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Section 2.1 of draft-ietf-dnsext-dnssec-registry-fixes-00 says: v | The description for allocation number 8 is changed to "Reserved until | 2020". It should say: v | The description for allocation number 4 is changed to "Reserved until | 2020". Section 3 of the draft says: v | The description of allocation 8 is changed from "Reserved for ECC" to | "Reserved until 2020". It should say: v | The description of allocation 4 is changed from "Reserved for ECC" to | "Reserved until 2020". Rationale for both: - number 8 has just been assigned by IANA to RSA/SHA-256 for "RFC-ietf-dnsext-dnssec-rsasha256-14" ; - cf. Section 2.2. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From owner-namedroppers@ops.ietf.org Wed Oct 14 14:09:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BE1B3A6917; Wed, 14 Oct 2009 14:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.481 X-Spam-Level: X-Spam-Status: No, score=-4.481 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhqEG-UcMgYc; Wed, 14 Oct 2009 14:09:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 379543A694F; Wed, 14 Oct 2009 14:09:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyB2t-000IdY-Nv for namedroppers-data0@psg.com; Wed, 14 Oct 2009 21:06:07 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyB2g-000Ic8-W2 for namedroppers@ops.ietf.org; Wed, 14 Oct 2009 21:06:05 +0000 Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9EL5qaU069260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Oct 2009 14:05:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20091014181501.A5F2F3A6901@core3.amsl.com> References: <20091014181501.A5F2F3A6901@core3.amsl.com> Date: Wed, 14 Oct 2009 14:05:52 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: [dnsext] What does "status" mean in draft-ietf-dnsext-dnssec-registry-fixes-00? Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: There is a major unstated premise of this document. It assumes, without saying, that the MANDATORY / OPTIONAL / OBSOLETE status of a signature algorithm is determined by RFC 4034. If the document said "these status are derived from RFC 4034", and if the added column said "Status from RFC 4034", it would fix the problem. However, the last paragraph of section 2 says: Newly allocated algorithms will need to state their intended status in their specification. Any changes to a previously allocated algorithm's status MUST be done by a standards track document. That is quite troubling. If the new RFC updates 4034, then the status change comes from the update to 4034, not from the existence of the new doc. If the new RFC does not update 4034, then the IANA registry's value goes to hell quickly. A way to fix this would be to state "the only way to make a signature algorithm mandatory or obsolete is to update RFC 4034; the IANA registry can be updated at the same time as the update to RFC 4034 is published". --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Wed Oct 14 22:01:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0123A6991; Wed, 14 Oct 2009 22:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+MRmSHtK06R; Wed, 14 Oct 2009 22:01:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0293A3A6993; Wed, 14 Oct 2009 22:01:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyIMi-0003Gh-2a for namedroppers-data0@psg.com; Thu, 15 Oct 2009 04:55:04 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyIMU-0003Fl-25 for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 04:54:59 +0000 Received: from farside-mini.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 45690A94442; Thu, 15 Oct 2009 04:54:49 +0000 (UTC) Message-ID: <4AD6AB18.9000708@mail-abuse.org> Date: Wed, 14 Oct 2009 21:54:48 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk CC: =?ISO-8859-1?Q?Alfred_H=F6nes?= , fernando@gont.com.ar, namedroppers@ops.ietf.org, tuexen@fh-muenster.de Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 10/14/09 12:16 PM, Ray.Bellis@nominet.org.uk wrote: > > > I fully support the idea of the draft, as already indicated. > > > > And I fully support Michael in that we want to use "unmodified TCP". > > Indeed - modifying TCP itself is not (as far as I'm concerned) on the > table. > > FWIW, yesterday I performed some benchmark tests against Bind 9.6. > > Over TCP/IP I was able to do 3000 qps. That was with a brand new TCP > connection for each query, with no parallelisation. This has ignored loads that might be created by bad actors with the goal of burdening servers. Transactions per second statements should also cover the level of reduction caused by credible attack. > The same server will do about 23000 qps over UDP. This would seem to imply that after an 8x increase in the number of servers, DNS over TCP could then achieve its current margins. Even after such a sizable investment, retaining current margins seems implausible. > > The main reason for having this draft is the perceived unwillingness > > of various parties to implement/support/allow TCP as it was intended, > > a mandatory transport for DNS in case UDP does not suffice, in > > particular for packet size / fragmentation reasons. > > Exactly, yes. DNS is not currently dependent upon TCP, nor had DNS been designed to become dependent upon TCP. The fact that most CPE equipment does not proxy DNS over TCP should give this WG some pause about the economical practicality of depending upon TCP. At least, TCP will ensure DNS represents less of a threat when exploited to attack other services. However, nearly all other services heavily depend upon DNS remaining operational. > > We (or many of us) want to convince those parties posing obstacles > > to this use of TCP that their opposition is not justified, and that > > IMO cannot be done by a simple normative statement of "MUST" for TCP. > > No, we need to provide arguments and show ways to mitigate the raised > > concerns! Exploring the effects of TCP options and parameters and > > giving recommendations to implementers and operators of how to use TCP > > in the best possible manner seems the right way to achieve this goal. > > This should include concrete arguments for implementors and vendors > > of middleboxes that DNS over TCP is not evil. > > This is what I've attempted to do already, but I accept that it needs > more work. > > Mostly what I'd like to be able to do is dispel (or at least mitigate) > the FUD about TCP as a transport mechanism for DNS. Would you suggest a substantial increases in the resources needed to sustain current levels of service is not cause for concern or careful review of possible alternative? It seems important to ensure that resources estimates be based upon reasonable expectations of what might be needed to endure credible levels of abuse? > > If we can agree on this strategy, the draft has a chance to be > > amended and turned into a valuable document that gives enough > > concrete guidance to both implementers and operators to actually > > overcome the observed reservedness against the TCP support for > > DNS transactions as specified in STD 13 and STD 3. > > > > Such exploration and elaboration should also better educate the > > WG on aspects of DNS transport, allowing it to perform -- in a > > second step then -- a more targeted evaluation of proposals for > > alternate DNS transport(s), and eventually make better informed > > decisions on how to proceed with new proposals to this end. > > > > N.B.: The priority of dealing with possible signalling of Transport > > (and/or other feature) support in DNS servers may very well be made > > dependent on the outcome of the first steps above. > > > > Can wee agree on this way forward? > > This sounds sensible, although I would like to take the counsel of those > wiser to the ways of the IETF than I am. > > At the very least, the idea of having a real expert on TCP advise is > very sensible. One might have hoped TCP would _not_ have been seen as the _only_ option available, and that fair comparisons of the alternatives would have been sought instead of discouraged. It seems unwise to eliminate alternatives already providing service for other critical infrastructure in a manner similar to that required by DNS. When dependent upon TCP, how much DNS infrastructure will become dependent upon Akamai like services, and who might desire this outcome? -Doug From owner-namedroppers@ops.ietf.org Wed Oct 14 23:31:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D1E3A6862; Wed, 14 Oct 2009 23:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.048 X-Spam-Level: X-Spam-Status: No, score=-4.048 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSEwtukEB14y; Wed, 14 Oct 2009 23:31:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 03A613A6841; Wed, 14 Oct 2009 23:31:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyJlt-000AxS-0D for namedroppers-data0@psg.com; Thu, 15 Oct 2009 06:25:09 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyJli-000Awd-K7 for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 06:25:06 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=WJ6Fmbi08CFW6MV7bS/MrJGtHbtJIdc2L+qkJEOywYIXtNqD7VNXn2c3 ZBBFqz+NB5Cf236zCDDEgG7TrabFtn7BlrPI8dOW/XAgfFswuMFsxs1y6 QCAHfBAGZTwP3ac; 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=1255587898; x=1287123898; 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.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20draft-ietf-dnsext-dns-tcp-requirements-00=20/=20a =20way=20forward|Date:=20Thu,=2015=20Oct=202009=2007:24:5 5=20+0100|Message-ID:=20|To:=20Douglas =20Otis=20|Cc:=20Alfred=20=3D?ISO-8 859-1?Q?H=3DF6nes?=3D=20,=0D=0A=09fernando@ gont.com.ar,=0D=0A=09namedroppers@ops.ietf.org,=0D=0A=09t uexen@fh-muenster.de|MIME-Version:=201.0|In-Reply-To:=20< 4AD6AB18.9000708@mail-abuse.org>|References:=20<48DCD05A- 8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de>=20from=20Mich ael=20Tuexen=0D=0A=20at=20Oct=20"14,"=202009=20"07:22:32" =20pm=20<200910141841.UAA25186@TR-Sys.de>=20=20<4AD6AB18.9000708@mail-abuse.org>; bh=z97qucHjfxnvlT0Q+LHPySF/ug1J0WaKGSlKKgRg3mE=; b=YRkfM+R7uCeQd/ZHGe0d8WQl6RRG/WD5JrAGpELYVVeycFQWmfA+5Dvh MOBe5EPauz5x7AUmZcb7ayv6IwJ9CfqAPZ1acTIJWNIoXKm5a4sMlAOxK uVLWWCAen4bOB7N; X-IronPort-AV: E=Sophos;i="4.44,564,1249254000"; d="scan'208";a="13664327" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 15 Oct 2009 07:24:56 +0100 In-Reply-To: <4AD6AB18.9000708@mail-abuse.org> References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> To: Douglas Otis Cc: Alfred =?ISO-8859-1?Q?H=F6nes?= , fernando@gont.com.ar, namedroppers@ops.ietf.org, tuexen@fh-muenster.de Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 15 Oct 2009 07:24:55 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 15/10/2009 07:24:55 AM, Serialize complete at 15/10/2009 07:24:55 AM Content-Type: multipart/alternative; boundary="=_alternative 00233CFC80257650_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 00233CFC80257650_= Content-Type: text/plain; charset="US-ASCII" > This has ignored loads that might be created by bad actors with the goal > of burdening servers. Transactions per second statements should also > cover the level of reduction caused by credible attack. Doug, Indeed, that was a lab test. As Vix indrectly pointed out, a client that fails to send FIN packets is not good for servers. However, 90% of the TLD authoritative servers and all but 'm' from the root servers *already* support TCP/IP. And yet the DNS is not collapsing under the weight of DoS attacks against them. > DNS is not currently dependent upon TCP, nor had DNS been designed to > become dependent upon TCP. The fact that most CPE equipment does not > proxy DNS over TCP should give this WG some pause about the economical > practicality of depending upon TCP. The fact that very few middlebox vendors implement TCP is not, IMHO, because of some deeply held reservations about TCP. Hell, many such boxes proxy HTTP without any problem and that's far harder. As far as I can tell it's simple laziness on the part of the implementors. Ray --=_alternative 00233CFC80257650_= Content-Type: text/html; charset="US-ASCII" > This has ignored loads that might be created by bad actors with the goal
> of burdening servers.  Transactions per second statements should also
> cover the level of reduction caused by credible attack.
Doug,

Indeed, that was a lab test.  As Vix indrectly pointed out, a client that fails to send FIN packets is not good for servers.

However, 90% of the TLD authoritative servers and all but 'm' from the root servers *already* support TCP/IP.

And yet the DNS is not collapsing under the weight of DoS attacks against them.

> DNS is not currently dependent upon TCP, nor had DNS been designed to
> become dependent upon TCP.  The fact that most CPE equipment does not
> proxy DNS over TCP should give this WG some pause about the economical
> practicality of depending upon TCP.

The fact that very few middlebox vendors implement TCP is not, IMHO, because of some deeply held reservations about TCP.  Hell, many such boxes proxy HTTP without any problem and that's far harder.  As far as I can tell it's simple laziness on the part of the implementors.

Ray
--=_alternative 00233CFC80257650_=-- From rootf70@93-44-83-250.ip96.fastwebnet.it Thu Oct 15 02:26:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFADD3A6878 for ; Thu, 15 Oct 2009 02:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -79.54 X-Spam-Level: X-Spam-Status: No, score=-79.54 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8qfPzAX6its for ; Thu, 15 Oct 2009 02:26:17 -0700 (PDT) Received: from 93-44-83-250.ip96.fastwebnet.it (93-44-83-250.ip96.fastwebnet.it [93.44.83.250]) by core3.amsl.com (Postfix) with ESMTP id 457953A6860 for ; Thu, 15 Oct 2009 02:26:16 -0700 (PDT) Received: from 93.44.83.250 by relay-1.mail.demon.net; Thu, 15 Oct 2009 10:26:19 +0100 Date: Thu, 15 Oct 2009 10:26:19 +0100 From: "Berta Wilkins" X-Mailer: The Bat! (v2.00.7) Educational Reply-To: rootf70@93-44-83-250.ip96.fastwebnet.it X-Priority: 3 (Normal) Message-ID: <062588865.42922094300340@93-44-83-250.ip96.fastwebnet.it> To: dnsext-archive@lists.ietf.org Subject: dont regret anymore MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit you are tired of that job? Grab a better Educational status. (816)-(292)-(2839) call us, leave your name and number we will contact you back soon From owner-namedroppers@ops.ietf.org Thu Oct 15 05:43:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74D483A687E; Thu, 15 Oct 2009 05:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4 X-Spam-Level: **** X-Spam-Status: No, score=4 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5N-P1Efz54i; Thu, 15 Oct 2009 05:43:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5381E3A681E; Thu, 15 Oct 2009 05:43:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyPYh-0001HY-6q for namedroppers-data0@psg.com; Thu, 15 Oct 2009 12:35:55 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyPYW-0001GF-NW for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 12:35:53 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA236900097; Thu, 15 Oct 2009 14:34:57 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA27012; Thu, 15 Oct 2009 14:34:55 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910151234.OAA27012@TR-Sys.de> Subject: [dnsext] draft-crocker-dnssec-algo-signal-04 editorials To: steve@shinkuro.com, scott.rose@nist.gov Date: Thu, 15 Oct 2009 14:34:55 +0200 (MESZ) Cc: namedroppers@ops.ietf.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I have a few, mostly editorial suggestions to further improve the most recent version of your DNSSEC 'Algorithm-Signal' draft, draft-crocker-dnssec-algo-signal-04. (1) General -- grammar "The DNS Security Extensions ..." is plural, but the draft says "... was developed" -- shouldn't it better say "... were developed" ? This affects the Abstract and the Introduction (para 1, see below). (2) Section 1 (2a) 1st para -- textual improvement I suggest to improve the readability by shuffling the words in the first sentence, and apply item (1) above: The DNS Security Extensions (DNSSEC) was developed to provide origin authentication and integrity protection for DNS data by using digital signatures [RFC4033], [RFC4034] and [RFC4035]. [...] --- The DNS Security Extensions ("DNSSEC", [RFC4033], [RFC4034] and [RFC4035]) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. [...] (2b) paragraph shuffling Currently, the *last* paragraph of the Introduction introduces the goal of the memo and the proposed means to achieve it (and EDNS option), but already the second para refers to "This proposed EDNS option". This breaks the flow of the reasoning. Therefore, I suggest to move the 4th para up, making it the second one. (3) Section 2 (3a) 1st para -- improvement The current text ... | Below shows how the signaling attribute is defined in the RDATA of | the OPT RR as specified in [RFC2671]: ... seems to be a bit unpleasant; "Below" usually is not conceived as a noun. I suggest to insert a proper noun for improved readability. Also, the "as" in the second line seems to introduce ambiguity as to what has been defined in RFC 2671; I suggest to drop it. vvvvvvvvvvvv | The figure below shows how the signaling attribute is defined in the | RDATA of the OPT RR specified in [RFC2671]: ^ (3b) last para -- clarification / consistency The current version of the text is not consistent with the subsequent explanations; it looks like the original concept of 'staging' algo numbers by value has survived here. Since doing so would constrain IANA in the allocation of new numbers and force implementations to keep support for older algos (with numerically lower code) forever, I thought this idea had been abandoned. Also, the phrase "ALG-CODE is the ... algorithms" is unpleasant and arguably bad grammar, since "ALG-CODE" designates the a single code point in the diagram, which is then repeated arbitrarily. So altogether I suggest the following change: | ALG-CODE is the assigned DNSSEC algorithm codes that the client | indicates as understood. The values MUST be in descending order, | with the highest algorithm code first, followed by as many other | codes as the validator wishes to signal that it prefers. [...] ---vvvv vvvvvvvvvvvvvvvv | The ALG-CODE values designate the assigned DNSSEC algorithm codes that the client indicates as understood. The values MUST be in | descending order of preference, with the most preferred algorithm ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ code first, followed by as many other codes as the validator wishes | to signal that it understands. [...] ^^^^^^^^^^^ (4) Section 3, 1st para Accordingly, the text in the 1st para of Section 3 should be adjusted for clarity and consistence: A validating end-system resolver sets the AU option in the OPT meta-RR when sending a query. The validating end-system resolver | sets the value(s) in the order of preference, with highest algorithm value first as described in section 2. The end-system resolver MUST also set the DNSSEC-OK bit [RFC4035] to indicate that it wishes to receive DNSSEC RRs in the response. --- A validating end-system resolver sets the AU option in the OPT meta-RR when sending a query. The validating end-system resolver | sets the value(s) in the order of preference, with the most preferred v ^^^^^^^^^^^^^^^^^^ | algorithm value first, as described in section 2. The end-system resolver MUST also set the DNSSEC-OK bit [RFC4035] to indicate that it wishes to receive DNSSEC RRs in the response. (5) Section 3.1 (5a) 1st para The second comma separates two full sentences and should therefore better be replaces by a semicolon (or a period, if you prefer): Typically, stub resolvers rely on an upstream recursive server (or | cache) to provide a response, any algorithm supportence on the stub resolver's side could be overruled by the upstream recursive server. --- Typically, stub resolvers rely on an upstream recursive server (or | cache) to provide a response; any algorithm supportence on the stub resolver's side could be overruled by the upstream recursive server. (5d) 3rd para -- typo? I suggest to s/therefor/therefore/ . [ My dictionary classifies the former variant as "obsolete form used in jurisprudence". IANAL, but the latter indeed seems more common. :-) ] (6) Section 6, 2nd para -- typo Please s/in order ot/in order to/ . ^^ ^^ Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From owner-namedroppers@ops.ietf.org Thu Oct 15 05:44:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF833A687F; Thu, 15 Oct 2009 05:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.047 X-Spam-Level: X-Spam-Status: No, score=-5.047 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NW6H56CSNqD1; Thu, 15 Oct 2009 05:43:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 99BD93A681E; Thu, 15 Oct 2009 05:43:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyPa4-0001S5-Hh for namedroppers-data0@psg.com; Thu, 15 Oct 2009 12:37:20 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyPZq-0001Op-Li for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 12:37:18 +0000 Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n9FC3bXB004568; Thu, 15 Oct 2009 08:03:37 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Thu, 15 Oct 2009 08:03:21 -0400 From: "Rose, Scott W." To: "ah@TR-Sys.de" CC: "namedroppers@ops.ietf.org" Date: Thu, 15 Oct 2009 08:03:21 -0400 Subject: Re: [dnsext] Significant typo (I hope) in draft-ietf-dnsext-dnssec-registry-fixes-00 Thread-Topic: [dnsext] Significant typo (I hope) in draft-ietf-dnsext-dnssec-registry-fixes-00 Thread-Index: AcpNDos9OLZJAswJSySm4W2UDvZ4BQAgPH6x Message-ID: In-Reply-To: <200910142030.WAA25633@TR-Sys.de> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6FC87C9820Escottrosenistgov_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --_000_C6FC87C9820Escottrosenistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alfred, Thank you for the quick catch. Made a rush to get this out before Monday a= nd made mistakes. It should be numbers 4, 9 and 11 that are "reserved unti= l 2020". Scott On 10/14/09 4:30 PM, "ah@TR-Sys.de" wrote: Section 2.1 of draft-ietf-dnsext-dnssec-registry-fixes-00 says: v | The description for allocation number 8 is changed to "Reserved until | 2020". It should say: v | The description for allocation number 4 is changed to "Reserved until | 2020". Section 3 of the draft says: v | The description of allocation 8 is changed from "Reserved for ECC" to | "Reserved until 2020". It should say: v | The description of allocation 4 is changed from "Reserved for ECC" to | "Reserved until 2020". Rationale for both: - number 8 has just been assigned by IANA to RSA/SHA-256 for "RFC-ietf-dnsext-dnssec-rsasha256-14" ; - cf. Section 2.2. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scottr@nist.gov ph: +1 301-975-8439 http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_C6FC87C9820Escottrosenistgov_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dnsext] Significant typo (I hope) in draft-ietf-dnsext-dnssec-r= egistry-fixes-00 Alfred,
Thank you for the quick catch.  Made a rush to get this out before Mon= day and made mistakes.  It should be numbers 4, 9 and 11 that are R= 20;reserved until 2020”.  

Scott


On 10/14/09 4:30 PM, "ah@TR-Sys.de" = <ah@TR-Sys.de> wrote:

Section 2.1 of draft-ietf-dnsext-dnssec-reg= istry-fixes-00 says:

            &nb= sp;            =             &nb= sp;   v
|  The description for allocation number 8 is changed to "Reserve= d until
|  2020".

It should say:
            &nb= sp;            =             &nb= sp;   v
|  The description for allocation number 4 is changed to "Reserve= d until
|  2020".


Section 3 of the draft says:
            &nb= sp;            =         v
|  The description of allocation 8 is changed from "Reserved for = ECC" to
|  "Reserved until 2020".

It should say:
            &nb= sp;            =         v
|  The description of allocation 4 is changed from "Reserved for = ECC" to
|  "Reserved until 2020".


Rationale for both:
-  number 8 has just been assigned by IANA to RSA/SHA-256 for
   "RFC-ietf-dnsext-dnssec-rsasha256-14" ;
-  cf. Section 2.2.


Kind regards,
  Alfred.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-= Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -1= 8         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de       =             &nb= sp; |
+------------------------+--------------------------------------------+



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Scott Rose
NIST
scottr@nist.gov
ph: +1 301-975-8439
http://www-x.antd.nist.gov/dn= ssec
http://www.dnsops.gov/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 --_000_C6FC87C9820Escottrosenistgov_-- From owner-namedroppers@ops.ietf.org Thu Oct 15 07:07:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7DA33A691C; Thu, 15 Oct 2009 07:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.018 X-Spam-Level: **** X-Spam-Status: No, score=4.018 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxptF4eiU6Ho; Thu, 15 Oct 2009 07:07:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 112A53A6914; Thu, 15 Oct 2009 07:07:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyQua-000BJp-1k for namedroppers-data0@psg.com; Thu, 15 Oct 2009 14:02:36 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyQuP-000BIc-Vl for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 14:02:34 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA237375299; Thu, 15 Oct 2009 16:01:39 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA27159; Thu, 15 Oct 2009 16:01:37 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910151401.QAA27159@TR-Sys.de> Subject: [dnsext] What is the 'canonical' spelling: RRset of RRSet ? To: namedroppers@ops.ietf.org Date: Thu, 15 Oct 2009 16:01:37 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Folks, I need a bit of feedback for a review. What is the correct/preferred spelling/capitalization from the PoV of the list: "RRset" or "RRSet" ? There's a very decided position in the IETF w.r.t. the capitalization of other important acronyms, like "IPsec". Do the readers of this list care similarly in the above case? Background information usage in on selected 'important' DNS RFCs: o "RRset" is used in RFCs 4033, 4034, 4035, and 4509; o "RRSet" appears in RFCs 2181 and 5155. o current DNS related I-Ds also vary; there are even drafts using both. Any opinions? Thanks in advance for the help, and kind regards, Alfred. From owner-namedroppers@ops.ietf.org Thu Oct 15 08:12:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6144428C113; Thu, 15 Oct 2009 08:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.898 X-Spam-Level: X-Spam-Status: No, score=-3.898 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJUI9jtObnL4; Thu, 15 Oct 2009 08:12:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B8D33A69CA; Thu, 15 Oct 2009 08:12:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyRtj-000Jbq-25 for namedroppers-data0@psg.com; Thu, 15 Oct 2009 15:05:47 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyRtV-000JaN-Li for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 15:05:43 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:To:Subject:MIME-Version:X-Mailer: Message-ID:From:Date:X-MIMETrack:Content-Type; b=LSqt8QimXEnklQ+r/OJqqF5Wm2qek1jHo+ZcQShCyo58hCWl/tD4RaXA YO0jfHAaLqHu62QMofGll1AGH0N/Rv1moHcypxYK4hQ9YvYzhWin/VpJo R7iGKGVwg8mybNo; 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=1255619133; x=1287155133; 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.Bellis@nominet.org.uk|Subject:=20Fw:=20New =20Version=20Notification=20for=20draft-bellis-dns-recurs ive-discovery-00|Date:=20Thu,=2015=20Oct=202009=2016:05:3 0=20+0100|Message-ID:=20|To:=20namedropp ers=20|MIME-Version:=201.0; bh=Ut9/O7tMXGRSd/2w+8vS7Wu1V3geu4BVEqSUjqwm9DA=; b=KqwGlAebKYzpHns48hrsDju5pEupf/9CFfWLK6zmoXKUDUexVPXW1O+0 GNEVtoCYsBknUK8owKKgJQGrhCIk2McXhtxF7V/5WysHtk1PX29MRWGHU 3b1D722sN/LkunR; X-IronPort-AV: E=Sophos;i="4.44,566,1249254000"; d="scan'208";a="18627853" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 15 Oct 2009 16:05:31 +0100 To: namedroppers Subject: [dnsext] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 15 Oct 2009 16:05:30 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 15/10/2009 04:05:30 PM, Serialize complete at 15/10/2009 04:05:30 PM Content-Type: multipart/alternative; boundary="=_alternative 0052E6AD80257650_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 0052E6AD80257650_= Content-Type: text/plain; charset="US-ASCII" I've just submitted the following new draft. Strictly speaking it's probably DNSOP material, but Olafur said I should announce it here too. --8<--8<-- A new version of I-D, draft-bellis-dns-recursive-discovery-00.txt has been successfuly submitted by Ray Bellis and posted to the IETF repository. Filename: draft-bellis-dns-recursive-discovery Revision: 00 Title: DNS Proxy Bypass by Recursive DNS Discovery and LOCAL.ARPA Creation_date: 2009-10-15 WG ID: Independent Submission Number_of_pages: 9 Abstract: This document describes a method for a DNS client resolver to discover the IP addresses of the upstream recursive DNS resolvers and hence bypass the local DNS proxy. It also directs IANA to reserve the "LOCAL.ARPA" domain name and to create a registry for well known sub-domains of that domain name, such sub-domains being reserved for use within any network's administrative boundary. --8<--8<-- The draft is available for download at http://tools.ietf.org/html/draft-bellis-dns-recursive-discovery-00 Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 0052E6AD80257650_= Content-Type: text/html; charset="US-ASCII" I've just submitted the following new draft.

Strictly speaking it's probably DNSOP material, but Olafur said I should announce it here too.

--8<--8<--
A new version of I-D, draft-bellis-dns-recursive-discovery-00.txt has been successfuly submitted by Ray Bellis and posted to the IETF repository.

Filename:                draft-bellis-dns-recursive-discovery
Revision:                00
Title:                   DNS Proxy Bypass by Recursive DNS Discovery and LOCAL.ARPA
Creation_date:           2009-10-15
WG ID:                   Independent Submission
Number_of_pages:         9

Abstract:
This document describes a method for a DNS client resolver to
discover the IP addresses of the upstream recursive DNS resolvers and
hence bypass the local DNS proxy.  It also directs IANA to reserve
the "LOCAL.ARPA" domain name and to create a registry for well known
sub-domains of that domain name, such sub-domains being reserved for
use within any network's administrative boundary.
--8<--8<--

The draft is available for download at http://tools.ietf.org/html/draft-bellis-dns-recursive-discovery-00

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211


 --=_alternative 0052E6AD80257650_=-- From owner-namedroppers@ops.ietf.org Thu Oct 15 08:45:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D923A691B; Thu, 15 Oct 2009 08:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.868 X-Spam-Level: X-Spam-Status: No, score=0.868 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnrSjaNhV9YV; Thu, 15 Oct 2009 08:45:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3022C3A68F5; Thu, 15 Oct 2009 08:45:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MySQK-0004zf-QJ for namedroppers-data0@psg.com; Thu, 15 Oct 2009 15:39:28 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MySQB-0004wo-8m for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 15:39:26 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5C1F82FE8CDC for ; Thu, 15 Oct 2009 15:39:17 +0000 (UTC) Date: Thu, 15 Oct 2009 11:39:14 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] What is the 'canonical' spelling: RRset of RRSet ? Message-ID: <20091015153914.GC6184@shinkuro.com> References: <200910151401.QAA27159@TR-Sys.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200910151401.QAA27159@TR-Sys.de> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Oct 15, 2009 at 04:01:37PM +0200, Alfred Hönes wrote: > Background information usage in on selected 'important' DNS RFCs: > o "RRset" is used in RFCs 4033, 4034, 4035, and 4509; > o "RRSet" appears in RFCs 2181 and 5155. > o current DNS related I-Ds also vary; there are even drafts using both. > > Any opinions? >From the evidence, there are plenty of opinions! But since 2181 defines RRSet and does not define RRset, I claim that the latter term is undefined and that the former term is the only correct spelling of the notion. Contrariwise, others might argue that DNS is case-preserving but case-insensitive, and therefore RRSet and RRset (and even rrset) denote the same concept. I answer that we are writing in English and not DNS, and English is case-sensitive and case-preserving. I'll note (for those to whom these things are meaningful) that I also believe the Gowers edition of Fowler to be the One True version and that anything else is a needless innovation. One might infer that I am sort of curmudgeonly on this topic. I am not, however, the RFC Editor. It might be worth asking them whether they have a rule about this (but given the publications you mention, I doubt it). A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Oct 15 09:54:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEEF728C102; Thu, 15 Oct 2009 09:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InqT38q7R1+k; Thu, 15 Oct 2009 09:54:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7003C3A672F; Thu, 15 Oct 2009 09:54:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyTVb-000DxL-NO for namedroppers-data0@psg.com; Thu, 15 Oct 2009 16:48:59 +0000 Received: from [131.111.8.135] (helo=ppsw-5.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyTVS-000Dwn-IO for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 16:48:57 +0000 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]:49964) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:cet1) id 1MyTVR-00047j-H7 (Exim 4.70) for namedroppers@ops.ietf.org (return-path ); Thu, 15 Oct 2009 17:48:49 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1MyTVR-0001QK-9X (Exim 4.67) for namedroppers@ops.ietf.org (return-path ); Thu, 15 Oct 2009 17:48:49 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.2); 15 Oct 2009 17:48:49 +0100 Date: 15 Oct 2009 17:48:49 +0100 From: Chris Thompson To: namedroppers@ops.ietf.org Reply-To: cet1@cam.ac.uk Subject: Re: [dnsext] What is the 'canonical' spelling: RRset of RRSet ? Message-ID: In-Reply-To: <20091015153914.GC6184@shinkuro.com> References: <200910151401.QAA27159@TR-Sys.de> <20091015153914.GC6184@shinkuro.com> X-Mailer: Prayer v1.3.2 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Oct 15 2009, Andrew Sullivan wrote: >On Thu, Oct 15, 2009 at 04:01:37PM +0200, Alfred H=F6nes wrote: >> Background information usage in on selected 'important' DNS RFCs: >> o "RRset" is used in RFCs 4033, 4034, 4035, and 4509; >> o "RRSet" appears in RFCs 2181 and 5155. >> o current DNS related I-Ds also vary; there are even drafts using both. >>=20 >> Any opinions? > >From the evidence, there are plenty of opinions! But since 2181 >defines RRSet and does not define RRset, I claim that the latter term >is undefined and that the former term is the only correct spelling of >the notion. But RFC 2136 defines RRset (and uses it heavily) and that takes precedence over RFC 2181 by a whole 3 months in publication date! :-) There are some earlier (rather informal) references. The earliest I found= =20 in a casual search was in RFC 1996, and it uses "RRset". I admit to a strong personal bias in favour of "RRset". >I'll note (for those to whom these things are meaningful) that I also >believe the Gowers edition of Fowler to be the One True version and >that anything else is a needless innovation. One might infer that I >am sort of curmudgeonly on this topic. You want to start a curmudgeoness contest *here*? That's extremely ... brave of you. --=20 Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From owner-namedroppers@ops.ietf.org Thu Oct 15 10:19:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9BA93A67C0; Thu, 15 Oct 2009 10:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.712 X-Spam-Level: X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eciP2o0vyMM; Thu, 15 Oct 2009 10:19:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A1D93A67A2; Thu, 15 Oct 2009 10:19:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyTvl-000GP0-Qq for namedroppers-data0@psg.com; Thu, 15 Oct 2009 17:16:01 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyTvZ-000GNe-1F for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 17:16:00 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D86702FE8CDC for ; Thu, 15 Oct 2009 17:15:46 +0000 (UTC) Date: Thu, 15 Oct 2009 13:15:43 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] What is the 'canonical' spelling: RRset of RRSet ? Message-ID: <20091015171543.GF6184@shinkuro.com> References: <200910151401.QAA27159@TR-Sys.de> <20091015153914.GC6184@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Oct 15, 2009 at 05:48:49PM +0100, Chris Thompson wrote: >> From the evidence, there are plenty of opinions! But since 2181 >> defines RRSet and does not define RRset, I claim that the latter term >> is undefined and that the former term is the only correct spelling of >> the notion. > > But RFC 2136 defines RRset (and uses it heavily) and that takes precedence > over RFC 2181 by a whole 3 months in publication date! :-) Hrm, now that's a good point. I forgot about that definition. Therefore, I must revise my opinion, and claim that RRset is indeed defined. Nevertheless, since 2181 says it's the "clarifications" document, I still claim that it is authoritative on this topic. Still, for questions of publication style, the right authority is the RFC Editor. If I were going to make it to Hiroshima (I have a personal conflict that can't be resolved in the IETF meeting's favour), I'd probably stop by their desk and ask them. > You want to start a curmudgeoness contest *here*? That's extremely ... > brave of you. I did limit the scope to rules for English, please note! A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Oct 15 10:19:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95673A67C0; Thu, 15 Oct 2009 10:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-1.052, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8INnDaC-YV6; Thu, 15 Oct 2009 10:19:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 13AFD3A67A2; Thu, 15 Oct 2009 10:19:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyTvt-000GPV-Rc for namedroppers-data0@psg.com; Thu, 15 Oct 2009 17:16:09 +0000 Received: from [209.85.219.207] (helo=mail-ew0-f207.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyTvk-000GOn-PN for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 17:16:08 +0000 Received: by ewy3 with SMTP id 3so625830ewy.41 for ; Thu, 15 Oct 2009 10:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Yi1mk8bkq3IFyS4GgIAqd/AyQl01U8XLwhBmLR3d4nc=; b=S8Z73eK8drGfFQb/hDWX4CUGnnkGpqZew/fITLp8ATVBBVSbwzuahog346n+OPuRx7 rVbt6DbWw+mFpRi+IuXVmBJ4IRFQyBkd4cifGS7g3RHMEGig56Kqp3jiOg5vgpbb6sTm 4FKcktvtcha1FarKUJVvYz90W8H74KOSp8a1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=VdjPh8GV2oNEgXvSb758/ESbT/GW8UD4W9QQgPTX4EDBGjsPTR3zQzFwsS5vcTtbdS fT9lGEDS7/CbgBRyut7rwmNTBh7IhEIL9OSyGn5HTwFhJJR8hG8vktCs7KZDgC2OOaXt eBvqVDk0jzKZr8M6aHkSi5HPTuGJ5mO8EFvOY= MIME-Version: 1.0 Received: by 10.216.85.68 with SMTP id t46mr87078wee.114.1255626959123; Thu, 15 Oct 2009 10:15:59 -0700 (PDT) In-Reply-To: References: <200910151401.QAA27159@TR-Sys.de> <20091015153914.GC6184@shinkuro.com> Date: Thu, 15 Oct 2009 13:15:59 -0400 Message-ID: <1028365c0910151015n3e17a78cx6fe154f3ed37299e@mail.gmail.com> Subject: Re: [dnsext] What is the 'canonical' spelling: RRset of RRSet ? From: Donald Eastlake To: namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=0016e6d645a8de748c0475fc6e69 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016e6d645a8de748c0475fc6e69 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 15, 2009 at 12:48 PM, Chris Thompson wrote: > ... > But RFC 2136 defines RRset (and uses it heavily) and that takes precedence > over RFC 2181 by a whole 3 months in publication date! :-) > > There are some earlier (rather informal) references. The earliest I found > in a casual search was in RFC 1996, and it uses "RRset". > > I admit to a strong personal bias in favour of "RRset". +1 Donald --0016e6d645a8de748c0475fc6e69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 15, 2009 at 12:48 PM, Chris Thompson= <cet1@cam.ac.uk= > wrote:
...
But RFC 2136 defines RRset (and uses it heavily) a= nd that takes precedence
over RFC 2181 by a whole 3 months in publication date! :-)

There are some earlier (rather informal) references. The earliest I found i= n a casual search was in RFC 1996, and it uses "RRset".

I admit to a strong personal bias in favour of "RRset".

+1

Donald=A0
--0016e6d645a8de748c0475fc6e69-- From owner-namedroppers@ops.ietf.org Thu Oct 15 10:40:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7F228C0E7; Thu, 15 Oct 2009 10:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAxz1Lz3vQG2; Thu, 15 Oct 2009 10:40:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BAA3B3A659A; Thu, 15 Oct 2009 10:40:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyUFP-000IHo-B9 for namedroppers-data0@psg.com; Thu, 15 Oct 2009 17:36:19 +0000 Received: from [2001:7b8:206:1:216:76ff:feb8:3c02] (helo=bartok.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyUF0-000ID5-CZ for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 17:36:08 +0000 Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n9FHZkZ2088921; Thu, 15 Oct 2009 19:35:46 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200910151735.n9FHZkZ2088921@bartok.nlnetlabs.nl> To: Alfred =?hp-roman8?B?SM5uZXM=?= cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] What is the 'canonical' spelling: RRset of RRSet ? In-reply-to: <200910151401.QAA27159@TR-Sys.de> References: <200910151401.QAA27159@TR-Sys.de> Comments: In-reply-to Alfred =?hp-roman8?B?SM5uZXM=?= message dated "Thu, 15 Oct 2009 16:01:37 +0200." Date: Thu, 15 Oct 2009 19:35:46 +0200 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (bartok.nlnetlabs.nl [127.0.0.1]); Thu, 15 Oct 2009 19:35:46 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Alfred, Folks, I need a bit of feedback for a review. Thanks for bringing this up. What is the correct/preferred spelling/capitalization from the PoV of the list: "RRset" or "RRSet" ? Any opinions? My preference is for RRset because that is what I always use. jaap From owner-namedroppers@ops.ietf.org Thu Oct 15 11:18:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FD253A67B1; Thu, 15 Oct 2009 11:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGf2aArfBgjq; Thu, 15 Oct 2009 11:18:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A43673A67A7; Thu, 15 Oct 2009 11:18:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyUny-000MCZ-Cw for namedroppers-data0@psg.com; Thu, 15 Oct 2009 18:12:02 +0000 Received: from [72.14.220.153] (helo=fg-out-1718.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyUno-000MBz-Lp for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 18:12:00 +0000 Received: by fg-out-1718.google.com with SMTP id 16so584217fgg.17 for ; Thu, 15 Oct 2009 11:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Z8ojC5VNHjz2fpStqASppZCgktKzT1TxwiDnuHxESr8=; b=fUBhp07y7z7OicCKXOUFou6hVLTBxdOAG6xwpCeEkW/3837UA2mJc7N9EQrrhHOyEz NhINsMpG3KPt+AN7oZVJOy9kkoVvgwz0AME79pvUGvPDdYtk7AlxAKnusoaIqnlBnbDt kEZjPUFa4BVdMQ+hlLkM83/fHjlB79EXws1No= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=PW5K21EMP40fAVHRa0juIwl2KNVOKe60yuJFYc2bBI1IHBBiqWxxCA0x3mTPYmu4lh LKw05yvWKTgx8OZ8fILyNf8p3RaVqexa57CrAXtgZw1C7cnWk+AxM3+TF5Ht2urZdRus Phn1SiVfelR+lPGWmsorTBao1j472fPl149iE= Received: by 10.86.173.4 with SMTP id v4mr464900fge.78.1255630311313; Thu, 15 Oct 2009 11:11:51 -0700 (PDT) Received: from sjc-office-nat-214.mail-abuse.org (SJC-Office-NAT-214.mail-abuse.org [168.61.10.214]) by mx.google.com with ESMTPS id l19sm260883fgb.26.2009.10.15.11.11.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Oct 2009 11:11:50 -0700 (PDT) Message-ID: <4AD765E0.1070604@gmail.com> Date: Thu, 15 Oct 2009 11:11:44 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk CC: Douglas Otis , =?ISO-8859-1?Q?Alfred_H=F6nes?= , fernando@gont.com.ar, namedroppers@ops.ietf.org, tuexen@fh-muenster.de Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 10/14/09 11:24 PM, Ray.Bellis@nominet.org.uk wrote: >> This has ignored loads that might be created by bad actors with >> the goal of burdening servers. Transactions per second statements >> should also cover the level of reduction caused by credible >> attack. > > Doug, > > Indeed, that was a lab test. As Vix indrectly pointed out, a client > that fails to send FIN packets is not good for servers. > > However, 90% of the TLD authoritative servers and all but 'm' from > the root servers *already* support TCP/IP. > > And yet the DNS is not collapsing under the weight of DoS attacks > against them. Be careful with conclusions based upon TCP availability versus TCP dependence. Once DNS becomes dependent upon TCP operations as a result of increased message size and the deprecation of EDNS0 to handle these messages, then resource sharing with TCP may need adjusting. A preference for UDP and lack of dependence upon TCP could be why DNS remains functional. >> DNS is not currently dependent upon TCP, nor had DNS been designed >> to become dependent upon TCP. The fact that most CPE equipment >> does not proxy DNS over TCP should give this WG some pause about >> the economical practicality of depending upon TCP. > > The fact that very few middlebox vendors implement TCP is not, IMHO, > because of some deeply held reservations about TCP. Hell, many such > boxes proxy HTTP without any problem and that's far harder. As far as > I can tell it's simple laziness on the part of the implementors. For HTTP proxies, a critical operational requirement is sufficient memory resources. Reductions in network demand or security concerns help justify these resources. Network reductions will not occur for DNS, nor will DNS proxies improve security. The same economics that determine whether TCP is used in CPE equipment for DNS likely represents a microcosm of DNS resource economics. Needing more resources to offer the same service seems destine to produce a trade-off in reduced reliability. -Doug From owner-namedroppers@ops.ietf.org Thu Oct 15 11:52:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99DD23A6927; Thu, 15 Oct 2009 11:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JY+CgeKJxc4T; Thu, 15 Oct 2009 11:52:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9CFA83A68A9; Thu, 15 Oct 2009 11:52:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyVLk-000PAF-HF for namedroppers-data0@psg.com; Thu, 15 Oct 2009 18:46:56 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyVLb-000P9C-35 for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 18:46:54 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id D843BC2DA5; Thu, 15 Oct 2009 19:46:43 +0100 (BST) Date: Thu, 15 Oct 2009 19:45:57 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Doug Otis , Ray.Bellis@nominet.org.uk cc: Douglas Otis , =?UTF-8?Q?Alfred_H=C3=B6nes?= , fernando@gont.com.ar, namedroppers@ops.ietf.org, tuexen@fh-muenster.de, Alex Bligh Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward Message-ID: In-Reply-To: <4AD765E0.1070604@gmail.com> References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> <4AD765E0.1070604@gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 15 October 2009 11:11:44 -0700 Doug Otis wrote: > Be careful with conclusions based upon TCP availability versus TCP > dependence. Once DNS becomes dependent upon TCP operations as a result > of increased message size and the deprecation of EDNS0 to handle these > messages, then resource sharing with TCP may need adjusting. A > preference for UDP and lack of dependence upon TCP could be why DNS > remains functional. Mmmm... there seems to be a horse/cart issue here. DNS is not functional in practice, in that it does not reliable transport query responses that are needed to transmit information securely. I will avoid putting words in your mouth Doug, as I don't think you've gone this far, but if someone were to argue, "don't make tcp support server side mandatory because if everyone used it the servers might melt" (and I note the likelihood of this is not yet established), my response would be that this is like suggesting we avoid querying web-servers in case we overload them. Just like http, the DNS protocol is being asked to do more and more work per query as query sizes increase, and more queries as total users increase. Keeping the protocol crippled so it can't transmit large packets in order to avoid servers being overloaded would be a peculiar option. There may well be tweaks to TCP, tweaks to TCP parameters, or entirely new transport protocols which would be far better. However, as far as I know, they are not yet ready to deploy. Thus they aren't reasons not to make TCP support mandatory. What, beyond a warning that TCP support may lead to substantial resource requirements on servers, are you suggesting in terms of this draft (if anything)? -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Oct 15 11:56:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C88153A689A; Thu, 15 Oct 2009 11:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubJkR6hB3hen; Thu, 15 Oct 2009 11:56:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A45173A67AA; Thu, 15 Oct 2009 11:56:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyVPY-000PYn-LU for namedroppers-data0@psg.com; Thu, 15 Oct 2009 18:50:52 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyVPJ-000PXB-3W for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 18:50:48 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=oYPsvxDXn3X84L5HiJDeYT6bJTTFnUoc6xEp8c5HjtDePGv23iA37W9L 5mFEBAIhL/nDCIuaYUSeH0U0rVm7I+ZOBZElMrAQwkaf5RzUY5R1rAWbc xvNqrfS1R76t++0; 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=1255632637; x=1287168637; 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.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20draft-ietf-dnsext-dns-tcp-requirements-00=20/=20a =20way=20forward|Date:=20Thu,=2015=20Oct=202009=2019:50:3 3=20+0100|Message-ID:=20|To:=20Doug=20Ot is=20|Cc:=20Alfred=20=3D?ISO-8859- 1?Q?H=3DF6nes?=3D=20,=0D=0A=09Douglas=20Oti s=20,=0D=0A=09fernando@gont.com.ar, =0D=0A=09namedroppers@ops.ietf.org,=0D=0A=09tuexen@fh-mue nster.de|MIME-Version:=201.0|In-Reply-To:=20<4AD765E0.107 0604@gmail.com>|References:=20<48DCD05A-8C47-42D1-9500-EB 1203EDB7EE@fh-muenster.de>=20from=20Michael=20Tuexen=0D =0A=20at=20Oct=20"14,"=202009=20"07:22:32"=20pm=20<200910 141841.UAA25186@TR-Sys.de>=20=20<4AD6AB1 8.9000708@mail-abuse.org>=20=20<4AD765E0 .1070604@gmail.com>; bh=g2B+n/hdcogPEkWoqJHuDMh6dFv361J4nQI89VpQLBM=; b=EklyMHmIPRkLttFQmnS1FdNUjF9w09zx2fAHJarJAnQWBikojeO8QJqm aCWa9phT2b+BUtQCA1iNhiMMOga2xL5rOVXXwkZd2BAkkpGIcY0hpbtaE WKht/TuKca+zMk+; X-IronPort-AV: E=Sophos;i="4.44,567,1249254000"; d="scan'208";a="13684415" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 15 Oct 2009 19:50:35 +0100 In-Reply-To: <4AD765E0.1070604@gmail.com> References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> <4AD765E0.1070604@gmail.com> To: Doug Otis Cc: Alfred =?ISO-8859-1?Q?H=F6nes?= , Douglas Otis , fernando@gont.com.ar, namedroppers@ops.ietf.org, tuexen@fh-muenster.de Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 15 Oct 2009 19:50:33 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 15/10/2009 07:50:34 PM, Serialize complete at 15/10/2009 07:50:34 PM Content-Type: multipart/alternative; boundary="=_alternative 0067816380257650_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 0067816380257650_= Content-Type: text/plain; charset="US-ASCII" > Be careful with conclusions based upon TCP availability versus TCP > dependence. Once DNS becomes dependent upon TCP operations as a result > of increased message size and the deprecation of EDNS0 to handle these > messages, then resource sharing with TCP may need adjusting. A > preference for UDP and lack of dependence upon TCP could be why DNS > remains functional. I haven't actually heard anyone suggesting that we deprecate EDNS0. I don't think my draft can be interpreted as suggesting it either. *Most* of the time it works. In any event EDNS0 is currently required even in TCP to handle the DO bit. The last figures I heard from signed zones were that TCP volumes were ~1% of UDP volumes. My initial testing does suggest that that level is easily manageable, although as yet I haven't done enough testing to actually prove it. Ray --=_alternative 0067816380257650_= Content-Type: text/html; charset="US-ASCII"
> Be careful with conclusions based upon TCP availability versus TCP
> dependence. Once DNS becomes dependent upon TCP operations as a result
> of increased message size and the deprecation of EDNS0 to handle these
> messages, then resource sharing with TCP may need adjusting.  A
> preference for UDP and lack of dependence upon TCP could be why DNS
> remains functional.
I haven't actually heard anyone suggesting that we deprecate EDNS0.  I don't think my draft can be interpreted as suggesting it either.  *Most* of the time it works.  In any event EDNS0 is currently required even in TCP to handle the DO bit.

The last figures I heard from signed zones were that TCP volumes were ~1% of UDP volumes.  My initial testing does suggest that that level is easily manageable, although as yet I haven't done enough testing to actually prove it.

Ray
--=_alternative 0067816380257650_=-- From owner-namedroppers@ops.ietf.org Thu Oct 15 12:44:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363A03A6947; Thu, 15 Oct 2009 12:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=-2.131, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtz143XL4mS8; Thu, 15 Oct 2009 12:44:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 732643A690D; Thu, 15 Oct 2009 12:44:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyW9f-0003ul-Vb for namedroppers-data0@psg.com; Thu, 15 Oct 2009 19:38:31 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyW9W-0003ts-IU for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 19:38:30 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9FJbU2x019603; Thu, 15 Oct 2009 15:37:30 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200910151937.n9FJbU2x019603@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Oct 2009 15:37:29 -0400 To: Jaap Akkerhuis , Alfred =?hp-roman8?B?SM5uZXM=?= From: Olafur Gudmundsson Subject: Re: [dnsext] What is the 'canonical' spelling: RRset of RRSet ? Cc: namedroppers@ops.ietf.org In-Reply-To: <200910151735.n9FHZkZ2088921@bartok.nlnetlabs.nl> References: <200910151401.QAA27159@TR-Sys.de> <200910151735.n9FHZkZ2088921@bartok.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 13:35 15/10/2009, Jaap Akkerhuis wrote: >Alfred, > > Folks, > I need a bit of feedback for a review. > >Thanks for bringing this up. > > What is the correct/preferred spelling/capitalization from the PoV > of the list: "RRset" or "RRSet" ? > > Any opinions? > >My preference is for RRset because that is what I always use. > > jaap FWIW scanning the archives of namedroppers with: foreach i ( namedroppers.* ) foreach? echo $i foreach? grep RRset $i/* | wc foreach? grep RRSet $i/* | wc foreach? end namedroppers.199x 1056 12172 120612 48 552 4367 namedroppers.2000 48 556 4639 2 28 211 namedroppers.2001 159 2050 16458 21 248 2003 namedroppers.2002 422 4873 43979 9 118 884 namedroppers.2003 770 8831 84217 25 295 2504 namedroppers.2004 366 4349 37347 72 921 7248 namedroppers.2005 516 4780 56603 141 1776 15789 namedroppers.2006 180 2104 17631 247 2620 30338 namedroppers.2007 55 626 5450 48 577 5140 namedroppers.2008 264 3086 26183 176 2585 23184 namedroppers.2009 420 5121 48336 85 1552 12005 RRset is much more popular except RRSet seems to be more popular with the advocates of NSEC3 :-) Olafur From owner-namedroppers@ops.ietf.org Thu Oct 15 13:10:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437FF3A69BF; Thu, 15 Oct 2009 13:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2EdtzcNZI-V; Thu, 15 Oct 2009 13:10:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 672163A6405; Thu, 15 Oct 2009 13:10:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyWXh-0006MR-9E for namedroppers-data0@psg.com; Thu, 15 Oct 2009 20:03:21 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyWXT-0006JX-N1 for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 20:03:18 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=qSOrkEK148hfo3q0WmPVDSOeAQ3XPELDN7osVsb94FZQ0uP5AiCLtRpZ ySD4InKVjwlXFzPmv67Kmcz6ausa5ItGQfGlWMIpA6EmDm8eMLdQv4Xlf RsJ3zR+Xs3DQ0Z8; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1255636987; x=1287172987; 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:=20"Roy=20Arends"=20|Subject: =20Re:=20[dnsext]=20What=20is=20the=20'canonical'=20spell ing:=20RRset=20of=20RRSet=20?|Date:=20Thu,=2015=20Oct=202 009=2022:03:06=20+0200|Message-ID:=20 |To:=20Alfred=20=3D?ISO-8859-1?Q?H=3DF6nes?=3D=20|Cc:=20namedroppers@ops.ietf.org|MIME-Version:=201. 0|In-Reply-To:=20<200910151401.QAA27159@TR-Sys.de> |References:=20<200910151401.QAA27159@TR-Sys.de>; bh=GbGmoPSnW71oNwiqx5d7p3bU0ShsxLg2HS9TUZ4KAro=; b=P6Gs/SloBnjOy6s+danLjYHkxQKeW7FFi64jQ+8g+M/Z40ev3ecEAjpW /Te3rR/5LTd9LHHxeGLoZ+tdUZdH6YTr8zUHDHV6JDOs6C2AApbmrJyzD vlh3kz9nh0rJ2hG; X-IronPort-AV: E=Sophos;i="4.44,567,1249254000"; d="scan'208";a="18632183" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 15 Oct 2009 21:03:05 +0100 In-Reply-To: <200910151401.QAA27159@TR-Sys.de> References: <200910151401.QAA27159@TR-Sys.de> To: Alfred =?ISO-8859-1?Q?H=F6nes?= Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] What is the 'canonical' spelling: RRset of RRSet ? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M2_08202008 August 20, 2008 Message-ID: From: "Roy Arends" Date: Thu, 15 Oct 2009 22:03:06 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 15/10/2009 09:03:05 PM, Serialize complete at 15/10/2009 09:03:05 PM Content-Type: multipart/alternative; boundary="=_alternative 006E2609C1257650_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 006E2609C1257650_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Alfred H=F6nes wrote on 10/15/2009 04:01:37 PM: > Folks, > I need a bit of feedback for a review. >=20 > What is the correct/preferred spelling/capitalization from the PoV > of the list: "RRset" or "RRSet" ? >=20 > There's a very decided position in the IETF w.r.t. the capitalization > of other important acronyms, like "IPsec". > Do the readers of this list care similarly in the above case? >=20 > Background information usage in on selected 'important' DNS RFCs: > o "RRset" is used in RFCs 4033, 4034, 4035, and 4509; > o "RRSet" appears in RFCs 2181 and 5155. > o current DNS related I-Ds also vary; there are even drafts using both. >=20 > Any opinions? I can't believe this came up :-) This is what I wrote a wrote many moons ago: Begin forwarded message: From: Roy Arends Date: February 16, 2007 9:37:46 PM GMT+01:00 To: DNS Directorate=20 Subject: tongue in cheek weekend reading: RRSet vs RRset=20 Peter Koch and I are pondering which of the term RRSet or RRset is the=20 preferred one. In other words, should it be written with or without=20 capital 's'. Have fun reading. Dear Peter, I did a little research on what the correct notation should be. RFC 1996 introduces the term RRset, but does not explicitly define it. RFC 2136 explicitly defines RRset. RFC 2181 explicitly defines RRSet. RFC 2181 did not re-define the term RRset to RRSet, since it updates nor=20 obsoletes RFC 2136. We are left with two different acronyms that have a similar definition,=20 and we may assume that they can co-exist. However, we still have to pick=20 one for our current draft. To decide which is preferred, we simply count=20 the RFCs that use RRset and use RRSet, and we go with term that is used in = the most RFCs. Note that I did not include the obsoleted drafts in my=20 count. RRset: 1996 2136 2308 2663 2694 2874 3007 3364 3403 3833 3958 4033 4034 4035 4470 4471 4472 4509 RRSet: 2181 3123 4592 4641 4697 4795 Thats 24 RFCs, of which 18 RFCs use RRset, 6 RFCs use RRSet. This, however, is skewed. Since the 'RRset' RFCs might actually refer to=20 RFC 2181 (the 'RRSet' RFC), in which case those are completely wrong and=20 should be candidate for a -bis draft. With priority ofcourse. Since RFC=20 1996 and RFC 2136 were published before RFC 2181, I'll skip those. These=20 are in error: 2308 2874 4471 The adjusted count is now: 15 RFCs use, or should have used the term RRset, 9 RFCs use the term RRSet. This is still skewed, since some RFCs refer to both 2136 and 2181. Since=20 2181 was published later than 2136, we assume it should be leading. Those=20 RFCs are ambiguous and should be candidate for a -bis draft. With priority = ofcourse. These are in error: 2694 4033 4034 4035 4472 The adjusted count is now: 10 RFCs use, or should have used the term RRset, 14 RFCs use RRSet. But, this goes both ways. RFC 4592, which uses RRSet (defined in 2181),=20 does NOT refer to 2181, but DOES refer to 2136. This obviously and=20 blatantly wrong, and is thus candidate for a -bis document. With Priority=20 of course. The adjusted count is now: 11 RFCs use, or should have used the term RRset, 13 RFCs use, or should have used the term RRSet. There is a problem with RFC 2308 though. This RFC was previously counted=20 as wrong. RFC 2308 has RFC 2181 in the reference section, but does NOT=20 refer to 2181 in the body. Since we now have RFC 2308 with an obsolete=20 orphan reference, we must re-instate the status of RFC 2308 as using the=20 term RRset correct. The reference section needs to be updated, hence 2308=20 is still candidate for a -bis. With priority ofcourse. This now makes our count: 12 RFCs use, or should have used the term RRset, 12 RFCs use, or should have used the term RRSet. Since there is an equal count of RFCs using (or should have been using)=20 the term RRset or RRSet, this approach does not lead to a definite answer. We are now back to the question: which term is the prefered, 2136's RRset=20 or 2181's RRSet. Lets assume the choice is arbitrary, and we choose RRset from 2136. When our draft becomes an RFC, the count will then be: 13 RFCs use, or should have used the term RRset, 12 RFCs use, or should have used the term RRSet. Since most RFCs use the term RRset, I recommend that we do a 2181-bis as=20 well, after which we can -bis all RFCs that use the term RRSet, with=20 priority of course. This appears to be a lot less work compared to revving = all RFCs that use the term RRset in error. [afterword] There is one RFC that I haven't mentioned yet. RFC 2929 written by Don=20 Eastlake and Bill Manning. I have never EVER seen such an atrocity in my life, "RR Set". An extra=20 space. What were they thinking! Was the RFC just too damn short ? Is life=20 not confusing enough ? Have a good weekend :) Roy Arends ignoramus savant. --=_alternative 006E2609C1257650_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Alfred H=F6nes wrote on 10/15/2009 04:01:37 PM:

> Folks,
> I need a bit of feedback for a review.
>
> What is the correct/preferred spelling/capitalization from the PoV
> of the list:  "RRset"  or  "RRSet"  ?
>
> There's a very decided position in the IETF w.r.t. the capitalization<= br> > of other important acronyms, like "IPsec".
> Do the readers of this list care similarly in the above case?
>
> Background information usage in on selected 'important' DNS RFCs:
> o  "RRset" is used in RFCs 4033, 4034, 4035, and 4509;<= br> > o  "RRSet" appears in RFCs 2181 and 5155.
> o  current DNS related I-Ds also vary; there are even drafts using both.
>
> Any opinions?
I can't believe this came up :-)

This is what I wrote a wrote many moons ago:<= /tt>

Begin forwarded message:

From: Roy Arends <roy@dnss.ec>
Date: February 16, 2007 9:37:46 PM GMT+01:00<= /tt>
To: DNS Directorate
Subject: tongue in cheek weekend reading: RRSet vs RRset

Peter Koch and I are pondering which of the term RRS= et or RRset is the preferred one. In other words, should it be written with or without capital 's'.

Have fun reading.


Dear Peter,

I did a little research on what the correct notation should be.

RFC 1996 introduces the term RRset, but does not exp= licitly define it.
RFC 2136 explicitly defines RRset.
RFC 2181 explicitly defines RRSet.

RFC 2181 did not re-define the term RRset to RRSet, since it updates nor obsoletes RFC 2136.
We are left with two different acronyms that have a similar definition, and we may assume that they can co-exist. However, we still have to pick one for our current draft. To decide which is preferr= ed, we simply count the RFCs that use RRset and use RRSet, and we go with term that is used in the most RFCs. Note that I did not include the obsoleted drafts in my count.

RRset:
  1996 2136 2308 2663 2694 2874
  3007 3364 3403 3833 3958 4033
  4034 4035 4470 4471 4472 4509

RRSet:
  2181 3123 4592 4641 4697 4795

Thats 24 RFCs, of which

 18 RFCs use RRset,
  6 RFCs use RRSet.

This, however, is skewed. Since the 'RRset' RFCs mig= ht actually refer to RFC 2181 (the 'RRSet' RFC), in which case those are compl= etely wrong and should be candidate for a -bis draft. With priority ofcourse.  Since RFC 1996 and RFC 2136 were published before RFC 2181, I'll skip those. These are in error: 2308 2874 4471

The adjusted count is now:

 15 RFCs use, or should have used the term RRse= t,
  9 RFCs use the term RRSet.

This is still skewed, since some RFCs refer to both 2136 and 2181. Since 2181 was published later than 2136, we assume it should be leading. Those RFCs are ambiguous and should be candidate for a -bis draft. With priority ofcourse. These are in error: 2694 4033 4034 4035 4472

The adjusted count is now:

 10 RFCs use, or should have used the term RRse= t,
 14 RFCs use RRSet.

But, this goes both ways. RFC 4592, which uses RRSet (defined in 2181), does NOT refer to 2181, but DOES refer to 2136. This obviously and blatantly wrong, and is thus candidate for a -bis document. With Priority of course.

The adjusted count is now:

11 RFCs use, or should have used the term RRset,
13 RFCs use, or should have used the term RRSet.

There is a problem with RFC 2308 though. This RFC was previously counted as wrong.  RFC 2308 has RFC 2181 in the referen= ce section, but does NOT refer to 2181 in the body. Since we now have RFC 2308 with an obsolete orphan reference, we must re-instate the status of RFC 2308 as using the term RRset correct. The reference section needs to be updated, hence 2308 is still candidate for a -bis. With priority ofcours= e.

This now makes our count:

12 RFCs use, or should have used the term RRset,
12 RFCs use, or should have used the term RRSet.

Since there is an equal count of RFCs using (or shou= ld have been using) the term RRset or RRSet, this approach does not lead to a definite answer.
We are now back to the question: which term is the prefered, 2136's RRset or 2181's RRSet.

Lets assume the choice is arbitrary, and we choose RRset from 2136.

When our draft becomes an RFC, the count will then be:

13 RFCs use, or should have used the term RRset,
12 RFCs use, or should have used the term RRSet.

Since most RFCs use the term RRset, I recommend that we do a 2181-bis as well, after which we can -bis all RFCs that use the term RRSet, with priority of course. This appears to be a lot less work compared to revving all RFCs that use the term RRset in error.

[afterword]

There is one RFC that I haven't mentioned yet. RFC 2929 written by Don Eastlake and Bill Manning.

I have never EVER seen such an atrocity in my life, "RR Set". An extra space. What were they thinking! Was the RFC just too damn short ? Is life not confusing enough ?

Have a good weekend :)

Roy Arends
ignoramus savant.

--=_alternative 006E2609C1257650_=-- From owner-namedroppers@ops.ietf.org Thu Oct 15 13:39:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B99303A67F4; Thu, 15 Oct 2009 13:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.634 X-Spam-Level: X-Spam-Status: No, score=0.634 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inN9lfOXcWGX; Thu, 15 Oct 2009 13:39:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD1653A67A7; Thu, 15 Oct 2009 13:38:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyX2P-0009Fe-Oy for namedroppers-data0@psg.com; Thu, 15 Oct 2009 20:35:05 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyX2F-0009Ex-D8 for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 20:35:03 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B3DE72FE8CDC for ; Thu, 15 Oct 2009 20:34:53 +0000 (UTC) Date: Thu, 15 Oct 2009 16:34:51 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] planning draft-ietf-dnsext-rfc2672bis-dname-17 to IESG Message-ID: <20091015203450.GI6184@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, Some time ago, we had a WGLC on the draft-ietf-dnsext-rfc2672bis-dname document. There was some difficulty in getting prompt review of the document, but at the end we had a mixed message. A number of remarks came in asking for additional clarification, particularly with respect to DNSSEC. The editors have gamely tackled that problem, and have recently uploaded draft-ietf-dnsext-rfc2672bis-dname-17. I have reviewed that document, and it appears to me that the issues that cropped up last time are solved. In addition, we actually had enough reviews that supported the document that I think it is ok to go ahead. I am therefore prepared to send this on to the IESG, on the strength of previous review and the changes the editors made. In order to make sure I am not overlooking anything, I hereby ask for comments, particularly from those who raised issues during the previous WGLC, in case you still have objections to proceeding with the document. **Your silence will be construed as agreement, contrary to our usual convention** because I believe the document has addressed all the concerns raised. I plan to close this period at 17:00 EDT on 2009-10-23. If you are someone who intends to review the document once more, and cannot complete your review by then, please tell me when you can complete your review instead. It's been some time since the WGLC, and I appreciate that everyone may not be standing by waiting anxiously to review a document. (On the other hand, if you say it'll take you six months, the WG may not be able to wait so long.) After this is done, I'll post a WG summary and then, depending on the result, send the document on to the IESG. In case you wish to review the previous controversy, most of it can be found in threads following the message at http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01851.html. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From oversupplied3@93-47-10-116.ip110.fastwebnet.it Thu Oct 15 13:51:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531B428C175 for ; Thu, 15 Oct 2009 13:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -73.763 X-Spam-Level: X-Spam-Status: No, score=-73.763 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvPTM0msNygc for ; Thu, 15 Oct 2009 13:51:24 -0700 (PDT) Received: from 93-47-10-116.ip110.fastwebnet.it (93-47-10-116.ip110.fastwebnet.it [93.47.10.116]) by core3.amsl.com (Postfix) with ESMTP id BFFB428C171 for ; Thu, 15 Oct 2009 13:51:23 -0700 (PDT) Received: from 93.47.10.116 by mail.ricelake.com; Thu, 15 Oct 2009 21:51:28 +0100 Message-ID: <01ca4de1$a5f22290$740a2f5d@oversupplied3> From: "Bridgett Dickinson" To: Subject: you will get it now Date: Thu, 15 Oct 2009 21:51:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 You dont like your life? You can get best educational status now. 816 . 292 - 2839 ring us, and leave your name with number so we can call you back From owner-namedroppers@ops.ietf.org Thu Oct 15 14:17:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DC1F28C185; Thu, 15 Oct 2009 14:17:18 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWbatngnjo+q; Thu, 15 Oct 2009 14:17:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8DD0A28C0E8; Thu, 15 Oct 2009 14:17:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyXc8-000CHb-E2 for namedroppers-data0@psg.com; Thu, 15 Oct 2009 21:12:00 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyXbz-000CGu-3i for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 21:11:58 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id BC0C8CB3E8 for ; Thu, 15 Oct 2009 21:11:50 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward In-Reply-To: Your message of "Thu, 15 Oct 2009 07:24:55 +0100." References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 15 Oct 2009 21:11:50 +0000 Message-ID: <63734.1255641110@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Ray.Bellis@nominet.org.uk > Date: Thu, 15 Oct 2009 07:24:55 +0100 > ... > However, 90% of the TLD authoritative servers and all but 'm' from the > root servers *already* support TCP/IP. > > And yet the DNS is not collapsing under the weight of DoS attacks against > them. it would become so, the moment we started to depend on tcp as a primary delivery channel rather than as an occasional fallback. if you give an attacker a knob they might not twist it. if twisting the knob would make your primary service unavailable to others, then they absolutely will twist it. so i'll say again: if we *require* state, then the whole system will become more vulnerable and less robust, unless that state is defended much better than can be done with TCP as it is presently defined. From owner-namedroppers@ops.ietf.org Thu Oct 15 14:39:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8329D3A62C1; Thu, 15 Oct 2009 14:39:35 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVkaYNnRZzsX; Thu, 15 Oct 2009 14:39:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B07EC3A68ED; Thu, 15 Oct 2009 14:39:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyXzW-000FNc-V6 for namedroppers-data0@psg.com; Thu, 15 Oct 2009 21:36:10 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyXzN-000FLn-AS for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 21:36:08 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0C490CB3F8 for ; Thu, 15 Oct 2009 21:36:01 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] What is the 'canonical' spelling: RRset of RRSet ? In-Reply-To: Your message of "Thu, 15 Oct 2009 13:15:59 -0400." <1028365c0910151015n3e17a78cx6fe154f3ed37299e@mail.gmail.com> References: <200910151401.QAA27159@TR-Sys.de> <20091015153914.GC6184@shinkuro.com> <1028365c0910151015n3e17a78cx6fe154f3ed37299e@mail.gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 15 Oct 2009 21:36:01 +0000 Message-ID: <64915.1255642561@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Thu, 15 Oct 2009 13:15:59 -0400 > From: Donald Eastlake > > > I admit to a strong personal bias in favour of "RRset". > > +1 also +1. as a bonus, here's some historical background on the term itself. RFC 2136 was the first time the atomicity of resource record sets denoted by was made explicit, because it was very important to the operation of the DNS UPDATE protocol. i coined the term "RRset" for RFC 2136 but the atomicity itself was always implicit in RFC 1034 and 1035, so it was not new information. BIND itself wasn't as strict about resource record set atomicity until version 4.9 -- which was the first release i had a hand in -- and so it was a hot topic for me personally during the production of RFC 2136. an early draft of DNS UPDATE attempted to make updates on a per-RR basis, and DNS IXFR as far as i know still does so. From owner-namedroppers@ops.ietf.org Thu Oct 15 15:56:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1A5028C182; Thu, 15 Oct 2009 15:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.284 X-Spam-Level: X-Spam-Status: No, score=-1.284 tagged_above=-999 required=5 tests=[AWL=-0.789, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gl-yITNiXVhN; Thu, 15 Oct 2009 15:55:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E67D3A67AE; Thu, 15 Oct 2009 15:55:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyZ91-000KzI-Mu for namedroppers-data0@psg.com; Thu, 15 Oct 2009 22:50:03 +0000 Received: from [209.85.220.222] (helo=mail-fx0-f222.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyZ8s-000KyE-6c for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 22:50:01 +0000 Received: by fxm22 with SMTP id 22so1678049fxm.12 for ; Thu, 15 Oct 2009 15:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=KwUD82MAnVeCYcr4EI1sfnCi3wKQGeCAULmZIbMa2Xc=; b=Y0u76LD9imOZOt2deqkZk5Nr21bPlshtLQvb7SPzZM4NLOI6BuTsKXdVJcx5aDxfda mhUa/H2D62ygUSGK3jdN0teVv+iWOkg8ovZYi5R4UVZMRY37IKud5kW1y+pt/y43lnWr ecqP+I2rcTejYZz4IEC/VPAOvEOHGREw0EeJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=exFxvJ0Pg175I+FDL0X+6itdp/csYRyyQWF3XMc5S5WK3Wx52XvOWv/nm9eLIuWOni ePzOMQu5oLdDqXk7fp3eFnxoQO3479qXL/Xhl0DUa8b0y4ljCM6mvUNDhOotq6t+xnrE 0hgALSHCJDCOveyN8s9++PT+Gkm4y+JimRbYs= Received: by 10.204.7.204 with SMTP id e12mr553351bke.117.1255646992854; Thu, 15 Oct 2009 15:49:52 -0700 (PDT) Received: from sjc-office-nat-214.mail-abuse.org (SJC-Office-NAT-214.mail-abuse.org [168.61.10.214]) by mx.google.com with ESMTPS id 9sm796377fks.4.2009.10.15.15.49.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Oct 2009 15:49:52 -0700 (PDT) Message-ID: <4AD7A709.4040600@gmail.com> Date: Thu, 15 Oct 2009 15:49:45 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk CC: =?ISO-8859-1?Q?Alfred_H=F6nes?= , Douglas Otis , fernando@gont.com.ar, namedroppers@ops.ietf.org, tuexen@fh-muenster.de Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> <4AD765E0.1070604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 10/15/09 11:50 AM, Ray.Bellis@nominet.org.uk wrote: > > > Be careful with conclusions based upon TCP availability versus TCP > > dependence. Once DNS becomes dependent upon TCP operations as a result > > of increased message size and the deprecation of EDNS0 to handle these > > messages, then resource sharing with TCP may need adjusting. A > > preference for UDP and lack of dependence upon TCP could be why DNS > > remains functional. > > I haven't actually heard anyone suggesting that we deprecate EDNS0. I > don't think my draft can be interpreted as suggesting it either. *Most* > of the time it works. In any event EDNS0 is currently required even in > TCP to handle the DO bit. Sorry, the deprecation of large frames to handle UDP for DNSSEC. This might be the result when EDNS0/UDP exploitation grows worse as DNSSEC becomes prevalent. > The last figures I heard from signed zones were that TCP volumes were > ~1% of UDP volumes. My initial testing does suggest that that level is > easily manageable, although as yet I haven't done enough testing to > actually prove it. The impetus for a TCP mandate is to offer an assured alternative to UDP when handling larger frames. The percentage of systems dependent upon TCP might then change dramatically, especially if UDP proves problematic with these larger frames. Mandating TCP support implies TCP will remain dependable. If or when TCP becomes prominently used for general queries in support of DNSSEC, DNS reliability will have been significantly eroded. Only transports able to sustain the DNS service when faced with abuse should be mandated and thereby assured. It will not benefit TCP to have its API dramatically changed, or to have it defined as an object rather than a byte stream. There are other transports in use for nearly a decade able to fulfill this role by offering unreliable unordered delivery of objects. This allows server state to exclude in-flight data and to be limited to socket tuples, tags, and object counts following a cookie exchange. The cookie exchange is needed as insurance against reflected attacks without reliance upon BCP38. -Doug From owner-namedroppers@ops.ietf.org Thu Oct 15 16:17:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04CCF3A67E2; Thu, 15 Oct 2009 16:17:19 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhN8otaAU7It; Thu, 15 Oct 2009 16:17:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1BADA3A683B; Thu, 15 Oct 2009 16:17:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyZVg-000Mjm-DX for namedroppers-data0@psg.com; Thu, 15 Oct 2009 23:13:28 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyZVV-000Mit-Ss for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 23:13:26 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id C3588E601C; Thu, 15 Oct 2009 23:13:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n9FNDCNG031967; Fri, 16 Oct 2009 10:13:14 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200910152313.n9FNDCNG031967@drugs.dv.isc.org> To: Paul Vixie Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> <63734.1255641110@nsa.vix.com> Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward In-reply-to: Your message of "Thu, 15 Oct 2009 21:11:50 -0000." <63734.1255641110@nsa.vix.com> Date: Fri, 16 Oct 2009 10:13:12 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <63734.1255641110@nsa.vix.com>, Paul Vixie writes: > > From: Ray.Bellis@nominet.org.uk > > Date: Thu, 15 Oct 2009 07:24:55 +0100 > > ... > > However, 90% of the TLD authoritative servers and all but 'm' from the > > root servers *already* support TCP/IP. > > > > And yet the DNS is not collapsing under the weight of DoS attacks against > > them. > > it would become so, the moment we started to depend on tcp as a primary > delivery channel rather than as an occasional fallback. if you give an > attacker a knob they might not twist it. if twisting the knob would make > your primary service unavailable to others, then they absolutely will twist > it. so i'll say again: if we *require* state, then the whole system will > become more vulnerable and less robust, unless that state is defended much > better than can be done with TCP as it is presently defined. What people are demanding is that the occasional fallback channel actually be available when it is needed. That is a reasonable requirement. There are too many lazy vendors in the DNS marketplace, we wouldn't have the problems we do with load balancers and proxies if the vendors were actually conscientious and looked at the RFCs. As far as I can tell both classes of vendor just looked at the packets usually on the wire and said that's all we need to support and forgot about the rest. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Thu Oct 15 16:17:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E79C3A6811; Thu, 15 Oct 2009 16:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.249 X-Spam-Level: X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[AWL=0.744, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3NoJHjPUAKF; Thu, 15 Oct 2009 16:17:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CDD843A67E2; Thu, 15 Oct 2009 16:17:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyZWT-000MnG-Lx for namedroppers-data0@psg.com; Thu, 15 Oct 2009 23:14:17 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyZWK-000Mm0-3r for namedroppers@ops.ietf.org; Thu, 15 Oct 2009 23:14:15 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 398C3C2DA5; Fri, 16 Oct 2009 00:14:04 +0100 (BST) Date: Fri, 16 Oct 2009 00:13:18 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Doug Otis , Ray.Bellis@nominet.org.uk cc: =?UTF-8?Q?Alfred_H=C3=B6nes?= , Douglas Otis , fernando@gont.com.ar, namedroppers@ops.ietf.org, tuexen@fh-muenster.de, Alex Bligh Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward Message-ID: <67F2A7EB27FCA04C582C59B9@Ximines.local> In-Reply-To: <4AD7A709.4040600@gmail.com> References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> <4AD765E0.1070604@gmail.com> <4AD7A709.4040600@gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 15 October 2009 15:49:45 -0700 Doug Otis wrote: > Sorry, the deprecation of large frames to handle UDP for DNSSEC. This > might be the result when EDNS0/UDP exploitation grows worse as DNSSEC > becomes prevalent. May be the draft should make clear that UDP is still mandated as well. I can't really see why TCP would be used in preference to UDP when there is no middlebox in the way. Even if all middleboxen were evil, and can't be worked around (e.g. through proxy-bypass), recursive servers would still use UDP to make their recursive queries, so I would not expect TCP load on authoritative servers to increase nearly as much. Clients of recursive servers can presumably take advantage of persistent connections (and recursive servers can favour clients that do so). -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Oct 15 20:27:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815523A684E; Thu, 15 Oct 2009 20:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5 tests=[AWL=-0.631, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBs3yhuO6KtH; Thu, 15 Oct 2009 20:27:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 75F4E3A6835; Thu, 15 Oct 2009 20:27:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MydN2-000GJx-Uw for namedroppers-data0@psg.com; Fri, 16 Oct 2009 03:20:48 +0000 Received: from [209.85.219.207] (helo=mail-ew0-f207.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MydMt-000GJN-5v for namedroppers@ops.ietf.org; Fri, 16 Oct 2009 03:20:47 +0000 Received: by ewy3 with SMTP id 3so1104482ewy.41 for ; Thu, 15 Oct 2009 20:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=RSSytDQ8vLcop01VftH4EpPXm623eSR1icIA8bdL6pY=; b=UXptamHamCYiB/E1T4M1zY+tgFPLPvROw2d4TdS1jUqCB/4lfdi8sPdzYQSeM33ZW1 4m9jICSxmHsa5yOdCMwi4S01ysb1qgDSdP+lG7IAKq9B7KmSdFJNnO/rxIfvh7iUMZYG OK00BgVLwcS8tweQXA5hxrBmAeeanNFfJmZx4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=aI+OskHhx7d4shiWc2kH2Nem29HdJpQ8GDH29C44Gw8SALK8zO+y0d39BHOBH1Wqdr YWqnQjJe4QDLW9K6QoSgapDtLZ5fBO5ZRUWhFwXSQ2NOkzfuOM31vyWmP2qbgjJpquYa 6pd8yhYYx/dmexsn0KbENGSiRPIvJreC3vGQI= Received: by 10.211.147.10 with SMTP id z10mr228326ebn.28.1255663237635; Thu, 15 Oct 2009 20:20:37 -0700 (PDT) Received: from sjc-office-nat-214.mail-abuse.org (SJC-Office-NAT-214.mail-abuse.org [168.61.10.214]) by mx.google.com with ESMTPS id 5sm1626939eyh.33.2009.10.15.20.20.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Oct 2009 20:20:36 -0700 (PDT) Message-ID: <4AD7E680.80500@gmail.com> Date: Thu, 15 Oct 2009 20:20:32 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Alex Bligh CC: Ray.Bellis@nominet.org.uk, =?ISO-8859-1?Q?Alfred_H=F6nes?= , Douglas Otis , fernando@gont.com.ar, namedroppers@ops.ietf.org, tuexen@fh-muenster.de Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> <4AD765E0.1070604@gmail.com> <4AD7A709.4040600@gmail.com> <67F2A7EB27FCA04C582C59B9@Ximines.local> In-Reply-To: <67F2A7EB27FCA04C582C59B9@Ximines.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 10/15/09 4:13 PM, Alex Bligh wrote: > --On 15 October 2009 15:49:45 -0700 Doug Otis > wrote: > >> Sorry, the deprecation of large frames to handle UDP for DNSSEC. This >> might be the result when EDNS0/UDP exploitation grows worse as DNSSEC >> becomes prevalent. > > May be the draft should make clear that UDP is still mandated as well. A UDP mandate to handle what exactly? Should EDNS0/UDP be required to handle 1280, 1480, 4096, 8192, 9216 or perhaps 64k bytes? What minimum frame size is required to dissuade TCP use in an era of DNSSEC? What happens when reflected attacks cause large DNS UDP frame support to be dropped, especially after TCP support has been mandated? Mandating TCP support for DNS will be misleading, as this suggests TCP represents a suitable replacement for UDP. It does not. It would also be wrong to insist TCP represents a suitable replacement for UDP simply because it will only be used in a small percentage of the transactions. Any such assumption is likely to be proved wildly inaccurate in short order. Especially when the costs of TCP resources are much less for consumers than for those attempting to retain a robust service. > I can't really see why TCP would be used in preference to UDP when there > is no middlebox in the way. Even if all middleboxen were evil, and can't > be worked around (e.g. through proxy-bypass), recursive servers would > still use UDP to make their recursive queries, so I would not expect > TCP load on authoritative servers to increase nearly as much. There are DNS reflected attacks being staged that take out multiple OC192 connections. This type of threat with the introduction of DNSSEC may play a role in the deprecation of large frame UDP DNS. After all, a mandate for TCP implies there is no reason to be concerned. Just use TCP right? > Clients of recursive servers can presumably take advantage of > persistent connections (and recursive servers can favour clients > that do so). TCP servers will still be required to retain unacknowledged data, where persistence does not seem to help in reducing this exposure. TCP takes DNS in the wrong direction. -Doug From owner-namedroppers@ops.ietf.org Thu Oct 15 21:09:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 142F328C170; Thu, 15 Oct 2009 21:09:55 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdRcdMWbDd01; Thu, 15 Oct 2009 21:09:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1FC3E3A691E; Thu, 15 Oct 2009 21:09:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mye2A-000JW5-Kd for namedroppers-data0@psg.com; Fri, 16 Oct 2009 04:03:18 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mye21-000JUx-8e for namedroppers@ops.ietf.org; Fri, 16 Oct 2009 04:03:16 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 822E3E6056; Fri, 16 Oct 2009 04:03:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n9G430Gn035121; Fri, 16 Oct 2009 15:03:01 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200910160403.n9G430Gn035121@drugs.dv.isc.org> To: Doug Otis Cc: Alex Bligh , Ray.Bellis@nominet.org.uk, =?ISO-8859-1?Q?Alfred_H=F6nes?= , Douglas Otis , fernando@gont.com.ar, namedroppers@ops.ietf.org, tuexen@fh-muenster.de From: Mark Andrews References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> <4AD765E0.1070604@gmail.com> <4AD7A709.4040600@gmail.com> <67F2A7EB27FCA04C582C59B9@Ximines.local> <4AD7E680.80500@gmail.com> Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward In-reply-to: Your message of "Thu, 15 Oct 2009 20:20:32 PDT." <4AD7E680.80500@gmail.com> Date: Fri, 16 Oct 2009 15:03:00 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4AD7E680.80500@gmail.com>, Doug Otis writes: > On 10/15/09 4:13 PM, Alex Bligh wrote: > > --On 15 October 2009 15:49:45 -0700 Doug Otis > > wrote: > > > >> Sorry, the deprecation of large frames to handle UDP for DNSSEC. This > >> might be the result when EDNS0/UDP exploitation grows worse as DNSSEC > >> becomes prevalent. > > > > May be the draft should make clear that UDP is still mandated as well. > > A UDP mandate to handle what exactly? Should EDNS0/UDP be required to > handle 1280, 1480, 4096, 8192, 9216 or perhaps 64k bytes? What minimum > frame size is required to dissuade TCP use in an era of DNSSEC? What > happens when reflected attacks cause large DNS UDP frame support to be > dropped, especially after TCP support has been mandated? > > Mandating TCP support for DNS will be misleading, as this suggests TCP > represents a suitable replacement for UDP. No. It doesn't. It reflects the reality TCP has always been required by general purpose resolvers not operating in a highly controlled environment that prohibited UDP responses that exceed 512 bytes. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Thu Oct 15 21:50:38 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C4B3A6877; Thu, 15 Oct 2009 21:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB4Pqb3jOanB; Thu, 15 Oct 2009 21:50:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CDF1D3A67E1; Thu, 15 Oct 2009 21:50:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyehD-0000J5-U2 for namedroppers-data0@psg.com; Fri, 16 Oct 2009 04:45:43 +0000 Received: from [209.85.221.193] (helo=mail-qy0-f193.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Myeh3-0000Ht-Uw for namedroppers@ops.ietf.org; Fri, 16 Oct 2009 04:45:41 +0000 Received: by qyk31 with SMTP id 31so1208622qyk.9 for ; Thu, 15 Oct 2009 21:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=qbXIHXBWdZNuhDwXxXbtoJX7MR+i4PK88/KIaseGWKk=; b=HnwiM5OcH7STSSCzwv6jl50MOQ6kBufrzQVnbU3Jxw5jL+CgdjInAxp47+pYFuGzoF 3gZLEFN26pVuUqYrp6y5DHJNK8makglpGpcaC8lXlAq/Poz2TWyz08CfTU0TnZXbj3D5 4KS6GTrleEv4F7IGfkhZxfmoxZ4X3Fo6jL8tA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=gt9+Op24fPl4eV63BZi9Kex2kEQxG4VXIE+9Q2htRQgwjEMmBJZecUPL/rRXpZ1/hF 66A8o/Jd7H+frDQMagwfCcjpVyxEhne1gG1nxeYAzLS2BofxML0GLoppr8Wd7J98noub Nl6hVRDoN/tT1lWQ8bY36ibjg2zvUGAs5SoTQ= Received: by 10.224.127.12 with SMTP id e12mr734226qas.275.1255668333272; Thu, 15 Oct 2009 21:45:33 -0700 (PDT) Received: from sjc-office-nat-214.mail-abuse.org (SJC-Office-NAT-214.mail-abuse.org [168.61.10.214]) by mx.google.com with ESMTPS id 2sm1462609qwi.47.2009.10.15.21.45.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Oct 2009 21:45:32 -0700 (PDT) Message-ID: <4AD7FA69.5050309@gmail.com> Date: Thu, 15 Oct 2009 21:45:29 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Mark Andrews CC: Alex Bligh , Ray.Bellis@nominet.org.uk, =?UTF-8?B?QWxmcmVkIEjDtm5lcw==?= , Douglas Otis , fernando@gont.com.ar, namedroppers@ops.ietf.org, tuexen@fh-muenster.de Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> <4AD765E0.1070604@gmail.com> <4AD7A709.4040600@gmail.com> <67F2A7EB27FCA04C582C59B9@Ximines.local> <4AD7E680.80500@gmail.com> <200910160403.n9G430Gn035121@drugs.dv.isc.org> In-Reply-To: <200910160403.n9G430Gn035121@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 10/15/09 9:03 PM, Mark Andrews wrote: > In message<4AD7E680.80500@gmail.com>, Doug Otis writes: > >> Mandating TCP support for DNS will be misleading, as this suggests TCP >> represents a suitable replacement for UDP. > > No. It doesn't. It reflects the reality TCP has always been required > by general purpose resolvers not operating in a highly controlled > environment that prohibited UDP responses that exceed 512 bytes. Mark, TCP is _not_ always required. -Doug From owner-namedroppers@ops.ietf.org Thu Oct 15 22:24:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B52D33A689A; Thu, 15 Oct 2009 22:24:31 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3-FtXvDpa64; Thu, 15 Oct 2009 22:24:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E431F3A6782; Thu, 15 Oct 2009 22:24:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyfF7-000DVs-MP for namedroppers-data0@psg.com; Fri, 16 Oct 2009 05:20:45 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyfEx-000DPZ-Nu for namedroppers@ops.ietf.org; Fri, 16 Oct 2009 05:20:43 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 8C645E601C; Fri, 16 Oct 2009 05:20:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n9G5KSH4036106; Fri, 16 Oct 2009 16:20:29 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200910160520.n9G5KSH4036106@drugs.dv.isc.org> To: Doug Otis Cc: Alex Bligh , Ray.Bellis@nominet.org.uk, =?UTF-8?B?QWxmcmVkIEjDtm5lcw==?= , Douglas Otis , fernando@gont.com.ar, namedroppers@ops.ietf.org, tuexen@fh-muenster.de From: Mark Andrews References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> <4AD765E0.1070604@gmail.com> <4AD7A709.4040600@gmail.com> <67F2A7EB27FCA04C582C59B9@Ximines.local> <4AD7E680.80500@gmail.com> <200910160403.n9G430Gn035121@drugs.dv.isc.org> <4AD7FA69.5050309@gmail.com> Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward In-reply-to: Your message of "Thu, 15 Oct 2009 21:45:29 PDT." <4AD7FA69.5050309@gmail.com> Date: Fri, 16 Oct 2009 16:20:28 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4AD7FA69.5050309@gmail.com>, Doug Otis writes: > On 10/15/09 9:03 PM, Mark Andrews wrote: > > In message<4AD7E680.80500@gmail.com>, Doug Otis writes: > > > >> Mandating TCP support for DNS will be misleading, as this suggests TCP > >> represents a suitable replacement for UDP. > > > > No. It doesn't. It reflects the reality TCP has always been required > > by general purpose resolvers not operating in a highly controlled > > environment that prohibited UDP responses that exceed 512 bytes. > > Mark, > > TCP is _not_ always required. > > -Doug Please re-read what I said. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From somewaynj80@93-42-173-54.ip87.fastwebnet.it Fri Oct 16 00:09:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592343A68F9 for ; Fri, 16 Oct 2009 00:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.514 X-Spam-Level: X-Spam-Status: No, score=-14.514 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_SPEC_ROLEX=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv7sskglI1dR for ; Fri, 16 Oct 2009 00:09:09 -0700 (PDT) Received: from 93-42-173-54.ip87.fastwebnet.it (93-42-173-54.ip87.fastwebnet.it [93.42.173.54]) by core3.amsl.com (Postfix) with ESMTP id D75F63A6983 for ; Fri, 16 Oct 2009 00:09:08 -0700 (PDT) Received: from 93.42.173.54 by mail.revolvergroup.com; Fri, 16 Oct 2009 08:09:13 +0100 Message-ID: <01ca4e37$f2d825e0$36ad2a5d@somewaynj80> From: "Opal Vogt" To: Subject: upto 75% off on rolex. Date: Fri, 16 Oct 2009 08:09:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Now you will love your xmas and thanskgiving http://boxround.com From owner-namedroppers@ops.ietf.org Fri Oct 16 00:39:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45ADC3A67DA; Fri, 16 Oct 2009 00:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.898 X-Spam-Level: X-Spam-Status: No, score=-3.898 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C32eLQAICKmF; Fri, 16 Oct 2009 00:39:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C28FC3A697C; Fri, 16 Oct 2009 00:39:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyhIy-000BOy-Om for namedroppers-data0@psg.com; Fri, 16 Oct 2009 07:32:52 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyhIm-000BNC-5F; Fri, 16 Oct 2009 07:32:50 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=1SuKSjgoxyVBV1lmCplF/M+i7Mj6pZfDH2kz5FaIL66cK4c9YfNeXFl4 08vASMn9RgyE23bcRvSNhG/bVoKZ4MrfFsvn+52YAaEwjKSny0kNKu1oK 4Md8kj1PQdSlYyz; 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=1255678360; x=1287214360; 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.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20draft-ietf-dnsext-dns-tcp-requirements-00=20/=20a =20way=20forward|Date:=20Fri,=2016=20Oct=202009=2008:32:3 6=20+0100|Message-ID:=20|To:=20Mark=20An drews=20|Cc:=20namedroppers@ops.ietf.org, =0D=0A=09owner-namedroppers@ops.ietf.org,=0D=0A=09Paul=20 Vixie=20|MIME-Version:=201.0|In-Reply-To: =20<200910152313.n9FNDCNG031967@drugs.dv.isc.org> |References:=20<48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-m uenster.de>=20from=20Michael=20Tuexen=0D=0A=20at=20Oct=20 "14,"=202009=20"07:22:32"=20pm=20<200910141841.UAA25186@T R-Sys.de>=20=20<4AD6AB18.9000708@mail-ab use.org>=20=20<63734.1255641110@nsa.vix. com>=20<200910152313.n9FNDCNG031967@drugs.dv.isc.org>; bh=KsPyFlE76XG1/EVOuGsQ0ocTMkYMr+6lyFbRKVNO/50=; b=c+ZgCL+NcPE9PB5eqgywnjue+QsJDHJDhImXc+zBKsjYayQjU+BYi3JT pC6JYGuLZkByrvnO1Mn0MM2xSV/zWentk+tKEhNZozW5JWX49+KKZOuWC 9doyrZoBUxjGJiP; X-IronPort-AV: E=Sophos;i="4.44,571,1249254000"; d="scan'208";a="18637550" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 16 Oct 2009 08:32:37 +0100 In-Reply-To: <200910152313.n9FNDCNG031967@drugs.dv.isc.org> References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> <63734.1255641110@nsa.vix.com> <200910152313.n9FNDCNG031967@drugs.dv.isc.org> To: Mark Andrews Cc: namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org, Paul Vixie Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 16 Oct 2009 08:32:36 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 16/10/2009 08:32:37 AM, Serialize complete at 16/10/2009 08:32:37 AM Content-Type: multipart/alternative; boundary="=_alternative 0029701080257651_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 0029701080257651_= Content-Type: text/plain; charset="US-ASCII" > What people are demanding is that the occasional fallback channel > actually be available when it is needed. That is a reasonable > requirement. Absolutely. For _most_ large authoritative and presumably recursive installations TCP is already there. This draft is trying to catch the edge cases, and is very unlikely _on it's own_ to make any significant difference to TCP query volumes. > There are too many lazy vendors in the DNS marketplace, we wouldn't > have the problems we do with load balancers and proxies if the > vendors were actually conscientious and looked at the RFCs. > > As far as I can tell both classes of vendor just looked at the > packets usually on the wire and said that's all we need to support > and forgot about the rest. That's exactly my view as well. Ray --=_alternative 0029701080257651_= Content-Type: text/html; charset="US-ASCII"
> What people are demanding is that the occasional fallback channel
> actually be available when it is needed.  That is a reasonable
> requirement.
Absolutely.  For _most_ large authoritative and presumably recursive installations TCP is already there.  This draft is trying to catch the edge cases, and is very unlikely _on it's own_ to make any significant difference to TCP query volumes.
 
> There are too many lazy vendors in the DNS marketplace, we wouldn't
> have the problems we do with load balancers and proxies if the
> vendors were actually conscientious and looked at the RFCs.
>
> As far as I can tell both classes of vendor just looked at the
> packets usually on the wire and said that's all we need to support
> and forgot about the rest.
That's exactly my view as well.

Ray
--=_alternative 0029701080257651_=-- From owner-namedroppers@ops.ietf.org Fri Oct 16 00:51:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC333A6989; Fri, 16 Oct 2009 00:51:13 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auDtCbmqBzOJ; Fri, 16 Oct 2009 00:51:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3CCB63A68F9; Fri, 16 Oct 2009 00:51:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyhXW-000CUB-T5 for namedroppers-data0@psg.com; Fri, 16 Oct 2009 07:47:54 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyhXN-000CT5-92 for namedroppers@ops.ietf.org; Fri, 16 Oct 2009 07:47:52 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id EA7E4CB4A6 for ; Fri, 16 Oct 2009 07:47:44 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward In-Reply-To: Your message of "Fri, 16 Oct 2009 08:32:36 +0100." References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> <63734.1255641110@nsa.vix.com> <200910152313.n9FNDCNG031967@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 16 Oct 2009 07:47:44 +0000 Message-ID: <90171.1255679264@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Ray.Bellis@nominet.org.uk > Date: Fri, 16 Oct 2009 08:32:36 +0100 > > > What people are demanding is that the occasional fallback channel > > actually be available when it is needed. That is a reasonable > > requirement. > > Absolutely. For _most_ large authoritative and presumably recursive > installations TCP is already there. This draft is trying to catch the > edge cases, and is very unlikely _on it's own_ to make any significant > difference to TCP query volumes. does the current draft make it clear that tcp is (and has always been) mandatory AND that it is (and has always been) a backup or secondary transport (after UDP/EDNS)? if so then i withdraw any objection i was thinking i might have to it. > > There are too many lazy vendors in the DNS marketplace, we wouldn't > > have the problems we do with load balancers and proxies if the vendors > > were actually conscientious and looked at the RFCs. > > > > As far as I can tell both classes of vendor just looked at the packets > > usually on the wire and said that's all we need to support and forgot > > about the rest. > > That's exactly my view as well. and mine. From owner-namedroppers@ops.ietf.org Fri Oct 16 01:04:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA3B3A68F9; Fri, 16 Oct 2009 01:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.823 X-Spam-Level: X-Spam-Status: No, score=-3.823 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf30BB9c9Fvh; Fri, 16 Oct 2009 01:04:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 596B03A6874; Fri, 16 Oct 2009 01:04:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Myhih-000DQ9-6R for namedroppers-data0@psg.com; Fri, 16 Oct 2009 07:59:27 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MyhiU-000DP7-L8 for namedroppers@ops.ietf.org; Fri, 16 Oct 2009 07:59:24 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=HyLeEUknvOnuzFGuZO6+GCth8Hr6B1Ck92MY8T9UzVZhKrf/JB9bYT9c a3Gaj4awqwabs/KcLnyoQoxbmlopp3LdKnh3D5xWmEgbjNw3+MXgVdpgO q49G+5Ep28LnLC7; 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=1255679954; x=1287215954; 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.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20draft-ietf-dnsext-dns-tcp-requirements-00=20/=20a =20way=20forward|Date:=20Fri,=2016=20Oct=202009=2008:59:1 2=20+0100|Message-ID:=20|To:=20Paul=20Vi xie=20|Cc:=20namedroppers@ops.ietf.org |MIME-Version:=201.0|In-Reply-To:=20<63734.1255641110@nsa .vix.com>|References:=20<48DCD05A-8C47-42D1-9500-EB1203ED B7EE@fh-muenster.de>=20from=20Michael=20Tuexen=0D=0A=20at =20Oct=20"14,"=202009=20"07:22:32"=20pm=20<200910141841.U AA25186@TR-Sys.de>=20=20<4AD6AB18.900070 8@mail-abuse.org>=20=20=20<63734.1255641 110@nsa.vix.com>; bh=DY8ZC8NqblHYPODTv/UgwShTWnOesw3bTu7tzGAdHwo=; b=dHtH+XK3U6OcCengF27Omof3ptJDLhhe1lrAOanJqJCwaydaQMHOeMI4 5jaXTQIhzOcupT5Q8VqhE9VWfeyYCSb5MdLSm0Xhrbx2uLDEvvmBHSACs jmtqyvB73BbuUH/; X-IronPort-AV: E=Sophos;i="4.44,571,1249254000"; d="scan'208";a="18637898" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 16 Oct 2009 08:59:12 +0100 In-Reply-To: <63734.1255641110@nsa.vix.com> References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> <63734.1255641110@nsa.vix.com> To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 16 Oct 2009 08:59:12 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 16/10/2009 08:59:12 AM, Serialize complete at 16/10/2009 08:59:12 AM Content-Type: multipart/alternative; boundary="=_alternative 002BDF3280257651_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 002BDF3280257651_= Content-Type: text/plain; charset="US-ASCII" > it would become so, the moment we started to depend on tcp as a primary > delivery channel rather than as an occasional fallback. I'm not proposing that it become the primary channel, although if it helps I might considering watering down the "you don't always have to do UDP first" section. > if you give an > attacker a knob they might not twist it. if twisting the knob would make > your primary service unavailable to others, then they absolutely will twist > it. so i'll say again: if we *require* state, then the whole system will > become more vulnerable and less robust, unless that state is defended much > better than can be done with TCP as it is presently defined. I'll say again: that knob is _already_ available to twist on the vast majority of DNS installations. The vendors of their software (mostly ISC BIND, of course) and their operators already know how to read RFCs and support TCP by default. It's the middleboxes sat in the path and other minority edge cases that I'm interested in. Ray --=_alternative 002BDF3280257651_= Content-Type: text/html; charset="US-ASCII"
> it would become so, the moment we started to depend on tcp as a primary
> delivery channel rather than as an occasional fallback.

I'm not proposing that it become the primary channel, although if it helps I might considering watering down the "you don't always have to do UDP first" section.

> if you give an
> attacker a knob they might not twist it.  if twisting the knob would make
> your primary service unavailable to others, then they absolutely will twist
> it.  so i'll say again: if we *require* state, then the whole system will
> become more vulnerable and less robust, unless that state is defended much
> better than can be done with TCP as it is presently defined.
I'll say again: that knob is _already_ available to twist on the vast majority of DNS installations.  The vendors of their software (mostly ISC BIND, of course) and their operators already know how to read RFCs and support TCP by default.

It's the middleboxes sat in the path and other minority edge cases that I'm interested in.

Ray
--=_alternative 002BDF3280257651_=-- From owner-namedroppers@ops.ietf.org Fri Oct 16 01:10:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258A93A6989; Fri, 16 Oct 2009 01:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cLnX1KFXU4z; Fri, 16 Oct 2009 01:10:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E219F3A67DA; Fri, 16 Oct 2009 01:10:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Myhp3-000Dwa-A8 for namedroppers-data0@psg.com; Fri, 16 Oct 2009 08:06:01 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Myhot-000Dvm-KF for namedroppers@ops.ietf.org; Fri, 16 Oct 2009 08:05:59 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=lL/GKTXRva1IVG8eqXrMPxYfxbytx7poKf08VJNyLlRo4V/yEBNjiYkK BOlt3aSH5SG9mZFjsXbyRRaDgw6JnBMkGgbDA+jtBgIg7S/Xn1e82os+t XJyYcJesM1spt7/; 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=1255680351; x=1287216351; 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.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20draft-ietf-dnsext-dns-tcp-requirements-00=20/=20a =20way=20forward|Date:=20Fri,=2016=20Oct=202009=2009:05:4 9=20+0100|Message-ID:=20|To:=20Paul=20Vi xie=20|Cc:=20namedroppers@ops.ietf.org |MIME-Version:=201.0|In-Reply-To:=20<90171.1255679264@nsa .vix.com>|References:=20<48DCD05A-8C47-42D1-9500-EB1203ED B7EE@fh-muenster.de>=20from=20Michael=20Tuexen=0D=0A=20at =20Oct=20"14,"=202009=20"07:22:32"=20pm=20<200910141841.U AA25186@TR-Sys.de>=20=20<4AD6AB18.900070 8@mail-abuse.org>=20=20<63734.1255641110 @nsa.vix.com>=20<200910152313.n9FNDCNG031967@drugs.dv.isc .org>=20=20=20<90171.1255679264@nsa.vix. com>; bh=AwlrVEAew0fYC7YeBpsIID5NlbnOApPf7ryjv3lhDy0=; b=V5w6+rrLmgvSOJDwIALV3K9Sh3pjWi8KwoJSYMRem7i7s6jSJIVwwCEI F27q0t56BZlvRszAoFGoBmXnhZ0uA8Kd5b/QP4iHnkaSwFboWjH4HOo2B RL/FDr9ee4U9JbH; X-IronPort-AV: E=Sophos;i="4.44,571,1249254000"; d="scan'208";a="18637999" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 16 Oct 2009 09:05:49 +0100 In-Reply-To: <90171.1255679264@nsa.vix.com> References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> <63734.1255641110@nsa.vix.com> <200910152313.n9FNDCNG031967@drugs.dv.isc.org> <90171.1255679264@nsa.vix.com> To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 16 Oct 2009 09:05:49 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 16/10/2009 09:05:49 AM, Serialize complete at 16/10/2009 09:05:49 AM Content-Type: multipart/alternative; boundary="=_alternative 002C7A4480257651_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 002C7A4480257651_= Content-Type: text/plain; charset="US-ASCII" > does the current draft make it clear that tcp is (and has always been) > mandatory AND that it is (and has always been) a backup or secondary > transport (after UDP/EDNS)? It's not quite as explicit as that. It points out that in 1035 and 1123 it was "SHOULD", but that 1123 predicted a time when it would become "required" (non-2119 required). So this draft changes that into "REQUIRED" except in a small set of edge cases. It does not attempt to make TCP a primary transport, with the caveat that it says: "A resolver SHOULD send a UDP query first, but MAY elect to send a TCP query instead if it has good reason to expect the response would be truncated if it were sent over UDP, or for other operational reasons." Ray --=_alternative 002C7A4480257651_= Content-Type: text/html; charset="US-ASCII"
> does the current draft make it clear that tcp is (and has always been)
> mandatory AND that it is (and has always been) a backup or secondary
> transport (after UDP/EDNS)?
It's not quite as explicit as that.

It points out that in 1035 and 1123 it was "SHOULD", but that 1123 predicted a time when it would become "required" (non-2119 required).

So this draft changes that into "REQUIRED" except in a small set of edge cases.

It does not attempt to make TCP a primary transport, with the caveat that it says: "A resolver SHOULD send a UDP query first, but MAY elect to send a TCP query instead if it has good reason to expect the response would be truncated if it were sent over UDP, or for other operational reasons."

Ray
--=_alternative 002C7A4480257651_=-- From owner-namedroppers@ops.ietf.org Fri Oct 16 02:03:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C963A6858; Fri, 16 Oct 2009 02:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.177 X-Spam-Level: X-Spam-Status: No, score=0.177 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq4Ad95dHjqO; Fri, 16 Oct 2009 02:03:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7F84A3A67F0; Fri, 16 Oct 2009 02:02:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Myid0-000ITn-Cg for namedroppers-data0@psg.com; Fri, 16 Oct 2009 08:57:38 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Myicq-000ITI-Vr for namedroppers@ops.ietf.org; Fri, 16 Oct 2009 08:57:36 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 370ABC2DA5; Fri, 16 Oct 2009 09:57:25 +0100 (BST) Date: Fri, 16 Oct 2009 09:56:37 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ray.Bellis@nominet.org.uk, Paul Vixie cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward Message-ID: <9B2E80D2F59499F1EFDB9302@Ximines.local> In-Reply-To: References: <48DCD05A-8C47-42D1-9500-EB1203EDB7EE@fh-muenster.de> from Michael Tuexen at Oct "14," 2009 "07:22:32" pm <200910141841.UAA25186@TR-Sys.de> <4AD6AB18.9000708@mail-abuse.org> <63734.1255641110@nsa.vix.com> <200910152313.n9FNDCNG031967@drugs.dv.isc.org> <90171.1255679264@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 16 October 2009 09:05:49 +0100 Ray.Bellis@nominet.org.uk wrote: >> does the current draft make it clear that tcp is (and has always been) >> mandatory AND that it is (and has always been) a backup or secondary >> transport (after UDP/EDNS)? > > It's not quite as explicit as that. > > It points out that in 1035 and 1123 it was "SHOULD", but that 1123 > predicted a time when it would become "required" (non-2119 required). > > So this draft changes that into "REQUIRED" except in a small set of edge > cases. I think this is a wise course to steer, not least because there was a debate on here as to whether MUST'ing TCP support was a clarification (as per the original work item), or a marginal change in requirements, and that debate didn't appear to reach consensus. Given that almost all those who thought it was a marginal change believed that support (under most circumstances) should be a MUST anyway, discussing in exactly what circumstances TCP support is currently a SHOULD seems a little bit of an angels-on-pinheads argument, as the very presence of the work item illustrates that not everyone agrees what the current requirement level for TCP support is. -- Alex Bligh From dnsddr7u18h3crvn-sq@adelphia.com Fri Oct 16 03:03:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD5F3A67A1 for ; Fri, 16 Oct 2009 03:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.027 X-Spam-Level: X-Spam-Status: No, score=-46.027 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcBp1O5gAF8b for ; Fri, 16 Oct 2009 03:03:12 -0700 (PDT) Received: from host111-49-dynamic.10-79-r.retail.telecomitalia.it (host111-49-dynamic.10-79-r.retail.telecomitalia.it [79.10.49.111]) by core3.amsl.com (Postfix) with SMTP id 710983A677C for ; Fri, 16 Oct 2009 03:03:11 -0700 (PDT) From: VIAGRA Official Site To: dnsext-archive@ietf.org Subject: Dear dnsext-archive@ietf.org 51% 0FF on Pfizer ! MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 091015-0, 15/10/2009), Outbound message X-Antivirus-Status: Clean Message-Id: <20091016100311.710983A677C@core3.amsl.com> Date: Fri, 16 Oct 2009 03:03:11 -0700 (PDT)
Can't See Images? Click here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2009 njnj INC | Unsubscribe | More Newsletters | Privacy
From occasionst35@213-227-219-58.static.vega-ua.net Sat Oct 17 06:26:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1023A687B for ; Sat, 17 Oct 2009 06:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.719 X-Spam-Level: ** X-Spam-Status: No, score=2.719 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_STATIC=1.172, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1-brf2GLQ+t for ; Sat, 17 Oct 2009 06:26:35 -0700 (PDT) Received: from 213-227-219-58.static.vega-ua.net (213-227-219-58.static.vega-ua.net [213.227.219.58]) by core3.amsl.com (Postfix) with ESMTP id A14E13A677E for ; Sat, 17 Oct 2009 06:26:34 -0700 (PDT) Received: from 213.227.219.58 by smtp.roperscientific.com; Sat, 17 Oct 2009 16:26:33 +0300 Message-ID: <01ca4f46$9717b9e0$3adbe3d5@occasionst35> From: "Hubert Colvin" To: Subject: Cheap price Date: Sat, 17 Oct 2009 16:26:33 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 75%??? off on all products WOW! http://boxround.com From owner-namedroppers@ops.ietf.org Sun Oct 18 19:43:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0063A6861; Sun, 18 Oct 2009 19:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.219 X-Spam-Level: X-Spam-Status: No, score=-103.219 tagged_above=-999 required=5 tests=[AWL=2.461, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R42MQz1fY1sV; Sun, 18 Oct 2009 19:43:48 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 2EA853A67DB; Sun, 18 Oct 2009 19:43:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mzh0m-0002md-Pu for namedroppers-data0@psg.com; Mon, 19 Oct 2009 01:26:12 +0000 Received: from [194.176.119.229] (helo=smtp1.bondis.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mzgjs-0001FW-82 for namedroppers@ops.ietf.org; Mon, 19 Oct 2009 01:12:44 +0000 Received: from sn4wlan167.klm.aas.attingo.nl (unknown [77.241.230.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.bondis.org (Postfix) with ESMTPSA id CECB51AB2FF; Sat, 17 Oct 2009 09:22:52 +0000 (UTC) Cc: cet1@cam.ac.uk, namedroppers@ops.ietf.org, dnsop@ietf.org Message-Id: <9D254492-785C-4169-A953-3A1187EC3A41@bondis.org> From: joao damas To: =?ISO-8859-1?Q?Alfred_H=CEnes?= In-Reply-To: <200910161714.TAA01113@TR-Sys.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Subject: [dnsext] Re: [DNSOP] new draft about idn tld variants implementation Date: Sat, 17 Oct 2009 11:21:56 +0200 References: <200910161714.TAA01113@TR-Sys.de> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 16 Oct 2009, at 19:14, Alfred H=CEnes wrote: > 2.3. DNAME Apex not Redirected itself > > Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its > owner name; the owner name of a DNAME is not redirected itself. The > domain name that owns a DNAME record is allowed to have other > resource record types at that domain name, except DNAMEs, CNAMEs or > other types that have restrictions on what they can co-exist with. > |> DNAME RRs are not allowed at the parent side of a delegation point > |> but are allowed at a zone apex. > What this says is that if you use a DNAME at the parent it must =20 replace the delegation. It does not say that the DNAME can't be in the =20= parent. The real issue that needs attention here is an operational one: the =20 extra load at the root servers derived from the need to do CNAME =20 synthesis for a percentage of the queries. This has a provisioning =20 side which would be good to quantify and an implementation efficiency =20= side, which could be addressed by ICANN throwing money at implementers =20= to optimise that part if DNAME is the choice for IDN variant =20 implementation at the root. Joao= From owner-namedroppers@ops.ietf.org Sun Oct 18 20:36:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E293A6852; Sun, 18 Oct 2009 20:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bB-h+JtVU6K5; Sun, 18 Oct 2009 20:36:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0382B3A6358; Sun, 18 Oct 2009 20:36:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MzhnY-0007Dh-1X for namedroppers-data0@psg.com; Mon, 19 Oct 2009 02:16:36 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MzhCJ-0003uf-LJ for namedroppers@ops.ietf.org; Mon, 19 Oct 2009 01:42:08 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id B216C3A68B0; Sun, 18 Oct 2009 09:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-gost-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091018160001.B216C3A68B0@core3.amsl.com> Date: Sun, 18 Oct 2009 09:00:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC Author(s) : V. Dolmatov, et al. Filename : draft-ietf-dnsext-dnssec-gost-01.txt Pages : 8 Date : 2009-10-18 This document describes how to produce GOST signature and hash algorithms DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). V.Dolmatov Expires April 18, 2010 [page 1] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-gost-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-gost-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-18085140.I-D@ietf.org> --NextPart-- From owner-namedroppers@ops.ietf.org Mon Oct 19 00:06:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327C33A68C3; Mon, 19 Oct 2009 00:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=-1.490, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cO6LvwYjq9+j; Mon, 19 Oct 2009 00:06:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 387BA3A6810; Mon, 19 Oct 2009 00:06:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MzlB4-000MLM-Sz for namedroppers-data0@psg.com; Mon, 19 Oct 2009 05:53:06 +0000 Received: from [131.111.8.135] (helo=ppsw-5.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MzkuH-000L9m-A7 for namedroppers@ops.ietf.org; Mon, 19 Oct 2009 05:39:45 +0000 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]:59422) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:cet1) id 1MyrKl-0000C6-I8 (Exim 4.70) (return-path ); Fri, 16 Oct 2009 19:15:23 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1MyrKl-0004m7-Jb (Exim 4.67) (return-path ); Fri, 16 Oct 2009 19:15:23 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.2); 16 Oct 2009 19:15:23 +0100 Date: 16 Oct 2009 19:15:23 +0100 From: Chris Thompson To: =?ISO-8859-1?Q?Alfred_H=F6nes?= Cc: namedroppers@ops.ietf.org, dnsop@ietf.org Reply-To: cet1@cam.ac.uk Subject: [dnsext] Re: [DNSOP] new draft about idn tld variants implementation Message-ID: In-Reply-To: <200910161714.TAA01113@TR-Sys.de> References: from Chris Thompson at Oct "16, " 2009 "05:02:10" pm <200910161714.TAA01113@TR-Sys.de> X-Mailer: Prayer v1.3.2 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Oct 16 2009, Alfred H=F6nes wrote: >On Oct 16 2009, Chris Thompson wrote: > >> On Oct 16 2009, Alfred H=F6nes wrote: >> >>> Another point: >>> >>> The draft is speaking abut "DNAME _in_ the root". >>> >>> According to my surficial knowledge, DNAME RRs 'live' >>> at the _apex_ of the zone that shall be redirected, not >>> at the delegation point -- or did I miss something? >>> Within each zone, there may be at most one DNAME RR, >>> and if so, it must be at the apex of the zone. >> >> That's just wrong. DNAMEs can occur anywhere within a zone >> (including at the apex, but not restricted to it), and there >> can be as many as you like within a zone, subject only to the >> constraint that no RR has a name subordinate to that of a DNAME. > >I don't think so. > >Here's a full section from draft-ietf-dnsext-rfc2672bis-dname-17 >(expected to be shipped to the IESG soon) : > >2.3. DNAME Apex not Redirected itself The term "DNAME Apex" occurs nowhere else in the document, and is perhaps rather unfortunate. I've always assumed it was meant to be the same as "DNAME owner name" as in the text below, and certainly not equivalent to "zone apex". > Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its > owner name; the owner name of a DNAME is not redirected itself. The > domain name that owns a DNAME record is allowed to have other > resource record types at that domain name, except DNAMEs, CNAMEs or > other types that have restrictions on what they can co-exist with. >|> DNAME RRs are not allowed at the parent side of a delegation point >|> but are allowed at a zone apex. "Allowed at a zone apex" !=3D "Must be at the zone apex". (And of course lifting a DNAME into the parent zone must *replace* the delegation, not co-exist with it.) > There still is a need to have the customary SOA and NS resource > records at the zone apex. This means that DNAME does not mirror a > zone completely, as it does not mirror the zone apex. > > These rules also allow DNAME records to be queried through RFC 1034 > [RFC1034] compliant, DNAME-unaware caches. Not allowing DNAMEs except at the zone apex would be grossly incompatible with RFC 2672 itself (see the example in section 5.2) and with deployed code. I cannot imagine it was the intent of the draft to make such a change without a highly explicit statement to that effect. (Nor do I see any reason to make such a change.) I guess this had better be continued on namedroppers rather than dnsop. --=20 Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From owner-namedroppers@ops.ietf.org Mon Oct 19 12:16:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7279E3A6781; Mon, 19 Oct 2009 12:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivBRDY07unPN; Mon, 19 Oct 2009 12:16:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 572153A68B9; Mon, 19 Oct 2009 12:16:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MzxHa-0004kx-R4 for namedroppers-data0@psg.com; Mon, 19 Oct 2009 18:48:38 +0000 Received: from [131.111.8.136] (helo=ppsw-6.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mzx5m-0003QQ-Eq for namedroppers@ops.ietf.org; Mon, 19 Oct 2009 18:40:26 +0000 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]:39119) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:cet1) id 1Mzx5j-00082w-JP (Exim 4.70) for namedroppers@ops.ietf.org (return-path ); Mon, 19 Oct 2009 19:36:23 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1Mzx5j-0000Pe-0B (Exim 4.67) for namedroppers@ops.ietf.org (return-path ); Mon, 19 Oct 2009 19:36:23 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.2); 19 Oct 2009 19:36:22 +0100 Date: 19 Oct 2009 19:36:22 +0100 From: Chris Thompson To: namedroppers@ops.ietf.org Reply-To: cet1@cam.ac.uk Subject: [dnsext] Re: DNAME-bis issues (was: [DNSOP] new draft about idn tld variant implementation) Message-ID: X-Mailer: Prayer v1.3.2 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [I sent this response to Andrew's posting to namedroppers on Friday, but it seems to have been lost completely in this weekend's troubles with the mailing list. Ah well, it gives me a chance to correct and expand it a bit this time ...] On Oct 16 2009, Andrew Sullivan wrote: >As near as I can tell, the problem is that the current draft makes an >explicit claim that DNAME is not allowed on the parent side of zone >cuts, and there is reason to believe that existing implentations have >no trouble with child-side DNAMEs, so this would be a protocol change. No-one (I hope) is claiming that a DNAME can exist on the parent side of a cut, in the sense of coexisting with delegation (i.e. non-apex) NS records. This came up while discussing draft-yao-dnsop-idntld-implementation-00.txt. There are two proposals being compared: ; In the root zone xn--314159. NS ...some nameserver... NS ...other nameservers... xn--217182. NS ...some nameserver... NS ...other namesevers... versus ; In the root zone xn--314159. NS ...some nameserver... NS ...other namesevers... xn--217182. DNAME xn--314159. Alfred said essentially (I hope I am not misrepresenting him) "You can't use the second variant, because DNAMEs have to be at the zone apex. You have to delegate and then put the DNAME at the apex of the child zone." My claim is that is not the intention of the draft, or (as the lawyers say) in the alternative that it is, it's grossly incompatible with RFC 2672. with deployed code, and with existing DNAME records. But if I am right in thinking that was not the intention of the draft, then the fact that it could be misinterpreted that way is fairly serious. I can certainly see that section 2.3 taken in isolation could be confusing. I would suggest replacing "DNAME Apex" by "DNAME Owner Name" in the section title, and the second paragraph by If a DNAME record is present at the zone apex, there is still is a need to have the customary SOA and NS resource records there as well. This means that a DNAME cannot be used to mirror a zone completely, as it does not mirror the zone apex. Should I declare an interest? We use DNAMEs in parts of our reverse lookup tree, and some of them are very definitely not at a zone apex. -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From owner-namedroppers@ops.ietf.org Mon Oct 19 12:21:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D773A6781; Mon, 19 Oct 2009 12:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.946 X-Spam-Level: X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[AWL=-0.451, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjnsABKq7Fsr; Mon, 19 Oct 2009 12:21:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ABEC83A696C; Mon, 19 Oct 2009 12:21:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mzx1V-0002yG-U7 for namedroppers-data0@psg.com; Mon, 19 Oct 2009 18:32:01 +0000 Received: from [209.85.220.227] (helo=mail-fx0-f227.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mzwf6-0000jh-69 for namedroppers@ops.ietf.org; Mon, 19 Oct 2009 18:08:52 +0000 Received: by fxm27 with SMTP id 27so5500707fxm.41 for ; Mon, 19 Oct 2009 11:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=bCW8K3IUe6d+1qPTLg8n6Pkjj7GE9DbgM0m9nI29LVA=; b=cl9vJY1lEwkhEQ3LF/oEdFQBOz5qhswr42afTRemxQ7pMsMUKfSad9mmNKwzQkz3PS AgOuJbwthXi0KqHHOBTjLApTa+lv3fuWYCMb/5psHb6BJOiDK9LqN4/JjRU3ifR1UJuO 7fKjnvw4S5Zgz1eShM/wX9uI+zSzQjK4nq+Ls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=Xl+XpdLjiwEEo615B2WuYiLB+mU/iiQ22eZ3iFt6NJDPmbov4RAhXThG5SveJb6Qxf zRKAzkhNixX/8OXiEEqQ0wBKhsIXtSntfO7vmnuEFI2pqr1uaVSTCwTpFR0tRkqN5a0q 7oRNKMRx8UbQ6schfzJZ/Hojz5wvMZqPVZxt4= Received: by 10.204.24.71 with SMTP id u7mr5153359bkb.35.1255975730476; Mon, 19 Oct 2009 11:08:50 -0700 (PDT) Received: from sjc-office-nat-214.mail-abuse.org (SJC-Office-NAT-214.mail-abuse.org [168.61.10.214]) by mx.google.com with ESMTPS id 26sm251393fks.2.2009.10.19.11.08.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 19 Oct 2009 11:08:49 -0700 (PDT) Message-ID: <4ADCAB2C.2000302@gmail.com> Date: Mon, 19 Oct 2009 11:08:44 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: IETF DNSEXT WG Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: There seems to have been an outage of the namedropper mailing list. This message is being resubmitted, as it appears to have been lost. -------- Original Message -------- Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward Date: Fri, 16 Oct 2009 11:24:56 -0700 From: Doug Otis To: Ray.Bellis@nominet.org.uk CC: Paul Vixie , namedroppers@ops.ietf.org On 10/16/09 1:05 AM, Ray.Bellis@nominet.org.uk wrote: > > > does the current draft make it clear that tcp is (and has always been) > > mandatory AND that it is (and has always been) a backup or secondary > > transport (after UDP/EDNS)? > > It's not quite as explicit as that. > > It points out that in 1035 and 1123 it was "SHOULD", but that 1123 > predicted a time when it would become "required" (non-2119 required). > > So this draft changes that into "REQUIRED" except in a small set of edge > cases. > > It does not attempt to make TCP a primary transport, with the caveat > that it says: "A resolver SHOULD send a UDP query first, but MAY elect > to send a TCP query instead if it has good reason to expect the response > would be truncated if it were sent over UDP, or for other operational > reasons." A reality of dependence needs to be clarified. There remains a urgent need to better deal with TCP's potential for causing inordinate and disproportionate burdens on DNS servers that are unlikely to be met. A strong cautionary statement warning that "TCP SHOULD receive lower resource priority during aberrant demand to ensure UDP operation" could help clarify the limited reliance safely placed upon the use of TCP with DNS. Unfortunately, even this type of warning seems unlikely at preventing a degradation of availability. The overarching problem of security inducing the change to DNS can largely be solved by modern transport. Transports used at recursive resolvers represent a secondary problem that may never change. -Doug From owner-namedroppers@ops.ietf.org Mon Oct 19 16:00:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605DC3A68FE; Mon, 19 Oct 2009 16:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.404 X-Spam-Level: X-Spam-Status: No, score=0.404 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7C8l2xQDSBI; Mon, 19 Oct 2009 16:00:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA87E28C0E5; Mon, 19 Oct 2009 16:00:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MzzxC-000NJY-Sp for namedroppers-data0@psg.com; Mon, 19 Oct 2009 21:39:46 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MzzbC-000Kzv-Cq for namedroppers@ops.ietf.org; Mon, 19 Oct 2009 21:17:02 +0000 Received: (qmail 28554 invoked by uid 399); 19 Oct 2009 21:17:01 -0000 Received: from localhost (HELO ?192.168.0.102?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Oct 2009 21:17:01 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4ADCD74B.6060302@dougbarton.us> Date: Mon, 19 Oct 2009 14:16:59 -0700 From: Doug Barton User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Protocol numbers for RSA/SHA{256|512} (Was: Re: [dnsext] GOST DNSSEC, implementations?) X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Andrew Sullivan wrote: > On Fri, Sep 25, 2009 at 09:40:21PM -0700, Doug Barton wrote: > >> IANA could kill two birds with one stone by not assigning 8-11 "in the >> foreseeable future" and assigning something totally different to >> RSA/SHA{256|512}. > > Actually, in consultation with IANA, we've determined that we'll > assign the identifiers in the 8-11 range I see based on http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml that the decision to use the numbers that were already shipped seems to have been finalized. From owner-namedroppers@ops.ietf.org Mon Oct 19 19:15:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4473E3A69DC; Mon, 19 Oct 2009 19:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.13 X-Spam-Level: X-Spam-Status: No, score=-0.13 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5c1NKlBlZkY; Mon, 19 Oct 2009 19:15:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 287253A68FB; Mon, 19 Oct 2009 19:15:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N03La-0004Jc-4x for namedroppers-data0@psg.com; Tue, 20 Oct 2009 01:17:10 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N02NF-0000mT-4W for namedroppers@ops.ietf.org; Tue, 20 Oct 2009 00:18:51 +0000 Received: from [172.16.33.103] (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6A9962FE8CA1; Tue, 20 Oct 2009 00:14:50 +0000 (UTC) From: Andrew Sullivan To: Doug Barton In-Reply-To: <4ADCD74B.6060302@dougbarton.us> X-Mailer: iPhone Mail (7D11) Subject: Re: Protocol numbers for RSA/SHA{256|512} (Was: Re: [dnsext] GOST DNSSEC, implementations?) References: <4ADCD74B.6060302@dougbarton.us> Message-Id: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7D11) Date: Mon, 19 Oct 2009 20:14:46 -0400 Cc: "namedroppers@ops.ietf.org" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Hi, I didn't see an argument that seemed like, "This is harmful," where harm was defined otherwise than, "It's in bad taste." I don't think bad taste is enough, and as I argued before, I think the precedent argument is bogus (and I'm prepared to meet it in future). Of course, we do not yet have an RFC, and if the issue is important enough to anyone to change, now would be the time to make loud screeching noises. I won't speak for Olafur, but I regard my role in this as being the instrument of the WG's will. I think I got it right, but I'm ever open to correction. A -- Andrew Sullivan On 2009-10-19, at 17:16, Doug Barton wrote: > Andrew Sullivan wrote: >> On Fri, Sep 25, 2009 at 09:40:21PM -0700, Doug Barton wrote: >> >>> IANA could kill two birds with one stone by not assigning 8-11 "in >>> the >>> foreseeable future" and assigning something totally different to >>> RSA/SHA{256|512}. >> >> Actually, in consultation with IANA, we've determined that we'll >> assign the identifiers in the 8-11 range > > I see based on > http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml > that the decision to use the numbers that were already shipped seems > to have been finalized. > From owner-namedroppers@ops.ietf.org Mon Oct 19 19:29:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06123A63C9; Mon, 19 Oct 2009 19:29:46 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3QQlzMLy+aV; Mon, 19 Oct 2009 19:29:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2EC703A62C1; Mon, 19 Oct 2009 19:29:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N047i-0007t9-Rf for namedroppers-data0@psg.com; Tue, 20 Oct 2009 02:06:54 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N03mI-00066L-0t for namedroppers@ops.ietf.org; Tue, 20 Oct 2009 01:48:46 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 05970CBBCC for ; Tue, 20 Oct 2009 01:44:45 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: DNAME-bis issues (was: [DNSOP] new draft about idn tld variant implementation) In-Reply-To: Your message of "19 Oct 2009 19:36:22 +0100." References: X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 20 Oct 2009 01:44:44 +0000 Message-ID: <19465.1256003084@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: 19 Oct 2009 19:36:22 +0100 > From: Chris Thompson > ... > Alfred said essentially (I hope I am not misrepresenting him) "You can't > use the second variant, because DNAMEs have to be at the zone apex. You > have to delegate and then put the DNAME at the apex of the child zone." > > My claim is that is not the intention of the draft, or (as the lawyers say) > in the alternative that it is, it's grossly incompatible with RFC 2672. > with deployed code, and with existing DNAME records. +1. > But if I am right in thinking that was not the intention of the draft, > then the fact that it could be misinterpreted that way is fairly serious. +1. From owner-namedroppers@ops.ietf.org Tue Oct 20 20:29:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E523A682B; Tue, 20 Oct 2009 20:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDogxd1dw07J; Tue, 20 Oct 2009 20:29:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 436973A672F; Tue, 20 Oct 2009 20:29:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0Rjq-0008zN-U0 for namedroppers-data0@psg.com; Wed, 21 Oct 2009 03:19:50 +0000 Received: from [209.85.216.204] (helo=mail-px0-f204.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0RjP-0008v6-0M for namedroppers@ops.ietf.org; Wed, 21 Oct 2009 03:19:23 +0000 Received: by pxi42 with SMTP id 42so4737149pxi.5 for ; Tue, 20 Oct 2009 20:19:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.148.16 with SMTP id a16mr478612wao.57.1256095161956; Tue, 20 Oct 2009 20:19:21 -0700 (PDT) In-Reply-To: <200910071459.n97ExVoK041341@stora.ogud.com> References: <20091006181501.EF9443A67F4@core3.amsl.com> <200910071459.n97ExVoK041341@stora.ogud.com> Date: Tue, 20 Oct 2009 20:19:21 -0700 Message-ID: Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-00.txt From: Matthew Dempsky To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: (Sorry, missed this response until now.) On Wed, Oct 7, 2009 at 7:59 AM, Olafur Gudmundsson wrote: > "First" query to a server in this case yes UDP is required before TCP > Is "Subsequent" query different ? My understanding of the current wording is each individual query SHOULD be tried over UDP first. I'm fine with this interpretation, subject to the constraints I mentioned in my last email (i.e., that clients need to be prepared to interoperate with servers that don't offer TCP because of constrained circumstances). It sounds like you're interpreting it as the first query to a server MUST be tried over UDP, but subsequent queries to the same server (after ensuring TCP support) only SHOULD be tried over UDP. I'm okay with this as well, though as an informative remark, I'd suggest pointing out that servers may change configuration over time, and one that supported TCP at one time may no longer support it in the future. > For example every time someone asks for a non existent .gov name the > answer is 1700+ bytes. Can a resolver that has detected lots of TC's from > a server for .gov to just ask all future queries over TCP ? > (This is a resolver behind a pipe that restricts answers to 1500 bytes). My assumption is that as long as the TCP socket is still open, the client should be free to send as many queries over it as it can/wants. Assuming there are no open TCP connections to the server though, I think as long as the last TC response was fairly recent (e.g., within the last 5 minutes), then it seems reasonable to try over TCP first if the resolver expects a truncated response. From owner-namedroppers@ops.ietf.org Tue Oct 20 23:24:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9AF83A69CC; Tue, 20 Oct 2009 23:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VveAGsI4Zv30; Tue, 20 Oct 2009 23:24:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 85D443A69CB; Tue, 20 Oct 2009 23:24:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0URA-0001CC-Tr for namedroppers-data0@psg.com; Wed, 21 Oct 2009 06:12:44 +0000 Received: from [209.85.222.174] (helo=mail-pz0-f174.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0UQz-0001B3-Jb for namedroppers@ops.ietf.org; Wed, 21 Oct 2009 06:12:40 +0000 Received: by pzk4 with SMTP id 4so9098408pzk.32 for ; Tue, 20 Oct 2009 23:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=rnYrlfpl3LqtGvdYvDKZAbuDMyTEPpJvE1eQfA5Cv+c=; b=ssfZ2QYypc3P1HCkNl5cMHyk17YKGzrpU9TnkKR95znXVBtReaxS77W8j1wRp7pQFF c47e0qzrR5GElB4TBoIRsWAR+dakufu/40Ux6cMM/kd5MkuB3czJxVqLGihdZv7zGIVd qs+MJpUw67XDiIgJRFi0EiwzHKSQh1ogJi5Xc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=iE3m1PFjUoEe9mRj2QpLfCXbFEjq4t6hPJ+DKstU1FHcX1uqmLQHhIdoTVMWDbcjdM CapsmS2SNdjwCfccoMd4yke2L+3GDmL8MS5T+lccz3f9Cz4oySIuJkLsl/s7YccH0Y0u E6UU2mw9hgHyQJ+P+6o0aTF2tshiy8D3x0Wh0= Received: by 10.115.39.8 with SMTP id r8mr7241324waj.104.1256105552351; Tue, 20 Oct 2009 23:12:32 -0700 (PDT) Received: from whatisfuture ([218.241.111.35]) by mx.google.com with ESMTPS id 20sm1235985pzk.1.2009.10.20.23.12.30 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Oct 2009 23:12:31 -0700 (PDT) Message-ID: <016801ca5215$791b8d00$236ff1da@whatisfuture> From: "Health" To: , References: Subject: Re: [dnsext] Re: DNAME-bis issues (was: [DNSOP] new draft about idn tld variant implementation) Date: Wed, 21 Oct 2009 14:12:28 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNocmlzIFRob21wc29uIiA8 Y2V0MUBjYW0uYWMudWs+DQpUbzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50OiBU dWVzZGF5LCBPY3RvYmVyIDIwLCAyMDA5IDI6MzYgQU0NClN1YmplY3Q6IFtkbnNleHRdIFJlOiBE TkFNRS1iaXMgaXNzdWVzICh3YXM6IFtETlNPUF0gbmV3IGRyYWZ0IGFib3V0IGlkbiB0bGQgdmFy aWFudCBpbXBsZW1lbnRhdGlvbikNCg0KDQo+IFtJIHNlbnQgdGhpcyByZXNwb25zZSB0byBBbmRy ZXcncyBwb3N0aW5nIHRvIG5hbWVkcm9wcGVycyBvbiBGcmlkYXksDQo+IGJ1dCBpdCBzZWVtcyB0 byBoYXZlIGJlZW4gbG9zdCBjb21wbGV0ZWx5IGluIHRoaXMgd2Vla2VuZCdzIHRyb3VibGVzDQo+ IHdpdGggdGhlIG1haWxpbmcgbGlzdC4gQWggd2VsbCwgaXQgZ2l2ZXMgbWUgYSBjaGFuY2UgdG8g Y29ycmVjdCBhbmQNCj4gZXhwYW5kIGl0IGEgYml0IHRoaXMgdGltZSAuLi5dDQo+IA0KPiBPbiBP Y3QgMTYgMjAwOSwgQW5kcmV3IFN1bGxpdmFuIHdyb3RlOg0KPiANCj4+QXMgbmVhciBhcyBJIGNh biB0ZWxsLCB0aGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBjdXJyZW50IGRyYWZ0IG1ha2VzIGFuDQo+ PmV4cGxpY2l0IGNsYWltIHRoYXQgRE5BTUUgaXMgbm90IGFsbG93ZWQgb24gdGhlIHBhcmVudCBz aWRlIG9mIHpvbmUNCj4+Y3V0cywgYW5kIHRoZXJlIGlzIHJlYXNvbiB0byBiZWxpZXZlIHRoYXQg ZXhpc3RpbmcgaW1wbGVudGF0aW9ucyBoYXZlDQo+Pm5vIHRyb3VibGUgd2l0aCBjaGlsZC1zaWRl IEROQU1Fcywgc28gdGhpcyB3b3VsZCBiZSBhIHByb3RvY29sIGNoYW5nZS4NCj4gDQo+IE5vLW9u ZSAoSSBob3BlKSBpcyBjbGFpbWluZyB0aGF0IGEgRE5BTUUgY2FuIGV4aXN0IG9uIHRoZSBwYXJl bnQgc2lkZQ0KPiBvZiBhIGN1dCwgaW4gdGhlIHNlbnNlIG9mIGNvZXhpc3Rpbmcgd2l0aCBkZWxl Z2F0aW9uIChpLmUuIG5vbi1hcGV4KQ0KPiBOUyByZWNvcmRzLg0KPiANCj4gVGhpcyBjYW1lIHVw IHdoaWxlIGRpc2N1c3NpbmcgZHJhZnQteWFvLWRuc29wLWlkbnRsZC1pbXBsZW1lbnRhdGlvbi0w MC50eHQuDQo+IFRoZXJlIGFyZSB0d28gcHJvcG9zYWxzIGJlaW5nIGNvbXBhcmVkOg0KPiANCj4g IDsgSW4gdGhlIHJvb3Qgem9uZQ0KPiAgeG4tLTMxNDE1OS4gTlMgLi4uc29tZSBuYW1lc2VydmVy Li4uDQo+ICAgICAgICAgICAgICBOUyAuLi5vdGhlciBuYW1lc2VydmVycy4uLg0KPiAgeG4tLTIx NzE4Mi4gTlMgLi4uc29tZSBuYW1lc2VydmVyLi4uDQo+ICAgICAgICAgICAgICBOUyAuLi5vdGhl ciBuYW1lc2V2ZXJzLi4uDQo+IA0KPiB2ZXJzdXMNCj4gDQo+ICA7IEluIHRoZSByb290IHpvbmUN Cj4gIHhuLS0zMTQxNTkuIE5TIC4uLnNvbWUgbmFtZXNlcnZlci4uLg0KPiAgICAgICAgICAgICAg TlMgLi4ub3RoZXIgbmFtZXNldmVycy4uLg0KPiAgeG4tLTIxNzE4Mi4gRE5BTUUgeG4tLTMxNDE1 OS4NCg0KDQpkbyB5b3UgbWVhbiB0aGF0IHRoZSBmb2xsb3dpbmcgcmVjb3JkcyBjYW4gd29yayBv ciBub3QgaW4gdGhlIHJvb3Qgc2VydmVyPw0KDQo+ICB4bi0tMzE0MTU5LiBOUyAuLi5zb21lIG5h bWVzZXJ2ZXIuLi4NCj4gICAgICAgICAgICAgIE5TIC4uLm90aGVyIG5hbWVzZXZlcnMuLi4NCj4g IHhuLS0yMTcxODIuIEROQU1FIHhuLS0zMTQxNTkuDQoNCkkgaGFzIGEgbGl0dGxlIGNvbmZ1c2Vk IGJ5IHRoZSBmb2xsb3dpbmcgY29tbWVudHMuDQoNCkNvdWxkIHlvdSBoZWxwIG1lIHRvIGNsYXJp ZnkgaXQ/DQoNClRoYW5rcyBhIGxvdC4NCg0KDQoNCj4gDQo+IEFsZnJlZCBzYWlkIGVzc2VudGlh bGx5IChJIGhvcGUgSSBhbSBub3QgbWlzcmVwcmVzZW50aW5nIGhpbSkgIllvdSBjYW4ndA0KPiB1 c2UgdGhlIHNlY29uZCB2YXJpYW50LCBiZWNhdXNlIEROQU1FcyBoYXZlIHRvIGJlIGF0IHRoZSB6 b25lIGFwZXguIFlvdQ0KPiBoYXZlIHRvIGRlbGVnYXRlIGFuZCB0aGVuIHB1dCB0aGUgRE5BTUUg YXQgdGhlIGFwZXggb2YgdGhlIGNoaWxkIHpvbmUuIg0KPiANCj4gTXkgY2xhaW0gaXMgdGhhdCBp cyBub3QgdGhlIGludGVudGlvbiBvZiB0aGUgZHJhZnQsIG9yIChhcyB0aGUgbGF3eWVycyBzYXkp DQo+IGluIHRoZSBhbHRlcm5hdGl2ZSB0aGF0IGl0IGlzLCBpdCdzIGdyb3NzbHkgaW5jb21wYXRp YmxlIHdpdGggUkZDIDI2NzIuDQo+IHdpdGggZGVwbG95ZWQgY29kZSwgYW5kIHdpdGggZXhpc3Rp bmcgRE5BTUUgcmVjb3Jkcy4NCj4gDQo+IEJ1dCBpZiBJIGFtIHJpZ2h0IGluIHRoaW5raW5nIHRo YXQgd2FzIG5vdCB0aGUgaW50ZW50aW9uIG9mIHRoZSBkcmFmdCwNCj4gdGhlbiB0aGUgZmFjdCB0 aGF0IGl0IGNvdWxkIGJlIG1pc2ludGVycHJldGVkIHRoYXQgd2F5IGlzIGZhaXJseSBzZXJpb3Vz Lg0KPiBJIGNhbiBjZXJ0YWlubHkgc2VlIHRoYXQgc2VjdGlvbiAyLjMgdGFrZW4gaW4gaXNvbGF0 aW9uIGNvdWxkIGJlIGNvbmZ1c2luZy4NCj4gSSB3b3VsZCBzdWdnZXN0IHJlcGxhY2luZyAiRE5B TUUgQXBleCIgYnkgIkROQU1FIE93bmVyIE5hbWUiIGluIHRoZSBzZWN0aW9uDQo+IHRpdGxlLCBh bmQgdGhlIHNlY29uZCBwYXJhZ3JhcGggYnkNCj4gDQo+ICAgSWYgYSBETkFNRSByZWNvcmQgaXMg cHJlc2VudCBhdCB0aGUgem9uZSBhcGV4LCB0aGVyZSBpcyBzdGlsbCBpcyBhIG5lZWQNCj4gICB0 byBoYXZlIHRoZSBjdXN0b21hcnkgU09BIGFuZCBOUyByZXNvdXJjZSByZWNvcmRzIHRoZXJlIGFz IHdlbGwuIFRoaXMNCj4gICBtZWFucyB0aGF0IGEgRE5BTUUgY2Fubm90IGJlIHVzZWQgdG8gbWly cm9yIGEgem9uZSBjb21wbGV0ZWx5LCBhcyBpdA0KPiAgIGRvZXMgbm90IG1pcnJvciB0aGUgem9u ZSBhcGV4Lg0KPiANCj4gU2hvdWxkIEkgZGVjbGFyZSBhbiBpbnRlcmVzdD8gV2UgdXNlIEROQU1F cyBpbiBwYXJ0cyBvZiBvdXIgcmV2ZXJzZSBsb29rdXANCj4gdHJlZSwgYW5kIHNvbWUgb2YgdGhl bSBhcmUgdmVyeSBkZWZpbml0ZWx5IG5vdCBhdCBhIHpvbmUgYXBleC4NCj4gDQo+IC0tIA0KPiBD aHJpcyBUaG9tcHNvbiAgICAgICAgICAgICAgIFVuaXZlcnNpdHkgb2YgQ2FtYnJpZGdlIENvbXB1 dGluZyBTZXJ2aWNlLA0KPiBFbWFpbDogY2V0MUB1Y3MuY2FtLmFjLnVrICAgIE5ldyBNdXNldW1z IFNpdGUsIENhbWJyaWRnZSBDQjIgM1FILA0KPiBQaG9uZTogKzQ0IDEyMjMgMzM0NzE1ICAgICAg IFVuaXRlZCBLaW5nZG9tLg0KPg== From owner-namedroppers@ops.ietf.org Wed Oct 21 00:03:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AA943A69A0; Wed, 21 Oct 2009 00:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJf0rRebpFyD; Wed, 21 Oct 2009 00:03:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 05DDF3A6999; Wed, 21 Oct 2009 00:03:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0V5b-0005Tx-Se for namedroppers-data0@psg.com; Wed, 21 Oct 2009 06:54:31 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0V5S-0005TF-It for namedroppers@ops.ietf.org; Wed, 21 Oct 2009 06:54:30 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id A39DCE605D; Wed, 21 Oct 2009 06:54:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n9L6sILi061468; Wed, 21 Oct 2009 17:54:19 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200910210654.n9L6sILi061468@drugs.dv.isc.org> To: "Health" Cc: cet1@cam.ac.uk, namedroppers@ops.ietf.org From: Mark Andrews References: <016801ca5215$791b8d00$236ff1da@whatisfuture> Subject: Re: [dnsext] Re: DNAME-bis issues (was: [DNSOP] new draft about idn tld variant implementation) In-reply-to: Your message of "Wed, 21 Oct 2009 14:12:28 +0800." <016801ca5215$791b8d00$236ff1da@whatisfuture> Date: Wed, 21 Oct 2009 17:54:18 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DNAME's placement is the same as any ordinary resource record (e.g. MX, TXT). There is nothing special about where DNAME can or can't be used. This is perfectly legal. xn--314159. NS ...some nameserver... NS ...other namesevers... xn--217182. DNAME xn--314159. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Wed Oct 21 04:42:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BEE53A6A30; Wed, 21 Oct 2009 04:42:39 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-uMwNmsjhi6; Wed, 21 Oct 2009 04:42:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 38F133A6A07; Wed, 21 Oct 2009 04:42:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0ZRj-000BJb-Nn for namedroppers-data0@psg.com; Wed, 21 Oct 2009 11:33:39 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0ZRh-000BJ8-Si for namedroppers@ops.ietf.org; Wed, 21 Oct 2009 11:33:37 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 503E6CBE6E for ; Wed, 21 Oct 2009 11:33:37 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: DNAME-bis issues (was: [DNSOP] new draft about idn tld variant implementation) In-Reply-To: Your message of "Wed, 21 Oct 2009 17:54:18 +1100." <200910210654.n9L6sILi061468@drugs.dv.isc.org> References: <016801ca5215$791b8d00$236ff1da@whatisfuture> <200910210654.n9L6sILi061468@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 21 Oct 2009 11:33:37 +0000 Message-ID: <4175.1256124817@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Mark Andrews > Date: Wed, 21 Oct 2009 17:54:18 +1100 > > DNAME's placement is the same as any ordinary resource record (e.g. MX, > TXT). There is nothing special about where DNAME can or can't be used. +1. > This is perfectly legal. > > xn--314159. NS ...some nameserver... > NS ...other namesevers... > xn--217182. DNAME xn--314159. legal, but unlikely. rather, we'd see: XX. NS ...some nameserver... NS ...other namesevers... xn--217182. DNAME xn--314159.XX. or: XX. NS ...some nameserver... NS ...other namesevers... xn--217182. DNAME XX. that is, the existing NS would continue to be associated with an existing CCTLD, and the DNAME will point to that or to some subdomain under that. From owner-namedroppers@ops.ietf.org Wed Oct 21 06:46:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B3D3A6992; Wed, 21 Oct 2009 06:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.424 X-Spam-Level: X-Spam-Status: No, score=-0.424 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU0H-vA75xy9; Wed, 21 Oct 2009 06:46:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 919F328C10E; Wed, 21 Oct 2009 06:46:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0bNl-00036I-UH for namedroppers-data0@psg.com; Wed, 21 Oct 2009 13:37:41 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0bNj-00035j-V5 for namedroppers@ops.ietf.org; Wed, 21 Oct 2009 13:37:40 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3F5502FE8CDC for ; Wed, 21 Oct 2009 13:37:38 +0000 (UTC) Date: Wed, 21 Oct 2009 09:37:36 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: DNAME-bis issues (was: [DNSOP] new draft about idn tld variant implementation) Message-ID: <20091021133736.GD41456@shinkuro.com> References: <016801ca5215$791b8d00$236ff1da@whatisfuture> <200910210654.n9L6sILi061468@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910210654.n9L6sILi061468@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, On Wed, Oct 21, 2009 at 05:54:18PM +1100, Mark Andrews wrote: > > DNAME's placement is the same as any ordinary resource record (e.g. > MX, TXT). There is nothing special about where DNAME can or can't > be used. While that is true, quite plainly the current dname-bis draft doesn't leave everyone with that impression. We need proposed text to make the intent clearer. Can someone please propose it? Given the emergence of this issue, the document is clearly not ready for advancement, and it needs to be fixed before we send it on. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From johnsmithsvt@aspireyou.com Wed Oct 21 07:16:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8743A683A; Wed, 21 Oct 2009 07:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.703 X-Spam-Level: X-Spam-Status: No, score=-2.703 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEfxxZZ9ZY8E; Wed, 21 Oct 2009 07:16:47 -0700 (PDT) Received: from 201-27-3-126.dsl.telesp.net.br (201-27-3-126.dsl.telesp.net.br [201.27.3.126]) by core3.amsl.com (Postfix) with SMTP id 1C9493A679C; Wed, 21 Oct 2009 07:16:15 -0700 (PDT) Subject: Vacheron Constantin better than original Date: Wed, 21 Oct 2009 10:16:23 -0500 From: "Xavier Allison" To: "Manuela Russo" Message-ID: Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Hello Dee Get the Finest Vacheron Constantin Watches here! We only sell premium watches. These original watches sell in stores for thousands of dollars. We sell them for much less. - Rep-licated to the Smallest Detail - 98% Perfectly Accurate Markings - Signature Green Sticker w/ Serial Number on Watch Back - Magnified Quickset Date - Includes all Proper Markings Visit us: http://itcwmpea.cn/ Christmas discount this week only! Make your order before the prices go up. Best regards, Mr. Plummer From owner-namedroppers@ops.ietf.org Wed Oct 21 08:39:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA68928C0E5; Wed, 21 Oct 2009 08:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.866 X-Spam-Level: X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfOD07D3cSAT; Wed, 21 Oct 2009 08:39:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D121A28C10E; Wed, 21 Oct 2009 08:39:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0d96-000JXs-JU for namedroppers-data0@psg.com; Wed, 21 Oct 2009 15:30:40 +0000 Received: from [131.111.8.131] (helo=ppsw-1.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0d93-000JXO-VN for namedroppers@ops.ietf.org; Wed, 21 Oct 2009 15:30:38 +0000 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]:46176) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:cet1) id 1N0d92-0005L8-3F (Exim 4.70) (return-path ); Wed, 21 Oct 2009 16:30:36 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1N0d91-0006gt-Vy (Exim 4.67) (return-path ); Wed, 21 Oct 2009 16:30:35 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.2); 21 Oct 2009 16:30:35 +0100 Date: 21 Oct 2009 16:30:35 +0100 From: Chris Thompson To: Andrew Sullivan Cc: namedroppers@ops.ietf.org, =?ISO-8859-1?Q?Alfred_H=F6nes?= Reply-To: cet1@cam.ac.uk Subject: Re: [dnsext] Re: DNAME-bis issues (was: [DNSOP] new draft about idn tld variant implementation) Message-ID: In-Reply-To: <20091021133736.GD41456@shinkuro.com> References: <016801ca5215$791b8d00$236ff1da@whatisfuture> <200910210654.n9L6sILi061468@drugs.dv.isc.org> <20091021133736.GD41456@shinkuro.com> X-Mailer: Prayer v1.3.2 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Oct 21 2009, Andrew Sullivan wrote: >Dear colleagues, > >On Wed, Oct 21, 2009 at 05:54:18PM +1100, Mark Andrews wrote: >>=20 >> DNAME's placement is the same as any ordinary resource record (e.g. >> MX, TXT). There is nothing special about where DNAME can or can't >> be used. > >While that is true, quite plainly the current dname-bis draft doesn't >leave everyone with that impression. We need proposed text to make >the intent clearer. Can someone please propose it? Given the >emergence of this issue, the document is clearly not ready for >advancement, and it needs to be fixed before we send it on. We really need Alfred H=F6nes to comment on this, as he was the one who acquired the wrong impression. My feeling is that the confusion is confined to section 2.3, and I would now suggest the following: --- draft-ietf-dnsext-rfc2672bis-dname-17.xml=09Wed Oct 21 16:17:14 2009 +++ draft-ietf-dnsext-rfc2672bis-dname-17a.xml=09Wed Oct 21 16:19:51 2009 @@ -214,7 +214,7 @@ =09for the YXDOMAIN (value 6) RCODE. =09 -
+
=09Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its =09owner name; the owner name of a DNAME is not redirected itself. @@ -224,9 +224,10 @@ =09DNAME RRs are not allowed at the parent side of a delegation point=20 =09but are allowed at a zone apex. -=09There still is a need to have the customary SOA and NS -=09resource records at the zone apex. This means that DNAME does not -=09mirror a zone completely, as it does not mirror the zone apex. +=09If a DNAME record is present at the zone apex, there is still a need +=09to have the customary SOA and NS resource records there as well. Such +=09a DNAME cannot be used to mirror a zone completely, as it does not +=09mirror the zone apex. =09These rules also allow DNAME records to be queried through RFC 1034 =09 compliant, DNAME-unaware caches. --=20 Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From owner-namedroppers@ops.ietf.org Wed Oct 21 12:39:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2253A69A4; Wed, 21 Oct 2009 12:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNmPQphPZ5GA; Wed, 21 Oct 2009 12:39:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6AAA83A69D8; Wed, 21 Oct 2009 12:39:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0grC-000Plf-P2 for namedroppers-data0@psg.com; Wed, 21 Oct 2009 19:28:26 +0000 Received: from [194.176.119.229] (helo=smtp1.bondis.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0gr8-000Pl8-BX for namedroppers@ops.ietf.org; Wed, 21 Oct 2009 19:28:23 +0000 Received: from PB2.dhcp.nanog.merit.net (PB2.dhcp.nanog.merit.net [192.35.167.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.bondis.org (Postfix) with ESMTPSA id A693B1AB2FF for ; Wed, 21 Oct 2009 19:28:17 +0000 (UTC) Message-Id: <31B11D8F-1DBE-4A85-BA6F-1A963E9EF3FC@bondis.org> From: joao damas To: namedroppers@ops.ietf.org In-Reply-To: <4A5354C9.7010107@nlnetlabs.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] I-D: IXFR-ONLY proposal (Was: New Version Notification for draft-kerr-ixfr-only-00) Date: Wed, 21 Oct 2009 15:28:14 -0400 References: <4A533F5C.5010501@nlnetlabs.nl> <1246974100.3922.15644.camel@shane-asus-laptop> <4A5354C9.7010107@nlnetlabs.nl> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Just reviewed this i-d and like it and find it useful and mostly complete. Regarding Wouter's comment, text that provides implementation guidelines and further describes usage scenarios is a good thing even if not strictly necessary to define the proposed standard extension. In this spirit, either leaving the options with a MAY in them or writing a separate section on "guidelines" or "examples of usage" is a good thing for everyone who then has to use the implementations that come out. Joao On 7 Jul 2009, at 09:59, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Shane, > > On 07/07/2009 03:41 PM, Shane Kerr wrote: >> I guess we can change this to SHOULD. If IXFR-ONLY breaks things then >> implementors will either add such an option, or people will stop >> using >> their software. If it doesn't break things (or cause extra delays, >> packets, and so on), then such a knob is not necessary after all. :) > > I think you missed yet-another option where the master could disable > IXFR-ONLY support for a particular zone. But agreed with you above. > >> I guess either of these could be changed to a MAY. Neither of these >> is >> required, because they are merely optimizations. > > So, all of them are not necessary. They are not needed to make > IXFR-ONLY work. Therefore I propose to delete the text about the > options entirely. > > Best regards, > Wouter From owner-namedroppers@ops.ietf.org Wed Oct 21 13:08:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5D228C104; Wed, 21 Oct 2009 13:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.644 X-Spam-Level: *** X-Spam-Status: No, score=3.644 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9iZ+7LIxoEY; Wed, 21 Oct 2009 13:08:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C526D28C100; Wed, 21 Oct 2009 13:08:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0hKq-0003r6-Tp for namedroppers-data0@psg.com; Wed, 21 Oct 2009 19:59:04 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0hKm-0003oK-A1 for namedroppers@ops.ietf.org; Wed, 21 Oct 2009 19:59:01 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA281685068; Wed, 21 Oct 2009 21:57:48 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA12840; Wed, 21 Oct 2009 21:57:42 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910211957.VAA12840@TR-Sys.de> Subject: Re: [dnsext] Re: DNAME-bis issues (was: [DNSOP] new draft about idn tld variant implementation) To: cet1@cam.ac.uk Date: Wed, 21 Oct 2009 21:57:42 +0200 (MESZ) Cc: namedroppers@ops.ietf.org, draft-ietf-dnsext-rfc2672bis-dname@cabernet.tools.IETF.ORG, draft-yao-dnsop-idntld-implementation@cabernet.tools.IETF.ORG, dnsop@ietf.org In-Reply-To: from Chris Thompson at Oct "21," 2009 "04:30:35" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Oct 21 2009, Chris Thomson wrote: > On Oct 21 2009, Andrew Sullivan wrote: > >> Dear colleagues, >> >> On Wed, Oct 21, 2009 at 05:54:18PM +1100, Mark Andrews wrote: >>> >>> DNAME's placement is the same as any ordinary resource record (e.g. >>> MX, TXT). There is nothing special about where DNAME can or can't >>> be used. >> >> While that is true, quite plainly the current dname-bis draft doesn't >> leave everyone with that impression. We need proposed text to make >> the intent clearer. Can someone please propose it? Given the >> emergence of this issue, the document is clearly not ready for >> advancement, and it needs to be fixed before we send it on. > > We really need Alfred H=CEnes to comment on this, as he was the one who= > acquired the wrong impression. ... I'll try, also elaborating on thoughts only exchanged off-list so far (last week). First my apologies for not being able to return to this discussion earlier. And maybe I was a bit overshooting in the first instance, too much focussed on the aspects I try to clarify below. Let me first discuss the more generic questions underlying the 'variant' domain (TLD or other) draft and discussion. The basic topic where we started from last week is a delegation. With regard to the root zone (and any other "registry-like" zone), "owner" and "delegation" are not only technical terms related to DNS database and protocol details, but also are contractual and legal terms, and so a lot of care needs to be taken in using these terms. This has repercussions to the protocol and database layer; for instance, in a DNSSEC signed zone the owner of the zone will sign the records there, and will be kept accountable for their content. For brevity, I'll designate the discussed "DNAME at the root" as an instance of a "pseudo-delegation" below (vs. "normal" delegation). For a "normal" delegation, the NS RRset in the delegating zone indeed is owned (in the legal sense!) by the parent zone owner; it is subject to the contractual relationship between the owner of the parent zone and the owner of the delegated zone. The NS RRset at the zone cut is handed over to the parent zone in a technical, contractual and legal sense. (Note that the owner of a zone is free to publish a different NS RRset for the zone at the apex of the zone itself than what he has handed over to the parent -- but he should strongly consider the consequences.) Hence, consistently DNSSEC signs the delegation NS RRs in the parent zone and thereby documents the legal ownership as well. Consequently, any other RRs for the delegated zone, if copied into the parent zone are not signed under DNSSEC there -- independent of their use as "glue" RRs in the narrow sense (address RRs for the name servers specified in the delegating NS RRs) or not. Since with DNAME queries for the owner name (technical!) of a DNAME RR will be answered from the zone where that DNAME RR is located, any other RRs with the same owner (technically!) name must be co-located in the same zone and hence fall technically under the authority (legally) of the owner (in legal terms) of the parent zone. This is entirely consistent with DNSSEC signing authority for all RRsets at the owner name (technically) of the DNAME RR being with the owner (legally and technically) of the 'hosting' zone of the DNAME RR. Many owners (legally) of TLDs and other "registry-like" zones place various RRs not directly related to the delegation (in the technical sense) at the zone apex for the delegated zone. For instance, I've seen TXT and NAPTR RRs recently there, but other RR types might be likely too. In the case of a 'pseudo-delegation' with DNAME in the parent zone these RRsets all would need to be stored in the latter, for instance in the root zone. Without DNSSEC, doing so and maintaining these RRs might be regarded as an O&M issue that could be organized on a contractual base, overriding to some extent the basic legal split of responsibility. But with a DNSSEC signed parent zone, the sibling RRsets of the DNAME would become subject of the parent zone signing policy and practice; I seriously doubt that this would be practical; furthermore, it is likely that the DNSSEC signature over such RRsets would be taken under some legislation as a strong sign of ownership and hence accountability of the parent zone owner for the content of these RRsets. This seems to be in perfect accordance with the DNSSEC trust model. Even more, the user of an 'alias' domain name will want to gain full legal authority of this name and consequently also will be held accountable for it; delegating registration-like domains will most likely not want to become accountable for these names. For a 'normal' delegation, there's a visible 'proof' of ownership for the delegation by the SOA RR at the apex of the delegated zone, which might legally serve as a strong indication of ownership of the delegation -- there's a pointer to "layer 8 and above" in the SOA in the form of the RNAME element in the SOA RDATA. A DNAME RR however does not carry such link to higher layers. Therefore, 'pseudo-delegations' via DNAME will most likely not be regarded as delegations of ownership, authority and accountability in the legal sense. All these complications do not arise if the owner (technically) of a DNAME RR is owned (legally) by the same administrative entity as the TARGET domain of the DNAME. Thus, it look like to avoid administrative, operational, and legal issues with DNAME, it seems to be evident that 'pseudo-delegations' are inappropriate for cases where the semantics of a true delegation (in the legal sense) is inherent and/or intended. This is obviously not the case in certain company-internal structured zones, where the ownership and authority for both domains related to a DNAME are within a single administrative domain, and most likely equally in many regions of the reverse DNS trees. So the terse rule of thumb might be: 'normal' delegations are for cases where the semantics of a (plain English etc.) delegation is expected, 'pseudo-delegations' can be used where the semantics of a "hint" or "shortcut" prevails. Back from the 'variant' domain arguments to the protocol specification undergoing revision (I-D.dnsext-rfc2782bis-dname): > ... My feeling is that the confusion is > confined to section 2.3, and I would now suggest the following: > > --- draft-ietf-dnsext-rfc2672bis-dname-17.xml Wed Oct 21 16:17:14 2009 > +++ draft-ietf-dnsext-rfc2672bis-dname-17a.xml Wed Oct 21 16:19:= 51 2009 > @@ -214,7 +214,7 @@ > for the YXDOMAIN (value 6) RCODE. > >
> -
> +
Good clarification. Agreed. > > Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to = its > owner name; the owner name of a DNAME is not redirected itself. > @@ -224,9 +224,10 @@ > DNAME RRs are not allowed at the parent side of a delegation poin= t > but are allowed at a zone apex. > > - There still is a need to have the customary SOA and NS > - resource records at the zone apex. This means that DNAME does no= t > - mirror a zone completely, as it does not mirror the zone apex. > + If a DNAME record is present at the zone apex, there is still a n= eed > + to have the customary SOA and NS resource records there as well. = Such > + a DNAME cannot be used to mirror a zone completely, as it does no= t > + mirror the zone apex. Good. Maybe even better (arrow lines tagging proposed changes): v > + If a DNAME record is present at a zone apex, there is still a nee= d > + to have the customary SOA and NS, and perhaps other resource reco= rds ^^^^^^^^^^^^^^^^^^^ > + there as well. Such a DNAME cannot be used to mirror a zone > + completely, as it does not mirror the zone apex. > > These rules also allow DNAME records to be queried through RFC 10= 34 > compliant, DNAME-unaware caches. > > -- > Chris Thompson University of Cambridge Computing Service,= > Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, > Phone: +44 1223 334715 United Kingdom. Kind regards, Alfred H=CEnes. -- = +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From owner-namedroppers@ops.ietf.org Thu Oct 22 04:11:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34A5B3A69DC; Thu, 22 Oct 2009 04:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgpKNUGez27e; Thu, 22 Oct 2009 04:11:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3222D3A699A; Thu, 22 Oct 2009 04:11:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0vSC-000N6v-TE for namedroppers-data0@psg.com; Thu, 22 Oct 2009 11:03:36 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0vSA-000N6Y-Tp for namedroppers@ops.ietf.org; Thu, 22 Oct 2009 11:03:35 +0000 Received: from conversion-daemon.dakota.ucd.ie by dakota.ucd.ie (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) id <0KRW00901W2NKR00@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Thu, 22 Oct 2009 12:03:32 +0100 (IST) Received: from [10.0.1.177] (bark.no8.be [83.141.81.52]) by dakota.ucd.ie (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTPSA id <0KRW00007XDVS600@dakota.ucd.ie>; Thu, 22 Oct 2009 12:03:32 +0100 (IST) Date: Thu, 22 Oct 2009 12:03:31 +0100 From: Niall O'Reilly Subject: Re: [dnsext] Re: DNAME-bis issues (was: [DNSOP] new draft about idn tld variant implementation) In-reply-to: To: cet1@cam.ac.uk Cc: Andrew Sullivan , namedroppers@ops.ietf.org, =?UTF-8?B?QWxmcmVkIEjDtm5lcw==?= Message-id: <4AE03C03.3040509@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <016801ca5215$791b8d00$236ff1da@whatisfuture> <200910210654.n9L6sILi061468@drugs.dv.isc.org> <20091021133736.GD41456@shinkuro.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Chris Thompson wrote: > --- draft-ietf-dnsext-rfc2672bis-dname-17.xml Wed Oct 21 16:17:14 2009 > +++ draft-ietf-dnsext-rfc2672bis-dname-17a.xml Wed Oct 21 16:19:51 2009 > @@ -214,7 +214,7 @@ > for the YXDOMAIN (value 6) RCODE. > >
> -
> +
> > Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its > owner name; the owner name of a DNAME is not redirected itself. +1 > @@ -224,9 +224,10 @@ > DNAME RRs are not allowed at the parent side of a delegation point > but are allowed at a zone apex. > > - There still is a need to have the customary SOA and NS > - resource records at the zone apex. This means that DNAME does not > - mirror a zone completely, as it does not mirror the zone apex. > + If a DNAME record is present at the zone apex, there is still a need > + to have the customary SOA and NS resource records there as well. Such > + a DNAME cannot be used to mirror a zone completely, as it does not > + mirror the zone apex. > > These rules also allow DNAME records to be queried through RFC 1034 > compliant, DNAME-unaware caches. > +1, but I think the sentence before the Chris's proposed update is also a possible source of confusion. I'm thinking of what text to send. -- Niall O'Reilly University College Dublin IT Services From owner-namedroppers@ops.ietf.org Thu Oct 22 04:45:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98883A68A3; Thu, 22 Oct 2009 04:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wt-J0ulg3gdU; Thu, 22 Oct 2009 04:45:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CEC4A3A6875; Thu, 22 Oct 2009 04:45:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0vyN-0000xp-UN for namedroppers-data0@psg.com; Thu, 22 Oct 2009 11:36:51 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0vyL-0000x3-Uy for namedroppers@ops.ietf.org; Thu, 22 Oct 2009 11:36:50 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0KRW00C01YE2PP00@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Thu, 22 Oct 2009 12:36:46 +0100 (IST) Received: from [10.0.1.177] (bark.no8.be [83.141.81.52]) by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTPSA id <0KRW00K0MYX8YS00@cali.ucd.ie>; Thu, 22 Oct 2009 12:36:45 +0100 (IST) Date: Thu, 22 Oct 2009 12:36:44 +0100 From: Niall O'Reilly Subject: Re: [dnsext] Re: DNAME-bis issues (was: [DNSOP] new draft about idn tld variant implementation) In-reply-to: <4AE03C03.3040509@ucd.ie> To: cet1@cam.ac.uk Cc: Andrew Sullivan , namedroppers@ops.ietf.org, =?UTF-8?B?QWxmcmVkIEjDtm5lcw==?= Message-id: <4AE043CC.2040905@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <016801ca5215$791b8d00$236ff1da@whatisfuture> <200910210654.n9L6sILi061468@drugs.dv.isc.org> <20091021133736.GD41456@shinkuro.com> <4AE03C03.3040509@ucd.ie> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Niall O'Reilly wrote: > but I think the sentence before the Chris's proposed update > is also a possible source of confusion. I'm thinking of what > text to send. The phrase, "parent side of a delegation point" seems to have been introduced without definition, even though the established term, "zone cut" seems equivalent. I suggest replacing DNAME RRs are not allowed at the parent side of a delegation point but are allowed at a zone apex. by A DNAME RR is not allowed in conjunction with an NS record except at the apex of a zone. or else A DNAME RR may not have the same owner name as an NS record except at the apex of a zone. IHTH -- Niall O'Reilly University College Dublin IT Services From owner-namedroppers@ops.ietf.org Thu Oct 22 12:05:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B813A68F8; Thu, 22 Oct 2009 12:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=0.450, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxRAX8JHo++A; Thu, 22 Oct 2009 12:05:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 149573A6887; Thu, 22 Oct 2009 12:05:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N12o1-000CUc-D5 for namedroppers-data0@psg.com; Thu, 22 Oct 2009 18:54:37 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N12nw-000CU2-5B for namedroppers@ops.ietf.org; Thu, 22 Oct 2009 18:54:32 +0000 Received: (qmail 4755 invoked by uid 399); 22 Oct 2009 18:54:29 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Oct 2009 18:54:29 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4AE0AA6A.60500@dougbarton.us> Date: Thu, 22 Oct 2009 11:54:34 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Andrew Sullivan CC: "namedroppers@ops.ietf.org" Subject: Re: Protocol numbers for RSA/SHA{256|512} (Was: Re: [dnsext] GOST DNSSEC, implementations?) References: <4ADCD74B.6060302@dougbarton.us> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Andrew Sullivan wrote: > Hi, > > I didn't see an argument that seemed like, "This is harmful," where harm > was defined otherwise than, "It's in bad taste." I don't think bad > taste is enough, and as I argued before, I think the precedent argument > is bogus (and I'm prepared to meet it in future). I think that there are numerous flaws in your logic here, but given that A) You don't find my arguments persuasive, and B) No one else in the WG has spoken up explicitly to say that they also believe that different numbers should be assigned, I am willing to let the matter drop assuming no one else agrees that it should be pursued. FWIW, the most egregious flaw in your logic is that it is possible to "meet" the precedent argument in the future. Your decision seems to rest on two pillars, the first being that Jelte had "a good reason" to ship code with those two numbers and that "interoperability" is important to maintain in this situation (in spite of the fact that the feature was marked experimental, is incredibly unlikely to have any critical deployments at this point, is not enabled in more recent releases, etc. etc.). Given these two points, the next person/group/organization that picks their own code points and ships code with them will fall into exactly the same category. They will have a "good reason" to have done so, reinforced by this precedent (and others in the past) and will have at least as strong an argument on the interoperability front (given that the current argument is flimsy at best). So are you going to draw the line in the sand next time when it might actually break something, or do you draw the line in the sand this time when the organization in question has explicitly stated that "The code using these code points has been disabled in more recent releases," and "you would also not meet with any resistance if other code points would be assigned?" Or maybe we just have no lines? After all there are hundreds of unassigned code points in that registry (and most of the others for that matter). Who really cares if we just start appropriating them? Finally I'd like to reiterate my point that this is not an attack against Jelte personally, NLnet Labs, Andrew, or anyone else. Mistakes happen, and I'm sure I'll make some of my own someday. :) However in my mind this principle is incredibly important, based on my experience of having dealt with the fallout when I was at IANA. However if no one else agrees that this is something worth pursuing, so be it. Doug (... and no sand for that matter) -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Thu Oct 22 14:00:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D903A67E3; Thu, 22 Oct 2009 14:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.478 X-Spam-Level: X-Spam-Status: No, score=-0.478 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE2k2t1O0NDj; Thu, 22 Oct 2009 14:00:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7750F3A67B2; Thu, 22 Oct 2009 14:00:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N14ch-000Php-9c for namedroppers-data0@psg.com; Thu, 22 Oct 2009 20:51:03 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N14ce-000Pgq-Eq for namedroppers@ops.ietf.org; Thu, 22 Oct 2009 20:51:00 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C070F2FE8CDC for ; Thu, 22 Oct 2009 20:50:58 +0000 (UTC) Date: Thu, 22 Oct 2009 16:50:57 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Separating DNAME-bis from whether to use DNAME at a given level Message-ID: <20091022205056.GI44604@shinkuro.com> References: <200910211957.VAA12840@TR-Sys.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200910211957.VAA12840@TR-Sys.de> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, On Wed, Oct 21, 2009 at 09:57:42PM +0200, Alfred Hönes wrote: > Let me first discuss the more generic questions underlying the > 'variant' domain (TLD or other) draft and discussion. [. . .] > Back from the 'variant' domain arguments to the protocol specification > undergoing revision (I-D.dnsext-rfc2782bis-dname): I'd like to keep these two topics distinct, please. The legal and political (in the broad sense, like "policy") ramifications of using DNAME are not really on-topic for DNSEXT, so let's try to separate the two discussions. Thanks, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From nmppacqijhudqn@aichi-corp.com Fri Oct 23 07:49:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2103A6821 for ; Fri, 23 Oct 2009 07:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.217 X-Spam-Level: X-Spam-Status: No, score=-9.217 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oM6oQUC3fSvv for ; Fri, 23 Oct 2009 07:49:50 -0700 (PDT) Received: from adsl-ull-110-26.51-151.net24.it (adsl-ull-110-26.51-151.net24.it [151.51.26.110]) by core3.amsl.com (Postfix) with SMTP id 949DA3A67ED for ; Fri, 23 Oct 2009 07:49:48 -0700 (PDT) To: Subject: Feel the joy of being a healthy person! From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 090531-0, 31/05/2009), Outbound message X-Antivirus-Status: Clean Message-Id: <20091023144949.949DA3A67ED@core3.amsl.com> Date: Fri, 23 Oct 2009 07:49:48 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.clotheuntil.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://clotheuntil.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 6, B411. 162 Clements Road. London. SE43 5DG

© 2009 AMAZON, Ltd. All Rights Reserved

From owner-namedroppers@ops.ietf.org Fri Oct 23 08:54:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924E73A68E7; Fri, 23 Oct 2009 08:54:09 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syGgP+VvAJ6h; Fri, 23 Oct 2009 08:54:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E6913A659C; Fri, 23 Oct 2009 08:54:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1MLO-000GQf-OK for namedroppers-data0@psg.com; Fri, 23 Oct 2009 15:46:22 +0000 Received: from [193.251.215.91] (helo=relais-inet.francetelecom.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1MLM-000GPr-Cy for namedroppers@ops.ietf.org; Fri, 23 Oct 2009 15:46:20 +0000 Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 395A42483A4 for ; Fri, 23 Oct 2009 17:46:19 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 083AA238048; Fri, 23 Oct 2009 17:46:19 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 23 Oct 2009 17:46:19 +0200 From: To: "namedroppers@ops.ietf.org" CC: BURGEY Eric RD-CORE Date: Fri, 23 Oct 2009 17:46:17 +0200 Subject: [dnsext] A64-DNS Resource Record for IPv4-mapped IPv6 Address Thread-Topic: A64-DNS Resource Record for IPv4-mapped IPv6 Address Thread-Index: AcpT9eurO1sJtfLdRfCoXMhcRvq/NAAAcrVQ Message-ID: <3151_1256312779_4AE1CFCB_3151_6277_1_94C682931C08B048B7A8645303FDC9F30781B16118@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/mixed; boundary="_002_94C682931C08B048B7A8645303FDC9F30781B16118PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.10.23.144819 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --_002_94C682931C08B048B7A8645303FDC9F30781B16118PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Dear all, We have submitted recently this draft. Comments, questions, suggestions are more than welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de Internet-Drafts@ietf.org Envoy=E9 : vendredi 23 octobre 2009 17:30 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-boucadair-behave-dns-a64-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A64: DNS Resource Record for IPv4-mapped IPv6 Address Author(s) : M. Boucadair, E. Burgey Filename : draft-boucadair-behave-dns-a64-01.txt Pages : 15 Date : 2009-10-23 In the context of IPv4-IPv6 interconnection (or interworking), several solu= tions have been proposed within IETF. Some of these solutions require the = definition of a new IPv4-mapped IPv6 address [I-D.ietf-behave-address-forma= t] which is used to represent an IPv4- only host in an IPv6 realms and the = definition of a new mechanism called DNS64 for synthesizing a AAAA record, = representing an IPv4- mapped IPv6 address in the DNS system, from the A rec= ord representing the IPv4 address of the IPv4-only host [I-D.ietf-behave-dn= s64]. This IPv4-mapped IPv6 address, when managed by a translator, is to b= e considered as "fake" address in a DNS system since it is not necessarily = assigned to any host's interface qualified by the associated name. This do= cument defines a new DNS record type and query type to identify IPv4-mapped= IPv6 address [I-D.ietf-behave-address-format] from native IPv6 ones. The = new record type and query type aim at helping the requesting party to enfor= ce its policies and avoid crossing NAT64 boxes when possible. Native addresses are to be preferred. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-behave-dns-a64-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** --_002_94C682931C08B048B7A8645303FDC9F30781B16118PUEXCB1Bnante_ Content-Type: message/external-body; name="draft-boucadair-behave-dns-a64-01.url" Content-Description: draft-boucadair-behave-dns-a64-01.url Content-Disposition: attachment; filename="draft-boucadair-behave-dns-a64-01.url"; size=98; creation-date="Fri, 23 Oct 2009 17:31:41 GMT"; modification-date="Fri, 23 Oct 2009 17:31:41 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VjYWRhaXItYmVoYXZlLWRucy1hNjQtMDEudHh0DQo= --_002_94C682931C08B048B7A8645303FDC9F30781B16118PUEXCB1Bnante_-- From dnsops@dnsops.jp Sat Oct 24 00:23:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CACFD3A689A for ; Sat, 24 Oct 2009 00:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29.735 X-Spam-Level: X-Spam-Status: No, score=-29.735 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyNMmiKAvQiy for ; Sat, 24 Oct 2009 00:23:19 -0700 (PDT) Received: from n30.pro-internet.pl (n30.pro-internet.pl [193.189.116.30]) by core3.amsl.com (Postfix) with SMTP id 70C2E3A6869 for ; Sat, 24 Oct 2009 00:23:18 -0700 (PDT) From: VIAGRA Official Site To: dnsext-archive@ietf.org Subject: Dear dnsext-archive@ietf.org 56% 0FF on Pfizer ! MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20091024072318.70C2E3A6869@core3.amsl.com> Date: Sat, 24 Oct 2009 00:23:18 -0700 (PDT)
Can't See Images? Click here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2009 qpao INC | Unsubscribe | More Newsletters | Privacy
From owner-namedroppers@ops.ietf.org Sat Oct 24 01:20:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 389843A6994; Sat, 24 Oct 2009 01:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4xTiUKqM1Yr; Sat, 24 Oct 2009 01:20:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4DA5E3A6989; Sat, 24 Oct 2009 01:20:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1biZ-000Euu-Gt for namedroppers-data0@psg.com; Sat, 24 Oct 2009 08:11:19 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1biX-000Eug-EA for namedroppers@ops.ietf.org; Sat, 24 Oct 2009 08:11:17 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 314EDE601C for ; Sat, 24 Oct 2009 08:11:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n9O8B8hU095123 for ; Sat, 24 Oct 2009 19:11:13 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200910240811.n9O8B8hU095123@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: [dnsext] Is rfc3110 correct? Date: Sat, 24 Oct 2009 19:11:08 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This looks like is should be PKCS1 type 1 padding but that starts with 00. % grep signature rfc2537.txt rfc3110.txt | grep FF rfc2537.txt: signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) rfc3110.txt: signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n) % draft-ietf-dnsext-dnssec-rsasha256-14 looks ok. % grep signature draft-ietf-dnsext-dnssec-rsasha256-14.txt | grep FF signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) % I noticed this as rsasha256 and rsasha512 is not supported by OpenSSL 0.9.7 and to one had to use something more primative than RSA_sign(). Matk -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark@isc.org From owner-namedroppers@ops.ietf.org Sat Oct 24 01:27:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588433A6869; Sat, 24 Oct 2009 01:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Pcax9IME2LA; Sat, 24 Oct 2009 01:27:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 836A13A6817; Sat, 24 Oct 2009 01:27:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1btz-000G7q-HN for namedroppers-data0@psg.com; Sat, 24 Oct 2009 08:23:07 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1btx-000G7X-QP for namedroppers@ops.ietf.org; Sat, 24 Oct 2009 08:23:05 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id EBD1CE6056 for ; Sat, 24 Oct 2009 08:23:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n9O8N2pU095195 for ; Sat, 24 Oct 2009 19:23:02 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200910240823.n9O8N2pU095195@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: [dnsext] Re: Is rfc3110 correct? In-reply-to: Your message of "Sat, 24 Oct 2009 19:11:08 +1100." Date: Sat, 24 Oct 2009 19:23:02 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Mark Andrews writes: > > This looks like is should be PKCS1 type 1 padding but that > starts with 00. > > % grep signature rfc2537.txt rfc3110.txt | grep FF > rfc2537.txt: signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod > n) > rfc3110.txt: signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod > n) > % Dont' worry, rfc3110 in size of n - 1 and rfc2537 is size of n so both have the same prefix. We shouldn't flip back and forth is style howeve. > draft-ietf-dnsext-dnssec-rsasha256-14 looks ok. > > % grep signature draft-ietf-dnsext-dnssec-rsasha256-14.txt | grep FF > signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) > % > > I noticed this as rsasha256 and rsasha512 is not supported > by OpenSSL 0.9.7 and to one had to use something more > primative than RSA_sign(). > > Matk -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mzifraxphq@advf.com Sat Oct 24 04:37:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602E428C0F1 for ; Sat, 24 Oct 2009 04:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.262 X-Spam-Level: X-Spam-Status: No, score=-13.262 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaDvhtli8Us1 for ; Sat, 24 Oct 2009 04:37:15 -0700 (PDT) Received: from ambrosi.com (unknown [121.247.94.183]) by core3.amsl.com (Postfix) with SMTP id 21E353A67DF for ; Sat, 24 Oct 2009 04:37:13 -0700 (PDT) To: Subject: We're here to fight your health problems From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 080516-1, 05/16/2008), Outbound message X-Antivirus-Status: Clean Message-Id: <20091024113714.21E353A67DF@core3.amsl.com> Date: Sat, 24 Oct 2009 04:37:13 -0700 (PDT)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.finddraw.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://finddraw.com/faq.php

Privacy Statement | Terms & Conditions | Contact

AMAZON Ltd.
Tower Bridge Business Complex. Unit 7, B614. 959 Clements Road. London. SE70 8DG

© 2009 AMAZON, Ltd. All Rights Reserved

From owner-namedroppers@ops.ietf.org Sun Oct 25 06:13:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24C4B3A684F; Sun, 25 Oct 2009 06:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLssd2rTIONW; Sun, 25 Oct 2009 06:13:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1145B3A682B; Sun, 25 Oct 2009 06:13:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N22mn-000FZq-11 for namedroppers-data0@psg.com; Sun, 25 Oct 2009 13:05:29 +0000 Received: from [64.18.2.219] (helo=exprod7og116.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N22mk-000FZY-R0 for namedroppers@ops.ietf.org; Sun, 25 Oct 2009 13:05:26 +0000 Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSuRNFFDWinKiO0UUgQEYBgY+6O7h067u@postini.com; Sun, 25 Oct 2009 06:05:26 PDT Received: from webmail.nominum.com (exchange-10.nominum.com [64.89.228.57]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "exchange-10.win.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A2D781B82B4 for ; Sun, 25 Oct 2009 06:05:31 -0700 (PDT) Received: from exchange-10.WIN.NOMINUM.COM ([64.89.228.57]) by exchange-10.WIN.NOMINUM.COM ([64.89.228.57]) with mapi; Sun, 25 Oct 2009 06:05:23 -0700 From: Bob Halley To: "namedroppers@ops.ietf.org" Date: Sun, 25 Oct 2009 06:05:21 -0700 Subject: [dnsext] Trust Anchors Thread-Topic: Trust Anchors Thread-Index: AcpVc9AC1/UAusfZQiSUji5fR88hwg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I've been reading drafts in preparation for Hiroshima, and I noticed =20 that in draft-ietf-dnsext-dnssec-bis-updates-09.txt, section 4.9 says 4.9. Nested Trust Anchors A DNSSEC validator may be configured such that, for a given =20 response, more than one trust anchor could be used to validate the chain of trust to the response zone. For example, imagine a validator configured with trust anchors for "example." and "zone.example." When the validator is asked to validate a response to "www.sub.zone.example.", either trust anchor could apply. When presented with this situation, DNSSEC validators SHOULD try all applicable trust anchors until one succeeds. There are some scenarios where different behaviors, such as choosing the trust anchor closest to the QNAME of the response, may be desired. A DNSSEC validator MAY enable such behaviors as configurable overrides. I reread the Trusted Anchors thread in the namedroppers archive, and I =20 didn't see such a strong consensus for the ANY approach. At best I =20 saw support for ANY + CLOSEST (and perhaps other schemes). Some =20 people had a strong preference for only CLOSEST. I didn't participate =20 in that thread, but I too favor the CLOSEST approach. Was there =20 further discussion on this that I missed? If not, I think the =20 language in the draft is too strong, because it favors ANY and says =20 that CLOSEST, while permissible, must be a "configurable override". The purpose of the ANY approach appears to be system robustness. The =20 (certainly reasonable) concern is that statically configured trust =20 anchors will go stale, and resolutions will fail. While trying *more* =20 statically configured data (i.e. other closer-to-the-root anchors) may =20 help in some cases, this solution is not really getting at the real =20 issue, which is static configuration. We already have a standards =20 track mechanism for keeping trust anchors fresh, namely RFC 5011. I don't see any point to ANY. It doesn't solve the staleness problem, =20 it just adds hacks, which although they may be useful, may also be =20 surprising and detrimental. It also goes against the existing trust =20 anchor practice of at least two validators (BIND and Nominum). I propose that the draft mandate the use of CLOSEST and suggest the =20 use of RFC 5011 to avoid staleness. If there's no consensus for that, =20 I'd be satisfied with just removing section 4.9. /Bob From palefacesm87@vil06-1-88-173-40-211.fbx.proxad.net Sun Oct 25 07:47:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11F63A6858 for ; Sun, 25 Oct 2009 07:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -73.104 X-Spam-Level: X-Spam-Status: No, score=-73.104 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_TIRED_OF_YOUR=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4HRhb1yy-T7 for ; Sun, 25 Oct 2009 07:47:43 -0700 (PDT) Received: from vil06-1-88-173-40-211.fbx.proxad.net (vil06-1-88-173-40-211.fbx.proxad.net [88.173.40.211]) by core3.amsl.com (Postfix) with ESMTP id 31DD73A6839 for ; Sun, 25 Oct 2009 07:47:42 -0700 (PDT) Received: from 88.173.40.211 by rothfielding.com; Sun, 25 Oct 2009 15:47:55 +0100 From: "Susanne Payton" To: Subject: no reason to regret Date: Sun, 25 Oct 2009 15:47:55 +0100 Message-ID: <01ca558a$8487f1b0$d328ad58@palefacesm87> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal tired of your boring life? Gain respect in society with a higher education based on your knowledge and accomplishments Are you having difficulty finding employment in your field of interest because you dontt have the paper to back it up ?even though you are qualified? (816)-(292)-(2839) phone us, drop your name and number so we can contact you back From owner-namedroppers@ops.ietf.org Sun Oct 25 09:37:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37B13A687A; Sun, 25 Oct 2009 09:37: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZrZa56dy2pS; Sun, 25 Oct 2009 09:37:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB3013A67D9; Sun, 25 Oct 2009 09:37:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N25z3-000BvU-HP for namedroppers-data0@psg.com; Sun, 25 Oct 2009 16:30:21 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N25yv-000Buu-8x for namedroppers@ops.ietf.org; Sun, 25 Oct 2009 16:30:13 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id D54F1CC659 for ; Sun, 25 Oct 2009 16:30:12 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] Trust Anchors In-Reply-To: Your message of "Sun, 25 Oct 2009 06:05:21 MST." References: X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sun, 25 Oct 2009 16:30:12 +0000 Message-ID: <49737.1256488212@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: if CLOSEST does not match but ANY does, then a system capture in an ancestor can introduce trustworthy data about my zones without changing my zone's NS. for example if the operators of COM were to sign (offline) some data about SPELLING-ERROR.VIX.COM and sell these signatures to OpenDNS, it would be seen as authentic. never mind that the operators of COM, and the OpenDNS people, are all good people and would not do this. if it's BANK-OF-AMERICA.COM rather than VIX.COM then we're giving some financial institutions a solid theoretical basis on which to never (ever) allow DNSSEC to be used to authenticate their online presence. ANY would be a disasterous mistake. CLOSEST is what we can go out and sell. if somebody publishes one key and signs with another and complaint that their parent key should have been allowed to work, we'll tell them, "all power tools can kill, so please don't wrap the cord around your legs like that." given the number of ways in which DNSSEC is hard to deploy, let's not add more. so, i'm +1 on message-id by bob halley. From owner-namedroppers@ops.ietf.org Sun Oct 25 11:33:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FFFA3A6894; Sun, 25 Oct 2009 11:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U6BfkgYTIVV; Sun, 25 Oct 2009 11:33:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E81553A6883; Sun, 25 Oct 2009 11:33:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N27oD-000Orn-NU for namedroppers-data0@psg.com; Sun, 25 Oct 2009 18:27:17 +0000 Received: from [64.18.2.175] (helo=exprod7og111.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N27o6-000Oqw-IQ for namedroppers@ops.ietf.org; Sun, 25 Oct 2009 18:27:10 +0000 Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSuSYfdwhfSJC4tqvJ32iZBNA4G7ciIWr@postini.com; Sun, 25 Oct 2009 11:27:10 PDT Received: from webmail.nominum.com (exchange-10.nominum.com [64.89.228.57]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "exchange-10.win.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id ACCB91B8293; Sun, 25 Oct 2009 11:27:16 -0700 (PDT) Received: from exchange-10.WIN.NOMINUM.COM ([64.89.228.57]) by exchange-10.WIN.NOMINUM.COM ([64.89.228.57]) with mapi; Sun, 25 Oct 2009 11:27:09 -0700 From: Bob Halley To: Paul Vixie CC: "namedroppers@ops.ietf.org" Date: Sun, 25 Oct 2009 11:27:06 -0700 Subject: Re: [dnsext] Trust Anchors Thread-Topic: [dnsext] Trust Anchors Thread-Index: AcpVoMLjDqFgefiQSCOddJU/g6GqOA== Message-ID: <985637DA-318C-4D0F-8F42-D5E8D61E1E7B@nominum.com> References: <49737.1256488212@nsa.vix.com> In-Reply-To: <49737.1256488212@nsa.vix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 25 Oct 2009, at 16:30, Paul Vixie wrote: > if CLOSEST does not match but ANY does, then a system capture in an =20 > ancestor > can introduce trustworthy data about my zones without changing my =20 > zone's NS. It doesn't have to change your NS RRs, but it does have to change your =20 DS RRs. > for example if the operators of COM were to sign (offline) some data =20 > about > SPELLING-ERROR.VIX.COM and sell these signatures to OpenDNS, it =20 > would be seen > as authentic. No. RFC 4035 section 5 specifies that trust anchors are used to validate =20 keys at the apex of the zone with the anchor's name. As I understand the standard, COM could not hijack SPELLING-ERROR.VIX.COM=20 without altering VIX.COM's DS RRs. If COM and VIX.COM were signed, =20 a trust anchor at COM would say "start resolutions under COM in secure =20 mode and make sure one of the keys for COM is this one". That would =20 establish a valid keyset for COM, and resolution would proceed in the =20 usual way down to VIX.COM. Assuming COM handed out the legitimate DS =20 and NS RRs for VIX.COM, then anything in VIX.COM would have to be =20 authenticated by one of the keys at the apex of VIX.COM. So, to be clear, a compromised parent *can* hijack a child, but it =20 must do so by altering the DS RRset for the child. (Where "removing =20 the DS RRset and converting the delegation to an insecure delegation" =20 is included in "altering the DS RRset".) Assuming that a validator had anchors for COM and VIX.COM, then here's =20 a comparison of ANY and CLOSEST in various scenarios. "Works" means "legitimate data validates and forged data does not =20 validate". Scenario ANY CLOSEST ---------------------------------------------------------------------------= -------------------------------------------- Both anchors not stale Works Works COM anchor not stale, VIX.COM anchor goes stale, but VIX.COM NS & DS in COM still good Works Fails VIX.COM anchor not stale, COM anchor goes stale Works Works Both anchors go stale Fails Fails VIX.COM anchor not stale, COM compromised, VIX.COM DS RRs changed in COM Appropriately Forged data forged data never validates validates True data may True data or may always validates not validate Supporters of ANY worry that during transition to DNSSEC you will set =20 up your validator with a VIX.COM anchor, because COM is not signed =20 yet. Later COM will be signed, and you'll add an anchor for it and =20 forget to remove the VIX.COM anchor. If the VIX.COM anchor goes =20 stale, under CLOSEST your resolutions will fail, whereas under ANY =20 they will not. Supporters of CLOSEST argue that the detection of a compromise or =20 other problem in the parent is good security. I'm sympathetic to the problems of staleness that ANY supporters worry =20 about. By my prior sysadmin experience tells me that if I configure VIX.CO= M=20 and COM both as trust anchors on my validator, and use ANY, than one =20 of them will go stale and I'll not notice, and then when I'm on =20 vacation the other one will go stale, and resolution will fail, and =20 I'll get emergency phone calls. I'd rather we kept CLOSEST for its security benefit in the compromise =20 case, and tried to tackle anchor staleness directly (via RFC 5011 or =20 some other means). /Bob From owner-namedroppers@ops.ietf.org Sun Oct 25 19:28:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4593A69C6; Sun, 25 Oct 2009 19:28: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHLb6M6dm6fk; Sun, 25 Oct 2009 19:28:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 561DC3A683A; Sun, 25 Oct 2009 19:28:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2FAa-000AKj-4t for namedroppers-data0@psg.com; Mon, 26 Oct 2009 02:18:52 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2FAX-000AKR-85 for namedroppers@ops.ietf.org; Mon, 26 Oct 2009 02:18:49 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id D0A13CC71C for ; Mon, 26 Oct 2009 02:18:48 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] Trust Anchors In-Reply-To: Your message of "Sun, 25 Oct 2009 11:27:06 MST." <985637DA-318C-4D0F-8F42-D5E8D61E1E7B@nominum.com> References: <49737.1256488212@nsa.vix.com> <985637DA-318C-4D0F-8F42-D5E8D61E1E7B@nominum.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 26 Oct 2009 02:18:48 +0000 Message-ID: <72644.1256523528@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Bob Halley > Date: Sun, 25 Oct 2009 11:27:06 -0700 > > No. thanks for explaining this. > Supporters of ANY worry that during transition to DNSSEC you will set up > your validator with a VIX.COM anchor, because COM is not signed yet. > Later COM will be signed, and you'll add an anchor for it and forget to > remove the VIX.COM anchor. If the VIX.COM anchor goes stale, under > CLOSEST your resolutions will fail, whereas under ANY they will not. > > Supporters of CLOSEST argue that the detection of a compromise or other > problem in the parent is good security. > > I'm sympathetic to the problems of staleness that ANY supporters worry > about. By my prior sysadmin experience tells me that if I configure > VIX.COM and COM both as trust anchors on my validator, and use ANY, than > one of them will go stale and I'll not notice, and then when I'm on > vacation the other one will go stale, and resolution will fail, and I'll > get emergency phone calls. > > I'd rather we kept CLOSEST for its security benefit in the compromise > case, and tried to tackle anchor staleness directly (via RFC 5011 or some > other means). i get it. i do not think the standard should address the multiple ancestor problem since this is a configuration detail. this could mean simply not specifying the behaviour if there are multiple static trust anchors all covering the signature that you're trying to validate. but if we're going to talk about multiple enclosing static trust anchors, i'd rather we say that the closest one has to match and the others aren't looked at at all, then to say any of them can match. the RFC could also say that multiple enclosing static trust anchors are a bad idea, and if they are configured then the software should syslog a warning about it, early and often. From echoesl33@romanceprosdating.com Mon Oct 26 03:49:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CEA43A694E; Mon, 26 Oct 2009 03:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.312 X-Spam-Level: X-Spam-Status: No, score=-7.312 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_TW=1.335, HELO_MISMATCH_TW=0.994, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_OBFU_SPLIT_HR2=0.183, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heWaCWMb77Wa; Mon, 26 Oct 2009 03:49:11 -0700 (PDT) Received: from gorilla.com.tw (unknown [60.248.161.28]) by core3.amsl.com (Postfix) with ESMTP id D1E5D3A68EF; Mon, 26 Oct 2009 03:49:07 -0700 (PDT) Received: from 60.248.161.28 by mail1.romanceprosdating.com; Mon, 26 Oct 2009 18:48:57 +0800 Date: Mon, 26 Oct 2009 18:48:57 +0800 From: "Sally Villanueva" X-Mailer: The Bat! (v3.0.0.15) Professional Reply-To: echoesl33@romanceprosdating.com X-Priority: 3 (Normal) Message-ID: <306383788.36907032291896@romanceprosdating.com> To: p2prg-bounces@ietf.org Subject: Small pilule, strong desire MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit

VIEW THIS NEWSLETTER ONLINE
Be love that rocks!
if no image is shown please click here

GET IN!

Subscribe  Unsubscribe Send to a Friend Preferences Report Spam
You are receiving this communication because you subscribed p2prg-bounces@ietf.org at our site. If for any reason you wish to stop receiving this communication, click on this Unsubscribe link. This will create a new email that contains your unsubscribe request. Please send that email to us, and we will reply back confirming the completion of your unsubscription request.
From owner-namedroppers@ops.ietf.org Mon Oct 26 04:38:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB67128C1CD; Mon, 26 Oct 2009 04:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.286 X-Spam-Level: X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1g5oeb5QIqm; Mon, 26 Oct 2009 04:38:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1A76128C16F; Mon, 26 Oct 2009 04:38:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2NmH-0007FN-Mo for namedroppers-data0@psg.com; Mon, 26 Oct 2009 11:30:21 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2NmF-0007Ew-IC for namedroppers@ops.ietf.org; Mon, 26 Oct 2009 11:30:19 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 86DA728C0CF; Mon, 26 Oct 2009 04:30:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026113003.86DA728C0CF@core3.amsl.com> Date: Mon, 26 Oct 2009 04:30:03 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Transport over TCP Author(s) : R. Bellis Filename : draft-ietf-dnsext-dns-tcp-requirements-01.txt Pages : 8 Date : 2009-10-26 This document updates the requirements for the support of the TCP protocol for the transport of DNS traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-tcp-requirements-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-dns-tcp-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26042111.I-D@ietf.org> --NextPart-- From owner-namedroppers@ops.ietf.org Mon Oct 26 05:03:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCCFC28C277; Mon, 26 Oct 2009 05:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.068 X-Spam-Level: X-Spam-Status: No, score=-4.068 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvee2oiBtagH; Mon, 26 Oct 2009 05:03:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 56AE328C273; Mon, 26 Oct 2009 05:03:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2OD9-000ANo-E5 for namedroppers-data0@psg.com; Mon, 26 Oct 2009 11:58:07 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2OD6-000ANS-3z for namedroppers@ops.ietf.org; Mon, 26 Oct 2009 11:58:04 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=HGj3Va9AgHzlvXCer8bgm7/zGGwIEdOwJ4Gl0HL5i1Cl0mtmroznVhRa /V4W8k2acYLAPPgo8vFPl8mWU2Lyxd6oRlev1fGPAIoq/YmC8dnarfQy2 bnYH6+mmchVxxnI; 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=1256558284; x=1288094284; 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.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20I-D=20Action:draft-ietf-dnsext-dns-tcp-requirements -01.txt|Date:=20Mon,=2026=20Oct=202009=2011:58:00=20+0000 |Message-ID:=20|To:=20namedroppers@ops.i etf.org|MIME-Version:=201.0|In-Reply-To:=20<2009102611300 3.86DA728C0CF@core3.amsl.com>|References:=20<200910261130 03.86DA728C0CF@core3.amsl.com>; bh=D9rKR7Vyikni2DH8BkFKAcYaJ3wzf8xyy63xP8nY/gc=; b=eoHMdEpmAvwxdoJX25Uoxap0mgCfKyAyJj52PO0wArGaYYF+EREdB1k8 KcRJNrkZVY/2E0B3kcB2YLSyS32Yjhy4VdyWBKmgWJjYPJa/V2MLdcm8P Mkn/f+zEo/qBJyy; X-IronPort-AV: E=Sophos;i="4.44,625,1249254000"; d="scan'208";a="13888526" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 26 Oct 2009 11:58:01 +0000 In-Reply-To: <20091026113003.86DA728C0CF@core3.amsl.com> References: <20091026113003.86DA728C0CF@core3.amsl.com> To: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Mon, 26 Oct 2009 11:58:00 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 26/10/2009 11:58:01 AM, Serialize complete at 26/10/2009 11:58:01 AM Content-Type: multipart/alternative; boundary="=_alternative 0041BC838025765B_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 0041BC838025765B_= Content-Type: text/plain; charset="US-ASCII" As you'll have just seen I've just made a (minor) update to this draft. I've addressed most (if not all) of the editorial nits and comments. However for now I've left out wider discussion of the TCP tuning issues, references to UTO, etc, as "(currently) out of scope", pending face-to-face discussion in Hiroshima. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 0041BC838025765B_= Content-Type: text/html; charset="US-ASCII" As you'll have just seen I've just made a (minor) update to this draft.

I've addressed most (if not all) of the editorial nits and comments.

However for now I've left out wider discussion of the TCP tuning issues, references to UTO, etc, as "(currently) out of scope", pending face-to-face discussion in Hiroshima.

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211


 --=_alternative 0041BC838025765B_=-- From owner-namedroppers@ops.ietf.org Mon Oct 26 06:47:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B45E28C285; Mon, 26 Oct 2009 06:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmBGBB4yAw83; Mon, 26 Oct 2009 06:47:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D846628C27E; Mon, 26 Oct 2009 06:47:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2PpV-000Ku7-77 for namedroppers-data0@psg.com; Mon, 26 Oct 2009 13:41:49 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2PpS-000Ktd-GK for namedroppers@ops.ietf.org; Mon, 26 Oct 2009 13:41:46 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n9QDfdxS037667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Oct 2009 14:41:40 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4AE5A713.9050705@nlnetlabs.nl> Date: Mon, 26 Oct 2009 14:41:39 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: Paul Vixie CC: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] Trust Anchors References: <49737.1256488212@nsa.vix.com> <985637DA-318C-4D0F-8F42-D5E8D61E1E7B@nominum.com> <72644.1256523528@nsa.vix.com> In-Reply-To: <72644.1256523528@nsa.vix.com> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 26 Oct 2009 14:41:40 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bob, +1 for CLOSEST. (But I already voiced that before). Bob Halley wrote: >> Supporters of CLOSEST argue that the detection of a compromise or other >> problem in the parent is good security. Paul Vixie wrote: > enclosing static trust anchors are a bad idea, and if they are configured > then the software should syslog a warning about it, early and often. There is even a worse problem than Paul mentions, use two layers of trust anchor, ANY, and the following happens: example.com: signed by local company, trust anchor. com: signed but example.com is not signed, trust anchor. (fairly regular case where the company uses a domain internally, and .com is using, say, opt-out NSEC3) In this case, the people from verisign and local IT are good, and the anchors may be up to date, but some (spoofed) response makes the validator to up from the valid example.com dnskey to the securely-insecure-delegation from .com. It can be fixed, 'MOSTLY-ANY', where the chain of trust MUST extend securely to the lowest trust-anchor available. Thus, an invalid trust anchor is then not a no-op but instead it states 'must be secure at this domain'. If ANY is adopted I suggest this so as to make it secure. I think it is getting complicated for little benefit, hence CLOSEST. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkrlpxMACgkQkDLqNwOhpPho3gCgqfCUyKCF2z/DIZaSoIX35zcY fzoAniLYU/LaiI4DB3TYWCy500yO6Ojc =ZK8K -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Oct 26 07:58:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B29628C0F1; Mon, 26 Oct 2009 07:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.516 X-Spam-Level: X-Spam-Status: No, score=-0.516 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89tWuA+cXedl; Mon, 26 Oct 2009 07:58:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D5B03A67CF; Mon, 26 Oct 2009 07:58:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2QvM-0003d8-Ib for namedroppers-data0@psg.com; Mon, 26 Oct 2009 14:51:56 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2QvK-0003cZ-JH for namedroppers@ops.ietf.org; Mon, 26 Oct 2009 14:51:54 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1DC852FE8CDC for ; Mon, 26 Oct 2009 14:51:53 +0000 (UTC) Date: Mon, 26 Oct 2009 10:51:51 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Trust Anchors Message-ID: <20091026145151.GD55437@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Sun, Oct 25, 2009 at 06:05:21AM -0700, Bob Halley wrote: > didn't see such a strong consensus for the ANY approach. At best I > saw support for ANY + CLOSEST (and perhaps other schemes). Could you say more about what "ANY + CLOSEST" would be? That is, since closest is obviously inside the any chain, if any works then by definition closest works, assuming closest is in fact a valid key. Is the idea of "ANY + CLOSEST" that any works as long as closest works? If so, how is that different from closest? By the way, when we last discussed this I formed the impression of at least a substantial number of people in favour of the ANY strategy, so I'm surprised you came to a different conclusion on reading the archive. I'll go back and have another look, though. > I propose that the draft mandate the use of CLOSEST and suggest the > use of RFC 5011 to avoid staleness. If there's no consensus for that, > I'd be satisfied with just removing section 4.9. Speaking with no hat, I am opposed to both of those options. I oppose mandating the use of CLOSEST because, on my reading, it imports degrees of trust into a system that is simply not designed with degrees of trust in the first place. I am especially uncomfortable with promoting degrees of trust on the implict basis of some other property. I oppose removing the section because it is quite plain that the issue is not clear to everyone. Those of us involved in an ICANN RSTEP review of PIR's .org plans, for example, were all surprised by this interpretation of the RFCs; and while I will happily concede that I am often confused (so my own surprise might not be a big deal), I feel rather strongly that the other participants' surprise was an indication of a serious ambiguity in the specification. I'd prefer to see the inclusion of a mandate for CLOSEST than to see the section dropped completely. With my co-chair hat back on, but speaking only for myself, I think it is super important that we come to some conclusion about this quickly, produce the relevant text, and move on. Let us please settle on something and forge a consensus on it, so that we can tell the rest of the world (which is busily deploying this technology) an unambiguous story about how it all works. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Oct 26 09:33:38 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A6DA3A6AF1; Mon, 26 Oct 2009 09:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBhqiAamRQrr; Mon, 26 Oct 2009 09:33:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7BE2728C0F5; Mon, 26 Oct 2009 09:33:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2SQ6-000ETV-Dr for namedroppers-data0@psg.com; Mon, 26 Oct 2009 16:27:46 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2SQ4-000ET3-2z for namedroppers@ops.ietf.org; Mon, 26 Oct 2009 16:27:44 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9QGRdih016690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Oct 2009 09:27:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20091026145151.GD55437@shinkuro.com> References: <20091026145151.GD55437@shinkuro.com> Date: Mon, 26 Oct 2009 09:27:38 -0700 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] Trust Anchors Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 10:51 AM -0400 10/26/09, Andrew Sullivan wrote: >I oppose mandating the use of CLOSEST because, on my reading, it >imports degrees of trust into a system that is simply not designed >with degrees of trust in the first place. I am especially >uncomfortable with promoting degrees of trust on the implict basis of >some other property. +1. The IETF has seen this kind of feature creep in other security protocols, and the end result is always unexpected behavior for the relying parties. Even in protocols where degrees of trust were built-in from the beginning, namely PGP, the use of degrees were mostly abandoned by users or, worse, used without understanding. Even for pieces that have black-and-white trust but multiple trust anchors with intermediate certificates, it gets ugly really quickly. Just say "path validation with constraints" to a PKIX developer, and see if they cry (or laugh maniacally). >I oppose removing the section because it is quite plain that the issue >is not clear to everyone. Those of us involved in an ICANN RSTEP >review of PIR's .org plans, for example, were all surprised by this >interpretation of the RFCs; and while I will happily concede that I am >often confused (so my own surprise might not be a big deal), I feel >rather strongly that the other participants' surprise was an >indication of a serious ambiguity in the specification. I'd prefer to >see the inclusion of a mandate for CLOSEST than to see the section >dropped completely. +1, for the same reasons. Patrik can say how many times he had to explain this to me, even as we were reading the exact same words at the same time. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Mon Oct 26 09:45:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4DCE28C2BB; Mon, 26 Oct 2009 09:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nM4NU5+t-Cj; Mon, 26 Oct 2009 09:45:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C44A28C234; Mon, 26 Oct 2009 09:45:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2SbH-000FkQ-BD for namedroppers-data0@psg.com; Mon, 26 Oct 2009 16:39:19 +0000 Received: from [64.18.2.155] (helo=exprod7og101.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2SbF-000Fjq-Ae for namedroppers@ops.ietf.org; Mon, 26 Oct 2009 16:39:17 +0000 Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSuXQsTNClGgUZQRKOuDqwtZ8SX68x+t+@postini.com; Mon, 26 Oct 2009 09:39:17 PDT Received: from webmail.nominum.com (exchange-10.nominum.com [64.89.228.57]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "exchange-10.win.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 90C9F1B8185; Mon, 26 Oct 2009 09:39:20 -0700 (PDT) Received: from exchange-10.WIN.NOMINUM.COM ([64.89.228.57]) by exchange-10.WIN.NOMINUM.COM ([64.89.228.57]) with mapi; Mon, 26 Oct 2009 09:39:12 -0700 From: Bob Halley To: Andrew Sullivan CC: "namedroppers@ops.ietf.org" Date: Mon, 26 Oct 2009 09:39:10 -0700 Subject: Re: [dnsext] Trust Anchors Thread-Topic: [dnsext] Trust Anchors Thread-Index: AcpWWtk7+DQZ51AMQmClusR1CD5/XA== Message-ID: References: <20091026145151.GD55437@shinkuro.com> In-Reply-To: <20091026145151.GD55437@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 26 Oct 2009, at 14:51, Andrew Sullivan wrote: > On Sun, Oct 25, 2009 at 06:05:21AM -0700, Bob Halley wrote: > >> didn't see such a strong consensus for the ANY approach. At best I >> saw support for ANY + CLOSEST (and perhaps other schemes). > > Could you say more about what "ANY + CLOSEST" would be? That is, > since closest is obviously inside the any chain, if any works then by > definition closest works, assuming closest is in fact a valid key. Sorry for being unclear. What I meant by "ANY + CLOSEST" would be =20 something like Validators SHOULD allow a configurable choice between the CLOSEST and =20 ANY trust anchor policies. The default is left to the =20 implementation. Operators should consider carefully which policy is =20 right for them. To be clear, I still prefer a MUST or a SHOULD for CLOSEST. But if =20 there is not consensus for that, I'd settle for not blessing ANY as =20 the default. /Bob From booksellerhck28@rovingsoftware.com Mon Oct 26 23:50:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9739C3A67C1; Mon, 26 Oct 2009 23:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.271 X-Spam-Level: X-Spam-Status: No, score=-9.271 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9WFHkXlwixG; Mon, 26 Oct 2009 23:50:25 -0700 (PDT) Received: from milverdene.com (unknown [213.123.183.163]) by core3.amsl.com (Postfix) with ESMTP id 8CA493A6405; Mon, 26 Oct 2009 23:50:25 -0700 (PDT) Received: from 213.123.183.163 by edgemail1.constantcontact.com; Tue, 27 Oct 2009 06:50:06 +0000 Date: Tue, 27 Oct 2009 06:50:06 +0000 From: "Anne Tillman" X-Mailer: The Bat! (v3.62.14) Educational Reply-To: booksellerhck28@rovingsoftware.com X-Priority: 3 (Normal) Message-ID: <897799512.30129781497429@rovingsoftware.com> To: psamp-request@ietf.org Subject: Target: her G-spot! MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit

VIEW THIS NEWSLETTER ONLINE
Wang up!
if no image is shown please click here

GET IN!

Subscribe  Unsubscribe Send to a Friend Preferences Report Spam
You are receiving this communication because you subscribed psamp-request@ietf.org at our site. If for any reason you wish to stop receiving this communication, click on this Unsubscribe link. This will create a new email that contains your unsubscribe request. Please send that email to us, and we will reply back confirming the completion of your unsubscription request.
From owner-namedroppers@ops.ietf.org Tue Oct 27 01:49:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F3F228C0E4; Tue, 27 Oct 2009 01:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKU+7gCdBTgx; Tue, 27 Oct 2009 01:49:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E142B3A69C6; Tue, 27 Oct 2009 01:49:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2hcm-000IlI-Gj for namedroppers-data0@psg.com; Tue, 27 Oct 2009 08:41:52 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2hcj-000IkY-Gb for namedroppers@ops.ietf.org; Tue, 27 Oct 2009 08:41:49 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n9R8ffIL056855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Oct 2009 09:41:45 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4AE6B245.1060603@nlnetlabs.nl> Date: Tue, 27 Oct 2009 09:41:41 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: Paul Hoffman CC: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Trust Anchors References: <20091026145151.GD55437@shinkuro.com> In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 27 Oct 2009 09:41:46 +0100 (CET) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/26/2009 05:27 PM, Paul Hoffman wrote: > +1. The IETF has seen this kind of feature creep in other security protocols, and the end result is always unexpected behavior for the relying parties. Even in protocols where degrees of trust were built-in from the beginning, namely PGP, the use of degrees were mostly abandoned by users or, worse, used without understanding. So its fine to put the anchors on an equal 'security' footing. For the digital signature part. The name in it does signify that the operator wanted that name to be dnssec secure. Now allowing that name to become secure using another key is fine with me, but to stop possible downgrade attacks you really have to include some language that says, for ANY, that if one anchor fails and another is attempted, that the resulting chain of trust should securely reach the original closest anchor. So that, although you may use the root .com or example.com key to validate www.example.com, the name 'example.com' was secure in the chain of trust. It is then a protection against some stale key for example.com But that does not mean that example.com is allowed to become unsigned. I realize this likely defeats some amount of the trouble we try to save the operators here, because that stale key now prevents rollover to unknown algorithms, the domain to change hands and then become unsigned, ... Many reasons to configure such anchors are exactly, say that example.com is signed, but .com is not, and the root is. The ANY mechanism allows the security to be downgraded by spoofing for example.com, which is why I attempt to get some extra language about covering the domain name of the closest anchor with a secure part of the chain (I mean, not unsigned). And I am spending a lot of words on it, because people say this is confusing. It is not degrees of trust I want, but rather to avoid downgrades: CLOSEST is simple, simple to understand, and very secure. Configuration that makes certain trust anchors applicable only to a particular part of the DNS tree - in high detail for security minded people - should not be ruled out, I think. Does scoping keys create such (evil) feature creep with degrees of trust in it? Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkrmskUACgkQkDLqNwOhpPjAGQCfa3yCyU1IuUPe5O6iz6nN8I7b zL8AoKzKg0yGe6j6TXkF0TRcDw5lLORq =+Bs5 -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Tue Oct 27 06:19:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B7228C133; Tue, 27 Oct 2009 06:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ld9qqZbgDa7; Tue, 27 Oct 2009 06:19:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6699328C1C3; Tue, 27 Oct 2009 06:19:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2lpG-0000di-H4 for namedroppers-data0@psg.com; Tue, 27 Oct 2009 13:11:02 +0000 Received: from [194.176.119.229] (helo=smtp1.bondis.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2lpE-0000d3-Di for namedroppers@ops.ietf.org; Tue, 27 Oct 2009 13:11:00 +0000 Received: from core.c-l-i.net (core.c-l-i.net [204.62.249.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.bondis.org (Postfix) with ESMTPSA id B78A91AB2FF for ; Tue, 27 Oct 2009 13:10:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) Subject: Re: [dnsext] Trust Anchors From: =?iso-8859-1?Q?Jo=E3o_Damas?= In-Reply-To: <4AE6B245.1060603@nlnetlabs.nl> Date: Tue, 27 Oct 2009 14:10:56 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20091026145151.GD55437@shinkuro.com> <4AE6B245.1060603@nlnetlabs.nl> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.1076) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: the operational problem here is, again, that resolver operators don't necessarily sync-up with zone producers. I also think that closest should be the way to go when you have 2 or more keys that can validate a given signature. Given this is an operational problem, I believe tweaking the protocol will never yield a perfect solution and that this sort of situation would see the users better served by crafting a BCP where, for instance, the choreography necessary for domain moves between registrars would be listed. The situation when a parent zone becomes DNSSEC enabled (allowing DS records to be stored there and signed) might lead to an operational recommendation for the child zone producer to keep the keys unchanged from the time when the zone was an island, that is: do not roll just because your parent became DNSSEC-enabled. Joao From owner-namedroppers@ops.ietf.org Tue Oct 27 07:29:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196DE3A68AB; Tue, 27 Oct 2009 07:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILCCrxwfTABd; Tue, 27 Oct 2009 07:29:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F4FB3A693F; Tue, 27 Oct 2009 07:29:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2muf-0008UK-KT for namedroppers-data0@psg.com; Tue, 27 Oct 2009 14:20:41 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2mud-0008U2-2e for namedroppers@ops.ietf.org; Tue, 27 Oct 2009 14:20:39 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 79EBB2FE8CDC for ; Tue, 27 Oct 2009 14:20:33 +0000 (UTC) Date: Tue, 27 Oct 2009 10:20:31 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Trust Anchors Message-ID: <20091027142031.GP55437@shinkuro.com> References: <20091026145151.GD55437@shinkuro.com> <4AE6B245.1060603@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4AE6B245.1060603@nlnetlabs.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: No hat. On Tue, Oct 27, 2009 at 09:41:41AM +0100, W.C.A. Wijngaards wrote: > So that, although you may use the root .com or example.com key > to validate www.example.com, the name 'example.com' was secure in > the chain of trust. > > It is then a protection against some stale key for example.com > But that does not mean that example.com is allowed to become unsigned. […] > Many reasons to configure such anchors are exactly, say that example.com > is signed, but .com is not, and the root is. The ANY mechanism allows > the security to be downgraded by spoofing for example.com, which is why > I attempt to get some extra language about covering the domain name of > the closest anchor with a secure part of the chain (I mean, not > unsigned). And I am spending a lot of words on it, because people say > this is confusing. For me, at least, all that the changes to dnssec-bis-updates should say is that, if there are two paths for a validation of a given name, using different trust anchors at different distances in the tree, either one is as good as any other. You are, however, pointing out a nasty consequence of the current proposal: when the closest TA does not validate, and a distant TA does validate but there is an intermediate zone that is unsigned, you move the target domain from "bogus" to "insecure". I think this is a good point (but I didn't understand what you were saying until this message. Sorry I'm so thick). Now, what bothers me about saying, for simplicity's sake, "Do CLOSEST," (because the real issue is too hard to explain or understand) is that we are almost guaranteeing false failures by picking "CLOSEST". The usual response to this concern is, "Yes, people have to be super-competent in operating their zones during DNSSEC adoption." To me, that position flies in the face of all our experience with the actual operation of the DNS. We know that there are plenty of zones out there that are operated quite badly without DNSSEC. We're asking either that, overnight, all those human errors go away, or else that people accept that they have to trade unreliability to get the security we are trying to sell them. I believe that what will happen, if we stick with CLOSEST, is that a number of domains will have nasty experiences with DNSSEC. The report that ends up going to management when each outage happens will be, "Due to DNSSEC, our domain became unavailable to CustomerC from $starttime to $endtime." Management in each case will say, "How much do we need this DNSSEC anyway?" Since the advantage of DNSSEC to the publisher of the DNS data is not that great, the incentive will not be strong to continue using it, and pretty soon this useful technology will get a reputation as another complicated, doesn't-work thing that should just be turned off. Finally, the argument that there is an important downgrade available under ANY depends on the premise that, in validating cases, there is a valuable difference between "bogus" and "insecure". Mike StJohns has argued strongly that, for practical purposes, if you are really going to check validation you're not going to care what the reasons are that something doesn't validate. If that's right, then there is no _practical_ downgrade path here anyway. I don't know whether he's right, however. I therefore think that we ought to work on text that makes it clear that the postive-validation paths are all just as good as one another, but that a good security policy might prefer bogus over insecure paths in case postive validation is not at all possible. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Oct 27 08:52:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA7C3A697E; Tue, 27 Oct 2009 08:52:43 -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, RDNS_NONE=0.1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7Ty4a0OTp29; Tue, 27 Oct 2009 08:52:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB24A3A67CF; Tue, 27 Oct 2009 08:52:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2oGY-000J6b-CO for namedroppers-data0@psg.com; Tue, 27 Oct 2009 15:47:22 +0000 Received: from [206.190.53.31] (helo=smtp126.rog.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2oGV-000J6I-QF for namedroppers@ops.ietf.org; Tue, 27 Oct 2009 15:47:19 +0000 Received: (qmail 98606 invoked from network); 27 Oct 2009 15:47:18 -0000 Received: from 209-148-165-15.dynamic.rogerstelecom.net (thierry.moreau@209.148.165.15 with plain) by smtp126.rog.mail.re2.yahoo.com with SMTP; 27 Oct 2009 08:47:18 -0700 PDT X-Yahoo-SMTP: 7IPMVjmswBCDdW1xQhDBl8GZu.GNdc4Rou3wNA-- X-YMail-OSG: QfCh.BsVM1nVaPPE36xFTdFHU66g4GTbOmvglW4Ja.Q6WjgEwDjDMJSAzempdNVTig-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE716EF.8050302@connotech.com> Date: Tue, 27 Oct 2009 11:51:11 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Trust Anchors References: <20091026145151.GD55437@shinkuro.com> <4AE6B245.1060603@nlnetlabs.nl> <20091027142031.GP55437@shinkuro.com> In-Reply-To: <20091027142031.GP55437@shinkuro.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: See inline below. In a related discussion on another forum, I indicated that I would stop discussing. But I couldn't resist making the connection below. These things belong to the DNS experts on this list, don't they? Regards, - Thierry Moreau Andrew Sullivan wrote: > No hat. > > On Tue, Oct 27, 2009 at 09:41:41AM +0100, W.C.A. Wijngaards wrote: > >> So that, although you may use the root .com or example.com key >> to validate www.example.com, the name 'example.com' was secure in >> the chain of trust. >> >> It is then a protection against some stale key for example.com >> But that does not mean that example.com is allowed to become unsigned. >> > > […] > > >> Many reasons to configure such anchors are exactly, say that example.com >> is signed, but .com is not, and the root is. The ANY mechanism allows >> the security to be downgraded by spoofing for example.com, which is why >> I attempt to get some extra language about covering the domain name of >> the closest anchor with a secure part of the chain (I mean, not >> unsigned). And I am spending a lot of words on it, because people say >> this is confusing. >> > > For me, at least, all that the changes to dnssec-bis-updates should > say is that, if there are two paths for a validation of a given name, > using different trust anchors at different distances in the tree, > either one is as good as any other. You are, however, pointing out a > nasty consequence of the current proposal: when the closest TA does > not validate, and a distant TA does validate but there is an > intermediate zone that is unsigned, you move the target domain from > "bogus" to "insecure". I think this is a good point (but I didn't > understand what you were saying until this message. Sorry I'm so > thick). > > Now, what bothers me about saying, for simplicity's sake, "Do > CLOSEST," (because the real issue is too hard to explain or > understand) is that we are almost guaranteeing false failures by > picking "CLOSEST". The usual response to this concern is, "Yes, > people have to be super-competent in operating their zones during > DNSSEC adoption." To me, that position flies in the face of all our > experience with the actual operation of the DNS. We know that there > are plenty of zones out there that are operated quite badly without > DNSSEC. We're asking either that, overnight, all those human errors > go away, or else that people accept that they have to trade > unreliability to get the security we are trying to sell them. > > I believe that what will happen, if we stick with CLOSEST, is that a > number of domains will have nasty experiences with DNSSEC. The report > that ends up going to management when each outage happens will be, > "Due to DNSSEC, our domain became unavailable to CustomerC from > $starttime to $endtime." Management in each case will say, "How much > do we need this DNSSEC anyway?" Since the advantage of DNSSEC to the > publisher of the DNS data is not that great, the incentive will not be > strong to continue using it, and pretty soon this useful technology > will get a reputation as another complicated, doesn't-work thing that > should just be turned off. > > Finally, the argument that there is an important downgrade available > under ANY depends on the premise that, in validating cases, there is a > valuable difference between "bogus" and "insecure". Mike StJohns has > argued strongly that, for practical purposes, if you are really going > to check validation you're not going to care what the reasons are that > something doesn't validate. If that's right, then there is no > _practical_ downgrade path here anyway. I don't know whether he's > right, however. > > I therefore think that we ought to work on text that makes it clear > that the postive-validation paths are all just as good as one another, > but that a good security policy might prefer bogus over insecure paths > in case postive validation is not at all possible. > > The DNS root signature deployment plan includes a gradual roll-out phase during which the policy should be (must be?) to prefer insecure over bogus in a case where the protocol allows either. > Best, > > A > > > From owner-namedroppers@ops.ietf.org Tue Oct 27 08:59:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4516E3A6847; Tue, 27 Oct 2009 08:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.473 X-Spam-Level: X-Spam-Status: No, score=-0.473 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iotKw9mfPEFC; Tue, 27 Oct 2009 08:59:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BDA5B3A69E1; Tue, 27 Oct 2009 08:59:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2oP1-000K9P-Jn for namedroppers-data0@psg.com; Tue, 27 Oct 2009 15:56:07 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2oOy-000K99-UW for namedroppers@ops.ietf.org; Tue, 27 Oct 2009 15:56:05 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 05F602FE8CDC; Tue, 27 Oct 2009 15:56:02 +0000 (UTC) Date: Tue, 27 Oct 2009 11:56:01 -0400 From: Andrew Sullivan To: Thierry Moreau Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Trust Anchors Message-ID: <20091027155600.GB60267@shinkuro.com> References: <20091026145151.GD55437@shinkuro.com> <4AE6B245.1060603@nlnetlabs.nl> <20091027142031.GP55437@shinkuro.com> <4AE716EF.8050302@connotech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AE716EF.8050302@connotech.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Oct 27, 2009 at 11:51:11AM -0400, Thierry Moreau wrote: > > The DNS root signature deployment plan includes a gradual roll-out phase > during which the policy should be (must be?) to prefer insecure over > bogus in a case where the protocol allows either. Surely that's not exactly relevant to the case under discussion, because there can't possibly be a downgrade for the root due to some higher-level intermediate insecured zone. Right? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Oct 27 09:07:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06D43A6A0C; Tue, 27 Oct 2009 09:07:00 -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, RDNS_NONE=0.1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMEImC8eY9A4; Tue, 27 Oct 2009 09:07:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F173E3A691F; Tue, 27 Oct 2009 09:06:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2oWR-000LLq-Jg for namedroppers-data0@psg.com; Tue, 27 Oct 2009 16:03:47 +0000 Received: from [68.142.225.229] (helo=smtp113.rog.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2oWP-000LLH-0S for namedroppers@ops.ietf.org; Tue, 27 Oct 2009 16:03:45 +0000 Received: (qmail 54134 invoked from network); 27 Oct 2009 16:03:44 -0000 Received: from 209-148-165-15.dynamic.rogerstelecom.net (thierry.moreau@209.148.165.15 with plain) by smtp113.rog.mail.re2.yahoo.com with SMTP; 27 Oct 2009 09:03:44 -0700 PDT X-Yahoo-SMTP: 7IPMVjmswBCDdW1xQhDBl8GZu.GNdc4Rou3wNA-- X-YMail-OSG: WExrRkoVM1llkpNpnoKB6tM7rtrNjW8j.dNXs7iAM7lBpJEDHCzozh9ViZ9ofLoQAQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE71AC9.8040803@connotech.com> Date: Tue, 27 Oct 2009 12:07:37 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Trust Anchors References: <20091026145151.GD55437@shinkuro.com> <4AE6B245.1060603@nlnetlabs.nl> <20091027142031.GP55437@shinkuro.com> <4AE716EF.8050302@connotech.com> <20091027155600.GB60267@shinkuro.com> In-Reply-To: <20091027155600.GB60267@shinkuro.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Andrew Sullivan wrote: > On Tue, Oct 27, 2009 at 11:51:11AM -0400, Thierry Moreau wrote: > >> The DNS root signature deployment plan includes a gradual roll-out phase >> during which the policy should be (must be?) to prefer insecure over >> bogus in a case where the protocol allows either. >> > > Surely that's not exactly relevant to the case under discussion, > because there can't possibly be a downgrade for the root due to some > higher-level intermediate insecured zone. Right? > > A > > If you establish a policy for one concern, should you care about other impact of the policy? - Thierry From owner-namedroppers@ops.ietf.org Tue Oct 27 11:20:33 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326E728C101; Tue, 27 Oct 2009 11:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.047 X-Spam-Level: X-Spam-Status: No, score=-5.047 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-AwUe8kwoda; Tue, 27 Oct 2009 11:20:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3343428C127; Tue, 27 Oct 2009 11:20:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2qYE-0008QO-59 for namedroppers-data0@psg.com; Tue, 27 Oct 2009 18:13:46 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2qY9-0008Q1-VZ for namedroppers@ops.ietf.org; Tue, 27 Oct 2009 18:13:42 +0000 Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n9RIDVrQ010972 for ; Tue, 27 Oct 2009 14:13:31 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Tue, 27 Oct 2009 14:13:27 -0400 From: "Rose, Scott W." To: "namedroppers@ops.ietf.org" Date: Tue, 27 Oct 2009 14:13:29 -0400 Subject: [dnsext] new version of draft-ietf-dnsext-dnskey-registry-fixes available Thread-Topic: new version of draft-ietf-dnsext-dnskey-registry-fixes available Thread-Index: AcpXMS8tip8ZXVPMWkSIgBodI7FO+Q== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Missed the deadline, but a new version is done: http://www.dnsops.gov/draft-ietf-dnsext-dnskey-registry-fixes-01.html -or- http://www.dnsops.gov/draft-ietf-dnsext-dnskey-registry-fixes-01.txt Changes: 1. Fixed the error on entry 8 (should have been entry 4 that is Reserved until 2020). 2. Added ref that RFC 4034 is the source of the original status for algorithms. 3. Changed language on changing algo status to be docs that update RFC 4034= . This will be submitted for real when the submission tool re-opens. Scott =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scottr@nist.gov ph: +1 301-975-8439 Google Voice: +1-571-249-3671 http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-namedroppers@ops.ietf.org Tue Oct 27 11:22:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E687928C0CF; Tue, 27 Oct 2009 11:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.36 X-Spam-Level: ** X-Spam-Status: No, score=2.36 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1bSrbXqU8JB; Tue, 27 Oct 2009 11:22:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1504E3A6992; Tue, 27 Oct 2009 11:22:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2qdy-0008yr-W8 for namedroppers-data0@psg.com; Tue, 27 Oct 2009 18:19:42 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2qdw-0008yU-Qp for namedroppers@ops.ietf.org; Tue, 27 Oct 2009 18:19:40 +0000 Received: from crankycanuck.ca (unknown [74.198.28.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A68422FE8CDC for ; Tue, 27 Oct 2009 18:19:36 +0000 (UTC) Date: Tue, 27 Oct 2009 14:19:33 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Trust Anchors Message-ID: <20091027181930.GB60934@shinkuro.com> References: <20091026145151.GD55437@shinkuro.com> <4AE6B245.1060603@nlnetlabs.nl> <20091027142031.GP55437@shinkuro.com> <4AE716EF.8050302@connotech.com> <20091027155600.GB60267@shinkuro.com> <4AE71AC9.8040803@connotech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AE71AC9.8040803@connotech.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: As before, no hat. On Tue, Oct 27, 2009 at 12:07:37PM -0400, Thierry Moreau wrote: > If you establish a policy for one concern, should you care about other > impact of the policy? Only if it has such an effect. I am arguing that there could be no such effect here, if the policy is designed correctly, because the point of the policy is to avoid downgrades where there is an insecure link in the chain. As there is no such possible downgrade in this case, we don't have to worry about it. If what you're saying is, "The language ought to be tailored to avoid this sort of problem," I agree. But if you're saying that this has implications for the root, I strongly disagree. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From amphetaminesqd@oregonbusiness.com Tue Oct 27 15:30:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E72028C0E1; Tue, 27 Oct 2009 15:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -36.472 X-Spam-Level: X-Spam-Status: No, score=-36.472 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_SPEC_LEO_BORD=0.639, URIBL_BLACK=20, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIlXhKDF+SyF; Tue, 27 Oct 2009 15:30:27 -0700 (PDT) Received: from host178-23-static.39-79-b.business.telecomitalia.it (host178-23-static.39-79-b.business.telecomitalia.it [79.39.23.178]) by core3.amsl.com (Postfix) with ESMTP id 822263A69CD; Tue, 27 Oct 2009 15:30:24 -0700 (PDT) Received: from 79.39.23.178 by ietf.org; Tue, 27 Oct 2009 23:30:21 +0100 Message-ID: <000d01ca5755$11a8c3f0$6400a8c0@amphetaminesqd> From: To: Subject: Risk Free Guarantee Date: Tue, 27 Oct 2009 23:30:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA5755.11A8C3F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA5755.11A8C3F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If you are having trouble reading this email, go to Online version =20 =20 =20 =20 =20 =20 =A0 eNewsletterOctober, 2009 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Support Us | Contact Us | Privacy Policy | UnsubscribeYou are subscri= bed as=20 dnsext-archive@ietf.org 2009 Independent Men's Sexual InstituteAll=20 Rights Reserved27 Allakaket St., 2nd Floor, AZ=20 19188 =20 =A0 ------=_NextPart_000_0007_01CA5755.11A8C3F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you are having trouble reading this email, go to Online version
=A0 eNewsletter
October, 2009

=


Support Us | Contact Us | Privacy Policy | Unsubscribe
You are subscribed as=20 dnsext-archive@ietf.org

2009 Independent Men's Sexual Institute
All=20 Rights Reserved
27 Allakaket St., 2nd Floor, AZ=20 19188
=A0
------=_NextPart_000_0007_01CA5755.11A8C3F0-- From amphetaminesqd@oregonbusiness.com Tue Oct 27 15:30:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E72028C0E1; Tue, 27 Oct 2009 15:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -36.472 X-Spam-Level: X-Spam-Status: No, score=-36.472 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_SPEC_LEO_BORD=0.639, URIBL_BLACK=20, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIlXhKDF+SyF; Tue, 27 Oct 2009 15:30:27 -0700 (PDT) Received: from host178-23-static.39-79-b.business.telecomitalia.it (host178-23-static.39-79-b.business.telecomitalia.it [79.39.23.178]) by core3.amsl.com (Postfix) with ESMTP id 822263A69CD; Tue, 27 Oct 2009 15:30:24 -0700 (PDT) Received: from 79.39.23.178 by ietf.org; Tue, 27 Oct 2009 23:30:21 +0100 Message-ID: <000d01ca5755$11a8c3f0$6400a8c0@amphetaminesqd> From: To: Subject: Risk Free Guarantee Date: Tue, 27 Oct 2009 23:30:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA5755.11A8C3F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA5755.11A8C3F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If you are having trouble reading this email, go to Online version =20 =20 =20 =20 =20 =20 =A0 eNewsletterOctober, 2009 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Support Us | Contact Us | Privacy Policy | UnsubscribeYou are subscri= bed as=20 dnsext-archive@ietf.org 2009 Independent Men's Sexual InstituteAll=20 Rights Reserved27 Allakaket St., 2nd Floor, AZ=20 19188 =20 =A0 ------=_NextPart_000_0007_01CA5755.11A8C3F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you are having trouble reading this email, go to Online version
=A0 eNewsletter
October, 2009

=


Support Us | Contact Us | Privacy Policy | Unsubscribe
You are subscribed as=20 dnsext-archive@ietf.org

2009 Independent Men's Sexual Institute
All=20 Rights Reserved
27 Allakaket St., 2nd Floor, AZ=20 19188
=A0
------=_NextPart_000_0007_01CA5755.11A8C3F0-- From owner-namedroppers@ops.ietf.org Tue Oct 27 17:09:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925B93A6A89; Tue, 27 Oct 2009 17:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=-0.468, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xz8Z6Kq3YR79; Tue, 27 Oct 2009 17:09:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F6173A6900; Tue, 27 Oct 2009 17:09:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2vvP-000BDR-27 for namedroppers-data0@psg.com; Tue, 27 Oct 2009 23:58:03 +0000 Received: from [209.85.219.207] (helo=mail-ew0-f207.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2vvK-000BD7-UV for namedroppers@ops.ietf.org; Tue, 27 Oct 2009 23:57:59 +0000 Received: by ewy3 with SMTP id 3so291750ewy.41 for ; Tue, 27 Oct 2009 16:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=/Nyq3H3zQFDWhFp1p2lIOpR5kOrIYn2RCKAtdDpQFqM=; b=m7cvkQInW5Jdj/ZkndDcOj7kGL0YjKrxDW1PJNJIZm7zUSISm+hmp0wVTVFCzjkTo4 CycchLiNNw0QkraWoGzVoL44oDotHu9KnkSveGdjeSJU5yDeph7ZLnxbRnw0LQcLpQlU 9pSewriFcYGRKDep5VZqOrq0Y7h9TWbgWE2l0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=lzCAxZcdT+AnNURDVVfOn3HAFxYuMPkYHthdJfBawNTcjvtfAvqW74KvduQ31gCz1S 9VOLckg7oQazcePeig44IyrPzW2XQGloDe91xftRjNotzetWaGufi+3n6Ukr2xuTcp5z E1daY+fBu0hw1sjRWEHo7dD1WwUUjKH4eYD4g= Received: by 10.211.129.8 with SMTP id g8mr702112ebn.71.1256687877696; Tue, 27 Oct 2009 16:57:57 -0700 (PDT) Received: from dotis-mac.local (SJC-Office-NAT-214.mail-abuse.org [168.61.10.214]) by mx.google.com with ESMTPS id 23sm1299625eya.28.2009.10.27.16.57.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 16:57:56 -0700 (PDT) Message-ID: <4AE788F4.80608@gmail.com> Date: Tue, 27 Oct 2009 16:57:40 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt References: <20091026113003.86DA728C0CF@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 10/26/09 4:58 AM, Ray.Bellis@nominet.org.uk wrote: > As you'll have just seen I've just made a (minor) update to this > draft. > > I've addressed most (if not all) of the editorial nits and comments. > > However for now I've left out wider discussion of the TCP tuning > issues, references to UTO, etc, as "(currently) out of scope", > pending face-to-face discussion in Hiroshima. Updating RFC 1123 should consider the functional alternative made possible with RFC2671. The maximal DNS message size of 512 should not reflect a 576 MTU, but that of 1476 MTU. Only beyond that limit, should TCP become required. After all, most CPE equipment can not proxy DNS over TCP, so DNS operation is not better accomplished with this over reaching TCP mandate. If smaller key sizes become practical, why not permit exclusive operation of UDP within a known supported range? 4. Transport Protocol Selection Change: o all requests and responses are guaranteed to be <= 512 bytes To: o all requests and responses can be contained within a 1476 byte IP packet to avoid IP fragmentation. Change: A resolver SHOULD send a UDP query first, but MAY elect to send a TCP query instead if it has good reason to expect the response would be truncated if it were sent over UDP (with or without EDNS0) or for other operational reasons. To: A resolver SHOULD send a UDP query first, but MAY elect to send a TCP query instead if it has good reason to expect the response would be truncated if it were sent over UDP with EDNS0, or for other operational reasons. 7. Security Considerations This section makes an unsupportable supposition that TCP dependence will prove safe because it has not yet resulted in successful DDoS attack. However, following adoption of this TCP mandate, UDP use for frames still within 1476 bytes might be unnecessarily withdrawn. If this were to occur for any DNS message over 512 bytes in conjunction with DNSSEC, a substantial portion of DNS traffic may become limited to only using TCP. TCP, even with SYN cookies, still needs to buffer unacknowledged data which creates a significant resource exposure with a DDoS vulnerability. -Doug From owner-namedroppers@ops.ietf.org Wed Oct 28 02:19:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEAF73A699D; Wed, 28 Oct 2009 02:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=-0.452, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzL2zjBCMTb7; Wed, 28 Oct 2009 02:19:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EBD843A6A6F; Wed, 28 Oct 2009 02:19:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N34bF-0000ja-5w for namedroppers-data0@psg.com; Wed, 28 Oct 2009 09:13:49 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N34bC-0000i8-Fz for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 09:13:46 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 19B27C2DA5; Wed, 28 Oct 2009 09:13:43 +0000 (GMT) Date: Wed, 28 Oct 2009 09:13:21 +0000 From: Alex Bligh Reply-To: Alex Bligh To: George Barwood , Doug Otis , Ray.Bellis@nominet.org.uk cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt Message-ID: <312F0CED683865C80DCB6C4C@Ximines.local> In-Reply-To: References: <20091026113003.86DA728C0CF@core3.amsl.com> <4AE788F4.80608@gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 28 October 2009 08:25:48 +0000 George Barwood wrote: > If TCP is required, it seems logical to limit UDP responses to the > original size and deprecate the EDNS response buffer size mechanism. > I'm not sure if this is Ray's intention, but I think I agree with this. I very much hope it isn't Ray's intention. That would be to use a sledge-hammer to crack a nut, though that metaphor perhaps does not encompass sufficient collateral damage. You are advocating preventing UDP packets with a payload greater than 512 bytes. For those worried about TCP loading, this would increase it hugely, as any client compliant with your recommendations would end up making a TCP request just in case the response didn't fit into a 512 byte UDP payload. This is quite apart from the fact that there is a huge volume of EDNS0-supporting clients out there which will continue to make EDNS0 queries, so the deprecation as such will have little effect. Where UDP works, there is no issue in using it. UDP is in the vast majority of cases totally unproblematic, it seems to me, for communication between caching resolver and authoritative server, and EDNS0 works just fine, even above 1500 bytes, as people in general don't have firewalls et al. in the way. The problem would appear to be in a small minority of those cases (generally where the caching resolver is itself behind some form of defective proxy), plus a significant portion of communication between stub resolver and caching proxy. proxy-bypass will I hope go a little way to alleviate the latter problem, but it won't cure it totally. TCP support (possibly combined with proxy-bypass) will, I think, address the vast majority of the cases. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Oct 28 04:19:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358EE3A67D3; Wed, 28 Oct 2009 04:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjsyXYXl5T6d; Wed, 28 Oct 2009 04:19:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B8E8F3A687B; Wed, 28 Oct 2009 04:19:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N36UQ-000Kzm-C8 for namedroppers-data0@psg.com; Wed, 28 Oct 2009 11:14:54 +0000 Received: from [2001:4900:1:392:213:20ff:fe1b:3bfe] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N36UN-000Ky3-1Z for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 11:14:51 +0000 Received: from [81.129.215.73] (helo=octopus.home) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N36UK-000FeT-Fo; Wed, 28 Oct 2009 11:14:49 +0000 Subject: registrar transfers (was Re: [dnsext] Trust Anchors) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: Joe Abley In-Reply-To: Date: Wed, 28 Oct 2009 11:14:45 +0000 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <17D53C86-AF99-48FF-B00B-A3E610D97CE2@hopcount.ca> References: <20091026145151.GD55437@shinkuro.com> <4AE6B245.1060603@nlnetlabs.nl> To: =?iso-8859-1?Q?Jo=E3o_Damas?= X-Mailer: Apple Mail (2.1076) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 2009-10-27, at 13:10, Jo=E3o Damas wrote: > Given this is an operational problem, I believe tweaking the =20 > protocol will never yield a perfect solution and that this sort of =20 > situation would see the users better served by crafting a BCP where, =20= > for instance, the choreography necessary for domain moves between =20 > registrars would be listed. This is very much an aside, but I continue to be mildly alarmed by the =20= conflation of "registrar" with "zone manager" in this kind of =20 discussion. Changing registrar in and of itself has no impact on DNSSEC, and there =20= is no requirement to roll keys or change trust anchors as part of a =20 registrar transfer. This is a simple database operation at the =20 registry, and does not effect what is published in the DNS at all. The case where you need to manage a key rollover is when the entity =20 managing the zone changes. I appreciate that there cases where a single organisation carries out =20= both functions (registrar and zone manager) but this is certainly not =20= the general case. For example, I have heard concern that without the problem of =20 transfers between registrars being solved, prominent/popular domains =20 will never be signed. Any such concern is very easily avoided by not =20 having a registrar sign the zone in the first place. Perhaps the useful BCP to promote in this area is "don't let other =20 people hold your keys if you care about your zone". Surely this is =20 obvious, though. Joe= From owner-namedroppers@ops.ietf.org Wed Oct 28 04:58:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4BFB3A694C; Wed, 28 Oct 2009 04:58:10 -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=[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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3m8Bdwz6wH5; Wed, 28 Oct 2009 04:58:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D02C63A681D; Wed, 28 Oct 2009 04:58:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N374b-0009L0-77 for namedroppers-data0@psg.com; Wed, 28 Oct 2009 11:52:17 +0000 Received: from [195.54.233.70] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N374Y-0009JN-HW for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 11:52:14 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 4E64F1542060; Wed, 28 Oct 2009 11:52:11 +0000 (GMT) Cc: =?ISO-8859-1?Q?Jo=E3o_Damas?= , namedroppers@ops.ietf.org Message-Id: From: Jim Reid To: Joe Abley In-Reply-To: <17D53C86-AF99-48FF-B00B-A3E610D97CE2@hopcount.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: [dnsext] Re: registrar transfers Date: Wed, 28 Oct 2009 11:52:10 +0000 References: <20091026145151.GD55437@shinkuro.com> <4AE6B245.1060603@nlnetlabs.nl> <17D53C86-AF99-48FF-B00B-A3E610D97CE2@hopcount.ca> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 28 Oct 2009, at 11:14, Joe Abley wrote: > Changing registrar in and of itself has no impact on DNSSEC I'm not sure that will always be the case Joe. Of course it should be.... Delegation metadata shouldn't change at the registry when the registrar changes. But it would not be wise to assume that. For instance, what if the registrar is involved in submitting the registrant's (zone manager's) KSK to the registry, say in an EPP transaction? Bad Things could happen at the registry if the EPP transfer request fails to include the delegation's KSK(s). For instance would this hypothetical transfer without KSK(s) transaction mean it's still OK for the current KSK(s) to be used or not? > I have heard concern that without the problem of transfers between > registrars being solved, prominent/popular domains will never be > signed. Any such concern is very easily avoided by not having a > registrar sign the zone in the first place. True. But this is somewhat idealistic IMO if DNSSEC ever becomes mainstream. The vast majority of people with domain names rely on their ISP or registrar as their source of DNS clue. So it's inevitable they'll turn to that source when it comes to signing their zones, just as they turn to them for DNS/mail/web hosting. I'm doubtful that uptake of DNSSEC is going to be encouraged by pushing the complexity of signing and key rollover out to the edges of the network where the DNS skill levels are low. BTW this thread probably should move from namedroppers if it continues. From owner-namedroppers@ops.ietf.org Wed Oct 28 05:09:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25C3C3A68BA; Wed, 28 Oct 2009 05:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sETpW58abv5v; Wed, 28 Oct 2009 05:09:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 523933A67A1; Wed, 28 Oct 2009 05:09:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N37IF-000EoX-0z for namedroppers-data0@psg.com; Wed, 28 Oct 2009 12:06:23 +0000 Received: from [194.176.119.229] (helo=smtp1.bondis.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N37IC-000Emc-Ih for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 12:06:20 +0000 Received: from core.c-l-i.net (core.c-l-i.net [204.62.249.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.bondis.org (Postfix) with ESMTPSA id 90C9C1AB2FF; Wed, 28 Oct 2009 12:06:17 +0000 (UTC) Subject: Re: registrar transfers (was Re: [dnsext] Trust Anchors) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: =?iso-8859-1?Q?Jo=E3o_Damas?= In-Reply-To: <17D53C86-AF99-48FF-B00B-A3E610D97CE2@hopcount.ca> Date: Wed, 28 Oct 2009 13:06:17 +0100 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20091026145151.GD55437@shinkuro.com> <4AE6B245.1060603@nlnetlabs.nl> <17D53C86-AF99-48FF-B00B-A3E610D97CE2@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.1076) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 28 Oct 2009, at 12:14, Joe Abley wrote: > > On 2009-10-27, at 13:10, Jo=E3o Damas wrote: > >> Given this is an operational problem, I believe tweaking the =20 >> protocol will never yield a perfect solution and that this sort of =20= >> situation would see the users better served by crafting a BCP =20 >> where, for instance, the choreography necessary for domain moves =20 >> between registrars would be listed. > > This is very much an aside, but I continue to be mildly alarmed by =20 > the conflation of "registrar" with "zone manager" in this kind of =20 > discussion. > depends were the key-related info resides, and even on who holds the =20 key. Although providing the DNS service is indeed not the same as =20 being a registrar, I find it likely that the registrar, which =20 currently keeps the list of NS, if any, will also keep the key-related =20= info (e.g. DS to be sent to the parent). It is also possible there =20 might be a third party dealing with the DNSSEC info, though it is hard =20= to imagine how to fit that new entity into the customer-registrar-=20 registry trio. Joao= From owner-namedroppers@ops.ietf.org Wed Oct 28 05:47:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D6D23A696F; Wed, 28 Oct 2009 05:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2ArvL17PgvN; Wed, 28 Oct 2009 05:47:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 36B363A68E6; Wed, 28 Oct 2009 05:47:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N37r3-0002WZ-M4 for namedroppers-data0@psg.com; Wed, 28 Oct 2009 12:42:21 +0000 Received: from [2001:4900:1:392:213:20ff:fe1b:3bfe] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N37r0-0002VE-U9 for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 12:42:19 +0000 Received: from [81.129.215.73] (helo=octopus.home) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N37qy-000GPS-4i; Wed, 28 Oct 2009 12:42:17 +0000 Subject: Re: registrar transfers (was Re: [dnsext] Trust Anchors) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: Joe Abley In-Reply-To: Date: Wed, 28 Oct 2009 12:42:14 +0000 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <64BA7014-F7D8-4AE5-9BF0-5013859E436C@hopcount.ca> References: <20091026145151.GD55437@shinkuro.com> <4AE6B245.1060603@nlnetlabs.nl> <17D53C86-AF99-48FF-B00B-A3E610D97CE2@hopcount.ca> To: =?iso-8859-1?Q?Jo=E3o_Damas?= X-Mailer: Apple Mail (2.1076) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I take Jim's point about the proper forum for this particular =20 extemporaneous rant, but ignoring it for a second... On 2009-10-28, at 12:06, Jo=E3o Damas wrote: > On 28 Oct 2009, at 12:14, Joe Abley wrote: > >> This is very much an aside, but I continue to be mildly alarmed by =20= >> the conflation of "registrar" with "zone manager" in this kind of =20 >> discussion. > > depends were the key-related info resides, and even on who holds the =20= > key. My point is that the key isn't part of the registry data, > Although providing the DNS service is indeed not the same as being a =20= > registrar, I find it likely that the registrar, which currently =20 > keeps the list of NS, if any, will also keep the key-related info =20 > (e.g. DS to be sent to the parent). the trust anchor to the registrant's zone is public information, is =20 held at the registry, and doesn't need to change during a domain =20 transfer, and > It is also possible there might be a third party dealing with the =20 > DNSSEC info, though it is hard to imagine how to fit that new entity =20= > into the customer-registrar-registry trio. although single organisations frequently perform multiple roles, the =20 zone manager role already exists and is already independent of the =20 registrant-registrar-registry roles. Joe= From owner-namedroppers@ops.ietf.org Wed Oct 28 06:52:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9038D3A68A7; Wed, 28 Oct 2009 06:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.381 X-Spam-Level: *** X-Spam-Status: No, score=3.381 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYzl7ivpFgCL; Wed, 28 Oct 2009 06:52:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9467B3A6782; Wed, 28 Oct 2009 06:52:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N38qF-0001IK-Le for namedroppers-data0@psg.com; Wed, 28 Oct 2009 13:45:35 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N38qC-0001Fq-84 for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 13:45:33 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA024377476; Wed, 28 Oct 2009 14:44:36 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA03343; Wed, 28 Oct 2009 14:44:35 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910281344.OAA03343@TR-Sys.de> Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt To: doug.mtview@gmail.com, Ray.Bellis@nominet.org.uk Date: Wed, 28 Oct 2009 14:44:34 +0100 (MEZ) Cc: namedroppers@ops.ietf.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At Tue, 27 Oct 2009 16:57:40 -0700, Doug Otis wrote: > ... > > Updating RFC 1123 should consider the functional alternative made > possible with RFC2671. The maximal DNS message size of 512 should > not reflect a 576 MTU, but that of 1476 MTU. Only beyond that limit, > should TCP become required. After all, most CPE equipment can not > proxy DNS over TCP, so DNS operation is not better accomplished with > this over reaching TCP mandate. > > ... Although perhaps 1476 might be desirable, it seems ill-advised to ask for that. We should align the limit to what already has found consensus in the IETF for IPv6 in particular, and what link layer specifications since then have learned to accommodate. RFC 2460 specifies (on page 24): |5. Packet Size Issues | | IPv6 requires that every link in the internet have an MTU of 1280 | octets or greater. On any link that cannot convey a 1280-octet | packet in one piece, link-specific fragmentation and reassembly | must be provided at a layer below IPv6. This limit has been chosen then with various tunnelling technologies in mind, leaving enough head room for additional tunnel headers etc. before reaching the traditional Ethernet packet size. Also, there now indeed are wireless technologies that needed such convergence layer to adapt the much smaller L2 packet size to the IPv6 requirement. We cannot expect anybody will change the boundary again, solely because this WG would appreciate it (other folks as well, surely!). The overwhelming majority of link layers for IPv4 should actually accommodate the same limit today. (Can somebody please quantify this assumption based on empirical data? -- Maybe router vendors will know best, and field tests might help to confirm the results.) Since avoiding IP layer fragmentation is one of the most important goals, from an operational and security perspective, we therefore should contend with the future-(IPv6-)proof packet size limit. I further suggest that DNSEXT should push the emerging INTAREA WG to consider aligning the MTU requirements for IPv4 with those for IPv6 (as quoted above). This in turn would then allow this WG to consider raising the mimimum UDP packet size for DNS as well. Please comment on the INTAREA WG Review call archived at: http://www.IETF.ORG/mail-archive/web/ietf-announce/current/msg06684.html This IMHO is the proper temporal sequence of tasks. I fear DNSEXT would most likely fail in IETF LC and in the IESG if it attempted to implicitely change the IPv4 specs in this way. On the other hand, this means that the "MUST implement" requirement for TCP Transport of 'normal' (non-{A|I}XFR) DNS traffic is still needed, with as few exceptions as possible for DNS components, and with _no_ exceptions for middleboxes. Furthermore, it might be wise to request *middlebox* support for DNS packets of (at least?) 4096 octets *today*, over any DNS transport. It seems not reasonable to expect useful seamless deployment of any increase in the DNS packet size (via EDNS, TCP transport, 'upgraded' or IPv6-based UDP transport, or any future DNS transport) unless we *first* happen to achieve adherence at large to this requirement! Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From owner-namedroppers@ops.ietf.org Wed Oct 28 07:02:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3286F3A69AB; Wed, 28 Oct 2009 07:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.042 X-Spam-Level: X-Spam-Status: No, score=-105.042 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeSuQJDlqoLB; Wed, 28 Oct 2009 07:02:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4258B3A693A; Wed, 28 Oct 2009 07:02:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N392f-0006qG-GC for namedroppers-data0@psg.com; Wed, 28 Oct 2009 13:58:25 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N392d-0006p5-5U for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 13:58:23 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 642E01C0128 for ; Wed, 28 Oct 2009 14:58:21 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 603CF1C010C for ; Wed, 28 Oct 2009 14:58:21 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 549227B0032 for ; Wed, 28 Oct 2009 14:58:21 +0100 (CET) Date: Wed, 28 Oct 2009 14:58:21 +0100 From: Stephane Bortzmeyer To: namedroppers@ops.ietf.org Subject: Re: Protocol numbers for RSA/SHA{256|512} (Was: Re: [dnsext] GOST DNSSEC, implementations?) Message-ID: <20091028135821.GA21952@nic.fr> References: <4ADCD74B.6060302@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ADCD74B.6060302@dougbarton.us> X-Operating-System: Debian GNU/Linux 5.0.3 X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Oct 19, 2009 at 02:16:59PM -0700, Doug Barton wrote a message of 14 lines which said: > I see based on > http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml Anyone knows an example of keys and signatures using algorithms 8 or 10, in the wild? This is for a blog entry I want to write. From owner-namedroppers@ops.ietf.org Wed Oct 28 07:04:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA043A67AB; Wed, 28 Oct 2009 07:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.001 X-Spam-Level: X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1a5G1tzgta8; Wed, 28 Oct 2009 07:04:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C043B3A6782; Wed, 28 Oct 2009 07:04:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3954-0007uv-3a for namedroppers-data0@psg.com; Wed, 28 Oct 2009 14:00:54 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3951-0007tM-IU for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 14:00:51 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=jK/bV1LVrHQecjXTyD3i11jwD0ZkYgAGmxkrnsiRqWWXj/leC3neIVbb m//K2JeJI8otES4mdahJINP7AdJPLQRAXaBGFy5/MpTugCK13V5sDlGwk n0HM/gqNrnP74tO; 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=1256738451; x=1288274451; 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.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20I-D=20Action:draft-ietf-dnsext-dns-tcp-requirements -01.txt|Date:=20Wed,=2028=20Oct=202009=2014:00:46=20+0000 |Message-ID:=20|To:=20Alfred=20=3D?ISO-8 859-1?Q?H=3DF6nes?=3D=20|Cc:=20namedroppers @ops.ietf.org|MIME-Version:=201.0|In-Reply-To:=20<2009102 81344.OAA03343@TR-Sys.de>|References:=20<200910281344.OAA 03343@TR-Sys.de>; bh=POvjKuy9mFvALXW6cMJYrJrT2bCMokV+2nWw49Lw0Uw=; b=0mDyKyafZ+nssXOe5tN1C0rD8LNndCzaSQiaxisCkYdtpNgK6ZOUXHLF v15YuUdlTRicZSJLq9Sum1Emi2MflxmBrZI3g0eet3vpbv/+c50vYKY3f 6yAT34kT92MDQIw; X-IronPort-AV: E=Sophos;i="4.44,640,1249254000"; d="scan'208";a="13945833" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 28 Oct 2009 14:00:47 +0000 In-Reply-To: <200910281344.OAA03343@TR-Sys.de> References: <200910281344.OAA03343@TR-Sys.de> To: Alfred =?ISO-8859-1?Q?H=F6nes?= Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 28 Oct 2009 14:00:46 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 28/10/2009 02:00:47 PM, Serialize complete at 28/10/2009 02:00:47 PM Content-Type: multipart/alternative; boundary="=_alternative 004CF9498025765D_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multipart message in MIME format. --=_alternative 004CF9498025765D_= Content-Type: text/plain; charset="US-ASCII" > Furthermore, it might be wise to request *middlebox* support for DNS > packets of (at least?) 4096 octets *today*, over any DNS transport. > It seems not reasonable to expect useful seamless deployment of any > increase in the DNS packet size (via EDNS, TCP transport, 'upgraded' > or IPv6-based UDP transport, or any future DNS transport) unless we > *first* happen to achieve adherence at large to this requirement! RFC 5625 does already attempt to address this. Ray --=_alternative 004CF9498025765D_= Content-Type: text/html; charset="US-ASCII"
> Furthermore, it might be wise to request *middlebox* support for DNS
> packets of (at least?) 4096 octets *today*, over any DNS transport.
> It seems not reasonable to expect useful seamless deployment of any
> increase in the DNS packet size (via EDNS, TCP transport, 'upgraded'
> or IPv6-based UDP transport, or any future DNS transport) unless we
> *first* happen to achieve adherence at large to this requirement!
RFC 5625 does already attempt to address this.

Ray
--=_alternative 004CF9498025765D_=-- From owner-namedroppers@ops.ietf.org Wed Oct 28 07:04:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9C9E28C148; Wed, 28 Oct 2009 07:04:42 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpA8H6s-CIpJ; Wed, 28 Oct 2009 07:04:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE0893A6782; Wed, 28 Oct 2009 07:04:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N395P-00086C-9l for namedroppers-data0@psg.com; Wed, 28 Oct 2009 14:01:15 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N395L-00084f-QI for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 14:01:11 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 71E7ECCBBE for ; Wed, 28 Oct 2009 14:01:11 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt In-Reply-To: Your message of "Wed, 28 Oct 2009 08:25:48 GMT." References: <20091026113003.86DA728C0CF@core3.amsl.com> <4AE788F4.80608@gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 28 Oct 2009 14:01:11 +0000 Message-ID: <22281.1256738471@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: "George Barwood" > Date: Wed, 28 Oct 2009 08:25:48 -0000 > > If TCP is required, it seems logical to limit UDP responses to the > original size and deprecate the EDNS response buffer size mechanism. EDNS0 was never intended to be a backfill for supposed TCP optionalness -- TCP was not considered optional by the people who created or approved EDNS0. > I don't think this should be the end of it though, at risk of boring > readers with repetition, for which I apologise, I'm advocating either > SCTP or something like > > http://www.george-barwood.pwp.blueyonder.co.uk/DnsServer/QRP.htm there's some off-list work going on along these lines, but it wasn't ready for the hiroshima meeting, which agenda seems rather overfull in any case. From owner-namedroppers@ops.ietf.org Wed Oct 28 07:32:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6FE428C1B1; Wed, 28 Oct 2009 07:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.405 X-Spam-Level: *** X-Spam-Status: No, score=3.405 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlWzmFNvBOmr; Wed, 28 Oct 2009 07:32:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CC40828C1BA; Wed, 28 Oct 2009 07:32:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N39Ud-000Ild-Mq for namedroppers-data0@psg.com; Wed, 28 Oct 2009 14:27:19 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N39Ua-000Ik2-Px for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 14:27:17 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA024689987; Wed, 28 Oct 2009 15:26:27 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA03489; Wed, 28 Oct 2009 15:26:26 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910281426.PAA03489@TR-Sys.de> Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt To: Ray.Bellis@nominet.org.uk Date: Wed, 28 Oct 2009 15:26:25 +0100 (MEZ) Cc: namedroppers@ops.ietf.org In-Reply-To: from "Ray.Bellis@nominet.org.uk" at Oct "28," 2009 "02:00:46" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Ray Bellis wrote: >> Furthermore, it might be wise to request *middlebox* support for DNS >> packets of (at least?) 4096 octets *today*, over any DNS transport. >> It seems not reasonable to expect useful seamless deployment of any >> increase in the DNS packet size (via EDNS, TCP transport, 'upgraded' >> or IPv6-based UDP transport, or any future DNS transport) unless we >> *first* happen to achieve adherence at large to this requirement! > > RFC 5625 does already attempt to address this. > > Ray "attempt to address" != "achieve adherence" :-) It's still a long way to go. Some folks need steadily repeated sermon until they are going to believe, isn't it? :-) So reinforcing the requirement to support larger DNS packets where full transparency of the network is not possible or desired should be worth the effort, wherever it fits neatly into a document. Alfred. From owner-namedroppers@ops.ietf.org Wed Oct 28 09:31:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1513A6A15; Wed, 28 Oct 2009 09:31:46 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laydYeiBtvnA; Wed, 28 Oct 2009 09:31:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B3CFA3A6975; Wed, 28 Oct 2009 09:31:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3BLU-000EO6-PR for namedroppers-data0@psg.com; Wed, 28 Oct 2009 16:26:00 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3BLR-000EMv-PA for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 16:25:57 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 6DC5CCCBED for ; Wed, 28 Oct 2009 16:25:57 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt In-Reply-To: Your message of "Wed, 28 Oct 2009 15:26:25 +0100." <200910281426.PAA03489@TR-Sys.de> References: <200910281426.PAA03489@TR-Sys.de> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 28 Oct 2009 16:25:57 +0000 Message-ID: <28272.1256747157@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Alfred =?hp-roman8?B?SM5uZXM=?= > Date: Wed, 28 Oct 2009 15:26:25 +0100 (MEZ) > > "attempt to address" != "achieve adherence" :-) > > It's still a long way to go. Some folks need steadily repeated > sermon until they are going to believe, isn't it? :-) "hello mr. middlebox vendor. since we neglected to inform you that the traffic you'll carry may include fragments and that you can't really predict maximum packet size based on the UDP port numbers on a packet, we agree that it's perfectly reasonable that you totally fscked it up. however, in an RFC you never heard of, we did finally get around to asking that you rev your software to stop fscking up our traffic, so could you please slot some engineering resources for it even though it will not result in higher sales nor will failing to do it result in lower sales? thanks in advance!" From owner-namedroppers@ops.ietf.org Wed Oct 28 12:30:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091383A6940; Wed, 28 Oct 2009 12:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.159 X-Spam-Level: X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_93=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW49tAho8zXC; Wed, 28 Oct 2009 12:30:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1FF7B3A6A0B; Wed, 28 Oct 2009 12:30:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3E6b-000OpY-1E for namedroppers-data0@psg.com; Wed, 28 Oct 2009 19:22:49 +0000 Received: from [128.9.168.207] (helo=bosco.isi.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3E6Y-000OpM-3x for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 19:22:46 +0000 Received: by bosco.isi.edu (Postfix, from userid 70) id B346C356BC7; Wed, 28 Oct 2009 12:19:39 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: [dnsext] RFC 5702 on Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org Message-Id: <20091028191939.B346C356BC7@bosco.isi.edu> Date: Wed, 28 Oct 2009 12:19:39 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: A new Request for Comments is now available in online RFC libraries. RFC 5702 Title: Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC Author: J. Jansen Status: Standards Track Date: October 2009 Mailbox: jelte@NLnetLabs.nl Pages: 10 Characters: 19425 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsext-dnssec-rsasha256-14.txt URL: http://www.rfc-editor.org/rfc/rfc5702.txt This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (RFC 4033, RFC 4034, and RFC 4035). [STANDARDS TRACK] This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From owner-namedroppers@ops.ietf.org Wed Oct 28 12:54:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C6F3A6A68; Wed, 28 Oct 2009 12:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrv+POYdTefw; Wed, 28 Oct 2009 12:54:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2BC2D3A6A81; Wed, 28 Oct 2009 12:54:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3EWV-0001cP-60 for namedroppers-data0@psg.com; Wed, 28 Oct 2009 19:49:35 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3EWT-0001bo-1H for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 19:49:33 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D0BBC2FE8CDC for ; Wed, 28 Oct 2009 19:49:29 +0000 (UTC) Date: Wed, 28 Oct 2009 15:49:28 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] RFC 5702 on Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC Message-ID: <20091028194928.GL61552@shinkuro.com> References: <20091028191939.B346C356BC7@bosco.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091028191939.B346C356BC7@bosco.isi.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, Oct 28, 2009 at 12:19:39PM -0700, rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > RFC 5702 > > Title: Use of SHA-2 Algorithms with > RSA in DNSKEY and RRSIG Resource > Records for DNSSEC > Author: J. Jansen Thanks to Jelte for his long efforts as editor on this "quick" document, and to the participants in the WG for their review. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Oct 28 13:21:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91D628C186; Wed, 28 Oct 2009 13:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.766 X-Spam-Level: X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Hp77t8OoXPb; Wed, 28 Oct 2009 13:21:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 745CB28C1CB; Wed, 28 Oct 2009 13:21:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3EwZ-0004Pa-Ls for namedroppers-data0@psg.com; Wed, 28 Oct 2009 20:16:31 +0000 Received: from [209.85.218.216] (helo=mail-bw0-f216.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3EwW-0004P0-2l for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 20:16:28 +0000 Received: by bwz8 with SMTP id 8so1481871bwz.39 for ; Wed, 28 Oct 2009 13:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+sAHkH1QBLsb64GSF4BoS9XLJl8OqLj+uAKpNZnv2p8=; b=L1FvUtYb07RnJT6iTu1GAIopuCt+f79x3fvgbYcnNHZvRkHlWztgQHN0jUphHh4FLT JmNFb+I7W6519vQ7vuxJxTWxm/eAamOaTFDBsB/hLrXEmwUBD7IKM1XWpXUN0KrnXzfI wrnGPiuJ8mXDb47Ft4oho6wL8BHnG4pqfWKWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Lp9EuGiv8fPWACfRCflAcjXKjFzMOgo/Z5sk2qvQBbPiErkUYtFxxf4pSaIWH+zw0A iYXdYn+80VTZ9YpEOakkOBcBHmPl/MbdnqfT01vi2F51Hi+Enw0/JEZMy6Ev+TN31Lrl BLmXHNKP+NBhO6dOYiZ7L3WmnQLVKbgl/rVW8= Received: by 10.204.156.213 with SMTP id y21mr5767387bkw.109.1256760986468; Wed, 28 Oct 2009 13:16:26 -0700 (PDT) Received: from sjc-office-nat-214.mail-abuse.org (SJC-Office-NAT-214.mail-abuse.org [168.61.10.214]) by mx.google.com with ESMTPS id h2sm2572021fkh.36.2009.10.28.13.16.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Oct 2009 13:16:25 -0700 (PDT) Message-ID: <4AE8A694.5010801@gmail.com> Date: Wed, 28 Oct 2009 13:16:20 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= CC: Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt References: <200910281344.OAA03343@TR-Sys.de> In-Reply-To: <200910281344.OAA03343@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 10/28/09 6:44 AM, Alfred � wrote: Alfred, > At Tue, 27 Oct 2009 16:57:40 -0700, Doug Otis wrote: >> ... >> Updating RFC 1123 should consider the functional alternative made >> possible with RFC2671. The maximal DNS message size of 512 should >> not reflect a 576 MTU, but that of 1476 MTU. Only beyond that limit, >> should TCP become required. After all, most CPE equipment can not >> proxy DNS over TCP, so DNS operation is not better accomplished with >> this over reaching TCP mandate. >> ... > > Although perhaps 1476 might be desirable, it seems ill-advised to > ask for that. We should align the limit to what already has found > consensus in the IETF for IPv6 in particular, and what link layer > specifications since then have learned to accommodate. > > RFC 2460 specifies (on page 24): > > |5. Packet Size Issues > | > | IPv6 requires that every link in the internet have an MTU of 1280 > | octets or greater. On any link that cannot convey a 1280-octet > | packet in one piece, link-specific fragmentation and reassembly > | must be provided at a layer below IPv6. > > This limit has been chosen then with various tunnelling technologies > in mind, leaving enough head room for additional tunnel headers etc. > before reaching the traditional Ethernet packet size. Yes it would cause fewer issues for tunneling IPv6 to impose an alternative to UDP jumbo frames when MTUs are larger than 1280 bytes. > Also, there now indeed are wireless technologies that needed such > convergence layer to adapt the much smaller L2 packet size to the > IPv6 requirement. > We cannot expect anybody will change the boundary again, solely > because this WG would appreciate it (other folks as well, surely!). > > > The overwhelming majority of link layers for IPv4 should actually > accommodate the same limit today. (Can somebody please quantify > this assumption based on empirical data? -- Maybe router vendors > will know best, and field tests might help to confirm the results.) > > Since avoiding IP layer fragmentation is one of the most important > goals, from an operational and security perspective, we therefore > should contend with the future-(IPv6-)proof packet size limit. Agreed. However, how much IPv6 tunneling of UDP would be affected by a 1476 MTU cut-off for DNS over UDP? Less than 1%? And how much more DNS traffic could then be handled by UDP with the 196 additional bytes? Surely this would cause less harm than 4096 byte MTUs. There is no desire to argue about this difference, but a TCP mandate at the 576 byte MTUs is clearly wrong. Imposing _any_ TCP mandate represents an expedient that takes DNS in the wrong direction. As such, this draft should also include a strong warning that resources needed to sustain TCP services might be provisioned for other transports during aberrant demand, and that it is not recommended to be dependent upon TCP availability. > I further suggest that DNSEXT should push the emerging INTAREA WG > to consider aligning the MTU requirements for IPv4 with those for > IPv6 (as quoted above). This in turn would then allow this WG to > consider raising the mimimum UDP packet size for DNS as well. > Please comment on the INTAREA WG Review call archived at: > http://www.IETF.ORG/mail-archive/web/ietf-announce/current/msg06684.html Imposing a TCP mandate when DNS messages exceed 512 bytes allows compliance with seldom used 576 byte MTUs. A TCP mandate at this MTU size makes little sense when it will likely increase TCP traffic DNS servers are thereby _mandated_ to provide. Expecting use of UDP up to either 1476 or 1280 byte MTUs still substantially limits reflected attack and packet fragmentation. > This IMHO is the proper temporal sequence of tasks. I fear DNSEXT > would most likely fail in IETF LC and in the IESG if it attempted > to implicitely change the IPv4 specs in this way. > > On the other hand, this means that the "MUST implement" requirement > for TCP Transport of 'normal' (non-{A|I}XFR) DNS traffic is still > needed, with as few exceptions as possible for DNS components, > and with _no_ exceptions for middleboxes. > > Furthermore, it might be wise to request *middlebox* support for DNS > packets of (at least?) 4096 octets *today*, over any DNS transport. > It seems not reasonable to expect useful seamless deployment of any > increase in the DNS packet size (via EDNS, TCP transport, 'upgraded' > or IPv6-based UDP transport, or any future DNS transport) unless we > *first* happen to achieve adherence at large to this requirement! It would seem this request has been made long ago, but adherence creates other problems less easily solved without complete adherence. -Doug From owner-namedroppers@ops.ietf.org Wed Oct 28 14:20:33 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2375F3A6810; Wed, 28 Oct 2009 14:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5 tests=[AWL=-0.984, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfgpuLPcyb4W; Wed, 28 Oct 2009 14:20:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 65E9128C1E6; Wed, 28 Oct 2009 14:20:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3FrL-000Aij-7O for namedroppers-data0@psg.com; Wed, 28 Oct 2009 21:15:11 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3FrH-000Ai5-RC for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 21:15:08 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9SLF6Ea005829 for ; Wed, 28 Oct 2009 17:15:06 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200910282115.n9SLF6Ea005829@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 28 Oct 2009 17:14:53 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: [dnsext] Draft agenda posted Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I think I got all requests in there: http://www.ietf.org/proceedings/09nov/agenda/dnsext.txt Olafur From owner-namedroppers@ops.ietf.org Wed Oct 28 16:47:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12D353A6A5F; Wed, 28 Oct 2009 16:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v29Vf0r9DtNe; Wed, 28 Oct 2009 16:47:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B0893A6A37; Wed, 28 Oct 2009 16:47:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3I8d-0004S3-Ge for namedroppers-data0@psg.com; Wed, 28 Oct 2009 23:41:11 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3I8Z-0004QT-Ug for namedroppers@ops.ietf.org; Wed, 28 Oct 2009 23:41:07 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id DC5ABE6026; Wed, 28 Oct 2009 23:41:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n9SNf0Jn042987; Thu, 29 Oct 2009 10:41:00 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200910282341.n9SNf0Jn042987@drugs.dv.isc.org> To: Doug Otis Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org From: Mark Andrews References: <200910281344.OAA03343@TR-Sys.de> <4AE8A694.5010801@gmail.com> Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt In-reply-to: Your message of "Wed, 28 Oct 2009 13:16:20 PDT." <4AE8A694.5010801@gmail.com> Date: Thu, 29 Oct 2009 10:41:00 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4AE8A694.5010801@gmail.com>, Doug Otis writes: > Imposing _any_ TCP mandate represents an expedient that takes DNS in the > wrong direction. As such, this draft should also include a strong > warning that resources needed to sustain TCP services might be > provisioned for other transports during aberrant demand, and that it is > not recommended to be dependent upon TCP availability. TCP has always been expected to be implemented unless you had GOOD reasons to not implement it and had REALLY thought about the consequences. Read RFC 1034 and 1123. TCP was not MAY. It was SHOULD. Does anyone here really think that any proxy vendor, that doesn't support TCP, could successfully argue that they did that analysis and have the result pass a laugh test? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Wed Oct 28 17:23:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03A903A6A2C; Wed, 28 Oct 2009 17:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SMjTAbSdhpM; Wed, 28 Oct 2009 17:23:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A3CA3A68FB; Wed, 28 Oct 2009 17:23:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3IaI-000FpA-M6 for namedroppers-data0@psg.com; Thu, 29 Oct 2009 00:09:46 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3IaC-000Flg-Bz for namedroppers@ops.ietf.org; Thu, 29 Oct 2009 00:09:40 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 5F983E601C; Thu, 29 Oct 2009 00:09:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n9T09aJr044049; Thu, 29 Oct 2009 11:09:36 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200910290009.n9T09aJr044049@drugs.dv.isc.org> To: Paul Vixie Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <200910281426.PAA03489@TR-Sys.de> <28272.1256747157@nsa.vix.com> Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt In-reply-to: Your message of "Wed, 28 Oct 2009 16:25:57 -0000." <28272.1256747157@nsa.vix.com> Date: Thu, 29 Oct 2009 11:09:36 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <28272.1256747157@nsa.vix.com>, Paul Vixie writes: > > From: Alfred =?hp-roman8?B?SM5uZXM=?= > > Date: Wed, 28 Oct 2009 15:26:25 +0100 (MEZ) > > > > "attempt to address" != "achieve adherence" :-) > > > > It's still a long way to go. Some folks need steadily repeated > > sermon until they are going to believe, isn't it? :-) > > "hello mr. middlebox vendor. since we neglected to inform you that the > traffic you'll carry may include fragments and that you can't really > predict maximum packet size based on the UDP port numbers on a packet, > we agree that it's perfectly reasonable that you totally fscked it up. > however, in an RFC you never heard of, we did finally get around to > asking that you rev your software to stop fscking up our traffic, so > could you please slot some engineering resources for it even though it > will not result in higher sales nor will failing to do it result in > lower sales? thanks in advance!" Dear mr. middlebox vendor. Please stop lying in your DHCP responses by adverting that your boxes contain a DNS server when they actually contain a DNS proxy and a poorly implemented one at that. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Wed Oct 28 18:03:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311573A69C8; Wed, 28 Oct 2009 18:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.864 X-Spam-Level: X-Spam-Status: No, score=-0.864 tagged_above=-999 required=5 tests=[AWL=-0.369, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTryuFHB6+ji; Wed, 28 Oct 2009 18:03:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E63C3A67F5; Wed, 28 Oct 2009 18:03:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3JMJ-0004CV-WF for namedroppers-data0@psg.com; Thu, 29 Oct 2009 00:59:24 +0000 Received: from [209.85.217.216] (helo=mail-gx0-f216.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3JMI-0004CI-3r for namedroppers@ops.ietf.org; Thu, 29 Oct 2009 00:59:22 +0000 Received: by gxk8 with SMTP id 8so1645894gxk.1 for ; Wed, 28 Oct 2009 17:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=XjXWMMxp/nnVzDmbMmSRqAjMrfxaMjaLj6bE/0/fUW0=; b=bIn/ZV/LZ6uze6NFN3FQ8Gv75n7URuRrZOqiNuH4gwcbjRhjA1/n2OR6tBhQtYwAL3 GeN2Opr/gi8ErVmlF8J1e/P8P9HEInf5JvlCpjB1KFJ6ZhxtfWdh4o+LxoQh5KYJY5Ep 7bgS1L98NYr4MzKqJdWgxDsIV7wuLDWlbePLo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ndjPHE23DW3cq6aLCxOar3GYdjco9TZaoyltGrvQy6hAsOBTgRv2rUmMaANu+f7BRa 8jZwAvCmGr8elW+6/ue/3awLlWNWKE5iw8TRkdOf1JqNvAhUspeztIJ1neF5d7cBvzuu JLG9vc9OVgPS8/XMKc78TFkgYdR25QnckwfB4= Received: by 10.150.42.1 with SMTP id p1mr1384181ybp.15.1256777961405; Wed, 28 Oct 2009 17:59:21 -0700 (PDT) Received: from sjc-office-nat-214.mail-abuse.org (SJC-Office-NAT-214.mail-abuse.org [168.61.10.214]) by mx.google.com with ESMTPS id 4sm559073ywg.43.2009.10.28.17.59.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Oct 2009 17:59:20 -0700 (PDT) Message-ID: <4AE8E8E5.4030403@gmail.com> Date: Wed, 28 Oct 2009 17:59:17 -0700 From: Doug Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Mark Andrews CC: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt References: <200910281344.OAA03343@TR-Sys.de> <4AE8A694.5010801@gmail.com> <200910282341.n9SNf0Jn042987@drugs.dv.isc.org> In-Reply-To: <200910282341.n9SNf0Jn042987@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 10/28/09 4:41 PM, Mark Andrews wrote: > In message<4AE8A694.5010801@gmail.com>, Doug Otis writes: >> Imposing _any_ TCP mandate represents an expedient that takes DNS in the >> wrong direction. As such, this draft should also include a strong >> warning that resources needed to sustain TCP services might be >> provisioned for other transports during aberrant demand, and that it is >> not recommended to be dependent upon TCP availability. > > TCP has always been expected to be implemented unless you had GOOD > reasons to not implement it and had REALLY thought about the > consequences. Read RFC 1034 and 1123. TCP was not MAY. It was > SHOULD. The concern is about establishing a dependence upon TCP. While TCP has often been a fall-back for truncated DNS answers, it has never been mandated. A SHOULD is not a MUST. TCP being functional for DNS was never assured. Even ensuring that TCP is enable does not ensure availability of a lower priority service. In addition, TCP is not enabled by one the roots, and most CPE equipment. While people can configure their CPE equipment to bypass DNS proxy services lacking proper TCP support, most do not. > Does anyone here really think that any proxy vendor, that doesn't > support TCP, could successfully argue that they did that analysis > and have the result pass a laugh test? What analysis? Vendors likely considered the resources needed to support the features they offered, and decided against expenditures related to TCP for DNS. The CPE market decided TCP was not an overriding requirement for DNS, in favor of cost. This same cost issue with TCP killed RDMA. Mandating that DNS servers MUST provide TCP when the service can be carried over UDP extended to conservative MTUs of 1280, or IMHO 1476, makes no sense. This strategy should also help curtail growth of DNS TCP traffic. After all, TCP is not well suited to efficiently handle DNS, and should be avoided where possible. -Doug From owner-namedroppers@ops.ietf.org Wed Oct 28 18:21:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75993A67F5; Wed, 28 Oct 2009 18:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0A8lD7w-BOqu; Wed, 28 Oct 2009 18:21:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE88C3A6359; Wed, 28 Oct 2009 18:21:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3Je0-0006HP-TZ for namedroppers-data0@psg.com; Thu, 29 Oct 2009 01:17:40 +0000 Received: from [209.85.216.204] (helo=mail-px0-f204.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3Jdz-0006HC-7E for namedroppers@ops.ietf.org; Thu, 29 Oct 2009 01:17:39 +0000 Received: by pxi42 with SMTP id 42so945662pxi.5 for ; Wed, 28 Oct 2009 18:17:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.242.2 with SMTP id p2mr21533977wah.153.1256779058843; Wed, 28 Oct 2009 18:17:38 -0700 (PDT) In-Reply-To: <4AE8E8E5.4030403@gmail.com> References: <200910281344.OAA03343@TR-Sys.de> <4AE8A694.5010801@gmail.com> <200910282341.n9SNf0Jn042987@drugs.dv.isc.org> <4AE8E8E5.4030403@gmail.com> Date: Wed, 28 Oct 2009 18:17:38 -0700 Message-ID: Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt From: Matthew Dempsky To: Doug Otis Cc: Mark Andrews , =?UTF-8?B?QWxmcmVkIO+/vQ==?= , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, Oct 28, 2009 at 5:59 PM, Doug Otis wrote: > =A0Mandating that DNS servers MUST provide TCP when the service can be ca= rried > over UDP extended to conservative MTUs of 1280, or IMHO 1476, makes no > sense. In a world with 100% support for EDNS, maybe. But not all clients and servers support EDNS. From owner-namedroppers@ops.ietf.org Wed Oct 28 18:37:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189F53A6861; Wed, 28 Oct 2009 18:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6CBbvr9aimL; Wed, 28 Oct 2009 18:37:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 176563A67FA; Wed, 28 Oct 2009 18:37:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3Jse-0007kE-1v for namedroppers-data0@psg.com; Thu, 29 Oct 2009 01:32:48 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3Jsb-0007k1-LS for namedroppers@ops.ietf.org; Thu, 29 Oct 2009 01:32:45 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 5E7A7E605D; Thu, 29 Oct 2009 01:32:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n9T1Wf7W027448; Thu, 29 Oct 2009 12:32:42 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200910290132.n9T1Wf7W027448@drugs.dv.isc.org> To: Doug Otis Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org From: Mark Andrews References: <200910281344.OAA03343@TR-Sys.de> <4AE8A694.5010801@gmail.com> <200910282341.n9SNf0Jn042987@drugs.dv.isc.org> <4AE8E8E5.4030403@gmail.com> Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt In-reply-to: Your message of "Wed, 28 Oct 2009 17:59:17 PDT." <4AE8E8E5.4030403@gmail.com> Date: Thu, 29 Oct 2009 12:32:41 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4AE8E8E5.4030403@gmail.com>, Doug Otis writes: > On 10/28/09 4:41 PM, Mark Andrews wrote: > > In message<4AE8A694.5010801@gmail.com>, Doug Otis writes: > >> Imposing _any_ TCP mandate represents an expedient that takes DNS in the > >> wrong direction. As such, this draft should also include a strong > >> warning that resources needed to sustain TCP services might be > >> provisioned for other transports during aberrant demand, and that it is > >> not recommended to be dependent upon TCP availability. > > > > TCP has always been expected to be implemented unless you had GOOD > > reasons to not implement it and had REALLY thought about the > > consequences. Read RFC 1034 and 1123. TCP was not MAY. It was > > SHOULD. > > The concern is about establishing a dependence upon TCP. While TCP has > often been a fall-back for truncated DNS answers, it has never been > mandated. A SHOULD is not a MUST. TCP being functional for DNS was > never assured. Even ensuring that TCP is enable does not ensure > availability of a lower priority service. In addition, TCP is not > enabled by one the roots, and most CPE equipment. While people can > configure their CPE equipment to bypass DNS proxy services lacking > proper TCP support, most do not. And prey tell how are the customers supposed to know that they can bypass it or even what values to configure? If the CPE vendor didn't want to implement a DNS server then they could have returned the DNS servers learned from upstream or none at all. Instead these vendors choose to have their DHCP clients use their box as a DNS server then failed to deliver on providing that service. > > Does anyone here really think that any proxy vendor, that doesn't > > support TCP, could successfully argue that they did that analysis > > and have the result pass a laugh test? > > What analysis? Vendors likely considered the resources needed to > support the features they offered, and decided against expenditures > related to TCP for DNS. The CPE market decided TCP was not an > overriding requirement for DNS, in favor of cost. This same cost issue > with TCP killed RDMA. Mandating that DNS servers MUST provide TCP when > the service can be carried over UDP extended to conservative MTUs of > 1280, or IMHO 1476, makes no sense. This strategy should also help > curtail growth of DNS TCP traffic. After all, TCP is not well suited to > efficiently handle DNS, and should be avoided where possible. You mean the same boxes that implement HTTP servers can't accept a TCP connection on port 53 and then make a outgoing TCP connection and then shuffle bits between the two TCP connections? This is all that is required of a the TCP component of a DNS proxy. Again, you want me to believe that they couldn't do something so simple? That the cost was too high once they had attracted the DNS traffic to their box rather than have it go to the upstream boxes directly? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From cruellyq1@adhocmgt.com Wed Oct 28 23:51:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 056863A69F3; Wed, 28 Oct 2009 23:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -67.095 X-Spam-Level: X-Spam-Status: No, score=-67.095 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQYufnqFDJoW; Wed, 28 Oct 2009 23:51:13 -0700 (PDT) Received: from 201-89-189-81.smace701.dsl.brasiltelecom.net.br (201-89-189-81.smace701.dsl.brasiltelecom.net.br [201.89.189.81]) by core3.amsl.com (Postfix) with ESMTP id E50B33A6973; Wed, 28 Oct 2009 23:51:11 -0700 (PDT) Received: from 201.89.189.81 by ietf.org; Thu, 29 Oct 2009 04:51:13 -0300 Message-ID: <000d01ca5864$34ac9560$6400a8c0@cruellyq1> From: To: Subject: Download 100% full version Date: Thu, 29 Oct 2009 04:51:13 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA5864.34AC9560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2741.2600 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA5864.34AC9560 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable BestPrice | View online version Last Chance to get 80% Off - SHOP NOW=20 =20 * MST, October 28, 2009. If an item is already on sale you'll receive the b= etter of the two discounts=2E 48.4624.7401  | Published by ietf.org.com ietf.org.com . 4849 South 34396 West . Suite A | Alaska City, J6 21693 Copyright =A92009 ietf.org.com. All rights reserved=2E ------=_NextPart_000_0007_01CA5864.34AC9560 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
BestPrice | View online v= ersion
3D"If=20
* MST, October= 28, 2009. If an item is already on sale you'll receive the better of the t= wo discounts.


------=_NextPart_000_0007_01CA5864.34AC9560-- From cruellyq1@adhocmgt.com Wed Oct 28 23:51:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 056863A69F3; Wed, 28 Oct 2009 23:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -67.095 X-Spam-Level: X-Spam-Status: No, score=-67.095 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQYufnqFDJoW; Wed, 28 Oct 2009 23:51:13 -0700 (PDT) Received: from 201-89-189-81.smace701.dsl.brasiltelecom.net.br (201-89-189-81.smace701.dsl.brasiltelecom.net.br [201.89.189.81]) by core3.amsl.com (Postfix) with ESMTP id E50B33A6973; Wed, 28 Oct 2009 23:51:11 -0700 (PDT) Received: from 201.89.189.81 by ietf.org; Thu, 29 Oct 2009 04:51:13 -0300 Message-ID: <000d01ca5864$34ac9560$6400a8c0@cruellyq1> From: To: Subject: Download 100% full version Date: Thu, 29 Oct 2009 04:51:13 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA5864.34AC9560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2741.2600 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA5864.34AC9560 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable BestPrice | View online version Last Chance to get 80% Off - SHOP NOW=20 =20 * MST, October 28, 2009. If an item is already on sale you'll receive the b= etter of the two discounts=2E 48.4624.7401  | Published by ietf.org.com ietf.org.com . 4849 South 34396 West . Suite A | Alaska City, J6 21693 Copyright =A92009 ietf.org.com. All rights reserved=2E ------=_NextPart_000_0007_01CA5864.34AC9560 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
BestPrice | View online v= ersion
3D"If=20
* MST, October= 28, 2009. If an item is already on sale you'll receive the better of the t= wo discounts.


------=_NextPart_000_0007_01CA5864.34AC9560-- From owner-namedroppers@ops.ietf.org Thu Oct 29 00:32:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65B33A6855; Thu, 29 Oct 2009 00:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[AWL=-0.402, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GdG3WxdtT3F; Thu, 29 Oct 2009 00:32:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 208C43A6405; Thu, 29 Oct 2009 00:32:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3POb-000PUM-ND for namedroppers-data0@psg.com; Thu, 29 Oct 2009 07:26:09 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3POZ-000PT9-BZ for namedroppers@ops.ietf.org; Thu, 29 Oct 2009 07:26:07 +0000 Received: from [192.168.100.90] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 1070BC2DA5; Thu, 29 Oct 2009 07:26:03 +0000 (GMT) Date: Thu, 29 Oct 2009 07:26:08 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Mark Andrews , Doug Otis cc: =?UTF-8?Q?Alfred_=EF=BF=BD?= , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt Message-ID: <9CEF96FFE6B3C34D88FD37B1@nimrod.local> In-Reply-To: <200910282341.n9SNf0Jn042987@drugs.dv.isc.org> References: <200910281344.OAA03343@TR-Sys.de> <4AE8A694.5010801@gmail.com> <200910282341.n9SNf0Jn042987@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 29 October 2009 10:41:00 +1100 Mark Andrews wrote: > Does anyone here really think that any proxy vendor, that doesn't > support TCP, could successfully argue that they did that analysis > and have the result pass a laugh test? I'm not sure middlebox vendors much care about a namedroppers laugh test or they wouldn't produce the proxy s/w they do. -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Oct 29 09:43:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7F23A67CF; Thu, 29 Oct 2009 09:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.158 X-Spam-Level: X-Spam-Status: No, score=-5.158 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFwW-lYsIZb5; Thu, 29 Oct 2009 09:43:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C11583A6835; Thu, 29 Oct 2009 09:43:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3Xzo-0009wb-Uw for namedroppers-data0@psg.com; Thu, 29 Oct 2009 16:37:08 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3Xzm-0009vb-GZ for namedroppers@ops.ietf.org; Thu, 29 Oct 2009 16:37:06 +0000 Received: from sjc-office-nat-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 9A769A9443E; Thu, 29 Oct 2009 16:37:05 +0000 (UTC) Message-ID: <4AE9C4B1.4050306@mail-abuse.org> Date: Thu, 29 Oct 2009 09:37:05 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Mark Andrews CC: Doug Otis , =?UTF-8?B?QWxmcmVkIO+/vQ==?= , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt References: <200910281344.OAA03343@TR-Sys.de> <4AE8A694.5010801@gmail.com> <200910282341.n9SNf0Jn042987@drugs.dv.isc.org> <4AE8E8E5.4030403@gmail.com> <200910290132.n9T1Wf7W027448@drugs.dv.isc.org> In-Reply-To: <200910290132.n9T1Wf7W027448@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 10/28/09 6:32 PM, Mark Andrews wrote: > In message<4AE8E8E5.4030403@gmail.com>, Doug Otis writes: >> While people can configure their CPE equipment to bypass DNS proxy >> services lacking proper TCP support, most do not. > > And prey tell how are the customers supposed to know that they can > bypass it or even what values to configure? If the CPE vendor > didn't want to implement a DNS server then they could have returned > the DNS servers learned from upstream or none at all. Instead these > vendors choose to have their DHCP clients use their box as a DNS > server then failed to deliver on providing that service. A status page often displays information obtained from the provider. A user might copy information over to their DHCP settings section, or perhaps explore their provider's support page. For this effort, they could find themselves without DNS service whenever these settings change. Perhaps the _most_ important setting a customer should make would be to change the _default_ password and ensure external access is disabled. A large number of CPE devices have been 0wned as a result of password guessing and various firmware faults. >> Mandating that DNS servers MUST provide TCP when the service can >> be carried over UDP extended to conservative MTUs of 1280, or IMHO >> 1476, makes no sense. This strategy should also help curtail >> growth of DNS TCP traffic. After all, TCP is not well suited to >> efficiently handle DNS, and should be avoided where possible. > > You mean the same boxes that implement HTTP servers can't accept a > TCP connection on port 53 and then make a outgoing TCP connection > and then shuffle bits between the two TCP connections? This is all > that is required of a the TCP component of a DNS proxy. > > Again, you want me to believe that they couldn't do something so > simple? That the cost was too high once they had attracted the DNS > traffic to their box rather than have it go to the upstream boxes > directly? Sure, it could be done. Unlike UDP, TCP requires more receive, transmit, and state buffers related to negotiations between two end points. Received buffers deal with message framing when products offer DNS related features, and transmit buffers for packet recovery. Moore's law helps, but dealing with more traffic offsets density improvements, where power and cooling also impose limits. Providers offering DNS also benefit from the reliance upon UDP. UDP requires fewer servers and is less prone to being DDoSed. -Doug From tangoing51@centralspasupply.com Thu Oct 29 14:21:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214BE3A6A21; Thu, 29 Oct 2009 14:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.061 X-Spam-Level: X-Spam-Status: No, score=-78.061 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YciV9LVpERG5; Thu, 29 Oct 2009 14:21:38 -0700 (PDT) Received: from c-71-200-22-112.hsd1.de.comcast.net (c-71-200-22-112.hsd1.de.comcast.net [71.200.22.112]) by core3.amsl.com (Postfix) with ESMTP id 4C15F3A68EF; Thu, 29 Oct 2009 14:21:37 -0700 (PDT) Received: from 71.200.22.112 by ietf.org; Thu, 29 Oct 2009 16:21:09 -0500 Message-ID: <000d01ca58dd$bbbccdd0$6400a8c0@tangoing51> From: To: Subject: OEM latest full version Date: Thu, 29 Oct 2009 16:21:09 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CA58DD.BBBCCDD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CA58DD.BBBCCDD0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable BestPrice | View online version Last Chance to get 80% Off - SHOP NOW=20 =20 * MST, October 28, 2009. If an item is already on sale you'll receive the b= etter of the two discounts. 92.4410.5098  | Published by ietf.org.com ietf.org.com . 7118 South 59688 West . Suite A | Alanson City, 7I 58258 Copyright =A92009 ietf.org.com. All rights reserved. ------=_NextPart_000_0007_01CA58DD.BBBCCDD0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
BestPrice | View online= version
3D"If=20
* MST, October= 28, 2009. If an item is already on sale you'll receive the better of the t= wo discounts.


------=_NextPart_000_0007_01CA58DD.BBBCCDD0-- From owner-namedroppers@ops.ietf.org Thu Oct 29 15:49:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6393A6914; Thu, 29 Oct 2009 15:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+YAwmb2eQvv; Thu, 29 Oct 2009 15:49:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 379A83A689E; Thu, 29 Oct 2009 15:49:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3dgX-000O6J-DB for namedroppers-data0@psg.com; Thu, 29 Oct 2009 22:41:37 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3dgU-000O57-Ff for namedroppers@ops.ietf.org; Thu, 29 Oct 2009 22:41:34 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 35BA4E6026; Thu, 29 Oct 2009 22:41:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n9TMfP9E074594; Fri, 30 Oct 2009 09:41:27 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200910292241.n9TMfP9E074594@drugs.dv.isc.org> To: Douglas Otis Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <200910281344.OAA03343@TR-Sys.de> <4AE8A694.5010801@gmail.com> <200910282341.n9SNf0Jn042987@drugs.dv.isc.org> <4AE8E8E5.4030403@gmail.com> <200910290132.n9T1Wf7W027448@drugs.dv.isc.org> <4AE9C4B1.4050306@mail-abuse.org> Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt In-reply-to: Your message of "Thu, 29 Oct 2009 09:37:05 PDT." <4AE9C4B1.4050306@mail-abuse.org> Date: Fri, 30 Oct 2009 09:41:25 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4AE9C4B1.4050306@mail-abuse.org>, Douglas Otis writes: > On 10/28/09 6:32 PM, Mark Andrews wrote: > > In message<4AE8E8E5.4030403@gmail.com>, Doug Otis writes: > >> While people can configure their CPE equipment to bypass DNS proxy > >> services lacking proper TCP support, most do not. > > > > And prey tell how are the customers supposed to know that they can > > bypass it or even what values to configure? If the CPE vendor > > didn't want to implement a DNS server then they could have returned > > the DNS servers learned from upstream or none at all. Instead these > > vendors choose to have their DHCP clients use their box as a DNS > > server then failed to deliver on providing that service. > > A status page often displays information obtained from the provider. A > user might copy information over to their DHCP settings section, or > perhaps explore their provider's support page. For this effort, they > could find themselves without DNS service whenever these settings change. Which leads us back to the CPE vendor doing a proper job. Either correctly copying data from upstream or fully implementing DNS. Customers shouldn't have to manually configure this information. > Perhaps the _most_ important setting a customer should make would be to > change the _default_ password and ensure external access is disabled. A > large number of CPE devices have been 0wned as a result of password > guessing and various firmware faults. Useful but not relevent to the discussion. > >> Mandating that DNS servers MUST provide TCP when the service can > >> be carried over UDP extended to conservative MTUs of 1280, or IMHO > >> 1476, makes no sense. This strategy should also help curtail > >> growth of DNS TCP traffic. After all, TCP is not well suited to > >> efficiently handle DNS, and should be avoided where possible. > > > > You mean the same boxes that implement HTTP servers can't accept a > > TCP connection on port 53 and then make a outgoing TCP connection > > and then shuffle bits between the two TCP connections? This is all > > that is required of a the TCP component of a DNS proxy. > > > > Again, you want me to believe that they couldn't do something so > > simple? That the cost was too high once they had attracted the DNS > > traffic to their box rather than have it go to the upstream boxes > > directly? > > Sure, it could be done. Unlike UDP, TCP requires more receive, > transmit, and state buffers related to negotiations between two > end points. Received buffers deal with message framing when products > offer DNS related features, and transmit buffers for packet recovery. > Moore's law helps, but dealing with more traffic offsets density > improvements, where power and cooling also impose limits. LOL. You think the HTTP server doesn't require these resources. One could even just translate both source and destination addresses and NAT the TCP/DNS connection. This does have the obvious problem in that it reduces the redunancy but if you track which nameservers are responding over UDP it should be reasonably robust. You could even send the SYN to all the DNS servers and just let the first to respond with a SYS/ACK continue. This gives you back the reduancy. It is not hard to provide DNS/TCP. The CPE vendors that don't are just plain lazy. > Providers offering DNS also benefit from the reliance upon UDP. UDP > requires fewer servers and is less prone to being DDoSed. > > -Doug > > > > > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Thu Oct 29 16:18:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E5E3A69AC; Thu, 29 Oct 2009 16:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.455 X-Spam-Level: X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[AWL=-0.960, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqAHCKlFbabI; Thu, 29 Oct 2009 16:18:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5F33C3A6933; Thu, 29 Oct 2009 16:18:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3eCt-000BEJ-5f for namedroppers-data0@psg.com; Thu, 29 Oct 2009 23:15:03 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3eCq-000BCY-21 for namedroppers@ops.ietf.org; Thu, 29 Oct 2009 23:15:00 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n9TNEwWe006035 for ; Thu, 29 Oct 2009 19:14:58 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200910292314.n9TNEwWe006035@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 29 Oct 2009 19:13:00 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson/DNSEXT chair Subject: [dnsext] WGLC: Gost algorithms for DNSSEC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, This note starts a WGLC for draft "Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC" URL for the document and its history: http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dnssec-gost The document is on the standards track. The WG last call is for 3 weeks as it overlaps IETF-76. The last call will end on November 19th at 23:59 UTC. This document defines the use of GOST R 34.10-2001 digital signature algorithm for DNSSEC. The document defines a DNSKEY format for the key, and a format for storing the resulting signatures in a RRSIG record. In addition the document defines a DS digest algorithm based on GOST R 34.11-94. Please read the document carefully, and send comments to the working group. Document note: The document uses in examples an unallocated DNSKEY algorithm code 249, when this document is issued as an RFC a different code WILL be allocated, the only use of this code is for early interoperabilty testing. The document process rules in this group require that at least 5 members of the working to state that they have reviewed the document and there is consensus of support to publish as a Standards Track RFC. Olafur & Andrew From owner-namedroppers@ops.ietf.org Thu Oct 29 16:50:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0FF3A67FC; Thu, 29 Oct 2009 16:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.086 X-Spam-Level: X-Spam-Status: No, score=-5.086 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvDYsnVLhSSR; Thu, 29 Oct 2009 16:50:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E4CF3A677C; Thu, 29 Oct 2009 16:50:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3eg8-000N0P-GD for namedroppers-data0@psg.com; Thu, 29 Oct 2009 23:45:16 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3eg6-000MzV-0c for namedroppers@ops.ietf.org; Thu, 29 Oct 2009 23:45:14 +0000 Received: from sjc-office-nat-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 4F5B2A94446; Thu, 29 Oct 2009 23:45:11 +0000 (UTC) Message-ID: <4AEA2907.5010501@mail-abuse.org> Date: Thu, 29 Oct 2009 16:45:11 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Mark Andrews CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt References: <200910281344.OAA03343@TR-Sys.de> <4AE8A694.5010801@gmail.com> <200910282341.n9SNf0Jn042987@drugs.dv.isc.org> <4AE8E8E5.4030403@gmail.com> <200910290132.n9T1Wf7W027448@drugs.dv.isc.org> <4AE9C4B1.4050306@mail-abuse.org> <200910292241.n9TMfP9E074594@drugs.dv.isc.org> In-Reply-To: <200910292241.n9TMfP9E074594@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 10/29/09 3:41 PM, Mark Andrews wrote: > In message<4AE9C4B1.4050306@mail-abuse.org>, Douglas Otis writes: >> On 10/28/09 6:32 PM, Mark Andrews wrote: >> >> A status page often displays information obtained from the >> provider. A user might copy information over to their DHCP >> settings section, or perhaps explore their provider's support page. >> For this effort, they could find themselves without DNS service >> whenever these settings change. > > Which leads us back to the CPE vendor doing a proper job. Either > correctly copying data from upstream or fully implementing DNS. > Customers shouldn't have to manually configure this information. Customers should still change default passwords, but few do. There are also features based upon DNS interception, such as parental controls et al. UDP makes these implementations easier. >> Sure, it could be done. Unlike UDP, TCP requires more receive, >> transmit, and state buffers related to negotiations between two >> end points. Received buffers deal with message framing when >> products offer DNS related features, and transmit buffers for >> packet recovery. Moore's law helps, but dealing with more traffic >> offsets density improvements, where power and cooling also impose >> limits. > > LOL. You think the HTTP server doesn't require these resources. The web access feature is however limited to a single session. This would not be the case for DNS over TCP, especially when manipulation might be involved. However, even the simple single session web access feature commonly contains security flaws. > One could even just translate both source and destination addresses > and NAT the TCP/DNS connection. This does have the obvious problem > in that it reduces the redunancy but if you track which nameservers > are responding over UDP it should be reasonably robust. You could > even send the SYN to all the DNS servers and just let the first to > respond with a SYS/ACK continue. This gives you back the reduancy. > > It is not hard to provide DNS/TCP. The CPE vendors that don't are > just plain lazy. This still depends upon available resources. Rather than lazy, perhaps it could be described as vendors avoiding support for more than what is absolutely necessary. An opportunity for non-lazy programmers to offer alternative reference implementations for common CPE chip-sets? -Doug From owner-namedroppers@ops.ietf.org Thu Oct 29 17:48:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD803A68AD; Thu, 29 Oct 2009 17:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0H4eztf4n7jy; Thu, 29 Oct 2009 17:48:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C511B3A67FC; Thu, 29 Oct 2009 17:48:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3fY9-0001xS-Q0 for namedroppers-data0@psg.com; Fri, 30 Oct 2009 00:41:05 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3fY7-0001xH-Lh for namedroppers@ops.ietf.org; Fri, 30 Oct 2009 00:41:03 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id C0ED4E6063; Fri, 30 Oct 2009 00:41:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n9U0exX9076269; Fri, 30 Oct 2009 11:41:00 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200910300041.n9U0exX9076269@drugs.dv.isc.org> To: Douglas Otis Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <200910281344.OAA03343@TR-Sys.de> <4AE8A694.5010801@gmail.com> <200910282341.n9SNf0Jn042987@drugs.dv.isc.org> <4AE8E8E5.4030403@gmail.com> <200910290132.n9T1Wf7W027448@drugs.dv.isc.org> <4AE9C4B1.4050306@mail-abuse.org> <200910292241.n9TMfP9E074594@drugs.dv.isc.org> <4AEA2907.5010501@mail-abuse.org> Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dns-tcp-requirements-01.txt In-reply-to: Your message of "Thu, 29 Oct 2009 16:45:11 PDT." <4AEA2907.5010501@mail-abuse.org> Date: Fri, 30 Oct 2009 11:40:59 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4AEA2907.5010501@mail-abuse.org>, Douglas Otis writes: > On 10/29/09 3:41 PM, Mark Andrews wrote: > > In message<4AE9C4B1.4050306@mail-abuse.org>, Douglas Otis writes: > >> On 10/28/09 6:32 PM, Mark Andrews wrote: > >> > >> A status page often displays information obtained from the > >> provider. A user might copy information over to their DHCP > >> settings section, or perhaps explore their provider's support page. > >> For this effort, they could find themselves without DNS service > >> whenever these settings change. > > > > Which leads us back to the CPE vendor doing a proper job. Either > > correctly copying data from upstream or fully implementing DNS. > > Customers shouldn't have to manually configure this information. > > Customers should still change default passwords, but few do. Again you make a irrelevent comment. If the vendor wanted to they could set a default password which is different for every box. This is not hard and some vendors do exactly that. > There are > also features based upon DNS interception, such as parental controls > et al. UDP makes these implementations easier. Doing this with TCP is not significantly harder than with UDP. > >> Sure, it could be done. Unlike UDP, TCP requires more receive, > >> transmit, and state buffers related to negotiations between two > >> end points. Received buffers deal with message framing when > >> products offer DNS related features, and transmit buffers for > >> packet recovery. Moore's law helps, but dealing with more traffic > >> offsets density improvements, where power and cooling also impose > >> limits. > > > > LOL. You think the HTTP server doesn't require these resources. > > The web access feature is however limited to a single session. This > would not be the case for DNS over TCP, especially when manipulation > might be involved. However, even the simple single session web access > feature commonly contains security flaws. But multiple TCP connections. > > One could even just translate both source and destination addresses > > and NAT the TCP/DNS connection. This does have the obvious problem > > in that it reduces the redunancy but if you track which nameservers > > are responding over UDP it should be reasonably robust. You could > > even send the SYN to all the DNS servers and just let the first to > > respond with a SYS/ACK continue. This gives you back the reduancy. > > > > It is not hard to provide DNS/TCP. The CPE vendors that don't are > > just plain lazy. > > This still depends upon available resources. Rather than lazy, perhaps > it could be described as vendors avoiding support for more than what is > absolutely necessary. An opportunity for non-lazy programmers to offer > alternative reference implementations for common CPE chip-sets? They exist. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From gambitsi30@gvl.esys.com Thu Oct 29 19:38:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3631C3A68EC; Thu, 29 Oct 2009 19:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.591 X-Spam-Level: X-Spam-Status: No, score=-76.591 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CUST=0.245, HELO_EQ_DSL=1.129, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SUB_MONEY=0.623, SARE_URI_OEM=0.533, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzSApid1UPEX; Thu, 29 Oct 2009 19:38:30 -0700 (PDT) Received: from ip-73-103-246-84-dsl.customer.tagcomunicazioni.it (ip-73-103-246-84-dsl.customer.tagcomunicazioni.it [84.246.103.73]) by core3.amsl.com (Postfix) with ESMTP id EF9C43A682D; Thu, 29 Oct 2009 19:38:27 -0700 (PDT) Received: by dfw-gate.raytheon.com with SMTP id 47zx788505nn.69.45051005562; Fri, 30 Oct 2009 03:38:30 +0100 Received: by 199.46.199.195 with SMTP id 72ov8298881kq.26.558348163; Fri, 30 Oct 2009 03:38:30 +0100 Date: Fri, 30 Oct 2009 03:38:30 +0100 To: dnsext-archive@ietf.org From: "Loriann Mooney" Subject: Save money with OEM soft Message-ID: <9A8PLXUZWAW57RG9V5.KUG65Y2VO1E.C6TK2LG3K4B@gambitsi30> X-Priority: 3 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1"
BestPrice | View online version
If you have any difficulty viewing this newsletter
* MST, October 28, 2009. If an item is already on sale you'll receive the better of the two discounts.


From gambitsi30@gvl.esys.com Thu Oct 29 19:38:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3631C3A68EC; Thu, 29 Oct 2009 19:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.591 X-Spam-Level: X-Spam-Status: No, score=-76.591 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CUST=0.245, HELO_EQ_DSL=1.129, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SUB_MONEY=0.623, SARE_URI_OEM=0.533, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzSApid1UPEX; Thu, 29 Oct 2009 19:38:30 -0700 (PDT) Received: from ip-73-103-246-84-dsl.customer.tagcomunicazioni.it (ip-73-103-246-84-dsl.customer.tagcomunicazioni.it [84.246.103.73]) by core3.amsl.com (Postfix) with ESMTP id EF9C43A682D; Thu, 29 Oct 2009 19:38:27 -0700 (PDT) Received: by dfw-gate.raytheon.com with SMTP id 47zx788505nn.69.45051005562; Fri, 30 Oct 2009 03:38:30 +0100 Received: by 199.46.199.195 with SMTP id 72ov8298881kq.26.558348163; Fri, 30 Oct 2009 03:38:30 +0100 Date: Fri, 30 Oct 2009 03:38:30 +0100 To: dnsext-archive@ietf.org From: "Loriann Mooney" Subject: Save money with OEM soft Message-ID: <9A8PLXUZWAW57RG9V5.KUG65Y2VO1E.C6TK2LG3K4B@gambitsi30> X-Priority: 3 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1"
BestPrice | View online version
If you have any difficulty viewing this newsletter
* MST, October 28, 2009. If an item is already on sale you'll receive the better of the two discounts.


From owner-namedroppers@ops.ietf.org Fri Oct 30 01:45:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90BF83A68A2; Fri, 30 Oct 2009 01:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.759 X-Spam-Level: X-Spam-Status: No, score=0.759 tagged_above=-999 required=5 tests=[AWL=-1.888, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSCM4H1PR2IX; Fri, 30 Oct 2009 01:45:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6DB803A67E5; Fri, 30 Oct 2009 01:45:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3mxx-0002U8-Bl for namedroppers-data0@psg.com; Fri, 30 Oct 2009 08:36:13 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3mxv-0002SD-BV for namedroppers@ops.ietf.org; Fri, 30 Oct 2009 08:36:11 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id 5F21C3EC57; Fri, 30 Oct 2009 10:42:52 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9hVDM4YwA0ch; Fri, 30 Oct 2009 10:42:52 +0300 (MSK) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id D040B3EC32; Fri, 30 Oct 2009 10:42:51 +0300 (MSK) Message-ID: <4AEA98FB.2060303@cryptocom.ru> Date: Fri, 30 Oct 2009 10:42:51 +0300 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Olafur Gudmundsson/DNSEXT chair CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC: Gost algorithms for DNSSEC References: <200910292314.n9TNEwWe006035@stora.ogud.com> In-Reply-To: <200910292314.n9TNEwWe006035@stora.ogud.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Olafur Gudmundsson/DNSEXT chair пишет: > > > Dear colleagues, > > This note starts a WGLC for draft "Use of GOST signature > algorithms in DNSKEY and RRSIG Resource Records for DNSSEC" > URL for the document and its history: > http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dnssec-gost > The document is on the standards track. > > The WG last call is for 3 weeks as it overlaps IETF-76. The last call will > end on November 19th at 23:59 UTC. > > This document defines the use of GOST R 34.10-2001 digital signature > algorithm > for DNSSEC. The document defines a DNSKEY format for the key, and a format > for storing the resulting signatures in a RRSIG record. > > In addition the document defines a DS digest algorithm based on > GOST R 34.11-94. > > Please read the document carefully, and send comments to the working group. > > Document note: The document uses in examples an unallocated DNSKEY > algorithm > code 249, when this document is issued as an RFC a different code WILL be > allocated, the only use of this code is for early interoperabilty testing. The example of signature in the current text of the draft will NOT check with this protocol code. If necessary, working examples for protocol code 249 can be supplied. dol@ > > The document process rules in this group require that at least > 5 members of the working to state that they have reviewed the document > and there is consensus of support to publish as a Standards Track RFC. > > Olafur & Andrew > > > From owner-namedroppers@ops.ietf.org Fri Oct 30 07:24:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A2603A6968; Fri, 30 Oct 2009 07:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.393 X-Spam-Level: *** X-Spam-Status: No, score=3.393 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4p+vlSg19Lhs; Fri, 30 Oct 2009 07:24:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6202B3A6965; Fri, 30 Oct 2009 07:24:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3sIK-0003rF-Ot for namedroppers-data0@psg.com; Fri, 30 Oct 2009 14:17:36 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3sIF-0003ny-4H for namedroppers@ops.ietf.org; Fri, 30 Oct 2009 14:17:32 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA036482198; Fri, 30 Oct 2009 15:16:38 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA08196; Fri, 30 Oct 2009 15:16:29 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910301416.PAA08196@TR-Sys.de> Subject: [dnsext] A few notes on the IXFR-ONLY draft To: draft-kerr-ixfr-only@cabernet.tools.IETF.ORG, namedroppers@ops.ietf.org Date: Fri, 30 Oct 2009 15:16:29 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: An interesting proposal has been made in draft-kerr-ixfr-only-00, but I did not find the time to take a closer look at it until now. (Unfortunately a draft file name has been chosen that does not allow automatic linking of the I-D as a "dnsext related" draft to the DNSEXT WG page at http://tools.ietf.org/wg/dnsext/. This has happened and cannot be changed any more, but it should serve as a reminder to '-00' draft authors to profit by the IETF tools for 'marketing' of their work.) The major deficiency of the document currently is the non-use of established precise terminology, making it somehow difficult to quickly understand the intention. The objective of the draft is to define a new QTYPE (see RFC 5395, section 3.1, for the most recent exposition of the RRTYPE currently defined categories). However, the draft very imprecisely always simply talks about an (unspecified) "type" -- not even "RR type"! Please improve the precision of the text. Similarly, I'd wish the draft to talk about "authoritative servers" -- primary and secondary servers, not simply "master" and "slave", or else state a definition of the shorthand terms. Please note that the problem you want to address most likely will occur in situations where the authoritative servers for a zone are not structured in a strict master-slave relationship, but more like (more or less fuuly-meshed) peers, making the general terms "master" and "slave" particularly inappropriate. RFC 1995 already talks about primary and secondary servers, and has introduced the terms "IXFR client" and "IXFR server", so this draft should preferably use similar terminology. Experience has shown that much confusion around the DNS has been caused by non-use of precise terms for the roles of DNS entities, and we should do better than other folks and attempt to use exemplary terminology in a consistent manner. So you will aks for better text. Ok. To give a starting point, here's my proposal for an improved Abstract: OLD: | Presents IXFR-ONLY, a way for a DNS slave to prevent a DNS master | from falling back from IXFR to AXFR. NEW: | This documents proposes a new QTYPE (Query pseudo RRtype) for the | Domain Name System (DNS). IXFR-ONLY is a variant of IXFR (RFC 1995) | that allows an authoritative server to incrementally update zone | content from another (primary) server without falling back from IXFR | to AXFR in case of an SOA Serial mismatch. This way, alternate peers | can be contacted more quickly and convergence of zone content may be | achieved much faster in important, resilient operational scenarios. At this time, I refrain from mentioning editorial nits since reworking of the text according to the principles suggested above will perhaps allow to uncover and correct these, or they will get moot anyway. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From owner-namedroppers@ops.ietf.org Fri Oct 30 07:59:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944E23A6969; Fri, 30 Oct 2009 07:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.564 X-Spam-Level: **** X-Spam-Status: No, score=4.564 tagged_above=-999 required=5 tests=[AWL=-1.986, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q75xI9rxHpn7; Fri, 30 Oct 2009 07:59:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BBB1A3A68D8; Fri, 30 Oct 2009 07:59:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3st1-000I6B-AF for namedroppers-data0@psg.com; Fri, 30 Oct 2009 14:55:31 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3ssy-000I4V-Ij for namedroppers@ops.ietf.org; Fri, 30 Oct 2009 14:55:29 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA036694478; Fri, 30 Oct 2009 15:54:38 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA08330; Fri, 30 Oct 2009 15:54:36 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910301454.PAA08330@TR-Sys.de> Subject: [dnsext] draft-ietf-dnsext-dnskey-registry-fixes-01 editorials To: scott.rose@nist.gov Date: Fri, 30 Oct 2009 15:54:35 +0100 (MEZ) Cc: namedroppers@ops.ietf.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Hello again, in an attempt to quickly follow up to the most recent versions of the active DNS related I-Ds before IETF, I arrived at your draft, draft-ietf-dnsext-dnskey-registry-fixes-01. I fully agree with that document and support it being forwarded quickly for publication as an RFC. One semi-technical question: Should the Reference to "FIPS 180-1" in the registry entry #3 better be updated to the current version, FIPS 180-3 ? Similar for "FIPS 186" --> "FIPS 186-3" ? IMO, either both or none should be quoted with the version included. This update could be done during this fixup as well (adding more notes to Section 3). A few editorials to be kept in mind: (1) Section 1, 1st para | ... codes for digital signature algorithm (...). --- v | ... codes for digital signature algorithms (...). (2) Section 2, 1st para Strike "This status . " (3) Section 5.2 Should references to FIPS 186[-3] and FIPS 180[-3] be added to this section? For completeness: [I-D.ogud-iana-protocol-maintenance-words] now published as RFC 5702! Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From owner-namedroppers@ops.ietf.org Fri Oct 30 09:44:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9F263A682B; Fri, 30 Oct 2009 09:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.463 X-Spam-Level: *** X-Spam-Status: No, score=3.463 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1HxQkGW81g1; Fri, 30 Oct 2009 09:44:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DF6B23A67AB; Fri, 30 Oct 2009 09:44:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3uVd-0005a7-JQ for namedroppers-data0@psg.com; Fri, 30 Oct 2009 16:39:29 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3uVa-0005Xk-6B for namedroppers@ops.ietf.org; Fri, 30 Oct 2009 16:39:27 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA037050710; Fri, 30 Oct 2009 17:38:30 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id RAA08470; Fri, 30 Oct 2009 17:38:28 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910301638.RAA08470@TR-Sys.de> Subject: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-01 To: ray.bellis@nominet.org.uk Date: Fri, 30 Oct 2009 17:38:28 +0100 (MEZ) Cc: namedroppers@ops.ietf.org X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Hello, I'd like to suggest a few improvements to the text in draft-ietf-dnsext-dns-tcp-requirements-01. All details mentioned are deemed editorial in nature, except for the last item, (5). (1) Abstract "TCP protocol" is weird, since the "P" already stands for "protocol". (Reading it loud, spelling out the acronym will show the mess.) Suggestion: This document updates the requirements for the support of the TCP | protocol for the transport of DNS traffic. --- vvv | This document updates the requirements for the support of the TCP as | a transport protocol for DNS traffic. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (2) Section 1 (2a) 1st para Similarly, I suggest to modify the 1st paragraph in Section 1 to avoid that nasty "xxP protocol" issue: Most DNS [RFC1035] transactions take place over the UDP [RFC0792] protocol. The TCP [RFC0793] protocol is used for zone transfers and is supported by many implementations for the transfer of other packets which exceed the protocol's original 512 byte packet-size limit. --- | Most DNS [RFC1035] transactions take place over UDP [RFC0792]. | TCP [RFC0793] is used for zone transfers and is supported by many implementations for the transfer of other packets which exceed the protocol's original 512 byte packet-size limit. Or if you prefer to be more verbose and expand the acronyms: | Most DNS [RFC1035] transactions take place over the User Datagram | Protocol (UDP, [RFC0792]). The Transmission Control Protocoll (TCP, | [RFC0793]) is used for zone transfers and is supported by many implementations for the transfer of other packets which exceed the protocol's original 512 byte packet-size limit. However, since the judgement over the implementation level is elaborated upon in the sequel, it might be better to strip down the second sentence, by striking "is supported by many implementations"; continuing with the above variant, that would end up with: | Most DNS [RFC1035] transactions take place over the User Datagram | Protocol (UDP, [RFC0792]). The Transmission Control Protocoll (TCP, | [RFC0793]) is used for zone transfers and for the transfer of other packets which exceed the protocol's original 512 byte packet-size limit. (2b) last para Again s/the TCP protocol/TCP/ . (3) Section 3 (3a) 1st para (near the end) How about s/TC flag as notice that/TV flag as a hint that/ ? ^^^^^^ ^^^^^^ (3b) after quotation from RFC 1123 I recommend to additionally quote from RFC 2181, Section 9: |9. The TC (truncated) header bit | |... | | Where TC is set, the partial RRSet that would not completely fit may | be left in the response. When a DNS client receives a reply with TC | set, it should ignore that response, and query again, using a | mechanism, such as a TCP connection, that will permit larger replies. !!!!!!!!!!!!!!!!!!!!!!!! (3c) 4th para ("Since ...") Although EDNS0 performs various field and protocol extensions, I would regard it as a single extension _Mechanism_ and therefore avoid plural here: Since the original core specifications for DNS were written, the | Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced. --- ^^^ ^^^^ Since the original core specifications for DNS were written, the | Extension Mechanism for DNS (EDNS0 [RFC2671]) has been introduced. ^^ ^^^ (3d) 5th para I would prefer to present the reasoning in the logical chain by reasons and immediate effects for clarity; this way, the term "unreliable" is getting attributed to exactly that mechanism that indeed is unreliable in practice: However, transport of UDP packets which exceed the size of the path | MTU has been found to be unreliable in some circumstances because of | IP packet fragmentation. [...] --- However, transport of UDP packets which exceed the size of the path | MTU causes IP packet fragmentation, which has been found to be | unreliable in some circumstances. [...] (3e) last para The draft says: The future that was anticipated in RFC 1123 has arrived, and the only | standardised mechanism which may have resolved the packet size issue has been found inadequate. This could be read by some interested parties rhat TCP were also inadequate. I suggest to insert "UDP-based" to disambiguate the text: The future that was anticipated in RFC 1123 has arrived, and the only | standardised UDP-based mechanism which may have resolved the packet ^^^^^^^^^^^ size issue has been found inadequate. (4) Section 4 (4a) 1st para Again, I suggest to reduce the density of "P" / "protocol": All DNS implementations MUST support both UDP and TCP transport | protocols, except as set out below. ---^^^^^^^^^ | All DNS implementations MUST support both UDP and TCP transport, | except as set out below. (4b) last para IMO, the most important "operational reason" should be spelled out explicitely, since it is of major influence on resource consumption: (re-)use of already established TCP connections! For instance: That requirement is hereby relaxed. A resolver SHOULD send a UDP query first, but MAY elect to send a TCP query instead if it has good reason to expect the response would be truncated if it were sent over UDP (with or without EDNS0) or for other operational reasons. --- That requirement is hereby relaxed. A resolver SHOULD send a UDP query first, but MAY elect to send a TCP query instead if it has good reason to expect the response would be truncated if it were sent over | UDP (with or without EDNS0) or for other operational reasons, in | particular if it already has an open TCP connection to the server. (5) Section 5 The 2nd para spells out the burden on servers and the network by parallel TCP connections to HTTP servers. Similar behavior does not make sense for (non-zone transfer) DNS transactions (cf. Section 6!). I recommend to add the requirement for clients to not do that: Other more modern protocols (e.g. HTTP [RFC2616]) have support for persistent TCP connections and operational experience has shown that long timeouts can easily cause resource exhaustion and poor response under heavy load. Intentionally opening many connections and leaving them dormant can trivially create a "denial of service" attack. This document therefore RECOMMENDS that the idle period should be of the order of TBD seconds. | | DNS clients SHOULD not open more than one TCP connection to a single | recursive resolver or authoritative server. DISCUSS: SHOULD --> MUST ?? Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From owner-namedroppers@ops.ietf.org Fri Oct 30 10:04:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1707C3A6A5C; Fri, 30 Oct 2009 10:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.837 X-Spam-Level: X-Spam-Status: No, score=-4.837 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQlwolfZ+oGS; Fri, 30 Oct 2009 10:04:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A3133A69CA; Fri, 30 Oct 2009 10:04:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3up0-000DKt-OC for namedroppers-data0@psg.com; Fri, 30 Oct 2009 16:59:30 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3uoy-000DJb-GZ for namedroppers@ops.ietf.org; Fri, 30 Oct 2009 16:59:28 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9UGxG4d032231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 09:59:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200910301454.PAA08330@TR-Sys.de> References: <200910301454.PAA08330@TR-Sys.de> Date: Fri, 30 Oct 2009 09:59:15 -0700 To: Alfred =?hp-roman8?B?SM5uZXM=?= , scott.rose@nist.gov From: Paul Hoffman Subject: Re: [dnsext] draft-ietf-dnsext-dnskey-registry-fixes-01 editorials Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 3:54 PM +0100 10/30/09, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >Hello again, >in an attempt to quickly follow up to the most recent versions of >the active DNS related I-Ds before IETF, I arrived at your draft, > draft-ietf-dnsext-dnskey-registry-fixes-01. Er, draft-ietf-dnsext-dnssec-registry-fixes-01 > >I fully agree with that document and support it being forwarded >quickly for publication as an RFC. > > >One semi-technical question: > >Should the Reference to "FIPS 180-1" in the registry entry #3 >better be updated to the current version, FIPS 180-3 ? > >Similar for "FIPS 186" --> "FIPS 186-3" ? As long as the technical details of the algorithms has not changed between versions of FIPS document, we should always refer to the -n version. This is because NIST usually names the first version without a number. Worse yet, NIST does not maintain the URLs for the old documents very well. >Should references to FIPS 186[-3] and FIPS 180[-3] be added >to this section? > >For completeness: >[I-D.ogud-iana-protocol-maintenance-words] now published as RFC 5702! No, the references for this doc should only be things that appeared outside of the proposed registry example. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Fri Oct 30 10:32:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49EF03A6858; Fri, 30 Oct 2009 10:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.857 X-Spam-Level: X-Spam-Status: No, score=-0.857 tagged_above=-999 required=5 tests=[AWL=-0.362, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7r2Zz5YVPLm3; Fri, 30 Oct 2009 10:32:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E2903A6768; Fri, 30 Oct 2009 10:32:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3vGn-000OG6-9d for namedroppers-data0@psg.com; Fri, 30 Oct 2009 17:28:13 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3vGl-000OE7-22 for namedroppers@ops.ietf.org; Fri, 30 Oct 2009 17:28:11 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 05D12C2DA3; Fri, 30 Oct 2009 17:28:05 +0000 (GMT) Date: Fri, 30 Oct 2009 17:27:37 +0000 From: Alex Bligh Reply-To: Alex Bligh To: "Alfred H?nes" , ray.bellis@nominet.org.uk cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-01 Message-ID: <81605B862CA03909F794BFE8@Ximines.local> In-Reply-To: <200910301638.RAA08470@TR-Sys.de> References: <200910301638.RAA08470@TR-Sys.de> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 30 October 2009 17:38:28 +0100 "Alfred H?nes" wrote: >| DNS clients SHOULD not open more than one TCP connection to a single >| recursive resolver or authoritative server. > > DISCUSS: SHOULD --> MUST ?? If, e.g., a library stub resolver is bound to userspace program X, and userspace program Y, each with different users, it would be a sizeable amount of work to get them to share the same TCP connection. I don't know whether technically that's two clients running on the same host, or one client. However, from a caching resolver's point of view they are indistinguishable from 2 clients behind a NAT. I would avoid changing SHOULD to MUST on the basis that it's difficult to tell whether it is complied with anyway, and we don't want to encourage a naive server operator to limit connections to one per IP or something similarly horrible. Perhaps we should add "Hosts SHOULD attempt to minimise the number of outgoing TCP connections made by clients" or similar. -- Alex Bligh From owner-namedroppers@ops.ietf.org Sat Oct 31 01:14:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8336B3A6826; Sat, 31 Oct 2009 01:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.978 X-Spam-Level: X-Spam-Status: No, score=-4.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwGNeWuiHsQu; Sat, 31 Oct 2009 01:14:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5EB993A66B4; Sat, 31 Oct 2009 01:14:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N48y7-0007LJ-H2 for namedroppers-data0@psg.com; Sat, 31 Oct 2009 08:05:51 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N48y3-0007JM-Ks for namedroppers@ops.ietf.org; Sat, 31 Oct 2009 08:05:47 +0000 Received: from sjc-office-nat-214.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 2B372A9443B; Sat, 31 Oct 2009 08:05:47 +0000 (UTC) Message-ID: <4AEBEFDA.30904@mail-abuse.org> Date: Sat, 31 Oct 2009 01:05:46 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Alex Bligh CC: Alfred H?nes , ray.bellis@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-01 References: <200910301638.RAA08470@TR-Sys.de> <81605B862CA03909F794BFE8@Ximines.local> In-Reply-To: <81605B862CA03909F794BFE8@Ximines.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 10/30/09 10:27 AM, Alex Bligh wrote: > > > --On 30 October 2009 17:38:28 +0100 "Alfred H?nes" > wrote: > >> | DNS clients SHOULD not open more than one TCP connection to a >> single | recursive resolver or authoritative server. >> >> DISCUSS: SHOULD --> MUST ?? > > If, e.g., a library stub resolver is bound to userspace program X, > and userspace program Y, each with different users, it would be a > sizeable amount of work to get them to share the same TCP connection. > I don't know whether technically that's two clients running on the > same host, or one client. However, from a caching resolver's point of > view they are indistinguishable from 2 clients behind a NAT. > > I would avoid changing SHOULD to MUST on the basis that it's > difficult to tell whether it is complied with anyway, and we don't > want to encourage a naive server operator to limit connections to one > per IP or something similarly horrible. Perhaps we should add "Hosts > SHOULD attempt to minimise the number of outgoing TCP connections > made by clients" or similar. There is no meaningful method of enforcement against clients wanting to obtain a greater portion of available bandwidth. They are likely to use multiple connections as a common strategy, which is indistinguishable from that seen from a NAT. How would someone ensure compliance? Of course, there are other transports that will not confront this issue. This is a concern as multiple connections bring TCP sooner to resource exhaustion. RFC 793 defines the TIME_WAIT state as 2 times the Maximum Segment Lifetime. The Maximum Segment Lifetime is specified as 2 minutes. RFC 1337 describes the problem TIME_WAIT is intended to avoid. (Not just ensuring receipt of FIN acknowledgment.) -Doug From owner-namedroppers@ops.ietf.org Sat Oct 31 10:02:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 668363A68AB; Sat, 31 Oct 2009 10:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2i3KNTxH6Zm; Sat, 31 Oct 2009 10:02:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7CBCF3A684A; Sat, 31 Oct 2009 10:02:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N4H9V-000EgK-0U for namedroppers-data0@psg.com; Sat, 31 Oct 2009 16:50:09 +0000 Received: from [2001:4900:1:392:213:20ff:fe1b:3bfe] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N4H9R-000Ee1-EG for namedroppers@ops.ietf.org; Sat, 31 Oct 2009 16:50:05 +0000 Received: from [81.129.215.73] (helo=octopus.home) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N4H9G-0005qP-Hs; Sat, 31 Oct 2009 16:49:55 +0000 Subject: Re: [dnsext] A few notes on the IXFR-ONLY draft Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: Joe Abley In-Reply-To: <200910301416.PAA08196@TR-Sys.de> Date: Sat, 31 Oct 2009 16:49:52 +0000 Cc: draft-kerr-ixfr-only@cabernet.tools.IETF.ORG, namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <100ED73C-DD52-431A-B455-882A7D13B888@hopcount.ca> References: <200910301416.PAA08196@TR-Sys.de> To: =?iso-8859-1?Q?Alfred_H=CEnes?= X-Mailer: Apple Mail (2.1076) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 2009-10-30, at 14:16, Alfred H=CEnes wrote: > NEW: > > | This documents proposes a new QTYPE (Query pseudo RRtype) for the > | Domain Name System (DNS). IXFR-ONLY is a variant of IXFR (RFC =20 > 1995) > | that allows an authoritative server to incrementally update zone > | content from another (primary) server without falling back from =20 > IXFR > | to AXFR in case of an SOA Serial mismatch. This way, alternate =20 > peers > | can be contacted more quickly and convergence of zone content may =20= > be > | achieved much faster in important, resilient operational scenarios. Your text misses slightly here since you misrepresent the effect of an =20= "SOA serial mismatch". The generation of an AXFR response to an =20 inbound IXFR happens for server-specific reasons (most often, you =20 would expect, because the specific delta requested by the IXFR client =20= cannot be isolated by the server). An SOA mismatch is expected for any kind of transfer; if the SOA of =20 the zone concerned was identical on both servers then no transfer of =20 any kind would normally be attempted at all. Joe