From rugginga5@afaridani.com Thu Apr 1 01:03:01 2010 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 C7E613A6A2D; Thu, 1 Apr 2010 01:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.431 X-Spam-Level: X-Spam-Status: No, score=-80.431 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_FAKE_RCVD_LINE_B=5.777, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 ZprLY0RPox1F; Thu, 1 Apr 2010 01:03:01 -0700 (PDT) Received: from fm-ip-61.247.42.120.fast.net.id (fm-ip-61.247.42.120.fast.net.id [61.247.42.120]) by core3.amsl.com (Postfix) with ESMTP id 6E0633A695F; Thu, 1 Apr 2010 01:02:57 -0700 (PDT) Received: from 61.247.42.120 by ismtp.easyspace.everyone.net; Thu, 1 Apr 2010 15:02:37 +0700 Message-ID: <000d01cad171$b192ad90$6400a8c0@rugginga5> From: dnsext-archive@ietf.org To: Subject: You have little joy in life? Lacks warmth and affection? Come to me. Date: Thu, 1 Apr 2010 15:02:37 +0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Find a perfect soul mate among the good-looking Russian women right here. http://my9571.spaces.live.com From dnsop-bounces@ietf.org Thu Apr 1 01:03:02 2010 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCCE83A6AC4 for ; Thu, 1 Apr 2010 01:03:02 -0700 (PDT) Subject: The results of your email commands From: dnsop-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1369155686==" Message-ID: Date: Thu, 01 Apr 2010 01:03:02 -0700 Precedence: bulk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF DNSOP WG mailing list X-List-Administrivia: yes Sender: dnsop-bounces@ietf.org Errors-To: dnsop-bounces@ietf.org --===============1369155686== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. No commands were found in this message. To obtain instructions, send a message containing just the word "help". - Done. --===============1369155686== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: dnsop-request@core3.amsl.com Delivered-To: dnsop-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7E613A6A2D; Thu, 1 Apr 2010 01:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.431 X-Spam-Level: X-Spam-Status: No, score=-80.431 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_FAKE_RCVD_LINE_B=5.777, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 ZprLY0RPox1F; Thu, 1 Apr 2010 01:03:01 -0700 (PDT) Received: from fm-ip-61.247.42.120.fast.net.id (fm-ip-61.247.42.120.fast.net.id [61.247.42.120]) by core3.amsl.com (Postfix) with ESMTP id 6E0633A695F; Thu, 1 Apr 2010 01:02:57 -0700 (PDT) Received: from 61.247.42.120 by ismtp.easyspace.everyone.net; Thu, 1 Apr 2010 15:02:37 +0700 Message-ID: <000d01cad171$b192ad90$6400a8c0@rugginga5> From: dnsext-archive@ietf.org To: Subject: You have little joy in life? Lacks warmth and affection? Come to me. Date: Thu, 1 Apr 2010 15:02:37 +0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Find a perfect soul mate among the good-looking Russian women right here. http://my9571.spaces.live.com --===============1369155686==-- From rugginga5@afaridani.com Thu Apr 1 01:03:01 2010 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 C7E613A6A2D; Thu, 1 Apr 2010 01:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.431 X-Spam-Level: X-Spam-Status: No, score=-80.431 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_FAKE_RCVD_LINE_B=5.777, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 ZprLY0RPox1F; Thu, 1 Apr 2010 01:03:01 -0700 (PDT) Received: from fm-ip-61.247.42.120.fast.net.id (fm-ip-61.247.42.120.fast.net.id [61.247.42.120]) by core3.amsl.com (Postfix) with ESMTP id 6E0633A695F; Thu, 1 Apr 2010 01:02:57 -0700 (PDT) Received: from 61.247.42.120 by ismtp.easyspace.everyone.net; Thu, 1 Apr 2010 15:02:37 +0700 Message-ID: <000d01cad171$b192ad90$6400a8c0@rugginga5> From: dnsext-archive@ietf.org To: Subject: You have little joy in life? Lacks warmth and affection? Come to me. Date: Thu, 1 Apr 2010 15:02:37 +0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Find a perfect soul mate among the good-looking Russian women right here. http://my9571.spaces.live.com From exuberantly@prodis.spb.ru Thu Apr 1 06:48:19 2010 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 0A59E3A6829; Thu, 1 Apr 2010 06:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -64.325 X-Spam-Level: X-Spam-Status: No, score=-64.325 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, 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, HTML_MESSAGE=0.001, PLING_QUERY=1.39, 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, SARE_RECV_SPAM_DOMN02=1.666, 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 CpLNHwcF+-Ll; Thu, 1 Apr 2010 06:48:18 -0700 (PDT) Received: from 201-68-156-138.dsl.telesp.net.br (201-68-156-138.dsl.telesp.net.br [201.68.156.138]) by core3.amsl.com (Postfix) with ESMTP id DA2C43A6784; Thu, 1 Apr 2010 06:48:16 -0700 (PDT) Received: from 201.68.156.138 by prodis.spb.ru; Thu, 1 Apr 2010 10:48:47 -0300 Message-ID: <000d01cad1a2$0d417060$6400a8c0@exuberantly> From: To: Subject: Why we stopped our communication? I expected more, Olga! Date: Thu, 1 Apr 2010 10:48:47 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_044C_01CAD1A2.0D417060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 This is a multi-part message in MIME format. ------=_NextPart_000_044C_01CAD1A2.0D417060 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You have new mail from Olga Click fast ------=_NextPart_000_044C_01CAD1A2.0D417060 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You have new mail from Olga Click fast
------=_NextPart_000_044C_01CAD1A2.0D417060-- From owner-namedroppers@ops.ietf.org Thu Apr 1 08:30:46 2010 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 D58A03A6ACE; Thu, 1 Apr 2010 08:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.143 X-Spam-Level: X-Spam-Status: No, score=-0.143 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 5GsG472Ra8XA; Thu, 1 Apr 2010 08:30:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6D57A3A6ADF; Thu, 1 Apr 2010 08:30:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxMGR-0003IZ-1G for namedroppers-data0@psg.com; Thu, 01 Apr 2010 15:24:59 +0000 Received: from [74.125.149.67] (helo=na3sys009aog101.obsmtp.com) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxMGO-0003I8-1j for namedroppers@ops.ietf.org; Thu, 01 Apr 2010 15:24:56 +0000 Received: from source ([209.85.223.197]) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKS7S6x9btyRS1pBBpVIPIBVhZkQdJGPYX@postini.com; Thu, 01 Apr 2010 08:24:55 PDT Received: by mail-iw0-f197.google.com with SMTP id 35so394550iwn.21 for ; Thu, 01 Apr 2010 08:24:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.150.16 with HTTP; Thu, 1 Apr 2010 08:24:54 -0700 (PDT) In-Reply-To: <92140.1270088620@nsa.vix.com> References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> Date: Thu, 1 Apr 2010 08:24:54 -0700 Received: by 10.231.145.5 with SMTP id b5mr231599ibv.70.1270135494905; Thu, 01 Apr 2010 08:24:54 -0700 (PDT) Message-ID: Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries From: David Ulevitch To: Paul Vixie Cc: IETF DNSEXT WG 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, Mar 31, 2010 at 7:23 PM, Paul Vixie wrote: >> Date: Wed, 31 Mar 2010 19:04:52 -0500 >> From: Michael Graff > >> Now, with this client-ip idea, it seems this may no longer work as >> expected. =A0Many more queries may be issued to servers which otherwise >> would be pooled together. > > client-ip is a bad idea for other better reasons than this. Can you elaborate? Is it because it provides more specific, better answers (read: different) based on who is querying much like Akamai, Google, Yahoo, Amazon, etc. do today on the authoritative side? Or are you opposed to something more fundamental about the idea or implementation itself? -David From owner-namedroppers@ops.ietf.org Thu Apr 1 09:29:07 2010 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 0551F3A6939; Thu, 1 Apr 2010 09:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.719 X-Spam-Level: * X-Spam-Status: No, score=1.719 tagged_above=-999 required=5 tests=[AWL=-1.517, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 3FzR3q3Ch1fo; Thu, 1 Apr 2010 09:29:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2BE243A67F6; Thu, 1 Apr 2010 09:29:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxNCn-000AdL-Bl for namedroppers-data0@psg.com; Thu, 01 Apr 2010 16:25:17 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxNCh-000Ach-RQ for namedroppers@ops.ietf.org; Thu, 01 Apr 2010 16:25:12 +0000 Received: from ajos-lt500.cis.neustar.com (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o31GP4bc040941; Thu, 1 Apr 2010 12:25:04 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.220] by ajos-lt500.cis.neustar.com (PGP Universal service); Thu, 01 Apr 2010 12:25:09 -0400 X-PGP-Universal: processed; by ajos-lt500.cis.neustar.com on Thu, 01 Apr 2010 12:25:09 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 1 Apr 2010 12:25:02 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: [dnsext] Question about content in EDNS0bis-03 Cc: ed.lewis@neustar.biz Content-Type: multipart/alternative; boundary="============_-941983392==_ma============" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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: --============_-941983392==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Referring to: http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis-edns0-03 # 6.2. OPT Record Format # ... # Any OPTION-CODE values not understood by a responder or requestor # MUST be ignored. Specifications of such options might wish to # include some kind of signaled acknowledgement. For example, an # option specification might say that if a responder sees option XYZ, # it MUST include option XYZ in its response. What does "MUST be ignored" entail? Is the option repeated in the response "silently" copied into the reply or is it omitted from the response? This question has arisen from an internal discussion. The second sentence is what is making interpretation difficult. If ignoring means to drop the option from the response, then the mere presence of the option in the response would be "some kind of signaled acknowledgement." But then there's the mention of "might wish to include" one, which implies that there would always be the option in the response. In the third sentence, what does "sees" mean - does it mean "understands"? The dilemma here is if the implementation is to adhere to the example rule, the implementation had to be aware of the option's definition, therefore be cognizant of the option (despite perhaps not implementing it). Is it thought that unrecognized (by the responder) EDNS0 options are not parsed, not read, and omitted in responses it emits? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 New pithy statement under construction... --============_-941983392==_ma============ Content-Type: text/html; charset="us-ascii" Question about content in EDNS0bis-03
Referring to:
http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis-edns0-03

# 6.2.  OPT Record Format
#
...
#   Any OPTION-CODE values not understood by a responder or requestor
#   MUST be ignored.  Specifications of such options might wish to
#   include some kind of signaled acknowledgement.  For example, an
#   option specification might say that if a responder sees option XYZ,
#   it MUST include option XYZ in its response.

What does "MUST be ignored" entail?  Is the option repeated in the response "silently" copied into the reply or is it omitted from the response?  This question has arisen from an internal discussion.

The second sentence is what is making interpretation difficult.  If ignoring means to drop the option from the response, then the mere presence of the option in the response would be "some kind of signaled acknowledgement."  But then there's the mention of "might wish to include" one, which implies that there would always be the option in the response.

In the third sentence, what does "sees" mean - does it mean "understands"?  The dilemma here is if the implementation is to adhere to the example rule, the implementation had to be aware of the option's definition, therefore be cognizant of the option (despite perhaps not implementing it).

Is it thought that unrecognized (by the responder) EDNS0 options are not parsed, not read, and omitted in responses it emits?
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

New pithy statement under construction...
--============_-941983392==_ma============-- From owner-namedroppers@ops.ietf.org Thu Apr 1 10:02:52 2010 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 DEC3D3A67F6; Thu, 1 Apr 2010 10:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.135 X-Spam-Level: X-Spam-Status: No, score=0.135 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] 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 225F5JEE8KFr; Thu, 1 Apr 2010 10:02:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7007E3A67B4; Thu, 1 Apr 2010 10:02:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxNiy-000EaJ-Rp for namedroppers-data0@psg.com; Thu, 01 Apr 2010 16:58:32 +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.71 (FreeBSD)) (envelope-from ) id 1NxNiw-000EZw-R0 for namedroppers@ops.ietf.org; Thu, 01 Apr 2010 16:58:30 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 2C49EB523F for ; Thu, 1 Apr 2010 16:58:30 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries In-Reply-To: Your message of "Thu, 01 Apr 2010 08:24:54 MST." References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 01 Apr 2010 16:58:30 +0000 Message-ID: <28432.1270141110@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, 1 Apr 2010 08:24:54 -0700 > From: David Ulevitch > > > client-ip is a bad idea for other better reasons than this. > > Can you elaborate? Is it because it provides more specific, better > answers (read: different) based on who is querying much like Akamai, > Google, Yahoo, Amazon, etc. do today on the authoritative side? Or are > you opposed to something more fundamental about the idea or > implementation itself? before i elaborate, can ed lewis talk about complexity and q-tuples again plz. From owner-namedroppers@ops.ietf.org Thu Apr 1 11:20:31 2010 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 DD9D53A6A94; Thu, 1 Apr 2010 11:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.003 X-Spam-Level: **** X-Spam-Status: No, score=4.003 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MSGID_FROM_MTA_HEADER=0.803, 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 oLSiZXJSMaa3; Thu, 1 Apr 2010 11:20:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF6553A696E; Thu, 1 Apr 2010 11:20:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxOv4-000NOd-Bw for namedroppers-data0@psg.com; Thu, 01 Apr 2010 18:15:06 +0000 Message-Id: Received: from [76.96.59.243] (helo=qmta13.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxOv1-000NNg-Fk for namedroppers@ops.ietf.org; Thu, 01 Apr 2010 18:15:04 +0000 Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta13.westchester.pa.mail.comcast.net with comcast id 0Cey1e0050vyq2s5DJF3Pc; Thu, 01 Apr 2010 18:15:03 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta05.westchester.pa.mail.comcast.net with comcast id 0JF21e00Q1EtFYL3RJF36D; Thu, 01 Apr 2010 18:15:03 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 01 Apr 2010 14:15:01 -0400 To: Samuel Weiler From: Michael StJohns Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-08 - Setting of CD Bit Cc: "Blacka, David" ,namedroppers@ops.ietf.org In-Reply-To: References: <201003241818.o2OIIPnx038928@stora.ogud.com> <20100401025540.2B43046B29@cyrus.watson.org> 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: Hi Sam - The issue is that its pretty difficult to differentiate "Waiting to contemplate the problem" from "Ignoring it and hoping it will go away again". As long as the current draft text for this problem does not make it into an RFC *and* this gets fixed in the same document as all the other fixes in the draft I will be content. Given that we're how many years down the path on -bis-updates, focusing on closing the last issues quickly is in all of our interests. So let's set a deadline and try and bring the discussion to a conclusion. Mike At 10:58 PM 3/31/2010, Samuel Weiler wrote: >On Wed, 31 Mar 2010, Michael StJohns wrote: > >>This appears to have black-holed yet again. Could we please work this through to a valid and supportable conclusion? The language in -11 is wrong. > >It's not black-holed, I just didn't delve into it in depth during the meeting week. Both this and the rollover-and-die fixes need work. >Would you feel better if we pushed a -12 saying "this section is still broken"? > >-- Sam From owner-namedroppers@ops.ietf.org Thu Apr 1 11:40:18 2010 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 988533A69B8; Thu, 1 Apr 2010 11:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.193 X-Spam-Level: X-Spam-Status: No, score=-93.193 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, 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 g0V0F9wmdcj0; Thu, 1 Apr 2010 11:40:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B156C3A67D7; Thu, 1 Apr 2010 11:40:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxPGQ-000PdH-9R for namedroppers-data0@psg.com; Thu, 01 Apr 2010 18:37:10 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxPGN-000Pcw-Du for namedroppers@ops.ietf.org; Thu, 01 Apr 2010 18:37:08 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA106376990; Thu, 1 Apr 2010 20:36:30 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA28716; Thu, 1 Apr 2010 20:36:29 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004011836.UAA28716@TR-Sys.de> Subject: Re: [dnsext] Question about content in EDNS0bis-03 To: Ed.Lewis@neustar.biz Date: Thu, 1 Apr 2010 20:36:29 +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: 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: Edward, you wrote: > ... > > Is it thought that unrecognized (by the responder) EDNS0 options > are not parsed, not read, and omitted in responses it emits? That was the idea from the previous draft version. Then, I had triggered discussion on "Building structured extensibility into EDNS0(bis)" in Please review my proposal for functional 'M' and 'E' bits nibbled off the 16-bit EDNS OPTION-CODE, and the ensuing discussion on the thread on namedroppers started with that message. To quickly recall: 'E' bit was intended to signal a request for "blind echoing" of an EDNS option in the response if the responder does not "support" the option code; E=0 (as for all option codes assigned so far) would have indicated: ignore (skip over the option if unknown); 'M' was intended to signal: respond with error if such option is seen at a responder that does not "support" it. The outcome was that structured extensibility was not liked by posters, mostly due to fears on possible problems with the established code base -- although feedback from implementers seemed to confirm that. e.g. EDNS versioning should be correctly implemented since years. IIRC, the discussion was not brought to a point where it would have been possible to declare broad consensus pro/con, and the draft authors therefore apparently simply have added a bit more text to the previous text without adding functionality or new requirements. Kind regards, Alfred Hnes. -- +------------------------+--------------------------------------------+ | 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 Apr 1 12:20:26 2010 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 71B833A659C; Thu, 1 Apr 2010 12:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.227 X-Spam-Level: X-Spam-Status: No, score=-94.227 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, 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 rY5YI++6vE9j; Thu, 1 Apr 2010 12:20:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7EA213A696A; Thu, 1 Apr 2010 12:20:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxPsV-000426-WE for namedroppers-data0@psg.com; Thu, 01 Apr 2010 19:16:32 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxPsT-00041h-AV for namedroppers@ops.ietf.org; Thu, 01 Apr 2010 19:16:29 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA106589358; Thu, 1 Apr 2010 21:15:58 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA28848; Thu, 1 Apr 2010 21:15:57 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004011915.VAA28848@TR-Sys.de> Subject: [dnsext] DNS trickery and RFC 5841 -- was: Re: [DNSOP] Misguided IPv4-IPv6 DNS trickery To: dnsop@ietf.org Date: Thu, 1 Apr 2010 21:15: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: [[ Apologies for cross-posting; this turns into scope of DNSEXT ... ]] Since most DNS queries are carried over UDP and hence cannot make use of RFC 5841, I suggest that we standardize an equivalent EDNS option, preferably with the same (inofficial) option number of 25. Then, BIG content providers and DNS service providers can start crafting DNS responses depending on the option content -- a much more general solution of the problem of the day. :-) Kind regards, Alfred. P.S.: The above RFC number obviously is an obfuscated _relative_ date, based on the birth year (1952) of some important folks, not the 1970-based epoch as in common operating systems. Please read 5841 as an encoding of 2010-04-01. -- +------------------------+--------------------------------------------+ | 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 Apr 1 13:02:39 2010 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 0AA9F3A68C8; Thu, 1 Apr 2010 13:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.175 X-Spam-Level: ** X-Spam-Status: No, score=2.175 tagged_above=-999 required=5 tests=[AWL=-1.060, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 F6xnj6NdDclP; Thu, 1 Apr 2010 13:02:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C16C73A6823; Thu, 1 Apr 2010 13:02:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxQY0-0008OK-EG for namedroppers-data0@psg.com; Thu, 01 Apr 2010 19:59:24 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxQXx-0008O4-M5 for namedroppers@ops.ietf.org; Thu, 01 Apr 2010 19:59:22 +0000 Received: from ajos-lt500.cis.neustar.com (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o31JxCJ7042682; Thu, 1 Apr 2010 15:59:12 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.220] by ajos-lt500.cis.neustar.com (PGP Universal service); Thu, 01 Apr 2010 15:59:19 -0400 X-PGP-Universal: processed; by ajos-lt500.cis.neustar.com on Thu, 01 Apr 2010 15:59:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <28432.1270141110@nsa.vix.com> References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> <28432.1270141110@nsa.vix.com> Date: Thu, 1 Apr 2010 15:59:09 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 16:58 +0000 4/1/10, Paul Vixie wrote: >before i elaborate, can ed lewis talk about complexity and q-tuples again plz. Altho this is sort of rhetorical, let's see if I can in a few paragraphs explain the sanctity of the Q-trinity and why this is not an obstacle for edns-client-ip (or vice versa). (I don't touch on combining queries.) Boiling DNS to it's very essence is the mapping of: Q-NAME, Q-TYPE, Q-CLASS to Q-NAME, Q-TYPE, Q-CLASS, RDATA. The three Q's is where I get "Q-trinity" from. Protocol archeologists can see this in examining the syntax of the question section and the answer section of a DNS message. Over time we've dressed this up a bit, namely dealing with sets of the mappings, later round-robin, and other icing. But it all boils down to the ability to ask for a Q-trinity and get back a (set of) RDATA. Over time we have seen various attempts to augment the Q-trinity or to vary the RDATA set based on something other than the Q-trinity, namely: - tell a cache to ignore what it had and fetch an authoritative answer - respond tailored to the addresses in the enveloping protocol header - assess the load on the application servers - altering answers for any other kind of policy (political or parental even). Some of these are workable, some are not. The first one is one I recommended against because it involved the header bits. The second and third use non-DNS data as part of the answer generation process. The fourth also uses non-DNS data. To stay on theme, the second item, tailoring responses to (specifically) a query source IP address has already proven workable, despite the obvious problems caches should face. Instead of being theoretical here, let's look at a example of this in use. There is support for this in BIND (views, match-source) which is so widespread that users of it take for a DNS standard (it's not!). edns-client-ip is extending the concept of BIND's views. Because views is rather undetectable (there are no traces of it in the response), caches treat the data as if "match-source" was 0.0.0.0/0 and ::/0. Without edns-client-ip, an authority server has to assume the address it sees as the source is the appropriate source. With edns-client-ip there is no need to assume. In the response, an authority server implicitly states that the response is for 0.0.0.0/0 or ::/0. With edns-client-ip the authority can scope the answer. edns-client-ip doesn't change the means by which an authority server prepares a response (if using views) but it does change how it determines the source IP address and how it expresses the applicability of the answer. For a caching server, edns-client-ip does represent a significant change to how it caches data. Fortunately, edns-client-ip is largely inappropriate for the majority of cache implementations, including just about all general purpose caches. On the other hand edns-client-ip is very important to a non-trivial population of caches which are chartered with offering DNS recursive service to topologically diverse stub resolvers and other DNS clients. Complexity is always a concern, it is what crimps scaling of any system. It is a subjective term though. We do like optimization - but each optimization is an instance of increasing complexity. (If internal combustion engines shied away from the complexity of electronic fuel injection, we'd all be mechanics in a polluted world.) The question isn't whether complexity is bad, but what it costs and what it gets us. What I would be more mindful of is the question "if edns-client-ip benefited only a certain segment of the population (of DNS instances), is it causing a fracture in the nature of the protocol?" That would be a more immediate threat. From what I've read (which includes unpublished rewrites of the -00), I don't think it does present an architectural fragmentation. I think the original draft on the topic wasn't clear enough and deserved to be hammered in a few places and parts of the definition needed to be fixed. But at the core of the proposal lay something that can work. With complexity only on those willing to take it on, edns-client-ip can be added to the protocol without causing fragmentation. Does this warrant a specification? Yes, in that there's a large enough group that needs to be interoperable. Other factors on "what's fragmentation?" - MX records are pretty much SMTP specific but that doesn't mean the protocol is fragmented. EDNS0 has a DO bit, only meaningful for DNSSEC, also not representing fragmentation. If edns-client-ip assumed any negotiation between the client and server or reinterpreted a field, flag, or bit, then it would be fragmenting the protocol. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 New pithy statement under construction... From dnsext-archive@ietf.org Thu Apr 1 21:38:55 2010 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 B47B83A67A2 for ; Thu, 1 Apr 2010 21:38:55 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Thu, 1 Apr 2010 21:38:49 -0700 (PDT) Received: from 173-160-121-73-Minnesota.hfc.comcastbusiness.net (173-160-121-73-Minnesota.hfc.comcastbusiness.net [173.160.121.73]) by core3.amsl.com (Postfix) with SMTP id 9C1A83A6978 for ; Thu, 1 Apr 2010 21:38:34 -0700 (PDT) From: Approved VIAGRA® Store Subject: News on myspace To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100402043837.9C1A83A6978@core3.amsl.com> Date: Thu, 1 Apr 2010 21:38:34 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 99606 Inc. All rights reserved.

From dmanet@ietf.org Fri Apr 2 04:29:52 2010 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 702613A68F3 for ; Fri, 2 Apr 2010 04:29:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Fri, 2 Apr 2010 04:29:45 -0700 (PDT) Received: from aaknews.com (unknown [89.44.88.172]) by core3.amsl.com (Postfix) with SMTP id 143ED3A6A45 for ; Fri, 2 Apr 2010 04:26:20 -0700 (PDT) From: Approved VIAGRA® Store Subject: Special Discount 73% for dnsext-archive@ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100402112623.143ED3A6A45@core3.amsl.com> Date: Fri, 2 Apr 2010 04:26:20 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 01187 Inc. All rights reserved.

From parex01@talldrinkofwater.com Fri Apr 2 05:01:15 2010 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 07E453A6982; Fri, 2 Apr 2010 05:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -83.25 X-Spam-Level: X-Spam-Status: No, score=-83.25 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_FAKE_RCVD_LINE_B=5.777, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, 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 8RSdQ0hQbPRr; Fri, 2 Apr 2010 05:01:14 -0700 (PDT) Received: from OldBear.cz.0.sdl.core.ttnet.cz (OldBear.cz.0.sdl.core.ttnet.cz [87.249.144.142]) by core3.amsl.com (Postfix) with ESMTP id D78FC3A6972; Fri, 2 Apr 2010 05:01:09 -0700 (PDT) Received: from 87.249.144.142 by postbox.fabulous.com; Fri, 2 Apr 2010 14:00:51 +0100 Message-ID: <000d01cad25c$23d953f0$6400a8c0@parex01> From: dnsext-archive@lists.ietf.org To: Subject: Lots of decent Russian women to choose from. Date: Fri, 2 Apr 2010 14:00:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 If you are disappointed in its second half, bold, come in! http://metalliferous28.spaces.live.com From dnsop-bounces@ietf.org Fri Apr 2 05:01:16 2010 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE273A69A4 for ; Fri, 2 Apr 2010 05:01:16 -0700 (PDT) Subject: The results of your email commands From: dnsop-bounces@ietf.org To: dnsext-archive@lists.ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1382142064==" Message-ID: Date: Fri, 02 Apr 2010 05:01:15 -0700 Precedence: bulk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF DNSOP WG mailing list X-List-Administrivia: yes Sender: dnsop-bounces@ietf.org Errors-To: dnsop-bounces@ietf.org --===============1382142064== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. No commands were found in this message. To obtain instructions, send a message containing just the word "help". - Done. --===============1382142064== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: dnsop-request@core3.amsl.com Delivered-To: dnsop-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07E453A6982; Fri, 2 Apr 2010 05:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -83.25 X-Spam-Level: X-Spam-Status: No, score=-83.25 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_FAKE_RCVD_LINE_B=5.777, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, 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 8RSdQ0hQbPRr; Fri, 2 Apr 2010 05:01:14 -0700 (PDT) Received: from OldBear.cz.0.sdl.core.ttnet.cz (OldBear.cz.0.sdl.core.ttnet.cz [87.249.144.142]) by core3.amsl.com (Postfix) with ESMTP id D78FC3A6972; Fri, 2 Apr 2010 05:01:09 -0700 (PDT) Received: from 87.249.144.142 by postbox.fabulous.com; Fri, 2 Apr 2010 14:00:51 +0100 Message-ID: <000d01cad25c$23d953f0$6400a8c0@parex01> From: dnsext-archive@lists.ietf.org To: Subject: Lots of decent Russian women to choose from. Date: Fri, 2 Apr 2010 14:00:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 If you are disappointed in its second half, bold, come in! http://metalliferous28.spaces.live.com --===============1382142064==-- From parex01@talldrinkofwater.com Fri Apr 2 05:01:15 2010 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 07E453A6982; Fri, 2 Apr 2010 05:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -83.25 X-Spam-Level: X-Spam-Status: No, score=-83.25 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_FAKE_RCVD_LINE_B=5.777, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, 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 8RSdQ0hQbPRr; Fri, 2 Apr 2010 05:01:14 -0700 (PDT) Received: from OldBear.cz.0.sdl.core.ttnet.cz (OldBear.cz.0.sdl.core.ttnet.cz [87.249.144.142]) by core3.amsl.com (Postfix) with ESMTP id D78FC3A6972; Fri, 2 Apr 2010 05:01:09 -0700 (PDT) Received: from 87.249.144.142 by postbox.fabulous.com; Fri, 2 Apr 2010 14:00:51 +0100 Message-ID: <000d01cad25c$23d953f0$6400a8c0@parex01> From: dnsext-archive@lists.ietf.org To: Subject: Lots of decent Russian women to choose from. Date: Fri, 2 Apr 2010 14:00:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 If you are disappointed in its second half, bold, come in! http://metalliferous28.spaces.live.com From dnsext-archive@ietf.org Fri Apr 2 05:04:48 2010 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 20EA03A6845 for ; Fri, 2 Apr 2010 05:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -41.956 X-Spam-Level: X-Spam-Status: No, score=-41.956 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, 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_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, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, URI_HEX=0.368, 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 yftFux0y9wep for ; Fri, 2 Apr 2010 05:04:47 -0700 (PDT) Received: from host22-22-static.14-79-b.business.telecomitalia.it (host22-22-static.14-79-b.business.telecomitalia.it [79.14.22.22]) by core3.amsl.com (Postfix) with ESMTP id 584193A67A4 for ; Fri, 2 Apr 2010 05:04:44 -0700 (PDT) From: "#1 VIAGRA Shop" To: dnsext-archive@ietf.org Subject: Yo, dnsext-archive, get 81% OFF Today MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100402120444.584193A67A4@core3.amsl.com> Date: Fri, 2 Apr 2010 05:04:44 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Hey dnsext-archive, click to enter our shop

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Yuviewud. All rights reserved.
From dnsext-archive@lists.ietf.org Fri Apr 2 05:06:14 2010 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 6AADD3A67AE for ; Fri, 2 Apr 2010 05:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -41.956 X-Spam-Level: X-Spam-Status: No, score=-41.956 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, 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_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, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, URI_HEX=0.368, 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 b3giwFlC2tTA for ; Fri, 2 Apr 2010 05:06:13 -0700 (PDT) Received: from host22-22-static.14-79-b.business.telecomitalia.it (host22-22-static.14-79-b.business.telecomitalia.it [79.14.22.22]) by core3.amsl.com (Postfix) with ESMTP id BED203A67D9 for ; Fri, 2 Apr 2010 05:06:12 -0700 (PDT) From: "#1 VIAGRA Shop" To: dnsext-archive@lists.ietf.org Subject: Yo, dnsext-archive, get 81% OFF Today MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100402120612.BED203A67D9@core3.amsl.com> Date: Fri, 2 Apr 2010 05:06:12 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Hey dnsext-archive, click to enter our shop

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Ajlifqh. All rights reserved.
From minotaurfrs@satarah.com Fri Apr 2 12:23:01 2010 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 92FDF3A6C2A; Fri, 2 Apr 2010 12:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -84.2 X-Spam-Level: X-Spam-Status: No, score=-84.2 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_STATICB=1.372, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RELAY_IS_203=0.994, 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 JRvO-m938hWb; Fri, 2 Apr 2010 12:23:01 -0700 (PDT) Received: from static-mum-203.94.229.131.mtnl.net.in (static-mum-203.94.229.131.mtnl.net.in [203.94.229.131]) by core3.amsl.com (Postfix) with ESMTP id 1C2553A6B9E; Fri, 2 Apr 2010 11:49:20 -0700 (PDT) Received: from 203.94.229.131 by pop.directnic.com; Sat, 3 Apr 2010 00:19:31 +0530 Date: Sat, 3 Apr 2010 00:19:31 +0530 From: dnsext-archive@ietf.org Subject: Find a Russian wife here. To: Message-ID: <000d01cad295$3ab17970$6400a8c0@minotaurfrs> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal How about Russian bride? http://copybook80.spaces.live.com From dnsop-bounces@ietf.org Fri Apr 2 12:23:03 2010 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4A93A6B8D for ; Fri, 2 Apr 2010 12:23:03 -0700 (PDT) Subject: The results of your email commands From: dnsop-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0712586007==" Message-ID: Date: Fri, 02 Apr 2010 12:23:02 -0700 Precedence: bulk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF DNSOP WG mailing list X-List-Administrivia: yes Sender: dnsop-bounces@ietf.org Errors-To: dnsop-bounces@ietf.org --===============0712586007== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. No commands were found in this message. To obtain instructions, send a message containing just the word "help". - Done. --===============0712586007== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: dnsop-request@core3.amsl.com Delivered-To: dnsop-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92FDF3A6C2A; Fri, 2 Apr 2010 12:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -84.2 X-Spam-Level: X-Spam-Status: No, score=-84.2 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_STATICB=1.372, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RELAY_IS_203=0.994, 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 JRvO-m938hWb; Fri, 2 Apr 2010 12:23:01 -0700 (PDT) Received: from static-mum-203.94.229.131.mtnl.net.in (static-mum-203.94.229.131.mtnl.net.in [203.94.229.131]) by core3.amsl.com (Postfix) with ESMTP id 1C2553A6B9E; Fri, 2 Apr 2010 11:49:20 -0700 (PDT) Received: from 203.94.229.131 by pop.directnic.com; Sat, 3 Apr 2010 00:19:31 +0530 Date: Sat, 3 Apr 2010 00:19:31 +0530 From: dnsext-archive@ietf.org Subject: Find a Russian wife here. To: Message-ID: <000d01cad295$3ab17970$6400a8c0@minotaurfrs> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal How about Russian bride? http://copybook80.spaces.live.com --===============0712586007==-- From diffserv-interest-bounces@ietf.org Fri Apr 2 12:23:03 2010 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D773A6B8D for ; Fri, 2 Apr 2010 12:23:03 -0700 (PDT) Subject: The results of your email commands From: diffserv-interest-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1129304900==" Message-ID: Date: Fri, 02 Apr 2010 12:23:02 -0700 Precedence: bulk X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.1.9 List-Id: Differentiated services general discussion X-List-Administrivia: yes Sender: diffserv-interest-bounces@ietf.org Errors-To: diffserv-interest-bounces@ietf.org --===============1129304900== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. No commands were found in this message. To obtain instructions, send a message containing just the word "help". - Done. --===============1129304900== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: diffserv-interest-request@core3.amsl.com Delivered-To: diffserv-interest-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92FDF3A6C2A; Fri, 2 Apr 2010 12:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -84.2 X-Spam-Level: X-Spam-Status: No, score=-84.2 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_STATICB=1.372, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RELAY_IS_203=0.994, 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 JRvO-m938hWb; Fri, 2 Apr 2010 12:23:01 -0700 (PDT) Received: from static-mum-203.94.229.131.mtnl.net.in (static-mum-203.94.229.131.mtnl.net.in [203.94.229.131]) by core3.amsl.com (Postfix) with ESMTP id 1C2553A6B9E; Fri, 2 Apr 2010 11:49:20 -0700 (PDT) Received: from 203.94.229.131 by pop.directnic.com; Sat, 3 Apr 2010 00:19:31 +0530 Date: Sat, 3 Apr 2010 00:19:31 +0530 From: dnsext-archive@ietf.org Subject: Find a Russian wife here. To: Message-ID: <000d01cad295$3ab17970$6400a8c0@minotaurfrs> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal How about Russian bride? http://copybook80.spaces.live.com --===============1129304900==-- From uniroyalmt@adv-laser.com Fri Apr 2 12:23:05 2010 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 CE8923A68A9 for ; Fri, 2 Apr 2010 12:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -84.2 X-Spam-Level: X-Spam-Status: No, score=-84.2 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_STATICB=1.372, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RELAY_IS_203=0.994, 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 sGQFp30CSMR9 for ; Fri, 2 Apr 2010 12:23:04 -0700 (PDT) Received: from static-mum-203.94.229.131.mtnl.net.in (static-mum-203.94.229.131.mtnl.net.in [203.94.229.131]) by core3.amsl.com (Postfix) with ESMTP id 1D4203A686D for ; Fri, 2 Apr 2010 11:49:43 -0700 (PDT) Received: from 203.94.229.131 by email.adv-laser.com; Sat, 3 Apr 2010 00:19:39 +0530 Date: Sat, 3 Apr 2010 00:19:39 +0530 From: dnsext-archive@lists.ietf.org Subject: I sexual Russian blonde, want to see, come closer. To: Message-ID: <000d01cad295$3fe17260$6400a8c0@uniroyalmt> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal 9 ladies are online now (Russia, dating) http://copybook80.spaces.live.com From dmailer.ok@ietf.org Sat Apr 3 02:31:59 2010 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 2EF0128C0EC for ; Sat, 3 Apr 2010 02:31:59 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sat, 3 Apr 2010 02:31:52 -0700 (PDT) Received: from accufacts.com (unknown [123.28.126.120]) by core3.amsl.com (Postfix) with SMTP id 068963A6964 for ; Sat, 3 Apr 2010 02:26:21 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100403092625.068963A6964@core3.amsl.com> Date: Sat, 3 Apr 2010 02:26:21 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 14703 Inc. All rights reserved.

From entmib-archive@lists.ietf.org Sat Apr 3 02:38:48 2010 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 7C0A53A67FE for ; Sat, 3 Apr 2010 02:38:48 -0700 (PDT) X-Quarantine-ID: <4nYx7l7lCsoc> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sat, 3 Apr 2010 02:38:41 -0700 (PDT) Received: from advpayroll.com (unknown [58.68.66.252]) by core3.amsl.com (Postfix) with SMTP id A5FFD3A69E8 for ; Sat, 3 Apr 2010 02:35:06 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100403093609.A5FFD3A69E8@core3.amsl.com> Date: Sat, 3 Apr 2010 02:35:06 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 03254 Inc. All rights reserved.

From dnsext-archive@ietf.org Sat Apr 3 16:20:25 2010 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 D5D133A6823 for ; Sat, 3 Apr 2010 16:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -39.284 X-Spam-Level: X-Spam-Status: No, score=-39.284 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, NUMERIC_HTTP_ADDR=0.001, 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, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_WS_SURBL=10, URI_HEX=0.368, 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 tapPZffBsC83 for ; Sat, 3 Apr 2010 16:20:24 -0700 (PDT) Received: from host140-242-static.225-95-b.business.telecomitalia.it (host140-242-static.225-95-b.business.telecomitalia.it [95.225.242.140]) by core3.amsl.com (Postfix) with ESMTP id D9BA73A67FC for ; Sat, 3 Apr 2010 16:20:23 -0700 (PDT) From: "Approved VIAGRA e-store" To: dnsext-archive@ietf.org Subject: Wassup dnsext-archive, your personal 80% discount code is DA374C5E MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100403232023.D9BA73A67FC@core3.amsl.com> Date: Sat, 3 Apr 2010 16:20:23 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Click here to browse shop's content
 

c 1999-2009 YIDA, Inc.
This e-mail was sent to dnsext-archive@ietf.org.

Click here to unsubscribe
From dnsext-archive@lists.ietf.org Sat Apr 3 16:20:36 2010 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 D26F73A6823 for ; Sat, 3 Apr 2010 16:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -39.285 X-Spam-Level: X-Spam-Status: No, score=-39.285 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, 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, SARE_FROM_DRUGS=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_WS_SURBL=10, URI_HEX=0.368, 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 NnCxhc+Kl08w for ; Sat, 3 Apr 2010 16:20:34 -0700 (PDT) Received: from host140-242-static.225-95-b.business.telecomitalia.it (host140-242-static.225-95-b.business.telecomitalia.it [95.225.242.140]) by core3.amsl.com (Postfix) with ESMTP id B0E743A67FC for ; Sat, 3 Apr 2010 16:20:33 -0700 (PDT) From: "Approved VIAGRA e-store" To: dnsext-archive@lists.ietf.org Subject: Wassup dnsext-archive, your personal 80% discount code is 57BE0F4 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100403232033.B0E743A67FC@core3.amsl.com> Date: Sat, 3 Apr 2010 16:20:33 -0700 (PDT) News
Trouble viewing these images? See the online version of this e-mail.

Click here to browse shop's content
 

c 1999-2009 BIOYLI, Inc.
This e-mail was sent to dnsext-archive@lists.ietf.org.

Click here to unsubscribe
From dmin@ietf.org Sat Apr 3 16:54:23 2010 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 AC4E23A6907 for ; Sat, 3 Apr 2010 16:54:23 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sat, 3 Apr 2010 16:54:16 -0700 (PDT) Received: from 138smtph3wg.tigo.com.sv (138smtph3wg.tigo.com.sv [200.85.31.138]) by core3.amsl.com (Postfix) with SMTP id 2AD6F3A6819 for ; Sat, 3 Apr 2010 16:54:10 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google To: MIME-Version: 1.0 Content-Type: text/html X-Antivirus: avast! (VPS 100403-1, 03/04/2010), Outbound message X-Antivirus-Status: Clean Message-Id: <20100403235414.2AD6F3A6819@core3.amsl.com> Date: Sat, 3 Apr 2010 16:54:10 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 62607 Inc. All rights reserved.

From dnsext-archive@ietf.org Sun Apr 4 09:27:52 2010 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 9AD6D3A6A6D for ; Sun, 4 Apr 2010 09:27:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char A9 hex): From: \251 Pfizer Inc \256 1[...] X-Spam-Flag: NO X-Spam-Score: -71.611 X-Spam-Level: X-Spam-Status: No, score=-71.611 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_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, 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_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 RWK2jzNh7n36 for ; Sun, 4 Apr 2010 09:27:51 -0700 (PDT) Received: from host-89-228-134-246.gorzow.mm.pl (host-89-228-134-246.gorzow.mm.pl [89.228.134.246]) by core3.amsl.com (Postfix) with SMTP id 170E53A6A6B for ; Sun, 4 Apr 2010 09:27:50 -0700 (PDT) From: Pfizer Inc 1975-2010 To: dnsext-archive@ietf.org Subject: Dear dnsext-archive@ietf.org April 91% 0FF MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100404162751.170E53A6A6B@core3.amsl.com> Date: Sun, 4 Apr 2010 09:27:50 -0700 (PDT)
Click here to view as a web page.

View image in browser now
From dmin@ietf.org Sun Apr 4 12:40:02 2010 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 4A2993A6964 for ; Sun, 4 Apr 2010 12:40:02 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sun, 4 Apr 2010 12:39:55 -0700 (PDT) Received: from 239-226-93-178.pool.ukrtel.net (239-226-93-178.pool.ukrtel.net [178.93.226.239]) by core3.amsl.com (Postfix) with SMTP id 097493A699D for ; Sun, 4 Apr 2010 12:39:52 -0700 (PDT) From: Approved VIAGRA® Store Subject: New Private Message for dnsext-archive@ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100404193954.097493A699D@core3.amsl.com> Date: Sun, 4 Apr 2010 12:39:52 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 04773 Inc. All rights reserved.

From dm@ietf.org Sun Apr 4 13:17:55 2010 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 6A8A23A6A14 for ; Sun, 4 Apr 2010 13:17:55 -0700 (PDT) X-Quarantine-ID: <9elcDwTEqCQ4> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sun, 4 Apr 2010 13:17:48 -0700 (PDT) Received: from 41-85-132-95.pool.ukrtel.net (41-85-132-95.pool.ukrtel.net [95.132.85.41]) by core3.amsl.com (Postfix) with SMTP id CC8023A6A07 for ; Sun, 4 Apr 2010 13:17:43 -0700 (PDT) From: Approved VIAGRA® Store Subject: Your Future Order with 76% off retail To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100404201746.CC8023A6A07@core3.amsl.com> Date: Sun, 4 Apr 2010 13:17:43 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 79233 Inc. All rights reserved.

From dmin@ietf.org Mon Apr 5 04:51:44 2010 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 DE81C28C11B for ; Mon, 5 Apr 2010 04:51:44 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 5 Apr 2010 04:51:38 -0700 (PDT) Received: from afmp.nl (unknown [124.123.198.71]) by core3.amsl.com (Postfix) with SMTP id 2378D3A6979 for ; Mon, 5 Apr 2010 04:49:39 -0700 (PDT) From: Approved VIAGRA® Store Subject: You have a new personal message To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100405114941.2378D3A6979@core3.amsl.com> Date: Mon, 5 Apr 2010 04:49:39 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 82740 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Mon Apr 5 09:01:23 2010 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 AD9E33A6868; Mon, 5 Apr 2010 09:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.083 X-Spam-Level: X-Spam-Status: No, score=-95.083 tagged_above=-999 required=5 tests=[AWL=-1.933, BAYES_50=0.001, 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, 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 Ro1voQhT5+eP; Mon, 5 Apr 2010 09:01:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27ABA3A6A22; Mon, 5 Apr 2010 09:01:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NyocN-000I9a-31 for namedroppers-data0@psg.com; Mon, 05 Apr 2010 15:53:39 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NyocI-000I8T-6P for namedroppers@ops.ietf.org; Mon, 05 Apr 2010 15:53:35 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA132782775; Mon, 5 Apr 2010 17:52:55 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id RAA04719; Mon, 5 Apr 2010 17:52:54 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004051552.RAA04719@TR-Sys.de> Subject: Re: [dnsext] WGLC Summary: Unknown RR's to Draft standard (rfc3597bis) To: rwfranks@acm.org Date: Mon, 5 Apr 2010 17:52:53 +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: At Mon, 29 Mar 2010 13:42:04 +0100, Dick Franks wrote: > All, > > On 28 March 2010 03:00, Olafur Gudmundsson wrote: > >> - Whether to continue to allow compression of, and require support >> for decompression of, the obsolete and experimental RR types from >> RFC1035 (MD, MF, MB, MG, MR and MINFO), as discussed in >> >> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00551.html >> > > Like it or not, these obsolete RR types are still part of RFC1035 > until formally expunged by standards action elsewhere. IMHO this seems > out of scope for RFC3597bis. > > ... Well, 3597bis targets *Draft Standard*, and it is not uncommon for *Proposed Standard* documents to Update a full Standard RFC. (Otherwise, the Full Standards could essentially never been changed because on the way from DS to FS, no significant technical changes should be introduced, but this would be the only opportunity to modify a FS under that premise.) Note however that RFC 1035 *explicitly* (and repeatedly) states that {MD, MF} are OBSOLETE and {MB, MG, MINFO, MR, NULL} are EXPERIMENTAL. According to my understanding, this is not overridden by the FS status of RFC 1035. Thus these RR types are not under Full Standard status. Furthermore, RFC 1123 (October 1999) said: ! Name servers MUST be able to load all RR types except MD and ! MF from configuration files. The MD and MF types are ! obsolete and MUST NOT be implemented; in particular, name ! servers MUST NOT load these types from configuration files. [...] ! The RR types MB, MG, MR, NULL, MINFO and RP are ! considered experimental, and applications that use the ! DNS cannot expect these RR types to be supported by ! most domains. Furthermore these types are subject to ! redefinition. You had proposed the following text: > To avoid such corruption, servers MUST NOT compress domain names > embedded in the RDATA of types that are class-specific or not well- > known. This requirement was stated in [RFC1123] without defining the >| term "well-known"; it is hereby specified that the RR types defined >| in [RFC1035] section 3.3 are the only types eligible for compression. IMHO "the RR types defined in [RFC1035] section 3.3" could be read as a (soft) requirement to support the legacy types listed in RFC 1035, section 3.3, including the "MUST NOT implement" (RFC 1123) RR types MD and MF. Do we really want that? Do we really need a specific document, "Section 8.2 of RFC 1035 is obsolete" (etc.) ? If we adopt the above text, I suggest to amend it by: | Note however that, according to [RFC1123], the obsolete RR types from | section 3.3 of [RFC1035] (i.e., MD and MF) MUST NOT be implemented | and support of the experimental RR types from section 3.3 of | [RFC1035] (whereof MB, MG, MR, and MINFO carry domain names in their | RDATA) cannot be expected; thus, implementations still supporting | these RR types SHOULD NOT apply domain name compression for such RRs | any more because caches cannot be expected to support them and being | able to undo the compression. This is a complicated, yet conservative rule. But I'd actually prefer a simple and clean rule, dropping these RR types and clearly stating the positive list of RR types for which compression applies (CNAME, MX, NS, PTR, and SOA). 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 Apr 5 10:39:29 2010 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 970BD3A67C2; Mon, 5 Apr 2010 10:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.722 X-Spam-Level: * X-Spam-Status: No, score=1.722 tagged_above=-999 required=5 tests=[AWL=-1.278, BAYES_50=0.001, 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 r8-dml7k4U24; Mon, 5 Apr 2010 10:39:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 58B953A679C; Mon, 5 Apr 2010 10:39:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NyqC8-0006B3-7R for namedroppers-data0@psg.com; Mon, 05 Apr 2010 17:34:40 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NyqC4-00069d-UW for namedroppers@ops.ietf.org; Mon, 05 Apr 2010 17:34:37 +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 64C141ECB4E8 for ; Mon, 5 Apr 2010 17:34:35 +0000 (UTC) Date: Mon, 5 Apr 2010 13:34:33 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Draft minutes from IETF 77 Message-ID: <20100405173433.GE55035@shinkuro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="aT9PWwzfKXlsBJM1" 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: --aT9PWwzfKXlsBJM1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear colleagues, Please review the attached minutes for accuracy. Send corrections to me or the list. Thanks to Matt for getting these to us so quickly (immediately after the session!), and apologies to all for not having posted them sooner. If I hear no objection, I shall send these minutes to the Secretariat a week hence (2010-04-12). Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. --aT9PWwzfKXlsBJM1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="minutes-d1-2010-04-05a.txt" Minutes of the DNS Extensions Working Group meeting at IETF 77 Prepared by Matthew Pounsett dnsext - 2010/03/23 13:00 PDT Name Equivalence / Aliases Issue ================================ Constraints Changes -------------------- NEW: Solutions must work with intermediary iterators and forwarders NEW: Delegation hierarchy needs to be taken into account. Records near the root of the tree can't make definitive statements about what is happening further from the root. CHANGE: Perhaps instead of "may require upgrades of client resolvers" perhaps "may require upgrades of client applications" Questions To Answer ------------------- 1) Do we require UPDATEs to modify nodes that are "the same"? 1a) Do we require immediate updates of all nodes, or can we allow for some delay required by copy operations? 1b) By "immediate" do we mean that all authoritative servers need to updated instantly? 1c) By "immediate" do we mean that caches need to be updated instantly too? (out of scope) 2) Is it okay that one of the names pointing to a node is an alias? Do we need to know what all of the aliases are? 3) If we do things way X, what breaks for the community? What about way Y? Possibly a more tractable question than finding all possible use cases. 4) Before trying to get a complete taxonomy, should we find out how the community feels about the hard constraints? draft-ietf-dnsext-dnssec-bis-updates-10 ======================================= - CD bit handling logic needs to be sorted out on mailing list - Changes due to "rollover and die"? Deferred until after rollover discussion - Time to WGLC and publish? Unanswered draft-dempsky-dnscurve-01 ========================= Comments -------- - client privacy is an interesting problem solved by this technology and by no other - point to point encryption may cause problems with middleboxes blocking DNS traffic they don't recognize - integrity not encryption should be considered to solve the middlebox problem - should consider a better researched curve - Diffie-Hellman results should be cached - should answer the question "What problem are we trying to solve?" before choosing to adopt this work and start engineering Sense of the room ----------------- Who has read this draft? enough How many people support adoption of this document? quiet How many people are opposed to adoption of this draft? quiet How many people have not made up their minds? more significant Taking this to the mailing list for followup. Paul Vixie - 0x20 ================= Should this progress with the intention of amending 1035? support, few opposed Should the document be spit into Standards Track and Informational? Unanswered Roll over and die ================= Should some changed be incorporated in draft-ietf-dnsext-dnssec-bis- updates? Additional discussion deferred to the list. --aT9PWwzfKXlsBJM1-- From seethedc933@truegrooves.com Mon Apr 5 13:28:29 2010 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 7A21128C11D; Mon, 5 Apr 2010 13:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.842 X-Spam-Level: *** X-Spam-Status: No, score=3.842 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_REPLICA_ROLEX=3.157, GB_ROLEX=5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, 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 kfmGJ8ij2nAC; Mon, 5 Apr 2010 13:28:28 -0700 (PDT) Received: from 200141084238.user.veloxzone.com.br (200141084238.user.veloxzone.com.br [200.141.84.238]) by core3.amsl.com (Postfix) with ESMTP id BC02528C1C3; Mon, 5 Apr 2010 13:21:37 -0700 (PDT) Received: from 200.141.84.238 by truegrooves.com; Mon, 5 Apr 2010 17:21:11 -0300 Message-ID: <000d01cad4fd$88329070$6400a8c0@seethedc933> From: dnsext-archive@lists.ietf.org To: Subject: Class and elegance Date: Mon, 5 Apr 2010 17:21:11 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD4FD.88329070" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2800.1807 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD4FD.88329070 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Swiss Replica & Co. is offering all Rolex Watches Replica and also the Brei= tling Replica Watches.Our approach is to match the practices of the origina= l watchmaker to the closest degree of replica rolex and breitling, ensuring= the end result is virtually indistinguishable. Designer replica watches ar= e a craft that we take seriously and take pride in. Quality is essential bo= th for Rolex and Breitling.Replica watches are the best solution if you can= not afford to purchase so expensive original Rolex and Breitling watches.Ou= r online shop can offer you wonderful replica watches collections.Visit UsP= rice: $229Price: $244Price: $249Price: $399Price: $229Price: $244Price: $24= 9Price: $389Swiss Replica & Co. is about honesty and integrity; a straightf= orward approach to replica watch sales. As a partnership in this business w= e made it our very first priority to establish fair, transparent business p= ractices for our clientele. We=92d each been involved in various online mer= chant initiatives previously and knew the traps some online businesses fall= into=2E ------=_NextPart_000_0007_01CAD4FD.88329070 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <= td>
=

Swiss Replica & = Co. is offering all Rolex Watches Replica and also the Breitling Replica Wa= tches.

Our approach is to match the practices of the origin= al watchmaker to the closest degree of replica rolex and breitling, ensurin= g the end result is virtually indistinguishable. Designer replica watches a= re a craft that we take seriously and take pride in. Quality is essential b= oth for Rolex and Breitling.

Replica watches are the best so= lution if you cannot afford to purchase so expensive original Rolex and Bre= itling watches.

Our online shop can offer you wonderful re= plica watches collections.

Visit Us

3D""<= /a>

Price: $249

3D""

Price: $229

3D""

Price: $244

3D""

Price: $399

3D""<= /a>

Price: $229

3D""

Price: $244

3D""<= /a>

Price: $249

3D""

Price: $389

Sw= iss Replica & Co. is about honesty and integrity; a straightforward approac= h to replica watch sales. As a partnership in this business we made it our = very first priority to establish fair, transparent business practices for o= ur clientele. We=92d each been involved in various online merchant initiati= ves previously and knew the traps some online businesses fall into.

------=_NextPart_000_0007_01CAD4FD.88329070-- From dnsop-bounces@ietf.org Mon Apr 5 13:28:31 2010 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671FC28C125 for ; Mon, 5 Apr 2010 13:28:31 -0700 (PDT) Subject: The results of your email commands From: dnsop-bounces@ietf.org To: dnsext-archive@lists.ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0551485076==" Message-ID: Date: Mon, 05 Apr 2010 13:28:29 -0700 Precedence: bulk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF DNSOP WG mailing list X-List-Administrivia: yes Sender: dnsop-bounces@ietf.org Errors-To: dnsop-bounces@ietf.org --===============0551485076== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Unprocessed: tling Replica Watches.Our approach is to match the practices of the origina= l watchmaker to the closest degree of replica rolex and breitling, ensuring= the end result is virtually indistinguishable. Designer replica watches ar= e a craft that we take seriously and take pride in. Quality is essential bo= th for Rolex and Breitling.Replica watches are the best solution if you can= not afford to purchase so expensive original Rolex and Breitling watches.Ou= r online shop can offer you wonderful replica watches collections.Visit UsP= rice: $229Price: $244Price: $249Price: $399Price: $229Price: $244Price: $24= 9Price: $389Swiss Replica & Co. is about honesty and integrity; a straightf= orward approach to replica watch sales. As a partnership in this business w= e made it our very first priority to establish fair, transparent business p= ractices for our clientele. We=92d each been involved in various online mer= chant initiatives previously and knew the traps some online businesses fall= into=2E - Done. --===============0551485076== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: dnsop-request@core3.amsl.com Delivered-To: dnsop-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A21128C11D; Mon, 5 Apr 2010 13:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.842 X-Spam-Level: *** X-Spam-Status: No, score=3.842 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_REPLICA_ROLEX=3.157, GB_ROLEX=5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, 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 kfmGJ8ij2nAC; Mon, 5 Apr 2010 13:28:28 -0700 (PDT) Received: from 200141084238.user.veloxzone.com.br (200141084238.user.veloxzone.com.br [200.141.84.238]) by core3.amsl.com (Postfix) with ESMTP id BC02528C1C3; Mon, 5 Apr 2010 13:21:37 -0700 (PDT) Received: from 200.141.84.238 by truegrooves.com; Mon, 5 Apr 2010 17:21:11 -0300 Message-ID: <000d01cad4fd$88329070$6400a8c0@seethedc933> From: dnsext-archive@lists.ietf.org To: Subject: Class and elegance Date: Mon, 5 Apr 2010 17:21:11 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD4FD.88329070" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2800.1807 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD4FD.88329070 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Swiss Replica & Co. is offering all Rolex Watches Replica and also the Brei= tling Replica Watches.Our approach is to match the practices of the origina= l watchmaker to the closest degree of replica rolex and breitling, ensuring= the end result is virtually indistinguishable. Designer replica watches ar= e a craft that we take seriously and take pride in. Quality is essential bo= th for Rolex and Breitling.Replica watches are the best solution if you can= not afford to purchase so expensive original Rolex and Breitling watches.Ou= r online shop can offer you wonderful replica watches collections.Visit UsP= rice: $229Price: $244Price: $249Price: $399Price: $229Price: $244Price: $24= 9Price: $389Swiss Replica & Co. is about honesty and integrity; a straightf= orward approach to replica watch sales. As a partnership in this business w= e made it our very first priority to establish fair, transparent business p= ractices for our clientele. We=92d each been involved in various online mer= chant initiatives previously and knew the traps some online businesses fall= into=2E ------=_NextPart_000_0007_01CAD4FD.88329070 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <= td>
=

Swiss Replica & = Co. is offering all Rolex Watches Replica and also the Breitling Replica Wa= tches.

Our approach is to match the practices of the origin= al watchmaker to the closest degree of replica rolex and breitling, ensurin= g the end result is virtually indistinguishable. Designer replica watches a= re a craft that we take seriously and take pride in. Quality is essential b= oth for Rolex and Breitling.

Replica watches are the best so= lution if you cannot afford to purchase so expensive original Rolex and Bre= itling watches.

Our online shop can offer you wonderful re= plica watches collections.

Visit Us

3D""<= /a>

Price: $249

3D""

Price: $229

3D""

Price: $244

3D""

Price: $399

3D""<= /a>

Price: $229

3D""

Price: $244

3D""<= /a>

Price: $249

3D""

Price: $389

Sw= iss Replica & Co. is about honesty and integrity; a straightforward approac= h to replica watch sales. As a partnership in this business we made it our = very first priority to establish fair, transparent business practices for o= ur clientele. We=92d each been involved in various online merchant initiati= ves previously and knew the traps some online businesses fall into.

------=_NextPart_000_0007_01CAD4FD.88329070-- --===============0551485076==-- From seethedc933@truegrooves.com Mon Apr 5 13:28:29 2010 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 7A21128C11D; Mon, 5 Apr 2010 13:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.842 X-Spam-Level: *** X-Spam-Status: No, score=3.842 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_REPLICA_ROLEX=3.157, GB_ROLEX=5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, 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 kfmGJ8ij2nAC; Mon, 5 Apr 2010 13:28:28 -0700 (PDT) Received: from 200141084238.user.veloxzone.com.br (200141084238.user.veloxzone.com.br [200.141.84.238]) by core3.amsl.com (Postfix) with ESMTP id BC02528C1C3; Mon, 5 Apr 2010 13:21:37 -0700 (PDT) Received: from 200.141.84.238 by truegrooves.com; Mon, 5 Apr 2010 17:21:11 -0300 Message-ID: <000d01cad4fd$88329070$6400a8c0@seethedc933> From: dnsext-archive@lists.ietf.org To: Subject: Class and elegance Date: Mon, 5 Apr 2010 17:21:11 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD4FD.88329070" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2800.1807 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD4FD.88329070 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Swiss Replica & Co. is offering all Rolex Watches Replica and also the Brei= tling Replica Watches.Our approach is to match the practices of the origina= l watchmaker to the closest degree of replica rolex and breitling, ensuring= the end result is virtually indistinguishable. Designer replica watches ar= e a craft that we take seriously and take pride in. Quality is essential bo= th for Rolex and Breitling.Replica watches are the best solution if you can= not afford to purchase so expensive original Rolex and Breitling watches.Ou= r online shop can offer you wonderful replica watches collections.Visit UsP= rice: $229Price: $244Price: $249Price: $399Price: $229Price: $244Price: $24= 9Price: $389Swiss Replica & Co. is about honesty and integrity; a straightf= orward approach to replica watch sales. As a partnership in this business w= e made it our very first priority to establish fair, transparent business p= ractices for our clientele. We=92d each been involved in various online mer= chant initiatives previously and knew the traps some online businesses fall= into=2E ------=_NextPart_000_0007_01CAD4FD.88329070 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <= td>
=

Swiss Replica & = Co. is offering all Rolex Watches Replica and also the Breitling Replica Wa= tches.

Our approach is to match the practices of the origin= al watchmaker to the closest degree of replica rolex and breitling, ensurin= g the end result is virtually indistinguishable. Designer replica watches a= re a craft that we take seriously and take pride in. Quality is essential b= oth for Rolex and Breitling.

Replica watches are the best so= lution if you cannot afford to purchase so expensive original Rolex and Bre= itling watches.

Our online shop can offer you wonderful re= plica watches collections.

Visit Us

3D""<= /a>

Price: $249

3D""

Price: $229

3D""

Price: $244

3D""

Price: $399

3D""<= /a>

Price: $229

3D""

Price: $244

3D""<= /a>

Price: $249

3D""

Price: $389

Sw= iss Replica & Co. is about honesty and integrity; a straightforward approac= h to replica watch sales. As a partnership in this business we made it our = very first priority to establish fair, transparent business practices for o= ur clientele. We=92d each been involved in various online merchant initiati= ves previously and knew the traps some online businesses fall into.

------=_NextPart_000_0007_01CAD4FD.88329070-- From owner-namedroppers@ops.ietf.org Mon Apr 5 13:44:34 2010 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 BC8DE3A6A07; Mon, 5 Apr 2010 13:44:34 -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 8QJziOJ3+Bi0; Mon, 5 Apr 2010 13:44:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A87633A68AD; Mon, 5 Apr 2010 13:44:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nyt2S-0002XS-Hx for namedroppers-data0@psg.com; Mon, 05 Apr 2010 20:36:52 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nyt2P-0002X0-MQ for namedroppers@ops.ietf.org; Mon, 05 Apr 2010 20:36:50 +0000 Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o35Kam3Q074321 for ; Mon, 5 Apr 2010 16:36:48 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4BBA49DF.2080608@ogud.com> Date: Mon, 05 Apr 2010 16:36:47 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: namedroppers Subject: [dnsext] ECC-Gost DNSKEY and DS values assigned Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 want to point out to implementors that IANA has assigned the values requested in dnssec-gost document. For DNSKEY ECC-GOST == 11 http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml for DS GOST R 34.11-94 == 3 http://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml I expect the RFC to show up in before the end of May. Olafur From dlcxmedia-feature-tags@ietf.org Mon Apr 5 14:00:20 2010 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 98EFF3A6A81 for ; Mon, 5 Apr 2010 14:00:20 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 5 Apr 2010 14:00:14 -0700 (PDT) Received: from acusis.com (unknown [200.29.110.228]) by core3.amsl.com (Postfix) with SMTP id 8EB1328C14B for ; Mon, 5 Apr 2010 14:00:07 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100405210010.8EB1328C14B@core3.amsl.com> Date: Mon, 5 Apr 2010 14:00:07 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 99767 Inc. All rights reserved.

From dmin@ietf.org Mon Apr 5 21:16:58 2010 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 87DBC28C16B for ; Mon, 5 Apr 2010 21:16:51 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 5 Apr 2010 21:16:36 -0700 (PDT) Received: from adminsoftware.net (unknown [124.123.176.124]) by core3.amsl.com (Postfix) with SMTP id 54C3B28C0FD for ; Mon, 5 Apr 2010 21:15:22 -0700 (PDT) From: Approved VIAGRA® Store Subject: Your Future Order with 79% off retail To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100406041525.54C3B28C0FD@core3.amsl.com> Date: Mon, 5 Apr 2010 21:15:22 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 45672 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Tue Apr 6 07:01:33 2010 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 2AA473A685D; Tue, 6 Apr 2010 07:01:33 -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 YWKfbfR1+Cqj; Tue, 6 Apr 2010 07:01:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 05F0E3A6808; Tue, 6 Apr 2010 07:01:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nz9F0-0004pk-6f for namedroppers-data0@psg.com; Tue, 06 Apr 2010 13:54:54 +0000 Received: from [131.111.8.137] (helo=ppsw-7.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nz9Ew-0004p7-IY for namedroppers@ops.ietf.org; Tue, 06 Apr 2010 13:54:50 +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-2.csi.cam.ac.uk ([131.111.8.54]:36161) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:cet1) id 1Nz9Eu-0002fI-OH (Exim 4.70) (return-path ); Tue, 06 Apr 2010 14:54:48 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1Nz9Eu-0007p0-GV (Exim 4.67) (return-path ); Tue, 06 Apr 2010 14:54:48 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.2); 06 Apr 2010 14:54:48 +0100 Date: 06 Apr 2010 14:54:48 +0100 From: Chris Thompson To: Olafur Gudmundsson Cc: namedroppers , scottr.nist@gmail.com Reply-To: cet1@cam.ac.uk Subject: Re: [dnsext] ECC-Gost DNSKEY and DS values assigned Message-ID: In-Reply-To: <4BBA49DF.2080608@ogud.com> References: <4BBA49DF.2080608@ogud.com> 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: On Apr 5 2010, Olafur Gudmundsson wrote: > >I want to point out to implementors that IANA has assigned the >values requested in dnssec-gost document. > >For DNSKEY >ECC-GOST == 11 > >http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml I note that this is incompatible with https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-fixes/ which wants 11 to be "Reserved until 2020". -- 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 Tue Apr 6 08:03:29 2010 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 114133A6838; Tue, 6 Apr 2010 08:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.367 X-Spam-Level: * X-Spam-Status: No, score=1.367 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, 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 IGCCgFdhvFID; Tue, 6 Apr 2010 08:03:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF2623A680E; Tue, 6 Apr 2010 08:03:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzAF4-000Eeh-Mj for namedroppers-data0@psg.com; Tue, 06 Apr 2010 14:59:02 +0000 Received: from [129.6.18.96] (helo=WSXGHUB1.xchange.nist.gov) by psg.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzAF1-000EdH-Mo for namedroppers@ops.ietf.org; Tue, 06 Apr 2010 14:58:59 +0000 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 6 Apr 2010 10:58:57 -0400 From: "Rose, Scott W." To: "cet1@cam.ac.uk" , namedroppers Date: Tue, 6 Apr 2010 10:58:57 -0400 Subject: Re: [dnsext] ECC-Gost DNSKEY and DS values assigned Thread-Topic: [dnsext] ECC-Gost DNSKEY and DS values assigned Thread-Index: AcrVkkT5tp2oFvsUQcO06kaAi61SlwAB2moy Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7E0C471C3AFscottrosenistgov_" 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: --_000_C7E0C471C3AFscottrosenistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Obviously draft-registry-fixes will need to change with the updated IANA as= signed values. Scott On 4/6/10 9:54 AM, "Chris Thompson" wrote: On Apr 5 2010, Olafur Gudmundsson wrote: > >I want to point out to implementors that IANA has assigned the >values requested in dnssec-gost document. > >For DNSKEY >ECC-GOST =3D=3D 11 > >http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xh= tml I note that this is incompatible with https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-fixes/ which wants 11 to be "Reserved until 2020". -- 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. =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 --_000_C7E0C471C3AFscottrosenistgov_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dnsext] ECC-Gost DNSKEY  and DS values assigned Obviously draft-registry-fixes will need to change with the updated I= ANA assigned values.

Scott


On 4/6/10 9:54 AM, "Chris Thompson" <cet1@cam.ac.uk> wrote:

On Apr 5 2010, Olafur Gudmundsson wrote:
>
>I want to point out to implementors that IANA has assigned the
>values requested in dnssec-gost document.
>
>For DNSKEY
>ECC-GOST =3D=3D 11
>
>http://www.iana.org/assignments/dns-sec-alg-numbers/dns-= sec-alg-numbers.xhtml

I note that this is incompatible with

https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-regist= ry-fixes/

which wants 11 to be "Reserved until 2020".

--
Chris Thompson           =     University of Cambridge Computing Service,
Email: cet1@ucs.cam.ac.uk   &n= bsp;New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.<= BR>

=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

 --_000_C7E0C471C3AFscottrosenistgov_-- From srveronica@eircom.net Tue Apr 6 08:22:39 2010 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 EABDC3A692D for ; Tue, 6 Apr 2010 08:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.235 X-Spam-Level: * X-Spam-Status: No, score=1.235 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2=1.234, BAYES_50=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 gaEK3wx47brq for ; Tue, 6 Apr 2010 08:22:37 -0700 (PDT) Received: from mail28.svc.cra.dublin.eircom.net (mail28.svc.cra.dublin.eircom.net [159.134.118.224]) by core3.amsl.com (Postfix) with SMTP id 10CC23A6845 for ; Tue, 6 Apr 2010 08:22:31 -0700 (PDT) Received: (qmail 8454 messnum 3704086 invoked from network[86.43.60.104/webmail04.webmail.cra.eircom.net]); 6 Apr 2010 15:22:27 -0000 Received: from webmail04.webmail.cra.eircom.net (HELO webmailclassic.eircom.net) (86.43.60.104) by mail28.svc.cra.dublin.eircom.net (qp 8454) with SMTP; 6 Apr 2010 15:22:27 -0000 From: "Jerry Ntai" Reply-To: To: jerryntai@yahoo.com.hk Subject: Re: Compliment of the day Date: Tue, 6 Apr 2010 16:22:27 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Originating-IP: 41.184.2.71 X-Mailer: Eircom Net CRC Webmail (http://www.eircom.net/) Organization: Eircom Net (http://www.eircom.net/) Message-Id: <20100406152232.10CC23A6845@core3.amsl.com> I am Mr Jerry Ntai, Head of Operation Mevas bank here in Hong Kong. I have a business proposal in the tune of $21.5million for you to handle with me from my bank. Are you interested? ----------------------------------------------------------------- Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts From owner-namedroppers@ops.ietf.org Tue Apr 6 11:42:45 2010 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 184583A69C2; Tue, 6 Apr 2010 11:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 WKExS+XOEMX3; Tue, 6 Apr 2010 11:42:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 87ACA3A69D4; Tue, 6 Apr 2010 11:41:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzDbC-000Eaj-Sj for namedroppers-data0@psg.com; Tue, 06 Apr 2010 18:34:06 +0000 Received: from [74.125.149.211] (helo=na3sys009aog114.obsmtp.com) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzDbA-000EaC-Bz for namedroppers@ops.ietf.org; Tue, 06 Apr 2010 18:34:04 +0000 Received: from source ([209.85.223.198]) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKS7t+m5Z6oxxR4Nh3f5kGbmyKEFMVgY65@postini.com; Tue, 06 Apr 2010 11:34:04 PDT Received: by mail-iw0-f198.google.com with SMTP id 36so190300iwn.29 for ; Tue, 06 Apr 2010 11:34:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.154.147 with HTTP; Tue, 6 Apr 2010 11:34:02 -0700 (PDT) In-Reply-To: References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> <28432.1270141110@nsa.vix.com> Date: Tue, 6 Apr 2010 11:34:02 -0700 Received: by 10.231.158.202 with SMTP id g10mr3515570ibx.43.1270578842855; Tue, 06 Apr 2010 11:34:02 -0700 (PDT) Message-ID: Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries From: David Ulevitch To: Edward Lewis 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: On Thu, Apr 1, 2010 at 12:59 PM, Edward Lewis wrote: > At 16:58 +0000 4/1/10, Paul Vixie wrote: > >> before i elaborate, can ed lewis talk about complexity and q-tuples again >> plz. > > From what I've read (which includes unpublished rewrites of the -00), I > don't think it does present an architectural fragmentation. Okay Paul -- back to my original question. What is your objection to providing optional hints via edns0 options between recursive and authoritative servers that improve the DNS answers a querying resolver is asking? Is it philosophical about different answers to different people or something more fundamental about the this proposed implementation? Thanks, David From owner-namedroppers@ops.ietf.org Tue Apr 6 13:01:24 2010 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 3FAAA28C0EF; Tue, 6 Apr 2010 13:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 hbtuDewu48Pr; Tue, 6 Apr 2010 13:01:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AFE7C28C0DD; Tue, 6 Apr 2010 13:01:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzEs0-000N1p-U4 for namedroppers-data0@psg.com; Tue, 06 Apr 2010 19:55:32 +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.71 (FreeBSD)) (envelope-from ) id 1NzErw-000N0h-Pt for namedroppers@ops.ietf.org; Tue, 06 Apr 2010 19:55:28 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 2ECE4A1084 for ; Tue, 6 Apr 2010 19:55:28 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries In-Reply-To: Your message of "Tue, 06 Apr 2010 11:34:02 MST." References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> <28432.1270141110@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 06 Apr 2010 19:55:28 +0000 Message-ID: <42864.1270583728@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: Tue, 6 Apr 2010 11:34:02 -0700 > From: David Ulevitch > > Okay Paul -- back to my original question. What is your objection to > providing optional hints via edns0 options between recursive and > authoritative servers that improve the DNS answers a querying resolver is > asking? Is it philosophical about different answers to different people > or something more fundamental about the this proposed implementation? i think i need to write a longer article about this, with drawings. but briefly, i have five areas of serious heartburn. first, this proposal inures to a hub/spoke topological model, where edges might be NAT'd and that as a query gets closer to the core it's less likely that a forwarding agent (could be DNS-layer or IP-layer) would need to rewrite this option's payload because it's more likely that the payload would exist in the same addressing realm as the responder. since i know that other topological models are now in use, and since i hope that IPv6 will encourage exploration of even more alternative models, i'm reluctant to pour any concrete around the model this proposal presumes upon. second, this proposal opens a new information pathway, which will often be enabled by default, thus newly leaking a lot of information that end users might wish hidden if they know about it but often won't know. defaults are not always privacy-friendly and sometimes overrides aren't available or aren't apparent. this reminds me of web cookies in that the implications on privacy won't be in the public's awareness and so the "analytics" people will have a wealth of new information to play with, some of which will be used commercially or even hostilely against unsuspecting end users. third, this proposal assumes that triangulation is a predictor of either performance or reachability or locality. if somebody proxies their DNS in one direction and proxies their HTTP in another direction, or if distance A-C is completely unrelated to distances A-B and B-C due to wormholes, then locality logic will either add no value or actually subtract value. this kind of differential proxying and these kinds of wormholes are already quite common and there's no reason to expect a reduction here, not even based on theoretical advantages offered indirectly by the proposal we're discussing. fourth, this proposal assumes that all applications want locality expressed in terms of IP addresses, and does not generalize it to include language preference or geolocation or political boundary information. if we're going to add locality or identity information to DNS queries then we should find out what the W3C people think, and other non-web applications people think, since when locality was added to HTTP it was expressed as a longer vector than just "client's IP address". we should do this right if we're going to do it at all. fifth, this proposal will raise the bar for all service providers even if it adds very little value (or is an aggregate value subtract for the reasons given above and possibly other reasons i haven't thought of yet.) thus, all authority and recursive providers/implementors/operators will have some competitive pressure to support this proposal or else face loss of relevance or loss of revenue. thus the complexity added won't be optional in any practical sense. debugging all this, and debugging the resulting system after it has this feature inside it, will be a new and permanent and global "operations tax" on the I.T. industry. note that i'm not listing the concern you said you expected, having to do with the stability and coherency of answers. that's not because i've stopped having that concern, but because i've already expressed it elsewhere: "What DNS Is Not" (ACM Queue, 05-November-2009, Paul Vixie, ISC) http://queue.acm.org/detail.cfm?id=1647302 rest assured that if the give concerns i've given here are somehow answered or ignored, then my previous objection, stated in the ACM Queue article referenced above, would remain very much "on the table" as far as i'm concerned. (i apologize for the high density here. i will try to write this up in a longer gentler way, for ACM Queue or Circle ID or similar, when i next come up for air.) From owner-namedroppers@ops.ietf.org Tue Apr 6 13:41:42 2010 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 4D0B428C0D6; Tue, 6 Apr 2010 13:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 F0ZBg3PNDDqM; Tue, 6 Apr 2010 13:41:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 161CF28C10A; Tue, 6 Apr 2010 13:39:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzFUJ-0001JS-F7 for namedroppers-data0@psg.com; Tue, 06 Apr 2010 20:35:07 +0000 Received: from [74.125.149.201] (helo=na3sys009aog109.obsmtp.com) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzFUG-0001JB-N8 for namedroppers@ops.ietf.org; Tue, 06 Apr 2010 20:35:04 +0000 Received: from source ([209.85.222.188]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKS7ua9zauNP2qv5Ulk3CSg14oAVW/ZrDN@postini.com; Tue, 06 Apr 2010 13:35:04 PDT Received: by mail-pz0-f188.google.com with SMTP id 26so326345pzk.6 for ; Tue, 06 Apr 2010 13:35:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.154.147 with HTTP; Tue, 6 Apr 2010 13:35:03 -0700 (PDT) In-Reply-To: <42864.1270583728@nsa.vix.com> References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> Date: Tue, 6 Apr 2010 13:35:03 -0700 Received: by 10.143.86.3 with SMTP id o3mr3034503wfl.182.1270586103220; Tue, 06 Apr 2010 13:35:03 -0700 (PDT) Message-ID: Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries From: David Ulevitch To: Paul Vixie Cc: 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 Tue, Apr 6, 2010 at 12:55 PM, Paul Vixie wrote: > briefly, i have five areas of serious heartburn. Thanks for the response. All good questions, but I don't think they are valid concerns. I don't understand the first, so I snipped it. > > second, this proposal opens a new information pathway, which will often b= e > enabled by default, thus newly leaking a lot of information that end user= s > might wish hidden if they know about it but often won't know. =A0defaults= are > not always privacy-friendly and sometimes overrides aren't available or > aren't apparent. =A0this reminds me of web cookies in that the implicatio= ns on > privacy won't be in the public's awareness and so the "analytics" people > will have a wealth of new information to play with, some of which will be > used commercially or even hostilely against unsuspecting end users. Speaking personally -- while I would enable this by default, and let people turn it off if they want -- our implementation would only enable this information pathway on a zone by zone basis. We don't want to trust unknown authoritative servers from filling our caches either. > third, this proposal assumes that triangulation is a predictor of either > performance or reachability or locality. =A0if somebody proxies their DNS= in > one direction and proxies their HTTP in another direction, or if distance > A-C is completely unrelated to distances A-B and B-C due to wormholes, th= en > locality logic will either add no value or actually subtract value. =A0th= is > kind of differential proxying and these kinds of wormholes are already qu= ite > common and there's no reason to expect a reduction here, not even based o= n > theoretical advantages offered indirectly by the proposal we're discussin= g. Again, when coordinating with a known authoritative for a specific zone, this point is moot. They know the right answer to give, and there are multi-billion dollar companies that are good at this. Akamai comes to mind as one of them. > fourth, this proposal assumes that all applications want locality express= ed > in terms of IP addresses, and does not generalize it to include language > preference or geolocation or political boundary information. =A0if we're = going > to add locality or identity information to DNS queries then we should fin= d > out what the W3C people think, and other non-web applications people thin= k, > since when locality was added to HTTP it was expressed as a longer vector > than just "client's IP address". =A0we should do this right if we're goin= g to > do it at all. This is orthogonal. edns-client-ip is intended to help deliver answers based on topographic proximity, not language or similar. And it does that based on the answers given by the owner of the zone being resolved. Who better to deliver that answer than the content owner? I can think of no one. > > fifth, this proposal will raise the bar for all service providers even if= it > adds very little value (or is an aggregate value subtract for the reasons > given above and possibly other reasons i haven't thought of yet.) =A0thus= , all > authority and recursive providers/implementors/operators will have some > competitive pressure to support this proposal or else face loss of releva= nce > or loss of revenue. =A0thus the complexity added won't be optional in any > practical sense. =A0debugging all this, and debugging the resulting syste= m > after it has this feature inside it, will be a new and permanent and glob= al > "operations tax" on the I.T. industry. The fortunate thing here is that nobody is required to implement it. There is no tax being created. And nobody is required to support it unless they will derive benefits from it. Major content providers will derive benefits. Major DNS resolution services and ISPs will derive benefits. Debugging is also no harder than it is today (and perhaps is easier!). Today, when you resolve www.google.com, www.yahoo.com and www.amazon.com you get different answers depending on where you are and on what network you sit. This will remain the case with edns-client-ip. Any operations tax has already been in place for years and has already been fully realized. :-) -David > > note that i'm not listing the concern you said you expected, having to do > with the stability and coherency of answers. =A0that's not because i've s= topped > having that concern, but because i've already expressed it elsewhere: > > =A0 =A0 =A0 =A0"What DNS Is Not" (ACM Queue, 05-November-2009, Paul Vixie= , ISC) > =A0 =A0 =A0 =A0http://queue.acm.org/detail.cfm?id=3D1647302 > > rest assured that if the give concerns i've given here are somehow answer= ed > or ignored, then my previous objection, stated in the ACM Queue article > referenced above, would remain very much "on the table" as far as i'm > concerned. > > (i apologize for the high density here. =A0i will try to write this up in= a > longer gentler way, for ACM Queue or Circle ID or similar, when i next co= me > up for air.) > > From owner-namedroppers@ops.ietf.org Wed Apr 7 06:36:45 2010 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 4DDA43A6924; Wed, 7 Apr 2010 06:36:45 -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 OHR81BKfhHl5; Wed, 7 Apr 2010 06:36:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 95AAF3A690A; Wed, 7 Apr 2010 06:36:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzVKG-000IgS-4r for namedroppers-data0@psg.com; Wed, 07 Apr 2010 13:29:48 +0000 Received: from [131.111.8.136] (helo=ppsw-6.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzVKD-000Ig5-Ci for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 13:29: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-2.csi.cam.ac.uk ([131.111.8.54]:41996) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:cet1) id 1NzVKB-0001yI-Kr (Exim 4.70) (return-path ); Wed, 07 Apr 2010 14:29:43 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1NzVKB-0002id-Eh (Exim 4.67) (return-path ); Wed, 07 Apr 2010 14:29:43 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.2); 07 Apr 2010 14:29:42 +0100 Date: 07 Apr 2010 14:29:42 +0100 From: Chris Thompson To: "Rose, Scott W." Cc: namedroppers Reply-To: cet1@cam.ac.uk Subject: Re: [dnsext] ECC-Gost DNSKEY and DS values assigned Message-ID: In-Reply-To: References: 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: On Apr 6 2010, Rose, Scott W. wrote: >Obviously draft-registry-fixes will need to change with the updated >IANA assigned values. Yes, but wasn't the idea of marking 9 & 11 as reserved that they had been used surreptitiously for NSEC3-ised versions of RSASHA256 and RSASHA512 (before the NSEC3-support-is-implied-anyway decision was taken)? If that's actually thought to be a non-issue after all, then reserving 9 doesn't make sense either. I think the real point I was trying to make is that apparently the IANA weren't being kept informed of the thinking behind (or maybe even the existence of) the registry-fixes draft. -- 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 Apr 7 08:19:40 2010 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 3E1F528C126; Wed, 7 Apr 2010 08:19:40 -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 w8GhfKvyZ1J5; Wed, 7 Apr 2010 08:19:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5DEA728C12E; Wed, 7 Apr 2010 08:17:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzWw9-0003ft-PN for namedroppers-data0@psg.com; Wed, 07 Apr 2010 15:13:01 +0000 Received: from [209.85.212.52] (helo=mail-vw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzWw6-0003Uc-Ai for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 15:12:58 +0000 Received: by vws12 with SMTP id 12so390994vws.11 for ; Wed, 07 Apr 2010 08:12:57 -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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VQBiy5JVXXbIDyTLEOf9IjPxNHAtMR2UxDLMVdAnbwo=; b=niCy6bDte6XpqToQs0jMpLV/rM74Vm3TJS9DFuMSBzbCNDpfC042TeQ+KNRbv/Zh8g o2purlf9IbPINSgsT+aUlo/PAP1wC5n4WZ/MJ5A5eMOVhTekzMCfKvEypU87/nl0Dsl+ 3ZhuokE8lnNGPvzyn47VxofrJEwKf05yDs1zU= 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 :cc:content-type:content-transfer-encoding; b=GB6uPadMbfEkCCJ73q0rx/CJHSdmgo8leYYrns1kNU+mpptgxtMBx6K0dqTagIHQTR eWY0x1u2F9kD0Ur2sRrohBlQyAWWk9bl9l4tuYoj240rBsRBC4QBY5NOrVMB9Ziv4yAM M2dHbldQgJ9JMncCGb2HITxTg5cOchVQ6HWvA= MIME-Version: 1.0 Received: by 10.220.67.73 with HTTP; Wed, 7 Apr 2010 08:12:57 -0700 (PDT) In-Reply-To: References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> Date: Wed, 7 Apr 2010 08:12:57 -0700 Received: by 10.220.121.229 with SMTP id i37mr4392109vcr.237.1270653177480; Wed, 07 Apr 2010 08:12:57 -0700 (PDT) Message-ID: Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries From: Ted Hardie To: David Ulevitch Cc: Paul Vixie , 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: Hi David, First, while we're back on this topic, would you address the issue Michael Graff pointed out at the top of this thread? Some further discussion in-line. On Tue, Apr 6, 2010 at 1:35 PM, David Ulevitch wrote: > On Tue, Apr 6, 2010 at 12:55 PM, Paul Vixie wrote: > >> briefly, i have five areas of serious heartburn. > > Thanks for the response. =A0All good questions, but I don't think they > are valid concerns. =A0I don't understand the first, so I snipped it. > That's a fairly hilarious response to a concern, but I am easily amused. >> >> second, this proposal opens a new information pathway, which will often = be >> enabled by default, thus newly leaking a lot of information that end use= rs >> might wish hidden if they know about it but often won't know. =A0default= s are >> not always privacy-friendly and sometimes overrides aren't available or >> aren't apparent. =A0this reminds me of web cookies in that the implicati= ons on >> privacy won't be in the public's awareness and so the "analytics" people >> will have a wealth of new information to play with, some of which will b= e >> used commercially or even hostilely against unsuspecting end users. > > Speaking personally -- while I would enable this by default, and let > people turn it off if they want -- our implementation would only > enable this information pathway on a zone by zone basis. =A0We don't > want to trust unknown authoritative servers from filling our caches > either. > How does this address the concern about the user's information leaking? This appears to address the provider's concern about doing this without recompense instead. >> third, this proposal assumes that triangulation is a predictor of either >> performance or reachability or locality. =A0if somebody proxies their DN= S in >> one direction and proxies their HTTP in another direction, or if distanc= e >> A-C is completely unrelated to distances A-B and B-C due to wormholes, t= hen >> locality logic will either add no value or actually subtract value. =A0t= his >> kind of differential proxying and these kinds of wormholes are already q= uite >> common and there's no reason to expect a reduction here, not even based = on >> theoretical advantages offered indirectly by the proposal we're discussi= ng. > > Again, when coordinating with a known authoritative for a specific > zone, this point is moot. =A0They know the right answer to give, and > there are multi-billion dollar companies that are good at this. > Akamai comes to mind as one of them. > Again, this doesn't seem particularly responsive to Paul's point about the topology. If proxy my DNS in one direction (e.g. my office servers, in order to take advantage of split dns) but HTTP in a different direction (through a socks tunnel at a public WiFi), the locality logic here will not work and may be worse than the unoptimized version. When the actual application connection comes in, they may realize it is unoptimized and react (if the app-layer protocol supports it), but they do not know the right answer to give in this case. You may argue it is rare, of course, but this is a fairly clear case where the topology does not match. As a further aside, you seem to focus a good bit on coordinating with "known authoritative for a specific zone", but the draft is written with a default that seems more likely to turn it on unless the user has inserted the appropriate bits to turn it off. If you actually expect this to be tur= ned on only when there is an out-of-band agreement, explaining why this should be a standard with that configuration would help. regards, Ted Hardie From owner-namedroppers@ops.ietf.org Wed Apr 7 08:26:02 2010 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 0B11A28C13F; Wed, 7 Apr 2010 08:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 0LrLQ+Wcp8Lh; Wed, 7 Apr 2010 08:26:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B0D1C3A6AD2; Wed, 7 Apr 2010 08:22:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzX2R-0004Oa-Ne for namedroppers-data0@psg.com; Wed, 07 Apr 2010 15:19:31 +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.71 (FreeBSD)) (envelope-from ) id 1NzX2P-0004Nw-B8 for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 15:19:29 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 890D9A1206; Wed, 7 Apr 2010 15:19:27 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Ted Hardie cc: David Ulevitch , namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries In-Reply-To: Your message of "Wed, 07 Apr 2010 08:12:57 MST." References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 07 Apr 2010 15:19:27 +0000 Message-ID: <89801.1270653567@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: Wed, 7 Apr 2010 08:12:57 -0700 > From: Ted Hardie > ... > That's a fairly hilarious response to a concern, but I am easily amused. ted, i found david's reply to be completely nonresponsive. if i've spent 20 years considering the points of view i expressed, then i'd like david (or anyone else responding to me) to spend at least 20 minutes considering their own position in light of what i said. i guess it's time to rename my personal blog "hey you kids get offa my lawn" or similar. however, the fault is mine, i compressed way too much information into a single page of text. i owe, as i said in my postscript, a longer treatment. --paul From owner-namedroppers@ops.ietf.org Wed Apr 7 08:39:17 2010 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 713B23A6918; Wed, 7 Apr 2010 08:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[AWL=-0.961, 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 0TroftFTL2cw; Wed, 7 Apr 2010 08:39:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 67CBF3A685D; Wed, 7 Apr 2010 08:39:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzXHM-0006bl-FY for namedroppers-data0@psg.com; Wed, 07 Apr 2010 15:34:56 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzXHJ-0006ZW-7I for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 15:34: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 13C201ECB4E8; Wed, 7 Apr 2010 15:34:51 +0000 (UTC) Date: Wed, 7 Apr 2010 11:34:49 -0400 From: Andrew Sullivan To: Chris Thompson Cc: "Rose, Scott W." , namedroppers Subject: Re: [dnsext] ECC-Gost DNSKEY and DS values assigned Message-ID: <20100407153449.GR485@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 Wed, Apr 07, 2010 at 02:29:42PM +0100, Chris Thompson wrote: > Yes, but wasn't the idea of marking 9 & 11 as reserved that they had > been used surreptitiously for NSEC3-ised versions of RSASHA256 and > RSASHA512 (before the NSEC3-support-is-implied-anyway decision was > taken)? If that's actually thought to be a non-issue after all, then > reserving 9 doesn't make sense either. Yes, that's right. > I think the real point I was trying to make is that apparently the IANA > weren't being kept informed of the thinking behind (or maybe even the > existence of) the registry-fixes draft. No, unfortunately they were, but they seem not to have caught this. Neither did your Chairs, unfortunately. I'm not sure what we're going to be able to do about it. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Apr 7 08:53:40 2010 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 C037A3A6ACA; Wed, 7 Apr 2010 08:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.515 X-Spam-Level: X-Spam-Status: No, score=-0.515 tagged_above=-999 required=5 tests=[AWL=-0.915, 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 eijWHNTzpWIL; Wed, 7 Apr 2010 08:53:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 743D23A6AD3; Wed, 7 Apr 2010 08:53:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzXUt-0008dq-NH for namedroppers-data0@psg.com; Wed, 07 Apr 2010 15:48:55 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzXUr-0008dR-4B for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 15:48: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 DC39A1ECB4E8 for ; Wed, 7 Apr 2010 15:48:51 +0000 (UTC) Date: Wed, 7 Apr 2010 11:48:50 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries Message-ID: <20100407154850.GS485@shinkuro.com> References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> <89801.1270653567@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89801.1270653567@nsa.vix.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: No hat. On Wed, Apr 07, 2010 at 03:19:27PM +0000, Paul Vixie wrote: > however, the fault is mine, i compressed way too much information into a > single page of text. i owe, as i said in my postscript, a longer treatment. With this, I disagree strongly. Information density is good. At least one of your concerns is a significant objection that needs treatment in a Security Considerations section of a draft. At least another one, and by my reading two, amounts to an objection that the proposal contains architectural assumptions about the relationships amongs query originators, intermediate resolvers, and authority servers. In my view, those objections have to be answered in their own terms, or else we need an argument why the terms are wrong. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Apr 7 09:02:55 2010 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 C72E628B797; Wed, 7 Apr 2010 09:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.459 X-Spam-Level: X-Spam-Status: No, score=-1.459 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 0C-F8Vwp5BAj; Wed, 7 Apr 2010 09:02:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8FF793A6AEF; Wed, 7 Apr 2010 09:02:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzXed-000ACe-1Q for namedroppers-data0@psg.com; Wed, 07 Apr 2010 15:58:59 +0000 Received: from [74.125.149.67] (helo=na3sys009aog101.obsmtp.com) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzXea-000ACK-8k for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 15:58:56 +0000 Received: from source ([74.125.83.178]) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKS7yrv9CzFoaMwU2NzywjF8xc9brqSQEZ@postini.com; Wed, 07 Apr 2010 08:58:56 PDT Received: by mail-pv0-f178.google.com with SMTP id 4so846622pvg.37 for ; Wed, 07 Apr 2010 08:58:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.154.147 with HTTP; Wed, 7 Apr 2010 08:58:54 -0700 (PDT) In-Reply-To: References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> Date: Wed, 7 Apr 2010 08:58:54 -0700 Received: by 10.115.65.14 with SMTP id s14mr7481554wak.209.1270655934519; Wed, 07 Apr 2010 08:58:54 -0700 (PDT) Message-ID: Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries From: David Ulevitch To: Ted Hardie Cc: Paul Vixie , 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, Apr 7, 2010 at 8:12 AM, Ted Hardie wrote: > Hi David, > > First, while we're back on this topic, would you address the issue Michae= l > Graff pointed out at the top of this thread? Michael was asking about concurrent outstanding queries having an impact on DNSSEC validation overhead (and ultimately the potential to cause a denial of service I suppose). There isn't any more cause for concern here than there is with just DNSSEC. DNSSEC has a significant tax on resources for the benefits of some increased security, but edns-client-ip doesn't make that tax any better or worse. Just as a client can ask for ${random}.${random}.dnssec-enabled-zone.com 1000's of times, they can spoof a request from a number of source IPs much the same way. The problem exists with or without edns-client-ip and the mitigation methods are the same in either scenario. >> Thanks for the response. =A0All good questions, but I don't think they >> are valid concerns. =A0I don't understand the first, so I snipped it. > > That's a fairly hilarious response to a concern, but I am easily amused. I've re-read it this morning. I'm still confused but I think it's because I'm coming from a different point of view. We're not discussing a hypothetical protocol extension, we're discussing something that already exists and are trying to standardize it. If paul believes that putting a standard in place so people can know what to expect, look for, and observe equates to pouring "concrete around the model" then I disagree with his view. Not standardizing it won't make it go away. Maybe folks don't know this -- lots of edns option-code's are in use today, and like this one, they should at least be published so others can understand them if they observe them in the wild and want to respond to them. >>> second, this proposal opens a new information pathway, which will often= be >>> enabled by default, thus newly leaking a lot of information that end us= ers >>> might wish hidden if they know about it but often won't know. =A0defaul= ts are >>> not always privacy-friendly and sometimes overrides aren't available or >>> aren't apparent. =A0this reminds me of web cookies in that the implicat= ions on >>> privacy won't be in the public's awareness and so the "analytics" peopl= e >>> will have a wealth of new information to play with, some of which will = be >>> used commercially or even hostilely against unsuspecting end users. >> >> Speaking personally -- while I would enable this by default, and let >> people turn it off if they want -- our implementation would only >> enable this information pathway on a zone by zone basis. =A0We don't >> want to trust unknown authoritative servers from filling our caches >> either. >> > > How does this address the concern about the user's information leaking? > This appears to address the provider's concern about doing this without > recompense instead. There's 4 scenarios I see -- 1) A user is using a specific recursive DNS server visiting a resource where the authoritative DNS server is hosted by the resource owner. 2) A user is using a non-specific recursive DNS server visiting a resource where the authoritative DNS server is hosted by the resource owner. 3) A user is using a specific (local resolver, OpenDNS, etc.) recursive DNS server visiting a resource where the authoritative DNS server is hosted by a third party (like UltraDNS). 4) A user is using a non-specific (internet cafe, ISP, etc.) recursive DNS server visiting a resource where the authoritative DNS server is hosted by a third party (like UltraDNS). In #1 and #3 I see absolutely no issue. The user has made a choice to use a DNS service that operates in this way. In #2 there is no data leakage that isn't already being leaked to the resource owner already once a connection is made. In #4 there is data leakage. The user's source IP address, assuming it isn't RFC1918'd, will be passed to a third-party authoritative DNS service which can collect and track that data in a way they otherwise wouldn't. I'm not confident this represents data leakage of any material significance, but it's certainly worthy of discussion. Do I think it has the same utility as HTTP cookies? Not even close. Could it be used to better understand browsing habits of DNS end-users, yes I think it could. I do believe the benefits far outweigh the concerns in #4. > >>> third, this proposal assumes that triangulation is a predictor of eithe= r >>> performance or reachability or locality. =A0if somebody proxies their D= NS in >>> one direction and proxies their HTTP in another direction, or if distan= ce >>> A-C is completely unrelated to distances A-B and B-C due to wormholes, = then >>> locality logic will either add no value or actually subtract value. =A0= this >>> kind of differential proxying and these kinds of wormholes are already = quite >>> common and there's no reason to expect a reduction here, not even based= on >>> theoretical advantages offered indirectly by the proposal we're discuss= ing. >> >> Again, when coordinating with a known authoritative for a specific >> zone, this point is moot. =A0They know the right answer to give, and >> there are multi-billion dollar companies that are good at this. >> Akamai comes to mind as one of them. >> > > Again, this doesn't seem particularly responsive to Paul's point about > the topology. =A0If proxy my DNS in one direction (e.g. my office servers= , > in order to take advantage of split dns) but HTTP in a different directio= n > (through a socks tunnel at a public WiFi), the locality logic here > will not work and may be worse than the unoptimized version. =A0When > the actual application connection comes in, they may realize it is > unoptimized and react (if the app-layer protocol supports it), but they > do not know the right answer to give in this case. > > You may argue it is rare, of course, but this is a fairly clear case wher= e > the topology does not match. But edns-client-ip doesn't make this worse. The potential problem you highlight is absolutely the case today when visiting any of the Alexa top 10 (and probably the majority of the top 100) websites. edns-client-ip can only make this better, I don't see how it will make it worse. Your edge case exists with or without edns-client-ip because 20%+ of the Internet already uses the location of the resolver to hand back a response (Akamai). People who really care about this do as you describe and handle it higher up in the stack to redirect appropriately. > > As a further aside, you seem to focus a good bit on coordinating with > "known authoritative for a specific zone", but the draft is written with > a default that seems more likely to turn it on unless the user has insert= ed > the appropriate bits to turn it off. =A0If you actually expect this to be= turned > on only when there is an out-of-band agreement, explaining why > this should be a standard with that configuration would help. The motivation, in my mind, for this draft is that this stuff is already happening. At OpenDNS, we've been using edns option code's for years to signal information between clients and resolvers, forwarders and resolvers and between resolvers and authoritative servers. Now that there are more and more people trying to do things the way we've been doing them it makes sense to standardize the methods, claim the option-code's already in use, etc. So while we believe that it only makes sense to do this on a zone by zone basis, and perhaps that can be written into the draft of why someone might want to do that, it's more important to make sure we're all doing it the same way to avoid problems later on. We're happy to modify our implementations based on whatever standard is determined, but the higher-level concept of providing better resource resolution for large-scale recursive services is happening already and isn't really what is being discussed here (though it seems as though people wish it were). That train has already left the station. The question that remains is how to best accomplish it in a way that is open and can be implemented by anyone who wants to implement it. -David > > regards, > > Ted Hardie > From disportspunting@ietf.org Wed Apr 7 09:04:39 2010 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 921883A6AFA for ; Wed, 7 Apr 2010 09:04:39 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 7 Apr 2010 09:04:38 -0700 (PDT) Received: from amcore.com (unknown [190.74.225.141]) by core3.amsl.com (Postfix) with ESMTP id 3E45028C10A for ; Wed, 7 Apr 2010 09:04:05 -0700 (PDT) From: Approved VIAGRA® Store Subject: You have a new personal message To: MIME-Version: 1.0 Content-Type: text/html X-Antivirus: avast! (VPS 100407-0, 07/04/2010), Outbound message X-Antivirus-Status: Clean Message-Id: <20100407160410.3E45028C10A@core3.amsl.com> Date: Wed, 7 Apr 2010 09:04:05 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 49223 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Wed Apr 7 09:31:16 2010 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 DA0963A695A; Wed, 7 Apr 2010 09:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.518 X-Spam-Level: X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[AWL=-1.081, 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 3Qb+Ld3jTkIP; Wed, 7 Apr 2010 09:31:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B93D93A696D; Wed, 7 Apr 2010 09:31:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzY2d-000Dlc-KD for namedroppers-data0@psg.com; Wed, 07 Apr 2010 16:23:47 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzY2b-000Dkz-8W for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 16:23:45 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 3857FB70CE1; Wed, 7 Apr 2010 09:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9QjpqGRZf4d; Wed, 7 Apr 2010 09:23:42 -0700 (PDT) Received: from [10.0.1.5] (cpe-70-95-123-210.hawaii.res.rr.com [70.95.123.210]) by virtualized.org (Postfix) with ESMTP id 3EF33B70CD5; Wed, 7 Apr 2010 09:23:42 -0700 (PDT) Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Wed, 7 Apr 2010 06:23:39 -1000 Cc: "namedroppers@ops.ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> To: David Ulevitch X-Mailer: Apple Mail (2.1078) 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 Apr 7, 2010, at 5:58 AM, David Ulevitch wrote: > Maybe folks don't know this -- lots of edns > option-code's are in use today, and like this one, I (as IANA Executive Director (acting)) wasn't aware of this. How are = these unassigned option-codes used? > they should at > least be published so others can understand them if they observe them > in the wild and want to respond to them. I can see this devolving into the always popular '"don't reward = squatters" vs. "document reality"' rat hole. Regards, -drc From owner-namedroppers@ops.ietf.org Wed Apr 7 10:15:36 2010 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 B9E9C3A6868; Wed, 7 Apr 2010 10:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 67i7f9vAX9Gf; Wed, 7 Apr 2010 10:15:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CA063A6811; Wed, 7 Apr 2010 10:15:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzYlj-000JMb-6H for namedroppers-data0@psg.com; Wed, 07 Apr 2010 17:10:23 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzYlf-000JLs-Ty for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 17:10:20 +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 o37HA0aS000546; Wed, 7 Apr 2010 10:10:00 -0700 (PDT) Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <89801.1270653567@nsa.vix.com> Date: Wed, 7 Apr 2010 13:09:59 -0400 Cc: Nicholas Weaver , Ted Hardie , David Ulevitch , namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> <89801.1270653567@nsa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.1078) 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: > first, this proposal inures to a hub/spoke topological model, where = edges > might be NAT'd and that as a query gets closer to the core it's less = likely > that a forwarding agent (could be DNS-layer or IP-layer) would need to=20= > rewrite this option's payload because it's more likely that the = payload > would exist in the same addressing realm as the responder. since i = know > that other topological models are now in use, and since i hope that = IPv6 > will encourage exploration of even more alternative models, i'm = reluctant > to pour any concrete around the model this proposal presumes upon. I would argue instead that this is about the "cloud and spoke" model, = which reasonably accurately represents reality when the goal is to = identify which spoke or small group of spokes a user is at. =20 After all, if this model did not represent reality, how would Akamai be = in business? > second, this proposal opens a new information pathway, which will = often be > enabled by default, thus newly leaking a lot of information that end = users > might wish hidden if they know about it but often won't know. = defaults are > not always privacy-friendly and sometimes overrides aren't available = or > aren't apparent. this reminds me of web cookies in that the = implications on > privacy won't be in the public's awareness and so the "analytics" = people > will have a wealth of new information to play with, some of which will = be > used commercially or even hostilely against unsuspecting end users. Privacy concerns must be scaled and placed in context. "You don't worry = about mosquito bites when there are arterial bleeds". The privacy leakage from this proposal is an order of magnitude less = than existing privacy leakages through analytics, APIs, web browsers = with amazingly agressive prefetching, and a host of other issues:=20 Even moreso, the information leakage is minor, and only goes to the = authorities where the user is trying to contact!=20 If you want to contact a site, it will learn your exact IP address = anyway, and you use DNS generally to contact sites with other protocols. And if you don't want the site to know your IP address, route your DNS = through a proxy as well (you should be anyway. EG, TOR already does = that.) > third, this proposal assumes that triangulation is a predictor of = either > performance or reachability or locality. if somebody proxies their = DNS in > one direction and proxies their HTTP in another direction, or if = distance > A-C is completely unrelated to distances A-B and B-C due to wormholes, = then > locality logic will either add no value or actually subtract value. = this > kind of differential proxying and these kinds of wormholes are already = quite > common and there's no reason to expect a reduction here, not even = based on > theoretical advantages offered indirectly by the proposal we're = discussing. Again, the proof is that this actually works. For those who use their = ISP's resolvers, Akamai-type techniques provide very good performance. =20= The cases where people put their path through pervented proxying should = not be a major concern, its VERY rare, and such deliberate perverted = cases could instead relay their DNS through the same path. > fourth, this proposal assumes that all applications want locality = expressed > in terms of IP addresses, and does not generalize it to include = language > preference or geolocation or political boundary information. if we're = going > to add locality or identity information to DNS queries then we should = find > out what the W3C people think, and other non-web applications people = think, > since when locality was added to HTTP it was expressed as a longer = vector > than just "client's IP address". we should do this right if we're = going to > do it at all. No, this proposal assumes that there is a large group of significant = services which have successfully used locality expressed in terms of IP = coordinate space, that this information works well already when the = ISP's resolver is used, and that such coordinate services should still = work when users use a third party resolver. And you have to do locality at the DNS level, because DNS is the only = way you can express the locality WITHOUT adding RTTs in the process = (like you would with HTTP redirects): latency is key here. > fifth, this proposal will raise the bar for all service providers even = if it > adds very little value (or is an aggregate value subtract for the = reasons > given above and possibly other reasons i haven't thought of yet.) = thus, all > authority and recursive providers/implementors/operators will have = some > competitive pressure to support this proposal or else face loss of = relevance > or loss of revenue. thus the complexity added won't be optional in = any > practical sense. debugging all this, and debugging the resulting = system > after it has this feature inside it, will be a new and permanent and = global > "operations tax" on the I.T. industry. Except that we are in the position where third party resolvers are at a = huge competitive disadvantage because a proposal like this doesn't = exist. "Akamai sucks when you use Google DNS or OpenDNS". And if = Akamai sucks, the web sucks. The question which the detractors have not answered: Do you want a = third party resolver services (OpenDNS, Google Public DNS etc) to be on = a significantly disadvantaged footing when compared to the ISP provided = resolver services? =20 If the answer is yes, say so. "Akamai should only work well if you use = your ISP's DNS infrastructure". =20 If the answer is no, there MUST be some mechanism for the third party = resolvers to export client-IP information in some form to a group of = authority servers. From owner-namedroppers@ops.ietf.org Wed Apr 7 10:20:43 2010 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 3E98D3A6811; Wed, 7 Apr 2010 10:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 0lvCQEBVUYlM; Wed, 7 Apr 2010 10:20:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 325B63A6957; Wed, 7 Apr 2010 10:20:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzYsM-000KMd-OM for namedroppers-data0@psg.com; Wed, 07 Apr 2010 17:17:14 +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.71 (FreeBSD)) (envelope-from ) id 1NzYsK-000KMK-AW for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 17:17:12 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id EA54AA1223; Wed, 7 Apr 2010 17:17:11 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Nicholas Weaver cc: Ted Hardie , David Ulevitch , namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries In-Reply-To: Your message of "Wed, 07 Apr 2010 13:09:59 -0400." References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> <89801.1270653567@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 07 Apr 2010 17:17:11 +0000 Message-ID: <94999.1270660631@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: Nicholas Weaver > Date: Wed, 7 Apr 2010 13:09:59 -0400 > > After all, if this model did not represent reality, how would Akamai be > in business? akamai offers the great boon of requiring consciousness and discipline on the part of web publishers. to use akamai's services you have to use relative URL's for in-site navigation, and you have to know when and what you are publishing. as far as the stupid dns tricks themselves, akamai and speedera and the others are pretty much selling snake oil, but lucky thing is, nobody ever got fired for signing a purchase order for snake oil. (see: anti-virus.) From owner-namedroppers@ops.ietf.org Wed Apr 7 10:37:07 2010 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 0F07E28C116; Wed, 7 Apr 2010 10:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.371 X-Spam-Level: X-Spam-Status: No, score=-0.371 tagged_above=-999 required=5 tests=[AWL=0.124, 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 0ac0PJa0WOdT; Wed, 7 Apr 2010 10:37:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E9E628C0FE; Wed, 7 Apr 2010 10:37:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzZ7G-000M9D-FI for namedroppers-data0@psg.com; Wed, 07 Apr 2010 17:32:38 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzZ7C-000M8C-3B for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 17:32:34 +0000 Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o37HWRAB091759; Wed, 7 Apr 2010 13:32:27 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4BBCC1A9.9030903@ogud.com> Date: Wed, 07 Apr 2010 13:32:25 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: cet1@cam.ac.uk CC: "Rose, Scott W." , namedroppers Subject: Re: [dnsext] ECC-Gost DNSKEY and DS values assigned References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 Chris, I should have engaged my brain last week on vacation when IANA asked for confirmation of the allocation :-) I just had a discussion with IANA about this issue. IANA will change the allocation from 11. Once the new allocation is complete I will notify the mailing list. Sorry about the confusion Olafur On 07/04/2010 9:29 AM, Chris Thompson wrote: > On Apr 6 2010, Rose, Scott W. wrote: > >> Obviously draft-registry-fixes will need to change with the updated >> IANA assigned values. > > Yes, but wasn't the idea of marking 9 & 11 as reserved that they had > been used surreptitiously for NSEC3-ised versions of RSASHA256 and > RSASHA512 (before the NSEC3-support-is-implied-anyway decision was > taken)? If that's actually thought to be a non-issue after all, then > reserving 9 doesn't make sense either. > > I think the real point I was trying to make is that apparently the IANA > weren't being kept informed of the thinking behind (or maybe even the > existence of) the registry-fixes draft. > From owner-namedroppers@ops.ietf.org Wed Apr 7 11:05:34 2010 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 21E503A6821; Wed, 7 Apr 2010 11:05:34 -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 uUgnahctcdKA; Wed, 7 Apr 2010 11:05:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6D163A6923; Wed, 7 Apr 2010 11:05:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzZWh-000Pg2-3u for namedroppers-data0@psg.com; Wed, 07 Apr 2010 17:58:55 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzZWf-000Pfn-7h for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 17:58:53 +0000 Received: by pwi1 with SMTP id 1so1254879pwi.11 for ; Wed, 07 Apr 2010 10:58:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Wed, 7 Apr 2010 10:58:50 -0700 (PDT) Date: Wed, 7 Apr 2010 10:58:50 -0700 Received: by 10.114.49.4 with SMTP id w4mr8994775waw.88.1270663130368; Wed, 07 Apr 2010 10:58:50 -0700 (PDT) Message-ID: Subject: [dnsext] IANA considerations for DNSCurve? From: Matthew Dempsky To: IETF DNSEXT WG 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 was curious if anyone has thoughts on what (if any) IANA considerations are required for DNSCurve. In my draft, I claim no action is needed, because it doesn't request reservation of any new resource types, option codes, etc. However, after reading RFC 3490 and seeing that the "xn--" prefix was IANA assigned, perhaps it's appropriate to request IANA formally assign "54-byte case-insensitive, alphanumeric (but excluding aeio) labels starting with uz5" to DNSCurve? Also, to support alternate cryptosystems, does anyone have suggestions on how that should be constructed? E.g., one thought I have is for NIST P-256 public keys to use (say) uz6 and uz7 followed by 51-bytes of public key info. Since a P-256 key is a full 256-bit key (unlike Curve25519 which uses 255-bit public keys), the two separate prefixes are used to avoid adding an extra byte to the label. Another possibility is to just use uz6 followed by 52-bytes of public key. Slightly simpler encoding, slightly longer labels. Another possibility is to use uz6 followed by some (encoded) integer value to indicate it's a P-256 public key and then followed by the public key itself. Slightly easier IANA assignment of new codes, but even longer labels. From owner-namedroppers@ops.ietf.org Wed Apr 7 12:09:23 2010 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 1B6F43A6940; Wed, 7 Apr 2010 12:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.064 X-Spam-Level: X-Spam-Status: No, score=-5.064 tagged_above=-999 required=5 tests=[AWL=1.431, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, 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 4+d5FWoiAzpx; Wed, 7 Apr 2010 12:09:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1BEB23A67B2; Wed, 7 Apr 2010 12:09:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzaXz-0008Jz-Ia for namedroppers-data0@psg.com; Wed, 07 Apr 2010 19:04:19 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzaXw-0008Ja-Ca for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 19:04:16 +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 o37J4BHu027524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Apr 2010 12:04:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 7 Apr 2010 12:04:09 -0700 To: Matthew Dempsky , IETF DNSEXT WG From: Paul Hoffman Subject: Re: [dnsext] IANA considerations for DNSCurve? 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:58 AM -0700 4/7/10, Matthew Dempsky wrote: >However, after reading RFC 3490 and seeing that the "xn--" prefix was >IANA assigned, perhaps it's appropriate to request IANA formally >assign "54-byte case-insensitive, alphanumeric (but excluding aeio) >labels starting with uz5" to DNSCurve? Rat-hole alert. Not that what you ask for is wrong: I think it is exactly right. But it might be incredibly contentious. (Disclaimer: I'm the one who came up with the "xn--" hack.) >Also, to support alternate >cryptosystems, does anyone have suggestions on how that should be >constructed? The above rule is fine; other signature algorithms can use a different three letters. Note that you are *not* prohibiting the use of uz5<51other> for other legitimate uses. There is no issue with what the user sees, which was the case with the IDNA prefix. >E.g., one thought I have is for NIST P-256 public keys to use (say) >uz6 and uz7 followed by 51-bytes of public key info. Since a P-256 >key is a full 256-bit key (unlike Curve25519 which uses 255-bit public >keys), the two separate prefixes are used to avoid adding an extra >byte to the label. > >Another possibility is to just use uz6 followed by 52-bytes of public >key. Slightly simpler encoding, slightly longer labels. That can be determined later. >Another possibility is to use uz6 followed by some (encoded) integer >value to indicate it's a P-256 public key and then followed by the >public key itself. Slightly easier IANA assignment of new codes, but >even longer labels. Again, that can be decided later. For now, it suffices to hint to other signature algorithm designers that doing it similar to the way you have done is a good idea. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Wed Apr 7 13:51:53 2010 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 A81DB3A67FA; Wed, 7 Apr 2010 13:51:53 -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 6VU+bxTxW-t8; Wed, 7 Apr 2010 13:51:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9CA313A67B7; Wed, 7 Apr 2010 13:51:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzcAu-000K64-DU for namedroppers-data0@psg.com; Wed, 07 Apr 2010 20:48:36 +0000 Received: from [209.85.212.52] (helo=mail-vw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzcAr-000K5b-Ld for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 20:48:33 +0000 Received: by vws12 with SMTP id 12so563313vws.11 for ; Wed, 07 Apr 2010 13:48:32 -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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1CeKEtIUUknhzB6zyewsmwkJ14FMhiDBukh6ZoDsr0g=; b=Sua9sBSsH9DKevHY8xsd0wpUthecNIB8WCjppENBSrN3shleO7qDUsRQ5skPWjqIgL liQV3yO9t5ewc1V2kAryWb2892E40FE3Q8zagxBgR9Lo0Cv7J1jCLY6kYREKz4XXV8C5 oSTwuoQ8EauxfQPUC6EVxxPNy8NiJgcKL0tFo= 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 :cc:content-type:content-transfer-encoding; b=bzEXKD0XDSQVLr6Ge4bi4gCne0Rviyl14aP0bOpNdQGb9HpfoAqwhxW1ZeYsI7yuT8 Vhg+slr/UE51GqL/FeACaiiLcX4bRNn5cRKsnBl1J16v6t/7mFx4fEovdXsTCc2BGDDA MABgTAiqpKGuJZ04JcfMM9Ma8WGT/HlUFxKbg= MIME-Version: 1.0 Received: by 10.220.67.73 with HTTP; Wed, 7 Apr 2010 13:48:32 -0700 (PDT) In-Reply-To: References: <4BB3E324.2050207@isc.org> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> <89801.1270653567@nsa.vix.com> Date: Wed, 7 Apr 2010 13:48:32 -0700 Received: by 10.220.126.201 with SMTP id d9mr4814491vcs.106.1270673312686; Wed, 07 Apr 2010 13:48:32 -0700 (PDT) Message-ID: Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries From: Ted Hardie To: Nicholas Weaver Cc: Paul Vixie , David Ulevitch , 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, Apr 7, 2010 at 10:09 AM, Nicholas Weaver wrote: > Privacy concerns must be scaled and placed in context. =A0"You don't worr= y about mosquito bites when there are arterial bleeds". > Why put someone with arterial bleeding in a roomful of mosquitoes with unkn= own exposure to malaria, yellow fever or dengue? Your for the exploitation of metaphor, Ted From owner-namedroppers@ops.ietf.org Wed Apr 7 13:52:26 2010 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 7B18428C15E; Wed, 7 Apr 2010 13:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=-0.351, 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 sFgcxvbisYGq; Wed, 7 Apr 2010 13:52:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62ACC28C15A; Wed, 7 Apr 2010 13:52:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzc8w-000JqZ-9k for namedroppers-data0@psg.com; Wed, 07 Apr 2010 20:46:34 +0000 Received: from [209.85.212.52] (helo=mail-vw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzc8s-000Jq9-0a for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 20:46:30 +0000 Received: by vws12 with SMTP id 12so561876vws.11 for ; Wed, 07 Apr 2010 13:46:29 -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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LpdJd334izNOJjZ76ArcCDigHiIZcmTHYTJVgaX0ZAA=; b=DRntUhMzwzo5kCTId1Vu0O/Rn8jknE5SohQJA2E1yeSo7yQReoeoltqNp0tKETfgoQ /QbGRWMxk+G1ziwMcgZgH/vcf1YiFzjfF1U3X5CY79orqYLWtSqxg0nKdXaXJAVOctL9 IqAKjbWSGFloaGWGOPIdyRwBurtDjT3o4yLBU= 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 :cc:content-type:content-transfer-encoding; b=aK1y07YXBlF5Dfh9tY8JXjgDUGGPu079gc2pWjyYBdtscrfKYyHCVwiBQo+FV0lkhl SrOLzYFUFVkyB9Kez5zbE3CkmejnKwWYh8CSlADPn2EQj9tfIXVdBdjzVFz40Q5z0s1S WJNwBgvAL92gPcwsCjhOHqyYFRHmBZiXVgGIA= MIME-Version: 1.0 Received: by 10.220.67.73 with HTTP; Wed, 7 Apr 2010 13:46:27 -0700 (PDT) In-Reply-To: References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> Date: Wed, 7 Apr 2010 13:46:27 -0700 Received: by 10.220.108.27 with SMTP id d27mr4695840vcp.232.1270673187223; Wed, 07 Apr 2010 13:46:27 -0700 (PDT) Message-ID: Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries From: Ted Hardie To: David Ulevitch Cc: Paul Vixie , 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, Apr 7, 2010 at 8:58 AM, David Ulevitch wrote: > On Wed, Apr 7, 2010 at 8:12 AM, Ted Hardie wrote: >> Hi David, >> >> First, while we're back on this topic, would you address the issue Micha= el >> Graff pointed out at the top of this thread? > > Michael was asking about concurrent outstanding queries having an > impact on DNSSEC validation overhead (and ultimately the potential to > cause a denial of service I suppose). I think you missed part of his point. He was saying that oustanding querie= s can be merged in the current system and this may not be possible if this is in use: "BIND 9 will combine queries currently. That is, if a query for foo.com is already in progress another query from a client will cause it to merge into that same work item. " The proposal on the table changes the cachability characteristics of the response, by tying it to a specific locality in IP space. That may elimi= nate this optimization. (That's my take, anyway, but Michael should speak up as well if he's still interested in the thread) =A0There isn't any more cause for > concern here than there is with just DNSSEC. =A0DNSSEC has a significant > tax on resources for the benefits of some increased security, but > edns-client-ip doesn't make that tax any better or worse. =A0Just as a > client can ask for ${random}.${random}.dnssec-enabled-zone.com 1000's > of times, they can spoof a request from a number of source IPs much > the same way. =A0The problem exists with or without edns-client-ip and > the mitigation methods are the same in either scenario. > >>> Thanks for the response. =A0All good questions, but I don't think they >>> are valid concerns. =A0I don't understand the first, so I snipped it. >> >> That's a fairly hilarious response to a concern, but I am easily amused. > > I've re-read it this morning. =A0I'm still confused but I think it's > because I'm coming from a different point of view. =A0We're not > discussing a hypothetical protocol extension, we're discussing > something that already exists and are trying to standardize it. =A0If > paul believes that putting a standard in place so people can know what > to expect, look for, and observe equates to pouring "concrete around > the model" then I disagree with his view. =A0Not standardizing it won't > make it go away. =A0Maybe folks don't know this -- lots of edns > option-code's are in use today, and like this one, they should at > least be published so others can understand them if they observe them > in the wild and want to respond to them. > Sadly, that's not as hilarious; I hope you can work with David on getting documented what ought to be. >>>> second, this proposal opens a new information pathway, which will ofte= n be >>>> enabled by default, thus newly leaking a lot of information that end u= sers >>>> might wish hidden if they know about it but often won't know. =A0defau= lts are >>>> not always privacy-friendly and sometimes overrides aren't available o= r >>>> aren't apparent. =A0this reminds me of web cookies in that the implica= tions on >>>> privacy won't be in the public's awareness and so the "analytics" peop= le >>>> will have a wealth of new information to play with, some of which will= be >>>> used commercially or even hostilely against unsuspecting end users. >>> >>> Speaking personally -- while I would enable this by default, and let >>> people turn it off if they want -- our implementation would only >>> enable this information pathway on a zone by zone basis. =A0We don't >>> want to trust unknown authoritative servers from filling our caches >>> either. >>> >> >> How does this address the concern about the user's information leaking? >> This appears to address the provider's concern about doing this without >> recompense instead. > > There's 4 scenarios I see -- > > 1) A user is using a specific recursive DNS server visiting a resource > where the authoritative DNS server is hosted by the resource owner. > 2) A user is using a non-specific recursive DNS server visiting a > resource where the authoritative DNS server is hosted by the resource > owner. What does "non-specific" mean above? Discovered by DHCP, rather than manually configured? > 3) A user is using a specific (local resolver, OpenDNS, etc.) > recursive DNS server visiting a resource where the authoritative DNS > server is hosted by a third party (like UltraDNS). > 4) A user is using a non-specific (internet cafe, ISP, etc.) recursive > DNS server visiting a resource where the authoritative DNS server is > hosted by a third party (like UltraDNS). > > In #1 and #3 I see absolutely no issue. =A0The user has made a choice to > use a DNS service that operates in this way. But this opt-out, not opt-in, and there is no way for the user to tell that the recursive resolver is operates in this way. > In #2 there is no data leakage that isn't already being leaked to the > resource owner already once a connection is made. You have to know what the application does to know whether this leakage is new or not. An http client talking to a squid proxy does not leak prio= r to this and leaks now. > In #4 there is data leakage. =A0The user's source IP address, assuming > it isn't RFC1918'd, will be passed to a third-party authoritative DNS > service which can collect and track that data in a way they otherwise > wouldn't. =A0I'm not confident this represents data leakage of any > material significance, but it's certainly worthy of discussion. =A0Do I > think it has the same utility as HTTP cookies? =A0Not even close. =A0Coul= d > it be used to better understand browsing habits of DNS end-users, yes > I think it could. > > I do believe the benefits far outweigh the concerns in #4. > I don't think you're getting much useful data on the "browsing data of DNS end-users", which is, honestly, not a phrase I'd use. Or should I assume you mean the benefit of more money from advertisers paying for locality-targeted ads, rather than more generic ads? >> >>>> third, this proposal assumes that triangulation is a predictor of eith= er >>>> performance or reachability or locality. =A0if somebody proxies their = DNS in >>>> one direction and proxies their HTTP in another direction, or if dista= nce >>>> A-C is completely unrelated to distances A-B and B-C due to wormholes,= then >>>> locality logic will either add no value or actually subtract value. = =A0this >>>> kind of differential proxying and these kinds of wormholes are already= quite >>>> common and there's no reason to expect a reduction here, not even base= d on >>>> theoretical advantages offered indirectly by the proposal we're discus= sing. >>> >>> Again, when coordinating with a known authoritative for a specific >>> zone, this point is moot. =A0They know the right answer to give, and >>> there are multi-billion dollar companies that are good at this. >>> Akamai comes to mind as one of them. >>> >> >> Again, this doesn't seem particularly responsive to Paul's point about >> the topology. =A0If proxy my DNS in one direction (e.g. my office server= s, >> in order to take advantage of split dns) but HTTP in a different directi= on >> (through a socks tunnel at a public WiFi), the locality logic here >> will not work and may be worse than the unoptimized version. =A0When >> the actual application connection comes in, they may realize it is >> unoptimized and react (if the app-layer protocol supports it), but they >> do not know the right answer to give in this case. >> >> You may argue it is rare, of course, but this is a fairly clear case whe= re >> the topology does not match. > > But edns-client-ip doesn't make this worse. I think the point is that it doesn't provide a benefit in this case, a point on which we appear to agree. =A0The potential problem you > highlight is absolutely the case today when visiting any of the Alexa > top 10 (and probably the majority of the top 100) websites. > edns-client-ip can only make this better, I don't see how it will make > it worse. =A0Your edge case exists with or without edns-client-ip > because 20%+ of the Internet already uses the location of the resolver > to hand back a response (Akamai). =A0People who really care about this > do as you describe and handle it higher up in the stack to redirect > appropriately. > >> >> As a further aside, you seem to focus a good bit on coordinating with >> "known authoritative for a specific zone", but the draft is written with >> a default that seems more likely to turn it on unless the user has inser= ted >> the appropriate bits to turn it off. =A0If you actually expect this to b= e turned >> on only when there is an out-of-band agreement, explaining why >> this should be a standard with that configuration would help. > > The motivation, in my mind, for this draft is that this stuff is > already happening. =A0At OpenDNS, we've been using edns option code's > for years to signal information between clients and resolvers, > forwarders and resolvers and between resolvers and authoritative > servers. =A0Now that there are more and more people trying to do things > the way we've been doing them it makes sense to standardize the > methods, claim the option-code's already in use, etc. =A0So while we > believe that it only makes sense to do this on a zone by zone basis, > and perhaps that can be written into the draft of why someone might > want to do that, it's more important to make sure we're all doing it > the same way to avoid problems later on. > > We're happy to modify our implementations based on whatever standard > is determined, but the higher-level concept of providing better > resource resolution for large-scale recursive services is happening > already and isn't really what is being discussed here (though it seems > as though people wish it were). =A0That train has already left the > station. =A0The question that remains is how to best accomplish it in a > way that is open and can be implemented by anyone who wants to > implement it. > No, the question is whether there is a method that is architecturally sound, responsive to privacy concerns, and you know, actually works. That might be worth a standard. You can have a method that is "open and can be implemented by anyone" without being architecturally sound or responsive to privacy concerns witho= ut meeting the other concerns. Just might two cents, Ted Hardie > -David > > > >> >> regards, >> >> Ted Hardie >> > From owner-namedroppers@ops.ietf.org Wed Apr 7 14:48:13 2010 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 BF7F93A69C1; Wed, 7 Apr 2010 14:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.53 X-Spam-Level: X-Spam-Status: No, score=0.53 tagged_above=-999 required=5 tests=[AWL=-1.959, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_23=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 h1x+Dh6Bta1z; Wed, 7 Apr 2010 14:48:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 31F593A69A8; Wed, 7 Apr 2010 14:48:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzd2Z-000083-CK for namedroppers-data0@psg.com; Wed, 07 Apr 2010 21:44:03 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzd2U-00007g-Qu for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 21:43:58 +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 98B871ECB4E8 for ; Wed, 7 Apr 2010 21:43:57 +0000 (UTC) Date: Wed, 7 Apr 2010 17:43:56 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-kerr-ixfr-only-01 Message-ID: <20100407214355.GH1351@shinkuro.com> References: <4B87D72A.5030206@nic.cz> <4BA8D973.2000100@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4BA8D973.2000100@nic.cz> 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, This request got overlooked (by me) during the IETF meeting. Apologies to Ondřej and Shane. In any case, we have a request for adoption of draft-kerr-ixfr-only as a WG item. I've noted some interest in the draft. If at least five participants say they support adoption and commit to reviewing through WGLC, then we can agree to the request. Best regards, Andrew (as co-chair) On Tue, Mar 23, 2010 at 04:08:35PM +0100, Ondřej Surý wrote: > Hi, > > please adopt this document as a WG item. > > Thank you, > Ondrej > > On 26.2.2010 15:14, Ondřej Surý wrote: >> Hi, >> >> we have incorporated all comments on -00. Thanks to Mark, Alfred, >> Wouter, Joao, Joe and Jelte for those comments. >> >> Ondrej >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-kerr-ixfr-only-01 >> Date: Fri, 26 Feb 2010 05:37:37 -0800 (PST) >> From: IETF I-D Submission Tool >> To: ondrej.sury@nic.cz >> CC: shane@isc.org >> >> >> A new version of I-D, draft-kerr-ixfr-only-01.txt has been successfuly >> submitted by Ondrej Sury and posted to the IETF repository. >> >> Filename: draft-kerr-ixfr-only >> Revision: 01 >> Title: IXFR-ONLY to Prevent IXFR Fallback to AXFR >> Creation_date: 2010-02-26 >> WG ID: Independent Submission >> Number_of_pages: 6 >> >> Abstract: >> 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. This way, alternate peers can be contacted more quickly and >> convergence of zone content may be achieved much faster in important, >> resilient operational scenarios. > > > -- > Ondřej Surý > vedoucí výzkumu/R&D manager > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Apr 7 14:53:13 2010 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 8C1FD3A691F; Wed, 7 Apr 2010 14:53:13 -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 WGb0OwvcRPIK; Wed, 7 Apr 2010 14:53:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 921E03A67D7; Wed, 7 Apr 2010 14:53:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzd7F-0000e7-JY for namedroppers-data0@psg.com; Wed, 07 Apr 2010 21:48:53 +0000 Received: from [209.85.222.187] (helo=mail-pz0-f187.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzd7B-0000dd-Ve for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 21:48:50 +0000 Received: by pzk17 with SMTP id 17so1407214pzk.5 for ; Wed, 07 Apr 2010 14:48:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.180.6 with HTTP; Wed, 7 Apr 2010 14:48:48 -0700 (PDT) In-Reply-To: References: <4BB3E324.2050207@isc.org> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> Date: Wed, 7 Apr 2010 14:48:48 -0700 Received: by 10.114.164.13 with SMTP id m13mr9313490wae.166.1270676928245; Wed, 07 Apr 2010 14:48:48 -0700 (PDT) Message-ID: Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries From: Matthew Dempsky To: Ted Hardie Cc: 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, Apr 7, 2010 at 1:46 PM, Ted Hardie wrote: > The proposal on the table changes the cachability characteristics of the > response, by tying it to a specific =A0locality in IP space. =A0 That may= eliminate > this optimization. There's no reason queries with the same edns-client-ip parameter can't be merged (and to prevent colliding attacks, it's advisable that they do). Further, caches should only be sending queries with netmask>0 to servers they actually expect will give a useful response, so there's explicit opt-in for the extra bandwidth on both parties. A cache won't send queries with a long netmask and an authoritative server won't suggest longer netmasks unless they want to endure the extra costs. > You have to know what the application does to know whether this leakage > is new or not. =A0An http client talking to =A0a squid proxy does not lea= k prior > to this and leaks now. How does your HTTP client know that the HTTP proxy isn't adding an X-Forwarded-For header? Also, an HTTP client that's talking to an HTTP proxy shouldn't be talking to DNS anyway. If you're going to ask an HTTP proxy for http://www.ietf.org/, the client has no use for resolving www.ietf.org first. I'd suggest mail clients resolving DKIM TXT records as a more realistic example. That said, I don't see any realistic scenarios where queries for A/AAAA records could result in privacy leaks, and I don't see any reason a privacy conscious cache couldn't limit use of edns-client-ip to those record types. > No, the question is whether there is a method that is architecturally > sound, responsive to privacy concerns, and you know, actually works. > That might be worth a standard. > > You can have a method that is "open and can be implemented by anyone" > without being architecturally sound or responsive to privacy concerns wit= hout > meeting the other concerns. I don't like edns-client-ip's increased cache memory usage, but it's the best solution we have to date to improve user experience. If you have ideas on how to implement a 100% solution to this problem, then I'm interested. But in the mean time, I'm happy to use an easy-to-implement and easy-to-deploy 95% solution. From owner-namedroppers@ops.ietf.org Wed Apr 7 15:04:11 2010 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 0815E3A691F; Wed, 7 Apr 2010 15:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHCPZKAJ6ylo; Wed, 7 Apr 2010 15:04:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 340113A67D7; Wed, 7 Apr 2010 15:04:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzdIl-0002F0-PI for namedroppers-data0@psg.com; Wed, 07 Apr 2010 22:00:47 +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.71 (FreeBSD)) (envelope-from ) id 1NzdIi-0002EJ-D5 for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 22:00:44 +0000 Received: from [199.212.90.27] (helo=dh27.r1.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzdIf-000IM0-Eh; Wed, 07 Apr 2010 22:00:42 +0000 Subject: Re: [dnsext] Fwd: New Version Notification for draft-kerr-ixfr-only-01 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <20100407214355.GH1351@shinkuro.com> Date: Wed, 7 Apr 2010 18:00:40 -0400 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <1FCC5BC0-C414-4A3D-88E2-D28D8EB3A92E@hopcount.ca> References: <4B87D72A.5030206@nic.cz> <4BA8D973.2000100@nic.cz> <20100407214355.GH1351@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1078) X-SA-Exim-Connect-IP: 199.212.90.27 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false 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 2010-04-07, at 17:43, Andrew Sullivan wrote: > In any case, we have a request for adoption of draft-kerr-ixfr-only as > a WG item. I've noted some interest in the draft. If at least five > participants say they support adoption and commit to reviewing through > WGLC, then we can agree to the request. I support adoption and commit to reviewing through WGLC. Joe From owner-namedroppers@ops.ietf.org Wed Apr 7 15:23:36 2010 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 694263A69C6; Wed, 7 Apr 2010 15:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=-0.263, 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 LQUN-3vzMjj0; Wed, 7 Apr 2010 15:23:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B2F253A67D7; Wed, 7 Apr 2010 15:23:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzdbD-0004KW-FC for namedroppers-data0@psg.com; Wed, 07 Apr 2010 22:19:51 +0000 Received: from [209.85.212.52] (helo=mail-vw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzdb8-0004KF-GH for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 22:19:46 +0000 Received: by vws16 with SMTP id 16so8859vws.11 for ; Wed, 07 Apr 2010 15:19:44 -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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wz9XnvOjSIGnO3YdTKu1UTJn0W8UWSyfgN4M7vT46QM=; b=Tt6nQ0lq+YPU7jwk+Jr2bI2FDS41Sj07alEfIzNM3GrgSgF0FkODewZLYSIyGpxpFS m1azIfwEottvHFgsr5PZ9whctO6/4Bl6jFmDo1lgFPaLTWNcr6tVQkj5bwA/DnrFR7DR jAJZ1wg1pgFJkkuVua39X3aKlYct1spiVJ+A0= 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 :cc:content-type:content-transfer-encoding; b=Hfkp5vPGnwvGAyWjry+AgWJ4ez12XO9s13wS+Fy6PEhZnSBv+cKoVhyaa5zshofNeS DLTY6DuqccD8rqphVbOYwpBezgXUbBtFL3DYTEwqJ8omw/WpfxWMVQHDt0dvIKrG8uNv 8PBSdYdgCQfmZQYycttkAodsYvRYI7Fv96rwQ= MIME-Version: 1.0 Received: by 10.220.67.73 with HTTP; Wed, 7 Apr 2010 15:19:44 -0700 (PDT) In-Reply-To: References: <4BB3E324.2050207@isc.org> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> Date: Wed, 7 Apr 2010 15:19:44 -0700 Received: by 10.220.107.8 with SMTP id z8mr4755152vco.74.1270678784853; Wed, 07 Apr 2010 15:19:44 -0700 (PDT) Message-ID: Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries From: Ted Hardie To: Matthew Dempsky Cc: 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, Apr 7, 2010 at 2:48 PM, Matthew Dempsky wrote= : > On Wed, Apr 7, 2010 at 1:46 PM, Ted Hardie wrote: >> The proposal on the table changes the cachability characteristics of the >> response, by tying it to a specific =A0locality in IP space. =A0 That ma= y eliminate >> this optimization. > > There's no reason queries with the same edns-client-ip parameter can't > be merged (and to prevent colliding attacks, it's advisable that they > do). Sorry, that's the cachability characteristic I meant: now you have to merg= e based on edns-client-ip parameter, rather than more generally. > > How does your HTTP client know that the HTTP proxy isn't adding an > X-Forwarded-For header? By running it against a server I control? How do I know it isn't adding it to only *some* servers? I don't know. But I wouldn't support standardizing that behavior either. > > Also, an HTTP client that's talking to an HTTP proxy shouldn't be > talking to DNS anyway. =A0If you're going to ask an HTTP proxy for > http://www.ietf.org/, the client has no use for resolving www.ietf.org > first. As has been pointed out, my use of "proxy" has varied and been inexact. My apologies. >=A0I'd suggest mail clients resolving DKIM TXT records as a more > realistic example. > > That said, I don't see any realistic scenarios where queries for > A/AAAA records could result in privacy leaks, and I don't see any > reason a privacy conscious cache couldn't limit use of edns-client-ip > to those record types. > Freedom Fighter X from territory FOO queries Bad Gov BAR's servers for ENUM records related to a specific phone number. Assuming Bad Gov BAR answers using servers its controls, it gets the IP address or range used to query for the number. Constructing the SIP path to initiate the call could use entirely different IPs and a proxy infrastructure outside Bad Gov BAR's control. You'd probably pay in call quality, but not with your life. I did not see a limitation in the draft to A/AAAA, and the problem with identifying a "privacy conscious cache" goes back to the discussion raised above--how do I know? > >> No, the question is whether there is a method that is architecturally >> sound, responsive to privacy concerns, and you know, actually works. >> That might be worth a standard. >> >> You can have a method that is "open and can be implemented by anyone" >> without being architecturally sound or responsive to privacy concerns wi= thout >> meeting the other concerns. > > I don't like edns-client-ip's increased cache memory usage, but it's > the best solution we have to date to improve user experience. =A0If you > have ideas on how to implement a 100% solution to this problem, then > I'm interested. =A0But in the mean time, I'm happy to use an > easy-to-implement and easy-to-deploy 95% solution. > It's pretty obvious I don't agree with at least some folks on the requireme= nts. I think this should be opt-in; that's a non-requirement or too high a deplo= yment barrier for others. So it's not 95% of my personal requirements. regards, Ted Hardie From owner-namedroppers@ops.ietf.org Wed Apr 7 17:18:22 2010 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 0D5F43A681C; Wed, 7 Apr 2010 17:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.014 X-Spam-Level: X-Spam-Status: No, score=-102.014 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 Zex03E6rnd1d; Wed, 7 Apr 2010 17:18:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 17ACC3A67E1; Wed, 7 Apr 2010 17:18:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzfKc-000FYz-Ti for namedroppers-data0@psg.com; Thu, 08 Apr 2010 00:10:50 +0000 Received: from [216.239.44.51] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzfKZ-000FYe-RG for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 00:10:48 +0000 Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o380Ake2021586 for ; Wed, 7 Apr 2010 17:10:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270685446; bh=Bjd8Fc9Gl6Tw304QAmYP6kdy6/Q=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZiisaXqOvLSIWFIcm5EhU034sp1N31wXxDJR7Ptr4wLJWC5mRcz2wjiekd/7C2lZ7 frUd04b5XihWVbfGUYs7w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=pYldy96zfyA8SYmMSRCDLC6E0unaGUqUDu0h3Klv+TwCzerGRuXfonWojfe561WFY tmYXejnkcmsoHr9LC97FQ== Received: from fxm26 (fxm26.prod.google.com [10.184.13.26]) by kpbe14.cbf.corp.google.com with ESMTP id o380AiIS017427 for ; Wed, 7 Apr 2010 17:10:45 -0700 Received: by fxm26 with SMTP id 26so78675fxm.13 for ; Wed, 07 Apr 2010 17:10:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.186.17 with HTTP; Wed, 7 Apr 2010 17:10:24 -0700 (PDT) In-Reply-To: References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> From: Carlo Contavalli Date: Thu, 8 Apr 2010 01:10:24 +0100 Received: by 10.239.188.19 with SMTP id n19mr939632hbh.170.1270685444346; Wed, 07 Apr 2010 17:10:44 -0700 (PDT) Message-ID: Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries To: Ted Hardie Cc: Matthew Dempsky , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true 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, Apr 7, 2010 at 11:19 PM, Ted Hardie wrote: >> That said, I don't see any realistic scenarios where queries for >> A/AAAA records could result in privacy leaks, and I don't see any >> reason a privacy conscious cache couldn't limit use of edns-client-ip >> to those record types. >> > > Freedom Fighter X from territory FOO queries Bad Gov BAR's > servers for ENUM records related to a specific phone number. > Assuming Bad Gov BAR answers using servers its controls, > it gets the IP address or range used to query for the number. > > Constructing the SIP path to initiate the call could use entirely > different IPs and a proxy infrastructure outside Bad Gov BAR's > control. You'd probably pay in call quality, but not with your life. > > I did not see a limitation in the draft to A/AAAA, and the problem > with identifying a "privacy conscious cache" goes back to the discussion > raised above--how do I know? Is there anything *now* in the DNS protocol that provides you with any guarantee that your IP isn't captured or forwarded by other means to parties you do not want to see it? Eg, how do you know that the resolver you're using *now* is not forwarding your ip by using a non-standard protocol extension? or storing it in case law enforcement agencies ask them? How do you know it's being "privacy conscious"? I do not think that the lack of a standardized extension decreases the chances of my ip being forwarded to parties I don't trust against my will. If this is something the industry is doing or needs to do, I believe standardizing it is a way to provide guidelines, better control it, expose the practice, and increase awareness, even if I don't think it's a real threat to begin with. Freedom Fighter X should not use the DNS to begin with, or protect his DNS queries by other means. There is no way to guarantee that his IP is not being seen or disclosed to other parties, regardless of edns-client-ip. If you do not trust your recursive resolver to do the right thing, all bets are off. Carlo From owner-namedroppers@ops.ietf.org Wed Apr 7 17:25:53 2010 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 D8CF33A6853; Wed, 7 Apr 2010 17:25:53 -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 SZcPMuk3IoH6; Wed, 7 Apr 2010 17:25:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AECA73A67E1; Wed, 7 Apr 2010 17:25:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzfUe-000GtT-C8 for namedroppers-data0@psg.com; Thu, 08 Apr 2010 00:21:12 +0000 Received: from [74.125.83.52] (helo=mail-gw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzfUb-000Gt4-Jr for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 00:21:09 +0000 Received: by gwj23 with SMTP id 23so799068gwj.11 for ; Wed, 07 Apr 2010 17:21:08 -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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4BuFLvbGnCuFQJAZyq/hz6aovYfkIddWRxE8D8yUDcE=; b=b8FguU3dePQDuZ9E8KocMBXzs84vccnsJJ0dO8aqNpMwon17WTRe+R2nEsY/bsiPPf STcLkn+edVE73gvb8vrqVXBXrZyvDwQpxFjKMAFV5eoZ9EJWMSnPHQezl4pbIog5Mlh5 mEaJQ9Q8Yp/pPjAZtk+O8wauPxJ2NIMabOTLw= 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 :cc:content-type:content-transfer-encoding; b=aQD57y3lLtoOC3Hf6gYeiuDVfCW5My2AwA5GgxoGNECw6ChGmghyR8/MO6e7T5dOUT gRRx82DFIBbb9RQKcFqxr4hZ/5aePHK6izYLCZ1qrg3cnQcoy/F3LP9hIeK5CfsVayv7 JY0Jdrh+dTNDyYmcCSAi9h1Rmr0KKqSjDsC98= MIME-Version: 1.0 Received: by 10.100.91.5 with HTTP; Wed, 7 Apr 2010 17:21:08 -0700 (PDT) In-Reply-To: <20100407214355.GH1351@shinkuro.com> References: <4B87D72A.5030206@nic.cz> <4BA8D973.2000100@nic.cz> <20100407214355.GH1351@shinkuro.com> Date: Wed, 7 Apr 2010 21:21:08 -0300 Received: by 10.101.167.36 with SMTP id u36mr20438602ano.171.1270686068611; Wed, 07 Apr 2010 17:21:08 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Fwd: New Version Notification for draft-kerr-ixfr-only-01 From: Brian Dickson To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=UTF-8 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, Apr 7, 2010 at 6:43 PM, Andrew Sullivan wrote: > Dear colleagues, > > This request got overlooked (by me) during the IETF meeting. > Apologies to Ond=C5=99ej and Shane. > > In any case, we have a request for adoption of draft-kerr-ixfr-only as > a WG item. =C2=A0I've noted some interest in the draft. =C2=A0If at least= five > participants say they support adoption and commit to reviewing through > WGLC, then we can agree to the request. I support adoption as a WG item. I commit to reviewing through WGLC. Brian From dnsext-archive@ietf.org Thu Apr 8 02:45:13 2010 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 162A23A6826 for ; Thu, 8 Apr 2010 02:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.005 X-Spam-Level: X-Spam-Status: No, score=-21.005 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_PL=1.135, HELO_MISMATCH_PL=1.448, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, 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_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, URI_HEX=0.368, 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 P4oEbtuRb01L for ; Thu, 8 Apr 2010 02:45:07 -0700 (PDT) Received: from userv.ctc.pl (unknown [217.11.136.62]) by core3.amsl.com (Postfix) with ESMTP id 710963A6A2D for ; Thu, 8 Apr 2010 02:44:55 -0700 (PDT) From: "Viagra Pharmacy #1" To: dnsext-archive@ietf.org Subject: To user dnsext-archive: 70% prices slashing MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100408094455.710963A6A2D@core3.amsl.com> Date: Thu, 8 Apr 2010 02:44:55 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Website of the store on-line

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Ywucqmai. All rights reserved.
From dnsext-archive@lists.ietf.org Thu Apr 8 02:45:56 2010 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 17E713A68CC for ; Thu, 8 Apr 2010 02:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.005 X-Spam-Level: X-Spam-Status: No, score=-21.005 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_PL=1.135, HELO_MISMATCH_PL=1.448, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, 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_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, URI_HEX=0.368, 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 jAl0wnhzo8-S for ; Thu, 8 Apr 2010 02:45:50 -0700 (PDT) Received: from userv.ctc.pl (unknown [217.11.136.62]) by core3.amsl.com (Postfix) with ESMTP id AF0553A6826 for ; Thu, 8 Apr 2010 02:45:49 -0700 (PDT) From: "Viagra Pharmacy #1" To: dnsext-archive@lists.ietf.org Subject: To user dnsext-archive: 70% prices slashing MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100408094549.AF0553A6826@core3.amsl.com> Date: Thu, 8 Apr 2010 02:45:49 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Website of the store on-line

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Myveh. All rights reserved.
From owner-namedroppers@ops.ietf.org Thu Apr 8 06:23:55 2010 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 944413A6A6B; Thu, 8 Apr 2010 06:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.124 X-Spam-Level: X-Spam-Status: No, score=0.124 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_SORBS_WEB=0.619, 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 YeXv4zgShjd1; Thu, 8 Apr 2010 06:23:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4CFEF28C150; Thu, 8 Apr 2010 06:22:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzraB-0002bO-3w for namedroppers-data0@psg.com; Thu, 08 Apr 2010 13:15:43 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzra8-0002az-Ei for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 13:15:40 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o38DFdl0099854 for ; Thu, 8 Apr 2010 09:15:39 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id o38DFd1p099853 for namedroppers@ops.ietf.org; Thu, 8 Apr 2010 09:15:39 -0400 (EDT) (envelope-from namedroppers) Received: from [140.186.190.103] (helo=haybaler.sackheads.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzdjq-00052q-CN for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 22:28:46 +0000 Received: from localhost (localhost.sackheads.org [127.0.0.1]) by haybaler.sackheads.org (Postfix) with ESMTP id 600B428661; Wed, 7 Apr 2010 18:28:45 -0400 (EDT) Authentication-Results: haybaler.sackheads.org; domainkeys=pass (testing) header.from=john@sackheads.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1270679325; bh=aB3TOWbOPk+XFqm4avevUJJceWaTIVIBhrKt0Wsg6cU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TeS9yXan3AQuS9oismURLn29Izmzu1lrLBH56SWt0IfSni84I1w7Kuzy6iSSK2IWO LHq8KTiV+V/OIT1+Z2J9wB+M9wXh8u9vzHbAApuawtos3syt//RQP7CyORwQxJJOVQ 6fvYeEPT6FvhMRVGr53ZlLqYMN5qte0mz6LzTmtg= Received: from haybaler.sackheads.org ([127.0.0.1]) by localhost (haybaler.sackheads.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6jv+KbEE9Kx; Wed, 7 Apr 2010 18:28:45 -0400 (EDT) Received: by haybaler.sackheads.org (Postfix, from userid 65534) id 3CBC52864B; Wed, 7 Apr 2010 18:28:45 -0400 (EDT) Received: from mobilehost12788.mobile.mymmode.com (unknown [72.246.0.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: john@sackheads.org) by haybaler.sackheads.org (Postfix) with ESMTP id 131542862B; Wed, 7 Apr 2010 18:28:42 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=haybaler; d=sackheads.org; c=nofws; q=dns; h=dkim-signature:subject:mime-version:content-type:from: in-reply-to:date:cc:content-transfer-encoding:message-id:references:to:x-mailer; b=nVNzMfkAckUcSPFAHCJrm9KeqFcsAqFwDt0y3gxV4gt0GvXnNwqUrnFTbDvMgrcPX TpSz/p9fhyjos1bUtVIfCil71ubUk7pjJBq+cdm/IM26NwJs4ZiXnT+7keTfQjwbucp TCBP6WVpypPx7esUhtwqjQLg14sKV14EdgE4TTg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1270679325; bh=aB3TOWbOPk+XFqm4avevUJJceWaTIVIBhrKt0Wsg6cU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TeS9yXan3AQuS9oismURLn29Izmzu1lrLBH56SWt0IfSni84I1w7Kuzy6iSSK2IWO LHq8KTiV+V/OIT1+Z2J9wB+M9wXh8u9vzHbAApuawtos3syt//RQP7CyORwQxJJOVQ 6fvYeEPT6FvhMRVGr53ZlLqYMN5qte0mz6LzTmtg= Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: John Payne In-Reply-To: <94999.1270660631@nsa.vix.com> Date: Wed, 7 Apr 2010 18:28:37 -0400 Cc: Nicholas Weaver , Ted Hardie , David Ulevitch , namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4C263138-34F9-47EA-B727-DF363645AE9F@sackheads.org> References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> <89801.1270653567@nsa.vix.com> <94999.1270660631@nsa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.1077) X-Scanned-By: MIMEDefang 2.67 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 Apr 7, 2010, at 1:17 PM, Paul Vixie wrote: >> From: Nicholas Weaver >> Date: Wed, 7 Apr 2010 13:09:59 -0400 >>=20 >> After all, if this model did not represent reality, how would Akamai = be >> in business? >=20 > akamai offers the great boon of requiring consciousness and discipline > on the part of web publishers. to use akamai's services you have to = use > relative URL's for in-site navigation, and you have to know when and = what > you are publishing. Paul... please realize that many people take what you say as completely = factual. You seem to be confusing a particular toolset that I don't think has = been in use in about 8 years (an "akamaizer") with the end result of = Akamai serving websites. I can't think of a single instance now that = requires relative URLs. I also would hope that people know when and = what they publish with or without CDNs, but that's also not a = requirement to use a CDN. From owner-namedroppers@ops.ietf.org Thu Apr 8 06:23:56 2010 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 4FF1A3A6A6B; Thu, 8 Apr 2010 06:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.217 X-Spam-Level: X-Spam-Status: No, score=-95.217 tagged_above=-999 required=5 tests=[AWL=-0.956, 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, 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 Dtp6VIrzUmRN; Thu, 8 Apr 2010 06:23:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2991028C152; Thu, 8 Apr 2010 06:22:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzraf-0002ee-57 for namedroppers-data0@psg.com; Thu, 08 Apr 2010 13:16:13 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzrab-0002eJ-Oq for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 13:16:10 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA153712531; Thu, 8 Apr 2010 15:15:31 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA11709; Thu, 8 Apr 2010 15:15:30 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004081315.PAA11709@TR-Sys.de> Subject: [dnsext] Re: adoption of draft-kerr-ixfr-only-01 as a work item for DNSEXT To: namedroppers@ops.ietf.org Date: Thu, 8 Apr 2010 15:15:30 +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: [[ changed Subject to make it more expressive ]] Andrew Sullivan wrote: > In any case, we have a request for adoption of draft-kerr-ixfr-only as > a WG item. I've noted some interest in the draft. If at least five > participants say they support adoption and commit to reviewing through > WGLC, then we can agree to the request. > > Best regards, > > Andrew (as co-chair) I *conditionally* support the ixfr-only proposal. Background: Given the approval of axfr-clarify for publication as an RFC and discussions we had on AXFR over UDP (two year ago, rejected by the WG), large parts of RFC 1995 have become aged and inappropriate. RFC 1995 is based on the (non-)specification of AXFR in STD 13 and states two assumptions on AXFR that simply do not hold (or do not hold any more) -- there is no scenario for AXFR where the server responds with a single SOA record, and there is no need for a SOA query *over UDP* before performing AXFR (over TCP). Even worse, the RFC 1995 procedure apparently is incompatible with the response verification rules laid down in the Forgery Resilience document, RFC 5452; this IMHO makes the automatic fallback from IXFR to AXFR rather questionable *in general*, from a current point of view. Further, I found a substantial amount of editorial flaws in RFC 1995. Thus, it seems of utmost priority to first provide an updated specification for IXFR before starting work in the WG that is based on this aged RFC. Of course, the ixfr-only idea could be easily integrated with an rfc1995-bis draft, and that should IMHO be the way to proceed. This strategy would reduce the number of documents to work on and avoid complicated document dependencies impeding advancement of documents on the Standards Track. Given the WGs decision to ban AXFR over UDP, the UDP part of IXFR should be reconsidered, and it might indeed make sense to integrate the idea of ixfr-only with the UPD-only part of IXFR. Recently, I already had offered our chairs to help work on a rfc1995-bis draft -- as soon as the AXFR RFC is out. Technical detail: Since ixfr-only needs EDNS anyway (for a new [extended] RCODE), it should be considered to signal new behavior for IXFR (and allow for additional feedback if necessary) via a new EDNS Option (for use with IXFR only), thus avoiding the introduction of a new QTYPE. 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 Apr 8 06:24:16 2010 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 09B5C28C14D; Thu, 8 Apr 2010 06:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.124 X-Spam-Level: X-Spam-Status: No, score=0.124 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_SORBS_WEB=0.619, 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 UCGf3ScgBUDy; Thu, 8 Apr 2010 06:24:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C804128C159; Thu, 8 Apr 2010 06:22:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzrZt-0002Yg-GU for namedroppers-data0@psg.com; Thu, 08 Apr 2010 13:15:25 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzrZn-0002Y5-Cu for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 13:15:21 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o38DFHCb099844 for ; Thu, 8 Apr 2010 09:15:17 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id o38DFHXK099843 for namedroppers@ops.ietf.org; Thu, 8 Apr 2010 09:15:17 -0400 (EDT) (envelope-from namedroppers) Received: from [140.186.190.103] (helo=haybaler.sackheads.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzdjm-00051R-Np for namedroppers@ops.ietf.org; Wed, 07 Apr 2010 22:28:43 +0000 Received: from localhost (localhost.sackheads.org [127.0.0.1]) by haybaler.sackheads.org (Postfix) with ESMTP id 3D69528628; Wed, 7 Apr 2010 18:28:39 -0400 (EDT) Authentication-Results: haybaler.sackheads.org; domainkeys=pass (testing) header.from=john@sackheads.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1270679319; bh=32pA+LNDXGaeqZKgeyf3PGwo89v0UVNMkbwIT3RvxKg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=YBzpcb9Y5FFxx+pyJ9vG9dkq+ndq8/adKfo3d6t3FlB2+qf2wSrhgkQUBWTHnqfB/ suBLVxDegczLI4JZDUwUwXG/z7lXLCaIgadP/hpNwc+FyW3ZVPgBp6DK3Z7qEn2nx1 nDrWfdk/EextSGPsdt9tViQgh/khLYP4QgDXaug8= Received: from haybaler.sackheads.org ([127.0.0.1]) by localhost (haybaler.sackheads.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19votuU7W-AN; Wed, 7 Apr 2010 18:28:39 -0400 (EDT) Received: by haybaler.sackheads.org (Postfix, from userid 65534) id 165D428626; Wed, 7 Apr 2010 18:28:39 -0400 (EDT) Received: from mobilehost12788.mobile.mymmode.com (unknown [72.246.0.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: john@sackheads.org) by haybaler.sackheads.org (Postfix) with ESMTP id CF75328625; Wed, 7 Apr 2010 18:28:37 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=haybaler; d=sackheads.org; c=nofws; q=dns; h=dkim-signature:subject:mime-version:content-type:from: in-reply-to:date:cc:content-transfer-encoding:message-id:references:to:x-mailer; b=WfN+tFpH0scFiteXR0QqN08A+7jdE1IwsG8CI3Pbt99U0MGXBb6vtq/03plgWbG3j +IKgAbWncIntHIq7gfrWBr6S1YR6y7CJF0Fvadm6OlPHL5eYCs3NIfjjLulI66g/voo Bw80PxpfJYVg2rJmi6NDE1oQpqcgcL79yUQR6Xg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1270679318; bh=32pA+LNDXGaeqZKgeyf3PGwo89v0UVNMkbwIT3RvxKg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=zmYbQyDSKR8oCsxjIIAVLHrXCM5LlCxxDsvwRPgwJcNZiRHkvv/ATPnyNYxzYrQ9d S9WMmZzvn5YQ/2ihL0UUbxYsa230vZYD5bk5UoGRAeITFyZP9djfboXTyA33zllwDv LE3Mz22ViDiAUo4V5alxfpxMZDjpMngmdNkVrjrg= Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: John Payne In-Reply-To: <42864.1270583728@nsa.vix.com> Date: Wed, 7 Apr 2010 18:28:26 -0400 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2F1E984B-4709-4BBA-8379-C1F92AA19546@sackheads.org> References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.1077) X-Scanned-By: MIMEDefang 2.67 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 Apr 6, 2010, at 3:55 PM, Paul Vixie wrote: > third, this proposal assumes that triangulation is a predictor of = either > performance or reachability or locality. if somebody proxies their = DNS in > one direction and proxies their HTTP in another direction, or if = distance > A-C is completely unrelated to distances A-B and B-C due to wormholes, = then > locality logic will either add no value or actually subtract value. = this > kind of differential proxying and these kinds of wormholes are already = quite > common and there's no reason to expect a reduction here, not even = based on > theoretical advantages offered indirectly by the proposal we're = discussing. This proposal closes the "distant recursive DNS" case. It only makes = things better there. Where DNS and HTTP are deliberately sent via different paths today, = _no_ difference to today. Some might be better, some might be worse. = Some might see absolutely no difference. Who cares? With the = popularity of opendns and google public dns, there's instant benefit to = many. >=20 > fourth, this proposal assumes that all applications want locality = expressed > in terms of IP addresses, and does not generalize it to include = language > preference or geolocation or political boundary information. if we're = going > to add locality or identity information to DNS queries then we should = find > out what the W3C people think, and other non-web applications people = think, > since when locality was added to HTTP it was expressed as a longer = vector > than just "client's IP address". we should do this right if we're = going to > do it at all. As far as I can tell.... there is no assumption of locality at all, = other than proximity. =20 Any geolocation, language, etc would be handled at a higher level, _as = it is today_.=20= From owner-namedroppers@ops.ietf.org Thu Apr 8 07:26:14 2010 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 C78393A6837; Thu, 8 Apr 2010 07:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.913 X-Spam-Level: X-Spam-Status: No, score=-94.913 tagged_above=-999 required=5 tests=[AWL=-1.022, BAYES_20=-0.74, 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, 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 4G20bW5FNd3j; Thu, 8 Apr 2010 07:26:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CE7023A67A7; Thu, 8 Apr 2010 07:26:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzsbO-000APg-QO for namedroppers-data0@psg.com; Thu, 08 Apr 2010 14:21:02 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzsbK-000APF-CQ for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 14:20:59 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA153896423; Thu, 8 Apr 2010 16:20:23 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA11765; Thu, 8 Apr 2010 16:20:22 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004081420.QAA11765@TR-Sys.de> Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 To: namedroppers@ops.ietf.org Date: Thu, 8 Apr 2010 16:20:22 +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: Beyond the ongoing discussion, I have concerns with the compatibility of the proposal with DNSSEC. If DNSSEC verification is done locally (at the stub resolver, at a CPE edge router, etc.) but a "general" recursor is used for the first stage of DNS resolution, there seem to be lots of opportunities for getting RRSIGs inconsistent with the 'customized' RRsets served to the stub and verifier. IMO, for various reasons DNSSEC verification is likely to become of much greater importance for many (most?) Internet users shortly than the fractional parts of seconds in web access the proponents of this proposal claim to provide as a justification. I'd like to see a draft revision that clearly explains how DNSSEC will work with this idea before the question for adaption as a work item is restated. Further, regarding the claimed justification: The delays induced by missing or poorly configured reverse DNS entries and much too short TTL values (altogether holding off firewall approval of access until sensical domain names are available for logging and policy treatment, e.g. advertisement and 'tracer/counter' suppression) exceed the claimed acceleration by an order of magnitude (at least), and the time needed for the user to read, check and deny (or accept) myriads of cookie requests issued by many sites adds another magnitude. 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 Apr 8 07:55:30 2010 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 6F24B3A68F6; Thu, 8 Apr 2010 07:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.552 X-Spam-Level: * X-Spam-Status: No, score=1.552 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_50=0.001, 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 XRG2UG9Vs6fe; Thu, 8 Apr 2010 07:55:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CF723A68DE; Thu, 8 Apr 2010 07:55:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzt4h-000EIk-Iw for namedroppers-data0@psg.com; Thu, 08 Apr 2010 14:51:19 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzt4c-000EHv-0S for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 14:51:14 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o38Ep5Xo000637; Thu, 8 Apr 2010 10:51:06 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Thu, 08 Apr 2010 10:51:11 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 08 Apr 2010 10:51:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4BB3E324.2050207@isc.org> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> Date: Thu, 8 Apr 2010 10:42:08 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: [dnsext] Privacy and Re: ...-edns-client-ip-00 Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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:19 -0700 4/7/10, Ted Hardie wrote: >It's pretty obvious I don't agree with at least some folks on >the requirements. I think this should be opt-in; that's a non-requirement >or too high a deployment barrier for others. So it's not 95% of my >personal requirements. In the effort to help with the next version of the edns-client-ip draft, I am having a hard time understanding why privacy is a concern. Reading the messages I realize that there's a fear that if the authority servers know who's asking, then the authority servers have a better grasp on who is asking for information. What I mean by "having a hard time understanding" is more a reflection that I think the concern, as I am reading it, is unfounded. I am saying this because it could be I'm just not seeing the issue. And until then I wouldn't know what to recommend be included in the draft. In today's DNS, if you ask for information from a recursive server, that server has the ability to record who asked for what at a fine level of granularity. The initiator could use different recursive servers to try to "hide" a pattern of access, so one server might not see all the queries. At the authority server, what becomes apparent is the IP address of the recursive servers, but at a much lower granularity - not each query that is issued but only for queries that are cache misses. If the TTL of an RRset is long, a lot of the end queries won't make it to the authority. There are many factors to consider. But taking the example of an enum query, which identifies an E.164 telephone number that is potentially being contacted, what is going on? There are those that propose the TTLs of "enum" records (typically NAPTR) be kept short to provide the real-time-iness of the current telephone system. This would mean more cache-misses and therefore more of a reflection of actual initiator query activity. (Are we talking a single initiator or multiple?) Without edns-client-ip, it is still possible to determine the recursive servers sending the query, using non-DNS means. Assuming there is legal leverage, an authority could approach/force operators to monitor the incoming requests to get closer to the source. (If the operator doesn't cooperate, the authority could simply not respond to the recursive server. But if things are that sinister, why doesn't the authority just go after the holder of the telephone number and pursue actions there?) National jurisdictions being what they are, one can dream up a lot of spy novel situations - which is what makes it hard to quantify the underlying DNS protocol issue at hand. If the situation is not as cat-and-mouse as a political cloak-and-dagger mystery, for example, merely trying to capture demographic data about shoppers, then you have a situation where the recursive cache operator has a competitive advantage over the authority server. Revealing the client IP has to meeting with some incentive by the authority server. (The general lack of this is why this is not a general purpose feature.) If the desire is to hide query patterns even if extreme measures are taken, it is still possible to create "reasonable doubt" about the actual source via a series of forwarders. If one is willing to do this, then they are also not likely to take advantage of a tailored response based on their topology. (Or have that provided at the application management layer.) My misunderstanding of the privacy concern boils down to - with edns-client-ip the authority server will only see the sources that cause cache misses from intermediates that are willing to reveal where the query came from. If the intermediate is topologically co-located with the client, then there's no need to pass this on, and therefore quite useless. If the intermediate is offering some sort of anonymization (wsat? = would scrabble allow that?) then there's no incentive to send the edns-client-ip. Only if the intermediate wants to mimic the authority's tailoring service is there incentive to reveal something about the query source. And even then only to a fuzzy level of detail (probably never more than a /24 of IPv4 because that seems to be the lower limit of what policy carries in an exterior gateway protocol. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From owner-namedroppers@ops.ietf.org Thu Apr 8 08:00:06 2010 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 1D6EE3A67B4; Thu, 8 Apr 2010 08:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.979 X-Spam-Level: * X-Spam-Status: No, score=1.979 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_50=0.001, 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 QztpDO5WIdZv; Thu, 8 Apr 2010 08:00:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B669028C12C; Thu, 8 Apr 2010 08:00:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzt9q-000F27-EM for namedroppers-data0@psg.com; Thu, 08 Apr 2010 14:56:38 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzt9h-000Ezc-WB for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 14:56:30 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o38EuMhj000700; Thu, 8 Apr 2010 10:56:23 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Thu, 08 Apr 2010 10:56:28 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 08 Apr 2010 10:56:28 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201004081420.QAA11765@TR-Sys.de> References: <201004081420.QAA11765@TR-Sys.de> Date: Thu, 8 Apr 2010 10:56:17 -0400 To: Alfred =?hp-roman8?B?SM5uZXM=?= From: Edward Lewis Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 16:20 +0200 4/8/10, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >Beyond the ongoing discussion, I have concerns with the >compatibility of the proposal with DNSSEC. I think there is no issue. Let's say I have this: For all IP addressed in 24.0.0.0/8 www.example.org A 192.0.2.100 and for all other IP address: www.example.org A 192.0.2.200 Then I would use the same zone key to sign each record set and hand out the answer as appropriate. www.example.org A 192.0.2.100 www.example.org RRSIG A ........ example.org. 12345 ...... sig1 and www.example.org A 192.0.2.200 www.example.org RRSIG A ........ example.org. 12345 ...... sig2 (example.org. DNSKEY .... would have explicit 0.0.0.0/0&::/0 range) The RRSIG & DS & etc. would be the same for the different records. Same as we would do for split DNS using views. I could elaborate, but let me try to get away with a quick response first to see of that makes sense. (The answer lays in RFC 2181's trustworthiness ratings.) >If DNSSEC verification is done locally (at the stub resolver, >at a CPE edge router, etc.) but a "general" recursor is used >for the first stage of DNS resolution, there seem to be lots >of opportunities for getting RRSIGs inconsistent with the >'customized' RRsets served to the stub and verifier. If the RRSIGs are managed in the correct way - that is as part of an RRSet, then they won't be confused. If a cache does not employ edns-client-ip, then it can't tell one answer from the next. It is possible that the cache might see both (but how?) sets, but this is no different than a cache seeing an updated set today. (The only difference is that there is wall clock data in the RRSIG - but one should not conflate that with serial numbers. It is possible that a newer serial number could have RRSIGs with older times.) >IMO, for various reasons DNSSEC verification is likely to become >of much greater importance for many (most?) Internet users shortly >than the fractional parts of seconds in web access the proponents >of this proposal claim to provide as a justification. My estimation is that this is short changing the justification. It's not just making the web browser faster, it's also helping to divide the load on data centers. To be truthful, I don't know of a white paper that is sufficiently detailed to establish this in the "engineering plane". However, it does seem to be playing well in the "press release plane." >I'd like to see a draft revision that clearly explains how DNSSEC >will work with this idea before the question for adaption as a work >item is restated. That can be included. DNSSEC issues are not unique to edns-client-ip, they crop up in tailoring responses based on load measurements and many other factors. >Further, regarding the claimed justification: > >The delays induced by missing or poorly configured reverse DNS >entries and much too short TTL values (altogether holding off >firewall approval of access until sensical domain names are >available for logging and policy treatment, e.g. advertisement >and 'tracer/counter' suppression) exceed the claimed acceleration >by an order of magnitude (at least), and the time needed for the >user to read, check and deny (or accept) myriads of cookie >requests issued by many sites adds another magnitude. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From owner-namedroppers@ops.ietf.org Thu Apr 8 08:14:50 2010 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 8813E3A6A99; Thu, 8 Apr 2010 08:14:50 -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 4qmo92fEyUa1; Thu, 8 Apr 2010 08:14:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A28513A6AA3; Thu, 8 Apr 2010 08:14:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NztMy-000GfL-Fv for namedroppers-data0@psg.com; Thu, 08 Apr 2010 15:10:12 +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.71 (FreeBSD)) (envelope-from ) id 1NztMs-000GeS-L1 for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 15:10:07 +0000 Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id o38F9vI2062467; Thu, 8 Apr 2010 17:09:57 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <201004081509.o38F9vI2062467@bartok.nlnetlabs.nl> To: Edward Lewis cc: Alfred =?hp-roman8?B?SM5uZXM=?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 In-reply-to: References: <201004081420.QAA11765@TR-Sys.de> Comments: In-reply-to Edward Lewis message dated "Thu, 08 Apr 2010 10:56:17 -0400." Date: Thu, 08 Apr 2010 17:09:57 +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, 08 Apr 2010 17:09:57 +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: Wouldn't it be nice if all of the definitions of equivalence were the same? YES! And we seem to think a like about the pivacy issue. jaap From owner-namedroppers@ops.ietf.org Thu Apr 8 08:25:23 2010 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 3A8E63A6A13; Thu, 8 Apr 2010 08:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.119 X-Spam-Level: X-Spam-Status: No, score=-4.119 tagged_above=-999 required=5 tests=[AWL=0.929, 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 vdXKtwz+KvsA; Thu, 8 Apr 2010 08:25:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C0E8D3A68AE; Thu, 8 Apr 2010 08:25:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NztX9-000I9M-B5 for namedroppers-data0@psg.com; Thu, 08 Apr 2010 15:20:43 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NztX5-000I7z-6W for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 15:20:39 +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 o38FJsJZ025597; Thu, 8 Apr 2010 08:20:36 -0700 (PDT) Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Thu, 8 Apr 2010 11:20:36 -0400 Cc: Nicholas Weaver , namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BB3E324.2050207@isc.org> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> To: Edward Lewis X-Mailer: Apple Mail (2.1078) 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: Additionally... On Apr 8, 2010, at 10:42 AM, Edward Lewis wrote: > At 15:19 -0700 4/7/10, Ted Hardie wrote: >> It's pretty obvious I don't agree with at least some folks on >> the requirements. I think this should be opt-in; that's a = non-requirement >> or too high a deployment barrier for others. So it's not 95% of my >> personal requirements. >=20 > In the effort to help with the next version of the edns-client-ip = draft, I am having a hard time understanding why privacy is a concern. = Reading the messages I realize that there's a fear that if the authority = servers know who's asking, then the authority servers have a better = grasp on who is asking for information. What I mean by "having a hard = time understanding" is more a reflection that I think the concern, as I = am reading it, is unfounded. I am saying this because it could be I'm = just not seeing the issue. And until then I wouldn't know what to = recommend be included in the draft. >=20 > In today's DNS, if you ask for information from a recursive server, = that server has the ability to record who asked for what at a fine level = of granularity. The initiator could use different recursive servers to = try to "hide" a pattern of access, so one server might not see all the = queries. =20 This is a very poor way to hide a pattern of access anyway. > My misunderstanding of the privacy concern boils down to - with = edns-client-ip the authority server will only see the sources that cause = cache misses from intermediates that are willing to reveal where the = query came from. If the intermediate is topologically co-located with = the client, then there's no need to pass this on, and therefore quite = useless. If the intermediate is offering some sort of anonymization = (wsat? =3D would scrabble allow that?) then there's no incentive to send = the edns-client-ip. Only if the intermediate wants to mimic the = authority's tailoring service is there incentive to reveal something = about the query source. And even then only to a fuzzy level of detail = (probably never more than a /24 of IPv4 because that seems to be the = lower limit of what policy carries in an exterior gateway protocol. Additionally, and key, DNS is not used in a vaccume as an information = service, but is almost exclusively used as a guideline to actually = initiate contact, or as a database lookup after contact has been = initiated the other way. =20 So even in the E.164 example, a DNS lookup is followed by an actual = contact from the initiator to the recipient, so the only privacy leakage = occurs when the system running the directory (DNS) does not also have = control over the final recipient data. Thus in nation-state type examples, the nation state can generally get = the exact information from the final contact (and if a nation-state = adversary is your threat model, you better be using TOR which makes all = these issues moot). =20 Likewise, for commercial privacy: if you are contacting web service X, = who cares that the slash /24 you are using apppears in service-provider = X's DNS authority server logs, when your actual IP is in the HTTP logs? Thus its clear that the ONLY information leakage which can occur, and = minor though it is, is when the authority server does NOT have any = access to the communication itself. From owner-namedroppers@ops.ietf.org Thu Apr 8 08:32:26 2010 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 911553A6AB5; Thu, 8 Apr 2010 08:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 GtVMwlo-HpzL; Thu, 8 Apr 2010 08:32:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B15AE3A6A87; Thu, 8 Apr 2010 08:32:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NztdS-000IvV-E9 for namedroppers-data0@psg.com; Thu, 08 Apr 2010 15:27:14 +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.71 (FreeBSD)) (envelope-from ) id 1NztdO-000Ius-I8 for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 15:27:11 +0000 Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id o38FR4XV085069; Thu, 8 Apr 2010 17:27:04 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <201004081527.o38FR4XV085069@bartok.nlnetlabs.nl> To: Edward Lewis , Alfred =?hp-roman8?B?SM5uZXM=?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 In-reply-to: <201004081509.o38F9vI2062467@bartok.nlnetlabs.nl> References: <201004081420.QAA11765@TR-Sys.de> <201004081509.o38F9vI2062467@bartok.nlnetlabs.nl> Comments: In-reply-to Jaap Akkerhuis message dated "Thu, 08 Apr 2010 17:09:57 +0200." Date: Thu, 08 Apr 2010 17:27:04 +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, 08 Apr 2010 17:27:04 +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: Oops, Private mail escaped the asylum^Wkeyboard. Sorry. jaap Wouldn't it be nice if all of the definitions of equivalence were the same? YES! And we seem to think a like about the privacy issue. jaap From dmanet@ietf.org Thu Apr 8 08:36:48 2010 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 74B593A6A80 for ; Thu, 8 Apr 2010 08:36:48 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Thu, 8 Apr 2010 08:36:47 -0700 (PDT) Received: from bzq-79-180-61-26.red.bezeqint.net (bzq-79-180-61-26.red.bezeqint.net [79.180.61.26]) by core3.amsl.com (Postfix) with SMTP id CE82A3A6ABA for ; Thu, 8 Apr 2010 08:36:04 -0700 (PDT) From: Approved VIAGRA® Store Subject: Special Code for 79% for dnsext-archive@ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100408153606.CE82A3A6ABA@core3.amsl.com> Date: Thu, 8 Apr 2010 08:36:04 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 46031 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Thu Apr 8 09:37:32 2010 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 271823A69C5; Thu, 8 Apr 2010 09:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 t70RFfnv0d-T; Thu, 8 Apr 2010 09:37:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81CEA3A69A2; Thu, 8 Apr 2010 09:37:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzudh-0000Tc-Vp for namedroppers-data0@psg.com; Thu, 08 Apr 2010 16:31:33 +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.71 (FreeBSD)) (envelope-from ) id 1Nzudf-0000RF-Bk for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 16:31:31 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id BC6ADA138B; Thu, 8 Apr 2010 16:31:30 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: John Payne cc: Nicholas Weaver , Ted Hardie , David Ulevitch , namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries In-Reply-To: Your message of "Wed, 07 Apr 2010 18:28:37 -0400." <4C263138-34F9-47EA-B727-DF363645AE9F@sackheads.org> References: <4BB3E324.2050207@isc.org> <92140.1270088620@nsa.vix.com> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> <89801.1270653567@nsa.vix.com> <94999.1270660631@nsa.vix.com> <4C263138-34F9-47EA-B727-DF363645AE9F@sackheads.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 08 Apr 2010 16:31:30 +0000 Message-ID: <51992.1270744290@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: John Payne > Date: Wed, 7 Apr 2010 18:28:37 -0400 > > You seem to be confusing a particular toolset that I don't think has been > in use in about 8 years (an "akamaizer") with the end result of Akamai > serving websites. I can't think of a single instance now that requires > relative URLs. I also would hope that people know when and what they > publish with or without CDNs, but that's also not a requirement to use a > CDN. i apologize for speaking out-of-date information about akamai's requirements. john is right, i should have done my homework before posting. From owner-namedroppers@ops.ietf.org Thu Apr 8 10:04:53 2010 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 4B3913A69AD; Thu, 8 Apr 2010 10:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.224 X-Spam-Level: X-Spam-Status: No, score=0.224 tagged_above=-999 required=5 tests=[AWL=-1.140, 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 hPv9HgwACCTU; Thu, 8 Apr 2010 10:04:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F3EFA3A6800; Thu, 8 Apr 2010 10:04:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzv6a-0003vn-FR for namedroppers-data0@psg.com; Thu, 08 Apr 2010 17:01:24 +0000 Received: from [209.85.212.52] (helo=mail-vw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzv6X-0003vR-JW for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 17:01:21 +0000 Received: by vws11 with SMTP id 11so76536vws.11 for ; Thu, 08 Apr 2010 10:01:20 -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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1TlLMPCX25JdX/73OCEnTgJhbmMiKN9QBy6O425tFQI=; b=fWlkfoI1fceZRM5MJPqUp+9I1xSFOpsyuyjJFUvzb5iGFg/BF+7sLPbiqa81L+TUvo N6ownzhQFmpVFPo99vhNFyB1ryVal1BiJ37PIQx2R4fqVsmJYiwlQkTxmFEgSxnmS1vY i0kwIue0sa2oLE72fNQ89JKWYRm8SEzWwCnbk= 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 :cc:content-type:content-transfer-encoding; b=FwGKXqER6zJEsEs9+ZBQ0P6x9LTJ1ZcCybIfmgj60NUpH+WOwlv1ZfXGzD/lpYm/g+ X3uOSF/PYwcgiK3wDR8nrc+U/cLjhEPsrml1n3Ep3ASbznca1+mEf+IqA3bpGj6/dgGv p0x7sI1/tL4P5MY9rMKS13oGT0YharvcwdO0s= MIME-Version: 1.0 Received: by 10.220.92.196 with HTTP; Thu, 8 Apr 2010 10:01:20 -0700 (PDT) In-Reply-To: References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> Date: Thu, 8 Apr 2010 10:01:20 -0700 Received: by 10.220.107.26 with SMTP id z26mr264206vco.151.1270746080123; Thu, 08 Apr 2010 10:01:20 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 From: Ted Hardie To: Edward Lewis Cc: 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: Ed, Please forgive the top posting. In the text below you are mixing an analys= is of the protocol, the information flow implicit in the query stream, and your personal take on whether or not the information is "valuable" for some pretty mixed set o= f what "value" might mean. The discussion to date has covered much of this ground, but your posting re-mixes pieces that Paul, David, and I have tried to pull apart. That's a bit frustrating. Since you are interested in helping out with this draft, perhaps you can start from the other end. Why is this proposal of interest to you, and what benefit do you see to the DNS? Maybe if we start back there, we can see other ways to get to that goal. regards, Ted On Thu, Apr 8, 2010 at 7:42 AM, Edward Lewis wrote: > At 15:19 -0700 4/7/10, Ted Hardie wrote: >> >> It's pretty obvious I don't agree with at least some folks on >> the requirements. =A0I think this should be opt-in; that's a non-require= ment >> or too high a deployment barrier for others. =A0So it's not 95% of my >> personal requirements. > > In the effort to help with the next version of the edns-client-ip draft, = I > am having a hard time understanding why privacy is a concern. =A0Reading = the > messages I realize that there's a fear that if the authority servers know > who's asking, then the authority servers have a better grasp on who is > asking for information. =A0What I mean by "having a hard time understandi= ng" > is more a reflection that I think the concern, as I am reading it, is > unfounded. =A0I am saying this because it could be I'm just not seeing th= e > issue. =A0And until then I wouldn't know what to recommend be included in= the > draft. > > In today's DNS, if you ask for information from a recursive server, that > server has the ability to record who asked for what at a fine level of > granularity. =A0The initiator could use different recursive servers to tr= y to > "hide" a pattern of access, so one server might not see all the queries. = =A0At > the authority server, what becomes apparent is the IP address of the > recursive servers, but at a much lower granularity - not each query that = is > issued but only for queries that are cache misses. =A0If the TTL of an RR= set > is long, a lot of the end queries won't make it to the authority. > > There are many factors to consider. =A0But taking the example of an enum > query, which identifies an E.164 telephone number that is potentially bei= ng > contacted, what is going on? =A0There are those that propose the TTLs of > "enum" records (typically NAPTR) be kept short to provide the > real-time-iness of the current telephone system. =A0This would mean more > cache-misses and therefore more of a reflection of actual initiator query > activity. =A0(Are we talking a single initiator or multiple?) > > Without edns-client-ip, it is still possible to determine the recursive > servers sending the query, using non-DNS means. =A0Assuming there is lega= l > leverage, an authority could approach/force operators to monitor the > incoming requests to get closer to the source. =A0(If the operator doesn'= t > cooperate, the authority could simply not respond to the recursive server= . > =A0But if things are that sinister, why doesn't the authority just go aft= er > the holder of the telephone number and pursue actions there?) =A0National > jurisdictions being what they are, one can dream up a lot of spy novel > situations - which is what makes it hard to quantify the underlying DNS > protocol issue at hand. > > If the situation is not as cat-and-mouse as a political cloak-and-dagger > mystery, for example, merely trying to capture demographic data about > shoppers, then you have a situation where the recursive cache operator ha= s a > competitive advantage over the authority server. =A0Revealing the client = IP > has to meeting with some incentive by the authority server. =A0(The gener= al > lack of this is why this is not a general purpose feature.) > > If the desire is to hide query patterns even if extreme measures are take= n, > it is still possible to create "reasonable doubt" about the actual source > via a series of forwarders. =A0If one is willing to do this, then they ar= e > also not likely to take advantage of a tailored response based on their > topology. =A0(Or have that provided at the application management layer.) > > My misunderstanding of the privacy concern boils down to - with > edns-client-ip the authority server will only see the sources that cause > cache misses from intermediates that are willing to reveal where the quer= y > came from. =A0If the intermediate is topologically co-located with the cl= ient, > then there's no need to pass this on, and therefore quite useless. =A0If = the > intermediate is offering some sort of anonymization (wsat? =3D would scra= bble > allow that?) then there's no incentive to send the edns-client-ip. =A0Onl= y if > the intermediate wants to mimic the authority's tailoring service is ther= e > incentive to reveal something about the query source. =A0And even then on= ly to > a fuzzy level of detail (probably never more than a /24 of IPv4 because t= hat > seems to be the lower limit of what policy carries in an exterior gateway > protocol. > > -- > -=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-=3D-=3D= - > Edward Lewis > NeuStar =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0You can leave a voice mess= age at +1-571-434-5468 > > Wouldn't it be nice if all of the definitions of equivalence were the sam= e? > > From owner-namedroppers@ops.ietf.org Thu Apr 8 10:07:13 2010 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 B13B43A6999; Thu, 8 Apr 2010 10:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.515 X-Spam-Level: X-Spam-Status: No, score=-0.515 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 37FvZn+a7rYv; Thu, 8 Apr 2010 10:07:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 341C33A6954; Thu, 8 Apr 2010 10:07:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzv9P-0004Ix-Ei for namedroppers-data0@psg.com; Thu, 08 Apr 2010 17:04:19 +0000 Received: from [209.85.212.52] (helo=mail-vw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nzv9M-0004IX-W0 for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 17:04:17 +0000 Received: by vws11 with SMTP id 11so77885vws.11 for ; Thu, 08 Apr 2010 10:04:16 -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:received:message-id:subject:from:to:cc:content-type; bh=yy7Fwh8eV/zhpiIzkCeZ9ztvCCdYP85TOgE5wdUiSA4=; b=rKXjU+IQC9igKCZATMnGAqb91EECP2CKI67V/HUtFgENgmXiRfpVm1u0Ey75WhzAvC gsoJpJrZovd32ZF/fhb6SFdeyRfE018u45wj7R5D3A7pSgIdsGZZ7Yl6zG8+af5xvp8Q p6NebsjlIHt6l2wDm/LCdEt+mKQU3a4jV+gmA= 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 :cc:content-type; b=fvDN7JREbzbDVKRQXPy/AH1c/VWTo6Dy9D8AxlsV5FTAKoc9py1keHVQtwFLpMFwrV Vkyn/TJBurHNe6PLM1rRSZePELx3CKUV40LuLpjnqHlcEqmOZioayyW2RWz/IVqOi5n1 kCJGoyNyDzfco45CBc+QsSDzpp1ug0sfTSj90= MIME-Version: 1.0 Received: by 10.220.92.196 with HTTP; Thu, 8 Apr 2010 10:04:15 -0700 (PDT) In-Reply-To: References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> Date: Thu, 8 Apr 2010 10:04:15 -0700 Received: by 10.220.62.134 with SMTP id x6mr302875vch.48.1270746255724; Thu, 08 Apr 2010 10:04:15 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 From: Ted Hardie To: Nicholas Weaver Cc: Edward Lewis , 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: Hi Nick, On Thu, Apr 8, 2010 at 8:20 AM, Nicholas Weaver wrote: > > Additionally, and key, DNS is not used in a vaccume as an information service, but is almost exclusively used as a guideline to actually initiate contact, or as a database lookup after contact has been initiated the other way. > > So even in the E.164 example, a DNS lookup is followed by an actual contact from the initiator to the recipient, so the only privacy leakage occurs when the system running the directory (DNS) does not also have control over the final recipient data. It depends entirely on the protocol flow of the application as to whether or not the initiated contact leaks any information or not. With a SIP proxy infrastructure it may not (if you are willing to take a hit on poor performance). With other proxy infrastructure it may also avoid this. > > > Thus in nation-state type examples, the nation state can generally get the exact information from the final contact (and if a nation-state adversary is your threat model, you better be using TOR which makes all these issues moot). > > Likewise, for commercial privacy: if you are contacting web service X, who cares that the slash /24 you are using apppears in service-provider X's DNS authority server logs, when your actual IP is in the HTTP logs? > > > Thus its clear that the ONLY information leakage which can occur, and minor though it is, is when the authority server does NOT have any access to the communication itself. > No, it leaks new information when the communication path from the initiator is otherwise not direct--in any case with an application-layer proxy, in other words. regards, Ted From owner-namedroppers@ops.ietf.org Thu Apr 8 10:19:20 2010 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 9B8EC3A696E; Thu, 8 Apr 2010 10:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.583 X-Spam-Level: X-Spam-Status: No, score=-4.583 tagged_above=-999 required=5 tests=[AWL=0.465, 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 XLcVI0R-kO-a; Thu, 8 Apr 2010 10:19:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B5D33A6977; Thu, 8 Apr 2010 10:18:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzvK7-000608-UL for namedroppers-data0@psg.com; Thu, 08 Apr 2010 17:15:23 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzvK5-0005zU-9e for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 17:15:21 +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 o38HFHui013493; Thu, 8 Apr 2010 10:15:18 -0700 (PDT) Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Thu, 8 Apr 2010 13:15:16 -0400 Cc: Nicholas Weaver , Edward Lewis , namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <360DA6F9-2CC2-4F13-9E83-6B710993A502@ICSI.Berkeley.EDU> References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> To: Ted Hardie X-Mailer: Apple Mail (2.1078) 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 Apr 8, 2010, at 1:04 PM, Ted Hardie wrote: > Hi Nick, >=20 > On Thu, Apr 8, 2010 at 8:20 AM, Nicholas Weaver > wrote: >=20 >>=20 >> Additionally, and key, DNS is not used in a vaccume as an information = service, but is almost exclusively used as a guideline to actually = initiate contact, or as a database lookup after contact has been = initiated the other way. >>=20 >> So even in the E.164 example, a DNS lookup is followed by an actual = contact from the initiator to the recipient, so the only privacy leakage = occurs when the system running the directory (DNS) does not also have = control over the final recipient data. >=20 > It depends entirely on the protocol flow of the application as to > whether or not the > initiated contact leaks any information or not. With a SIP proxy > infrastructure it > may not (if you are willing to take a hit on poor performance). With > other proxy > infrastructure it may also avoid this. You forward the DNS through the same proxy infrastructure, or through = another proxy infrastructure! >>=20 >> Thus in nation-state type examples, the nation state can generally = get the exact information from the final contact (and if a nation-state = adversary is your threat model, you better be using TOR which makes all = these issues moot). >>=20 >> Likewise, for commercial privacy: if you are contacting web service = X, who cares that the slash /24 you are using apppears in = service-provider X's DNS authority server logs, when your actual IP is = in the HTTP logs? >>=20 >>=20 >> Thus its clear that the ONLY information leakage which can occur, and = minor though it is, is when the authority server does NOT have any = access to the communication itself. >>=20 > No, it leaks new information when the communication path from the > initiator is otherwise > not direct--in any case with an application-layer proxy, in other = words. If you are using an application-layer proxy, send the DNS through the = same proxy or another proxy. To not do so defeats much of the purpose = of using a proxy if the concern is privacy, no matter what the DNS = resolver does, because you are leaking the information to the recursive = resolver and the inplicit information from the resolver to the = authority! The "but a proxy" case is IMO, a red herring: our job shouldn't be to = protect stupid from very minor threats, when stupid is obviously NOT = TRYING TO PROTECT ITSELF (by using the same proxy for DNS as data). From owner-namedroppers@ops.ietf.org Thu Apr 8 10:21:47 2010 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 D7D973A6898; Thu, 8 Apr 2010 10:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 QrIE2y3RE0Sp; Thu, 8 Apr 2010 10:21:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 68A1728C11D; Thu, 8 Apr 2010 10:19:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzvLe-0006Gq-5m for namedroppers-data0@psg.com; Thu, 08 Apr 2010 17:16:58 +0000 Received: from [38.229.66.8] (helo=obelisk11.ord01.cymru.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzvLa-0006GW-8i for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 17:16:54 +0000 Received: from t61p (vpn-21-37.svcs.iad01.cymru.com [192.168.21.37]) by obelisk11.ord01.cymru.com (Postfix) with ESMTP id 4C20CB0176 for ; Thu, 8 Apr 2010 17:16:53 +0000 (GMT) Date: Thu, 8 Apr 2010 12:16:52 -0500 From: John Kristoff To: namedroppers@ops.ietf.org Subject: [dnsext] Comments on draft-vandergaast-edns-client-ip-00 Message-ID: <20100408121652.722c0345@t61p> X-Mailer: Claws Mail Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: First a bit of history... In 2006 when draft-eastlake-dnsext-cookies-00.txt came out and while I was at Neustar, I experimented with putting RRs in the additional section of a query said as much on list. What I didn't put on the list, but did talk to at least a couple people at the time about (hi Roy! :-) was to put the original querier address in there. I think I mentioned it to Paul or somebody at the Chicago dns-ops meeting and that's when I realized I needed to learn more about EDNS0. That idea was spawned even earlier while I was doing netops at Northwestern. We monitored queries at our resolvers and used that info to help find problems with source hosts. Often however, we got queries from other recursive servers. When those servers were passing on something that was a problem, we really would have liked a DNS-based information pathway to know the original querier. The point is that there may be significant interest in this for reasons other than synthesized answers. Coincidentally, Roy then preceded to tell me about a traceroute idea he had. Roy, perhaps its time to dust that off? A few comments about the draft now... The draft allows for truncating the original querier address using an "arbitrary" netmask, which might help alleviate some privacy concerns, but the original querier has no control and likely no way to verify how it is used to authoritative servers they do not control. Not that it matters, but the draft says the address SHOULD be truncated, but gives no guidance on how to come up with a reasonable mask and I'm not sure it even could. The solution to end users in the 8.1 section is not going to be sufficient either, since an implementation could completely ignore it. Maybe just make it optional and if its not used set the mask to all zeros? And I doubt the so The draft calls itself "Client IP information", but only specifics a source address and a netmask. It could have specified additional information that would have potentially provided additional insight into the original querier, such as the id, source port or client-ip path. Maybe the undocumented implementations do? What are the drawbacks or advantages of other IP or IP protocol fields being conveyed as well? I have a sinking feeling there are new some attack vectors made possible with this draft, and if I do a more rigorous analysis of the draft and find any I'll be back. One, which may be partially solved by implementation is cache enumeration. That is, knowing who is talking to a cache and querying for what may be possible by forging client-ip detail. Regarding the privacy concerns, I think those are very legitimate concerns and users should be at least aware that their DNS queries might be seen by others than their recursive server operator. However, from a technical standpoint, I'm not sure this seem sufficient to prevent this work from going forward. It might warrant a "edns-client-ip is harmful" response as Paul appears poised to do. John From owner-namedroppers@ops.ietf.org Thu Apr 8 10:40:35 2010 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 03EA53A6845; Thu, 8 Apr 2010 10:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.671 X-Spam-Level: X-Spam-Status: No, score=0.671 tagged_above=-999 required=5 tests=[AWL=1.166, 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 FyfkTs6qgOwD; Thu, 8 Apr 2010 10:40:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8EC2E3A68B6; Thu, 8 Apr 2010 10:39:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzvcM-0008tE-FJ for namedroppers-data0@psg.com; Thu, 08 Apr 2010 17:34:14 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzvcJ-0008so-RC for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 17:34:12 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o38HXmRT002304; Thu, 8 Apr 2010 13:34:03 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Thu, 08 Apr 2010 13:34:08 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 08 Apr 2010 13:34:08 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> Date: Thu, 8 Apr 2010 13:33:39 -0400 To: Ted Hardie From: Edward Lewis Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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:01 -0700 4/8/10, Ted Hardie wrote: >Please forgive the top posting. In the text below you are mixing an analysis >of FWIW, I prefer top posting... >That's a bit frustrating. And from that discussion I deduced that the privacy issue is a red herring. >Since you are interested in helping out with this draft, perhaps you >can start from the other end. The draft is still an individual draft and I work with some of the authors, so I'm talking with them. That's why I am inquiring about the so-called privacy issue. (As I said, I think it isn't, I'm trying to figure out why others think it is and what the implications are.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From ailerons8@jelany.com Thu Apr 8 12:26:00 2010 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 880123A6A13; Thu, 8 Apr 2010 12:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -61.405 X-Spam-Level: X-Spam-Status: No, score=-61.405 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_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_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, 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, 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 igkJTnED8j-w; Thu, 8 Apr 2010 12:25:59 -0700 (PDT) Received: from 189-19-15-86.dsl.telesp.net.br (189-19-15-86.dsl.telesp.net.br [189.19.15.86]) by core3.amsl.com (Postfix) with ESMTP id 14E273A6AFA; Thu, 8 Apr 2010 12:25:58 -0700 (PDT) Received: from 189.19.15.86 by 2035042954.pamx1.hotmail.com; Thu, 8 Apr 2010 16:24:22 -0300 Message-ID: <000d01cad751$17a03aa0$6400a8c0@ailerons8> From: dnsext-archive@ietf.org To: Subject: A year ago you came to Russia, I remember you, write me! Date: Thu, 8 Apr 2010 16:24:22 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD751.17A03AA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD751.17A03AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I can do for you is - what can not no girl! Please Visit ------=_NextPart_000_0007_01CAD751.17A03AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I can do for you is - what can not no girl! Please Visit
<= /BODY> ------=_NextPart_000_0007_01CAD751.17A03AA0-- From owner-namedroppers@ops.ietf.org Thu Apr 8 12:46:25 2010 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 4B1FD28C10F; Thu, 8 Apr 2010 12:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.873 X-Spam-Level: X-Spam-Status: No, score=-99.873 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, 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 hR+1CRVucJ94; Thu, 8 Apr 2010 12:46:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4BA8528C0CF; Thu, 8 Apr 2010 12:46:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzxZV-000P5K-QA for namedroppers-data0@psg.com; Thu, 08 Apr 2010 19:39:25 +0000 Received: from [74.125.121.35] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzxZT-000P51-AH for namedroppers@ops.ietf.org; Thu, 08 Apr 2010 19:39:23 +0000 Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o38JdKhO032442 for ; Thu, 8 Apr 2010 21:39:21 +0200 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1270755561; bh=l/NEaqK6iz/5pD2t/1SPPLOC4U0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=B+un11qfq3JAn5L2qKGTOJOAYa8cT4lraDSjRuh0oRPta0pSYQ1SLnd/EXxdhXvaz VyoUuoWPwnGncN4wP4O2A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=GVty4uCvMPZtz83X/ihhiLYJAiCz69uv0Rj7G9NfjvdokYA3SLaEyZ2ZTMFM5l2M3 YNJtmLqfUnXcwtlg26rSA== Received: from fxm5 (fxm5.prod.google.com [10.184.13.5]) by wpaz33.hot.corp.google.com with ESMTP id o38JdB82017108 for ; Thu, 8 Apr 2010 12:39:19 -0700 Received: by fxm5 with SMTP id 5so2455271fxm.29 for ; Thu, 08 Apr 2010 12:39:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.102.7.21 with HTTP; Thu, 8 Apr 2010 12:39:18 -0700 (PDT) In-Reply-To: References: <4BB3E324.2050207@isc.org> <28432.1270141110@nsa.vix.com> <42864.1270583728@nsa.vix.com> <89801.1270653567@nsa.vix.com> Date: Thu, 8 Apr 2010 20:39:18 +0100 Received: by 10.102.240.16 with SMTP id n16mr348034muh.100.1270755558658; Thu, 08 Apr 2010 12:39:18 -0700 (PDT) Message-ID: Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries From: Wilmer van der Gaast To: Nicholas Weaver Cc: Paul Vixie , Ted Hardie , David Ulevitch , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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 April 2010 18:09, Nicholas Weaver wrote: >> third, this proposal assumes that triangulation is a predictor of either >> performance or reachability or locality. =A0if somebody proxies their DN= S in >> one direction and proxies their HTTP in another direction, or if distanc= e >> A-C is completely unrelated to distances A-B and B-C due to wormholes, t= hen >> locality logic will either add no value or actually subtract value. =A0t= his >> kind of differential proxying and these kinds of wormholes are already q= uite >> common and there's no reason to expect a reduction here, not even based = on >> theoretical advantages offered indirectly by the proposal we're discussi= ng. > The cases where people put their path through pervented proxying should n= ot be a major concern, its VERY rare, and such deliberate perverted cases c= ould instead relay their DNS through the same path. > Also, IMHO edns-client-ip, if anything, actually improves this situation. Right now if people have setups like this, it can cause problems with geo-sensitive DNS authorities. This is not a new problem introduced by edns-client-ip. edns-client-ip does, however, allow people to put the IP address from where subsequent connections will be originated in the option if they can predict it. Cheers, --=20 Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From sedatestjv3@siliconefamily.j-net.ru Thu Apr 8 12:49:53 2010 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 10AC63A6995; Thu, 8 Apr 2010 12:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.604 X-Spam-Level: X-Spam-Status: No, score=-86.604 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, 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, 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 xU8juKxBmB3J; Thu, 8 Apr 2010 12:49:52 -0700 (PDT) Received: from ac-217-129-181-155.netvisao.pt (ac-217-129-181-155.netvisao.pt [217.129.181.155]) by core3.amsl.com (Postfix) with ESMTP id D707028C126; Thu, 8 Apr 2010 12:49:50 -0700 (PDT) Received: from 217.129.181.155 by mx2.j-net.ru; Thu, 8 Apr 2010 20:49:04 +0000 Date: Thu, 8 Apr 2010 20:49:04 +0000 From: dnsext-archive@ietf.org Subject: 7 new messages from ladies for you (dating) To: Message-ID: <000d01cad754$8b24cd30$6400a8c0@sedatestjv3> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal I can do for you is - what can not no girl! http://loudspeak38.spaces.live.com From sedatestjv3@siliconefamily.j-net.ru Thu Apr 8 12:49:53 2010 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 10AC63A6995; Thu, 8 Apr 2010 12:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.604 X-Spam-Level: X-Spam-Status: No, score=-86.604 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, 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, 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 xU8juKxBmB3J; Thu, 8 Apr 2010 12:49:52 -0700 (PDT) Received: from ac-217-129-181-155.netvisao.pt (ac-217-129-181-155.netvisao.pt [217.129.181.155]) by core3.amsl.com (Postfix) with ESMTP id D707028C126; Thu, 8 Apr 2010 12:49:50 -0700 (PDT) Received: from 217.129.181.155 by mx2.j-net.ru; Thu, 8 Apr 2010 20:49:04 +0000 Date: Thu, 8 Apr 2010 20:49:04 +0000 From: dnsext-archive@ietf.org Subject: 7 new messages from ladies for you (dating) To: Message-ID: <000d01cad754$8b24cd30$6400a8c0@sedatestjv3> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal I can do for you is - what can not no girl! http://loudspeak38.spaces.live.com From lu@dmd.net.au Thu Apr 8 14:29:26 2010 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 A711428C11D; Thu, 8 Apr 2010 14:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.612 X-Spam-Level: X-Spam-Status: No, score=-69.612 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_DSL=1.129, HTML_MESSAGE=0.001, PLING_QUERY=1.39, 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_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 T1Zv4dhRuCAq; Thu, 8 Apr 2010 14:29:26 -0700 (PDT) Received: from 189-246-222-201.adsl.terra.cl (189-246-222-201.adsl.terra.cl [201.222.246.189]) by core3.amsl.com (Postfix) with ESMTP id DB3CD28C114; Thu, 8 Apr 2010 14:29:23 -0700 (PDT) Received: from 201.222.246.189 by dmd.net.au; Thu, 8 Apr 2010 17:28:57 -0400 Message-ID: <000d01cad762$7f179820$6400a8c0@lu> From: dnsext-archive@ietf.org To: Subject: Hi sweety! Remember me? Date: Thu, 8 Apr 2010 17:28:57 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD762.7F179820" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2741.2600 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD762.7F179820 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hundreds of profiles of Russian hotties. Click Here ------=_NextPart_000_0007_01CAD762.7F179820 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hundreds of profiles of Russian hotties. Click Here
------=_NextPart_000_0007_01CAD762.7F179820-- From dnsop-bounces@ietf.org Thu Apr 8 14:29:29 2010 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6ABA28C175 for ; Thu, 8 Apr 2010 14:29:28 -0700 (PDT) Subject: The results of your email commands From: dnsop-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0567020464==" Message-ID: Date: Thu, 08 Apr 2010 14:29:27 -0700 Precedence: bulk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF DNSOP WG mailing list X-List-Administrivia: yes Sender: dnsop-bounces@ietf.org Errors-To: dnsop-bounces@ietf.org --===============0567020464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Done. --===============0567020464== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: dnsop-request@core3.amsl.com Delivered-To: dnsop-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A711428C11D; Thu, 8 Apr 2010 14:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.612 X-Spam-Level: X-Spam-Status: No, score=-69.612 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_DSL=1.129, HTML_MESSAGE=0.001, PLING_QUERY=1.39, 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_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 T1Zv4dhRuCAq; Thu, 8 Apr 2010 14:29:26 -0700 (PDT) Received: from 189-246-222-201.adsl.terra.cl (189-246-222-201.adsl.terra.cl [201.222.246.189]) by core3.amsl.com (Postfix) with ESMTP id DB3CD28C114; Thu, 8 Apr 2010 14:29:23 -0700 (PDT) Received: from 201.222.246.189 by dmd.net.au; Thu, 8 Apr 2010 17:28:57 -0400 Message-ID: <000d01cad762$7f179820$6400a8c0@lu> From: dnsext-archive@ietf.org To: Subject: Hi sweety! Remember me? Date: Thu, 8 Apr 2010 17:28:57 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD762.7F179820" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2741.2600 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD762.7F179820 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hundreds of profiles of Russian hotties. Click Here ------=_NextPart_000_0007_01CAD762.7F179820 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hundreds of profiles of Russian hotties. Click Here
------=_NextPart_000_0007_01CAD762.7F179820-- --===============0567020464==-- From diffserv-interest-bounces@ietf.org Thu Apr 8 14:29:29 2010 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF7928C182 for ; Thu, 8 Apr 2010 14:29:29 -0700 (PDT) Subject: The results of your email commands From: diffserv-interest-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1378595235==" Message-ID: Date: Thu, 08 Apr 2010 14:29:27 -0700 Precedence: bulk X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.1.9 List-Id: Differentiated services general discussion X-List-Administrivia: yes Sender: diffserv-interest-bounces@ietf.org Errors-To: diffserv-interest-bounces@ietf.org --===============1378595235== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Done. --===============1378595235== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: diffserv-interest-request@core3.amsl.com Delivered-To: diffserv-interest-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A711428C11D; Thu, 8 Apr 2010 14:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.612 X-Spam-Level: X-Spam-Status: No, score=-69.612 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_DSL=1.129, HTML_MESSAGE=0.001, PLING_QUERY=1.39, 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_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 T1Zv4dhRuCAq; Thu, 8 Apr 2010 14:29:26 -0700 (PDT) Received: from 189-246-222-201.adsl.terra.cl (189-246-222-201.adsl.terra.cl [201.222.246.189]) by core3.amsl.com (Postfix) with ESMTP id DB3CD28C114; Thu, 8 Apr 2010 14:29:23 -0700 (PDT) Received: from 201.222.246.189 by dmd.net.au; Thu, 8 Apr 2010 17:28:57 -0400 Message-ID: <000d01cad762$7f179820$6400a8c0@lu> From: dnsext-archive@ietf.org To: Subject: Hi sweety! Remember me? Date: Thu, 8 Apr 2010 17:28:57 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD762.7F179820" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2741.2600 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD762.7F179820 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hundreds of profiles of Russian hotties. Click Here ------=_NextPart_000_0007_01CAD762.7F179820 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hundreds of profiles of Russian hotties. Click Here
------=_NextPart_000_0007_01CAD762.7F179820-- --===============1378595235==-- From lu@dmd.net.au Thu Apr 8 14:29:26 2010 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 A711428C11D; Thu, 8 Apr 2010 14:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.612 X-Spam-Level: X-Spam-Status: No, score=-69.612 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_DSL=1.129, HTML_MESSAGE=0.001, PLING_QUERY=1.39, 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_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 T1Zv4dhRuCAq; Thu, 8 Apr 2010 14:29:26 -0700 (PDT) Received: from 189-246-222-201.adsl.terra.cl (189-246-222-201.adsl.terra.cl [201.222.246.189]) by core3.amsl.com (Postfix) with ESMTP id DB3CD28C114; Thu, 8 Apr 2010 14:29:23 -0700 (PDT) Received: from 201.222.246.189 by dmd.net.au; Thu, 8 Apr 2010 17:28:57 -0400 Message-ID: <000d01cad762$7f179820$6400a8c0@lu> From: dnsext-archive@ietf.org To: Subject: Hi sweety! Remember me? Date: Thu, 8 Apr 2010 17:28:57 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD762.7F179820" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2741.2600 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD762.7F179820 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hundreds of profiles of Russian hotties. Click Here ------=_NextPart_000_0007_01CAD762.7F179820 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hundreds of profiles of Russian hotties. Click Here
------=_NextPart_000_0007_01CAD762.7F179820-- From coagulated@tracor-europe.com Thu Apr 8 17:33:54 2010 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 D3F483A67B2; Thu, 8 Apr 2010 17:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.309 X-Spam-Level: X-Spam-Status: No, score=-75.309 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_FR=0.35, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, 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 xYHoL+FdWVIq; Thu, 8 Apr 2010 17:33:54 -0700 (PDT) Received: from 81-65-13-160.rev.numericable.fr (81-65-13-160.rev.numericable.fr [81.65.13.160]) by core3.amsl.com (Postfix) with ESMTP id EE5993A659A; Thu, 8 Apr 2010 17:33:53 -0700 (PDT) Received: from 81.65.13.160 by mx00.1and1.fr; Fri, 9 Apr 2010 02:33:23 +0100 Message-ID: <000d01cad77c$43554a20$6400a8c0@coagulated> From: dnsext-archive@lists.ietf.org To: Subject: Want to know what the real Russian girls love and warmth? Date: Fri, 9 Apr 2010 02:33:23 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD77C.43554A20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2900.2869 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD77C.43554A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Russian beauties are waiting. Please Visit ------=_NextPart_000_0007_01CAD77C.43554A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Russian beauties are waiting. Please Visit
------=_NextPart_000_0007_01CAD77C.43554A20-- From dnsop-bounces@ietf.org Thu Apr 8 17:33:56 2010 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86EE93A659A for ; Thu, 8 Apr 2010 17:33:56 -0700 (PDT) Subject: The results of your email commands From: dnsop-bounces@ietf.org To: dnsext-archive@lists.ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0549268489==" Message-ID: Date: Thu, 08 Apr 2010 17:33:55 -0700 Precedence: bulk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF DNSOP WG mailing list X-List-Administrivia: yes Sender: dnsop-bounces@ietf.org Errors-To: dnsop-bounces@ietf.org --===============0549268489== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Done. --===============0549268489== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: dnsop-request@core3.amsl.com Delivered-To: dnsop-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F483A67B2; Thu, 8 Apr 2010 17:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.309 X-Spam-Level: X-Spam-Status: No, score=-75.309 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_FR=0.35, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, 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 xYHoL+FdWVIq; Thu, 8 Apr 2010 17:33:54 -0700 (PDT) Received: from 81-65-13-160.rev.numericable.fr (81-65-13-160.rev.numericable.fr [81.65.13.160]) by core3.amsl.com (Postfix) with ESMTP id EE5993A659A; Thu, 8 Apr 2010 17:33:53 -0700 (PDT) Received: from 81.65.13.160 by mx00.1and1.fr; Fri, 9 Apr 2010 02:33:23 +0100 Message-ID: <000d01cad77c$43554a20$6400a8c0@coagulated> From: dnsext-archive@lists.ietf.org To: Subject: Want to know what the real Russian girls love and warmth? Date: Fri, 9 Apr 2010 02:33:23 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD77C.43554A20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2900.2869 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD77C.43554A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Russian beauties are waiting. Please Visit ------=_NextPart_000_0007_01CAD77C.43554A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Russian beauties are waiting. Please Visit
------=_NextPart_000_0007_01CAD77C.43554A20-- --===============0549268489==-- From coagulated@tracor-europe.com Thu Apr 8 17:33:54 2010 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 D3F483A67B2; Thu, 8 Apr 2010 17:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.309 X-Spam-Level: X-Spam-Status: No, score=-75.309 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_FR=0.35, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, 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 xYHoL+FdWVIq; Thu, 8 Apr 2010 17:33:54 -0700 (PDT) Received: from 81-65-13-160.rev.numericable.fr (81-65-13-160.rev.numericable.fr [81.65.13.160]) by core3.amsl.com (Postfix) with ESMTP id EE5993A659A; Thu, 8 Apr 2010 17:33:53 -0700 (PDT) Received: from 81.65.13.160 by mx00.1and1.fr; Fri, 9 Apr 2010 02:33:23 +0100 Message-ID: <000d01cad77c$43554a20$6400a8c0@coagulated> From: dnsext-archive@lists.ietf.org To: Subject: Want to know what the real Russian girls love and warmth? Date: Fri, 9 Apr 2010 02:33:23 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD77C.43554A20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2900.2869 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD77C.43554A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Russian beauties are waiting. Please Visit ------=_NextPart_000_0007_01CAD77C.43554A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Russian beauties are waiting. Please Visit
------=_NextPart_000_0007_01CAD77C.43554A20-- From owner-namedroppers@ops.ietf.org Fri Apr 9 01:53:38 2010 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 6F2053A697B; Fri, 9 Apr 2010 01:53:38 -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 U5ZL5Gh6BtmT; Fri, 9 Apr 2010 01:53:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F00528C0CE; Fri, 9 Apr 2010 01:53:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O09sF-000L6I-3J for namedroppers-data0@psg.com; Fri, 09 Apr 2010 08:47:35 +0000 Received: from [209.85.210.184] (helo=mail-yx0-f184.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O09sD-000L3R-1b for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 08:47:33 +0000 Received: by yxe14 with SMTP id 14so1578701yxe.5 for ; Fri, 09 Apr 2010 01:47:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Fri, 9 Apr 2010 01:47:31 -0700 (PDT) Date: Fri, 9 Apr 2010 01:47:31 -0700 Received: by 10.101.197.32 with SMTP id z32mr1935890anp.201.1270802851466; Fri, 09 Apr 2010 01:47:31 -0700 (PDT) Message-ID: Subject: [dnsext] Reserved EDNS0 option codes for private use From: Matthew Dempsky To: IETF DNSEXT WG 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: According to http://www.iana.org/assignments/dns-parameters, there are no EDNS0 option codes reserved for private use. As every other 16-bit DNS parameter reserves 65280--65534 for private use, I suggest the same range be similarly reserved for EDNS0 option codes. From droopyo36@peoplesbanktrust.net Fri Apr 9 02:33:21 2010 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 6A17F3A6782; Fri, 9 Apr 2010 02:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -57.148 X-Spam-Level: X-Spam-Status: No, score=-57.148 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_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_MESSAGE=0.001, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_ADULT2=1.42, SARE_RECV_SPAM_DOMN02=1.666, 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 wAkLnNT76ADD; Fri, 9 Apr 2010 02:33:20 -0700 (PDT) Received: from 200-232-193-108.dsl.telesp.net.br (200-232-193-108.dsl.telesp.net.br [200.232.193.108]) by core3.amsl.com (Postfix) with ESMTP id 675DF3A6A72; Fri, 9 Apr 2010 02:32:34 -0700 (PDT) Received: from 200.232.193.108 by mail.peoplesbanktrust.net; Fri, 9 Apr 2010 06:32:28 -0300 Message-ID: <000d01cad7c7$923dae20$6400a8c0@droopyo36> From: dnsext-archive@ietf.org To: Subject: Russian dating site Date: Fri, 9 Apr 2010 06:32:28 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD7C7.923DAE20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.3790.1830 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD7C7.923DAE20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am your Russian pussy - you remember my nickname? Please Visit ------=_NextPart_000_0007_01CAD7C7.923DAE20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am your Russian pussy - you remember my nicknam= e? Please Visit
------=_NextPart_000_0007_01CAD7C7.923DAE20-- From zoomingjfe26@cbgb.net Fri Apr 9 02:33:22 2010 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 9B08D3A6A72 for ; Fri, 9 Apr 2010 02:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -57.178 X-Spam-Level: X-Spam-Status: No, score=-57.178 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_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_MESSAGE=0.001, PLING_QUERY=1.39, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, 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 4nG9-F3aYxX9 for ; Fri, 9 Apr 2010 02:33:21 -0700 (PDT) Received: from 200-232-193-108.dsl.telesp.net.br (200-232-193-108.dsl.telesp.net.br [200.232.193.108]) by core3.amsl.com (Postfix) with ESMTP id 80F763A6AEE for ; Fri, 9 Apr 2010 02:32:34 -0700 (PDT) Received: from 200.232.193.108 by sitemail.everyone.net; Fri, 9 Apr 2010 06:32:29 -0300 Message-ID: <000d01cad7c7$92a91a20$6400a8c0@zoomingjfe26> From: dnsext-archive@lists.ietf.org To: Subject: Hi sweety! Remember me? Date: Fri, 9 Apr 2010 06:32:29 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD7C7.92A91A20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2800.1807 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD7C7.92A91A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you are disappointed in its second half, bold, come in! Visit Our Site ------=_NextPart_000_0007_01CAD7C7.92A91A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you are disappointed in its second half, bold,= come in! Visit Our Site
------=_NextPart_000_0007_01CAD7C7.92A91A20-- From dnsop-bounces@ietf.org Fri Apr 9 02:33:23 2010 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3EED3A6A72 for ; Fri, 9 Apr 2010 02:33:22 -0700 (PDT) Subject: The results of your email commands From: dnsop-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0912227405==" Message-ID: Date: Fri, 09 Apr 2010 02:33:22 -0700 Precedence: bulk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF DNSOP WG mailing list X-List-Administrivia: yes Sender: dnsop-bounces@ietf.org Errors-To: dnsop-bounces@ietf.org --===============0912227405== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Done. --===============0912227405== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: dnsop-request@core3.amsl.com Delivered-To: dnsop-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A17F3A6782; Fri, 9 Apr 2010 02:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -57.148 X-Spam-Level: X-Spam-Status: No, score=-57.148 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_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_MESSAGE=0.001, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_ADULT2=1.42, SARE_RECV_SPAM_DOMN02=1.666, 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 wAkLnNT76ADD; Fri, 9 Apr 2010 02:33:20 -0700 (PDT) Received: from 200-232-193-108.dsl.telesp.net.br (200-232-193-108.dsl.telesp.net.br [200.232.193.108]) by core3.amsl.com (Postfix) with ESMTP id 675DF3A6A72; Fri, 9 Apr 2010 02:32:34 -0700 (PDT) Received: from 200.232.193.108 by mail.peoplesbanktrust.net; Fri, 9 Apr 2010 06:32:28 -0300 Message-ID: <000d01cad7c7$923dae20$6400a8c0@droopyo36> From: dnsext-archive@ietf.org To: Subject: Russian dating site Date: Fri, 9 Apr 2010 06:32:28 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD7C7.923DAE20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.3790.1830 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD7C7.923DAE20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am your Russian pussy - you remember my nickname? Please Visit ------=_NextPart_000_0007_01CAD7C7.923DAE20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am your Russian pussy - you remember my nicknam= e? Please Visit
------=_NextPart_000_0007_01CAD7C7.923DAE20-- --===============0912227405==-- From diffserv-interest-bounces@ietf.org Fri Apr 9 02:33:23 2010 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E7A3A6A72 for ; Fri, 9 Apr 2010 02:33:23 -0700 (PDT) Subject: The results of your email commands From: diffserv-interest-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1807710755==" Message-ID: Date: Fri, 09 Apr 2010 02:33:22 -0700 Precedence: bulk X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.1.9 List-Id: Differentiated services general discussion X-List-Administrivia: yes Sender: diffserv-interest-bounces@ietf.org Errors-To: diffserv-interest-bounces@ietf.org --===============1807710755== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Done. --===============1807710755== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: diffserv-interest-request@core3.amsl.com Delivered-To: diffserv-interest-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A17F3A6782; Fri, 9 Apr 2010 02:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -57.148 X-Spam-Level: X-Spam-Status: No, score=-57.148 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_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_MESSAGE=0.001, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_ADULT2=1.42, SARE_RECV_SPAM_DOMN02=1.666, 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 wAkLnNT76ADD; Fri, 9 Apr 2010 02:33:20 -0700 (PDT) Received: from 200-232-193-108.dsl.telesp.net.br (200-232-193-108.dsl.telesp.net.br [200.232.193.108]) by core3.amsl.com (Postfix) with ESMTP id 675DF3A6A72; Fri, 9 Apr 2010 02:32:34 -0700 (PDT) Received: from 200.232.193.108 by mail.peoplesbanktrust.net; Fri, 9 Apr 2010 06:32:28 -0300 Message-ID: <000d01cad7c7$923dae20$6400a8c0@droopyo36> From: dnsext-archive@ietf.org To: Subject: Russian dating site Date: Fri, 9 Apr 2010 06:32:28 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD7C7.923DAE20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.3790.1830 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD7C7.923DAE20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am your Russian pussy - you remember my nickname? Please Visit ------=_NextPart_000_0007_01CAD7C7.923DAE20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am your Russian pussy - you remember my nicknam= e? Please Visit
------=_NextPart_000_0007_01CAD7C7.923DAE20-- --===============1807710755==-- From sties@mail3.kd.pp.ru Fri Apr 9 06:44:31 2010 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 E7E973A6808; Fri, 9 Apr 2010 06:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.328 X-Spam-Level: X-Spam-Status: No, score=-91.328 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, J_CHICKENPOX_64=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_STILLSINGLE=1.66, 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 RVS4EAJwvnhq; Fri, 9 Apr 2010 06:44:31 -0700 (PDT) Received: from ppp079166170145.dsl.hol.gr (ppp079166170145.dsl.hol.gr [79.166.170.145]) by core3.amsl.com (Postfix) with ESMTP id A112F3A672F; Fri, 9 Apr 2010 06:44:30 -0700 (PDT) Received: from 79.166.170.145 by mx1.mxmailer.com; Fri, 9 Apr 2010 16:44:23 +0200 Date: Fri, 9 Apr 2010 16:44:23 +0200 From: dnsext-archive@ietf.org Subject: Still single?look at my profile, Olga from Russia To: Message-ID: <000d01cad7ea$c3b74f10$6400a8c0@sties> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Why we stopped our communication? I expected more, Olga! http://diffuse06.spaces.live.com From sties@mail3.kd.pp.ru Fri Apr 9 06:44:31 2010 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 E7E973A6808; Fri, 9 Apr 2010 06:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.328 X-Spam-Level: X-Spam-Status: No, score=-91.328 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, J_CHICKENPOX_64=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_STILLSINGLE=1.66, 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 RVS4EAJwvnhq; Fri, 9 Apr 2010 06:44:31 -0700 (PDT) Received: from ppp079166170145.dsl.hol.gr (ppp079166170145.dsl.hol.gr [79.166.170.145]) by core3.amsl.com (Postfix) with ESMTP id A112F3A672F; Fri, 9 Apr 2010 06:44:30 -0700 (PDT) Received: from 79.166.170.145 by mx1.mxmailer.com; Fri, 9 Apr 2010 16:44:23 +0200 Date: Fri, 9 Apr 2010 16:44:23 +0200 From: dnsext-archive@ietf.org Subject: Still single?look at my profile, Olga from Russia To: Message-ID: <000d01cad7ea$c3b74f10$6400a8c0@sties> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Why we stopped our communication? I expected more, Olga! http://diffuse06.spaces.live.com From owner-namedroppers@ops.ietf.org Fri Apr 9 07:57:00 2010 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 782973A6452; Fri, 9 Apr 2010 07:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[AWL=-0.842, 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 ivfyXWl3+6VH; Fri, 9 Apr 2010 07:56:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 470253A68A0; Fri, 9 Apr 2010 07:56:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0FYJ-00014R-7E for namedroppers-data0@psg.com; Fri, 09 Apr 2010 14:51:23 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0FYG-000144-Qr for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 14:51:20 +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 47DC31ECB4E8 for ; Fri, 9 Apr 2010 14:51:19 +0000 (UTC) Date: Fri, 9 Apr 2010 10:51:17 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Message-ID: <20100409145117.GH3595@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, I'm speaking only for myself, here, in trying to come to some conclusions in light of the discussion we had in Anaheim about DNS "name equivalences" and so on. Importantly, I want to convey that I haven't discussed this with Olafur and that I have not reached any conclusion. We have been investigating two things in parallel: 1. What the requirements would be for some kind of additional aliasing mechanism for the DNS. 2. Whether there is any protocol work that DNSEXT should do in support of (1). ICANN has issued some questions and answers (http://www.icann.org/en/topics/idn/fast-track/synchronized-idn-cctlds-faq-en.htm) in support of their "Proposed Implementation Plan for Synchronized IDN ccTLDs" (http://www.icann.org/en/announcements/announcement-22mar10-en.htm). The Q&A makes perfectly clear that, at least as far as ICANN is concerned, whatever synchronized TLDs are, they have nothing to do with the DNS. To the extent that two synchronized domains are supposed to have similar zone data, that is entirely a matter for provisioning tools and contracts. ICANN's plan might be understood to suggest that, even if there is a problem here to be solved (and I guess there is, or ICANN wouldn't be doing something about it), no protocol work is needed in order that it could be addressed. Are others in agreement with that? If so, then it would appear that the WG does not need to consider this topic any more as a possible work item. If you do not agree with that conclusion, it would be interesting to me to hear why not, and what you think needs support in the protocol that cannot be accommodated in ICANN's plan. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Apr 9 08:33:33 2010 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 E03123A6874; Fri, 9 Apr 2010 08:33:33 -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 04UzLOv0ErdM; Fri, 9 Apr 2010 08:33:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 922563A683A; Fri, 9 Apr 2010 08:33:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0G8k-0005dX-OW for namedroppers-data0@psg.com; Fri, 09 Apr 2010 15:29:02 +0000 Received: from [64.78.22.237] (helo=EXPFE100-2.exc.icann.org) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0G8i-0005d8-On for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 15:29:00 +0000 Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Fri, 9 Apr 2010 08:28:59 -0700 From: Kim Davies To: Andrew Sullivan CC: "namedroppers@ops.ietf.org" Date: Fri, 9 Apr 2010 08:28:57 -0700 Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Thread-Topic: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Thread-Index: AcrX+V+ic/7Qv1QVSDmvtpgtKAcz6w== Message-ID: <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> References: <20100409145117.GH3595@shinkuro.com> In-Reply-To: <20100409145117.GH3595@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 09/04/2010, at 7:51 AM, Andrew Sullivan wrote: >=20 > ICANN's plan might be understood to suggest that, even if there is a > problem here to be solved (and I guess there is, or ICANN wouldn't be > doing something about it), no protocol work is needed in order that it > could be addressed. Are others in agreement with that? If so, then > it would appear that the WG does not need to consider this topic any > more as a possible work item. >=20 > If you do not agree with that conclusion, it would be interesting to > me to hear why not, and what you think needs support in the protocol > that cannot be accommodated in ICANN's plan. I think it would be fair to say the ICANN staff's view is that we are highl= y desirous of a protocol-level solution to this problem. However there are = immediate non-technical imperatives to launch synchronised domains in some = fashion and this is an approximation that can be accomplished within the cu= rrent framework. Operators of synchronised domains would be required to mig= rate from this interim arrangement to any technological solution the techni= cal community can come up with. So, no, I don't think the intent of the ICANN proposal is to suggest this i= s the final solution to the problem. kim= From owner-namedroppers@ops.ietf.org Fri Apr 9 08:45:26 2010 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 3FF6D3A6956; Fri, 9 Apr 2010 08:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.333 X-Spam-Level: X-Spam-Status: No, score=0.333 tagged_above=-999 required=5 tests=[AWL=-1.556, BAYES_05=-1.11, 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 185lU4au8Psj; Fri, 9 Apr 2010 08:45:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6D50F3A6929; Fri, 9 Apr 2010 08:45:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0GL1-0007Jy-JM for namedroppers-data0@psg.com; Fri, 09 Apr 2010 15:41:43 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0GKz-0007JY-Bp for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 15:41:41 +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 4D18B1ECB4E8 for ; Fri, 9 Apr 2010 15:41:40 +0000 (UTC) Date: Fri, 9 Apr 2010 11:41:38 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Message-ID: <20100409154138.GK3595@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.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: On Fri, Apr 09, 2010 at 08:28:57AM -0700, Kim Davies wrote: > I think it would be fair to say the ICANN staff's view is that we > are highly desirous of a protocol-level solution to this > problem. However there are immediate non-technical imperatives to > launch synchronised domains in some fashion and this is an > approximation that can be accomplished within the current > framework. Excellent. Now, if you could just give me an operational definition of "synchronised domain", we'd be in business. The ICANN Q&A makes it clear that it's a matter of users not being surprised. It doesn't even require the A records for a pair of subordinate (respective) labels to be the same, the zone example notwithstanding (and I can think of plenty of ways in which having them different would be a way to make users less surprised). As far as I can tell, domains are synchronized just in case the top-level operator says so. So what problem are you going to solve with a protocol-level solution that isn't solved here already? > Operators of synchronised domains would be required to > migrate from this interim arrangement to any technological solution > the technical community can come up with. Quite apart from the novel jurisprudence entailed by a US corporation "requiring" anything of foreign sovereign states, I don't understand how you can make this blanket requirement for a technical solution we haven't invented yet. Maybe it won't work for the case in question. Moreover, it seems that the ICANN plan is going to give us an unpredictable number of new deployed solutions with which we can't be incompatible. Right? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Apr 9 08:48:40 2010 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 A0A273A6968; Fri, 9 Apr 2010 08:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, 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 7ShU1YzLGNED; Fri, 9 Apr 2010 08:48:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D1B873A6967; Fri, 9 Apr 2010 08:48:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0GOP-0007m8-UZ for namedroppers-data0@psg.com; Fri, 09 Apr 2010 15:45:13 +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.71 (FreeBSD)) (envelope-from ) id 1O0GOO-0007lU-13 for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 15:45:12 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id B088EA15D5 for ; Fri, 9 Apr 2010 15:45:09 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-Reply-To: Your message of "Fri, 09 Apr 2010 08:28:57 MST." <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 09 Apr 2010 15:45:09 +0000 Message-ID: <11753.1270827909@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: Kim Davies > Date: Fri, 9 Apr 2010 08:28:57 -0700 > ... > So, no, I don't think the intent of the ICANN proposal is to suggest this > is the final solution to the problem. this is compatible with my own design constraints, which included: Must not require stubs or recursives to be upgraded, since there are millions of these and the tail is long Must be an Internet Standard, not a proprietary or adhoc extension, to facilitate multivendor operation Must not place any burden on registry, which may be regulated (so, autoinsertion into root zone, no!) Authority server operators, protocol implementors, and registrars can accept burdens, since they have incentives, and are few in number BNAME and SHADOW both meet these criteria, in that they would require action only unilaterally (by the zone's authority server implementors/operators). as such, a fast tracked response by this WG which was similar to "make BNAME and SHADOW available" would still be very well timed to meet kim davies' (ICANN's) stated objectives. note that other methods besides BNAME and SHADOW may be superior once a problem statement is generally agreed. i'm using them here as examples of things this WG could do that would still be relevant even given ICANN's current zone synchronization fast-track proposal, referred to up-thread. From owner-namedroppers@ops.ietf.org Fri Apr 9 09:40:49 2010 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 303F83A6A21; Fri, 9 Apr 2010 09:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.161 X-Spam-Level: X-Spam-Status: No, score=-5.161 tagged_above=-999 required=5 tests=[AWL=-0.666, 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 IPIUvQtgmgug; Fri, 9 Apr 2010 09:40:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E0F5D3A6941; Fri, 9 Apr 2010 09:40:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0HB4-000Dh7-0S for namedroppers-data0@psg.com; Fri, 09 Apr 2010 16:35:30 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0HB1-000Dgj-Et for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 16:35:27 +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 o39GZ37O077173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Apr 2010 09:35:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> Date: Fri, 9 Apr 2010 09:35:02 -0700 To: Kim Davies From: Paul Hoffman Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Cc: 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 8:28 AM -0700 4/9/10, Kim Davies wrote: >I think it would be fair to say the ICANN staff's view is that we are highly desirous of a protocol-level solution to this problem. That statement does not match with what is written in the Q&A at : "Synchronized" in the context of this process relates solely to policy and procedural requirements. There is no technical mechanism by which synchronized IDN ccTLDs will be made to be identical at the DNS protocol level. Or are you differentiating "ICANN staff" from "ICANN" (as many of us do)? > However there are immediate non-technical imperatives to launch synchronised domains in some fashion and this is an approximation that can be accomplished within the current framework. Operators of synchronised domains would be required to migrate from this interim arrangement to any technological solution the technical community can come up with. Where in the Q&A or the main document is there a discussion of such migration? This is a serious question for this WG. >So, no, I don't think the intent of the ICANN proposal is to suggest this is the final solution to the problem. The above quote, and other similar text in the proposal and the Q&A, indicate otherwise. Getting something definitive from ICANN will have a significant impact on this WG. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Fri Apr 9 10:15:32 2010 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 210EE3A6874; Fri, 9 Apr 2010 10:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 HsDOscs9DPMG; Fri, 9 Apr 2010 10:15:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0BCFF3A6918; Fri, 9 Apr 2010 10:15:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0HjF-000I86-2x for namedroppers-data0@psg.com; Fri, 09 Apr 2010 17:10:49 +0000 Received: from [64.78.22.237] (helo=EXPFE100-2.exc.icann.org) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0HjB-000I7l-S1 for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 17:10:45 +0000 Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Fri, 9 Apr 2010 10:10:45 -0700 From: Kim Davies To: Andrew Sullivan CC: "namedroppers@ops.ietf.org" Date: Fri, 9 Apr 2010 10:10:44 -0700 Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Thread-Topic: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Thread-Index: AcrYB5cqDYmoI+WhQQGOdjvyTEASqQ== Message-ID: <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.org> References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> In-Reply-To: <20100409154138.GK3595@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 09/04/2010, at 8:41 AM, Andrew Sullivan wrote: >=20 > Excellent. Now, if you could just give me an operational definition > of "synchronised domain", we'd be in business. The ICANN Q&A makes it > clear that it's a matter of users not being surprised. It doesn't > even require the A records for a pair of subordinate (respective) > labels to be the same, the zone example notwithstanding (and I can > think of plenty of ways in which having them different would be a way > to make users less surprised). As far as I can tell, domains are > synchronized just in case the top-level operator says so. >=20 > So what problem are you going to solve with a protocol-level solution > that isn't solved here already? I'll caveat my answer with saying I am somewhat involved in this synchronis= ed domain concept, but thus far limited to answering questions from colleag= ues on what would be the impact on IANA's root zone operations. I hope more= directly involved colleagues will chime in if I am off base here. The fine details of the implementation of any synchronised TLD plan are not= developed yet. The basic notion is that using contractual language between= ICANN and the TLD operator, the TLD operator would be expected to take ste= ps to keep multiple trees in synch, even through they are technically separ= ate delegations at the root level. Administrative changes to the TLD delega= tion would likely need to be kept in synch.=20 In the introduction of the draft implementation plan[1], it reads "The issu= e relates to instances in the Fast Track Process where more than one offici= al language or script exists within a country/territory, and where requests= for multiple corresponding strings are considered equivalent. In these cas= es, those accessing domains under any of the strings expect that such domai= ns will resolve to the same address or value. Strings meeting these require= ments, and operated in a way to meet community expectations are referred to= as synchronized IDN ccTLDs." A basic assumption of the draft model is that the only tools available in t= he root zone at present are NS records. It could be some other technology, = be it DNAMEs or other alternatives are appropriate, but there is nothing ri= ght now tested and deployable to the point it can be confidently put into p= roduction in the root zone in the near future. > Quite apart from the novel jurisprudence entailed by a US corporation > "requiring" anything of foreign sovereign states, I don't understand > how you can make this blanket requirement for a technical solution we > haven't invented yet. Maybe it won't work for the case in question. =20 If a technical solution presents itself that involves altering the root zon= e to a different set of records to make two TLD structures match, then the = intention is ICANN will migrate from NS records in the root to the new solu= tion over some transition period. > Moreover, it seems that the ICANN plan is going to give us an > unpredictable number of new deployed solutions with which we can't be > incompatible. Right? I think staff estimate this addresses a few corner cases, which is not enti= rely predictable but is a relatively small amount. But the use case is the = same for each of the potential synchronised ccTLDs. I am not sure if that a= nswers your question? I have a feeling by sticking my head up, I am about to be called on for not= paying enough attention to the CLONE/BNAME etc. discussions recently... kim [1] http://www.icann.com/en/topics/idn/fast-track/proposed-plan-synchronize= d-idn-cctlds-22mar10-en.pdf From owner-namedroppers@ops.ietf.org Fri Apr 9 10:15:58 2010 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 2ED1A3A68AA; Fri, 9 Apr 2010 10:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[AWL=0.650, 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 KzBsZz7bScPy; Fri, 9 Apr 2010 10:15:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F10353A688E; Fri, 9 Apr 2010 10:15:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0HkM-000IEE-KM for namedroppers-data0@psg.com; Fri, 09 Apr 2010 17:11:58 +0000 Received: from [64.78.22.236] (helo=EXPFE100-1.exc.icann.org) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0HkK-000IDx-MO for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 17:11:56 +0000 Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Fri, 9 Apr 2010 10:11:55 -0700 From: Kim Davies To: Paul Hoffman CC: "namedroppers@ops.ietf.org" Date: Fri, 9 Apr 2010 10:11:54 -0700 Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Thread-Topic: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Thread-Index: AcrYB8DCkhJQkV22SxiFoGgK3aojpg== Message-ID: <465599C3-C8FB-4BBD-9ACE-1DC3AE8C34D8@icann.org> References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> In-Reply-To: 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 09/04/2010, at 9:35 AM, Paul Hoffman wrote: > At 8:28 AM -0700 4/9/10, Kim Davies wrote: >> I think it would be fair to say the ICANN staff's view is that we are hi= ghly desirous of a protocol-level solution to this problem. >=20 > That statement does not match with what is written in the Q&A at := "Synchronized" in the context of this process relates solely to policy and= procedural requirements. There is no technical mechanism by which synchron= ized IDN ccTLDs will be made to be identical at the DNS protocol level. ... >=20 > Where in the Q&A or the main document is there a discussion of such migra= tion? This is a serious question for this WG. >From the FAQ: "Should technical developments facilitate alternative mechanisms for suppor= ting variants of TLDs in the root zone which are found to be preferable to = provisioning variants using distinct delegations, ICANN will develop an app= ropriate phase-in period and operators of synchronized IDN ccTLDs will need= to migrate as appropriate to the new methodology." So, yes, the current proposal is for a policy/procedural only mechanism, bu= t intending to move to a technical one when possible. kim= From owner-namedroppers@ops.ietf.org Fri Apr 9 10:27:09 2010 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 66AFC3A6967; Fri, 9 Apr 2010 10:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.679 X-Spam-Level: * X-Spam-Status: No, score=1.679 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_50=0.001, 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 giP8AuSBfEYb; Fri, 9 Apr 2010 10:27:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 182DD3A6862; Fri, 9 Apr 2010 10:27:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0HvQ-000Jki-Iv for namedroppers-data0@psg.com; Fri, 09 Apr 2010 17:23:24 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0HvN-000JkF-G2 for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 17:23:21 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o39HNCPU011846; Fri, 9 Apr 2010 13:23:12 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Fri, 09 Apr 2010 13:23:17 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 09 Apr 2010 13:23:17 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> Date: Fri, 9 Apr 2010 13:23:09 -0400 To: Ted Hardie From: Edward Lewis Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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:01 -0700 4/8/10, Ted Hardie wrote: >what "value" might mean. The discussion to date has covered much of >this ground, >but your posting re-mixes pieces that Paul, David, and I have tried to >pull apart. I am still totally mystified by the concerns labelled as "privacy" after trying to identify the above messages. (As an annoying side note - the subject lines haven't been all that useful in identifying threads. To be fair, the messages are wide ranging.) I'm not a big expert on privacy. From what I understand the issue is that the desire is to limit the amount of personally identifying information in an otherwise anonymous interaction. In a DNS query, the identifying information currently is the source IP address and port and possibly the question. The originator of the query (assuming someone who is not advantaged by falsifying the source address) will have to reveal the addressing information and question to some other entity. The other entity can be a lot of things, including the authority server, but I'm going to scope this down to the set of entities that would consider edns-client-ip as a feature (which is a much broader scope that entities that would make use of it). The entity scope is now a recursive server, notably, one with a cache. To keep this from being application specific, I'm only going to consider a few specific questions related to the adoption of edns-client-ip. - What will an DNS authority server now know (with edns-client-ip) that it doesn't know now about the querier? - What might a cache leak information wise to another querier about what it has, specifically, in a way that would identify the original querier? Would that be a sufficient set of questions to cover the "privacy" issue? 1) What does an authority know because of edns-client-ip? The authority will only see the cache misses, so it is not guaranteed to see the frequency of requests nor the set of those sending the query (is it one or a botnet's worth of originators?). One could argue that with low enough TTLs the authority could force cache misses and see everything. But if the authority server is performing such manipulation they might as well manipulate the targets of the connection attempts. The percentage chance a query is uniquely identified to an authority server could be very small. If that were the case, then the privacy concern would be that anyone was identified at all, not that the community of interest was identified. At this point - I admit I'm not getting the concern. Is the goal blocking of personally identifiable information? On what scale? Is an IP subnet personally identifying? Can't a person trying to hide tracks use tunneling to avoid detection? Or work with recursive servers that provide source obfuscation? A side not on the latter, there was once a project that hid the accessor from the server via rerouting and tunnelling in a mesh of cooperating servers to provide plausible deniability. I don't know if that took off anywhere. The obfuscation was not just for DNS but for any service access. 2) What might a cache leak? If the cache keeps data "binned" by a gross level network address and mask and does not retain the original /32 (v4) or /128 (v6), what constitutes personally identifiable information? This assumes the cache is even participating in edns-client-ip. Idle conjecture: The cache's security is weak, perhaps their are other weaknesses in the operator's facility, like the billing machine (with credit card numbers) or a staff that is easily socially engineered (this is the Albuquerque, Arizona[0] police department and you have unpaid parking tickets we will forgive if you tell me ...). I don't know if you can tie back to a query why a cache has an an entry. And if the network range and mask is determined by the authority server, there's no clear indicator that there is personally identifiable information there. Summary - When one says "privacy" as in "privacy concerns" what is the real problem, how is it quantified within the actions of a protocol? "Privacy" against what discovery? Is there a privacy threat model? What is the concern over allowing a user to opt out of the passing of information on? If the information is not personally identifying, does this cross from being privacy to an issue of option negotiation? Is there some unwritten privacy assumption that one's source IP address can only every be used in a certain way? Is this an internet-wide issue which every protocol should be examined to see how it uses the layer 3 identifier? Or is privacy just about protecting "personally identifiable information?" [0] An intentional 'mistake.' PS - I was thinking about this email some more after writing and began to wonder if there's discomfort in the use of any fields of the protocol beyond the end-elements. Is the thought that the client of the protocol determines the use of the contents of the message. Implicit is an understanding and agreement to the proper conduct of the protocol of course. In this case, it's EDNS0 that is supposed to be hop-by-hop but then the use of the client IP is now seen as crossing a barrier at the bequest of the server, not the client. But - an IP address is what defines the network...so what is it's scope? I really don't understand the privacy issue here... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From owner-namedroppers@ops.ietf.org Fri Apr 9 11:11:14 2010 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 1FEB13A6845; Fri, 9 Apr 2010 11:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.572 X-Spam-Level: X-Spam-Status: No, score=0.572 tagged_above=-999 required=5 tests=[AWL=-1.687, BAYES_20=-0.74, 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 fUu9QsRLQDZK; Fri, 9 Apr 2010 11:11:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 631553A68E3; Fri, 9 Apr 2010 11:11:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0IaM-000PCs-5d for namedroppers-data0@psg.com; Fri, 09 Apr 2010 18:05:42 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0IaJ-000PCT-4A for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 18:05: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 85F571ECB4E8 for ; Fri, 9 Apr 2010 18:05:37 +0000 (UTC) Date: Fri, 9 Apr 2010 14:05:35 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Message-ID: <20100409180535.GQ3595@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.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, I'm going to push hard in this mail, because I really want to understand what work we think is needed to be done in this space given the evidence before us. Again, I wish to emphasise that I'm speaking for myself, in trying to understand our requirements gathering, and I have not made up my mind. On Fri, Apr 09, 2010 at 10:10:44AM -0700, Kim Davies wrote: > > The fine details of the implementation of any synchronised TLD plan > are not developed yet. The basic notion is that using contractual > language between ICANN and the TLD operator, the TLD operator would > be expected to take steps to keep multiple trees in synch, even > through they are technically separate delegations at the root > level. Administrative changes to the TLD delegation would likely > need to be kept in synch. The trouble is, we have no precise definition of what it would mean for them to be "in synch", and this bears directly on what we might conceivably be able to do here. If existing provisioning-side approaches are good enough and safe enough to do this already, today, for the root zone and, according to the Plan, with some sort of commitment that it will carry all the way down the tree, why do we need to do any more work? For more details on what this all could mean, see below. First, an administrative note. Remember, as a WG chair one of my jobs is to make sure the WG doesn't take on work it is incapable of finishing. Moreover, we are responsible for a mature protocol with a large installed base and a long history of painful protocol extensions (look at the demonstrated facts around TCP use, the long history of DNSSEC deployment, and the fact that EDNS0 continues to be problematic in some places, for examples). I expressed openness towards this aliasing topic because operators were claiming that the solutions we have now could not meet their needs. But at the time some people said, "This is a simple provisioning and contract issue, and there's no need for more work." If ICANN now actually implements some sort of aliasing using only contracts and provisioning rules, then that is evidence for the conclusion that the WG need do no more. Adding more things to the protocol adds complexity, and therefore we need a much better argument than, "We think it would be nice," in order to consider seriously big protocol additions. Finally, there's the administrative problem of adequate review: this WG has a hard time reviewing even simple documents, and the aliasing proposals all have big implications for topics like DNSSEC. We have too the complaint that any formal aliasing mechanism opens whole new opportunities for phishing and so on, so there is a raft of security issues that we'd have to investigate if we take on this work. So, if I put all that up against something already implemented (which, assuming it "works" for some value thereof, means that the problem is solved), I have a hard time seeing why the WG would want to do anything to the DNS protocols. Now, to the substance of your claim. The Q&A posted yesterday does require that operators make changes to all synchronized TLDs at the same time, but that nowise requires that the trees be "in sync", for any ordinary meaning of the word. On the contrary, the Q&A says plainly that these are two completely separate delegations, and that the only criterion for whether things are synchronized is whether users' expectations are met. Nowhere is that criterion operationalized, but because it's a matter of user experience this WG doesn't have to care: it's outside our competence to solve. I can certainly imagine plenty of ways in which users' expectations could be best met by having completely different RDATA in two completely different zones, so I don't see any reason why there is any implication at all for the DNS here. > In the introduction of the draft implementation plan[1], it reads > "The issue relates to instances in the Fast Track Process where more > than one official language or script exists within a > country/territory, and where requests for multiple corresponding > strings are considered equivalent. In these cases, those accessing > domains under any of the strings expect that such domains will > resolve to the same address or value. Strings meeting these > requirements, and operated in a way to meet community expectations > are referred to as synchronized IDN ccTLDs." I think it will not be a surprise that that definition has led to a lot of gnashing of teeth. I'm going to leave aside the issue with "language or script", because this isn't an internationalization forum. I'm also going to ignore the fanciful idea of "resolving to a value". For the purposes of this WG, the problem is that I don't know what the targetted behaviour is. Suppose that we have TLD1 and TLD2, and they're supposed to be synchronized. TLD1 comes from one repetoire of Unicode characters. Call it range1. TLD2 comes from another repetoire of Unicode characters. Call it range2. The only restriction is that range1 and range2 have at least one character that differs between them (they're not equivalent sets. In the unlikely event that any people who know about writing systems are reading this, I understand that this simplifying assumption is already really bad. Never mind that). Now, suppose we have any sets of labels, each of which is either in range1 (symbolized r1) or range2 (symbolized r2). Which of the following behaviours is desired: a. Should DNS names in the zones underneath the two synchronized zones be exactly (bit-for-bit) equivalent to one another? For example, for a fully qualified domain name of the form r1.r1.tld1, must there always and only be a synchronized entry r1.r1.tld2? b. Should all and every label under TLD1 be expressed in LE1 and all and every label under TLD2 be expressed in LE2? For example, for a fully qualified domain of the form r1.r1.tld1 must there always and only be a synchronized entry r2.r2.tld2? c. Should every label at every level of the DNS be expressed in both LE1 and LE2 (the combinatorial case)? For example, for a fully qualified domain name of the form r1.r1.r1.tld1, would it be necessary also to have r1.r1.r1.tld2, r2.r1.r1.tld2, r2.r2.r1.tld2, r2.r2.r2.tld2, r1.r2.r2.tld2, and so on? Those are three different aliasing behaviours. For the purposes of this WG, we don't care what the linguistic issues underlying this are, but we need to understand which of these are target behaviours and which not, so that we can (if we're going to do the work) address them. ICANN's answer, as near as I can make out from the Plan and the Q&A, is that we don't have to worry about it, because the right rules will be used for provisioning and for checking that behaviour conforms to users' expectations whatever happens. That's fine and good, and it means we don't have to do any work. Moreover, ICANN can't possibly mean anyway that the DNS trees are going to be "synced", even allowing for the issues surrounding loose coherence, TTLs, refresh times, and so on. That's because lots of these RRs _cannot_ be equivalent by definition: RRSIGs, NSEC(3)s, DSs, SOAs, and so on need to have zone-specific or owner-specific RDATA. This is a hard requirement of the protocol. ICANN's answer to that today is, "Right, and you don't have to worry about it because these are just different delegations in the DNS." That's good, but it again leads me to the conclusion that there is no work that this WG needs to do on this topic, because it can all be handled at the provisioning and contractual side. So I still don't understand how it is that ICANN's plan is not evidence that this WG has nothing to do in the area of aliasing -- i.e. that all the concerns that we thought we'd previously heard turn out to be solvable by provisioning mechanisms. What is the problem that needs solving? Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Apr 9 11:18:20 2010 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 19C6D3A689B; Fri, 9 Apr 2010 11:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 YvxD3awhqhHV; Fri, 9 Apr 2010 11:18:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B08403A6765; Fri, 9 Apr 2010 11:18:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0IjE-0000Pd-Cf for namedroppers-data0@psg.com; Fri, 09 Apr 2010 18:14:52 +0000 Received: from [2001:4f8:3:36::28] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0IjB-0000PK-W3 for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 18:14:50 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 71D0117D1A9; Fri, 9 Apr 2010 18:14:49 +0000 (UTC) Received: from dhcp-vlan13-91-252.home.flame.org (unknown [IPv6:2001:470:b8d7:13:61e:64ff:fef5:5604]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTPSA id 4825917D18E; Fri, 9 Apr 2010 18:14:48 +0000 (UTC) Message-ID: <4BBF6E97.1070807@isc.org> Date: Fri, 09 Apr 2010 13:14:47 -0500 From: Michael Graff User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Edward Lewis CC: Ted Hardie , namedroppers@ops.ietf.org Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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 4/9/10 12:23 PM, Edward Lewis wrote: > I'm not a big expert on privacy. From what I understand the issue is > that the desire is to limit the amount of personally identifying > information in an otherwise anonymous interaction. In a DNS query, the > identifying information currently is the source IP address and port and > possibly the question. This is the information that is passed between the client itself and its recursive resolver. The auth servers do not see anything more than the question really. This proposal extends the information from just the query being exposed to the client's IP address (or so close to it as to not matter.) All the complaints about "well, you should know you'll leak this information when you use a web browser anyway" is fair, but the net is not the web. I might be trying to find out who is attacking my network by issuing a dig command, reverse lookup, or I might be sending email. All of a sudden the root server(s) know I am doing some level of this, and while it won't happen on each query, over time a fairly good idea of which network addresses are in use could be collected. I know there was a proposal to limit it to only the things after the TLDs, but that still won't help TLDs that have more than one level, like *.co.uk. I think the argument about privacy is that who is issuing the query is no longer just between the client and its ISP, but now between the client and the world. --Michael From bulgen@motors-honda.ru Fri Apr 9 11:39:11 2010 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 88D4A3A672E; Fri, 9 Apr 2010 11:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -77.123 X-Spam-Level: X-Spam-Status: No, score=-77.123 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_NUMYO2=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, HELO_EQ_SE=0.35, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, 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 e5PQIapmJBuF; Fri, 9 Apr 2010 11:39:10 -0700 (PDT) Received: from c80-217-184-77.bredband.comhem.se (c80-217-184-77.bredband.comhem.se [80.217.184.77]) by core3.amsl.com (Postfix) with ESMTP id 836823A6839; Fri, 9 Apr 2010 11:39:09 -0700 (PDT) Received: from 80.217.184.77 by mail.motors-honda.ru; Fri, 9 Apr 2010 20:38:49 +0100 Date: Fri, 9 Apr 2010 20:38:49 +0100 From: dnsext-archive@ietf.org Subject: You have new mail from Olga To: Message-ID: <000d01cad813$e5554770$6400a8c0@bulgen> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal You have new mail from Olga 26 y.o. Russia, dating http://classroom98.spaces.live.com From owner-namedroppers@ops.ietf.org Fri Apr 9 11:50:59 2010 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 D3C8F3A689F; Fri, 9 Apr 2010 11:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.93 X-Spam-Level: X-Spam-Status: No, score=-9.93 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HABEAS_ACCREDITED_SOI=-4.3, HELO_MISMATCH_COM=0.553, RCVD_IN_BSP_TRUSTED=-4.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 Z+h9IXCJxD1G; Fri, 9 Apr 2010 11:50:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AD7263A6890; Fri, 9 Apr 2010 11:50:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JDl-0003q1-4R for namedroppers-data0@psg.com; Fri, 09 Apr 2010 18:46:25 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JDi-0003ol-Jg for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 18:46:23 +0000 Received: (qmail 23414 invoked from network); 9 Apr 2010 18:46:21 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 9 Apr 2010 18:46:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k1004; olt=johnl@user.iecc.com; bh=7EP6TohZJ04VVTX7jDtNrMWlmDv0t90ZoXdhDYI7aJ0=; b=G6ibMwtemtj9PMX2QcWLac9r19Y2QpBHddX8jTAP5MiIHwmaztO6HlLWI0i4/jVDZ0+1C8s7h+2dAbX8bL8FCTQouKv0Cdp7wVTq49XNN7K0UTDMEyaTI17F5GEtHidUymIttDDhZz/yYV/Dlmx4RDdP3kQmhpC8EUqhKAlk7ts= Date: 9 Apr 2010 18:46:20 -0000 Message-ID: <20100409184620.16101.qmail@simone.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-Reply-To: <20100409145117.GH3595@shinkuro.com> Organization: Cc: ajs@shinkuro.com X-Headerized: yes Mime-Version: 1.0 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: >ICANN's plan might be understood to suggest that, even if there is a >problem here to be solved (and I guess there is, or ICANN wouldn't be >doing something about it), no protocol work is needed in order that >it could be addressed. Are others in agreement with that? It is my impression that making two domains look or act "the same" depends at least as much on the behavior of web servers, MTAs, and other non-DNS software as on anything we could possibly do. R's, John From owner-namedroppers@ops.ietf.org Fri Apr 9 11:51:15 2010 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 8616C3A689B; Fri, 9 Apr 2010 11:51:15 -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 NaPIJZHDtXOZ; Fri, 9 Apr 2010 11:51:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6EC33A6890; Fri, 9 Apr 2010 11:51:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JEw-00048b-HP for namedroppers-data0@psg.com; Fri, 09 Apr 2010 18:47:38 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JEt-00048E-LH for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 18:47:35 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id EC5BDB7B145; Fri, 9 Apr 2010 11:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XO9up-wTmYe6; Fri, 9 Apr 2010 11:47:31 -0700 (PDT) Received: from [10.0.1.5] (cpe-70-95-123-210.hawaii.res.rr.com [70.95.123.210]) by virtualized.org (Postfix) with ESMTP id 34F6DB7B12A; Fri, 9 Apr 2010 11:47:31 -0700 (PDT) Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20100409180535.GQ3595@shinkuro.com> Date: Fri, 9 Apr 2010 08:47:29 -1000 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.org> <20100409180535.GQ3595@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1078) 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, On Apr 9, 2010, at 8:05 AM, Andrew Sullivan wrote: > If ICANN now actually implements some sort of aliasing using only > contracts and provisioning rules, then that is evidence for the > conclusion that the WG need do no more. =20 No, it isn't. Synchronized domains is obviously a hack and it = absolutely will not scale (I personally have my doubts it will even = scale at n=3D1, but that's probably just me). It is not a generic = solution and applies only at the TLD level. > What is the problem that needs solving? If I remember correctly, it was that DNAME was felt by some to be an = insufficient solution to the generic aliasing problem. Regards, -drc From owner-namedroppers@ops.ietf.org Fri Apr 9 12:05:39 2010 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 07BBD3A688E; Fri, 9 Apr 2010 12:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.735 X-Spam-Level: * X-Spam-Status: No, score=1.735 tagged_above=-999 required=5 tests=[AWL=0.370, 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 X5+6K2D7zbFl; Fri, 9 Apr 2010 12:05:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 93A643A6860; Fri, 9 Apr 2010 12:05:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JPL-0005Fo-56 for namedroppers-data0@psg.com; Fri, 09 Apr 2010 18:58:23 +0000 Received: from [38.229.66.8] (helo=obelisk11.ord01.cymru.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JPI-0005FU-RD for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 18:58:20 +0000 Received: from t61p (vpn-21-36.svcs.iad01.cymru.com [192.168.21.36]) by obelisk11.ord01.cymru.com (Postfix) with ESMTP id 0D1EBB014A; Fri, 9 Apr 2010 18:58:19 +0000 (GMT) Date: Fri, 9 Apr 2010 13:58:18 -0500 From: John Kristoff To: Edward Lewis Cc: Ted Hardie , namedroppers@ops.ietf.org Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 Message-ID: <20100409135818.621d730f@t61p> In-Reply-To: References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> X-Mailer: Claws Mail Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Fri, 9 Apr 2010 13:23:09 -0400 Edward Lewis wrote: > One could argue that with low enough TTLs the authority could force > cache misses and see everything. But if the authority server is > performing such manipulation they might as well manipulate the > targets of the connection attempts. Low TTLs aren't not necessary and won't be reliable. Using the web as an example, I'd used wildcards and dynamically generated content. As you browse to or through my site, you'd be performing lookups on domain names I generated just for you. I'd fully expect the web banner advertisers to do this sort of thing. > When one says "privacy" as in "privacy concerns" what is the real > problem, how is it quantified within the actions of a protocol? Perhaps it is simply shock at seeing assumptions about the traditional stub->ISPresolver->authority data flow being challenged? > I really don't understand the privacy issue here... You're not paranoid enough? :-) John From owner-namedroppers@ops.ietf.org Fri Apr 9 12:06:12 2010 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 E2EDC3A6902; Fri, 9 Apr 2010 12:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[AWL=-0.702, 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 a70RP1hjI+Ev; Fri, 9 Apr 2010 12:06:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B33543A6860; Fri, 9 Apr 2010 12:06:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JT0-0005gU-PE for namedroppers-data0@psg.com; Fri, 09 Apr 2010 19:02:10 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JSx-0005ZZ-Oz for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 19:02: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 E6F841ECB4E8 for ; Fri, 9 Apr 2010 19:01:02 +0000 (UTC) Date: Fri, 9 Apr 2010 15:01:01 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Message-ID: <20100409190101.GY3595@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.org> <20100409180535.GQ3595@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 Fri, Apr 09, 2010 at 08:47:29AM -1000, David Conrad wrote: > It is not a generic solution and applies only at the TLD level. That is not what ICANN's documents currently claim, because the Plan says (and the Q&A repeats) that the synchronization will be propagated all the way down the trees. If that claim is not completely empty, then similar mechanisms can be followed all the way down. > If I remember correctly, it was that DNAME was felt by some to be an > insufficient solution to the generic aliasing problem. Yes. And now we have a particular proposal that does it all by provisioning and contracts, and I'm not even sure which of the scenarios (if any) I outlined is aimed at. I think the answer is "all of them", and I think that is therefore an existence proof that everything can be done in policy & provisioning today. (I think I've now said this every way I can think to do, so I won't repeat it in detail again.) If the claim is that policy & provisioning won't scale, then it'd be nice to know what the desired scaling properties of anything we might do need to be, along with the other details I've asked for. With emphasis: no decision here. I'm just trying to understand the problem we're trying to solve. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Apr 9 12:06:27 2010 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 DEDA23A688E; Fri, 9 Apr 2010 12:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 EvWExEp7rGBL; Fri, 9 Apr 2010 12:06:27 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 84BF53A6860; Fri, 9 Apr 2010 12:06:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JTc-0005pj-Bh for namedroppers-data0@psg.com; Fri, 09 Apr 2010 19:02:48 +0000 Received: from [2001:470:1f05:a0f::1] (helo=tigger.mamista.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JTY-0005p0-Qh for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 19:02:44 +0000 Received: by tigger.mamista.net (Postfix, from userid 1012) id DAF6C1103FA; Sat, 10 Apr 2010 05:02:43 +1000 (EST) Received: from merboo.mamista.net (merboo.mamista.net [IPv6:2001:470:1f0b:1055::1]) by tigger.mamista.net (Postfix) with ESMTP id 9D140110213 for ; Sat, 10 Apr 2010 05:02:43 +1000 (EST) Received: by merboo.mamista.net (Postfix, from userid 1000) id 0B7DA97203B; Fri, 9 Apr 2010 21:02:42 +0200 (CEST) Date: Fri, 9 Apr 2010 21:02:42 +0200 From: Martin Barry To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 Message-ID: <20100409190241.GA23156@merboo.mamista.net> References: <4BBF6E97.1070807@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBF6E97.1070807@isc.org> User-Agent: Mutt/1.5.20 (2009-06-14) 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: $quoted_author = "Michael Graff" ; > > I think the argument about privacy is that who is issuing the query is > no longer just between the client and its ISP, but now between the > client and the world. The proposal dictated that it was not the exact IP address but some enclosing subnet tagged with the appropriate netmask. Michael, would you still regard such "less accurate" leakage as a privacy concern? cheers Marty From owner-namedroppers@ops.ietf.org Fri Apr 9 12:07:54 2010 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 731A93A6902; Fri, 9 Apr 2010 12:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.394 X-Spam-Level: * X-Spam-Status: No, score=1.394 tagged_above=-999 required=5 tests=[AWL=0.030, 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 ePTgQOPy7NCh; Fri, 9 Apr 2010 12:07:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC16E3A688E; Fri, 9 Apr 2010 12:07:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JTG-0005nM-Hb for namedroppers-data0@psg.com; Fri, 09 Apr 2010 19:02:26 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JTD-0005mZ-Et for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 19:02:23 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o39J21xl012768; Fri, 9 Apr 2010 15:02:01 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Fri, 09 Apr 2010 15:02:07 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 09 Apr 2010 15:02:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4BBF6E97.1070807@isc.org> References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> <4BBF6E97.1070807@isc.org> Date: Fri, 9 Apr 2010 15:01:59 -0400 To: Michael Graff From: Edward Lewis Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 Cc: Edward Lewis , Ted Hardie , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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:14 -0500 4/9/10, Michael Graff wrote: >I think the argument about privacy is that who is issuing the query is >no longer just between the client and its ISP, but now between the >client and the world. So, first question - why is this a "privacy" problem? I look at wikipedia for "privacy." I found this one tidbit: A word "privacy" is sometimes regarded as untranslatable[2] by linguists. (I take that to mean it's not something so universally understood.) The reason I started there is that to me "privacy" involves the protection against concealment of personally identifiable information. That isn't the only definition or interpretation as I find by casually reading wikipedia's page. It would help to have some definition of what privacy means in IETF protocol engineering - lest this become just a rathole discussion. Quoting wikipedia - 1 - "The boundaries and content of what is considered private differ among cultures and individuals, but share basic common themes." Is an IP address private data? What if the address is run through a NAT before being routable? What about randomized IPv6 addresses - those where the last 48 bits are not the MAC address but some other moving value. Is an network identifier (net range/mask) private data? (What is "private data"? Personally identifiable is what I assume.) 2 - "Privacy is sometimes related to anonymity, the wish to remain unnoticed or unidentified in the public realm." Is this the concern, that loss of anonymity? Has anonymity ever been a goal of the protocol's design? 3 - "Privacy is broader than security and includes the concepts of appropriate use and protection of information." This conflates the definition of privacy with the intent and use of the data, not the presence of the data. In the case of edns-client-ip as stated, I would argue that the use to tailor an answer is "appropriate use." All of that is an incomplete analysis by someone who has not spent time studying the issue. The second question - is the issue that the client can't opt-out of the dissemination? If that's the case, then this is solved (at least in the next draft as far as I have seen it). The protocol has in it the opt-out option. When a recursive server gets a query in with a edns-client-ip it is forbidden to change the option. So, to "hide" a client could preempt the edns-client-ip by inserting it's own "0.0.0.0/0" or v6 equivalent. Maybe that's the answer to the statement that the client has no control ... the control is there ... if you trust the cache to follow the protocol ... never mind that it has to follow the protocol to send back the right answer. Still searching for the problem. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From owner-namedroppers@ops.ietf.org Fri Apr 9 12:08:21 2010 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 037D33A6930; Fri, 9 Apr 2010 12:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[AWL=0.025, 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 lm1nkUZxYH4y; Fri, 9 Apr 2010 12:08:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 660293A688E; Fri, 9 Apr 2010 12:08:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JVm-00067V-LD for namedroppers-data0@psg.com; Fri, 09 Apr 2010 19:05:02 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JVj-000671-OA for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 19:05:00 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o39J4kKq012778; Fri, 9 Apr 2010 15:04:46 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Fri, 09 Apr 2010 15:04:53 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 09 Apr 2010 15:04:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20100409135818.621d730f@t61p> References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> <20100409135818.621d730f@t61p> Date: Fri, 9 Apr 2010 15:04:43 -0400 To: John Kristoff From: Edward Lewis Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 Cc: Edward Lewis , Ted Hardie , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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:58 -0500 4/9/10, John Kristoff wrote: >You're not paranoid enough? :-) Skeptical, sarcastic, cynical, jaded, yes, guilty. I once was paranoid, now I enjoy feeding it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From owner-namedroppers@ops.ietf.org Fri Apr 9 12:11:09 2010 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 193D23A6939; Fri, 9 Apr 2010 12:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=-0.902, 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 YAlrCoJwJ8sY; Fri, 9 Apr 2010 12:11:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C95533A697D; Fri, 9 Apr 2010 12:11:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JXb-0006Nt-7y for namedroppers-data0@psg.com; Fri, 09 Apr 2010 19:06:55 +0000 Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JXY-0006N8-EB for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 19:06:52 +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 74CD0154208B; Fri, 9 Apr 2010 20:06:47 +0100 (BST) Cc: namedroppers@ops.ietf.org Message-Id: From: Jim Reid To: Andrew Sullivan In-Reply-To: <20100409180535.GQ3595@shinkuro.com> 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] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Date: Fri, 9 Apr 2010 20:06:47 +0100 References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.org> <20100409180535.GQ3595@shinkuro.com> 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 9 Apr 2010, at 19:05, Andrew Sullivan wrote: > So I still don't understand how it is that ICANN's plan is not > evidence that this WG has nothing to do in the area of aliasing -- > i.e. that all the concerns that we thought we'd previously heard turn > out to be solvable by provisioning mechanisms. Frankly, I no longer understand ICANN's plan or what it might mean. Both in a general sense and for its impact on the DNS. Perhaps I'm just being more obtuse than normal and there is nothing to worry about. However if there is wider uncertainty or confusion, it needs to be cleared up. And soon. ICANN's consultation closes early next week. > What is the problem that needs solving? I don't know. It seems ICANN is saying it'll be OK for "synchronized domains" in "different scripts" (whatever ICANN mean by these terms) to be loosely coherent. If that's the case and there's a consensus for that view at the IETF, then we're done. There's nothing to see here, move along. OTOH, Kim's just said ICANN staff would like a protocol-level solution. Well, that is very unlikely to be achieved in line with the plan's timetable for equivalent ccTLDs. If ICANN goes ahead with something else before this protocol solution is ready -- which assumes they give this WG a clear problem statement to work on and provide the metric for determining success -- then that opens up a whole raft of new issues. Migrating from an interim approach to the protocol solution, backwards compatibility & interoperability, etc, etc. Maybe those using some interim policy/procedural solution will have no interest in migrating to a protocol solution. Remember ICANN can't impose things on ccTLDs as they can with gTLDs. Almost no ccTLDs have a contract with ICANN. It doesn't involve itself in ccTLD activities because that's a matter of National Sovereignty. So if ICANN goes ahead with a policy/procedural solution now, it may be impossible to put that genie back in its bottle later. Or deny that policy/procedural solution to current and new gTLDs. I also have concerns that ICANN's interim policy/procedural solution will impose or distort the constraints on whatever protocol work this WG does. The fuzziness is rather unsettling. From owner-namedroppers@ops.ietf.org Fri Apr 9 12:15:30 2010 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 54D8C3A6936; Fri, 9 Apr 2010 12:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.125 X-Spam-Level: X-Spam-Status: No, score=-102.125 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, SARE_UNSUB22=0.948, 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 l0M-ZAAPBPzP; Fri, 9 Apr 2010 12:15:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 02AEB3A699F; Fri, 9 Apr 2010 12:15:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JcO-0006xC-RM for namedroppers-data0@psg.com; Fri, 09 Apr 2010 19:11:52 +0000 Received: from [2001:4f8:3:36::28] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JcK-0006wY-LP for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 19:11:48 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 1DEAB17D1ED; Fri, 9 Apr 2010 19:11:48 +0000 (UTC) Received: from dhcp-vlan13-91-252.home.flame.org (unknown [IPv6:2001:470:b8d7:13:61e:64ff:fef5:5604]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTPSA id 5354117D1EC; Fri, 9 Apr 2010 19:11:47 +0000 (UTC) Message-ID: <4BBF7BF2.8000502@isc.org> Date: Fri, 09 Apr 2010 14:11:46 -0500 From: Michael Graff User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> <4BBF6E97.1070807@isc.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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 4/9/10 2:01 PM, Edward Lewis wrote: > If that's the case, then this is solved (at least in the next draft as > far as I have seen it). The protocol has in it the opt-out option. > When a recursive server gets a query in with a edns-client-ip it is > forbidden to change the option. So, to "hide" a client could preempt > the edns-client-ip by inserting it's own "0.0.0.0/0" or v6 equivalent. So, then all the work we're doing is only useful until every DNS client out there does this by default. Or until someone releases a "privacy enhancer" for windows that sets this option by default. Or a home gateway vendor decides to add one on the user's behalf. One thing about privacy is that it's not for you to decide what I consider private, it's what I find important to be kept private, for I in {all people}. I personally feel it is all too easy to collect online habits already. Adding another method in the most integral application protocol the network uses seems bad to me. --Michael From owner-namedroppers@ops.ietf.org Fri Apr 9 12:23:56 2010 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 570E73A6A5E; Fri, 9 Apr 2010 12:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, 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 yJjtqZQ8Es7F; Fri, 9 Apr 2010 12:23:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B8A453A6936; Fri, 9 Apr 2010 12:21:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JhV-0007q2-3w for namedroppers-data0@psg.com; Fri, 09 Apr 2010 19:17:09 +0000 Received: from [2001:4f8:3:36::28] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JhR-0007oj-Iz for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 19:17:05 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 0A69917D1ED; Fri, 9 Apr 2010 19:17:05 +0000 (UTC) Received: from dhcp-vlan13-91-252.home.flame.org (unknown [IPv6:2001:470:b8d7:13:61e:64ff:fef5:5604]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTPSA id 7924F17D1EC; Fri, 9 Apr 2010 19:17:04 +0000 (UTC) Message-ID: <4BBF7D2F.2070700@isc.org> Date: Fri, 09 Apr 2010 14:17:03 -0500 From: Michael Graff User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Martin Barry CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 References: <4BBF6E97.1070807@isc.org> <20100409190241.GA23156@merboo.mamista.net> In-Reply-To: <20100409190241.GA23156@merboo.mamista.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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 4/9/10 2:02 PM, Martin Barry wrote: > The proposal dictated that it was not the exact IP address but some > enclosing subnet tagged with the appropriate netmask. > > Michael, would you still regard such "less accurate" leakage as a privacy > concern? I seem to remember a study a while back that said anyone in the USA could be identified 80% of the time with only three bits of personal information. http://www.citeulike.org/user/burd/article/5822736 So, given three bits of information is all that is needed, and an IP address is assumed to be a locality identifier here, a subnet is just as leaky as an IP address at some point. So yea, I don't think a subnet is sufficient to lessen my concerns. --Michael From owner-namedroppers@ops.ietf.org Fri Apr 9 12:26:27 2010 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 637733A6999; Fri, 9 Apr 2010 12:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.364 X-Spam-Level: * X-Spam-Status: No, score=1.364 tagged_above=-999 required=5 tests=[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 tg20XQAI5A8d; Fri, 9 Apr 2010 12:26:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 43CFF3A698F; Fri, 9 Apr 2010 12:26:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Jkv-0008Fn-Fn for namedroppers-data0@psg.com; Fri, 09 Apr 2010 19:20:41 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Jks-0008FR-U3 for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 19:20:39 +0000 Received: (qmail 29578 invoked by uid 399); 9 Apr 2010 19:20:37 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 Apr 2010 19:20:37 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BBF7E03.9020400@dougbarton.us> Date: Fri, 09 Apr 2010 12:20:35 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> In-Reply-To: <20100409154138.GK3595@shinkuro.com> X-Enigmail-Version: 1.0.1 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: On 04/09/10 08:41, Andrew Sullivan wrote: > > Quite apart from the novel jurisprudence entailed by a US corporation > "requiring" anything of foreign sovereign states, Andrew, This comment is unhelpful, and inappropriate. As you yourself have asked in the past, it would be helpful if we could stay focused on the technical aspects of the issue(s) and not go down ratholes regarding whether or not we agree with various policy aspects. I realize that being asked to provide what amounts to be (to some extent at least) a technical solution to a policy/legal problem is distasteful to some in the group. However, this is the world we live in, you may choose not to participate. But if you choose TO participate it should be done with civility. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From dmailer.ok@ietf.org Fri Apr 9 12:36:30 2010 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 6DA043A6A50 for ; Fri, 9 Apr 2010 12:36:30 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Fri, 9 Apr 2010 12:36:23 -0700 (PDT) Received: from 83-221-78-223.dynamic.primacom.net (83-221-78-223.dynamic.primacom.net [83.221.78.223]) by core3.amsl.com (Postfix) with SMTP id 35FE73A69BC for ; Fri, 9 Apr 2010 12:32:11 -0700 (PDT) From: Approved VIAGRA® Store Subject: News on myspace To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100409193215.35FE73A69BC@core3.amsl.com> Date: Fri, 9 Apr 2010 12:32:11 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 54572 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Fri Apr 9 12:42:03 2010 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 D11083A698F; Fri, 9 Apr 2010 12:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.279 X-Spam-Level: X-Spam-Status: No, score=-0.279 tagged_above=-999 required=5 tests=[AWL=-0.679, 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 lKZatbxi-oGA; Fri, 9 Apr 2010 12:42:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 910053A6A91; Fri, 9 Apr 2010 12:35:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JuK-0009Um-T0 for namedroppers-data0@psg.com; Fri, 09 Apr 2010 19:30:24 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0JuH-0009Ti-S7 for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 19:30:21 +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 42F021ECB400 for ; Fri, 9 Apr 2010 19:30:20 +0000 (UTC) Date: Fri, 9 Apr 2010 15:30:17 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Message-ID: <20100409193016.GB5755@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> <4BBF7E03.9020400@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBF7E03.9020400@dougbarton.us> 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 Fri, Apr 09, 2010 at 12:20:35PM -0700, Doug Barton wrote: > On 04/09/10 08:41, Andrew Sullivan wrote: > > > > Quite apart from the novel jurisprudence entailed by a US corporation > > "requiring" anything of foreign sovereign states, > > Andrew, > > This comment is unhelpful, and inappropriate. As you yourself have asked > in the past, it would be helpful if we could stay focused on the > technical aspects of the issue(s) and not go down ratholes regarding > whether or not we agree with various policy aspects. I think you're entirely right to point out that it's irrelevant to the technical matter, and I therefore withdraw it. I still believe there is a practical matter that impinges on the alternatives open to the WG if some top-level domains claim to have some system for keeping different trees "in sync", for whatever "sync" means. For practical purposes we will not be able to do anything that does not provide all the features of those (to-be-deployed) systems. I note that it will also be quite a bit harder to know what things we have to be compatible with if we do not understand what the features of those to-be-deployed systems are. This practical matter goes directly to the question of whether this WG ought to take on the work, since if there's no reasonable prospect for success of a work item we simply can't adopt it as part of the charter. > But if you choose TO participate it should be done with civility. I'm not sure what it was I said that was uncivil, but I certainly didn't intend to be. To those who understood my remarks to be uncivil, I apologise. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Apr 9 13:02:37 2010 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 59BB43A690C; Fri, 9 Apr 2010 13:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.859 X-Spam-Level: * X-Spam-Status: No, score=1.859 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_UNSUB22=0.948] 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 jVAyosCbYb2I; Fri, 9 Apr 2010 13:02:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 703783A67AD; Fri, 9 Apr 2010 13:02:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0KKp-000Cgb-Pc for namedroppers-data0@psg.com; Fri, 09 Apr 2010 19:57:47 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0KKn-000Cfx-94 for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 19:57:45 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o39JvPh4013275; Fri, 9 Apr 2010 15:57:26 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Fri, 09 Apr 2010 15:57:31 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 09 Apr 2010 15:57:31 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4BBF7BF2.8000502@isc.org> References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> Date: Fri, 9 Apr 2010 15:56:18 -0400 To: Michael Graff From: Edward Lewis Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 14:11 -0500 4/9/10, Michael Graff wrote: >So, then all the work we're doing is only useful until every DNS client >out there does this by default. Or until someone releases a "privacy >enhancer" for windows that sets this option by default. Or a home >gateway vendor decides to add one on the user's behalf. Rathole alert - changing the question after the answer. >One thing about privacy is that it's not for you to decide what I >consider private, it's what I find important to be kept private, for I >in {all people}. And I'm asked if I'm paranoid. >I personally feel it is all too easy to collect online habits already. >Adding another method in the most integral application protocol the >network uses seems bad to me. "Too easy" is subjective. I think this concern is the most unfounded here because the recursive server operator is already able to collect this information and use it or sell it. Especially in the use case envisioned for the proposal as written. (There's mention on the list of other cases too.) There are many ways to hide your tracks on the Internet. If you want to enhance your privacy, use them. We keep saying the Internet was designed to be insecure so you have to protect yourself. Is there now a declaration that the Internet is insecure but anonymous? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From owner-namedroppers@ops.ietf.org Fri Apr 9 13:09:42 2010 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 D4BE43A6910; Fri, 9 Apr 2010 13:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[AWL=-0.360, 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 w3NhY4nhZ0Fz; Fri, 9 Apr 2010 13:09:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5998B3A68AC; Fri, 9 Apr 2010 13:09:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0KT5-000Dit-PK for namedroppers-data0@psg.com; Fri, 09 Apr 2010 20:06:19 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0KT3-000DiV-9e for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 20:06:17 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id E58F9B7B6DD; Fri, 9 Apr 2010 13:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyZgreYu78bo; Fri, 9 Apr 2010 13:06:14 -0700 (PDT) Received: from [10.0.1.5] (cpe-70-95-123-210.hawaii.res.rr.com [70.95.123.210]) by virtualized.org (Postfix) with ESMTP id 3E3C2B7B6CB; Fri, 9 Apr 2010 13:06:14 -0700 (PDT) Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20100409190101.GY3595@shinkuro.com> Date: Fri, 9 Apr 2010 10:06:12 -1000 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6E367537-2785-4BEC-93EC-97B21A8600FF@virtualized.org> References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.org> <20100409180535.GQ3595@shinkuro.com> <20100409190101.GY3595@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1078) 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, On Apr 9, 2010, at 9:01 AM, Andrew Sullivan wrote: >> It is not a generic solution and applies only at the TLD level. >=20 > That is not what ICANN's documents currently claim, because the Plan > says (and the Q&A repeats) that the synchronization will be propagated > all the way down the trees. If that claim is not completely empty, > then similar mechanisms can be followed all the way down. Sorry, I was unclear. The solution is not generic and applies only at = the TLD level in the sense that it is a requirement imposed by ICANN on = the registries and it is the registries' responsibility to ensure that = the synchronization propagates down the tree for all the synchronized = names under the TLD. In theory, I suppose a domain name holder could apply this for the names = they have registered, but I suspect they'd rather use DNAME. >> If I remember correctly, it was that DNAME was felt by some to be an >> insufficient solution to the generic aliasing problem. >=20 > Yes. And now we have a particular proposal that does it all by > provisioning and contracts, and I'm not even sure which of the > scenarios (if any) I outlined is aimed at. I think the answer is "all > of them", No. As I understand it, synchronized domains is attempting to address a = very small subset of the aliasing problem, specifically = linguistically/culturally identical albeit visually dissimilar strings = that users expect to behave identically in the Fast Track IDN ccTLD = program.=20 > If the claim is that policy & provisioning won't scale, then it'd be > nice to know what the desired scaling properties of anything we might > do need to be, along with the other details I've asked for.=20 I would assume we'd want the same scaling properties as any other aspect = of the DNS. The scaling concerns I have is that synchronized domains = requires verification that the trees are remaining synchronized. For = one or two trees, that might be feasible (depending on how much splay = there is in the tree). However, imagine thousands of synchronized = domains. I honestly can't believe this would actually work. Regards, -drc From owner-namedroppers@ops.ietf.org Fri Apr 9 13:36:32 2010 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 36CF53A6965; Fri, 9 Apr 2010 13:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.208 X-Spam-Level: ** X-Spam-Status: No, score=2.208 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_UNSUB22=0.948] 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 6DLB4DOjI-cO; Fri, 9 Apr 2010 13:36:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 239033A698F; Fri, 9 Apr 2010 13:36:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Kr7-000GUC-HL for namedroppers-data0@psg.com; Fri, 09 Apr 2010 20:31:09 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Kr5-000GSa-2p for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 20:31:07 +0000 Received: (qmail 18697 invoked by uid 399); 9 Apr 2010 20:31:05 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 Apr 2010 20:31:05 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BBF8E87.2030207@dougbarton.us> Date: Fri, 09 Apr 2010 13:31:03 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Edward Lewis CC: Michael Graff , namedroppers@ops.ietf.org Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> In-Reply-To: X-Enigmail-Version: 1.0.1 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: On 04/09/10 12:56, Edward Lewis wrote: > At 14:11 -0500 4/9/10, Michael Graff wrote: > >> One thing about privacy is that it's not for you to decide what I >> consider private, it's what I find important to be kept private, for I >> in {all people}. > > And I'm asked if I'm paranoid. There is no de facto paranoia in Michael's statement, in either the cultural nor the clinical sense; and for the record I agree with his sentiment. >> I personally feel it is all too easy to collect online habits already. >> Adding another method in the most integral application protocol the >> network uses seems bad to me. > > "Too easy" is subjective. I think this concern is the most unfounded > here because the recursive server operator is already able to collect > this information and use it or sell it. But that's a "risk" that is already built into the status quo. > There are many ways to hide your tracks on the Internet. If you want to > enhance your privacy, use them. But this proposal dramatically reduces the effectiveness of existing solutions by adding yet another way for my Personally Identifiable Information (PII) to leak out into legal and administrative domains that I have no direct relationship with. To take one simple and obvious example, if I visit a site at *.yahoo.com I may have no problem with them having my PII, in fact some of their services require it. That's my decision. But Yahoo! uses Akamai for their CDN, and I have not chosen to have a relationship with them. In fact, the average Internet user would not even know who/what Akamai is, or why their information is being sent there. I am actually sympathetic to the concept of "DNS tricks" for CDNs, but this is going too far. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Fri Apr 9 14:24:15 2010 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 109FA3A69E1; Fri, 9 Apr 2010 14:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.458 X-Spam-Level: X-Spam-Status: No, score=-1.458 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 7oCuWPfOQL1h; Fri, 9 Apr 2010 14:24:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B20DD3A6A11; Fri, 9 Apr 2010 14:23:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Lbm-000LfZ-RD for namedroppers-data0@psg.com; Fri, 09 Apr 2010 21:19:22 +0000 Received: from [74.125.149.73] (helo=na3sys009aog104.obsmtp.com) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Lbk-000Ldn-86 for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 21:19:20 +0000 Received: from source ([209.85.160.43]) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKS7+Z11qpijRsNt2vR2Fna2jdyAe74qQR@postini.com; Fri, 09 Apr 2010 14:19:20 PDT Received: by pwj6 with SMTP id 6so3198091pwj.30 for ; Fri, 09 Apr 2010 14:19:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.154.147 with HTTP; Fri, 9 Apr 2010 14:19:19 -0700 (PDT) In-Reply-To: <4BBF8E87.2030207@dougbarton.us> References: <4BB3E324.2050207@isc.org> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> <4BBF8E87.2030207@dougbarton.us> Date: Fri, 9 Apr 2010 14:19:19 -0700 Received: by 10.141.90.11 with SMTP id s11mr1045178rvl.152.1270847959115; Fri, 09 Apr 2010 14:19:19 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 From: David Ulevitch To: Doug Barton Cc: IETF DNSEXT WG 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 Fri, Apr 9, 2010 at 1:31 PM, Doug Barton wrote: > I am actually sympathetic to the concept of "DNS tricks" for CDNs, but > this is going too far. I find this surprising. To the best of my knowledge, every major ISP (except perhaps Comcast and ATT) is selling or sharing their DNS data with third-parties. Nothing in this draft can even remotely be construed as worse than that practice. Nor does anything in this proposal create an information leakage worse than that. Nor does it "endorse" or support such behavior. And, of course, I'm in full support of a section of the draft discussing these issues and privacy concerns. This proposal is deliberately designed for and written by DNS providers that users OPT-IN to using. By that very definition, these users are asking for a service from a company they are establishing a relationship with. I can't think of anything less privacy-aware and privacy-sensitive than that. -David From owner-namedroppers@ops.ietf.org Fri Apr 9 14:30:52 2010 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 A88D83A69EF; Fri, 9 Apr 2010 14:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.786 X-Spam-Level: * X-Spam-Status: No, score=1.786 tagged_above=-999 required=5 tests=[AWL=0.422, 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 KTUV5FaJ1hyw; Fri, 9 Apr 2010 14:30:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3BA573A6900; Fri, 9 Apr 2010 14:30:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Ljm-000MaF-3s for namedroppers-data0@psg.com; Fri, 09 Apr 2010 21:27:38 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Ljj-000Ma4-KB for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 21:27:35 +0000 Received: (qmail 31395 invoked by uid 399); 9 Apr 2010 21:27:34 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 Apr 2010 21:27:34 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BBF9BC5.6060008@dougbarton.us> Date: Fri, 09 Apr 2010 14:27:33 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: David Ulevitch CC: IETF DNSEXT WG Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 References: <4BB3E324.2050207@isc.org> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> <4BBF8E87.2030207@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.0.1 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: On 04/09/10 14:19, David Ulevitch wrote: > On Fri, Apr 9, 2010 at 1:31 PM, Doug Barton > wrote: > >> I am actually sympathetic to the concept of "DNS tricks" for CDNs, >> but this is going too far. > > I find this surprising. I find a lot of things in this thread surprising. > To the best of my knowledge, every major ISP (except perhaps Comcast > and ATT) is selling or sharing their DNS data with third-parties. Aside from the obvious EANECDOTAL aspect of this statement, even taking it at face value what you're saying is that if I have a concern about privacy of my DNS query data I currently have a choice of using providers that don't share it. The proposal removes that choice from me. > Nothing in this draft can even remotely be construed as worse than > that practice. Nor does anything in this proposal create an > information leakage worse than that. Nor does it "endorse" or > support such behavior. And, of course, I'm in full support of a > section of the draft discussing these issues and privacy concerns. I'm sorry, there is not enough rationality in this paragraph for me to even respond to. > This proposal is deliberately designed for and written by DNS > providers that users OPT-IN to using. So the same providers that are currently getting information from their users "for free" and selling it without their users' knowledge are now going to put development dollars into an opt-out system that will then cost them money? Even assuming that signaling mechanisms for the client side were developed and deployed (which is not likely)? (And yes, I understand that the proposal says opt-in, but that's just smoke and mirrors.) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Fri Apr 9 14:37:41 2010 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 971113A6900; Fri, 9 Apr 2010 14:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=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 S51GnZIdB7Q6; Fri, 9 Apr 2010 14:37:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 652EC3A679C; Fri, 9 Apr 2010 14:37:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0LpK-000NBW-Fo for namedroppers-data0@psg.com; Fri, 09 Apr 2010 21:33:22 +0000 Received: from [65.99.1.130] (helo=abenaki.wabanaki.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0LpH-000NAW-Vd for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 21:33:20 +0000 Received: from limpet.local (cpe-67-244-32-202.twcny.res.rr.com [67.244.32.202]) by abenaki.wabanaki.net (8.14.4/8.14.3) with ESMTP id o39LTR36059374; Fri, 9 Apr 2010 17:29:27 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4BBF9D18.9050601@abenaki.wabanaki.net> Date: Fri, 09 Apr 2010 17:33:12 -0400 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: David Conrad CC: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.org> <20100409180535.GQ3595@shinkuro.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: David, Assuming just for the moment that we are discussing two proposed entries in the IANA root zone: 1. =E4=B8=AD=E5=9B=BD, xn--fiqs8s, "chung guo", "China", zh-hans 2. =E4=B8=AD=E5=9C=8B, xn--fiqz9s, "chung guo", "China", zh-hant Could you explain to me what "applies only at the TLD level" means? Assuming that there is one or more entry in each of the zones, and at least one of these is non-leaf, at what point does the ICANN posited mechanism cease to apply? I don't need a prompt answer, I'm simply asking because of the distinction between "applies only at the TLD level" and what I understood from the (rather peculiar, process and text) ICANN text which seems to ask for a recursive descent complete mechanism. Thanks for taking the time to pull on the slippery end of a worm. Eric On 4/9/10 2:47 PM, David Conrad wrote: > Andrew, >=20 > On Apr 9, 2010, at 8:05 AM, Andrew Sullivan wrote: >> If ICANN now actually implements some sort of aliasing using only >> contracts and provisioning rules, then that is evidence for the >> conclusion that the WG need do no more. =20 >=20 > No, it isn't. Synchronized domains is obviously a hack and it absolute= ly will not scale (I personally have my doubts it will even scale at n=3D= 1, but that's probably just me). It is not a generic solution and applie= s only at the TLD level. >=20 >> What is the problem that needs solving? >=20 > If I remember correctly, it was that DNAME was felt by some to be an in= sufficient solution to the generic aliasing problem. >=20 > Regards, > -drc >=20 >=20 >=20 >=20 >=20 From owner-namedroppers@ops.ietf.org Fri Apr 9 14:40:44 2010 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 1EB573A695F; Fri, 9 Apr 2010 14:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, 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 V9smJsAmC3NA; Fri, 9 Apr 2010 14:40:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 22AD03A679C; Fri, 9 Apr 2010 14:40:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Ltf-000NjZ-9L for namedroppers-data0@psg.com; Fri, 09 Apr 2010 21:37:51 +0000 Received: from [2001:4f8:3:36::28] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Ltd-000NjL-8X for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 21:37:49 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id C531817D1F1; Fri, 9 Apr 2010 21:37:48 +0000 (UTC) Received: from dhcp-vlan13-91-252.home.flame.org (unknown [IPv6:2001:470:b8d7:13:61e:64ff:fef5:5604]) (using SSLv3 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTPSA id 4F3CB17D1EF; Fri, 9 Apr 2010 21:37:47 +0000 (UTC) Message-ID: <4BBF9E2B.7080100@isc.org> Date: Fri, 09 Apr 2010 16:37:47 -0500 From: Michael Graff User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: David Ulevitch CC: IETF DNSEXT WG Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 References: <4BB3E324.2050207@isc.org> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> <4BBF8E87.2030207@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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 4/9/10 4:19 PM, David Ulevitch wrote: > This proposal is deliberately designed for and written by DNS > providers that users OPT-IN to using. By that very definition, these > users are asking for a service from a company they are establishing a > relationship with. I can't think of anything less privacy-aware and > privacy-sensitive than that. Users do NOT opt-in, they opt-out. An ISP will enable this and all their users suddenly have their subnets exposed to auth servers. A user must insert something into each query to opt-out, and I'm certain that won't be happening before this would be deployed. Or am I misunderstanding this? --Michael From owner-namedroppers@ops.ietf.org Fri Apr 9 14:40:54 2010 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 38FB23A679C; Fri, 9 Apr 2010 14:40:54 -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 QUHv12xRuLvH; Fri, 9 Apr 2010 14:40:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 519FF3A69A0; Fri, 9 Apr 2010 14:40:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0LtX-000Nhk-8V for namedroppers-data0@psg.com; Fri, 09 Apr 2010 21:37:43 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0LtU-000NhO-LU for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 21:37:40 +0000 Received: by pwi1 with SMTP id 1so3345985pwi.11 for ; Fri, 09 Apr 2010 14:37:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.50.19 with HTTP; Fri, 9 Apr 2010 14:37:39 -0700 (PDT) In-Reply-To: <4BBF9BC5.6060008@dougbarton.us> References: <4BB3E324.2050207@isc.org> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> <4BBF8E87.2030207@dougbarton.us> <4BBF9BC5.6060008@dougbarton.us> Date: Fri, 9 Apr 2010 14:37:39 -0700 Received: by 10.115.67.25 with SMTP id u25mr1014000wak.96.1270849060007; Fri, 09 Apr 2010 14:37:40 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 From: Matthew Dempsky To: Doug Barton Cc: IETF DNSEXT WG 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 Fri, Apr 9, 2010 at 2:27 PM, Doug Barton wrote: > Aside from the obvious EANECDOTAL aspect of this statement, even taking > it at face value what you're saying is that if I have a concern about > privacy of my DNS query data I currently have a choice of using > providers that don't share it. The proposal removes that choice from me. Uh, how exactly? Providers that currently choose not to share your IP address will surely continue to offer ways for you to prevent your IP address from being exposed even after this option is standardized. From owner-namedroppers@ops.ietf.org Fri Apr 9 14:45:13 2010 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 E46713A6928; Fri, 9 Apr 2010 14:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.811 X-Spam-Level: X-Spam-Status: No, score=-9.811 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HABEAS_ACCREDITED_SOI=-4.3, HELO_MISMATCH_COM=0.553, RCVD_IN_BSP_TRUSTED=-4.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 kT1NuWN9vX-E; Fri, 9 Apr 2010 14:45:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 75A083A6838; Fri, 9 Apr 2010 14:45:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Lxp-000OJ0-7s for namedroppers-data0@psg.com; Fri, 09 Apr 2010 21:42:09 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Lxm-000OGS-G3 for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 21:42:06 +0000 Received: (qmail 87423 invoked from network); 9 Apr 2010 21:42:05 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 9 Apr 2010 21:42:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k1004; olt=johnl@user.iecc.com; bh=8dGUHMPRbw1l4SQ4DGzISG/NHWzOZRKfqprYKHW+ucI=; b=Mzxijtk6j5v6co2y/DGV6Buc33mMNFil2uI7gJ1RShxlYvGSlThnAd3yDLV5UA3Vrf+2XxCQIqxOLINhdqV+1EinDoJAXi+179QHIgQicthZatjNjLG+AUiOtDQsVFBIYt/jEPx6ffKCDidHA7hkNVYc0XAvpcmhDilav+w6AVQ= Date: 9 Apr 2010 21:42:04 -0000 Message-ID: <20100409214204.58523.qmail@simone.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-Reply-To: <6E367537-2785-4BEC-93EC-97B21A8600FF@virtualized.org> Organization: Cc: drc@virtualized.org X-Headerized: yes Mime-Version: 1.0 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: >No. As I understand it, synchronized domains is attempting to >address a very small subset of the aliasing problem, specifically >linguistically/culturally identical albeit visually dissimilar >strings that users expect to behave identically in the Fast Track IDN >ccTLD program. That's my understanding, too. It's not a technical problem, it's a political problem, countries such as China that use non-Roman character sets want domain names entirely written in their own language. That's a perfectly reasonable thing to ask for, but as we've seen in painful detail, there's no reasonable way to migrate mechanically from DNS names in mixed ASCII and IDN to all IDN. As far as I can tell (and I hope Kim corrects me if I'm wrong), ICANN has no compliance plan for synchronized domains, nor any enforcement plan other than perhaps a polite reminder if they get out of sync. In practice, this probably won't make matter, since I expect the most likely sequence of events is that names that already have all but the last component in IDN will just flip from .cn to . or whatever. There's no obvious incentive to make names not match, so it'll probably work well enough. Other than trying to check for ways that this plan would break the DNS for others, I don't see a role for us. R's, John From owner-namedroppers@ops.ietf.org Fri Apr 9 14:45:29 2010 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 52E4D3A69C0; Fri, 9 Apr 2010 14:45:29 -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 H0eWDid-7pZu; Fri, 9 Apr 2010 14:45:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E7543A6928; Fri, 9 Apr 2010 14:45:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0LyW-000ONC-1Q for namedroppers-data0@psg.com; Fri, 09 Apr 2010 21:42:52 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0LyT-000OMo-RN for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 21:42:49 +0000 Received: by pwi1 with SMTP id 1so3350146pwi.11 for ; Fri, 09 Apr 2010 14:42:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.50.19 with HTTP; Fri, 9 Apr 2010 14:42:48 -0700 (PDT) In-Reply-To: <4BBF9E2B.7080100@isc.org> References: <4BB3E324.2050207@isc.org> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> <4BBF8E87.2030207@dougbarton.us> <4BBF9E2B.7080100@isc.org> Date: Fri, 9 Apr 2010 14:42:48 -0700 Received: by 10.115.67.25 with SMTP id u25mr1021472wak.96.1270849368319; Fri, 09 Apr 2010 14:42:48 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 From: Matthew Dempsky To: Michael Graff Cc: IETF DNSEXT WG 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, Apr 9, 2010 at 2:37 PM, Michael Graff wrote: > Users do NOT opt-in, they opt-out. =A0An ISP will enable this and all > their users suddenly have their subnets exposed to auth servers. =A0A use= r > must insert something into each query to opt-out, and I'm certain that > won't be happening before this would be deployed. > > Or am I misunderstanding this? OpenDNS, Comcast, and possibly others offer out of band configuration options for controlling what DNS experience they get on a per-IP-address basis. This doesn't require any DNS client software updates. From owner-namedroppers@ops.ietf.org Fri Apr 9 14:49:31 2010 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 37B443A6A12; Fri, 9 Apr 2010 14:49:31 -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 xE5y0K6LdRKO; Fri, 9 Apr 2010 14:49:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3721F3A6928; Fri, 9 Apr 2010 14:49:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0M1w-000PAG-Gm for namedroppers-data0@psg.com; Fri, 09 Apr 2010 21:46:24 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0M1u-000P9T-1G for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 21:46:22 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id D5180B7BB41; Fri, 9 Apr 2010 14:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6hWY9Pyz7ss; Fri, 9 Apr 2010 14:46:18 -0700 (PDT) Received: from [192.168.1.81] (rrcs-74-87-61-153.west.biz.rr.com [74.87.61.153]) by virtualized.org (Postfix) with ESMTP id 4BFE2B7BB30; Fri, 9 Apr 2010 14:46:18 -0700 (PDT) Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <4BBF9D18.9050601@abenaki.wabanaki.net> Date: Fri, 9 Apr 2010 11:46:17 -1000 Cc: "namedroppers@ops.ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.org> <20100409180535.GQ3595@shinkuro.com> <4BBF9D18.9050601@abenaki.wabanaki.net> To: Eric Brunner-Williams X-Mailer: Apple Mail (2.1078) 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, In my follow-up to Andrew's note, I tried to clarify. Will try again. On Apr 9, 2010, at 11:33 AM, Eric Brunner-Williams wrote: > Could you explain to me what "applies only at the TLD level" means? It means that if example.com decided to implement synchronized domains = starting at the third level that they manage, ICANN would (of course) = have no role. The synchronized domains are a proposed solution to deal = with a particular set of labels that originate at the TLD level. That is, this isn't a generic solution to the domain aliasing problem I = thought DNSEXT was looking into. Apologies for the lack of clarity. Regards, -drc From owner-namedroppers@ops.ietf.org Fri Apr 9 15:10:06 2010 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 16A8C3A698E; Fri, 9 Apr 2010 15:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, 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 VIDFz63Vvbf8; Fri, 9 Apr 2010 15:10:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A2A493A694D; Fri, 9 Apr 2010 15:10:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0MLI-00029i-EO for namedroppers-data0@psg.com; Fri, 09 Apr 2010 22:06:24 +0000 Received: from [2001:4f8:3:36::28] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0MLG-00029M-13 for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 22:06:22 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 8BA2417D1F1; Fri, 9 Apr 2010 22:06:21 +0000 (UTC) Received: from dhcp-vlan13-91-252.home.flame.org (unknown [IPv6:2001:470:b8d7:13:61e:64ff:fef5:5604]) (using SSLv3 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTPSA id 1799F17D1EF; Fri, 9 Apr 2010 22:06:20 +0000 (UTC) Message-ID: <4BBFA4DC.7060506@isc.org> Date: Fri, 09 Apr 2010 17:06:20 -0500 From: Michael Graff User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Matthew Dempsky CC: IETF DNSEXT WG Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 References: <4BB3E324.2050207@isc.org> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> <4BBF8E87.2030207@dougbarton.us> <4BBF9E2B.7080100@isc.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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 4/9/10 4:42 PM, Matthew Dempsky wrote: > OpenDNS, Comcast, and possibly others offer out of band configuration > options for controlling what DNS experience they get on a > per-IP-address basis. This doesn't require any DNS client software > updates. What you describe is an opt-out, not an opt-in. That said... This sounds like the "DNS servers would do..." argument when someone really means "BIND 9" does. Except than there are a whole lot more players than there are in the DNS server software arena. What two ISPs do means just that: two ISPs might decide that allowing users to opt out of this is a reasonable thing to do. It doesn't cover the rest of the planet. For this to really be an opt-out, the client needs to insert the opt-out records. After all, my laptop isn't always at home, but I'd like my privacy to follow me, not remain at home while I'm out. --Michael From fornicate4@temporallabs.net Fri Apr 9 15:10:36 2010 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 D14D13A698E; Fri, 9 Apr 2010 15:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.301 X-Spam-Level: X-Spam-Status: No, score=-78.301 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MINDSPRING=0.45, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MINDSPRING=2.2, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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_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 E8+p+ef+u4bj; Fri, 9 Apr 2010 15:10:36 -0700 (PDT) Received: from user-142g0a5.cable.mindspring.com (user-142g0a5.cable.mindspring.com [72.40.1.69]) by core3.amsl.com (Postfix) with ESMTP id D8CCC3A694D; Fri, 9 Apr 2010 15:10:34 -0700 (PDT) Received: from 72.40.1.69 by mx2.daemonmail.net; Fri, 9 Apr 2010 18:09:55 -0500 Message-ID: <000d01cad831$62d9abb0$6400a8c0@fornicate4> From: dnsext-archive@lists.ietf.org To: Subject: I can do for you is - what can not no girl! Date: Fri, 9 Apr 2010 18:09:55 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD831.62D9ABB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2800.1437 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD831.62D9ABB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'll see you I really liked - let's get acquainted! I am from Russia! Visit= Our Site ------=_NextPart_000_0007_01CAD831.62D9ABB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'll see you I really liked - let's get acquainte= d! I am from Russia! Visit Our Site
<= /BODY> ------=_NextPart_000_0007_01CAD831.62D9ABB0-- From fornicate4@temporallabs.net Fri Apr 9 15:10:36 2010 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 D14D13A698E; Fri, 9 Apr 2010 15:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.301 X-Spam-Level: X-Spam-Status: No, score=-78.301 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MINDSPRING=0.45, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MINDSPRING=2.2, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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_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 E8+p+ef+u4bj; Fri, 9 Apr 2010 15:10:36 -0700 (PDT) Received: from user-142g0a5.cable.mindspring.com (user-142g0a5.cable.mindspring.com [72.40.1.69]) by core3.amsl.com (Postfix) with ESMTP id D8CCC3A694D; Fri, 9 Apr 2010 15:10:34 -0700 (PDT) Received: from 72.40.1.69 by mx2.daemonmail.net; Fri, 9 Apr 2010 18:09:55 -0500 Message-ID: <000d01cad831$62d9abb0$6400a8c0@fornicate4> From: dnsext-archive@lists.ietf.org To: Subject: I can do for you is - what can not no girl! Date: Fri, 9 Apr 2010 18:09:55 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD831.62D9ABB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2800.1437 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD831.62D9ABB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'll see you I really liked - let's get acquainted! I am from Russia! Visit= Our Site ------=_NextPart_000_0007_01CAD831.62D9ABB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'll see you I really liked - let's get acquainte= d! I am from Russia! Visit Our Site
<= /BODY> ------=_NextPart_000_0007_01CAD831.62D9ABB0-- From dnsop-bounces@ietf.org Fri Apr 9 15:10:38 2010 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886743A698E for ; Fri, 9 Apr 2010 15:10:38 -0700 (PDT) Subject: The results of your email commands From: dnsop-bounces@ietf.org To: dnsext-archive@lists.ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1281976272==" Message-ID: Date: Fri, 09 Apr 2010 15:10:37 -0700 Precedence: bulk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF DNSOP WG mailing list X-List-Administrivia: yes Sender: dnsop-bounces@ietf.org Errors-To: dnsop-bounces@ietf.org --===============1281976272== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Unprocessed: Our Site - Done. --===============1281976272== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: dnsop-request@core3.amsl.com Delivered-To: dnsop-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14D13A698E; Fri, 9 Apr 2010 15:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.301 X-Spam-Level: X-Spam-Status: No, score=-78.301 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MINDSPRING=0.45, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MINDSPRING=2.2, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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_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 E8+p+ef+u4bj; Fri, 9 Apr 2010 15:10:36 -0700 (PDT) Received: from user-142g0a5.cable.mindspring.com (user-142g0a5.cable.mindspring.com [72.40.1.69]) by core3.amsl.com (Postfix) with ESMTP id D8CCC3A694D; Fri, 9 Apr 2010 15:10:34 -0700 (PDT) Received: from 72.40.1.69 by mx2.daemonmail.net; Fri, 9 Apr 2010 18:09:55 -0500 Message-ID: <000d01cad831$62d9abb0$6400a8c0@fornicate4> From: dnsext-archive@lists.ietf.org To: Subject: I can do for you is - what can not no girl! Date: Fri, 9 Apr 2010 18:09:55 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD831.62D9ABB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2800.1437 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD831.62D9ABB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'll see you I really liked - let's get acquainted! I am from Russia! Visit= Our Site ------=_NextPart_000_0007_01CAD831.62D9ABB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'll see you I really liked - let's get acquainte= d! I am from Russia! Visit Our Site
<= /BODY> ------=_NextPart_000_0007_01CAD831.62D9ABB0-- --===============1281976272==-- From owner-namedroppers@ops.ietf.org Fri Apr 9 15:27:43 2010 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 904E03A6A46; Fri, 9 Apr 2010 15:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 Yo80zsw1H-HW; Fri, 9 Apr 2010 15:27:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D6D843A6A21; Fri, 9 Apr 2010 15:27:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Mc9-0004Bl-1D for namedroppers-data0@psg.com; Fri, 09 Apr 2010 22:23:49 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Mc5-0004Ap-JH for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 22:23:45 +0000 Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id B2633A94480; Fri, 9 Apr 2010 22:23:44 +0000 (UTC) Message-ID: <4BBFA8EE.5090400@mail-abuse.org> Date: Fri, 09 Apr 2010 15:23:42 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: David Conrad CC: Andrew Sullivan , namedroppers@ops.ietf.org, John Klensin Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.org> <20100409180535.GQ3595@shinkuro.com> <20100409190101.GY3595@shinkuro.com> <6E367537-2785-4BEC-93EC-97B21A8600FF@virtualized.org> In-Reply-To: <6E367537-2785-4BEC-93EC-97B21A8600FF@virtualized.org> 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 4/9/10 1:06 PM, David Conrad wrote: > Andrew, > > On Apr 9, 2010, at 9:01 AM, Andrew Sullivan wrote: > >>> It is not a generic solution and applies only at the TLD level. >>> >> That is not what ICANN's documents currently claim, because the Plan >> says (and the Q&A repeats) that the synchronization will be propagated >> all the way down the trees. If that claim is not completely empty, >> then similar mechanisms can be followed all the way down. >> > Sorry, I was unclear. The solution is not generic and applies only at the TLD level in the sense that it is a requirement imposed by ICANN on the registries and it is the registries' responsibility to ensure that the synchronization propagates down the tree for all the synchronized names under the TLD. > John Klensin expressed a desire for a means to determine name bundles, such as tld-1, tld-2, and tld-3 represent the same TLD. This would not scale, but there is a way for one domain to authorize any other domain in a scalable fashion. Domains below TLD bundles would need to be cloned or synthesized using CNAMEs. Cloning will represent added cost for domain holders to ensure unified mailboxes, purchase a bundle of certificates, etc. To assist in that effort, one might imagine domains could contain meta-information describing a name bundle set. This might require something similar to what Paul Vixie has described in: http://tools.ietf.org/search/draft-vixie-dnsext-dnsshadow > In theory, I suppose a domain name holder could apply this for the names they have registered, but I suspect they'd rather use DNAME. > DNAME does not offer a workable solution as this requires a non-aliased label in which to publish a single redirection. There was draft by Jiankang YAO et al, to use BNAME as a means to synthesize CNAMEs from the BNAME onward. http://tools.ietf.org/id/draft-yao-dnsext-bname This copies the NS records, but neglects treatment for MX records which are not to use CNAME as targets. Based upon advice given by a content delivery provider, tens of thousands of corporate domains now use a CNAME to locate an intermediate host in mail's journey to its final destination. Only the final destination has a valid MX record. John Klensin insisted a synthesis approach would be unacceptable as a result of the MX issue. However, BNAME synthesis would help consolidate recognizable names and the certificates needed. >>> If I remember correctly, it was that DNAME was felt by some to be an >>> insufficient solution to the generic aliasing problem. >>> >> Yes. And now we have a particular proposal that does it all by >> provisioning and contracts, and I'm not even sure which of the >> scenarios (if any) I outlined is aimed at. I think the answer is "all >> of them", >> > No. As I understand it, synchronized domains is attempting to address a very small subset of the aliasing problem, specifically linguistically/culturally identical albeit visually dissimilar strings that users expect to behave identically in the Fast Track IDN ccTLD program. > IDNA2008 declares some domains as being illegal. One could presume such domains would return NXDOMAIN rather than being aliased to a legal character-set that had been previously case-folded, as example. Depending upon how that might be resolved, the scope could be bigger than expected. >> If the claim is that policy& provisioning won't scale, then it'd be >> nice to know what the desired scaling properties of anything we might >> do need to be, along with the other details I've asked for. >> > I would assume we'd want the same scaling properties as any other aspect of the DNS. The scaling concerns I have is that synchronized domains requires verification that the trees are remaining synchronized. For one or two trees, that might be feasible (depending on how much splay there is in the tree). However, imagine thousands of synchronized domains. I honestly can't believe this would actually work.\ > In the case of zone cloning, there would be increased overhead related to signatures being created during the cloning process, and a lower cache hit rate that would affect both client and server. Whenever aliased domains have been referenced, clients would see a greater impact with CNAME synthesis. One would therefore hope that normally the alias is displayed. As far as obeying the rules, it would seem that only zone cloning can achieve this goal, but either approach could be made to work. -Doug From owner-namedroppers@ops.ietf.org Fri Apr 9 15:33:21 2010 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 2DD0C3A6A5A; Fri, 9 Apr 2010 15:33:21 -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 yg5TDlo2uXhH; Fri, 9 Apr 2010 15:33:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A1FF3A68B3; Fri, 9 Apr 2010 15:33:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Mht-0004m1-Ol for namedroppers-data0@psg.com; Fri, 09 Apr 2010 22:29:45 +0000 Received: from [74.125.83.180] (helo=mail-pv0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Mhr-0004lf-5B for namedroppers@ops.ietf.org; Fri, 09 Apr 2010 22:29:43 +0000 Received: by pvc22 with SMTP id 22so2426341pvc.11 for ; Fri, 09 Apr 2010 15:29:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.50.19 with HTTP; Fri, 9 Apr 2010 15:29:42 -0700 (PDT) In-Reply-To: <4BBFA4DC.7060506@isc.org> References: <4BB3E324.2050207@isc.org> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> <4BBF8E87.2030207@dougbarton.us> <4BBF9E2B.7080100@isc.org> <4BBFA4DC.7060506@isc.org> Date: Fri, 9 Apr 2010 15:29:42 -0700 Received: by 10.114.50.6 with SMTP id x6mr1187341wax.54.1270852182115; Fri, 09 Apr 2010 15:29:42 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 From: Matthew Dempsky To: Michael Graff Cc: IETF DNSEXT WG 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, Apr 9, 2010 at 3:06 PM, Michael Graff wrote: > On 4/9/10 4:42 PM, Matthew Dempsky wrote: >> OpenDNS, Comcast, and possibly others offer out of band configuration >> options for controlling what DNS experience they get on a >> per-IP-address basis. =A0This doesn't require any DNS client software >> updates. > > What you describe is an opt-out, not an opt-in. I was addressing your concern that DNS client software has to be updated first. The issue of whether it's an opt-out or opt-in simply depends on the default provisioning. > What two ISPs do means just that: =A0two ISPs might decide that allowing > users to opt out of this is a reasonable thing to do. =A0It doesn't cover > the rest of the planet. That's exactly my point. The Internet is heterogenous. But there's this moral panic rising over this draft because people seem to think that once there's a standard way to do something that people are in practice already doing, that it will *require* *everyone* to start doing it. > For this to really be an opt-out, the client needs to insert the opt-out > records. =A0After all, my laptop isn't always at home, but I'd like my > privacy to follow me, not remain at home while I'm out. If you want to maintain privacy on your laptop, you'll need to make sure you setup a VPN connection everywhere you go, and in which case, it's the same thing. You provision your VPS provider to respect your privacy, and then it doesn't matter where you are. From owner-namedroppers@ops.ietf.org Fri Apr 9 17:39:19 2010 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 B4A423A67B2; Fri, 9 Apr 2010 17:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.292, 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 NsmPPh9Bud+w; Fri, 9 Apr 2010 17:39:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 06FD13A659A; Fri, 9 Apr 2010 17:39:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0OaP-000Ha6-Nj for namedroppers-data0@psg.com; Sat, 10 Apr 2010 00:30:09 +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.71 (FreeBSD)) (envelope-from ) id 1O0OaL-000HYG-Nk for namedroppers@ops.ietf.org; Sat, 10 Apr 2010 00:30:05 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C80CAA1688 for ; Sat, 10 Apr 2010 00:30:04 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 In-Reply-To: Your message of "Fri, 09 Apr 2010 14:19:19 MST." References: <4BB3E324.2050207@isc.org> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> <4BBF8E87.2030207@dougbarton.us> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sat, 10 Apr 2010 00:30:04 +0000 Message-ID: <33529.1270859404@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: Fri, 9 Apr 2010 14:19:19 -0700 > From: David Ulevitch > > This proposal is deliberately designed for and written by DNS providers > that users OPT-IN to using. By that very definition, these users are > asking for a service from a company they are establishing a relationship > with. I can't think of anything less privacy-aware and privacy-sensitive > than that. so nxdomain-remapping policy-routing udp/53-thieving hotels could not add this new OPT blob and have it contain PII that authority servers would see? please point me to the specific design elements which would prevent this? From owner-namedroppers@ops.ietf.org Fri Apr 9 19:42:12 2010 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 6D3443A6842; Fri, 9 Apr 2010 19:42:12 -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 Y+WuVGW4lVab; Fri, 9 Apr 2010 19:42:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6ABEB3A6840; Fri, 9 Apr 2010 19:42:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0QYo-0005TR-W5 for namedroppers-data0@psg.com; Sat, 10 Apr 2010 02:36:38 +0000 Received: from [209.85.217.224] (helo=mail-gx0-f224.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0QYm-0005Rc-3C for namedroppers@ops.ietf.org; Sat, 10 Apr 2010 02:36:36 +0000 Received: by gxk24 with SMTP id 24so1991182gxk.18 for ; Fri, 09 Apr 2010 19:36:35 -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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=J99DtTXKepySBjWSWaooq3zdr97QAvHMuPdnRHzrxwc=; b=S+bask3kAvDQ3G1xQPLsTZxBI2gd6SUvZHqvjXtPkzew8Y4GRTvNS6MRXEGeMy0lAo v9VrA+FGDdGoY1vLPJxvj7bBISd2cDPrgnyfSfLES/sryhP+lDlhMP6/p3cm1GvAoctq 7l19DLpJ2JMwJjt/XJL0WTG6XbhwXqJ7FLCNY= 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 :cc:content-type:content-transfer-encoding; b=DIKrOGCUJgF2sx2KhVxIbV+PNd9APKgrvO79MVP2Ypcq2bFWyCKOnb0TWjS+PW+Pic Ta3xYy8oY5rZ58dVC5crBlpG06MqWRvkWAhq02GNpA8HenxQjAeb4QkcVMsGsGRo0IdT JmsGc1XM84mioBUm6icjffT/360QJkMI/hDlA= MIME-Version: 1.0 Received: by 10.100.91.5 with HTTP; Fri, 9 Apr 2010 19:36:35 -0700 (PDT) In-Reply-To: <20100409190101.GY3595@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.org> <20100409180535.GQ3595@shinkuro.com> <20100409190101.GY3595@shinkuro.com> Date: Fri, 9 Apr 2010 23:36:35 -0300 Received: by 10.101.106.32 with SMTP id i32mr1415310anm.249.1270866995133; Fri, 09 Apr 2010 19:36:35 -0700 (PDT) Message-ID: Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work From: Brian Dickson To: Andrew Sullivan Cc: 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: I think there is a bit of a log-jam in terms of local goals of the groups which necessarily involved, versus the potential global goal-set which has the possibility of exceeding all local goals, with minimal protocol change. ICANN are concerned with the root and TLDs, but there ends their mandate. Our WG needs clear requirements to avoid rat-holing. The TLDs need to provision and serve whatever is mandated by ICANN. DNS software vendors need RFCs to ensure interoperability. And the registrants, particularly in the IDN space, need something of real value, especially beyond just the TLDs, to make it worth doing IDNs in the first p= lace. I think it would be a useful exercise to "proffer" solution "sets" - slightly more abstract than particular implementations or protocol-specific IDs, but which associate a potential set of goals, along with the set of restrictions presumed, and the impact to protocol-level, provisioning, and scoping the changes (e.g. along the lines of Paul Vixies analysis of which DNS parties are or are not impacted by the protocol changes). Putting forward a set (possibly of size 0, 1, or other small integer) and getting feedback from the other groups, is what IMHO is needed to break the log-jam. Being able to say, "Here is what we can do, please choose one" limits our rat-holes, if we choose to not offer rat-holes up as options. And, at the same time, if it is easy to do something which provides an "all of the above" solution, nearly trivially, and with changes only to elements which were recently added, the long-tail problem can mostly be factored out. (I am thinking of DNSSEC validators as the impacted element, as an example case - they're new, and changing them in ways that are still backwards compatible to the current rules, is likely to see rapid and complete uptake, among those who already have validators deployed.) It's a bit backwards, but if we have some things we know we can deliver without great pains or efforts, being able to ask "Is this what you were thinking? Or how about this? Or this? Or none of the above?", might make the conversation go faster and easier. And if we get anything other than "none of the above", as a consistent answer, then our part is as simple as saying, "Fine, we do = so." IMHO. Brian On Fri, Apr 9, 2010 at 4:01 PM, Andrew Sullivan wrote: > On Fri, Apr 09, 2010 at 08:47:29AM -1000, David Conrad wrote: > >> It is not a generic solution and applies only at the TLD level. > > That is not what ICANN's documents currently claim, because the Plan > says (and the Q&A repeats) that the synchronization will be propagated > all the way down the trees. =A0If that claim is not completely empty, > then similar mechanisms can be followed all the way down. > >> If I remember correctly, it was that DNAME was felt by some to be an >> insufficient solution to the generic aliasing problem. > > Yes. =A0And now we have a particular proposal that does it all by > provisioning and contracts, and I'm not even sure which of the > scenarios (if any) I outlined is aimed at. =A0I think the answer is "all > of them", and I think that is therefore an existence proof that > everything can be done in policy & provisioning today. =A0(I think I've > now said this every way I can think to do, so I won't repeat it in > detail again.) > > If the claim is that policy & provisioning won't scale, then it'd be > nice to know what the desired scaling properties of anything we might > do need to be, along with the other details I've asked for. > > With emphasis: no decision here. =A0I'm just trying to understand the > problem we're trying to solve. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > > From owner-namedroppers@ops.ietf.org Fri Apr 9 20:04:16 2010 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 768183A67F7; Fri, 9 Apr 2010 20:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[AWL=0.310, 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 nZBvD+pD7asb; Fri, 9 Apr 2010 20:04:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8FD7E3A6781; Fri, 9 Apr 2010 20:04:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Qw3-00087J-GN for namedroppers-data0@psg.com; Sat, 10 Apr 2010 03:00:39 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Qw1-000871-40 for namedroppers@ops.ietf.org; Sat, 10 Apr 2010 03:00:37 +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 o3A30MMb001481; Fri, 9 Apr 2010 20:00:23 -0700 (PDT) Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <33529.1270859404@nsa.vix.com> Date: Fri, 9 Apr 2010 20:00:22 -0700 Cc: Nicholas Weaver , IETF DNSEXT WG Content-Transfer-Encoding: quoted-printable Message-Id: <0EFFB409-8BDE-4C4D-8C6D-AA8417F22CF2@icsi.berkeley.edu> References: <4BB3E324.2050207@isc.org> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> <4BBF8E87.2030207@dougbarton.us> <33529.1270859404@nsa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.1078) 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 Apr 9, 2010, at 5:30 PM, Paul Vixie wrote: >> Date: Fri, 9 Apr 2010 14:19:19 -0700 >> From: David Ulevitch >>=20 >> This proposal is deliberately designed for and written by DNS = providers >> that users OPT-IN to using. By that very definition, these users are >> asking for a service from a company they are establishing a = relationship >> with. I can't think of anything less privacy-aware and = privacy-sensitive >> than that. >=20 > so nxdomain-remapping policy-routing udp/53-thieving hotels could not = add > this new OPT blob and have it contain PII that authority servers would = see? Why would such a hotel bother? If the information has value, sell it = directly. >=20 > please point me to the specific design elements which would prevent = this? >=20 From steamrollingd6125@asr-performance.com Fri Apr 9 20:26:37 2010 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 926BF3A67F7 for ; Fri, 9 Apr 2010 20:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -59.528 X-Spam-Level: X-Spam-Status: No, score=-59.528 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, 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_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_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, SARE_ADLTSUB2=1.23, SARE_ADULT2=1.42, SARE_RECV_SPAM_DOMN02=1.666, SARE_SUB_PORN_WORD02=0.778, 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 xKBy3SdBPGHV for ; Fri, 9 Apr 2010 20:26:36 -0700 (PDT) Received: from 189-69-74-82.dsl.telesp.net.br (189-69-74-82.dsl.telesp.net.br [189.69.74.82]) by core3.amsl.com (Postfix) with ESMTP id 317483A63D3 for ; Fri, 9 Apr 2010 20:26:35 -0700 (PDT) Received: from 189.69.74.82 by mx1a.clickcom.com; Sat, 10 Apr 2010 00:25:44 -0300 Message-ID: <000d01cad85d$80f553c0$6400a8c0@steamrollingd6125> From: dnsext-archive@lists.ietf.org To: Subject: I am your Russian pussy - you remember my nickname? Date: Sat, 10 Apr 2010 00:25:44 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAD85D.80F553C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2905 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2900.2905 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAD85D.80F553C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi sweety! Remember me? Click Here ------=_NextPart_000_0007_01CAD85D.80F553C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi sweety! Remember me? Click Here
------=_NextPart_000_0007_01CAD85D.80F553C0-- From owner-namedroppers@ops.ietf.org Fri Apr 9 21:20:22 2010 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 47D9D3A69C1; Fri, 9 Apr 2010 21:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 ud7DjwTL4C79; Fri, 9 Apr 2010 21:20:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A4D9E3A6AD0; Fri, 9 Apr 2010 21:19:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0S5X-000FcN-IL for namedroppers-data0@psg.com; Sat, 10 Apr 2010 04:14:31 +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.71 (FreeBSD)) (envelope-from ) id 1O0S5V-000Fc5-1p for namedroppers@ops.ietf.org; Sat, 10 Apr 2010 04:14:29 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A3C9AA16B5 for ; Sat, 10 Apr 2010 04:14:28 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 In-Reply-To: Your message of "Fri, 09 Apr 2010 20:00:22 MST." <0EFFB409-8BDE-4C4D-8C6D-AA8417F22CF2@icsi.berkeley.edu> References: <4BB3E324.2050207@isc.org> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> <4BBF8E87.2030207@dougbarton.us> <33529.1270859404@nsa.vix.com> <0EFFB409-8BDE-4C4D-8C6D-AA8417F22CF2@icsi.berkeley.edu> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sat, 10 Apr 2010 04:14:28 +0000 Message-ID: <43078.1270872868@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: Nicholas Weaver > Date: Fri, 9 Apr 2010 20:00:22 -0700 > > Why would such a hotel bother? If the information has value, sell it > directly. that's not an answer to my question. i would like an answer to my question. however, in answer to your sidebar, most harm (by volume, from the big bang through now and likely continuing until heat death) has been, is, and will be accidental. my question again: > so nxdomain-remapping policy-routing udp/53-thieving hotels could not add > this new OPT blob and have it contain PII that authority servers would see? From owner-namedroppers@ops.ietf.org Fri Apr 9 21:39:46 2010 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 64F843A68DF; Fri, 9 Apr 2010 21:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.816 X-Spam-Level: X-Spam-Status: No, score=-4.816 tagged_above=-999 required=5 tests=[AWL=0.232, 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 T9PaS0NTxnch; Fri, 9 Apr 2010 21:39:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CE1AF3A68C1; Fri, 9 Apr 2010 21:39:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0SQH-000HkQ-G7 for namedroppers-data0@psg.com; Sat, 10 Apr 2010 04:35:57 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0SQF-000HkA-78 for namedroppers@ops.ietf.org; Sat, 10 Apr 2010 04:35:55 +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 o3A4Ze0K008386; Fri, 9 Apr 2010 21:35:40 -0700 (PDT) Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <43078.1270872868@nsa.vix.com> Date: Fri, 9 Apr 2010 21:35:40 -0700 Cc: Nicholas Weaver , IETF DNSEXT WG Content-Transfer-Encoding: quoted-printable Message-Id: <6001F445-1DF4-45EF-BF56-0A7CFFE9C823@icsi.berkeley.edu> References: <4BB3E324.2050207@isc.org> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> <4BBF8E87.2030207@dougbarton.us> <33529.1270859404@nsa.vix.com> <0EFFB409-8BDE-4C4D-8C6D-AA8417F22CF2@icsi.berkeley.edu> <43078.1270872868@nsa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.1078) 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 Apr 9, 2010, at 9:14 PM, Paul Vixie wrote: >> From: Nicholas Weaver >> Date: Fri, 9 Apr 2010 20:00:22 -0700 >>=20 >> Why would such a hotel bother? If the information has value, sell it >> directly. >=20 > that's not an answer to my question. i would like an answer to my = question. Yes it IS an answer, because the question you raise is really nonsense = as an objection. You can just as easily ask "is there anything that prevents the hotel = from simply selling the complete feed of my DNS requests to the highest = bidder?" and, well, the answer is no. The question is WHAT information would the hotel be exfiltrating that = isn't already inadvertantly exfiltrated anyway simply based on RESOLVER = IP, and WHY they would bother with uncompensated exfiltration. From owner-namedroppers@ops.ietf.org Fri Apr 9 23:10:25 2010 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 790033A693F; Fri, 9 Apr 2010 23:10:25 -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 9j-y2AJP3ssB; Fri, 9 Apr 2010 23:10:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3754E3A692E; Fri, 9 Apr 2010 23:10:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Tnm-0000yN-Ky for namedroppers-data0@psg.com; Sat, 10 Apr 2010 06:04:18 +0000 Received: from [74.125.149.69] (helo=na3sys009aog102.obsmtp.com) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Tnj-0000xy-US for namedroppers@ops.ietf.org; Sat, 10 Apr 2010 06:04:16 +0000 Received: from source ([209.85.160.45]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKS8AU3r82sx1dHBSA/vbcx5ydhhbOt5n1@postini.com; Fri, 09 Apr 2010 23:04:15 PDT Received: by pwi6 with SMTP id 6so3196496pwi.18 for ; Fri, 09 Apr 2010 23:04:14 -0700 (PDT) Received: by 10.141.90.11 with SMTP id s11mr1304276rvl.152.1270879454489; Fri, 09 Apr 2010 23:04:14 -0700 (PDT) Received: from [10.106.169.145] ([166.205.137.202]) by mx.google.com with ESMTPS id 20sm1599564pzk.11.2010.04.09.23.04.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 23:04:13 -0700 (PDT) References: <4BB3E324.2050207@isc.org> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> <4BBF8E87.2030207@dougbarton.us> <33529.1270859404@nsa.vix.com> Message-Id: <91D0FB82-1319-4688-9E5E-97598EF0EB5A@ulevitch.com> From: David Ulevitch To: Paul Vixie In-Reply-To: <33529.1270859404@nsa.vix.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 Date: Fri, 9 Apr 2010 23:04:04 -0700 Cc: IETF DNSEXT WG 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 Apr 9, 2010, at 5:30 PM, Paul Vixie wrote: >> Date: Fri, 9 Apr 2010 14:19:19 -0700 >> From: David Ulevitch >> >> This proposal is deliberately designed for and written by DNS >> providers >> that users OPT-IN to using. By that very definition, these users are >> asking for a service from a company they are establishing a >> relationship >> with. I can't think of anything less privacy-aware and privacy- >> sensitive >> than that. > > so nxdomain-remapping policy-routing udp/53-thieving hotels could > not add > this new OPT blob and have it contain PII that authority servers > would see? Being a standard neither requires nor precludes them from doing whatever it is they do. Surely you've been on one of their networks before. They do all kinds of crazy things, standards or no standards. > > please point me to the specific design elements which would prevent > this? It doesn't exist, nor should it. They are not the audience for this document, though they are certainly welcome to follow it. If they do, users will probably have a better Internet experience. An aside -- all the comments from people who think this is some win for targeting advertising clearly do not work in that industry. Those people already buy and sell cookies across domains and tons of other far more useful things than seeing a client source IP in a DNS request would offer. But this is not relevent to those who feel client-ip is enabling potential privacy violations where one previously did not exist, I guess. -David Sent from my iPhone > From owner-namedroppers@ops.ietf.org Fri Apr 9 23:11:26 2010 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 CCA593A692E; Fri, 9 Apr 2010 23:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 OVC4HvvY69bR; Fri, 9 Apr 2010 23:11:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0FE453A6963; Fri, 9 Apr 2010 23:11:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0TpP-00017m-I9 for namedroppers-data0@psg.com; Sat, 10 Apr 2010 06:05:59 +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.71 (FreeBSD)) (envelope-from ) id 1O0TpM-00017I-Rc for namedroppers@ops.ietf.org; Sat, 10 Apr 2010 06:05:56 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 2DBCBA16B5 for ; Sat, 10 Apr 2010 06:05:55 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie to: IETF DNSEXT WG Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 In-Reply-To: Your message of "Sat, 10 Apr 2010 00:30:04 GMT." <33529.1270859404@nsa.vix.com> References: <4BB3E324.2050207@isc.org> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> <4BBF8E87.2030207@dougbarton.us> <33529.1270859404@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sat, 10 Apr 2010 06:05:55 +0000 Message-ID: <47828.1270879555@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: Paul Vixie > Date: Sat, 10 Apr 2010 00:30:04 +0000 hey, that's me! > > Date: Fri, 9 Apr 2010 14:19:19 -0700 > > From: David Ulevitch > > > > This proposal is deliberately designed for and written by DNS providers > > that users OPT-IN to using. By that very definition, these users are > > asking for a service from a company they are establishing a relationship > > with. I can't think of anything less privacy-aware and privacy-sensitive > > than that. > > so nxdomain-remapping policy-routing udp/53-thieving hotels could not add > this new OPT blob and have it contain PII that authority servers would see? > > please point me to the specific design elements which would prevent this? it's been asserted that my question is out of order, which if true means that the opt-in nature of the underlying proposal is nonfalsifiable. so as an answer to doug barton's objection (quoted below), david ulevitch's message (quoted above) is nonsequitur. therefore: rewind, restart from positions, which means right here: On Fri, Apr 9, 2010 at 1:31 PM, Doug Barton wrote: > I am actually sympathetic to the concept of "DNS tricks" for CDNs, but > this is going too far. i'm not sympathetic to "DNS tricks" for reasons i published elsewhere a few months ago (http://queue.acm.org/detail.cfm?id=1647302, "What DNS Is Not"), but i agree in spirit with doug that this proposal would make things worse. From dnsext-archive@ietf.org Sat Apr 10 01:01:22 2010 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 3AB913A69A8 for ; Sat, 10 Apr 2010 01:01:22 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char A9 hex): From: USA \251 Doctor Cesar <[...] X-Spam-Flag: NO X-Spam-Score: -26.804 X-Spam-Level: X-Spam-Status: No, score=-26.804 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 UCjwPOAdoSMc for ; Sat, 10 Apr 2010 01:01:21 -0700 (PDT) Received: from 81.202.118.129.dyn.user.ono.com (81.202.118.129.dyn.user.ono.com [81.202.118.129]) by core3.amsl.com (Postfix) with SMTP id C70D43A6951 for ; Sat, 10 Apr 2010 01:01:11 -0700 (PDT) From: USA Doctor Cesar To: dnsext-archive@ietf.org Subject: Dear dnsext-archive@ietf.org April 24% OFF. MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100410080111.C70D43A6951@core3.amsl.com> Date: Sat, 10 Apr 2010 01:01:11 -0700 (PDT)
Click here to view as a web page.

View image in browser now
From owner-namedroppers@ops.ietf.org Sat Apr 10 04:45:13 2010 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 8DDE43A69E6; Sat, 10 Apr 2010 04:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.793 X-Spam-Level: * X-Spam-Status: No, score=1.793 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=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 rqPzdie2DRP7; Sat, 10 Apr 2010 04:45:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8415D3A698C; Sat, 10 Apr 2010 04:45:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Yzg-000Cht-8Y for namedroppers-data0@psg.com; Sat, 10 Apr 2010 11:36:56 +0000 Received: from [65.99.1.130] (helo=abenaki.wabanaki.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0Yzc-000ChP-DN for namedroppers@ops.ietf.org; Sat, 10 Apr 2010 11:36:52 +0000 Received: from limpet.local (cpe-67-244-32-202.twcny.res.rr.com [67.244.32.202]) by abenaki.wabanaki.net (8.14.4/8.14.3) with ESMTP id o3ABWltU064211; Sat, 10 Apr 2010 07:32:48 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4BC062CA.8030203@abenaki.wabanaki.net> Date: Sat, 10 Apr 2010 07:36:42 -0400 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Brian Dickson CC: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.org> <20100409180535.GQ3595@shinkuro.com> <20100409190101.GY3595@shinkuro.com> In-Reply-To: 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: On 4/9/10 10:36 PM, Brian Dickson wrote: > ... > ICANN are concerned with the root and TLDs, but there ends their mandate. Please see rfc1591. In particular Section 3, parts 2 and 3. > ... > The TLDs need to provision and serve whatever is mandated by ICANN. ICANN is a California domiciled 501(c)(3) corporation which enters into contracts with what it calls "registry operators" (aka "contracted parties"). Contracts do not contain "mandates", unlike regulations. ICANN is not a regulatory body, authorized by some specific enabling legislation. In broad terms, ICANN has contractual relationships with some (about 20) "registry operators" (far fewer actually independent "registry backend service providers", seven I think, pre-coffee), and memorada with some other "registry operators". > ... > And the registrants, particularly in the IDN space, need something of > real value, > especially beyond just the TLDs, to make it worth doing IDNs in the first place. The overwhelming bulk of that particular work has already been done, first in the IDNA WG, completed seven years ago, and more recently in the IDNAbis WG, recently completed. The problem statement here is either an administrative convenience statement for arbitrary similarity, or the edge cases arising from a very limited number of equivalent (in some sense) code points in the third-party repertoire, or the specific case of intelligibility and therefore equivalence (in some sense) of arbitrary substitution of code points in two sub-repertoires, commonly denoted "Simplified" and "Traditional" Chinese (aka "SC/TC equivalence"). The utility of non-LDH labels, even if bootstring encoded from an LDH alphabet, and available only through presentation, does not depend on any work this group can conceivably take. Eric From nodjpw@mobil-content.ru Sat Apr 10 05:45:04 2010 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 636393A67E3; Sat, 10 Apr 2010 05:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -74.312 X-Spam-Level: X-Spam-Status: No, score=-74.312 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, HOST_EQ_BR=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 JLKXpG99E+9U; Sat, 10 Apr 2010 05:45:03 -0700 (PDT) Received: from 189-55-58-85-nd.cpe.vivax.com.br (189-55-58-85-nd.cpe.vivax.com.br [189.55.58.85]) by core3.amsl.com (Postfix) with ESMTP id BBF123A6880; Sat, 10 Apr 2010 05:45:01 -0700 (PDT) Received: from 189.55.58.85 by mail.mobil-content.ru; Sat, 10 Apr 2010 09:44:55 -0300 Message-ID: <000d01cad8ab$9ee53870$6400a8c0@nodjpw> From: dnsext-archive@ietf.org To: Subject: 9 ladies are online now (Russia, dating) Date: Sat, 10 Apr 2010 09:44:55 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 I'll like you? Remember that night in the hotel? http://moyer812.spaces.live.com From dnsop-bounces@ietf.org Sat Apr 10 05:45:05 2010 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F283A68B9 for ; Sat, 10 Apr 2010 05:45:05 -0700 (PDT) Subject: The results of your email commands From: dnsop-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1074245869==" Message-ID: Date: Sat, 10 Apr 2010 05:45:05 -0700 Precedence: bulk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF DNSOP WG mailing list X-List-Administrivia: yes Sender: dnsop-bounces@ietf.org Errors-To: dnsop-bounces@ietf.org --===============1074245869== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://moyer812.spaces.live.com - Done. --===============1074245869== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: dnsop-request@core3.amsl.com Delivered-To: dnsop-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636393A67E3; Sat, 10 Apr 2010 05:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -74.312 X-Spam-Level: X-Spam-Status: No, score=-74.312 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, HOST_EQ_BR=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 JLKXpG99E+9U; Sat, 10 Apr 2010 05:45:03 -0700 (PDT) Received: from 189-55-58-85-nd.cpe.vivax.com.br (189-55-58-85-nd.cpe.vivax.com.br [189.55.58.85]) by core3.amsl.com (Postfix) with ESMTP id BBF123A6880; Sat, 10 Apr 2010 05:45:01 -0700 (PDT) Received: from 189.55.58.85 by mail.mobil-content.ru; Sat, 10 Apr 2010 09:44:55 -0300 Message-ID: <000d01cad8ab$9ee53870$6400a8c0@nodjpw> From: dnsext-archive@ietf.org To: Subject: 9 ladies are online now (Russia, dating) Date: Sat, 10 Apr 2010 09:44:55 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 I'll like you? Remember that night in the hotel? http://moyer812.spaces.live.com --===============1074245869==-- From extremistsop45@smz.opolie.ru Sat Apr 10 05:45:16 2010 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 9A9F33A68C4 for ; Sat, 10 Apr 2010 05:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -70.142 X-Spam-Level: X-Spam-Status: No, score=-70.142 tagged_above=-999 required=5 tests=[BAYES_99=3.5, CHARSET_FARAWAY_HEADER=3.2, 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, HOST_EQ_BR=1.295, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SUB_ENC_KOI8R=0.67, 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 9lomoq3+yYS0 for ; Sat, 10 Apr 2010 05:45:15 -0700 (PDT) Received: from 189-55-58-85-nd.cpe.vivax.com.br (189-55-58-85-nd.cpe.vivax.com.br [189.55.58.85]) by core3.amsl.com (Postfix) with ESMTP id E69F63A6880 for ; Sat, 10 Apr 2010 05:45:13 -0700 (PDT) Received: from 189.55.58.85 by mail.opolie.ru; Sat, 10 Apr 2010 09:45:07 -0300 Date: Sat, 10 Apr 2010 09:45:07 -0300 From: dnsext-archive@lists.ietf.org Subject: =?koi8-r?B?Tm8gd29tYW4gY2FuIG1ha2UgYSBiZXR0ZXIgd2lmZSB0aGFuIGEgUnVz?= =?koi8-r?B?c2lhbiBsYWR5IJYgcGljayBvbmUgaGVyZS4g?= To: Message-ID: <000d01cad8ab$a6268530$6400a8c0@extremistsop45> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal I'll see you I really liked - let's get acquainted! I am from Russia! http://moyer812.spaces.live.com From dnsext-archive@lists.ietf.org Sat Apr 10 07:38:01 2010 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 3B6C33A67F9 for ; Sat, 10 Apr 2010 07:38:01 -0700 (PDT) X-Quarantine-ID: <1aSVoMfeRJYb> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char A9 hex): From: \251 VIAGRA \256 Offic[...] X-Spam-Flag: NO X-Spam-Score: -79.166 X-Spam-Level: X-Spam-Status: No, score=-79.166 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, HOST_EQ_BROADBND=1.118, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, 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 1aSVoMfeRJYb for ; Sat, 10 Apr 2010 07:37:59 -0700 (PDT) Received: from host86-175-86-19.wlms-broadband.com (host86-175-86-19.wlms-broadband.com [86.175.86.19]) by core3.amsl.com (Postfix) with SMTP id 76DEB3A677C for ; Sat, 10 Apr 2010 07:37:59 -0700 (PDT) From: VIAGRA Official Site To: dnsext-archive@lists.ietf.org Subject: Dear dnsext-archive@lists.ietf.org April 34% OFF. MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100410143759.76DEB3A677C@core3.amsl.com> Date: Sat, 10 Apr 2010 07:37:59 -0700 (PDT)
Click here to view as a web page.

View image in browser now
From dnsext-archive@ietf.org Sat Apr 10 07:38:01 2010 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 5AA133A677C for ; Sat, 10 Apr 2010 07:38:01 -0700 (PDT) X-Quarantine-ID: <861yxb0nVOHh> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char A9 hex): From: \251 VIAGRA \256 Offic[...] X-Spam-Flag: NO X-Spam-Score: -79.166 X-Spam-Level: X-Spam-Status: No, score=-79.166 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, HOST_EQ_BROADBND=1.118, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, 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 861yxb0nVOHh for ; Sat, 10 Apr 2010 07:38:01 -0700 (PDT) Received: from host86-175-86-19.wlms-broadband.com (host86-175-86-19.wlms-broadband.com [86.175.86.19]) by core3.amsl.com (Postfix) with SMTP id 787623A67A6 for ; Sat, 10 Apr 2010 07:37:59 -0700 (PDT) From: VIAGRA Official Site To: dnsext-archive@ietf.org Subject: Dear dnsext-archive@ietf.org April 34% OFF. MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100410143759.787623A67A6@core3.amsl.com> Date: Sat, 10 Apr 2010 07:37:59 -0700 (PDT)
Click here to view as a web page.

View image in browser now
From owner-namedroppers@ops.ietf.org Sat Apr 10 09:12:21 2010 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 D50233A6923; Sat, 10 Apr 2010 09:12:21 -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=-1.207, 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 a5gr7TKE+ONw; Sat, 10 Apr 2010 09:12:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 044173A67DA; Sat, 10 Apr 2010 09:12:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0dAI-000Lmi-7A for namedroppers-data0@psg.com; Sat, 10 Apr 2010 16:04:10 +0000 Received: from [74.125.83.52] (helo=mail-gw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0dAA-000Lix-2h for namedroppers@ops.ietf.org; Sat, 10 Apr 2010 16:04:02 +0000 Received: by gwj23 with SMTP id 23so2049170gwj.11 for ; Sat, 10 Apr 2010 09:04:01 -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:received:message-id:subject:from:to:cc:content-type; bh=eJG5pJ8EskqJGkhLABRP6wy6z+ByatKcOgPdEcYC0F0=; b=cnO5kTRp4AdFJag2Q8Gt9bN/ZOMwt2cDYPqoBya/cRY0CrRZg4g71nlCzwQ6wsGyjg AJtiEbp0Ez43Wp9E/JZJLAL0fgE02jSLA/rhUBIwSX1dCF9vJvoQi4XvHLkyBlF4OUbu dxk1fWKbvc+8uqJ8tvrmQNl2DHqbRa0o1naX4= 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 :cc:content-type; b=fCRGztxHWnfx7uM4IZaAro2v/BO3wuunpD43Uu4Gu1cVgZa8juShTCq4LeayRch0Cp Pkb/Xke2orRw7s70JOZF9wkoiQCAXWfe9asm75ljbfVZOoJcf4IywCPKkVQaCVWU8auy 1Y2X/zgc5f+RKtQk1YmYVsHX+uSBf5qXz1aaM= MIME-Version: 1.0 Received: by 10.100.91.5 with HTTP; Sat, 10 Apr 2010 09:04:00 -0700 (PDT) In-Reply-To: <4BC062CA.8030203@abenaki.wabanaki.net> References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.org> <20100409180535.GQ3595@shinkuro.com> <20100409190101.GY3595@shinkuro.com> <4BC062CA.8030203@abenaki.wabanaki.net> Date: Sat, 10 Apr 2010 13:04:00 -0300 Received: by 10.101.29.22 with SMTP id g22mr2555417anj.56.1270915440819; Sat, 10 Apr 2010 09:04:00 -0700 (PDT) Message-ID: Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work From: Brian Dickson To: Eric Brunner-Williams Cc: Andrew Sullivan , 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 think we are (all) in agreement, to some degree. Here's what I'm trying to say, obviously not clearly enough to date: There are currently mechanisms with limited ability to "deliver" multiple names for the same data: CNAME and DNAME. Those are limited mechanisms, which do not handle all cases. And also, quite importantly, they do not in and of themselves support DNSSEC validation without additional work by the Signer. There are also brute-force means by which multiple names can be enumerated, which does not use any DNS protocol elements. Brute force, however, puts the burden on maintaining parallel zones on the registrant. The problem is scaling. What we don't yet have, in terms of problem statement, is an answer to what the scaling requirements are. If the answer is "two", then likely no protocol work is needed. Two scales nicely. I do not believe "two" is the answer, however. If, on the other hand, the answer is P (as in P vs NP), polynomial scaling, then I think we need to contemplate providing solutions in the WG. An example of polynomial is the expansion of regular expressions of the form: {$A|$B|$C|...} where $A == $x.{$a|$b|$c}.{$d|$e} $B == {$f|$g}.{$h|$i}.{$j|$k} $C == $y.{$l|$m}.$z and so on. We haven't *yet* been given that as a requirement, at least from ICANN or other groups. However, if the real world users, i.e. registrants and end-users, expect to be able to refer to things by such multitudes of names, and get "the same" answers, then scalability issues suggest having the technological means of keeping the zones completely identical is a firm requirement. And I believe that means DNS protocol work, either directly to do this, or indirectly to support non-DNS implementations, e.g. literally by means of indirection. I also believe that *use* of DNS protocol technology envisioned needs to be optional, and that the brute force and existing CNAME/DNAME solutions all need to be allowed and supported. One size does not fit all. And the sizes currently available do not include XXL, which is the real problem. Brian On Sat, Apr 10, 2010 at 8:36 AM, Eric Brunner-Williams wrote: > On 4/9/10 10:36 PM, Brian Dickson wrote: >> ... >> ICANN are concerned with the root and TLDs, but there ends their mandate. > > Please see rfc1591. In particular Section 3, parts 2 and 3. > >> ... >> The TLDs need to provision and serve whatever is mandated by ICANN. > > ICANN is a California domiciled 501(c)(3) corporation which enters > into contracts with what it calls "registry operators" (aka > "contracted parties"). Contracts do not contain "mandates", unlike > regulations. ICANN is not a regulatory body, authorized by some > specific enabling legislation. > > In broad terms, ICANN has contractual relationships with some (about > 20) "registry operators" (far fewer actually independent "registry > backend service providers", seven I think, pre-coffee), and memorada > with some other "registry operators". > >> ... >> And the registrants, particularly in the IDN space, need something of >> real value, >> especially beyond just the TLDs, to make it worth doing IDNs in the first place. > > The overwhelming bulk of that particular work has already been done, > first in the IDNA WG, completed seven years ago, and more recently in > the IDNAbis WG, recently completed. > > The problem statement here is either an administrative convenience > statement for arbitrary similarity, or the edge cases arising from a > very limited number of equivalent (in some sense) code points in the > third-party repertoire, or the specific case of intelligibility and > therefore equivalence (in some sense) of arbitrary substitution of > code points in two sub-repertoires, commonly denoted "Simplified" and > "Traditional" Chinese (aka "SC/TC equivalence"). > > The utility of non-LDH labels, even if bootstring encoded from an LDH > alphabet, and available only through presentation, does not depend on > any work this group can conceivably take. > > Eric > From owner-namedroppers@ops.ietf.org Sat Apr 10 09:49:10 2010 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 D22EF3A67F4; Sat, 10 Apr 2010 09:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.978 X-Spam-Level: * X-Spam-Status: No, score=1.978 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=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 JlyAwfNxfaiu; Sat, 10 Apr 2010 09:49:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF18C3A67CC; Sat, 10 Apr 2010 09:49:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0dny-0001wU-JM for namedroppers-data0@psg.com; Sat, 10 Apr 2010 16:45:10 +0000 Received: from [65.99.1.130] (helo=abenaki.wabanaki.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0dnw-0001wA-4i for namedroppers@ops.ietf.org; Sat, 10 Apr 2010 16:45:08 +0000 Received: from limpet.local (cpe-67-244-32-202.twcny.res.rr.com [67.244.32.202]) by abenaki.wabanaki.net (8.14.4/8.14.3) with ESMTP id o3AGf07O066425; Sat, 10 Apr 2010 12:41:01 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4BC0AB0B.3080808@abenaki.wabanaki.net> Date: Sat, 10 Apr 2010 12:44:59 -0400 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Brian Dickson CC: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.org> <20100409180535.GQ3595@shinkuro.com> <20100409190101.GY3595@shinkuro.com> <4BC062CA.8030203@abenaki.wabanaki.net> In-Reply-To: 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: On 4/10/10 12:04 PM, Brian Dickson wrote: > ... > If, on the other hand, the answer is P (as in P vs NP), polynomial > scaling, then I think we need to contemplate providing solutions in > the WG. It is traditional to speak of "binomial explosion" when discussing the issues involved in label formation using characters which are interchangeable in the SC and TC character repertoires (overlooking nuances). I'm not a native reader of Chinese, it is possible to find words (identifiers) with up to 8 characters, and, as in German, agglomerate madly to make longer words (identifiers) ... However, labels of length greater than some number less than 8, for which the registry (or registries, recalling the circa-2000 level of cooperation between the CDNC ccTLD registries) offer "similarity", ventures into self-inflicted injury territory. So, larger than 2, less than P. Eric From owner-namedroppers@ops.ietf.org Sat Apr 10 10:02:00 2010 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 1DAE53A684B; Sat, 10 Apr 2010 10:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, BODY_ENHANCEMENT2=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 kNFifQnDhCQu; Sat, 10 Apr 2010 10:01:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C5843A67CC; Sat, 10 Apr 2010 10:01:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0e0M-0003cP-LC for namedroppers-data0@psg.com; Sat, 10 Apr 2010 16:57:58 +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.71 (FreeBSD)) (envelope-from ) id 1O0e0J-0003bj-SL for namedroppers@ops.ietf.org; Sat, 10 Apr 2010 16:57:55 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 771F3A17C1 for ; Sat, 10 Apr 2010 16:57:53 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-Reply-To: Your message of "Sat, 10 Apr 2010 13:04:00 -0300." References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.org> <20100409180535.GQ3595@shinkuro.com> <20100409190101.GY3595@shinkuro.com> <4BC062CA.8030203@abenaki.wabanaki.net> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sat, 10 Apr 2010 16:57:53 +0000 Message-ID: <80514.1270918673@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: Sat, 10 Apr 2010 13:04:00 -0300 > From: Brian Dickson > ... > One size does not fit all. this is because our hands are tied by the installed base. if we were willing to upgrade all stub and recursive resolvers and all applications, the rest would be trivial :-). From owner-namedroppers@ops.ietf.org Sat Apr 10 10:32:51 2010 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 AEB1F3A692C; Sat, 10 Apr 2010 10:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.74 X-Spam-Level: X-Spam-Status: No, score=0.74 tagged_above=-999 required=5 tests=[AWL=1.176, BAYES_00=-2.599, BODY_ENHANCEMENT2=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=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 gUXRIwhIcAy9; Sat, 10 Apr 2010 10:32:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E57203A6916; Sat, 10 Apr 2010 10:32:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0eTK-0007MD-Q4 for namedroppers-data0@psg.com; Sat, 10 Apr 2010 17:27:54 +0000 Received: from [65.99.1.130] (helo=abenaki.wabanaki.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0eTI-0007Lr-0E for namedroppers@ops.ietf.org; Sat, 10 Apr 2010 17:27:52 +0000 Received: from limpet.local (cpe-67-244-32-202.twcny.res.rr.com [67.244.32.202]) by abenaki.wabanaki.net (8.14.4/8.14.3) with ESMTP id o3AHNVVi066648; Sat, 10 Apr 2010 13:23:32 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4BC0B502.6020302@abenaki.wabanaki.net> Date: Sat, 10 Apr 2010 13:27:30 -0400 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> <5B0CB63F-B238-44A8-89A6-09D508FE0FF9@icann.org> <20100409154138.GK3595@shinkuro.com> <1C64D935-BFA7-4C33-95AC-D7F514D093A0@icann.org> <20100409180535.GQ3595@shinkuro.com> <20100409190101.GY3595@shinkuro.com> <4BC062CA.8030203@abenaki.wabanaki.net> <80514.1270918673@nsa.vix.com> In-Reply-To: <80514.1270918673@nsa.vix.com> 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: On 4/10/10 12:57 PM, Paul Vixie wrote: >> Date: Sat, 10 Apr 2010 13:04:00 -0300 >> From: Brian Dickson >> ... >> One size does not fit all. > > this is because our hands are tied by the installed base. if we were willing > to upgrade all stub and recursive resolvers and all applications, the rest > would be trivial :-). I'll have a double shot of whatever he's having. From owner-namedroppers@ops.ietf.org Sat Apr 10 12:26:49 2010 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 8796E3A6862; Sat, 10 Apr 2010 12:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.716 X-Spam-Level: X-Spam-Status: No, score=0.716 tagged_above=-999 required=5 tests=[AWL=1.211, 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 34iuRCE0GmF2; Sat, 10 Apr 2010 12:26:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B76B23A6845; Sat, 10 Apr 2010 12:26:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0gDf-000KK4-1e for namedroppers-data0@psg.com; Sat, 10 Apr 2010 19:19:51 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0gDc-000KJn-Mf for namedroppers@ops.ietf.org; Sat, 10 Apr 2010 19:19:48 +0000 Received: (qmail 7381 invoked by uid 399); 10 Apr 2010 19:19:46 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 10 Apr 2010 19:19:46 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BC0CF4D.8000405@dougbarton.us> Date: Sat, 10 Apr 2010 12:19:41 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> In-Reply-To: <20100409145117.GH3595@shinkuro.com> X-Enigmail-Version: 1.0.1 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, What was the result of your request for comments on the ietf@ list on this topic? If the results have already been published and I missed them, apologies, a pointer will suffice. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Sat Apr 10 12:42:17 2010 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 7296E3A6862; Sat, 10 Apr 2010 12:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.158 X-Spam-Level: * X-Spam-Status: No, score=1.158 tagged_above=-999 required=5 tests=[AWL=0.164, 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 HLyRYtrpgBnB; Sat, 10 Apr 2010 12:42:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 286EB3A6823; Sat, 10 Apr 2010 12:42:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0gUp-000MMO-Q7 for namedroppers-data0@psg.com; Sat, 10 Apr 2010 19:37:35 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0gUn-000MM5-GR for namedroppers@ops.ietf.org; Sat, 10 Apr 2010 19:37:33 +0000 Received: (qmail 30644 invoked by uid 399); 10 Apr 2010 19:37:30 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 10 Apr 2010 19:37:30 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BC0D365.70008@dougbarton.us> Date: Sat, 10 Apr 2010 12:37:09 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: David Ulevitch CC: Paul Vixie , IETF DNSEXT WG Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 References: <4BB3E324.2050207@isc.org> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> <4BBF8E87.2030207@dougbarton.us> <33529.1270859404@nsa.vix.com> <91D0FB82-1319-4688-9E5E-97598EF0EB5A@ulevitch.com> In-Reply-To: <91D0FB82-1319-4688-9E5E-97598EF0EB5A@ulevitch.com> X-Enigmail-Version: 1.0.1 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: On 04/09/10 23:04, David Ulevitch wrote: > On Apr 9, 2010, at 5:30 PM, Paul Vixie wrote: > >> so nxdomain-remapping policy-routing udp/53-thieving hotels could not add >> this new OPT blob and have it contain PII that authority servers would >> see? > > Being a standard neither requires nor precludes them from doing whatever > it is they do. Giving the people who want to monetize DNS query information a standard way to do this will make this easier, and will contribute to more, not less of the same. > Surely you've been on one of their networks before. They > do all kinds of crazy things, standards or no standards. > >> >> please point me to the specific design elements which would prevent this? > > It doesn't exist, nor should it. They are not the audience for this > document, though they are certainly welcome to follow it. If they do, > users will probably have a better Internet experience. > > An aside -- all the comments from people who think this is some win for > targeting advertising clearly do not work in that industry. I was the DNS administrator for Yahoo! in the 2001-2003 time frame when we were (arguably) the largest Internet company in the world, and UNarguably an industry leader in targeted advertising. Before becoming the DNS administrator I worked as a developer, including web tools for our customers that required me to learn and develop against our cookie API. I could go on, but my point is yes, I know a little something about the business. > Those people > already buy and sell cookies across domains and tons of other far more > useful things than seeing a client source IP in a DNS request would > offer. All of which have mitigation strategies that I can easily use, along with the ability to decide that if a site wants more information than I am comfortable providing I can ultimately choose not to continue my experience with them. However, I can't even GET to the site to make that decision without DNS. And of course, as others have pointed out, the Internet contains more than just the WWW. > But this is not relevent to those who feel client-ip is enabling > potential privacy violations where one previously did not exist, I guess. Voila! :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Sat Apr 10 13:54:46 2010 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 BECA63A677D; Sat, 10 Apr 2010 13:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.427 X-Spam-Level: X-Spam-Status: No, score=0.427 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, 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 s3MzBu5quvle; Sat, 10 Apr 2010 13:54:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DAEBF3A67A3; Sat, 10 Apr 2010 13:54:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0har-0003lV-EO for namedroppers-data0@psg.com; Sat, 10 Apr 2010 20:47:53 +0000 Received: from [209.85.160.180] (helo=mail-gy0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0han-0003lH-W9 for namedroppers@ops.ietf.org; Sat, 10 Apr 2010 20:47:50 +0000 Received: by gyb13 with SMTP id 13so2121100gyb.11 for ; Sat, 10 Apr 2010 13:47:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.169.1 with HTTP; Sat, 10 Apr 2010 13:47:48 -0700 (PDT) In-Reply-To: <4BC0D365.70008@dougbarton.us> References: <4BB3E324.2050207@isc.org> <4BBF6E97.1070807@isc.org> <4BBF7BF2.8000502@isc.org> <4BBF8E87.2030207@dougbarton.us> <33529.1270859404@nsa.vix.com> <91D0FB82-1319-4688-9E5E-97598EF0EB5A@ulevitch.com> <4BC0D365.70008@dougbarton.us> Date: Sat, 10 Apr 2010 13:47:48 -0700 Received: by 10.151.128.7 with SMTP id f7mr1328755ybn.65.1270932468205; Sat, 10 Apr 2010 13:47:48 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Doug Barton , IETF DNSEXT WG 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 Sat, Apr 10, 2010 at 12:37 PM, Doug Barton wrote: > Giving the people who want to monetize DNS query information a standard > way to do this will make this easier, and will contribute to more, not > less of the same. By monetizing DNS query information, are we talking about; A) Encouraging more CDN-like DNS trickery or B) Making it easier for intermediaries to sell targeted advertising or maybe both. I'm losing track. We've discussed A a lot, I'm less clear about how B works, can someone provide a worked-out example? -- Colm From owner-namedroppers@ops.ietf.org Sat Apr 10 17:54:35 2010 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 B0F833A68D5; Sat, 10 Apr 2010 17:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=-1.981, 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 ot2nHG6mqZQM; Sat, 10 Apr 2010 17:54:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C47BC3A659A; Sat, 10 Apr 2010 17:54:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0lLJ-000PTk-51 for namedroppers-data0@psg.com; Sun, 11 Apr 2010 00:48:05 +0000 Received: from [74.125.82.180] (helo=mail-wy0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O0lLD-000PSQ-3x for namedroppers@ops.ietf.org; Sun, 11 Apr 2010 00:47:59 +0000 Received: by wyf22 with SMTP id 22so325791wyf.11 for ; Sat, 10 Apr 2010 17:47:57 -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:received:message-id:subject:from:to:content-type; bh=JE0d8G7zJWz45EHSXM7KDshXm1oeW29iQ1letE+Ydpc=; b=ugGXtQVSMKW9K+limROTJm6kc39/fu6Z5TmDSjQ0i2OQCCKpzxyX9JJjNcNJB2vMpz eG3OavacRu1J0pCjTbCuAv1nvJQW9GSZpW3T0Z62I156UzE1ZLYX71hWmRvKVwb2BWtg UMHhv6f8VIDqcpfETMoFknvzGf+e7ow530E1M= 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=WMNOlXsGqp1FAc3AWM2MfQ/Fp4mPMXKG4CQRu/IEsy2KmP8L0znSiXmVG0Tq1Y5jVC nemgbiZ7TiZDGcvvk7nzshY1a/CNaNTU2hhrVQ7Dr00VohZANfCA6NrY6U1zMrH3CO6L gxvDAzV/Mn/wT+Pg8y0ljDdczGpuuwg3A7IU8= MIME-Version: 1.0 Received: by 10.216.6.90 with HTTP; Sat, 10 Apr 2010 17:47:57 -0700 (PDT) In-Reply-To: References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> Date: Sat, 10 Apr 2010 20:47:57 -0400 Received: by 10.216.86.19 with SMTP id v19mr1133581wee.218.1270946877504; Sat, 10 Apr 2010 17:47:57 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 From: Donald Eastlake 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 believe that the vast majority of users would be delighted to trade a slightly fuzzed version of their IP address for better web performance. As I don't see that trade, in the context to today's Internet, as having some big hidden downside for them. The very small minority that would care about this are almost exactly the people who will understand what's going on and take appropriate measures to opt out. So I do not see a significant privacy problem with this proposal. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street +1-508-634-2066 (home) Milford, MA 01757 USA d3e3e3@gmail.com From entmib-archive@lists.ietf.org Sun Apr 11 07:51:01 2010 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 D1DA23A6899 for ; Sun, 11 Apr 2010 07:51:01 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sun, 11 Apr 2010 07:51:00 -0700 (PDT) Received: from acceptmyoffer.com (unknown [121.247.35.3]) by core3.amsl.com (Postfix) with SMTP id 7CB603A687B for ; Sun, 11 Apr 2010 07:50:55 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100411145059.7CB603A687B@core3.amsl.com> Date: Sun, 11 Apr 2010 07:50:55 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 14348 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Sun Apr 11 11:38:13 2010 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 28A203A67FA; Sun, 11 Apr 2010 11:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.742 X-Spam-Level: **** X-Spam-Status: No, score=4.742 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, MIME_BASE64_BLANKS=0.041, 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 TUqQpF99UlAU; Sun, 11 Apr 2010 11:38:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B08753A68E2; Sun, 11 Apr 2010 11:38:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O11v5-000Ldj-HR for namedroppers-data0@psg.com; Sun, 11 Apr 2010 18:30:07 +0000 Received: from [195.188.213.7] (helo=smtp-out4.blueyonder.co.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O11v2-000Ld3-89 for namedroppers@ops.ietf.org; Sun, 11 Apr 2010 18:30:04 +0000 Received: from [172.23.170.138] (helo=anti-virus01-09) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1O11v0-0007eZ-Ee; Sun, 11 Apr 2010 19:30:02 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1O11uz-0004ER-H4; Sun, 11 Apr 2010 19:30:01 +0100 Message-ID: From: "George Barwood" To: "Andrew Sullivan" , References: <20100409145117.GH3595@shinkuro.com> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Date: Sun, 11 Apr 2010 19:29:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFuZHJldyBTdWxsaXZhbiIg PGFqc0BzaGlua3Vyby5jb20+DQpUbzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50 OiBGcmlkYXksIEFwcmlsIDA5LCAyMDEwIDM6NTEgUE0NClN1YmplY3Q6IFtkbnNleHRdIElDQU5O J3MgInN5bmNocm9uaXplZCBkb21haW5zIiBhbmQgdGhlIEROU0VYVCBhbGlhcyBtYXliZS13b3Jr DQoNCg0KPiBEZWFyIGNvbGxlYWd1ZXMsDQo+IA0KPiBJJ20gc3BlYWtpbmcgb25seSBmb3IgbXlz ZWxmLCBoZXJlLCBpbiB0cnlpbmcgdG8gY29tZSB0byBzb21lDQo+IGNvbmNsdXNpb25zIGluIGxp Z2h0IG9mIHRoZSBkaXNjdXNzaW9uIHdlIGhhZCBpbiBBbmFoZWltIGFib3V0IEROUw0KPiAibmFt ZSBlcXVpdmFsZW5jZXMiIGFuZCBzbyBvbi4gIEltcG9ydGFudGx5LCBJIHdhbnQgdG8gY29udmV5 IHRoYXQgSQ0KPiBoYXZlbid0IGRpc2N1c3NlZCB0aGlzIHdpdGggT2xhZnVyIGFuZCB0aGF0IEkg aGF2ZSBub3QgcmVhY2hlZCBhbnkNCj4gY29uY2x1c2lvbi4NCj4gDQo+IFdlIGhhdmUgYmVlbiBp bnZlc3RpZ2F0aW5nIHR3byB0aGluZ3MgaW4gcGFyYWxsZWw6DQo+IA0KPiAgICAxLiAgV2hhdCB0 aGUgcmVxdWlyZW1lbnRzIHdvdWxkIGJlIGZvciBzb21lIGtpbmQgb2YgYWRkaXRpb25hbA0KPiAg ICBhbGlhc2luZyBtZWNoYW5pc20gZm9yIHRoZSBETlMuDQo+IA0KPiAgICAyLiAgV2hldGhlciB0 aGVyZSBpcyBhbnkgcHJvdG9jb2wgd29yayB0aGF0IEROU0VYVCBzaG91bGQgZG8gaW4NCj4gICAg c3VwcG9ydCBvZiAoMSkuDQo+IA0KPiBJQ0FOTiBoYXMgaXNzdWVkIHNvbWUgcXVlc3Rpb25zIGFu ZCBhbnN3ZXJzDQo+IChodHRwOi8vd3d3LmljYW5uLm9yZy9lbi90b3BpY3MvaWRuL2Zhc3QtdHJh Y2svc3luY2hyb25pemVkLWlkbi1jY3RsZHMtZmFxLWVuLmh0bSkNCj4gaW4gc3VwcG9ydCBvZiB0 aGVpciAiUHJvcG9zZWQgSW1wbGVtZW50YXRpb24gUGxhbiBmb3IgU3luY2hyb25pemVkIElETg0K PiBjY1RMRHMiDQo+IChodHRwOi8vd3d3LmljYW5uLm9yZy9lbi9hbm5vdW5jZW1lbnRzL2Fubm91 bmNlbWVudC0yMm1hcjEwLWVuLmh0bSkuDQo+IFRoZSBRJkEgbWFrZXMgcGVyZmVjdGx5IGNsZWFy IHRoYXQsIGF0IGxlYXN0IGFzIGZhciBhcyBJQ0FOTiBpcw0KPiBjb25jZXJuZWQsIHdoYXRldmVy IHN5bmNocm9uaXplZCBUTERzIGFyZSwgdGhleSBoYXZlIG5vdGhpbmcgdG8gZG8NCj4gd2l0aCB0 aGUgRE5TLiAgVG8gdGhlIGV4dGVudCB0aGF0IHR3byBzeW5jaHJvbml6ZWQgZG9tYWlucyBhcmUN Cj4gc3VwcG9zZWQgdG8gaGF2ZSBzaW1pbGFyIHpvbmUgZGF0YSwgdGhhdCBpcyBlbnRpcmVseSBh IG1hdHRlciBmb3INCj4gcHJvdmlzaW9uaW5nIHRvb2xzIGFuZCBjb250cmFjdHMuDQo+IA0KPiBJ Q0FOTidzIHBsYW4gbWlnaHQgYmUgdW5kZXJzdG9vZCB0byBzdWdnZXN0IHRoYXQsIGV2ZW4gaWYg dGhlcmUgaXMgYQ0KPiBwcm9ibGVtIGhlcmUgdG8gYmUgc29sdmVkIChhbmQgSSBndWVzcyB0aGVy ZSBpcywgb3IgSUNBTk4gd291bGRuJ3QgYmUNCj4gZG9pbmcgc29tZXRoaW5nIGFib3V0IGl0KSwg bm8gcHJvdG9jb2wgd29yayBpcyBuZWVkZWQgaW4gb3JkZXIgdGhhdCBpdA0KPiBjb3VsZCBiZSBh ZGRyZXNzZWQuICBBcmUgb3RoZXJzIGluIGFncmVlbWVudCB3aXRoIHRoYXQ/ICBJZiBzbywgdGhl bg0KPiBpdCB3b3VsZCBhcHBlYXIgdGhhdCB0aGUgV0cgZG9lcyBub3QgbmVlZCB0byBjb25zaWRl ciB0aGlzIHRvcGljIGFueQ0KPiBtb3JlIGFzIGEgcG9zc2libGUgd29yayBpdGVtLg0KPg0KPiBJ ZiB5b3UgZG8gbm90IGFncmVlIHdpdGggdGhhdCBjb25jbHVzaW9uLCBpdCB3b3VsZCBiZSBpbnRl cmVzdGluZyB0bw0KPiBtZSB0byBoZWFyIHdoeSBub3QsIGFuZCB3aGF0IHlvdSB0aGluayBuZWVk cyBzdXBwb3J0IGluIHRoZSBwcm90b2NvbA0KPiB0aGF0IGNhbm5vdCBiZSBhY2NvbW1vZGF0ZWQg aW4gSUNBTk4ncyBwbGFuLg0KDQpJIHNob3VsZCBzYXkgZmlyc3QgdGhhdCBJIGFtIG5vdCB2ZXJ5 IGNsZWFyIG9uIHRoZSBpc3N1ZS4NCg0KSSBkb24ndCB0aGluayB3b3JrIGlzIHN0cmljdGx5IG5l Y2Vzc2FyeSwgYnV0IGl0IG1heSBzdGlsbCBiZSBkZXNpcmFibGUuDQoNCk15IHNpbXBsaXN0aWMg aW50dWl0aW9uIGlzIHRoYXQgaWYgLkNOIGFuZCAu5Lit5Zu9IGFuZCAu5Lit5ZyLIGFyZSANCmFs aWFzZXMsIGl0IG1heSBiZSB3b3J0aHdoaWxlIHRvIHJlcHJlc2VudCB0aGlzIGluZm9ybWF0aW9u IGluIHRoZSBETlMuDQoNClRoaXMgc2hvdWxkIGFsbG93IGNhY2hpbmcgcmVzb2x2ZXJzIHRvIG5l ZWQgdG8gc3RvcmUgb25seSBvbmUgY29weSBvZg0KdGhlIHN1Yi10cmVlLCBwcm92aWRlZCB0aGV5 IGhhdmUgc3VwcG9ydCBmb3Igd2hhdGV2ZXIgbWVjaGFuaXNtIGlzIGRlZmluZWQNCnRvIGNvbW11 bmljYXRlIHRoZSBhbGlhcyBpbmZvcm1hdGlvbi4NCg0KSXQgbWF5IGFsc28gaGF2ZSBvdGhlciBi ZW5lZml0cywgSSB0aGluayB0aGF0IGZpbmRpbmcgcmVzb2x2aW5nIGFsaWFzZXMgYXQgdGhlDQpl YXJsaWVzdCBwb3NzaWJsZSB0aW1lIG1ha2VzIGdvb2Qgc2Vuc2UuDQoNCkl0IHNlZW1zIHRoYXQg dGhlIGV4aXN0aW5nIGFsaWFzIG1lY2hhbmlzbXMgYXJlIG5vdCBzYXRpc2ZhY3RvcnksIHRoZXJl Zm9yZQ0KZGVmaW5pbmcgYSBuZXcgcmVzb3VyY2UgcmVjb3JkIHR5cGUgY2FwYWJsZSBvZiBleHBy ZXNzaW5nIHRoZSBhbGlhcw0KaW5mb3JtYXRpb24gd291bGQgYmUgc2Vuc2libGUuDQoNCkJlc3Qg cmVnYXJkcywNCkdlb3JnZSBCYXJ3b29kDQoNCiANCj4gQmVzdCByZWdhcmRzLA0KPiANCj4gQW5k cmV3DQo+IA0KPiAtLSANCj4gQW5kcmV3IFN1bGxpdmFuDQo+IGFqc0BzaGlua3Vyby5jb20NCj4g U2hpbmt1cm8sIEluYy4NCj4= From owner-namedroppers@ops.ietf.org Sun Apr 11 15:07:09 2010 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 9EF2B3A67A1; Sun, 11 Apr 2010 15:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 eMm11tX8JM81; Sun, 11 Apr 2010 15:07:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E6343A63EC; Sun, 11 Apr 2010 15:07:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O15Bg-000F9y-3n for namedroppers-data0@psg.com; Sun, 11 Apr 2010 21:59:28 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O15Bd-000F8e-Fc for namedroppers@ops.ietf.org; Sun, 11 Apr 2010 21:59:25 +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 <0L0Q00201FKS5L00@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Sun, 11 Apr 2010 22:59:22 +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 <0L0Q000E5FQX1000@cali.ucd.ie>; Sun, 11 Apr 2010 22:59:21 +0100 (IST) Date: Sun, 11 Apr 2010 22:59:21 +0100 From: Niall O'Reilly Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-reply-to: <20100409145117.GH3595@shinkuro.com> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org, Niall O'Reilly Message-id: <4BC24639.7000202@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <20100409145117.GH3595@shinkuro.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100317) 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 09/04/10 15:51, Andrew Sullivan wrote: > Dear colleagues, > > I'm speaking only for myself, here, in trying to come to some > conclusions in light of the discussion we had in Anaheim about DNS > "name equivalences" and so on. Importantly, I want to convey that I > haven't discussed this with Olafur and that I have not reached any > conclusion. > > We have been investigating two things in parallel: > > 1. What the requirements would be for some kind of additional > aliasing mechanism for the DNS. > > 2. Whether there is any protocol work that DNSEXT should do in > support of (1). [...] > ICANN's plan might be understood to suggest that, even if there is a > problem here to be solved (and I guess there is, or ICANN wouldn't be > doing something about it), no protocol work is needed in order that it > could be addressed. Are others in agreement with that? Yes, but a subsequent message from Kim Davies clarifies this as intended to be an interim position. > If so, then > it would appear that the WG does not need to consider this topic any > more as a possible work item. This doesn't follow, because it's a general conclusion drawn from a particular case. ICANN is just one of the players on the DNS stage. > If you do not agree with that conclusion, it would be interesting to > me to hear why not, and what you think needs support in the protocol > that cannot be accommodated in ICANN's plan. I believe that ICANN's plan is only of marginal relevance to the questions mentioned at (1) and (2) above. At most, ICANN's plan may give rise to an additional opportunity to avail of any solution which may emerge for question (1). On the other hand, the question arises already in existing ccTLD operations, prior to, and independently of, the implementation of ICANN's plan. Possible use cases which would be served "by some kind of additional aliasing mechanism for the DNS" seem to me to be well covered in Paul Vixie's slide-set for the interim audio meeting held on 16 Feb 2010, and (very usefully) include an example which is not related to variant IDNA strings. Drafts (BNAME and SHADOW) are already available addressing these suggested use cases. It seems to me that it would be useful for a number of those with a material interest in the outcome to make clear statements on this list (as some have already done privately) in respect of the following questions: What their interest is; In what way existing aliasing (replication or indirection) mechanisms are (or appear to be) inadequate for them; What size of "equivalence cluster" they anticipate needing respectively for a single label and for an FQDN; Whether (with reasons) SHADOW appears a useful solution; Whether (with reasons) BNAME appears a useful solution. This should give a clear impression of what benefit, if any, might flow from any further work on this topic. So far, the discussion on this list of this topic seems to have been dominated by people either whose native language is English, or for whom the Latin alphabet is a close enough approximation to meeting their needs. Without meaning either to impugn anyone's acquired expertise or to play down the value of proxy advocacy, I suggest that two observations are pertinent: first, that such a group is likely not best qualified by experience to articulate the problem; secondly, that dominance by such a group may tend to marginalize those who are so qualified. If no-one speaks up, I'm inclined to agree with Andrew that "it would appear that the WG does not need to consider this topic any more as a possible work item", but not because of anything to do with ICANN's plan. I hope this helps. Niall O'Reilly From dmanet@ietf.org Sun Apr 11 15:48:24 2010 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 9EDB03A67A1 for ; Sun, 11 Apr 2010 15:48:24 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sun, 11 Apr 2010 15:48:23 -0700 (PDT) Received: from 231-102.125-70.bham.res.rr.com (231-102.125-70.bham.res.rr.com [70.125.102.231]) by core3.amsl.com (Postfix) with SMTP id 078983A63EC for ; Sun, 11 Apr 2010 15:48:20 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100411224822.078983A63EC@core3.amsl.com> Date: Sun, 11 Apr 2010 15:48:20 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 80875 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Sun Apr 11 16:28:48 2010 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 DC2B13A6946; Sun, 11 Apr 2010 16:28:48 -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 vRbM0wAIRE28; Sun, 11 Apr 2010 16:28:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 962883A6839; Sun, 11 Apr 2010 16:28:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O16Tc-000LhC-8l for namedroppers-data0@psg.com; Sun, 11 Apr 2010 23:22:04 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O16TZ-000Lh1-Ng for namedroppers@ops.ietf.org; Sun, 11 Apr 2010 23:22:01 +0000 Received: by farside.isc.org (Postfix, from userid 10265) id E40BEE7E83; Sun, 11 Apr 2010 23:21:59 +0000 (UTC) Date: Sun, 11 Apr 2010 23:21:59 +0000 From: Suzanne Woolf To: Niall O'Reilly Cc: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Message-ID: <20100411232159.GB30382@farside.isc.org> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BC24639.7000202@ucd.ie> User-Agent: Mutt/1.4.2.3i 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, Apr 11, 2010 at 10:59:21PM +0100, Niall O'Reilly wrote: > >ICANN's plan might be understood to suggest that, even if there is a > >problem here to be solved (and I guess there is, or ICANN wouldn't be > >doing something about it), no protocol work is needed in order that it > >could be addressed. Are others in agreement with that? > > Yes, but a subsequent message from Kim Davies clarifies this as > intended to be an interim position. There's also now a blog post at blog.icann.org that reiterates (more or less) what Kim said here. > >If so, then > >it would appear that the WG does not need to consider this topic any > >more as a possible work item. > > This doesn't follow, because it's a general conclusion drawn > from a particular case. ICANN is just one of the players on > the DNS stage. All other issues raised by the specific ICANN consultation aside (and there are plenty) I think this is the key observation for purposes of this WG and its need to determine what work might lie before in defining and operationalizing what "the same" might mean in the DNS. ICANN, as the operator of the IANA, is responsible for a key registry, the root zone. However, it is not responsible for all registries, and even if a loose correspondence between separate delegations meets ICANN's need for "the same" in terms of behavior for some or all of its delegations, it's quite possible that other registries will need different behavior obtained by different means-- not inconsistent with ICANN's requirements, whatever they are, but still subject to additional constraints arising from additional requirements. (It's a common situation in registry policy and operations that the operator of a child domain will have constraints and needs to which the parent is not subject, and there's no reason to think it won't happen here.) > If no-one speaks up, I'm inclined to agree with Andrew that > "it would appear that the WG does not need to consider this > topic any more as a possible work item", but not because of > anything to do with ICANN's plan. I think the part of your message I elided recaps the discussions the WG has had, including the conclusions previously reached and the drafts already offered. I agree with you that ICANN's inferred position, even if actually held there, doesn't change where the WG stands. However, as above, ICANN is an important operator that appears to have an interest in the idea of expressing "aliasing" or "sameness" in the DNS. Accordingly, I look forward to contributions from ICANN staff to defining what can and can't be done with separate delegations in this area and how additional requirements may be clarified and met. Suzanne (speaking for myself) From owner-namedroppers@ops.ietf.org Sun Apr 11 17:00:11 2010 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 CA8963A6946; Sun, 11 Apr 2010 17:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.746 X-Spam-Level: * X-Spam-Status: No, score=1.746 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=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 PUbfAg6hw1wl; Sun, 11 Apr 2010 17:00:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E6BD3A63EC; Sun, 11 Apr 2010 17:00:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O170T-000O3E-FR for namedroppers-data0@psg.com; Sun, 11 Apr 2010 23:56:01 +0000 Received: from [65.99.1.130] (helo=abenaki.wabanaki.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O170Q-000O2o-LV for namedroppers@ops.ietf.org; Sun, 11 Apr 2010 23:55:58 +0000 Received: from limpet.local (cpe-67-244-32-202.twcny.res.rr.com [67.244.32.202]) by abenaki.wabanaki.net (8.14.4/8.14.3) with ESMTP id o3BNpVED076433; Sun, 11 Apr 2010 19:51:32 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4BC26186.70207@abenaki.wabanaki.net> Date: Sun, 11 Apr 2010 19:55:50 -0400 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Niall O'Reilly" CC: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> In-Reply-To: <4BC24639.7000202@ucd.ie> 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: On 4/11/10 5:59 PM, Niall O'Reilly wrote: > ... >> ICANN's plan might be understood to suggest that, even if there is a >> problem here to be solved (and I guess there is, or ICANN wouldn't be >> doing something about it), no protocol work is needed in order that it >> could be addressed. Are others in agreement with that? > > Yes, but a subsequent message from Kim Davies clarifies this as > intended to be an interim position. While I appreciate Kim's efforts to clarify, 1) the Board level process which created the unusual sequence of drafts we are offered is without precident [the key here if interested is absence of Board working group process, generating a text of record before its authors were formally constituted], and 2) Staff comments in a bottom-up, multi-stakeholder policy making organization are simply Staff comments, and 3) the issue nexii (note the plural) are with the Han, Cyrillic, and Arabic Scripts authorities, and not necessarily with the change control authorities for the IANA root. I agree with Kim that the best interpretation of a problematic document and process, and situation, attempting a problem statement, is that it is transitional. >> If so, then >> it would appear that the WG does not need to consider this topic any >> more as a possible work item. > > This doesn't follow, because it's a general conclusion drawn > from a particular case. ICANN is just one of the players on the > DNS stage. While true, that observation doesn't get to either the necessary agency, if it is not ICANN, nor to the problem statement, and therefore the mechanism(s) which might be adequate. >> If you do not agree with that conclusion, it would be interesting to >> me to hear why not, and what you think needs support in the protocol >> that cannot be accommodated in ICANN's plan. > > I believe that ICANN's plan is only of marginal relevance to the > questions mentioned at (1) and (2) above. ... Agree. ICANN's request is quite limited as to where similarity exists, and what similarity means. On the other hand, prior to the rather widespread belief among policy people at ICANN Seoul that DNAME was sufficient, the question really hadn't been put to this WG, unless I was asleep, which could be the case. That is to say, for what ever reason, it is unlikely that we would be here, now, absent the post-Seoul policy consultation(s), though we could be "here" at some later point, without external impulse. ... At most, ICANN's > plan may give rise to an additional opportunity to avail of any > solution which may emerge for question (1). On the other hand, > the question arises already in existing ccTLD operations, prior > to, and independently of, the implementation of ICANN's plan. While possible true, in the sense that the Greek tonos issue was known here, if you really want to put a flaming stake through the heart of the person ultimately responsible for there being an issue, I suggest the author of the "one script per" allocation model, from the Anglophone head of the ccNSO. This absurdity leads some to calling SC/TC a "variant" issue, to disguise two scripts, and utter indifference to the 12 scripts (and 22 languages) for India. It does however work for most of the Arabic Script issues. > Possible use cases which would be served "by some kind of > additional aliasing mechanism for the DNS" seem to me to be well > covered in Paul Vixie's slide-set for the interim audio meeting held > on 16 Feb 2010, and (very usefully) include an example which is not > related to variant IDNA strings. Paul's not the only one who's suggested that alias has rationals other than label inter-intelligibly out of a sequence of code points admitting one or more alternative code points in the constructed string. > > Drafts (BNAME and SHADOW) are already available addressing > these suggested use cases. It seems to me that it would be > useful for a number of those with a material interest in the > outcome to make clear statements on this list (as some have > already done privately) in respect of the following questions: BNAME has the unusual property that it precludes delegation. This has side effects. > What their interest is; > In what way existing aliasing (replication or indirection) > mechanisms are (or appear to be) inadequate for them; > What size of "equivalence cluster" they anticipate needing > respectively for a single label and for an FQDN; Please see my prior note. > Whether (with reasons) SHADOW appears a useful solution; > Whether (with reasons) BNAME appears a useful solution. > > This should give a clear impression of what benefit, if any, > might flow from any further work on this topic. > > So far, the discussion on this list of this topic seems to > have been dominated by people either whose native language > is English, or for whom the Latin alphabet is a close enough > approximation to meeting their needs.... This was present when the IDNA WG rejected the CNDC proposal for intermediate tables, to rectify errors made in Han Unification, by the authors of the repertoire, in 2003. ... Without meaning either to > impugn anyone's acquired expertise or to play down the > value of proxy advocacy, I suggest that two observations are > pertinent: first, that such a group is likely not best qualified > by experience to articulate the problem; secondly, that dominance > by such a group may tend to marginalize those who are so qualified. I will agree that error arising out of lack of subject matter expertise took place in 2003, and in 2009, and more importantly, prior to 2003, but in another organization. However, the locus of policy formation is, as you observe partially correctly, only partially defined, and therefore even if this working group were formed of "cloud ascended sages", it could not be completely correct, only partially so. Additionally, there are no restraints on CNNIC technical staff, and other CDNC and JET technical staff, from full participation, now that Anaheim and the visa limitation problem is finally behind us. > If no-one speaks up, I'm inclined to agree with Andrew that > "it would appear that the WG does not need to consider this > topic any more as a possible work item", but not because of > anything to do with ICANN's plan. > > I hope this helps. > > Niall O'Reilly We all have our views. I'm partial to graph theory as a motivation, and DNSSEC or proof properties generally as a pervasive recursive descent problem. Eric From zionismai86@ottercreekinn.net Mon Apr 12 00:43:24 2010 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 5DF193A693A; Mon, 12 Apr 2010 00:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.508 X-Spam-Level: X-Spam-Status: No, score=-76.508 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, FM_DDDD_TIMES_2=1.999, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, 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_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_STILLSINGLE=1.66, 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 ggRryMy-8fQc; Mon, 12 Apr 2010 00:43:22 -0700 (PDT) Received: from host-76-11-236-117.newwavecomm.net (host-76-11-236-117.newwavecomm.net [76.11.236.117]) by core3.amsl.com (Postfix) with ESMTP id 24F5A3A696E; Mon, 12 Apr 2010 00:43:13 -0700 (PDT) Received: from 76.11.236.117 by mail.ottercreekinn.com; Mon, 12 Apr 2010 03:43:08 -0500 Message-ID: <000d01cada13$cb491a80$6400a8c0@zionismai86> From: dnsext-archive@ietf.org To: Subject: Still single?look at my profile, Olga from Russia Date: Mon, 12 Apr 2010 03:43:08 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CADA13.CB491A80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2900.2869 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CADA13.CB491A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I can do for you is - what can not no girl! Please Visit ------=_NextPart_000_0007_01CADA13.CB491A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I can do for you is - what can not no girl! Please Visit
------=_NextPart_000_0007_01CADA13.CB491A80-- From owner-namedroppers@ops.ietf.org Mon Apr 12 01:56:05 2010 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 BF6BF28C0E5; Mon, 12 Apr 2010 01:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.67 X-Spam-Level: X-Spam-Status: No, score=0.67 tagged_above=-999 required=5 tests=[AWL=-0.624, BAYES_05=-1.11, 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 3KDQI8Cp9luc; Mon, 12 Apr 2010 01:56:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 556BF3A6A1B; Mon, 12 Apr 2010 01:56:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1FJo-00024G-QM for namedroppers-data0@psg.com; Mon, 12 Apr 2010 08:48:32 +0000 Received: from [144.254.224.141] (helo=ams-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1FJm-00023u-4E for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 08:48:30 +0000 Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwBANN7wkuQ/uCWe2dsb2JhbACbMhUBAQsLIgYcoSKYIoUMBINC X-IronPort-AV: E=Sophos;i="4.52,189,1270425600"; d="sig'?scan'208";a="5452880" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 12 Apr 2010 08:12:35 +0000 Received: from [192.165.72.14] (dhcp-10-55-82-227.cisco.com [10.55.82.227]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3C8mFSl015466; Mon, 12 Apr 2010 08:48:16 GMT Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-265-697119649" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100411232159.GB30382@farside.isc.org> Date: Mon, 12 Apr 2010 10:48:15 +0200 Cc: "Niall O'Reilly" , Andrew Sullivan , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <20100411232159.GB30382@farside.isc.org> To: Suzanne Woolf X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1078) 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 an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-265-697119649 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 12 apr 2010, at 01.21, Suzanne Woolf wrote: > It's a > common situation in registry policy and operations that the operator > of a child domain will have constraints and needs to which the parent > is not subject, and there's no reason to think it won't happen here. Correct, but, what troubles me is the following text in the plan for = implementation from ICANN. I.e. this is what ICANN requires from the = applicant (see = http://icann.org/en/topics/idn/fast-track/proposed-plan-synchronized-idn-c= ctlds-22mar10-en.pdf, page 4): > 2. Documentation of adequate and verifiable procedures that the = requester will use to enable convergence at every level of the IDN = ccTLD, including information about the steps the requester will take to = remove any divergence that might occur. Such documentation must include = descriptions of the registry=92s plans to: >=20 > 2.1. Enable through a technical mechanism that synchronized domains = resolve to the same address or value in each level of the DNS tree; >=20 > 2.2 Require in a registration policy that synchronized domains resolve = to the same address or value in each level of the DNS tree; >=20 > 2.3 Ensure compliance with the registration policy for synchronized = domains; >=20 > 2.4 Provide timely reports on synchronized IDN ccTLD experiences = following the delegation and implementation of the synchronized IDN = ccTLDs; >=20 > 2.5 Migrate in a safe, stable and timely manner to improved technical = standard for the delegation and management of synchronized IDN ccTLDs if = established, and applicable for such delegations. This text must be changed, at least from my point of view, for the text = in what Kim writes, and the Q&A, and the blog, to be able to be true. = The text implies to me that ICANN requires the applicant to not only = show that they will do policing, but also how they will do it, and that = it is doing it. And that it reports to ICANN about it. Now, this in turn = imply that ICANN will approve/disapprove what the applicant is = suggesting, and that ICANN might say something if the registry is not = doing "good enough job". My personal view is that *if* some registry want to play around with = policies, do bundling etc, let them do it. But do not think the parent = that approve the delegations can enforce something "in each level of the = DNS tree". That implies a responsibility (on ICANN ultimately) that = should not exist. Not even implicitly. Patrik --Apple-Mail-265-697119649 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFLwt5PvHlR2X0luNwRAlGSAJ9+CgMsrLB8Rdvoy6XDSCrsurRKKgCgzXWV JISj6Zt8H5TIYlCL8rvO4AE= =T0y8 -----END PGP SIGNATURE----- --Apple-Mail-265-697119649-- From owner-namedroppers@ops.ietf.org Mon Apr 12 04:10:34 2010 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 B39A83A6944; Mon, 12 Apr 2010 04:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 ej81V6gEQwTE; Mon, 12 Apr 2010 04:10:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6BC623A6951; Mon, 12 Apr 2010 04:10:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1HRe-000MyQ-8Z for namedroppers-data0@psg.com; Mon, 12 Apr 2010 11:04:46 +0000 Received: from [209.85.160.180] (helo=mail-gy0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1HRb-000Mxs-GF for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 11:04:43 +0000 Received: by gyb13 with SMTP id 13so2662658gyb.11 for ; Mon, 12 Apr 2010 04:04:42 -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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=W1CS5Mf8X2A8mw2ys7cKYT0sC6iDP4hQK279Ukt9keU=; b=Y/QRECvaw4uJUGmPLpeqPLJLbDI+wNqcpPMRL/6jNG0lykYFhfYt+X3qUEEVZhvt3w TjKTQhByRGH5v21R156/xfT9FC63A4NgpBoNmXzeSvge5yP+Gpc1sACEr/LVVEaEPnvd GLKNwIt8uSRWnXdR+7gwCVbbgie2XUrdo/3JA= 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 :cc:content-type:content-transfer-encoding; b=YHg9PYmpD2hu2nNIyvFV03xpnnXSnlocDq9GzVIMtAoaSqPJ+CHCR1Q6YKcHwoIEs4 bhWv9FZVlu0NmnXO708A8TzpdYh/hXaJ15J4NDeCQw6R1YaNXcdXqOCuVj/GPSNJFa7D LlQPvHLMAzUBW/BKMfCXfEelmsc0YVrFYU1bw= MIME-Version: 1.0 Received: by 10.100.91.5 with HTTP; Mon, 12 Apr 2010 04:04:42 -0700 (PDT) In-Reply-To: References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <20100411232159.GB30382@farside.isc.org> Date: Mon, 12 Apr 2010 08:04:42 -0300 Received: by 10.100.19.4 with SMTP id 4mr6554541ans.41.1271070282624; Mon, 12 Apr 2010 04:04:42 -0700 (PDT) Message-ID: Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work From: Brian Dickson To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Suzanne Woolf , "Niall O'Reilly" , Andrew Sullivan , namedroppers@ops.ietf.org Content-Type: text/plain; charset=windows-1252 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: Without going into the policy issue(s) (as they're not directly a WG issue, IMHO), I'd say the proposed plan does help inform the requirements for sameness. It seems to me, that the requirements (valid or not) heavily favor mechanisms that provide the semantic of "hard link" rather than mechanisms that do "parallel provisioning". I'd say this is especially so in the context of DNSSEC (signatures and/or validation). Brian 2010/4/12 Patrik F=E4ltstr=F6m : > > On 12 apr 2010, at 01.21, Suzanne Woolf wrote: > >> It's a >> common situation in registry policy and operations that the operator >> of a child domain will have constraints and needs to which the parent >> is not subject, and there's no reason to think it won't happen here. > > Correct, but, what troubles me is the following text in the plan for impl= ementation from ICANN. I.e. this is what ICANN requires from the applicant = (see http://icann.org/en/topics/idn/fast-track/proposed-plan-synchronized-i= dn-cctlds-22mar10-en.pdf, page 4): > >> 2. =A0 =A0Documentation of adequate and verifiable procedures that the r= equester will use to enable convergence at every level of the IDN ccTLD, in= cluding information about the steps the requester will take to remove any d= ivergence that might occur. Such documentation must include descriptions of= the registry=92s plans to: >> >> 2.1. Enable through a technical mechanism that synchronized domains reso= lve to the same address or value in each level of the DNS tree; >> >> 2.2 Require in a registration policy that synchronized domains resolve t= o the same address or value in each level of the DNS tree; > >> >> 2.3 Ensure compliance with the registration policy for synchronized doma= ins; >> >> 2.4 Provide timely reports on synchronized IDN ccTLD experiences followi= ng the delegation and implementation of the synchronized IDN ccTLDs; >> >> 2.5 Migrate in a safe, stable and timely manner to improved technical st= andard for the delegation and management of synchronized IDN ccTLDs if esta= blished, and applicable for such delegations. > > This text must be changed, at least from my point of view, for the text i= n what Kim writes, and the Q&A, and the blog, to be able to be true. The te= xt implies to me that ICANN requires the applicant to not only show that th= ey will do policing, but also how they will do it, and that it is doing it.= And that it reports to ICANN about it. Now, this in turn imply that ICANN = will approve/disapprove what the applicant is suggesting, and that ICANN mi= ght say something if the registry is not doing "good enough job". > > My personal view is that *if* some registry want to play around with poli= cies, do bundling etc, let them do it. But do not think the parent that app= rove the delegations can enforce something "in each level of the DNS tree".= That implies a responsibility (on ICANN ultimately) that should not exist.= Not even implicitly. > > =A0 Patrik > > From prophylacticzap@pmcmgmt.com Mon Apr 12 04:28:39 2010 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 B367B3A69AB for ; Mon, 12 Apr 2010 04:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -59.473 X-Spam-Level: X-Spam-Status: No, score=-59.473 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_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_MESSAGE=0.001, 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_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, 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 5Zj9Ti7TEhZA for ; Mon, 12 Apr 2010 04:28:37 -0700 (PDT) Received: from 200-171-127-151.dsl.telesp.net.br (200-171-127-151.dsl.telesp.net.br [200.171.127.151]) by core3.amsl.com (Postfix) with ESMTP id 59C5C3A69A9 for ; Mon, 12 Apr 2010 04:28:37 -0700 (PDT) Received: from 200.171.127.151 by mail.pmcmgmt.com; Mon, 12 Apr 2010 08:28:29 -0300 Message-ID: <000d01cada33$46a00580$6400a8c0@prophylacticzap> From: dnsext-archive@lists.ietf.org To: Subject: 7 new messages from ladies for you (dating) Date: Mon, 12 Apr 2010 08:28:29 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CADA33.46A00580" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2741.2600 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CADA33.46A00580 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You are my good, my handsome - write me, I'm waiting! Please Visit ------=_NextPart_000_0007_01CADA33.46A00580 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
You are my good, my handsome - write me, I'm wait= ing! Please Visit
------=_NextPart_000_0007_01CADA33.46A00580-- From owner-namedroppers@ops.ietf.org Mon Apr 12 05:42:24 2010 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 55A1E3A6A38; Mon, 12 Apr 2010 05:42:24 -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.447, BAYES_50=0.001, 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 G9YzVSs6YyBL; Mon, 12 Apr 2010 05:42:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 15F883A6A30; Mon, 12 Apr 2010 05:42:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Ipa-000ARz-CN for namedroppers-data0@psg.com; Mon, 12 Apr 2010 12:33:34 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1IpW-000ARL-1I for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 12:33:30 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3CCXSop034208 for ; Mon, 12 Apr 2010 08:33:28 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id o3CCXSIK034207 for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 08:33:28 -0400 (EDT) (envelope-from namedroppers) Received: from [209.85.212.52] (helo=mail-vw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Fjk-0005k9-Og for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 09:15:21 +0000 Received: by vws12 with SMTP id 12so335648vws.11 for ; Mon, 12 Apr 2010 02:15:19 -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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mXdmIWVyixgheJhL+lQsq5v4u8OWhr88dpkmSugpWCU=; b=v4/7Ya0El1IzwEJHzisAXyV7s3ZvzhTqO/e9BFBlzxd+7rM4jxvhTEZPY6tCxxEn1j HJnRl2KgxJQ35stPhHCIqQbt66/gSS39/l+e6m78aTitUesmyOVy0h8WT3aORrgB8zRN XBoAJ8/YFzPnrz9wSVjSVtYoapliJaI/bXXfM= 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 :cc:content-type:content-transfer-encoding; b=WRIvK2+P+9AHe7K2GTAQzwwZa1xwx14DB9sR3YcPRGfiQyFM2rTf/CZgpUvp33w2hL 5pw3lrpYOw5eaJ66t79CZT9UUL4SnKaPSSIqHfFB42+lK0dDhsT//Wm+55XcxS9Ks0Ys k/NDwDIp/IpRtBjcGqsugnWTYd4yLTDPtVVZI= MIME-Version: 1.0 Received: by 10.220.92.196 with HTTP; Mon, 12 Apr 2010 02:15:19 -0700 (PDT) In-Reply-To: References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> Date: Mon, 12 Apr 2010 18:15:19 +0900 Received: by 10.220.124.220 with SMTP id v28mr1754759vcr.219.1271063719647; Mon, 12 Apr 2010 02:15:19 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 From: Ted Hardie To: Donald Eastlake Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.67 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 Sun, Apr 11, 2010 at 9:47 AM, Donald Eastlake wrote: > I believe that the vast majority of users would be delighted to trade > a slightly fuzzed version of their IP address for better web > performance. And the DNS knows my query is for a web page how? What is the proposed client API to turn this on and off on a granular basis so that I can get that better performance for my web search but not reveal what hotel I'm in when doing the DNS queries that enable my VoIP calls? As I don't see that trade, in the context to today's > Internet, as having some big hidden downside for them. The very small > minority that would care about this are almost exactly the people who > will understand what's going on and take appropriate measures to opt > out. So I do not see a significant privacy problem with this proposal. > Presuming that the minority that want privacy will have tools to get it simply does not follow my understanding of the situation. It certainly runs counter the understanding that has dominated GEOPRIV's concerns about location privacy. While they may not come to our meetings, there are people who want privacy and do not know how to turn on and off specific EDNS options in their host stacks. I believe there has already been a pointer given to the situation in Australia when a group investigating suicide had to be given lessons to avoid the Australian censorship, but here's another in case my memory is faulty: http://www.smh.com.au/technology/technology-news/elderly-learn-to-beat-euth= anasia-blacklist-20100405-rn6i.html This is a bit different and , yeah, it might be possible to teach this once someone who cares gens up friendly tools for it, but let's not pretend that this work is either already done or that only tech-savvy folks have privacy concerns. The helpful hotel DNS that starts to do this to make google run faster for = its visitors will turn it on and leave it on for everyone. If it weren't a cor= king pain to configure this on a per-site basis, nobody would be asking for a standard here. That means every protocol, every destination. Your prediction may differ, but that's mine, and I don't like the results e= ither in impact to the infrastructure or in privacy. regards, Ted PS. I'm massively jet-lagged, and my coherence has no doubt suffered; my apologies if so. > Thanks, > Donald > =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 > =A0Donald E. Eastlake 3rd =A0 +1-508-333-2270 (cell) > =A0155 Beaver Street =A0 +1-508-634-2066 (home) > =A0Milford, MA 01757 USA > =A0d3e3e3@gmail.com > > From fratricides231@cultureshark.net Mon Apr 12 07:25:36 2010 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 27BCF3A699E; Mon, 12 Apr 2010 07:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.814 X-Spam-Level: X-Spam-Status: No, score=-81.814 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_DSN=1.495, FH_FAKE_RCVD_LINE_B=5.777, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_XBL=3.033, 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 V+IM5+CbAdBL; Mon, 12 Apr 2010 07:25:35 -0700 (PDT) Received: from host52-98-static.39-79-b.business.telecomitalia.it (host52-98-static.39-79-b.business.telecomitalia.it [79.39.98.52]) by core3.amsl.com (Postfix) with ESMTP id D6FB63A68C5; Mon, 12 Apr 2010 07:25:34 -0700 (PDT) Received: from 79.39.98.52 by mailhost.speedypuppy.net; Mon, 12 Apr 2010 16:25:27 +0100 Message-ID: <000d01cada4b$ff809660$6400a8c0@fratricides231> From: dnsext-archive@ietf.org To: Subject: I'll like you? Remember that night in the hotel? Date: Mon, 12 Apr 2010 16:25:27 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CADA4B.FF809660" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2900.2527 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CADA4B.FF809660 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Do you want me again? I love you madly I want! Please Visit ------=_NextPart_000_0007_01CADA4B.FF809660 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Do you want me again? I love you madly I want! Please Visit
------=_NextPart_000_0007_01CADA4B.FF809660-- From fratricides231@cultureshark.net Mon Apr 12 07:25:36 2010 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 27BCF3A699E; Mon, 12 Apr 2010 07:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.814 X-Spam-Level: X-Spam-Status: No, score=-81.814 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_DSN=1.495, FH_FAKE_RCVD_LINE_B=5.777, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_XBL=3.033, 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 V+IM5+CbAdBL; Mon, 12 Apr 2010 07:25:35 -0700 (PDT) Received: from host52-98-static.39-79-b.business.telecomitalia.it (host52-98-static.39-79-b.business.telecomitalia.it [79.39.98.52]) by core3.amsl.com (Postfix) with ESMTP id D6FB63A68C5; Mon, 12 Apr 2010 07:25:34 -0700 (PDT) Received: from 79.39.98.52 by mailhost.speedypuppy.net; Mon, 12 Apr 2010 16:25:27 +0100 Message-ID: <000d01cada4b$ff809660$6400a8c0@fratricides231> From: dnsext-archive@ietf.org To: Subject: I'll like you? Remember that night in the hotel? Date: Mon, 12 Apr 2010 16:25:27 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CADA4B.FF809660" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2900.2527 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CADA4B.FF809660 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Do you want me again? I love you madly I want! Please Visit ------=_NextPart_000_0007_01CADA4B.FF809660 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Do you want me again? I love you madly I want! Please Visit
------=_NextPart_000_0007_01CADA4B.FF809660-- From owner-namedroppers@ops.ietf.org Mon Apr 12 07:44:12 2010 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 BF04628C0E1; Mon, 12 Apr 2010 07:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.812 X-Spam-Level: * X-Spam-Status: No, score=1.812 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_50=0.001, 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 w4o53uvYoT+z; Mon, 12 Apr 2010 07:44:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CD8528C108; Mon, 12 Apr 2010 07:44:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Kkm-0002u3-2q for namedroppers-data0@psg.com; Mon, 12 Apr 2010 14:36:44 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Kkj-0002td-5Y for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 14:36:41 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3CEaUVt034926; Mon, 12 Apr 2010 10:36:31 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Mon, 12 Apr 2010 10:36:37 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 12 Apr 2010 10:36:37 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> Date: Mon, 12 Apr 2010 10:32:34 -0400 To: Ted Hardie From: Edward Lewis Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 Cc: Donald Eastlake , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 18:15 +0900 4/12/10, Ted Hardie wrote: >And the DNS knows my query is for a web page how? Because you DNS-queried for www.example.com and the host responding to the applicable IP addresses only has HTTP ports open there. THe use case here is a DNS server administration that has unified it's DNS and server set up for a particular purpose. >What is the proposed >client API to turn this on and off on a granular basis so that I can >get that better >performance for my web search but not reveal what hotel I'm in when doing >the DNS queries that enable my VoIP calls? Remember this is not general purpose DNS. If you are worried about someone discovering your hotel...there are probably other concerns (like the enemy planting a mole at the registration desk). Ok, that's a cheap shot at the problem case, but otherwise I can't really relate to the situation. >Presuming that the minority that want privacy will have tools to get it >Your prediction may differ, but that's mine, and I don't like the results >either in impact to the infrastructure or in privacy. I'm struggling with myself to keep the privacy discussion DNS and protocol focused. I can't really. I keep thinking to myself, the issue here is that the IP address information, even obfuscated, is being used to help properly address the following traffic. I would term this acceptable use. But that isn't a technical determination. IP addresses are sent through the routing system, across router hops. Anyone's specific address is revealed net-wide. This is the motivation for what I understand to be obfuscated or randomized IPv6 addressing. In the details of the edns-client-ip proposal, this activity is still possible. To me it seems that the objection in this thread is related to the fear that the transmitted information might be misused, that is, used for some purpose other than directing IP traffic. There was a time in my career that I replied, in a similar situation, "I'm not a priest, I cannot engineer according to fear." I'll use that again because I don't know what to say. It's hard to respond to nebulous criticisms. There's no denying that the address information is being passed beyond where it is now. The new dissemination is to enable optimizations at the server-end. Whether this is traffic localization, load shifting, or whatever else, it is still related to the movement of traffic. Can disseminated information be used for any purpose? Sure. Can we stop this? No, probably not. Can the objection be stated in a way that can be adequately addressed through a careful design? That's the ideal, but I still can't imagine the issue in purely technical terms. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From owner-namedroppers@ops.ietf.org Mon Apr 12 08:01:53 2010 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 9770328C0D8; Mon, 12 Apr 2010 08:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_50=0.001, 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 Okb4f4R+-fiw; Mon, 12 Apr 2010 08:01:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7CEA128C10C; Mon, 12 Apr 2010 08:01:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1L3U-0005ig-Eb for namedroppers-data0@psg.com; Mon, 12 Apr 2010 14:56:04 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1L3R-0005iP-TZ for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 14:56: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 o3CEu0XV022071; Mon, 12 Apr 2010 07:56:01 -0700 (PDT) References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver From: Nicholas Weaver Subject: [dnsext] edns-client-ip privacy rat-hole Date: Mon, 12 Apr 2010 07:56:00 -0700 To: namedroppers WG X-Mailer: Apple Mail (2.1078) 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: Overall, I'm really not getting this privacy rat-hole. =20 a) Information largely equivalent to this is already being exported = when first-party resolvers are used, after all, this is why stupid DNS = tricks work. [1] Especially items like the hotel examples: identifying the resolver may = often identify the actual hotel anyway! b) DNS is not the end protocol. Why do you use DNS? Because your = system wants to interact with another host. =20 DNS is about name->address mappings, and if you look up something in the = DNS, it is because you are either going to be contacting that host, or = have been contacted by that host (DNSRBLs). Just as DNSSEC is pointless for securing name->address mappings from any = adversary other than the recursive resolver itself, DNS privacy of your = subnet identity from the remote authority is almost completely pointless = if you are then going to contact the remote host! [2] c) client-ip doesn't provide a good monetary channel. =20 If you want to monetize your DNS stream as a resolver, don't leak a = little data to authorities, capture the entire resolver stream and = sell/use that. EG, after all, data mining the raw query stream to the = resolver is the only monetization source that Google Public DNS has. = And nothing in the DNS protocol prevents this, and client-ip doesn't = affect this in any way. d) This has no effect on censorship. If anything, by making = third-party resolvers MORE attractive to use, this prevents censorship = from being implemented in the resolver (by mandating to the ISP a list = of "naughty domains"), forcing it to be instead on the wire. e) Unless a privacy problem is within two orders of magnitude of what = Google Analytics does, its a non-issue. Really. Look in your cookie = store for __utma. Each one of those sites is a cookie where Google = tracks everything you do. In addition to everything on DoubleClick... =20= Even if mosquitos have malaria (they don't), its far less of a concern = than a severed femoral artery. The question is really simple, and why I care about this: Should third party resolution services be able to produce the same = quality of results that users get from using their ISP's recursive = resolver? [3] If yes, third party resolvers need to export an abstract of the client = IP. Period. =20 If no, say so: "I don't want third party resolvers to be as effective as = ISP provided resolvers". I wonder if a simple name change, and one which actually describes this = better, would be good. How about "edns-client-subnet" instead? [1] And these tricks are important: like em, or hate em: having the user = get to a server 50ms closer will save ~200ms+ on a page-load, as those = RTTs add up for handshakes etc. [2] The only exception is if those running the authority are not related = to those running the system itself. [3] I'm not actually a fan of such services based on the behavior of the = principle services (OpenDNS and its wildcarding and MITM games, Google = Public DNS for its privacy-compromising design), but that personal. I = still want competition in this space, to limit ISP-related DNS abuses. From dmin@ietf.org Mon Apr 12 08:05:16 2010 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 E86433A6781 for ; Mon, 12 Apr 2010 08:05:16 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 12 Apr 2010 08:05:15 -0700 (PDT) Received: from lan-84-240-32-143.vln.skynet.lt (lan-84-240-32-143.vln.skynet.lt [84.240.32.143]) by core3.amsl.com (Postfix) with SMTP id DAEBD3A67FC for ; Mon, 12 Apr 2010 08:05:13 -0700 (PDT) From: Approved VIAGRA® Store Subject: Special Code for 74% for dnsext-archive@ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100412150514.DAEBD3A67FC@core3.amsl.com> Date: Mon, 12 Apr 2010 08:05:13 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 88396 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Mon Apr 12 08:42:16 2010 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 906833A69C3; Mon, 12 Apr 2010 08:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.744 X-Spam-Level: X-Spam-Status: No, score=0.744 tagged_above=-999 required=5 tests=[AWL=-1.361, BAYES_50=0.001, 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 ziixyFburflG; Mon, 12 Apr 2010 08:42:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C3CC3A68F3; Mon, 12 Apr 2010 08:42:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1LgR-000C0l-KI for namedroppers-data0@psg.com; Mon, 12 Apr 2010 15:36:19 +0000 Received: from [74.125.82.52] (helo=mail-ww0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1LgM-000Bzv-Dy for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 15:36:14 +0000 Received: by wwd20 with SMTP id 20so2154110wwd.11 for ; Mon, 12 Apr 2010 08:36:13 -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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XJQ6Zml7kOjHIFyyk1Mhn7ml1FFy8H6d+YN6nlKeQd0=; b=mhQiVcS05tFPWfekNiqCvkhVIV1eFosuzTBacaV9ot/4yMfddivy541rsGynH6XU03 YGCHghqfCMUZMxf9mJOIdgC3XPevmqybg1LZO2CQK6sx8spcpTKLZv1NdI4mP3Sfay71 qC/T9nnduO58o+9hFBW0wUt6qfz9y2Q6/Bq6Q= 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 :cc:content-type:content-transfer-encoding; b=CqGdb4gW2KSC5pCX7iOBt//FjICq+0sbnJ7RvyuOA/ixY7ldt5zYjV3SqSepebVyLT x5zRLWFdWb0QcFaLcS2cfw+uZfrIUW6ixEu9hHlU9puvAUrN+kde8qpeNDI/Z7DHCKUW rn8z2QNPJ91xq8MaWX1UX48ztpaHGskt941rA= MIME-Version: 1.0 Received: by 10.216.6.90 with HTTP; Mon, 12 Apr 2010 08:36:12 -0700 (PDT) In-Reply-To: References: <4BB3E324.2050207@isc.org> Date: Mon, 12 Apr 2010 11:36:12 -0400 Received: by 10.216.176.212 with SMTP id b62mr2323139wem.179.1271086572994; Mon, 12 Apr 2010 08:36:12 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 From: Donald Eastlake To: Ted Hardie Cc: 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: Hi Ted, On Mon, Apr 12, 2010 at 5:15 AM, Ted Hardie wrote: > On Sun, Apr 11, 2010 at 9:47 AM, Donald Eastlake wrote= : >> I believe that the vast majority of users would be delighted to trade >> a slightly fuzzed version of their IP address for better web >> performance. > > And the DNS knows my query is for a web page how? =A0What is the proposed > client API to turn this on and off on a granular basis so that I can > get that better > performance for my web search but not reveal what hotel I'm in when doing > the DNS queries that enable my VoIP calls? I would say that the vast majority of users would be delighted to trade a slightly fuzzed version of their IP address on all DNS queries for an improvement in their average network service where that improvement would be most significant for web and/or higher bandwidth streaming media. > =A0As I don't see that trade, in the context to today's >> Internet, as having some big hidden downside for them. The very small >> minority that would care about this are almost exactly the people who >> will understand what's going on and take appropriate measures to opt >> out. So I do not see a significant privacy problem with this proposal. > > Presuming that the minority that want privacy will have tools to get it > simply does not follow my understanding of the situation. =A0It certainly > runs counter the understanding that has dominated GEOPRIV's concerns > about location privacy. The following comment of might be a bit tangental to your remark immediately above but isn't GEOPRIV about physical location and the draft we are discussing about network topology location? No analogy is perfect, but it feels to me more like the leakage of topological location through a routing protocol than it does to, say, leakage of physical location via cell phone triangulation/GPS... > While they may not come to our meetings, there are people who want > privacy and do not know how to turn on and off specific EDNS options > in their host stacks. =A0I believe there has already been a pointer given > to the situation in Australia when a group investigating suicide had to b= e > given lessons to avoid the Australian censorship, but here's another > in case my memory is faulty: > http://www.smh.com.au/technology/technology-news/elderly-learn-to-beat-eu= thanasia-blacklist-20100405-rn6i.html Seems like a great example of a case where those concerned and technically knowledgeable are providing techniques to those who are concerned but not as technically knowledgeable. That's what I would expect in the case of this proposed standard. Although as far as I know no one is proposing to make it illegal to by-pass the client IP reporting mechanism :-) > This is a bit different and , yeah, it might be possible to teach this > once someone > who cares gens up friendly tools for it, but let's not pretend that > this work is either > already done or that only tech-savvy folks have privacy concerns. I never claimed tools to opt-out of this as yet unadopted standard already exist. There will be a set of people particularly worried about privacy and a set of people with the technical capability of developing such tools. I believe there will be some positive correlation between these sets and may have exaggerated that correlation in my initial remarks but I didn't believe the sets are identical or that only tech-savvy folks have privacy concerns. > The helpful hotel DNS that starts to do this to make google run faster fo= r its > visitors will turn it on and leave it on for everyone. =A0If it weren't a= corking > pain to configure this on a per-site basis, nobody would be asking for > a standard > here. =A0That means every protocol, every destination. Most likely yes. > Your prediction may differ, but that's mine, and I don't like the results= either > in impact to the infrastructure or in privacy. >From the infrastructure point of view, this seems to trade a higher burden on DNS authoritative and caching servers for faster service to the user and less burden on the network pipes. Given the continuing fall in the cost of computation and memory, this seems like a reasonable trade-off from the infrastructure point of view. On privacy, I'm willing to accept that it has a small negative effect. But, given that there is currently no way to opt out of similar, if typically more localized, exploitation of query source information by DNS servers and that this would provide such an opt-out mechanism as well as real performance improvements for those who do not opt-out, I think it will provide an overall benefit. > regards, > > Ted > > PS. =A0I'm massively jet-lagged, and my coherence has no doubt suffered; > my apologies if so. Sorry about that. You seem pretty coherent to me. Thanks, Donald From owner-namedroppers@ops.ietf.org Mon Apr 12 09:33:46 2010 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 E4FD128B23E; Mon, 12 Apr 2010 09:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=-0.644, 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 PG6dRQ-hS-wB; Mon, 12 Apr 2010 09:33:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 37B2C28C151; Mon, 12 Apr 2010 09:31:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1MQ7-000Jh2-Da for namedroppers-data0@psg.com; Mon, 12 Apr 2010 16:23:31 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1MQ4-000Jgg-EB for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 16:23:28 +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 206E01ECB401 for ; Mon, 12 Apr 2010 16:23:25 +0000 (UTC) Date: Mon, 12 Apr 2010 12:23:23 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Message-ID: <20100412162323.GQ11706@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC0CF4D.8000405@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BC0CF4D.8000405@dougbarton.us> 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 Sat, Apr 10, 2010 at 12:19:41PM -0700, Doug Barton wrote: > What was the result of your request for comments on the ietf@ list on > this topic? If the results have already been published and I missed > them, apologies, a pointer will suffice. I did not receive any comments that were not either on that list or on namedroppers, save some comments by John Klensin, who told me that he would not, under any circumstances, re-join namedroppers. John's comments were substantially the same as those he made at the mic in the Anaheim meeting. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Apr 12 09:55:27 2010 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 7CF193A6A95; Mon, 12 Apr 2010 09:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.075 X-Spam-Level: * X-Spam-Status: No, score=1.075 tagged_above=-999 required=5 tests=[AWL=-1.925, BAYES_50=0.001, 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 zUftMEnonRG9; Mon, 12 Apr 2010 09:55:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6D9AE28C180; Mon, 12 Apr 2010 09:48:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Mk8-000MI7-0y for namedroppers-data0@psg.com; Mon, 12 Apr 2010 16:44:12 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Mk3-000MHf-R7 for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 16:44:08 +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 235781ECB401 for ; Mon, 12 Apr 2010 16:44:06 +0000 (UTC) Date: Mon, 12 Apr 2010 12:44:04 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Message-ID: <20100412164403.GR11706@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BC24639.7000202@ucd.ie> 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, Apr 11, 2010 at 10:59:21PM +0100, Niall O'Reilly wrote: > On 09/04/10 15:51, Andrew Sullivan wrote: >> If so, then >> it would appear that the WG does not need to consider this topic any >> more as a possible work item. > > This doesn't follow, because it's a general conclusion drawn > from a particular case. ICANN is just one of the players on the DNS > stage. That is true, but I think I owe the WG a clearer version of the argument against additional work. So here it is. The WG currently has no work item here. What we have been doing is investigating whether there is work that we might do to make whatever the problem is (and we don't know exactly what that is, but it has something to do with making names aliases for one another) less acute. As WG co-chair, one of my jobs is to determine whether in fact we have work to do here -- i.e. whether there is a new deliverable that shows up on our charter and results in protocol changes or clarifications. I emphasise again that I am still working through that. One way that I work through such things is to make the strongest arguments I can for a given case, and see whether there are persuasive counter-arguments. In this case, I am attempting to make the strongest argument I can that we have no work to do. Conclusion: The DNSEXT WG should not do any protocol work on the topic of aliases in the DNS. Premise 1: The WG should only make additions or changes to the DNS protocol when that is required. Premise 1.1: The DNS is an old and mature protocol with a large installed base. Premise 1.2: Old, mature protocols with large installed bases are expensive to change. Premise 1.3: Previous DNS extensions and additions have taken a long time to be deployed. Premise 1.4: Additional mechanisms in a protocol add complexity, which is to be avoided. Premise 2: Work on aliases in the DNS is not required. Premise 2.1: Any aliasing needed is possible to do using existing provisioning and contractual arrangements. Premise 2.1.1: ICANN is planning to do aliasing by provisioning and contractual relationships, and will require such mechanisms to work all the way down the tree. Premise 1.1 and 1.2 require conjunction, so if the two premises are not both true, then they do not provide good support for premise 1. Premise 1.3 supports premise 1 independently. Premise 1 has the form A only if B (changes only if required). Premise 2 denies the consequent of premise 1, and so the argument is formally valid: if A then B (== A only if B), not B, therefore not A. So far, the primary counter-arguments have come in three forms. One is that 2.1.1 is false because the ICANN plan is of limited scope. I don't know that I buy that limitation: there is no formal limitation of scope in the existing plan, so in fact there's nothing to prevent the current plans from resulting in many additional delegations. The only restriction is that users are supposed to be not surprised. Unless ICANN has developed a great deal of user interface expertise while I wasn't looking, I don't think it's really competent to evaluate that; so there's just no formal choke on what the plan needs to be able to cope with. (A variant of this objection is that the ICANN plan actually won't scale, no matter what ICANN is saying publicly.) The second is that 2.1 is false because there are cases not covered by the ICANN plan. I'm still waiting for details here. Because ICANN's plan is transitive all the way down the tree, this is at least doubtful. The third is really a denial of premise 1.4: that premise 1.4 is too broad, and that limited additions to the DNS do no harm. This is my reading of the discussion and arguments so far. If I've missed a point someone made, I apologise. (It would be good to hit me with a clue-stick.) > So far, the discussion on this list of this topic seems to > have been dominated by people either whose native language > is English, or for whom the Latin alphabet is a close enough > approximation to meeting their needs. Without meaning either to impugn > anyone's acquired expertise or to play down the > value of proxy advocacy, I suggest that two observations are > pertinent: first, that such a group is likely not best qualified by > experience to articulate the problem; secondly, that dominance by such > a group may tend to marginalize those who are so qualified. I think this is an excellent observation. If there are needs that are unrelated to language issues, this would also be a good time to bring them up. Best regards, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Apr 12 10:09:13 2010 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 6A0243A69BE; Mon, 12 Apr 2010 10:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 kNQ3baqAATqb; Mon, 12 Apr 2010 10:09:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8710428C146; Mon, 12 Apr 2010 10:06:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1N0o-000PXq-1l for namedroppers-data0@psg.com; Mon, 12 Apr 2010 17:01:26 +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.71 (FreeBSD)) (envelope-from ) id 1O1N0l-000PXN-La for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 17:01:23 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 1A982A1B92 for ; Mon, 12 Apr 2010 17:01:23 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 In-Reply-To: Your message of "Mon, 12 Apr 2010 11:36:12 -0400." References: <4BB3E324.2050207@isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 12 Apr 2010 17:01:23 +0000 Message-ID: <600.1271091683@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: Mon, 12 Apr 2010 11:36:12 -0400 > From: Donald Eastlake > > I would say that the vast majority of users would be delighted to trade a > slightly fuzzed version of their IP address on all DNS queries for an > improvement in their average network service where that improvement would > be most significant for web and/or higher bandwidth streaming media. i don't doubt this. and yet, this is a rather sweeping change to the internet's architecture, where is the IAB's position statement on it? and also yet, the average citizen trades privacy for convenience every day, but in other non-internet contexts there are regulators who can say "hold on a minute, that's very sexy but the implications are dire." shall we say that none of that thinking applies to the freewheeling internet, and let the buyers simply beware? From owner-namedroppers@ops.ietf.org Mon Apr 12 10:18:58 2010 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 676D63A6A81; Mon, 12 Apr 2010 10:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.804 X-Spam-Level: *** X-Spam-Status: No, score=3.804 tagged_above=-999 required=5 tests=[AWL=-1.777, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_IS_SMALL6=0.556, HELO_MISMATCH_RU=3.1, RCVD_IN_SORBS_WEB=0.619] 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 4lXtQbjzO+G1; Mon, 12 Apr 2010 10:18:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F41E53A6A99; Mon, 12 Apr 2010 10:17:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1NCx-0001cO-4t for namedroppers-data0@psg.com; Mon, 12 Apr 2010 17:13:59 +0000 Received: from [62.113.86.202] (helo=aha.ru) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1NCu-0001c5-NV for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 17:13:56 +0000 Received: from [92.36.25.100] (account dburk@burkov.aha.ru HELO [92.36.25.100]) by backend13.aha.ru (CommuniGate Pro SMTP 4.3.11) with ESMTPSA id 474972632; Mon, 12 Apr 2010 21:13:53 +0400 Message-ID: <4BC354CE.2070407@burkov.aha.ru> Date: Mon, 12 Apr 2010 21:13:50 +0400 From: Dmitry Burkov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> <4BC0CF4D.8000405@dougbarton.us> <20100412162323.GQ11706@shinkuro.com> In-Reply-To: <20100412162323.GQ11706@shinkuro.com> Content-Type: text/plain; charset=windows-1251; 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 4/12/2010 8:23 PM, Andrew Sullivan wrote: > On Sat, Apr 10, 2010 at 12:19:41PM -0700, Doug Barton wrote: > >> What was the result of your request for comments on the ietf@ list on >> this topic? If the results have already been published and I missed >> them, apologies, a pointer will suffice. >> > I did not receive any comments that were not either on that list or on > namedroppers, save some comments by John Klensin, who told me that he > would not, under any circumstances, re-join namedroppers. John's > comments were substantially the same as those he made at the mic in > the Anaheim meeting. > I missed this reference on the list. John clearly expressed his position http://forum.icann.org/lists/sync-idn-cctlds/msg00004.html Dima > Best, > > A > > From owner-namedroppers@ops.ietf.org Mon Apr 12 10:21:06 2010 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 DC66D3A6A74; Mon, 12 Apr 2010 10:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 W6q1BxZ4Q+hz; Mon, 12 Apr 2010 10:21:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 89EF83A68F3; Mon, 12 Apr 2010 10:19:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1NFO-0001un-Je for namedroppers-data0@psg.com; Mon, 12 Apr 2010 17:16: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.71 (FreeBSD)) (envelope-from ) id 1O1NFL-0001uF-Rq for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 17:16:27 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 93793A1B7F for ; Mon, 12 Apr 2010 17:16:27 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-Reply-To: Your message of "Mon, 12 Apr 2010 12:44:04 -0400." <20100412164403.GR11706@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <20100412164403.GR11706@shinkuro.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 12 Apr 2010 17:16:27 +0000 Message-ID: <1266.1271092587@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: Mon, 12 Apr 2010 12:44:04 -0400 > From: Andrew Sullivan > > That is true, but I think I owe the WG a clearer version of the > argument against additional work. So here it is. > > ... > > This is my reading of the discussion and arguments so far. If I've > missed a point someone made, I apologise. (It would be good to hit me > with a clue-stick.) i think i disagree with your conclusion on the following basi. basis 1. aliasing has potential customers other than icann. basis 2. icann has asked for some kind of standardized automation. basis 3. dname is crippled by not affecting its ownername. basis 4. cname is crippled by not affecting its children. basis 5. parallel delegations would benefit from standardized automation. on the basis of #3 and #4 above, i think that BNAME should be adopted. on the basis of #5 above, i think that SHADOW should be adopted. on the basis of #1 and #2 above, i don't think that icann's Q&A document takes any of this off the table. i am willing to do authorship and editorial work to support BNAME & SHADOW, assuming that others here are willing to review the drafts. if all that is in place, then we should proceed with drafting. From owner-namedroppers@ops.ietf.org Mon Apr 12 10:23:35 2010 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 EB41528C11B; Mon, 12 Apr 2010 10:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 oxzo32hBnNwk; Mon, 12 Apr 2010 10:23:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 08DDB3A6407; Mon, 12 Apr 2010 10:21:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1NHC-0002B0-7q for namedroppers-data0@psg.com; Mon, 12 Apr 2010 17:18:22 +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.71 (FreeBSD)) (envelope-from ) id 1O1NHA-0002Ad-4h for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 17:18:20 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id D52C0A1B9A for ; Mon, 12 Apr 2010 17:18:19 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers WG" Subject: Re: [dnsext] edns-client-ip privacy rat-hole In-Reply-To: Your message of "Mon, 12 Apr 2010 17:49:18 +0100." <6A27525DB402441D939E3A92E18388EE@localhost> References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> <6A27525DB402441D939E3A92E18388EE@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 12 Apr 2010 17:18:19 +0000 Message-ID: <1468.1271092699@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: Mon, 12 Apr 2010 17:49:18 +0100 > > Concealing the identity of clients is not a design goal of the current > DNS standard, nor should it be. it is however an emergent property of the current system, on which many users may be relying. this should not be changed without investigation. From owner-namedroppers@ops.ietf.org Mon Apr 12 10:52:53 2010 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 0993C3A6A86; Mon, 12 Apr 2010 10:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[AWL=0.393, 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 r267NO6703eb; Mon, 12 Apr 2010 10:52:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 010183A6A77; Mon, 12 Apr 2010 10:52:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1NiF-0005u2-Qn for namedroppers-data0@psg.com; Mon, 12 Apr 2010 17:46:19 +0000 Received: from [74.125.82.52] (helo=mail-ww0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Ni7-0005ru-Kc for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 17:46:12 +0000 Received: by wwi17 with SMTP id 17so1923wwi.11 for ; Mon, 12 Apr 2010 10:46:09 -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:received:message-id:subject:from:to:content-type :content-transfer-encoding; bh=wWflf7kH6+65yIgBJdqI4wcE/pJsSdkmaA3pxbQNl48=; b=kpPy4VJpOAd3ADJEF3s9PnKdN++zEeY/GTM4sBnwY1pxZBc2SymdavgaEpAxNzvw36 afEwBIxEER1zlBMjwOQu+Oqu/gFhLA2/gwdMSVmVqZPC69pUJBPatriQ5aHViUr62CJf DepNtLycCloIIowWp6KEWGF5jU9wMYwZ1OBzk= 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:content-transfer-encoding; b=OTbWaqsACbG3wr5HXsIoD+jII1dNlE9yZTfhjC1v4NV7xwKH5jaMCIjlFng8Tv7+Wn 7fYaCPX4ZjO28nooEScNFpAWYr2J1JT1P5uCt0D0jnRfYKvF8LrLFautYsY119I9LLGU sAypFPpT28ujB3/uoCj2DMhzRPJJwbPrDnms8= MIME-Version: 1.0 Received: by 10.216.6.90 with HTTP; Mon, 12 Apr 2010 10:46:09 -0700 (PDT) In-Reply-To: <600.1271091683@nsa.vix.com> References: <4BB3E324.2050207@isc.org> <600.1271091683@nsa.vix.com> Date: Mon, 12 Apr 2010 13:46:09 -0400 Received: by 10.216.87.68 with SMTP id x46mr2538370wee.145.1271094369555; Mon, 12 Apr 2010 10:46:09 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Privacy and Re: ...-edns-client-ip-00 From: Donald Eastlake To: IETF DNSEXT WG 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: Hi Paul, On Mon, Apr 12, 2010 at 1:01 PM, Paul Vixie wrote: >> Date: Mon, 12 Apr 2010 11:36:12 -0400 >> From: Donald Eastlake >> >> I would say that the vast majority of users would be delighted to trade = a >> slightly fuzzed version of their IP address on all DNS queries for an >> improvement in their average network service where that improvement woul= d >> be most significant for web and/or higher bandwidth streaming media. > > i don't doubt this. =A0and yet, this is a rather sweeping change to the > internet's architecture, where is the IAB's position statement on it? It does not seem like a sweeping change to the Internet's architecture to me. At least no more sweeping than a change from distance-vector routing, which gives visibility only to summary reports from adjacent nodes, to link-state routing, which gives a global view of connectivity throughout the routing domain. Is there an IAB position statement giving an "IAB position" or even commenting on the improved performance but decreased node privacy caused by link-state routing? I don't think so and I do not expect the IAB to produce a position statement on the particular question we are discussing here, although they are certainly welcome to produce one if they want. > and also yet, the average citizen trades privacy for convenience every > day, but in other non-internet contexts there are regulators who can > say "hold on a minute, that's very sexy but the implications are dire." > shall we say that none of that thinking applies to the freewheeling > internet, and let the buyers simply beware? That is why, in my initial statement, my observation of customer willingness was coupled with a statement that I did not see "dire" implications. Thanks, Donald From owner-namedroppers@ops.ietf.org Mon Apr 12 10:53:07 2010 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 9BD4B3A6A9B; Mon, 12 Apr 2010 10:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.676 X-Spam-Level: X-Spam-Status: No, score=-4.676 tagged_above=-999 required=5 tests=[AWL=0.372, 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 5bxHV1JeT4dM; Mon, 12 Apr 2010 10:53:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0E77B3A6A86; Mon, 12 Apr 2010 10:53:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1NlR-0006QM-RV for namedroppers-data0@psg.com; Mon, 12 Apr 2010 17:49:37 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1NlM-0006Pu-35 for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 17:49:32 +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 o3CHnFar016466; Mon, 12 Apr 2010 10:49:15 -0700 (PDT) References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> In-Reply-To: <1468.1271092699@nsa.vix.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , "namedroppers WG" From: Nicholas Weaver Subject: Re: [dnsext] edns-client-ip privacy rat-hole Date: Mon, 12 Apr 2010 10:49:15 -0700 To: Paul Vixie X-Mailer: Apple Mail (2.1078) 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 Apr 12, 2010, at 10:18 AM, Paul Vixie wrote: >> From: "George Barwood" >> Date: Mon, 12 Apr 2010 17:49:18 +0100 >>=20 >> Concealing the identity of clients is not a design goal of the = current >> DNS standard, nor should it be. >=20 > it is however an emergent property of the current system, on which = many > users may be relying. this should not be changed without = investigation. If indeed this was an emergent property of the current system, Akamai = tricks wouldn't exist. Rather, for first party resolvers, with pretty good precision, you get a = good idea of where the querying clients are in network-topology space. =20= Thus the emergent property is actually the opposite of what you assert: = the IP of the recursive resolver tells the authorities where the clients = are located in the network. THIS is the emergent property we should be concerned with: should only = those clients who use their ISP's resolver benefit from this property? From owner-namedroppers@ops.ietf.org Mon Apr 12 11:08:54 2010 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 9645228C11B; Mon, 12 Apr 2010 11:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.845 X-Spam-Level: * X-Spam-Status: No, score=1.845 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_50=0.001, 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 xDoUjE+7ctV0; Mon, 12 Apr 2010 11:08:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 73BC728C146; Mon, 12 Apr 2010 11:08:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1NzX-0009Cg-Bt for namedroppers-data0@psg.com; Mon, 12 Apr 2010 18:04:11 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1NzR-0009C2-5v for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 18:04:05 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3CI3udA036725; Mon, 12 Apr 2010 14:03:56 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Mon, 12 Apr 2010 14:04:03 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 12 Apr 2010 14:04:03 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1468.1271092699@nsa.vix.com> References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> Date: Mon, 12 Apr 2010 14:03:53 -0400 To: "namedroppers WG" From: Edward Lewis Subject: Re: [dnsext] edns-client-ip privacy rat-hole Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 17:18 +0000 4/12/10, Paul Vixie wrote: >> From: "George Barwood" >> Date: Mon, 12 Apr 2010 17:49:18 +0100 >> >> Concealing the identity of clients is not a design goal of the current >> DNS standard, nor should it be. > >it is however an emergent property of the current system, on which many >users may be relying. this should not be changed without investigation. I don't think I agree with that concealing activity is an emerging property of the system, nor does a statement including "users may be relying" confer any sense of authority to any claim that the Internet's architecture is leaning one way or another. It is true that we don't have a book on privacy, there's no "level playing field." Namedroppers is not the place to write one up either, we aren't the experts on the topic. Without that book, a set of guidelines and requirements on privacy, or any topic for that matter, we are just going to rat hole. Rat-hole activities just lead to stagnation. Nothing will ever get done in the engineering sense. Consensus will be impossible to achieve because at any moment, some one might say "I have privacy concerns." This is a problem for the chairs - will issues, like privacy, that have historically not been discussed on the list be able to block the publication of extensions? I agree that a concern that is shown to be well-founded may appear at any time and needs to be addressed. But what about concerns that aren't shown to be a direct relation to the protocol (architecture)? In summary of this thread (privacy/edns-client-ip) what I see is this round of questions: One side: Does the option forward on info that is currently not forwarded? The other side: Yes, what is the problem with that? (I am trying very hard to find a problem. I can't. Not even with caller ID as a telephone analogy.) Users want to be concealed? Show me that. And show me what they want to be concealed from. (Are you concealing spammers? Phishers? I agree they want anonymity.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From owner-namedroppers@ops.ietf.org Mon Apr 12 11:57:16 2010 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 2C7C728C14E; Mon, 12 Apr 2010 11:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.122, 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 lc71L7wLk+K5; Mon, 12 Apr 2010 11:57:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 515E228C155; Mon, 12 Apr 2010 11:57:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Ogi-000G2H-Nh for namedroppers-data0@psg.com; Mon, 12 Apr 2010 18:48:48 +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.71 (FreeBSD)) (envelope-from ) id 1O1Ogg-000G1R-IR for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 18:48:46 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id EFFE5A1BB8 for ; Mon, 12 Apr 2010 18:48:45 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers WG" Subject: Re: [dnsext] edns-client-ip privacy rat-hole In-Reply-To: Your message of "Mon, 12 Apr 2010 10:49:15 MST." References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 12 Apr 2010 18:48:45 +0000 Message-ID: <5534.1271098125@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: Nicholas Weaver > Date: Mon, 12 Apr 2010 10:49:15 -0700 > > >> Concealing the identity of clients is not a design goal of the current > >> DNS standard, nor should it be. > > > > it is however an emergent property of the current system, on which many > > users may be relying. this should not be changed without investigation. > > If indeed this was an emergent property of the current system, Akamai > tricks wouldn't exist. that's nonsequitur. akamai needs to guess the location but not the identity, and in my opinion those tricks are just marketing smoke/mirrors in any case. this endless back and forth isn't illuminative and won't be conclusive. i'm going to lay off the point by point replies for a while until i can get my thoughts organized well enough for a position-blogpost somewhere. From owner-namedroppers@ops.ietf.org Mon Apr 12 12:09:37 2010 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 5942C3A68FE; Mon, 12 Apr 2010 12:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 TEe1X3DXNhZ5; Mon, 12 Apr 2010 12:09:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 861DB3A6ABF; Mon, 12 Apr 2010 12:09:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1OwB-000Jah-He for namedroppers-data0@psg.com; Mon, 12 Apr 2010 19:04:47 +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.71 (FreeBSD)) (envelope-from ) id 1O1Ow8-000JZb-Ux for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 19:04:44 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id B4946A1BB7 for ; Mon, 12 Apr 2010 19:04:44 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie to: "namedroppers WG" Subject: Re: [dnsext] edns-client-ip privacy rat-hole In-Reply-To: Your message of "Mon, 12 Apr 2010 18:48:45 GMT." <5534.1271098125@nsa.vix.com> References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 12 Apr 2010 19:04:44 +0000 Message-ID: <6278.1271099084@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: Paul Vixie > Date: Mon, 12 Apr 2010 18:48:45 +0000 > ... > this endless back and forth isn't illuminative and won't be conclusive. > i'm going to lay off the point by point replies for a while until i can > get my thoughts organized well enough for a position-blogpost somewhere. forgot to say: ...and, i recommend that others do likewise. From owner-namedroppers@ops.ietf.org Mon Apr 12 12:15:01 2010 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 BA12028C18E; Mon, 12 Apr 2010 12:15:01 -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 bwga01JvuLW9; Mon, 12 Apr 2010 12:15:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 26FDE28C1A1; Mon, 12 Apr 2010 12:14:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1P2L-000L69-0n for namedroppers-data0@psg.com; Mon, 12 Apr 2010 19:11:09 +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.71 (FreeBSD)) (envelope-from ) id 1O1P2J-000L5b-4q for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 19:11:07 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id DAC09A1BBD for ; Mon, 12 Apr 2010 19:11:06 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-Reply-To: Your message of "Mon, 12 Apr 2010 20:05:32 +0100." <19005DAF043444A092106B6CDB1EBA25@localhost> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <20100412164403.GR11706@shinkuro.com> <1266.1271092587@nsa.vix.com> <19005DAF043444A092106B6CDB1EBA25@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 12 Apr 2010 19:11:06 +0000 Message-ID: <6613.1271099466@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: Mon, 12 Apr 2010 20:05:32 +0100 > > > on the basis of #3 and #4 above, i think that BNAME should be adopted. > > The problem with BNAME is I think that DNSSEC validators must perform > special processing (similar to DNAME), or validation errors will occur - > the CNAME records will not validate without special processing. > > Thus it is not backward compatible with already deployed validating > resolvers* security complicates things, i see what you mean. unless we can synthesize the RRSIG that covers the synthesized CNAME, this would be a real problem. > One point that makes me uneasy is why DNAME was not defined to redirect > itself. > > Was there a reason for this? we wanted to be able to use DNAME at zone apexes, and the rule against CNAME and other data sharing an owner name made it really complicated. the use case for DNAME (which has disappeared) was bit string label PTR RRs, for which this mattered. > * A possible alternative that IS backwards compatible might be to return > the normal non-BNAME answer, and supply the BNAME as additional > information ( say in the authority section ) that can be used by BNAME > aware clients. Was this considered? ( Just a wild idea - I have not > thought for a long while on this ). since the non-BNAME answer might be out of zone, this isn't an approach. From owner-namedroppers@ops.ietf.org Mon Apr 12 12:31:11 2010 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 307673A6AAC; Mon, 12 Apr 2010 12:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.729 X-Spam-Level: X-Spam-Status: No, score=-4.729 tagged_above=-999 required=5 tests=[AWL=0.319, 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 lUGdSOJMQ9dU; Mon, 12 Apr 2010 12:31:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C92413A6AA2; Mon, 12 Apr 2010 12:31:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1PDP-000NOK-25 for namedroppers-data0@psg.com; Mon, 12 Apr 2010 19:22:35 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1PDM-000NNd-3D for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 19:22:32 +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 o3CJMFRN002396; Mon, 12 Apr 2010 12:22:15 -0700 (PDT) References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> In-Reply-To: <5534.1271098125@nsa.vix.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , "namedroppers WG" From: Nicholas Weaver Subject: Re: [dnsext] edns-client-ip privacy rat-hole Date: Mon, 12 Apr 2010 12:22:14 -0700 To: Paul Vixie X-Mailer: Apple Mail (2.1078) 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 Apr 12, 2010, at 11:48 AM, Paul Vixie wrote: >> From: Nicholas Weaver >> Date: Mon, 12 Apr 2010 10:49:15 -0700 >>=20 >>>> Concealing the identity of clients is not a design goal of the = current >>>> DNS standard, nor should it be. >>>=20 >>> it is however an emergent property of the current system, on which = many >>> users may be relying. this should not be changed without = investigation. >>=20 >> If indeed this was an emergent property of the current system, Akamai >> tricks wouldn't exist. >=20 > that's nonsequitur. akamai needs to guess the location but not the = identity, > and in my opinion those tricks are just marketing smoke/mirrors in any = case. No its not a non-sequiter: You are implying that location IS = privacy-sensitive, since edns-client-subnet [1] exports effectively = equivalent location information. That is exactly the point: to have third party resolvers able to = effectively convey the same location information that first party = resolvers already do by dint of the resolver's IP address. [1] which is really what it is, not client's IP but subnet with mask, = there is never a reason to do it more precise than /24, and most = resolvers would probably want even coarser to save cache and RTTs. From owner-namedroppers@ops.ietf.org Mon Apr 12 12:45:11 2010 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 510073A6AC3; Mon, 12 Apr 2010 12:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 NTXf+6Zk2ijO; Mon, 12 Apr 2010 12:45:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D24293A6A6F; Mon, 12 Apr 2010 12:45:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1PTm-000Pyr-1i for namedroppers-data0@psg.com; Mon, 12 Apr 2010 19:39: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.71 (FreeBSD)) (envelope-from ) id 1O1PTj-000Pyc-Vw for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 19:39:28 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id B669BA1BC6 for ; Mon, 12 Apr 2010 19:39:27 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers WG" Subject: Re: [dnsext] edns-client-ip privacy rat-hole In-Reply-To: Your message of "Mon, 12 Apr 2010 12:22:14 MST." References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 12 Apr 2010 19:39:27 +0000 Message-ID: <7879.1271101167@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: Nicholas Weaver > Date: Mon, 12 Apr 2010 12:22:14 -0700 > ... > That is exactly the point: to have third party resolvers able to > effectively convey the same location information that first party > resolvers already do by dint of the resolver's IP address. a client who cares about this can use a resolver that shares its IP path. however, if a client doesn't know or care about this, it won't be as easy for distant/centralized resolvers to avoid masking the supposed benefits of Stupid DNS Tricks by CDN's. seems like akamai and opendns built things that can't work, not even on a theoretical basis, because IP paths are so often not the same between a web browser and an opendns resolver, and now they're asking to ratchet up the complexity level of the whole industry in order to support these innovations. that in turn looks like an architectural change to the internet itself, which i'd like to see debated on that basis rather than just incrementally added out here in a working group. the architecture at present assumes a couple of local resolvers per network and that clients there will use those. we could achieve the exposure of web browser IP location to CDNs at DNS query time just by telling opendns to install proxies on every customer subnet. or we could tell CDN providers that they should use HTTP redirects rather than incoherent DNS to achieve their marketed benefits. it also seems like this is primarily a web thing not an internet thing, and that W3C would most likely love to add some kind of XMLRPC lookup mechanism with a UDP transport so that a web browser could stop asking internet level questions like "what's the address of web server XYZ" and start asking web level questions like "if my IP address is X and my language is Y and my GPS is Z then what are the preferred servers, in order, that i should use to reach URI Q?" opendns and akamai could innovate quite well and without any controversy as web companies within a framework like this. DNS basically works today, but not without a lot of effort by implementors and operators of infrastructure. making it more complicated and less predictable in order to support a single application (web browsing) is not something we should do mindlessly or incrementally or lightly. From owner-namedroppers@ops.ietf.org Mon Apr 12 13:00:16 2010 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 750C33A67DB; Mon, 12 Apr 2010 13:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.727 X-Spam-Level: * X-Spam-Status: No, score=1.727 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 nSkRk8mdVuN2; Mon, 12 Apr 2010 13:00:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DF16328C11B; Mon, 12 Apr 2010 13:00:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Pie-0002iE-62 for namedroppers-data0@psg.com; Mon, 12 Apr 2010 19:54:52 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Pib-0002hn-Qm for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 19:54:49 +0000 Received: by pwi1 with SMTP id 1so4851872pwi.11 for ; Mon, 12 Apr 2010 12:54:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.169.1 with HTTP; Mon, 12 Apr 2010 12:54:48 -0700 (PDT) In-Reply-To: <5534.1271098125@nsa.vix.com> References: <4BB3E324.2050207@isc.org> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> Date: Mon, 12 Apr 2010 12:54:48 -0700 Received: by 10.141.110.4 with SMTP id n4mr3919272rvm.261.1271102088713; Mon, 12 Apr 2010 12:54:48 -0700 (PDT) Message-ID: Subject: Re: [dnsext] edns-client-ip privacy rat-hole From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Paul Vixie Cc: namedroppers WG 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, Apr 12, 2010 at 11:48 AM, Paul Vixie wrote:>> > that's nonsequitur. =A0akamai needs to guess the location but not the ide= ntity, > and in my opinion those tricks are just marketing smoke/mirrors in any ca= se. What kind of experiment and data would convince you otherwise? For example, would it be sufficient to measure the TCP/80 RTT from say, 100 internet locations from some DNS-tricks based CDNs? As a control, this data could be compared to the TCP/53 RTT to port 53 at one of the well-deployed anycast root servers. And as a further refinement, we could then force those 100 locations to use a public recursive DNS offering, and compare the results again. The utility of the tricks need not be based on opinions, let's establish their true effect. > this endless back and forth isn't illuminative and won't be conclusive. = =A0i'm > going to lay off the point by point replies for a while until i can get m= y > thoughts organized well enough for a position-blogpost somewhere. Respectfully; I do not agree with this suggestion. We are supposed to be engineering here, and should concentrate on establishing facts and making our decisions data-driven. Further ideological debate and positioning is not useful. Many here do not agree with the position outlined in the ACMqueue article, months after the fact, so unfortunately evidence does not suggest that this will be a productive line of endeavor. Personally I think it is most useful to state objections explicitly, and to give examples or evidence as to how they can be demonstrated. All of that said, it feels like we need a summary of where we are, so I'll = try. It seems that at at the core of all this is simply an ideologically disagreement about what DNS actually is, and what it should be. One camp feels that the DNS has become a lookup and mapping system. And also that one useful property of such a system is to be able to route/map users to their nearest network endpoints. Their argument is that it benefits end user experience, and makes the internet "better" to some. It is also a source of profit to some who have decided to operate DNS in this way. The other camp feels that DNS is a database (and in fact RFC1035 talks about the DNS in these terms), and that modulo the effects of caching, that it is about presenting a consistent view of data - and that to do anything else is "lying". In real terms, this camp feels that the effects of this "lying" are a shifting of burden - both operational and economic - to innocent middlemen without their consent, and that this is harmful. In ideological and sensibility terms, the conversation seems to be; "We shouldn't afford DNS tricks any stamp of approval, it's a harmful precedent that encourages lecherous entrepreneurship at the expense of bystanders" Vs "We should recognize how the real internet is working, irrespective of how good/evil some of that is, and try to engineer it better". It feels like the privacy-arguments are merely a proxy for this core disagreement. Do what I'm wondering is - do we have any engineering methods at are disposal to arrive at a middle-ground, or consensus. For example, would another DNS option be useful that explicitly declares the answer section as "dynamic", aka "not a database" aka "lying" (I guess an evil bit for DNS) be useful? If there are no such methods for resolving the core disagreement, then it seems that we should ignore it, and move on to quantifying the measurable and real effects of the proposal and what benefit or harm it may cause. --=20 Colm From owner-namedroppers@ops.ietf.org Mon Apr 12 13:02:32 2010 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 2FBE03A69B5; Mon, 12 Apr 2010 13:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 sUfhJgA9bYcP; Mon, 12 Apr 2010 13:02:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4DF203A68EE; Mon, 12 Apr 2010 13:02:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1PnI-0003Xs-E3 for namedroppers-data0@psg.com; Mon, 12 Apr 2010 19:59:40 +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.71 (FreeBSD)) (envelope-from ) id 1O1PnG-0003XH-3J for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 19:59:38 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id E389AA1BC0 for ; Mon, 12 Apr 2010 19:59:36 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers WG Subject: Re: [dnsext] edns-client-ip privacy rat-hole In-Reply-To: Your message of "Mon\, 12 Apr 2010 12\:54\:48 MST." References: <4BB3E324.2050207@isc.org> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Apr 2010 19:59:36 +0000 Message-ID: <8744.1271102376@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: Mon, 12 Apr 2010 12:54:48 -0700 > From: Colm MacC=E1rthaigh >=20 > What kind of experiment and data would convince you otherwise? For > example, would it be sufficient to measure the TCP/80 RTT from say, 100 > internet locations from some DNS-tricks based CDNs? that would not convince me, nope. a representative sample of services and consumers would be orders of magnitude larger than those size numbers. From owner-namedroppers@ops.ietf.org Mon Apr 12 13:14:58 2010 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 D0FEE3A6AC5; Mon, 12 Apr 2010 13:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.077 X-Spam-Level: * X-Spam-Status: No, score=1.077 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 P2KShZWL8U-9; Mon, 12 Apr 2010 13:14:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1AF523A6AD0; Mon, 12 Apr 2010 13:14:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1PwH-0005Hd-OC for namedroppers-data0@psg.com; Mon, 12 Apr 2010 20:08:57 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1PwF-0005HG-Dc for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 20:08:55 +0000 Received: by pwi1 with SMTP id 1so4868304pwi.11 for ; Mon, 12 Apr 2010 13:08:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.169.1 with HTTP; Mon, 12 Apr 2010 13:08:54 -0700 (PDT) In-Reply-To: <7879.1271101167@nsa.vix.com> References: <4BB3E324.2050207@isc.org> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> <7879.1271101167@nsa.vix.com> Date: Mon, 12 Apr 2010 13:08:54 -0700 Received: by 10.115.87.32 with SMTP id p32mr4136550wal.86.1271102934364; Mon, 12 Apr 2010 13:08:54 -0700 (PDT) Message-ID: Subject: Re: [dnsext] edns-client-ip privacy rat-hole From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Paul Vixie , IETF DNSEXT WG 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, Apr 12, 2010 at 12:39 PM, Paul Vixie wrote > seems like akamai and opendns built things that can't work, not even on a > theoretical basis, because IP paths are so often not the same between a web > browser and an opendns resolver, and now they're asking to ratchet up the > complexity level of the whole industry in order to support these > innovations. Just to be very explicit about this; my understanding of the proposal is that it is not being considered as a mandatory option, and probably not even the standards track. In other words, using the above examples, only opendns and akamai would have to implement the option and deal with the complexity fallout. An ordinary client, using public DNS, or openDNS, or whoever, need do nothing special and the net effect to them is that they may get different answers depending on the IP block they query from. Inconsistent answers towards clients is a pattern DNS has exhibited since day one (due to caching) - so it certainly seems well-tested. If a network operator that forwards to public DNS, or openDNS, chooses to implement the option, then they will get extra complexity - but clearly they are opting in. And again, the behaviour towards clients regresses to the same situation as my previous paragraph. Can you give some concrete examples of what "ratchet up the complexity level of the whole industry" corresponds to? -- Colm From owner-namedroppers@ops.ietf.org Mon Apr 12 13:16:21 2010 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 C0B053A6AC9; Mon, 12 Apr 2010 13:16:21 -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 OK4Ezn8awdh0; Mon, 12 Apr 2010 13:16:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 332403A6830; Mon, 12 Apr 2010 13:16:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Q0R-00065U-Ko for namedroppers-data0@psg.com; Mon, 12 Apr 2010 20:13:15 +0000 Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Q0P-00063p-3j for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 20:13:13 +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 2A2FB15427EB; Mon, 12 Apr 2010 21:13:09 +0100 (BST) Cc: "namedroppers WG" Message-Id: <8BC94CF7-0CCC-46E3-AC4D-80003CC4CCB0@rfc1035.com> From: Jim Reid To: Paul Vixie In-Reply-To: <7879.1271101167@nsa.vix.com> 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] edns-client-ip privacy rat-hole Date: Mon, 12 Apr 2010 21:13:07 +0100 References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> <7879.1271101167@nsa.vix.com> 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 12 Apr 2010, at 20:39, Paul Vixie wrote: > DNS basically works today, but not without a lot of effort by > implementors > and operators of infrastructure. making it more complicated and less > predictable in order to support a single application (web browsing) > is not > something we should do mindlessly or incrementally or lightly. +1,000 From owner-namedroppers@ops.ietf.org Mon Apr 12 13:19:09 2010 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 5DF1E3A6AD2; Mon, 12 Apr 2010 13:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.86 X-Spam-Level: X-Spam-Status: No, score=0.86 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 X+LQmm-y69Fj; Mon, 12 Apr 2010 13:18:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DFCDF3A6AB2; Mon, 12 Apr 2010 13:18:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Q2S-0006S6-J7 for namedroppers-data0@psg.com; Mon, 12 Apr 2010 20:15:20 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Q2P-0006Rg-QB for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 20:15:17 +0000 Received: by pwi1 with SMTP id 1so4875525pwi.11 for ; Mon, 12 Apr 2010 13:15:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.169.1 with HTTP; Mon, 12 Apr 2010 13:15:16 -0700 (PDT) In-Reply-To: <8744.1271102376@nsa.vix.com> References: <4BB3E324.2050207@isc.org> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> <8744.1271102376@nsa.vix.com> Date: Mon, 12 Apr 2010 13:15:16 -0700 Received: by 10.141.110.4 with SMTP id n4mr3960804rvm.261.1271103316817; Mon, 12 Apr 2010 13:15:16 -0700 (PDT) Message-ID: Subject: Re: [dnsext] edns-client-ip privacy rat-hole From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Paul Vixie , IETF DNSEXT WG 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, Apr 12, 2010 at 12:59 PM, Paul Vixie wrote: >> Date: Mon, 12 Apr 2010 12:54:48 -0700 >> From: Colm MacC=E1rthaigh >> >> What kind of experiment and data would convince you otherwise? For >> example, would it be sufficient to measure the TCP/80 RTT from say, 100 >> internet locations from some DNS-tricks based CDNs? > > that would not convince me, nope. =A0a representative sample of services > and consumers would be orders of magnitude larger than those size numbers= . Can you propose a specific experiment that could be run practically? --=20 Colm From owner-namedroppers@ops.ietf.org Mon Apr 12 13:32:26 2010 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 96F4628C1A8; Mon, 12 Apr 2010 13:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.769 X-Spam-Level: X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[AWL=0.279, 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 1v0uUtKJZrj0; Mon, 12 Apr 2010 13:32:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 461F128C1A7; Mon, 12 Apr 2010 13:32:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1QF3-0008Qg-WA for namedroppers-data0@psg.com; Mon, 12 Apr 2010 20:28:22 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1QEx-0008PZ-CQ for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 20:28:15 +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 o3CKS0JU011820; Mon, 12 Apr 2010 13:28:00 -0700 (PDT) References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> <7879.1271101167@nsa.vix.com> In-Reply-To: <7879.1271101167@nsa.vix.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , "namedroppers WG" From: Nicholas Weaver Subject: Re: [dnsext] edns-client-ip privacy rat-hole Date: Mon, 12 Apr 2010 13:27:59 -0700 To: Paul Vixie X-Mailer: Apple Mail (2.1078) 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 Apr 12, 2010, at 12:39 PM, Paul Vixie wrote: > a client who cares about this can use a resolver that shares its IP = path. > however, if a client doesn't know or care about this, it won't be as = easy > for distant/centralized resolvers to avoid masking the supposed = benefits of > Stupid DNS Tricks by CDN's. Except the point is that the CDN tricks work because users generally DO = use network-local resolvers. This architecture works! > the architecture at present assumes a couple of local resolvers per = network > and that clients there will use those. we could achieve the exposure = of > web browser IP location to CDNs at DNS query time just by telling = opendns > to install proxies on every customer subnet. or we could tell CDN = providers > that they should use HTTP redirects rather than incoherent DNS to = achieve > their marketed benefits. This straw-man doesn't work because it is LATENCY that matters. If you = go through an HTTP 302 redirect or similar, you add 2 more round trips. = The goal of all of this is to greatly improve the latency, and the way = to do that is to limit DNS to one RTT, and have everything else go to a = very close server. Adding 100ms+ for a 302 redirect kills any savings = you get by going to a "close" server vs just one on the same part of the = continent. Why isn't everything over SSL when you go to Google? Its not the crypto = (even public key is cheap these days, and you can always throw hardware = at it), but SSL adds RTTs on setup. There is an overall desire to make web pages load in 200ms or less, from = when the user clicks on the link. And one of the key tenants for that = to work is for DNS to be able to deliver the IP of a "topologically = close" server. And this works when you use the ISPs' resolvers. =20 It is only when you use third party resolvers that this assumption = breaks down, and since it is a very small minority that currently uses = third party resolvers, AND this behavior is a barrier to third-party = resolvers becoming more popular, how can you not class this as a bug? > it also seems like this is primarily a web thing not an internet = thing, and > that W3C would most likely love to add some kind of XMLRPC lookup = mechanism > with a UDP transport so that a web browser could stop asking internet = level > questions like "what's the address of web server XYZ" and start asking = web > level questions like "if my IP address is X and my language is Y and = my GPS > is Z then what are the preferred servers, in order, that i should use = to > reach URI Q?" opendns and akamai could innovate quite well and = without any > controversy as web companies within a framework like this. So you don't want DNS? You want a competing system, specifically for = server discovery, and full deployment in order to be useful? This seems a silly straw man argument. =20 Almost as silly as requiring any viable third-party resolver to attain = CDN-level deployment of resolvers WITH multihoming (since resolvers are = found by IP, not name). > DNS basically works today, but not without a lot of effort by = implementors > and operators of infrastructure. making it more complicated and less > predictable in order to support a single application (web browsing) is = not > something we should do mindlessly or incrementally or lightly. Client-subnet passes your complaints here: It only makes things more = complicated for those who actually would benefit from using it. =20 As long as existing authority implementations properly behave when they = receive unknown EDNS options, its a complete non-issue: only those who = directly benefit from this would bother to implement it, so the = resolvers for Google, OpenDNS, etc, and the authorities which are = already doing CDN tricks. Nobody else would be affected. Unless you are saying authorities are going to blow up and catch on fire = if you throw unknown EDNS options their way. So in the end, pick your poison: #1: Allow third-party resolvers to gain the same benefits that = first-party resolvers have by adding a mechanism for them to express = client subnet to the domain authorities, information that first-party = resolvers implicitly reveal already and such authorities already rely = on. or #2: Decide that third-party resolvers MUST remain at a competitive = disadvantage to first party resolvers. Because option 3, making these DNS tricks go away, or asserting that = they aren't useful, ain't gonna happen. From owner-namedroppers@ops.ietf.org Mon Apr 12 14:02:18 2010 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 9381428C124; Mon, 12 Apr 2010 14:02:18 -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 O1mpu6BuFICM; Mon, 12 Apr 2010 14:02:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B47C03A67B4; Mon, 12 Apr 2010 14:02:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1QgC-000Cd8-8H for namedroppers-data0@psg.com; Mon, 12 Apr 2010 20:56:24 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Qg9-000Ccs-LN for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 20:56:21 +0000 Received: by pwi1 with SMTP id 1so4922658pwi.11 for ; Mon, 12 Apr 2010 13:56:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Mon, 12 Apr 2010 13:56:19 -0700 (PDT) In-Reply-To: <8744.1271102376@nsa.vix.com> References: <4BB3E324.2050207@isc.org> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> <8744.1271102376@nsa.vix.com> Date: Mon, 12 Apr 2010 13:56:19 -0700 Received: by 10.115.117.19 with SMTP id u19mr4223541wam.84.1271105779739; Mon, 12 Apr 2010 13:56:19 -0700 (PDT) Message-ID: Subject: Re: [dnsext] edns-client-ip privacy rat-hole From: Matthew Dempsky To: Paul Vixie Cc: namedroppers WG 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, Apr 12, 2010 at 12:59 PM, Paul Vixie wrote: >> Date: Mon, 12 Apr 2010 12:54:48 -0700 >> From: Colm MacC=E1rthaigh >> >> What kind of experiment and data would convince you otherwise? For >> example, would it be sufficient to measure the TCP/80 RTT from say, 100 >> internet locations from some DNS-tricks based CDNs? > > that would not convince me, nope. =A0a representative sample of services > and consumers would be orders of magnitude larger than those size numbers= . One of the fundamental theorems of statistics is that statistical power depends only on sample size, not population size. From owner-namedroppers@ops.ietf.org Mon Apr 12 14:24:41 2010 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 CA53428C19F; Mon, 12 Apr 2010 14:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 KDHVz9R4xuui; Mon, 12 Apr 2010 14:24:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB1C63A6AD5; Mon, 12 Apr 2010 14:24:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1R1Q-000GBG-HJ for namedroppers-data0@psg.com; Mon, 12 Apr 2010 21:18:20 +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.71 (FreeBSD)) (envelope-from ) id 1O1R1M-000GAt-Q1 for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 21:18:16 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 1BBFEA1BEA for ; Mon, 12 Apr 2010 21:18:16 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] edns-client-ip privacy rat-hole In-Reply-To: Your message of "Mon\, 12 Apr 2010 13\:08\:54 MST." References: <4BB3E324.2050207@isc.org> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> <7879.1271101167@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Apr 2010 21:18:16 +0000 Message-ID: <12058.1271107096@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: Mon, 12 Apr 2010 13:08:54 -0700 > From: Colm MacC=E1rthaigh >=20 > Can you give some concrete examples of what "ratchet up the complexity > level of the whole industry" corresponds to? if akamai and opendns are doing it, then who among their competitors would not also be doing it? this is not as simple as "opt-in" or "opt-out", even if we were sure that intermediate caches weren't going to strip off the client's opt-out client-ip 0.0.0.0 blob and put in an accurate one, either by malicious intent or just by nonmalicious operator/implementor error. but apart from that i had another thought at lunch today. if we're adding to the lookup tuple, then in dnssec terms don't we also have to add to the thing that rrsig is denoted by and/or the thing that rrsig covers? that is, if we're going to have N:N>1 rrsets having the same at the same time visible by the same intermediate cache and also by mobile clients within a single TTL and signature validity period, then won't we also have N:N>1 RRSIGs at the same owner name and having the same type-covered? From owner-namedroppers@ops.ietf.org Mon Apr 12 14:26:55 2010 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 DE66A28C1A3; Mon, 12 Apr 2010 14:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 2dnA9z42yka5; Mon, 12 Apr 2010 14:26:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7204B28C144; Mon, 12 Apr 2010 14:26:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1R3o-000GY1-KK for namedroppers-data0@psg.com; Mon, 12 Apr 2010 21:20:48 +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.71 (FreeBSD)) (envelope-from ) id 1O1R3l-000GWX-R1 for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 21:20:45 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 8B829A1BDF for ; Mon, 12 Apr 2010 21:20:45 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] edns-client-ip privacy rat-hole In-Reply-To: Your message of "Mon\, 12 Apr 2010 13\:15\:16 MST." References: <4BB3E324.2050207@isc.org> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> <8744.1271102376@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Apr 2010 21:20:45 +0000 Message-ID: <12134.1271107245@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: Mon, 12 Apr 2010 13:15:16 -0700 > From: Colm MacC=E1rthaigh >=20 > >> What kind of experiment and data would convince you otherwise? For > >> example, would it be sufficient to measure the TCP/80 RTT from say, > >> 100 internet locations from some DNS-tricks based CDNs? > > > > that would not convince me, nope. =A0a representative sample of services > > and consumers would be orders of magnitude larger than those size > > numbers. >=20 > Can you propose a specific experiment that could be run practically? as a lot of people in a position to say so authoritatively and based on personal experience can tell you, i'm no scientist. i'd like to believe that there's an empirical test whose inputs would be less burdensome than those of an actual working implementation of stupid dns tricks -- that is, less than complete knowledge. but if so i don't know what it is. weav? From owner-namedroppers@ops.ietf.org Mon Apr 12 14:41:07 2010 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 7D0253A672E; Mon, 12 Apr 2010 14:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_05=-1.11] 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 4J09xKbIwN8K; Mon, 12 Apr 2010 14:41:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 873983A6846; Mon, 12 Apr 2010 14:40:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1RHY-000ISv-VU for namedroppers-data0@psg.com; Mon, 12 Apr 2010 21:35:01 +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.71 (FreeBSD)) (envelope-from ) id 1O1RHW-000ISd-EC for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 21:34:58 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 28D15A1BE9 for ; Mon, 12 Apr 2010 21:34:58 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-Reply-To: Your message of "Mon, 12 Apr 2010 21:50:27 +0100." References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <20100412164403.GR11706@shinkuro.com> <1266.1271092587@nsa.vix.com> <19005DAF043444A092106B6CDB1EBA25@localhost> <6613.1271099466@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 12 Apr 2010 21:34:58 +0000 Message-ID: <12708.1271108098@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: Mon, 12 Apr 2010 21:50:27 +0100 > > By "normal" I mean the answer which would be given if BNAME were not > invented, which would usually be a referral. i think it would usually be an NXDOMAIN. > ... I suggest that $INCLUDE is good enough for producing copies of zones, > and the objective should be to minimize cache memory requirements for > state-of-the-art resolvers ( especially in view of the larger requirement > due to DNSSEC ). as a side note, i've been cautious in my SHADOW work to only speak in terms of zone transfers, and not in master file format or directives there (such as $INCLUDE). many authority DNS providers do not have anything like master file format and just use an external database (SQL) or internal database (BDB) for zone storage, and some only allow changes through the external database interface or through RFC 2136 UPDATE commands. others allow one-time import of "master file format" (which they sometimes mistakenly call "BIND format"). while there are also some authority implementations who do not use zone transfers to synchronize their authority servers, everybody seems to offer zone transfers (at least AXFR and often also IXFR). so, when i described mirroring in the SHADOW proposal, i described it in those terms. i guess this means i don't think it's realistic to defend "master file format" as a part of the DNS specification, but if so, consider that it does not appear "on the wire" and as such there is no possible interoperability test for it. (would "$INCLUDE DKA0:[SYS.DATA]FILE.DAT" fail such a test even though it would work fine on the VAX/VMS server that the master file came from?) > There is also a question of whether applications should re-write domain > names based on BNAME records before submitting requests to web servers > etc. That avoids the necessity of issuing multiple SSL certificates for > these domains in the long run, but possibly raises delicate security > questions. it's also a change to the application, which i specifically ruled out in my own work. if we're going to make a material difference to DNS within our own lifetimes we're not going to be changing anything except the zone's own authority servers and perhaps the zone's ancestor's authority servers. From owner-namedroppers@ops.ietf.org Mon Apr 12 14:57:34 2010 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 015453A68CD; Mon, 12 Apr 2010 14:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.5 X-Spam-Level: X-Spam-Status: No, score=-4.5 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_62=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 9dgbzJBVb+Fu; Mon, 12 Apr 2010 14:57:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DCCF83A679F; Mon, 12 Apr 2010 14:57:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1RXq-000Ktn-SD for namedroppers-data0@psg.com; Mon, 12 Apr 2010 21:51:50 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1RXk-000Krv-FT for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 21:51:44 +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 o3CLpRI6023060; Mon, 12 Apr 2010 14:51:27 -0700 (PDT) References: <4BB3E324.2050207@isc.org> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> <7879.1271101167@nsa.vix.com> <12058.1271107096@nsa.vix.com> In-Reply-To: <12058.1271107096@nsa.vix.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <3D98D6E5-C81F-46DC-B527-4123DCC998C6@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , IETF DNSEXT WG From: Nicholas Weaver Subject: Re: [dnsext] edns-client-ip privacy rat-hole Date: Mon, 12 Apr 2010 14:51:27 -0700 To: Paul Vixie X-Mailer: Apple Mail (2.1078) 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 Apr 12, 2010, at 2:18 PM, Paul Vixie wrote: >> Date: Mon, 12 Apr 2010 13:08:54 -0700 >> From: Colm MacC=E1rthaigh >>=20 >> Can you give some concrete examples of what "ratchet up the = complexity >> level of the whole industry" corresponds to? >=20 > if akamai and opendns are doing it, then who among their competitors = would > not also be doing it? this is not as simple as "opt-in" or "opt-out", = even > if we were sure that intermediate caches weren't going to strip off = the > client's opt-out client-ip 0.0.0.0 blob and put in an accurate one, = either > by malicious intent or just by nonmalicious operator/implementor = error. Anyone who cares about privacy BETTER NOT be using OpenDNS, Google = Public DNS, or similar services. These services are specifically NOT privacy preserving, and anyone who = considers using them in this way would be misusing them. And you WANT the competitors to be doing this: Without something = standard, you get pairwise agreements and provider A can do better than = provider B. Standards prevent this. > but apart from that i had another thought at lunch today. if we're = adding > to the lookup tuple, then in dnssec terms don't we also have to add to = the > thing that rrsig is denoted by and/or the thing that rrsig covers? = that is, > if we're going to have N:N>1 rrsets having the same = at the > same time visible by the same intermediate cache and also by mobile = clients > within a single TTL and signature validity period, then won't we also = have > N:N>1 RRSIGs at the same owner name and having the same type-covered? If you think of client-subnet as representing a scope, you only have 1 = signed RRSET per scope in the cache, which would make this = not-a-problem. You wouldn't be able to DNSSEC-protect that the value is = in the proper scope, but since the scope is an optimization, not an = absolute, this would, IMO, be OK. =20 If you wanted to add scope restrictions in the signature of the RRSET, = you'd need a new RTYPE rather than an EDNS option in replies, which = conveys that this RRSET is valid for this client subnet only. > i'd like to believe > that there's an empirical test whose inputs would be less burdensome = than > those of an actual working implementation of stupid dns tricks -- that = is, > less than complete knowledge. but if so i don't know what it is. = weav? A thought comes to mind: =20 Time the time it takes to load a sample web image OR an error message = with a cache-busting NONCE for a known-akamai'ed site from the client, = and from the same site when queried through OpenDNS, UltraDNS, and = Google Public DNS. For a known-failure, this should be DNS time (measure separately), and = 2x RTT to the Akamai'ed site (make the request with connection-close to = terminate), which will allow one to see how the different DNS providers = + akamai behave and if (and how much) it really makes a difference. You'd probably want to do it in signed java, but it MIGHT be doable in = Javascript. Its actually on the list of "hmm, might be interesting". From owner-namedroppers@ops.ietf.org Mon Apr 12 15:18:04 2010 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 3B7793A692C; Mon, 12 Apr 2010 15:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, J_CHICKENPOX_62=0.6] 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 kbks4E65iIdI; Mon, 12 Apr 2010 15:18:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 216613A6ACA; Mon, 12 Apr 2010 15:14:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Rm8-000NHV-8R for namedroppers-data0@psg.com; Mon, 12 Apr 2010 22:06:36 +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.71 (FreeBSD)) (envelope-from ) id 1O1Rm5-000NH6-HC for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 22:06:33 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 38035A1B7E for ; Mon, 12 Apr 2010 22:06:33 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] edns-client-ip privacy rat-hole In-Reply-To: Your message of "Mon, 12 Apr 2010 14:51:27 MST." <3D98D6E5-C81F-46DC-B527-4123DCC998C6@icsi.berkeley.edu> References: <4BB3E324.2050207@isc.org> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> <7879.1271101167@nsa.vix.com> <12058.1271107096@nsa.vix.com> <3D98D6E5-C81F-46DC-B527-4123DCC998C6@icsi.berkeley.edu> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 12 Apr 2010 22:06:33 +0000 Message-ID: <14093.1271109993@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: Nicholas Weaver > Date: Mon, 12 Apr 2010 14:51:27 -0700 > > > but apart from that i had another thought at lunch today. if we're > > adding to the lookup tuple, then in dnssec terms don't we also have to > > add to the thing that rrsig is denoted by and/or the thing that rrsig > > covers? that is, if we're going to have N:N>1 rrsets having the same > > at the same time visible by the same intermediate > > cache and also by mobile clients within a single TTL and signature > > validity period, then won't we also have N:N>1 RRSIGs at the same owner > > name and having the same type-covered? > > If you think of client-subnet as representing a scope, you only have 1 > signed RRSET per scope in the cache, which would make this not-a-problem. that covers the caching intermediary, with the understanding that the RRSIG has to be treated as having scope. what about a mobile client whose scope can change within a TTL and signature validity period? are you assuming that mobile clients will always set edns-client-ip and will scope any rrsets they cache, along with any signatures? if so then i wonder what happens if the client doesn't set edns-client-ip and its caching intermediary changes as a result of mobility. are you expecting the (unscoped) underlying rrset and its (therefore also unscoped) covering RRSIG to expire in tandem? > You wouldn't be able to DNSSEC-protect that the value is in the proper > scope, but since the scope is an optimization, not an absolute, this > would, IMO, be OK. > > If you wanted to add scope restrictions in the signature of the RRSET, > you'd need a new RTYPE rather than an EDNS option in replies, which > conveys that this RRSET is valid for this client subnet only. that sounds right to me. > > ... that is, less than complete knowledge. but if so i don't know what > > it is. weav? > > A thought comes to mind: > > Time the time it takes to load a sample web image OR an error message > with a cache-busting NONCE for a known-akamai'ed site from the client, > and from the same site when queried through OpenDNS, UltraDNS, and Google > Public DNS. > > For a known-failure, this should be DNS time (measure separately), and 2x > RTT to the Akamai'ed site (make the request with connection-close to > terminate), which will allow one to see how the different DNS providers + > akamai behave and if (and how much) it really makes a difference. > > You'd probably want to do it in signed java, but it MIGHT be doable in > Javascript. Its actually on the list of "hmm, might be interesting". that's good news. From owner-namedroppers@ops.ietf.org Mon Apr 12 15:28:13 2010 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 695233A6923; Mon, 12 Apr 2010 15:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.057 X-Spam-Level: * X-Spam-Status: No, score=1.057 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 8Zg+HU9uuTFJ; Mon, 12 Apr 2010 15:28:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 302BA3A6971; Mon, 12 Apr 2010 15:25:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1S0R-00007M-S1 for namedroppers-data0@psg.com; Mon, 12 Apr 2010 22:21:23 +0000 Received: from [209.85.210.184] (helo=mail-yx0-f184.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1S0P-00006k-GS for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 22:21:21 +0000 Received: by yxe14 with SMTP id 14so2872820yxe.5 for ; Mon, 12 Apr 2010 15:21:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Mon, 12 Apr 2010 15:21:20 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Apr 2010 15:21:20 -0700 Received: by 10.150.48.27 with SMTP id v27mr4497706ybv.53.1271110880164; Mon, 12 Apr 2010 15:21:20 -0700 (PDT) Message-ID: Subject: [dnsext] Re: Reserved EDNS0 option codes for private use From: Matthew Dempsky To: IETF DNSEXT WG 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, Apr 9, 2010 at 1:47 AM, Matthew Dempsky wrote= : > According to http://www.iana.org/assignments/dns-parameters, there are > no EDNS0 option codes reserved for private use. =A0As every other 16-bit > DNS parameter reserves 65280--65534 for private use, I suggest the > same range be similarly reserved for EDNS0 option codes. I've submitted the below draft requesting IANA reserve this range for private use: http://www.ietf.org/id/draft-dempsky-edns0-options-for-private-use-00.t= xt Comments? From owner-namedroppers@ops.ietf.org Mon Apr 12 15:28:22 2010 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 6B64E3A6846; Mon, 12 Apr 2010 15:28:22 -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=[AWL=-0.047, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_62=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 AXZgQ-g1MO5V; Mon, 12 Apr 2010 15:28:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3532D3A6B0B; Mon, 12 Apr 2010 15:25:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1RzZ-000PwZ-Pp for namedroppers-data0@psg.com; Mon, 12 Apr 2010 22:20:29 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1RzX-000PwF-KM for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 22:20:27 +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 o3CMKDvk027846; Mon, 12 Apr 2010 15:20:13 -0700 (PDT) References: <4BB3E324.2050207@isc.org> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> <7879.1271101167@nsa.vix.com> <12058.1271107096@nsa.vix.com> <3D98D6E5-C81F-46DC-B527-4123DCC998C6@icsi.berkeley.edu> In-Reply-To: <3D98D6E5-C81F-46DC-B527-4123DCC998C6@icsi.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <36E2F397-04FB-48D9-B83F-0671C15A4205@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable Cc: Paul Vixie , IETF DNSEXT WG From: Nicholas Weaver Subject: Re: [dnsext] edns-client-ip privacy rat-hole Date: Mon, 12 Apr 2010 15:20:13 -0700 To: Nicholas Weaver X-Mailer: Apple Mail (2.1078) 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 Apr 12, 2010, at 2:51 PM, Nicholas Weaver wrote: > A thought comes to mind: =20 >=20 > Time the time it takes to load a sample web image OR an error message = with a cache-busting NONCE for a known-akamai'ed site from the client, = and from the same site when queried through OpenDNS, UltraDNS, and = Google Public DNS. >=20 > For a known-failure, this should be DNS time (measure separately), and = 2x RTT to the Akamai'ed site (make the request with connection-close to = terminate), which will allow one to see how the different DNS providers = + akamai behave and if (and how much) it really makes a difference. >=20 > You'd probably want to do it in signed java, but it MIGHT be doable in = Javascript. Its actually on the list of "hmm, might be interesting". Just as a single data point, where I would actually expect everything to = work well for third party resolvers (given my bay area location): =20 I did this for a321.g.akamai.net (which is the name used for amongst = other things, the IRS website). Local resolver: Gets me 198.189.255.73, ~3ms latency. =20 Traceroute shows to cenic.net in oakland to an akamai node. OpenDNS: Gets me 72.246.53.9, ~3ms latency. Traceroute shows to cenic.net in oakland to two akamai hops. Slightly = different but the same effective path Google Public DNS: Gets me to 96.17.8.97, ~20ms latency. Traceroute shows to Transitrail to seattle, WA. That 20ms will add up on a real web visit however, as 3-4 RTTs are = burned for various things: SYN, page load, image page load, script = loads, etc... From owner-namedroppers@ops.ietf.org Mon Apr 12 17:11:01 2010 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 13C413A68C7; Mon, 12 Apr 2010 17:11:01 -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 h+YJOvrNfrVc; Mon, 12 Apr 2010 17:10:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 72BE33A6868; Mon, 12 Apr 2010 17:10:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Ta8-000Fxn-OG for namedroppers-data0@psg.com; Tue, 13 Apr 2010 00:02:20 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1TZz-000Fw3-Qz for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 00:02:11 +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 6800DE8071; Tue, 13 Apr 2010 00:02:10 +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 o3D024Os010600; Tue, 13 Apr 2010 10:02:05 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004130002.o3D024Os010600@drugs.dv.isc.org> To: "George Barwood" Cc: "Paul Vixie" , namedroppers@ops.ietf.org From: Mark Andrews References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <20100412164403.GR11706@shinkuro.com> <1266.1271092587@nsa.vix.com> <19005DAF043444A092106B6CDB1EBA25@localhost> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-reply-to: Your message of "Mon, 12 Apr 2010 20:05:32 +0100." <19005DAF043444A092106B6CDB1EBA25@localhost> Date: Tue, 13 Apr 2010 10:02:04 +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 <19005DAF043444A092106B6CDB1EBA25@localhost>, "George Barwood" writes : > > on the basis of #3 and #4 above, i think that BNAME should be adopted. > > The problem with BNAME is I think that DNSSEC validators must perform > special processing (similar to DNAME), or validation errors will occur - the CNAME > records will not validate without special processing. > > Thus it is not backward compatible with already deployed validating resolvers* So what? We know how to deal with this. Use the DNSSEC algorithm to signal that there may be a BNAME in the zone the same way as we use the DNSSEC algorithm to signal that there may be NSEC3 records in the zone. > One point that makes me uneasy is why DNAME was not defined to redirect itself. > > Was there a reason for this? Yes. The current behaviour allows companies to alias zones without involving the parent zone. > * A possible alternative that IS backwards compatible might be to return the > normal non-BNAME answer, and supply the BNAME as additional information > ( say in the authority section ) that can be used by BNAME aware clients. > Was this considered? ( Just a wild idea - I have not thought for a long while on this ). You return a CNAME or a BNAME, never both for the same qname, based on whether the client signals BNAME understanding (EDNS option). 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 Mon Apr 12 18:35:44 2010 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 6D0AE3A6810; Mon, 12 Apr 2010 18:35:44 -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 i7JTu-ZkZhOZ; Mon, 12 Apr 2010 18:35:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 80FEF3A67B5; Mon, 12 Apr 2010 18:35:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Uvi-00026E-2q for namedroppers-data0@psg.com; Tue, 13 Apr 2010 01:28:42 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Uve-00025y-VS for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 01:28:39 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3D1SbV6039969 for ; Mon, 12 Apr 2010 21:28:37 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id o3D1SbWC039968 for namedroppers@ops.ietf.org; Mon, 12 Apr 2010 21:28:37 -0400 (EDT) (envelope-from namedroppers) Received: from [64.78.22.237] (helo=EXPFE100-2.exc.icann.org) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1TYB-000Fb6-Qm for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 00:00:19 +0000 Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 12 Apr 2010 17:00:19 -0700 From: Tina Dam To: "namedroppers@ops.ietf.org" Date: Mon, 12 Apr 2010 17:00:19 -0700 Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Thread-Topic: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Thread-Index: AcrYGHYnX4u0yl5GRqGQ7M4B9astJwCgOdQw Message-ID: <05B243F724B2284986522B6ACD0504D7D341EB499E@EXVPMBX100-1.exc.icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_05B243F724B2284986522B6ACD0504D7D341EB499EEXVPMBX1001ex_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 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. ] --_000_05B243F724B2284986522B6ACD0504D7D341EB499EEXVPMBX1001ex_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I am sorry for joining the discussion late. I hope it is useful to = re-state some things related to ICANN's plan for Synchronized IDN ccTLDs. I= understand that this has been a confusion subject and I apologies for that= --_000_05B243F724B2284986522B6ACD0504D7D341EB499EEXVPMBX1001ex_-- From owner-namedroppers@ops.ietf.org Mon Apr 12 19:40:17 2010 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 C46C03A6AE1; Mon, 12 Apr 2010 19:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=-0.201, 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 rm02O7CnH2xa; Mon, 12 Apr 2010 19:40:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A8BB63A6AF0; Mon, 12 Apr 2010 19:40:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Vx0-000ApO-D4 for namedroppers-data0@psg.com; Tue, 13 Apr 2010 02:34:06 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1Vww-000Aov-NT for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 02:34:03 +0000 Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3D2XuFN040345; Mon, 12 Apr 2010 22:33:57 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4BC3D80E.5070306@ogud.com> Date: Mon, 12 Apr 2010 22:33:50 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: cet1@cam.ac.uk CC: "Rose, Scott W." , namedroppers Subject: Final allocation: Re: [dnsext] ECC-Gost DNSKEY and DS values assigned References: <4BBCC1A9.9030903@ogud.com> In-Reply-To: <4BBCC1A9.9030903@ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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: IANA updated the DNSKEY algorithm registry http://www.iana.org/assignments/dns-sec-alg-numbers/ 12 ECC-GOST The DS digest allocation is the same as before. Olafur From owner-namedroppers@ops.ietf.org Mon Apr 12 21:20:34 2010 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 B80CC3A6AF1; Mon, 12 Apr 2010 21:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.722 X-Spam-Level: X-Spam-Status: No, score=-9.722 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HABEAS_ACCREDITED_SOI=-4.3, HELO_MISMATCH_COM=0.553, RCVD_IN_BSP_TRUSTED=-4.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 WFsb8XjxQwAW; Mon, 12 Apr 2010 21:20:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ED6013A659C; Mon, 12 Apr 2010 21:20:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1XWO-000Oo4-0n for namedroppers-data0@psg.com; Tue, 13 Apr 2010 04:14:44 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1XWK-000Ond-Uc for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 04:14:41 +0000 Received: (qmail 14885 invoked from network); 13 Apr 2010 04:14:39 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 13 Apr 2010 04:14:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k1004; olt=johnl@user.iecc.com; bh=F/zMCuvgD1DhtDiCLDINm69ARhKM/fu+veIZdnnMF5M=; b=AqZjKoTPbmn6qiWUhtMZV+l3gBTjUEZLoD4jTVKTbtPJ93DRTyxn0eDz9Z8ef2ggr/ATcxfLwGeTv1VFFB6+o49jBT7VWBZSk2M/94otAW4Ej3GhhYDzayRIAVx11sYENZJ/S4eCXWLtU1qB7JMxDBE+aWCFPAC6pwuKigP+q3Y= Date: 13 Apr 2010 04:14:39 -0000 Message-ID: <20100413041439.45880.qmail@simone.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-Reply-To: <1266.1271092587@nsa.vix.com> Organization: Cc: vixie@isc.org X-Headerized: yes Mime-Version: 1.0 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: >basis 5. parallel delegations would benefit from standardized automation. I'm not at all sure this is true. ICANN's current plan says "not surprising" rather than "same bits". It is possible that ICANN is wrong, and people would prefer the same bits, but it is also quite possible that they are right, and providing the same bits doesn't solve a big enough problem to be worth new mechanism. R's, John From owner-namedroppers@ops.ietf.org Mon Apr 12 23:15:43 2010 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 70F013A6856; Mon, 12 Apr 2010 23:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.976 X-Spam-Level: **** X-Spam-Status: No, score=4.976 tagged_above=-999 required=5 tests=[AWL=1.081, 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 oro8749u6WtK; Mon, 12 Apr 2010 23:15:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 54F9A3A6853; Mon, 12 Apr 2010 23:15:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1ZEv-000GPv-1D for namedroppers-data0@psg.com; Tue, 13 Apr 2010 06:04:49 +0000 Received: from [195.188.213.6] (helo=smtp-out3.blueyonder.co.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1ZEp-000GN4-1e for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 06:04:43 +0000 Received: from [172.23.170.143] (helo=anti-virus02-10) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1O1ZEn-0000bb-6c; Tue, 13 Apr 2010 07:04:41 +0100 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1O1ZEm-0007Hk-II; Tue, 13 Apr 2010 07:04:40 +0100 Message-ID: <8DA2E211CC484529B2BC222063C45A03@localhost> From: "George Barwood" To: "Mark Andrews" Cc: "Paul Vixie" , References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <20100412164403.GR11706@shinkuro.com> <1266.1271092587@nsa.vix.com> <19005DAF043444A092106B6CDB1EBA25@localhost> <201004130002.o3D024Os010600@drugs.dv.isc.org> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Date: Tue, 13 Apr 2010 07:04:35 +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: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmsgQW5kcmV3cyIgPG1h cmthQGlzYy5vcmc+DQpUbzogIkdlb3JnZSBCYXJ3b29kIiA8Z2VvcmdlLmJhcndvb2RAYmx1ZXlv bmRlci5jby51az4NCkNjOiAiUGF1bCBWaXhpZSIgPHZpeGllQGlzYy5vcmc+OyA8bmFtZWRyb3Bw ZXJzQG9wcy5pZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDEzLCAyMDEwIDE6MDIgQU0N ClN1YmplY3Q6IFJlOiBbZG5zZXh0XSBJQ0FOTidzICJzeW5jaHJvbml6ZWQgZG9tYWlucyIgYW5k IHRoZSBETlNFWFQgYWxpYXMgbWF5YmUtd29yayANCg0KDQo+IA0KPiBJbiBtZXNzYWdlIDwxOTAw NURBRjA0MzQ0NEEwOTIxMDZCNkNEQjFFQkEyNUBsb2NhbGhvc3Q+LCAiR2VvcmdlIEJhcndvb2Qi IHdyaXRlcw0KPiA6DQo+PiA+IG9uIHRoZSBiYXNpcyBvZiAjMyBhbmQgIzQgYWJvdmUsIGkgdGhp bmsgdGhhdCBCTkFNRSBzaG91bGQgYmUgYWRvcHRlZC4NCj4+IA0KPj4gVGhlIHByb2JsZW0gd2l0 aCBCTkFNRSBpcyBJIHRoaW5rIHRoYXQgRE5TU0VDIHZhbGlkYXRvcnMgbXVzdCBwZXJmb3JtDQo+ PiBzcGVjaWFsIHByb2Nlc3NpbmcgKHNpbWlsYXIgdG8gRE5BTUUpLCBvciB2YWxpZGF0aW9uIGVy cm9ycyB3aWxsIG9jY3VyIC0gdGhlIENOQU1FDQo+PiByZWNvcmRzIHdpbGwgbm90IHZhbGlkYXRl IHdpdGhvdXQgc3BlY2lhbCBwcm9jZXNzaW5nLg0KPj4gDQo+PiBUaHVzIGl0IGlzIG5vdCBiYWNr d2FyZCBjb21wYXRpYmxlIHdpdGggYWxyZWFkeSBkZXBsb3llZCB2YWxpZGF0aW5nIHJlc29sdmVy cyoNCj4gDQo+IFNvIHdoYXQ/ICBXZSBrbm93IGhvdyB0byBkZWFsIHdpdGggdGhpcy4NCj4gDQo+ IFVzZSB0aGUgRE5TU0VDIGFsZ29yaXRobSB0byBzaWduYWwgdGhhdCB0aGVyZSBtYXkgYmUgYSBC TkFNRSBpbiB0aGUNCj4gem9uZSB0aGUgc2FtZSB3YXkgYXMgd2UgdXNlIHRoZSBETlNTRUMgYWxn b3JpdGhtIHRvIHNpZ25hbCB0aGF0DQo+IHRoZXJlIG1heSBiZSBOU0VDMyByZWNvcmRzIGluIHRo ZSB6b25lLg0KDQpUaGUgInNvIHdoYXQiIGlzIHRoYXQgaXQgd2lsbCBiZSB1bnNhZmUgdG8gZGVw bG95IEJOQU1FIGFzIGRlZmluZWQgaW4gdGhlIGN1cnJlbnQgZHJhZnQNCmJlY2F1c2UgaXQgY2Fu IGNhdXNlIHZhbGlkYXRpb24gZXJyb3JzIHdpdGggdmFsaWRhdGluZyByZXNvbHZlcnMgdGhhdCBo YXZlIG5vdCBiZWVuIHVwZGF0ZWQNCnRvIHN1cHBvcnQgQk5BTUUuIE1heWJlIHRoZXJlIGFyZSBz byBmZXcgdmFsaWRhdGluZyByZXNvbHZlcnMgY3VycmVudGx5IGRlcGxveWVkIHRoYXQNCnRoaXMg aXMgbm90IGEgcHJvYmxlbSwgYnV0IEkgdGhpbmsgaXQgYXQgbGVhc3QgbmVlZHMgY29uc2lkZXJh dGlvbi4NCg0KPj4gT25lIHBvaW50IHRoYXQgbWFrZXMgbWUgdW5lYXN5IGlzIHdoeSBETkFNRSB3 YXMgbm90IGRlZmluZWQgdG8gcmVkaXJlY3QgaXRzZWxmLg0KPj4gDQo+PiBXYXMgdGhlcmUgYSBy ZWFzb24gZm9yIHRoaXM/DQo+IA0KPiBZZXMuICBUaGUgY3VycmVudCBiZWhhdmlvdXIgYWxsb3dz IGNvbXBhbmllcyB0byBhbGlhcyB6b25lcyB3aXRob3V0IGludm9sdmluZw0KPiB0aGUgcGFyZW50 IHpvbmUuDQoNClRoYW5rcywgSSBzZWUuIEkgd29uZGVyIGlmIEROQU1FLCB3aGlsZSBub3QgcGVy ZmVjdCwgaXMgc3VmZmljaWVudCB0byBzb2x2ZQ0KbW9zdCBvZiB0aGUgcHJvYmxlbSB3aXRob3V0 IHVwZGF0aW5nIHRoZSBzdGFuZGFyZC4gUHJvYmFibHkgZ29pbmcgb3ZlciBvbGQgZ3JvdW5kIGhl cmUuDQogDQo+PiAqIEEgcG9zc2libGUgYWx0ZXJuYXRpdmUgdGhhdCBJUyBiYWNrd2FyZHMgY29t cGF0aWJsZSBtaWdodCBiZSB0byByZXR1cm4gdGhlDQo+PiBub3JtYWwgbm9uLUJOQU1FIGFuc3dl ciwgYW5kIHN1cHBseSB0aGUgQk5BTUUgYXMgYWRkaXRpb25hbCBpbmZvcm1hdGlvbg0KPj4gKCBz YXkgaW4gdGhlIGF1dGhvcml0eSBzZWN0aW9uICkgdGhhdCBjYW4gYmUgdXNlZCBieSBCTkFNRSBh d2FyZSBjbGllbnRzLg0KPj4gV2FzIHRoaXMgY29uc2lkZXJlZD8gKCBKdXN0IGEgd2lsZCBpZGVh IC0gSSBoYXZlIG5vdCB0aG91Z2h0IGZvciBhIGxvbmcgd2hpbGUgb24gdGhpcyApLg0KPiANCj4g WW91IHJldHVybiBhIENOQU1FIG9yIGEgQk5BTUUsIG5ldmVyIGJvdGggZm9yIHRoZSBzYW1lIHFu YW1lLCBiYXNlZA0KPiBvbiB3aGV0aGVyIHRoZSBjbGllbnQgc2lnbmFscyBCTkFNRSB1bmRlcnN0 YW5kaW5nIChFRE5TIG9wdGlvbikuDQoNCkkgZG9uJ3QgdGhpbmsgdGhhdCBoZWxwcyA6IGEgdmFs aWRhdGluZyByZXNvbHZlciB0aGF0IGRvZXNuJ3Qgc3VwcG9ydCBCTkFNRSB3aWxsIHN0aWxsDQpm YWlsIGJlY2F1c2UgdGhlIENOQU1FIHJlY29yZCBpcyBub3Qgc2lnbmVkICggYXNzdW1pbmcgRE5T U0VDIGhhcyBiZWVuIGZ1bGx5IGRlcGxveWVkICkuDQoNCj4gTWFyaw0KPiAtLSANCj4gTWFyayBB bmRyZXdzLCBJU0MNCj4gMSBTZXltb3VyIFN0LiwgRHVuZGFzIFZhbGxleSwgTlNXIDIxMTcsIEF1 c3RyYWxpYQ0KPiBQSE9ORTogKzYxIDIgOTg3MSA0NzQyICAgICAgICAgICAgICAgICBJTlRFUk5F VDogbWFya2FAaXNjLm9yZw== From dm@ietf.org Mon Apr 12 23:36:41 2010 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 0F0ED3A69D7 for ; Mon, 12 Apr 2010 23:36:41 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 12 Apr 2010 23:36:37 -0700 (PDT) Received: from 95-30-42-66.broadband.corbina.ru (95-30-42-66.broadband.corbina.ru [95.30.42.66]) by core3.amsl.com (Postfix) with SMTP id E82BA28C1D1 for ; Mon, 12 Apr 2010 23:33:58 -0700 (PDT) From: Approved VIAGRA® Store Subject: Sales Event get 73% off To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100413063400.E82BA28C1D1@core3.amsl.com> Date: Mon, 12 Apr 2010 23:33:58 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 23222 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Tue Apr 13 02:27:54 2010 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 2B1613A6A27; Tue, 13 Apr 2010 02:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.552 X-Spam-Level: * X-Spam-Status: No, score=1.552 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Axgh6L5T1g7j; Tue, 13 Apr 2010 02:27:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 686AF3A6AF1; Tue, 13 Apr 2010 02:24:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1cF5-000Lqh-1w for namedroppers-data0@psg.com; Tue, 13 Apr 2010 09:17:11 +0000 Received: from [83.145.227.89] (helo=gusev.araneus.fi) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1cF2-000LqP-1B for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 09:17:08 +0000 Received: from guava.gson.org (guava.gson.org [83.145.227.105]) by gusev.araneus.fi (Postfix) with ESMTP id C5F1291D9C; Tue, 13 Apr 2010 12:16:44 +0300 (EEST) Received: by guava.gson.org (Postfix, from userid 101) id 6A5F175E8A; Tue, 13 Apr 2010 12:17:05 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19396.13968.881313.199510@guava.gson.org> Date: Tue, 13 Apr 2010 12:17:04 +0300 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-Reply-To: <12708.1271108098@nsa.vix.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <20100412164403.GR11706@shinkuro.com> <1266.1271092587@nsa.vix.com> <19005DAF043444A092106B6CDB1EBA25@localhost> <6613.1271099466@nsa.vix.com> <12708.1271108098@nsa.vix.com> X-Mailer: VM 8.0.14 under 21.4.1 (i386--netbsdelf) 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: Paul Vixie wrote: > as a side note, i've been cautious in my SHADOW work to only speak in terms > of zone transfers, and not in master file format or directives there I don't think you have, because draft-vixie-dnsext-dnsshadow-00 makes a distinction between "relative" and "fully qualified" names, and that distinction only exists in master files and not in zone transfers. Since names in zone transfers are encoded in the DNS wire format, they are always effectively fully qualified. In particular, the technique describe in the last sentence of the following paragraph can't be applied to zone transfer data: 2.2.1. For example, if an Amber zone at VIX.COM has a master file which describe an apex MX RR with an unqualified MX EXCHANGE domain name such as MAIL1, then the MX target in the Amber zone will be MAIL1.VIX.COM. A Shadow of this zone whose apex is VIXIE.SF.CA.US will show this MX EXCHANGE as MAIL1.VIXIE.SF.CA.US. This may require configuration changes to supporting applications such as SMTP servers. This behaviour can be prevented by using fully qualified names wherever the name of the Amber zone, and not the name of its various Shadow zones, is to be published in the RDATA. -- Andreas Gustafsson, gson@araneus.fi From owner-namedroppers@ops.ietf.org Tue Apr 13 02:35:07 2010 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 E0C2B3A6804; Tue, 13 Apr 2010 02:35:07 -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 7idDYzXuoGDd; Tue, 13 Apr 2010 02:35:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 12CA73A6989; Tue, 13 Apr 2010 02:34:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1cRx-000Nn5-Ko for namedroppers-data0@psg.com; Tue, 13 Apr 2010 09:30:29 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1cRp-000Nlo-U6 for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 09:30:22 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3D9UKp8042932 for ; Tue, 13 Apr 2010 05:30:20 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id o3D9UKub042931 for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 05:30:20 -0400 (EDT) (envelope-from namedroppers) Received: from [64.78.22.237] (helo=EXPFE100-2.exc.icann.org) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1TYB-000Fb6-Qm for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 00:00:19 +0000 Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 12 Apr 2010 17:00:19 -0700 From: Tina Dam To: "namedroppers@ops.ietf.org" Date: Mon, 12 Apr 2010 17:00:19 -0700 Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Thread-Topic: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Thread-Index: AcrYGHYnX4u0yl5GRqGQ7M4B9astJwCgOdQw Message-ID: <05B243F724B2284986522B6ACD0504D7D341EB499E@EXVPMBX100-1.exc.icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_05B243F724B2284986522B6ACD0504D7D341EB499EEXVPMBX1001ex_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 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. ] --_000_05B243F724B2284986522B6ACD0504D7D341EB499EEXVPMBX1001ex_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I am sorry for joining the discussion late. I hope it is useful to = re-state some things related to ICANN's plan for Synchronized IDN ccTLDs. I= understand that this has been a confusion subject and I apologies for that= --_000_05B243F724B2284986522B6ACD0504D7D341EB499EEXVPMBX1001ex_-- From owner-namedroppers@ops.ietf.org Tue Apr 13 03:58:59 2010 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 DDF813A6A02; Tue, 13 Apr 2010 03:58:59 -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 V64hOHH3T4fp; Tue, 13 Apr 2010 03:58:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 475B23A6A11; Tue, 13 Apr 2010 03:58:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1djR-000Enh-1M for namedroppers-data0@psg.com; Tue, 13 Apr 2010 10:52:37 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1djO-000EnF-AU for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 10:52: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 E005DE8145; Tue, 13 Apr 2010 10:52:32 +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 o3DAqTtv026844; Tue, 13 Apr 2010 20:52:30 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004131052.o3DAqTtv026844@drugs.dv.isc.org> To: "George Barwood" Cc: "Paul Vixie" , namedroppers@ops.ietf.org From: Mark Andrews References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <20100412164403.GR11706@shinkuro.com> <1266.1271092587@nsa.vix.com> <19005DAF043444A092106B6CDB1EBA25@localhost> <201004130002.o3D024Os010600@drugs.dv.isc.org> <8DA2E211CC484529B2BC222063C45A03@localhost> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-reply-to: Your message of "Tue, 13 Apr 2010 07:04:35 +0100." <8DA2E211CC484529B2BC222063C45A03@localhost> Date: Tue, 13 Apr 2010 20:52:29 +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 <8DA2E211CC484529B2BC222063C45A03@localhost>, "George Barwood" write s: > > ----- Original Message ----- > From: "Mark Andrews" > To: "George Barwood" > Cc: "Paul Vixie" ; > Sent: Tuesday, April 13, 2010 1:02 AM > Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work > > > > > > In message <19005DAF043444A092106B6CDB1EBA25@localhost>, "George Barwood" writes > > : > >> > on the basis of #3 and #4 above, i think that BNAME should be adopted. > >> > >> The problem with BNAME is I think that DNSSEC validators must perform > >> special processing (similar to DNAME), or validation errors will occur - the CNAME > >> records will not validate without special processing. > >> > >> Thus it is not backward compatible with already deployed validating resolvers* > > > > So what? We know how to deal with this. > > > > Use the DNSSEC algorithm to signal that there may be a BNAME in the > > zone the same way as we use the DNSSEC algorithm to signal that > > there may be NSEC3 records in the zone. > > The "so what" is that it will be unsafe to deploy BNAME as defined in the current draft > because it can cause validation errors with validating resolvers that have not been updated > to support BNAME. Maybe there are so few validating resolvers currently deployed that > this is not a problem, but I think it at least needs consideration. Has the draft passed last call? How to deal with this has been described multiple times. We don't need to write it into the draft while we are still discussing the basic BNAME concept. We know we can make it work. > >> One point that makes me uneasy is why DNAME was not defined to redirect itself. > >> > >> Was there a reason for this? > > > > Yes. The current behaviour allows companies to alias zones without involving > > the parent zone. > > Thanks, I see. I wonder if DNAME, while not perfect, is sufficient to solve > most of the problem without updating the standard. Probably going over old > ground here. Indeed. > >> * A possible alternative that IS backwards compatible might be to return the > >> normal non-BNAME answer, and supply the BNAME as additional information > >> ( say in the authority section ) that can be used by BNAME aware clients. > >> Was this considered? ( Just a wild idea - I have not thought for a long while on this ). > > > > You return a CNAME or a BNAME, never both for the same qname, based > > on whether the client signals BNAME understanding (EDNS option). > > I don't think that helps : a validating resolver that doesn't support BNAME will still > fail because the CNAME record is not signed ( assuming DNSSEC has been fully deployed ). Apply the rules above and a validating resolver that doesn't understand BNAME will always treat the zone containing the BNAME as insecure as it won't understand the algorithm. A BNAME aware resolver will get the records and any relevent signatures provided there is a BNAME aware path between it and the authoritative server. 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 Tue Apr 13 04:02:04 2010 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 F0F1528C0F9; Tue, 13 Apr 2010 04:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[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 OwYZ16GqF6QP; Tue, 13 Apr 2010 04:02:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C9AC028C0FB; Tue, 13 Apr 2010 04:02:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1dob-000G1S-Lu for namedroppers-data0@psg.com; Tue, 13 Apr 2010 10:57:57 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1doX-000Fyf-Vk for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 10:57:54 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1O1doV-00063e-Cd; Tue, 13 Apr 2010 12:57:51 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.71) (envelope-from ) id 1O1doV-0004Of-09; Tue, 13 Apr 2010 12:57:51 +0200 From: Florian Weimer To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> Date: Tue, 13 Apr 2010 12:57:50 +0200 In-Reply-To: <20100409145117.GH3595@shinkuro.com> (Andrew Sullivan's message of "Fri, 9 Apr 2010 10:51:17 -0400") Message-ID: <87r5mj39ht.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: * Andrew Sullivan: > If you do not agree with that conclusion, it would be interesting to > me to hear why not, and what you think needs support in the protocol > that cannot be accommodated in ICANN's plan. When submitting a message, an email client needs to know what type of IDN transofrmation to apply, to avoid to do something to the addresses which is lossy, so that the server still can translate it to something expected by the network (if any such translation is necessary). This needs protocol support, but since email submission does not generally have access to DNS information, a protocol which is purely DNS-based cannot provide a solution. Any attempt to deal with this in DNS alone (whether through protocol extensions or through clever provisioning) will eventually lead to complaints that some domains do not work right, and further protocol work outside DNS. From dnsext-archive@ietf.org Tue Apr 13 04:14:52 2010 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 8E39E3A699D for ; Tue, 13 Apr 2010 04:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -62.727 X-Spam-Level: X-Spam-Status: No, score=-62.727 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, TVD_RCVD_IP=1.931, URI_HEX=0.368, 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 oPAn4Yhh0FUn for ; Tue, 13 Apr 2010 04:14:45 -0700 (PDT) Received: from 189.27.164.155.dynamic.adsl.gvt.net.br (189.27.164.155.dynamic.adsl.gvt.net.br [189.27.164.155]) by core3.amsl.com (Postfix) with ESMTP id 85A4D28C124 for ; Tue, 13 Apr 2010 04:14:21 -0700 (PDT) From: "Viagra Pharmacy #1" To: dnsext-archive@ietf.org Subject: To user dnsext-archive: 70% prices slashing MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100413111421.85A4D28C124@core3.amsl.com> Date: Tue, 13 Apr 2010 04:14:21 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Website of the store on-line

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Qky. All rights reserved.
From dnsext-archive@lists.ietf.org Tue Apr 13 04:15:22 2010 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 7CCDF28C1CF for ; Tue, 13 Apr 2010 04:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -42.727 X-Spam-Level: X-Spam-Status: No, score=-42.727 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URI_HEX=0.368, 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 9keErRMn+c4G for ; Tue, 13 Apr 2010 04:15:16 -0700 (PDT) Received: from 189.27.164.155.dynamic.adsl.gvt.net.br (189.27.164.155.dynamic.adsl.gvt.net.br [189.27.164.155]) by core3.amsl.com (Postfix) with ESMTP id 5AF0B3A683B for ; Tue, 13 Apr 2010 04:14:37 -0700 (PDT) From: "Viagra Pharmacy #1" To: dnsext-archive@lists.ietf.org Subject: To user dnsext-archive: 70% prices slashing MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100413111437.5AF0B3A683B@core3.amsl.com> Date: Tue, 13 Apr 2010 04:14:37 -0700 (PDT) Newsletter
Can't see everything? Visit online version here.

Website of the store on-line

About Us | Unsubscribe | Privacy Policy | Terms of Use

Copyright © 1998-2009 Opqxyjde. All rights reserved.
From entmib-archive@lists.ietf.org Tue Apr 13 06:17:26 2010 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 CA6133A6817 for ; Tue, 13 Apr 2010 06:17:26 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 13 Apr 2010 06:17:23 -0700 (PDT) Received: from advcom.it (unknown [124.123.74.69]) by core3.amsl.com (Postfix) with SMTP id AE0D23A68E7 for ; Tue, 13 Apr 2010 06:17:18 -0700 (PDT) From: Approved VIAGRA® Store Subject: Your Future Order with 73% off retail To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100413131719.AE0D23A68E7@core3.amsl.com> Date: Tue, 13 Apr 2010 06:17:18 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 78047 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Tue Apr 13 07:02:34 2010 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 6287228C0FA; Tue, 13 Apr 2010 07:02:34 -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 657cGXPPbFEr; Tue, 13 Apr 2010 07:02:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0D1413A6B16; Tue, 13 Apr 2010 07:02:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1gak-000LMf-GG for namedroppers-data0@psg.com; Tue, 13 Apr 2010 13:55:50 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1gag-000LME-ES for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 13:55:48 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3DDtiVB044736 for ; Tue, 13 Apr 2010 09:55:44 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id o3DDtiff044735 for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 09:55:44 -0400 (EDT) (envelope-from namedroppers) Received: from [140.186.190.103] (helo=haybaler.sackheads.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1fNG-0007uz-38 for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 12:37:50 +0000 Received: from localhost (localhost.sackheads.org [127.0.0.1]) by haybaler.sackheads.org (Postfix) with ESMTP id 508912893A; Tue, 13 Apr 2010 08:37:47 -0400 (EDT) Authentication-Results: haybaler.sackheads.org; domainkeys=pass (testing) header.from=john@sackheads.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1271162267; bh=WVEi/FcNQUGFdrhgRCcdMEkTdiMPjFn8VxAPrSCpmBU=; h=References:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:Cc; b=X93oXd9jjbkEcAhWS4A1uice8l+ElrxPkRVPLrqEYXRdfpXgCRdOKGE/9ILuJMJd2 SxukinLz/xIj0ohET/5ks9I9ZE8GoXJRo0VeJfBJwwpz7RQxMZ6wkzzUgrRGEYLJef fjqahPrPJqV9h8uQrqsgQsYU1YBSv5Wz/h8Sj6Eo= Received: from haybaler.sackheads.org ([127.0.0.1]) by localhost (haybaler.sackheads.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trYiNvCq93PV; Tue, 13 Apr 2010 08:37:47 -0400 (EDT) Received: by haybaler.sackheads.org (Postfix, from userid 65534) id A1EA328896; Tue, 13 Apr 2010 08:37:46 -0400 (EDT) Received: from [10.18.111.141] (mobile-166-137-137-186.mycingular.net [166.137.137.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: john@sackheads.org) by haybaler.sackheads.org (Postfix) with ESMTP id 053E728860; Tue, 13 Apr 2010 08:37:43 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=haybaler; d=sackheads.org; c=nofws; q=dns; h=dkim-signature:references:message-id:from:to:in-reply-to: content-type:content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=bdBsA3t/MXZNcCqI946AL1vp73dHsWHDUpbpOlYo9u0AWy8Uua/M7MQ0ujuyPon5W B5o1gMcMw4ABE7Eg9LrhTzEgCvWEZAS/XQcZ0OiABIIZ1tQesvkLy0MOQMkVdLxsmK4 To5lfYrFO/VyILIUktE21X+YlLis7KZvc2ROUnE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1271162266; bh=WVEi/FcNQUGFdrhgRCcdMEkTdiMPjFn8VxAPrSCpmBU=; h=References:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:Cc; b=ofrAuMAI6afr9JUWujZVgtN4JNM6JMpU2QY/Es4kAA2Vq8m1yKvZzfDvIHuwC7fva AYpoAQ5KhZoK1xX4CGDzndgR0DH3VIvk4NsXlg4n5eLDncKkkBxo7LVRTOBsTkNrXV NhwyPOGbp01I51hSv7FVPurFdOg7/hNa35Co4ysw= References: <4BB3E324.2050207@isc.org> <42864.1270583728@nsa.vix.com> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> <7879.1271101167@nsa.vix.com> Message-Id: <239F54D6-3487-4CB7-96E8-CA52FA76B63E@sackheads.org> From: John Payne To: Paul Vixie In-Reply-To: <7879.1271101167@nsa.vix.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Subject: Re: [dnsext] edns-client-ip privacy rat-hole Date: Tue, 13 Apr 2010 08:37:15 -0400 Cc: namedroppers WG X-Scanned-By: MIMEDefang 2.67 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 Apr 12, 2010, at 3:39 PM, Paul Vixie wrote: > DNS basically works today, but not without a lot of effort by > implementors > and operators of infrastructure. making it more complicated and less > predictable in order to support a single application (web browsing) > is not > something we should do mindlessly or incrementally or lightly. CDNs do a lot more than web stuff these days. "Stupid DNS tricks" have use cases (some more general than others) in almost every application that uses DNS (and some that didn't before the application users wanted to make use of CDNs). Where are the naysayers expecting this option to be deployed? I suspect you have a different answer to those for it. I'm deliberately not taking a position on this draft, although it might seem that I am because the only corrections I have made are to comments from the naysayers. ISPs have little incentive to enable this on their recursors - it will increase their complexity and cache misses whereas the client location granularity is "good enough" without this. Lying-port53-theiving hotels are already doing whatever they want with your dns stream. This makes no difference to them. I would have to imagine that Google public dns is using the client IP to construct answers for Google server names. Isn't it only fair that other recursive operators and other authorative operators get a chance to play in a standardized field? I'm less certain about whether authorative operators will want to enable this option as it does enable a potential information leak on their side., and cherry picking recursive operators to enable this for adds additional complexity and non-technical pain. From owner-namedroppers@ops.ietf.org Tue Apr 13 07:20:47 2010 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 E1F9C3A6A35; Tue, 13 Apr 2010 07:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=0.075, 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 zfpd4qYF07k2; Tue, 13 Apr 2010 07:20:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C79333A6903; Tue, 13 Apr 2010 07:19:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1guC-000P43-9k for namedroppers-data0@psg.com; Tue, 13 Apr 2010 14:15:56 +0000 Received: from [209.85.210.171] (helo=mail-yx0-f171.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1guA-000P3l-0P for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 14:15:54 +0000 Received: by yxe1 with SMTP id 1so3215461yxe.33 for ; Tue, 13 Apr 2010 07:15:53 -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:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uMh0P9mbMboeZcWpUbt8h86FCdThIB20Gb/GsRrnwPo=; b=O7l5LaXmcb/cWqU7tppCZpN2s/8mJtf0I479aDGGILsk7p+zx1/HEXxrlbZPpsGGk3 Y9GGTVXBprcLANK7M/TJrW2UAh775Rnwxu6UwoIqwun8Ft7Zb4iwgkqJwKb+xjoemKoq 8NTbMLWZi3m4WoXJHC0pFYLzw/4xVV6vFpqf8= 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 :cc:content-type:content-transfer-encoding; b=g+vI3o41byT3KeZkKSTfDDsA8mcaTUQYeCxl5htv/o2UXX1tm32mfKHcsrhkoQmuQf XQWCs6x1aCIZmSh5TqJ+9KToL9owr+Fzbm3b35cdpVVx2JhQqRhroQONJGk+bod3LNtV CsSUXOc/+YXu35LLOZObjO7Ktw5U0Nu34Y+jU= MIME-Version: 1.0 Received: by 10.100.91.5 with HTTP; Tue, 13 Apr 2010 07:15:48 -0700 (PDT) In-Reply-To: <1266.1271092587@nsa.vix.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <20100412164403.GR11706@shinkuro.com> <1266.1271092587@nsa.vix.com> Date: Tue, 13 Apr 2010 11:15:48 -0300 Received: by 10.101.211.25 with SMTP id n25mr10947334anq.169.1271168150109; Tue, 13 Apr 2010 07:15:50 -0700 (PDT) Message-ID: Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work From: Brian Dickson To: Paul Vixie Cc: 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: In addition to the below comments from Paul, there are other reasons to consider adding to the WG charter, and additional ways in which some or all of the problems can be resolved. I am not convinced that limiting the proposals here to already-written drafts, or to a specific number of new drafts (e.g. 1 or 2), is strictly necessary. If there is a third way, which has enough different about it to differentiate it from the other methods, and presuming the three ways are independent (neither inter-dependent nor mutually exclusive in any aspect), all three ways should be considered. The additional reason to consider adding to the WG charter is: - DNSSEC validation of "alias" zones through any of the aliases -- this would change some of the validation rules, but the benefit would be the ability to secure zones whose parent(s) are not currently signed -- e.g. if foo.example.com is AKA foo.example.cctld1, and com and example.com are signed, but cctld1 is not, then having DNSSEC validation via aliases would mean that it would be possible for foo to be validated regardless of which name it was known by (example.com or example.cctld1). The third way is to merely support DNSSEC validation using modified rules, and to handle the aliases through parallel delegations (NS and DS), with a much smaller subset of DNSKEYs (and signers) than the full set of aliases, including the possibility of just one signer (parent alias). With this way, the parallelism itself can be handed by metadata on the authority server(s). The linkage between the zone identity and zone contents is built by the authority server from its metadata. The linkages can be relatively trivially made N:1 instead of 1:1 (name to zone-content), on most implementations. And the implementations are then free to do the needed stuff for handling zone updates/transfers based on the multiplicity of zones. Changing metadata and in-server behavior does not change anything on the wire, which is why it is mostly non-WG stuff, other than describing to implementers what the big idea is - suitable for putting in a nice Appendix to a small ID on the DNSSEC validation rule changes. I'd be happy to write this up in a draft, if there is WG interest in the proposal, and thus would be interested in hearing from folks willing to review it. Brian On Mon, Apr 12, 2010 at 2:16 PM, Paul Vixie wrote: >> Date: Mon, 12 Apr 2010 12:44:04 -0400 >> From: Andrew Sullivan >> >> That is true, but I think I owe the WG a clearer version of the >> argument against additional work. =A0So here it is. >> >> ... >> >> This is my reading of the discussion and arguments so far. =A0If I've >> missed a point someone made, I apologise. =A0(It would be good to hit me >> with a clue-stick.) > > i think i disagree with your conclusion on the following basi. > > basis 1. aliasing has potential customers other than icann. > basis 2. icann has asked for some kind of standardized automation. > basis 3. dname is crippled by not affecting its ownername. > basis 4. cname is crippled by not affecting its children. > basis 5. parallel delegations would benefit from standardized automation. > > on the basis of #3 and #4 above, i think that BNAME should be adopted. > > on the basis of #5 above, i think that SHADOW should be adopted. > > on the basis of #1 and #2 above, i don't think that icann's Q&A document > takes any of this off the table. > > i am willing to do authorship and editorial work to support BNAME & SHADO= W, > assuming that others here are willing to review the drafts. =A0if all tha= t is > in place, then we should proceed with drafting. > > From owner-namedroppers@ops.ietf.org Tue Apr 13 07:34:55 2010 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 C00993A69FD; Tue, 13 Apr 2010 07:34: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 2+Jt-BNJw61b; Tue, 13 Apr 2010 07:34:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A35453A6973; Tue, 13 Apr 2010 07:34:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1h4x-0001Bb-SI for namedroppers-data0@psg.com; Tue, 13 Apr 2010 14:27:03 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1h4s-0001Ap-NM for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 14:26:58 +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 10772E8178; Tue, 13 Apr 2010 14:26:57 +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 o3DEQtf0031974; Wed, 14 Apr 2010 00:26:55 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004131426.o3DEQtf0031974@drugs.dv.isc.org> To: "George Barwood" Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <20100412164403.GR11706@shinkuro.com> <1266.1271092587@nsa.vix.com> <19005DAF043444A092106B6CDB1EBA25@localhost> <201004130002.o3D024Os010600@drugs.dv.isc.org> <8DA2E211CC484529B2BC222063C45A03@localhost> <201004131052.o3DAqTtv026844@drugs.dv.isc.org> <1A3CBDCF9402473A930431B4880CD5EC@localhost> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-reply-to: Your message of "Tue, 13 Apr 2010 15:13:33 +0100." <1A3CBDCF9402473A930431B4880CD5EC@localhost> Date: Wed, 14 Apr 2010 00:26:55 +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 <1A3CBDCF9402473A930431B4880CD5EC@localhost>, "George Barwood" write s: > > Apply the rules above and a validating resolver that doesn't > > understand BNAME will always treat the zone containing the BNAME > > as insecure as it won't understand the algorithm. A BNAME aware > > resolver will get the records and any relevent signatures provided > > there is a BNAME aware path between it and the authoritative server. > > So when a BNAME is placed in the root zone for .CN, the previously secure > root zone becomes insecure for all resolvers that have not been updated. Yes. > I'm not sure that is better than simply having validation failures on names > that depend on BNAME. It's much better than having lookups fail because of validation failures. > Still, maybe this is getting too far ahead. I'm stopping here. By the time BNAME is added to the root zone there will be multi-vendor support for it. It won't be deployed in a vacum. 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 Tue Apr 13 07:57:55 2010 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 5022328C22D; Tue, 13 Apr 2010 07:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.791 X-Spam-Level: X-Spam-Status: No, score=-4.791 tagged_above=-999 required=5 tests=[AWL=0.257, 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 dIz-kPGu+2+Y; Tue, 13 Apr 2010 07:57:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 544F228C185; Tue, 13 Apr 2010 07:57:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1hUV-0005z0-2B for namedroppers-data0@psg.com; Tue, 13 Apr 2010 14:53:27 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1hUS-0005ya-Ny for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 14:53:24 +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 o3DEr7oZ017257; Tue, 13 Apr 2010 07:53:07 -0700 (PDT) References: <4BB3E324.2050207@isc.org> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> <7879.1271101167@nsa.vix.com> <12058.1271107096@nsa.vix.com> <3D98D6E5-C81F-46DC-B527-4123DCC998C6@icsi.berkeley.edu> <14093.1271109993@nsa.vix.com> In-Reply-To: <14093.1271109993@nsa.vix.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <29BE9A8C-E000-41DE-8431-899FE985A459@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , IETF DNSEXT WG From: Nicholas Weaver Subject: Re: [dnsext] edns-client-ip privacy rat-hole Date: Tue, 13 Apr 2010 07:53:07 -0700 To: Paul Vixie X-Mailer: Apple Mail (2.1078) 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 Apr 12, 2010, at 3:06 PM, Paul Vixie wrote: >=20 > that covers the caching intermediary, with the understanding that the = RRSIG > has to be treated as having scope. what about a mobile client whose = scope > can change within a TTL and signature validity period? are you = assuming > that mobile clients will always set edns-client-ip and will scope any > rrsets they cache, along with any signatures? if so then i wonder = what > happens if the client doesn't set edns-client-ip and its caching = intermediary > changes as a result of mobility. are you expecting the (unscoped) = underlying > rrset and its (therefore also unscoped) covering RRSIG to expire in = tandem? Who cares? =20 edns-client-ip doesn't affect the correctness of the validation: the = whole point of the CDN tricks is the set of valid answers is VASTLY = larger than could be returned in a DNS record, and the authority makes a = decision as to which subset to give as an answer to a particular = request. In the DNSSEC world, it happens to have a matching RRSIG for = that subset. But the "wrong" node is still a valid answer, and will still validate, = its just a less efficient answer. And mobile clients ALWAYS have this problem with CDN'ed tricks: a less = efficient IP when they move, and this doesn't change it, and thus the = reason why many CDNs use very short TTLs (probably too short actually) And its actually not THAT bad a problem: the #1 key for CDN being good = is physical geography: getting a server in Oakland is vastly better than = one in LA or Seattle. The #2 is then network provider, but that matters = less as the CDN nodes may be in the ISPs, but they are in the = close-to-the-exchange-points side of the ISPs. WHat are the odds that a client moves >100 miles before the timeout = expires. As for setting edns-client-ip, there really is no point in the client = actually setting it in almost all cases: it is the resolver which sets = it based on the IP the request came from. The only reason a client = should set it is because it is a) Sending DNS through a different proxy than the rest of the traffic = (which is a Bad Thing to do anyway, but edns-client-ip supports) b) The client is paranoid and wants to disable this feature altogether c) An intermediate cache that is not on the network path for the rest = of the traffic, and is not a recursive resolver, wants to set it when = forwarding to the actual recursive resolver. (a very rare case) Apart from these exceptions, clients should neither know nor care about = this EDNS option.= From owner-namedroppers@ops.ietf.org Tue Apr 13 08:16:15 2010 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 0D5D53A6A1A; Tue, 13 Apr 2010 08:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.133 X-Spam-Level: X-Spam-Status: No, score=0.133 tagged_above=-999 required=5 tests=[AWL=0.328, 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 T0vDAk9u7UZm; Tue, 13 Apr 2010 08:16:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECE223A6807; Tue, 13 Apr 2010 08:16:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1hls-0008O4-4m for namedroppers-data0@psg.com; Tue, 13 Apr 2010 15:11:24 +0000 Received: from [144.254.224.141] (helo=ams-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1hlp-0008Nj-S4 for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 15:11:22 +0000 Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: PGP.sig : 186 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwBAGImxEuQ/uCWe2dsb2JhbACbSBUBAQsLIgYcowKaF4UNBA X-IronPort-AV: E=Sophos;i="4.52,197,1270425600"; d="sig'?scan'208";a="5526589" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 13 Apr 2010 14:35:33 +0000 Received: from [192.168.10.158] (dhcp-10-61-99-98.cisco.com [10.61.99.98]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3DFBJKi004017; Tue, 13 Apr 2010 15:11:19 GMT Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-306-806505572" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <1266.1271092587@nsa.vix.com> Date: Tue, 13 Apr 2010 17:11:21 +0200 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <82B643F2-F26F-4D7F-80EB-A2F6A6463F53@cisco.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <20100412164403.GR11706@shinkuro.com> <1266.1271092587@nsa.vix.com> To: Paul Vixie X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1078) 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 an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-306-806505572 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 12 apr 2010, at 19.16, Paul Vixie wrote: > i am willing to do authorship and editorial work to support BNAME & SHADOW, > assuming that others here are willing to review the drafts. if all that is > in place, then we should proceed with drafting. I am signing up to this. Patrik --Apple-Mail-306-806505572 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iD8DBQFLxImZvHlR2X0luNwRAsXQAKC7lWG70qq1avXE2RbC7d0SdWDrjwCfT1Pu mWtdLF7V22SU8lWJCVcNzbI= =b/WH -----END PGP SIGNATURE----- --Apple-Mail-306-806505572-- From owner-namedroppers@ops.ietf.org Tue Apr 13 08:51:21 2010 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 750883A6895; Tue, 13 Apr 2010 08:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 ahSUDR5ekVUT; Tue, 13 Apr 2010 08:51:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F70D3A67F8; Tue, 13 Apr 2010 08:51:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1iKg-000EGe-Rf for namedroppers-data0@psg.com; Tue, 13 Apr 2010 15:47:22 +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.71 (FreeBSD)) (envelope-from ) id 1O1iKe-000EGL-GW for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 15:47:20 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id EF111A1D59 for ; Tue, 13 Apr 2010 15:47:19 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] edns-client-ip privacy rat-hole In-Reply-To: Your message of "Tue, 13 Apr 2010 07:53:07 MST." <29BE9A8C-E000-41DE-8431-899FE985A459@icsi.berkeley.edu> References: <4BB3E324.2050207@isc.org> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> <7879.1271101167@nsa.vix.com> <12058.1271107096@nsa.vix.com> <3D98D6E5-C81F-46DC-B527-4123DCC998C6@icsi.berkeley.edu> <14093.1271109993@nsa.vix.com> <29BE9A8C-E000-41DE-8431-899FE985A459@icsi.berkeley.edu> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Tue, 13 Apr 2010 15:47:19 +0000 Message-ID: <56755.1271173639@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: Nicholas Weaver > Date: Tue, 13 Apr 2010 07:53:07 -0700 > ... > What are the odds that a client moves >100 miles before the timeout expires. non-negligible. anyway, if this means clients have to know how to recognize this or else face unexpected/unexplainable errors, then the document should say that. From owner-namedroppers@ops.ietf.org Tue Apr 13 08:51:28 2010 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 76FA83A6895; Tue, 13 Apr 2010 08:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.679 X-Spam-Level: X-Spam-Status: No, score=0.679 tagged_above=-999 required=5 tests=[AWL=0.816, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=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 P2vKPzjp6qZE; Tue, 13 Apr 2010 08:51:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 921743A67F8; Tue, 13 Apr 2010 08:51:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1iIr-000E1Y-Sy for namedroppers-data0@psg.com; Tue, 13 Apr 2010 15:45:29 +0000 Received: from [65.99.1.130] (helo=abenaki.wabanaki.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1iIp-000E0B-4r for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 15:45:27 +0000 Received: from limpet.local (cpe-67-244-32-202.twcny.res.rr.com [67.244.32.202]) by abenaki.wabanaki.net (8.14.4/8.14.3) with ESMTP id o3DFeGrB009938; Tue, 13 Apr 2010 11:40:17 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4BC4917E.1070103@abenaki.wabanaki.net> Date: Tue, 13 Apr 2010 11:45:02 -0400 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <20100412164403.GR11706@shinkuro.com> <1266.1271092587@nsa.vix.com> <82B643F2-F26F-4D7F-80EB-A2F6A6463F53@cisco.com> In-Reply-To: <82B643F2-F26F-4D7F-80EB-A2F6A6463F53@cisco.com> 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 4/13/10 11:11 AM, Patrik F=E4ltstr=F6m wrote: >=20 > On 12 apr 2010, at 19.16, Paul Vixie wrote: >=20 >> i am willing to do authorship and editorial work to support BNAME & SH= ADOW, >> assuming that others here are willing to review the drafts. if all th= at is >> in place, then we should proceed with drafting. >=20 > I am signing up to this. >=20 > Patrik >=20 Ditto. From owner-namedroppers@ops.ietf.org Tue Apr 13 09:04:17 2010 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 E45533A697D; Tue, 13 Apr 2010 09:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.889 X-Spam-Level: * X-Spam-Status: No, score=1.889 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 IbdA8bBXvF3W; Tue, 13 Apr 2010 09:04:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 68E3A28C214; Tue, 13 Apr 2010 09:03:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1iVP-000FuF-St for namedroppers-data0@psg.com; Tue, 13 Apr 2010 15:58:27 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1iVM-000Ftp-VH for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 15:58:25 +0000 Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4F5AD1ECB533 for ; Tue, 13 Apr 2010 15:58:22 +0000 (UTC) Date: Tue, 13 Apr 2010 11:58:20 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Re: Draft minutes from IETF 77 Message-ID: <20100413155820.GB14332@shinkuro.com> References: <20100405173433.GE55035@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100405173433.GE55035@shinkuro.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: Dear colleagues, As announced, I uploaded the minutes. Best regards, Andrew On Mon, Apr 05, 2010 at 01:34:33PM -0400, Andrew Sullivan wrote: > Dear colleagues, > > Please review the attached minutes for accuracy. Send corrections to > me or the list. > > Thanks to Matt for getting these to us so quickly (immediately after > the session!), and apologies to all for not having posted them sooner. > > If I hear no objection, I shall send these minutes to the Secretariat > a week hence (2010-04-12). > > Best, > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > > > Minutes of the DNS Extensions Working Group meeting at IETF 77 > > Prepared by Matthew Pounsett > > dnsext - 2010/03/23 13:00 PDT > > Name Equivalence / Aliases Issue > ================================ > > Constraints Changes > -------------------- > NEW: Solutions must work with intermediary iterators and forwarders > > NEW: Delegation hierarchy needs to be taken into account. Records > near the root of the tree can't make definitive statements about what > is happening further from the root. > > CHANGE: Perhaps instead of "may require upgrades of client resolvers" > perhaps "may require upgrades of client applications" > > > Questions To Answer > ------------------- > 1) Do we require UPDATEs to modify nodes that are "the same"? > 1a) Do we require immediate updates of all nodes, or can we allow > for some delay required by copy operations? > 1b) By "immediate" do we mean that all authoritative servers need > to updated instantly? > 1c) By "immediate" do we mean that caches need to be updated > instantly too? (out of scope) > > 2) Is it okay that one of the names pointing to a node is an alias? > Do we need to know what all of the aliases are? > > 3) If we do things way X, what breaks for the community? What about > way Y? Possibly a more tractable question than finding all possible > use cases. > > 4) Before trying to get a complete taxonomy, should we find out how > the community feels about the hard constraints? > > > draft-ietf-dnsext-dnssec-bis-updates-10 > ======================================= > > - CD bit handling logic needs to be sorted out on mailing list > - Changes due to "rollover and die"? Deferred until after rollover > discussion > - Time to WGLC and publish? Unanswered > > > draft-dempsky-dnscurve-01 > ========================= > > Comments > -------- > - client privacy is an interesting problem solved by this technology > and by no other > - point to point encryption may cause problems with middleboxes > blocking DNS traffic they don't recognize > - integrity not encryption should be considered to solve the middlebox > problem > - should consider a better researched curve > - Diffie-Hellman results should be cached > - should answer the question "What problem are we trying to solve?" > before choosing to adopt this work and start engineering > > Sense of the room > ----------------- > Who has read this draft? enough > How many people support adoption of this document? quiet > How many people are opposed to adoption of this draft? quiet > How many people have not made up their minds? more > significant > > Taking this to the mailing list for followup. > > > Paul Vixie - 0x20 > ================= > > Should this progress with the intention of amending 1035? > support, few opposed > > Should the document be spit into Standards Track and Informational? > Unanswered > > > > Roll over and die > ================= > Should some changed be incorporated in draft-ietf-dnsext-dnssec-bis- > updates? > Additional discussion deferred to the list. > > > > > > > > > From owner-namedroppers@ops.ietf.org Tue Apr 13 09:21:44 2010 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 436913A6801; Tue, 13 Apr 2010 09:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.812 X-Spam-Level: X-Spam-Status: No, score=-4.812 tagged_above=-999 required=5 tests=[AWL=0.236, 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 4eNyTgFV-aKh; Tue, 13 Apr 2010 09:21:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1F73A3A6899; Tue, 13 Apr 2010 09:21:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1imu-000JAJ-Fa for namedroppers-data0@psg.com; Tue, 13 Apr 2010 16:16:32 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1imr-000JA1-N9 for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 16:16:29 +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 o3DGGDmh028662; Tue, 13 Apr 2010 09:16:13 -0700 (PDT) References: <4BB3E324.2050207@isc.org> <6A27525DB402441D939E3A92E18388EE@localhost> <1468.1271092699@nsa.vix.com> <5534.1271098125@nsa.vix.com> <7879.1271101167@nsa.vix.com> <12058.1271107096@nsa.vix.com> <3D98D6E5-C81F-46DC-B527-4123DCC998C6@icsi.berkeley.edu> <14093.1271109993@nsa.vix.com> <29BE9A8C-E000-41DE-8431-899FE985A459@icsi.berkeley.edu> <56755.1271173639@nsa.vix.com> In-Reply-To: <56755.1271173639@nsa.vix.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <02742443-7AC3-4E5F-A862-E038F16F6A5A@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , IETF DNSEXT WG From: Nicholas Weaver Subject: Re: [dnsext] edns-client-ip privacy rat-hole Date: Tue, 13 Apr 2010 09:16:13 -0700 To: Paul Vixie X-Mailer: Apple Mail (2.1078) 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 Apr 13, 2010, at 8:47 AM, Paul Vixie wrote: >> From: Nicholas Weaver >> Date: Tue, 13 Apr 2010 07:53:07 -0700 >> ... >> What are the odds that a client moves >100 miles before the timeout = expires. >=20 > non-negligible. >=20 > anyway, if this means clients have to know how to recognize this or = else face > unexpected/unexplainable errors, then the document should say that. But as I said, the ONLY thing the client sees as a result of moving is = they still use a "sub par" (20ms higher latency) node. So the client = doesn't actually face an error, just mildly degraded performance. From owner-namedroppers@ops.ietf.org Tue Apr 13 09:45:40 2010 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 628373A69EF; Tue, 13 Apr 2010 09:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.155 X-Spam-Level: X-Spam-Status: No, score=-0.155 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_20=-0.74, SARE_LWSHORTT=1.24] 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 8fogsxYn8W9M; Tue, 13 Apr 2010 09:45:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6DA223A6944; Tue, 13 Apr 2010 09:45:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1j8E-000Mjh-0q for namedroppers-data0@psg.com; Tue, 13 Apr 2010 16:38:34 +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.71 (FreeBSD)) (envelope-from ) id 1O1j8B-000MjQ-Gw for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 16:38:31 +0000 Received: from [64.235.108.48] (helo=[192.168.182.3]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1j88-000DQs-GZ; Tue, 13 Apr 2010 16:38:29 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Subject: Fwd: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work From: Joe Abley Date: Tue, 13 Apr 2010 12:38:27 -0400 Cc: Tina Dam Content-Transfer-Encoding: quoted-printable Message-Id: <0D532A88-CB2B-41F1-91EC-83C0639A1EBB@hopcount.ca> References: <05B243F724B2284986522B6ACD0504D7D341EB4B9A@EXVPMBX100-1.exc.icann.org> To: namedroppers WG X-Mailer: Apple Mail (2.1078) X-SA-Exim-Connect-IP: 64.235.108.48 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false 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, For some reason Tina is having problems sending mail to this list. While = those problems are being ironed out, here's a forwarded message, which = contains some clarifying points about ICANN's sync idn work. [I might suggest being sure to include Tina on the cc line when doing = your group reply, to make sure she gets it directly.] Joe Begin forwarded message: > From: Tina Dam > Date: 13 April 2010 12:33:58 EDT > To: Joe Abley > Subject: FW: [dnsext] ICANN's "synchronized domains" and the DNSEXT = alias maybe-work >=20 > Hi Joe, please forward to the namedroppers list >=20 > Tina >=20 > -----Original Message----- > From: Tina Dam=20 > Sent: Monday, April 12, 2010 8:56 PM > To: 'namedroppers@ops.ietf.org' > Subject: RE: [dnsext] ICANN's "synchronized domains" and the DNSEXT = alias maybe-work >=20 > Trying that again. For some reason my first message got truncated. >=20 > --- > Hi all, I am sorry for joining the discussion late. I hope it is = useful to re-state some things related to ICANN's plan for Synchronized = IDN ccTLDs. I understand that this has been a confusion subject and I = apologies for that. >=20 > First of all, the process is very limited in the sense that it solely = allows for a few IDN ccTLDs. The reason behind this is that there is, as = you have pointed out, no solution that from a technical/DNS perspective = guarantees "synchronization" throughout all levels in a tree. So, until = such solution is in place ICANN is proposing to allow a small subset of = "variant/aliasing" IDN ccTLDs for introduction, where experience is = available, and with a set of procedural requirements and reporting = functions. >=20 > So the aim with the Synchronized Process as it is proposed today, it = to allow for a few IDN ccTLDs that fulfill certain criteria (for example = that the labels are not confusingly similar, visually) and under = procedural requirements (such as ensuring that a registrant get his = domain name under both/all synchronized IDN ccTLDs). This means that we = are not asking the IETF or the DNSEXT to solve a technical issue or come = up with a technical solution for this - in the very short term.=20 >=20 > You may however still be interested in the subject which is why some = of my colleagues have mentioned the public comment forum and the = webinars. That is to state your opinion based on your expertise, which = absolutely is very welcomed. >=20 > For the longer term, the intention is conduct some analysis and tests = to find a solution (possible technical) to (i) better address/manage = synchronized IDN ccTLDs and (ii) find a solution for all "types of = variant TLDs". >=20 > As you will see in the blog post from yesterday ICANN is looking to = the technical community for advice on such long-term solution. Some work = is necessary to be developed and specified before the actually technical = work can commence. For example we need to be specific about what we mean = when we say variant/sameness/aliasing and so forth (hence the " 's in = this email), and more, see the minimum list in the blog post. In fact, = in order to get a full overview of what is needed we will be looking for = advice from you. >=20 > I hope this clarifies a bit what we are trying to accomplish and what = help we need. I realize of course that in order for the DNSEXT to work = and help out you need a detailed description of what we are trying to = accomplish, in the long term.=20 >=20 > If this is not clear enough, please let me know, either via this list, = directly, or perhaps in the upcoming webinars. >=20 > Tina >=20 >=20 > Tina Dam > Sr. Director, IDNs > ICANN >=20 >=20 >=20 > PS. Links to some of the material I mentioned: >=20 > Proposed Implementation Plan for Synchronized IDN ccTLDs: = http://icann.org/en/announcements/announcement-22mar10-en.htm=20 >=20 > Public comment forum: = http://icann.org/en/public-comment/public-comment-201004-en.htm#synch=20 >=20 > Questions and answers for synchrnoized IDN cTLDs: = http://icann.org/en/topics/idn/fast-track/synchronized-idn-cctlds-faq-en.h= tm=20 >=20 > Webinars: = http://icann.org/en/announcements/announcement-2-08apr10-en.htm=20 >=20 > Blog post: = http://blog.icann.org/2010/04/update-about-synchronized-idn-cctlds/=20 >=20 >=20 From owner-namedroppers@ops.ietf.org Tue Apr 13 09:55:23 2010 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 DA5C53A6A5B; Tue, 13 Apr 2010 09:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 uKK9kXA4kDar; Tue, 13 Apr 2010 09:55:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C3F953A6A04; Tue, 13 Apr 2010 09:55:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1jHd-000NpZ-L8 for namedroppers-data0@psg.com; Tue, 13 Apr 2010 16:48:17 +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.71 (FreeBSD)) (envelope-from ) id 1O1jHb-000Np9-Db for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 16:48:15 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 06CB7A1D70 for ; Tue, 13 Apr 2010 16:48:15 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-Reply-To: Your message of "Tue, 13 Apr 2010 12:17:04 +0300." <19396.13968.881313.199510@guava.gson.org> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <20100412164403.GR11706@shinkuro.com> <1266.1271092587@nsa.vix.com> <19005DAF043444A092106B6CDB1EBA25@localhost> <6613.1271099466@nsa.vix.com> <12708.1271108098@nsa.vix.com> <19396.13968.881313.199510@guava.gson.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Tue, 13 Apr 2010 16:48:14 +0000 Message-ID: <59888.1271177294@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: Tue, 13 Apr 2010 12:17:04 +0300 > From: Andreas Gustafsson > > Paul Vixie wrote: > > ..., i've been cautious in my SHADOW work to only speak in terms of > > zone transfers, and not in master file format or directives there ... > > I don't think you have, because draft-vixie-dnsext-dnsshadow-00 makes > a distinction between "relative" and "fully qualified" names, and that > distinction only exists in master files and not in zone transfers. > Since names in zone transfers are encoded in the DNS wire format, they > are always effectively fully qualified. agreed. this is an open issue, and i spoke (quoted above) too glibly. > In particular, the technique describe in the last sentence of the > following paragraph can't be applied to zone transfer data: > ... see also: 4. Open Issues 4.1. Using a different default origin and then not touching fully- qualified names is weak. It plays especially poorly with fully dynamic zone content or database back ends. We either need to tail- replace the Amber apex with each Shadow apex, or we need to add new signalling somehow. From owner-namedroppers@ops.ietf.org Tue Apr 13 11:51:13 2010 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 0C0AB3A6A89; Tue, 13 Apr 2010 11:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.403 X-Spam-Level: X-Spam-Status: No, score=-102.403 tagged_above=-999 required=5 tests=[AWL=0.197, 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 WSHfupLJEo8m; Tue, 13 Apr 2010 11:51:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E12373A68C8; Tue, 13 Apr 2010 11:51:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1l6b-000GjP-9l for namedroppers-data0@psg.com; Tue, 13 Apr 2010 18:45:01 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1l6Y-000Gio-QE for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 18:44:58 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 7088C3A68C8; Tue, 13 Apr 2010 11:45:02 -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-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100413184502.7088C3A68C8@core3.amsl.com> Date: Tue, 13 Apr 2010 11:45:02 -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-03.txt Pages : 10 Date : 2010-04-13 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 implemented, 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-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-13113510.I-D@ietf.org> --NextPart-- From owner-namedroppers@ops.ietf.org Tue Apr 13 11:51:14 2010 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 64B793A68C8; Tue, 13 Apr 2010 11:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.159 X-Spam-Level: X-Spam-Status: No, score=0.159 tagged_above=-999 required=5 tests=[AWL=1.208, 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 Ganvr5NGRWc2; Tue, 13 Apr 2010 11:51:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 998FC3A6A6C; Tue, 13 Apr 2010 11:51:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1l5W-000GW2-8I for namedroppers-data0@psg.com; Tue, 13 Apr 2010 18:43:54 +0000 Received: from [129.6.18.96] (helo=wsxghub1.nist.gov) by psg.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1l5T-000GVa-Qb for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 18:43:51 +0000 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 13 Apr 2010 14:43:49 -0400 From: "Rose, Scott W." To: namedroppers Date: Tue, 13 Apr 2010 14:43:48 -0400 Subject: [dnsext] new version of draft-registry-fixes submitted. Thread-Topic: new version of draft-registry-fixes submitted. Thread-Index: AcrbOUDIQqXTSvYrMUKGFrLxiq3IHw== 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 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: FYI: Submitted the latest version of draft-registry-fixes since WGLC technically ended, but needs and update. Only one change from the -02 version: The addition of GOST-ECC to the table, but that's it. Changes from -01: http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00064.html 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 Apr 13 12:13:05 2010 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 A6D1228C0D6; Tue, 13 Apr 2010 12:13:05 -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 l0GNn-JXhZnv; Tue, 13 Apr 2010 12:13:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D84383A67D2; Tue, 13 Apr 2010 12:13:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1lTi-000LTS-Ju for namedroppers-data0@psg.com; Tue, 13 Apr 2010 19:08:54 +0000 Received: from [74.125.82.52] (helo=mail-ww0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1lTg-000LTE-BF for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 19:08:52 +0000 Received: by wwb39 with SMTP id 39so751963wwb.11 for ; Tue, 13 Apr 2010 12:08:51 -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 :from:date:received:message-id:subject:to:cc:content-type; bh=XMBeuh3TKD7+TMPRsI8CSf3WOAQSpQ4AzgwKjjWf3W4=; b=Duk//kIIvriQnoXCVnHIz44FSxy0BuK4etVOFbXlJC6TQdicZONl+h7lYFi8ciqHTG Z5Ee5payQ/KjqNINVciOAJIZcYA+YbdyMA58fKKTglSATtvvQDIRnZDULPRTK4jAcMkJ 2pkQqUrZXVCdW8ZeR/VeB1havrf3juNKEaddU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=lQlODArljPLyBRfVEyaqra9zsvV5co8FXhfjG3CmLLzDe4av+r39DDydL+jeX5SvKw y0t6Ixvu+72AlDXUZsdekaCxqNXo5YUjaTOkSZnuoxTpzjRTuAZ5qeAuWZkzjIGMHl2Z GRLAGnSL3uuKqr98xuDLlrGW5Wr8htGZPtcuw= MIME-Version: 1.0 Received: by 10.216.48.208 with HTTP; Tue, 13 Apr 2010 12:08:29 -0700 (PDT) In-Reply-To: <00840DF11F8D4B13A9472C6CC56234D1@localhost> References: <6FA6F5C6827C49D59FBC91736FC4685B@localhost> <00840DF11F8D4B13A9472C6CC56234D1@localhost> From: bert hubert Date: Tue, 13 Apr 2010 21:08:29 +0200 Received: by 10.216.91.6 with SMTP id g6mr3579573wef.37.1271185730850; Tue, 13 Apr 2010 12:08:50 -0700 (PDT) Message-ID: Subject: Re: [dnsext] New defence to Kaminsky attack To: George Barwood 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: On Tue, Apr 13, 2010 at 6:11 PM, George Barwood wrote: > Correct. Rule 2 below specifies that this NS record is not accepted, > since it is not "strictly below the Bailiwick". That should work. Ok - but I think this breaks down when someone uses '123www.powerdns.com' to spoof the powerdns.com nameservers, in other words, a 'sibling attack'. This would deliver a SOA, but would still be a zone. Or am I wrong? Bert From owner-namedroppers@ops.ietf.org Tue Apr 13 12:25:41 2010 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 9A5423A68E5; Tue, 13 Apr 2010 12:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 pJMC3W3kb8pg; Tue, 13 Apr 2010 12:25:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 050943A6A7C; Tue, 13 Apr 2010 12:25:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1lfn-000NbH-LB for namedroppers-data0@psg.com; Tue, 13 Apr 2010 19:21:23 +0000 Received: from [74.125.149.211] (helo=na3sys009aog114.obsmtp.com) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1lfl-000Nao-F0 for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 19:21:21 +0000 Received: from source ([74.125.83.179]) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKS8TEMAvs5Q33C1x1LMH/LhrrIT3c8GaB@postini.com; Tue, 13 Apr 2010 12:21:21 PDT Received: by mail-pv0-f179.google.com with SMTP id 12so4296602pvg.24 for ; Tue, 13 Apr 2010 12:21:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.154.147 with HTTP; Tue, 13 Apr 2010 12:21:20 -0700 (PDT) In-Reply-To: <02742443-7AC3-4E5F-A862-E038F16F6A5A@icsi.berkeley.edu> References: <4BB3E324.2050207@isc.org> <7879.1271101167@nsa.vix.com> <12058.1271107096@nsa.vix.com> <3D98D6E5-C81F-46DC-B527-4123DCC998C6@icsi.berkeley.edu> <14093.1271109993@nsa.vix.com> <29BE9A8C-E000-41DE-8431-899FE985A459@icsi.berkeley.edu> <56755.1271173639@nsa.vix.com> <02742443-7AC3-4E5F-A862-E038F16F6A5A@icsi.berkeley.edu> Date: Tue, 13 Apr 2010 12:21:20 -0700 Received: by 10.115.112.22 with SMTP id p22mr6008814wam.53.1271186480285; Tue, 13 Apr 2010 12:21:20 -0700 (PDT) Message-ID: Subject: Re: [dnsext] edns-client-ip privacy rat-hole From: David Ulevitch To: Nicholas Weaver Cc: Paul Vixie , IETF DNSEXT WG 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 Tue, Apr 13, 2010 at 9:16 AM, Nicholas Weaver wrote: > > On Apr 13, 2010, at 8:47 AM, Paul Vixie wrote: > >>> From: Nicholas Weaver >>> Date: Tue, 13 Apr 2010 07:53:07 -0700 >>> ... >>> What are the odds that a client moves >100 miles before the timeout exp= ires. >> >> non-negligible. > > But as I said, the ONLY thing the client sees as a result of moving is th= ey still use a "sub par" (20ms higher latency) node. =A0So the client doesn= 't actually face an error, just mildly degraded performance. > We can be more precise in describing the impact of this case (and "sub par" is a misnomer) -- The nomadic client's quality of service could really only be identical or better than if they had instead received a non-specific response ("dns trick" response). The worst case here is not "sub par" -- it's just "par." :-) -David From owner-namedroppers@ops.ietf.org Tue Apr 13 12:40:03 2010 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 4A1743A6AA8; Tue, 13 Apr 2010 12:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.386 X-Spam-Level: X-Spam-Status: No, score=-96.386 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_42=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 fQ4Cc6cdmrbe; Tue, 13 Apr 2010 12:40:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6348928C171; Tue, 13 Apr 2010 12:39:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1lsR-000PfB-Qf for namedroppers-data0@psg.com; Tue, 13 Apr 2010 19:34:27 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1lsO-000Pem-W7 for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 19:34:25 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:64:217:f2ff:fee0:a91f]) (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 90164E81F2 for ; Tue, 13 Apr 2010 19:34:24 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Tue, 13 Apr 2010 12:34:23 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: namedroppers@ops.ietf.org Subject: [dnsext] matching begin/end SOA in AXFR User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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've recently found something not very clear in draft-ietf-dnsext-axfr-clarify-14. I think it's quite minor and doesn't affect the current state of the document (in RFC editor queue), but I'd like to see clarification here. In Section 2.2 the I-D states: An AXFR response that is transferring the zone's contents will consist of a series (which could be a series of length 1) of DNS messages. In such a series, the first message MUST begin with the SOA resource record of the zone, the last message MUST conclude with the same SOA resource record. In general this seems to be a reasonable requirement, but some details are not clear to me: 1. why the first and last SOAs "MUST" be the same in the first place? 2. what's the definition of same? Does this mean SOA RRs that have the same owner name and class (and perhaps TTL?). Or does this require the RDATA be the same, too? If the comparison covers any domain name (some or all of owner name, mname and rname), is it case sensitive or not? 3. what should the recipient do if these two SOA RRs are not "same"? Should it abort the AXFR or just ignore the mismatch and keep going? As for 1, someone told me that this would probably be to "cover the case of an authoritative nameserver that didn't lock down zones while serving AXFR, so there was some possibility that the SOA serial number of the second SOA in an AXFR would not match the first SOA". If that's the intent, it makes sense to me (although I suspect it's unlikely we have had or will this type of buggy authoritative server implementation). Regarding question #2: If point 1 is the rationale of the requirement, it would probably be sufficient to match the SOA serial field in practice, ignoring all other fields even including the owner name. But, assuming we should at least match one field of the RDATA (i.e. serial), a more natural interpretation would be that all fields of the two SOA RRs including the class and TTL should match, and names are to be compared (after de-compression) in case insensitive manner. I'm still not sure about question #3. If we introduced this requirement to catch a bug of the primary server implementation of the AXFR as described above, I believe the AXFR session should be aborted; otherwise the primary and secondary servers would have inconsistent contents for the same serial version of the zone. On the other hand, if we actually didn't care about such an unlikely bug and this requirement was for some minor purpose like predictability, maybe "MUST" might have been too strong (although I'm not opposing to the keyword, especially at this stage). BTW, from my quick read of source code, neither of two commonly used authoritative server implementations, namely BIND 9 and NSD, even compares the two SOAs. So, even if a serial mismatch happened these implementation simply accept the AXFR'ed data. --- JINMEI, Tatuya From owner-namedroppers@ops.ietf.org Tue Apr 13 13:30:30 2010 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 991593A67F6; Tue, 13 Apr 2010 13:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.004 X-Spam-Level: ** X-Spam-Status: No, score=2.004 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_42=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 H6cyWcc6fH20; Tue, 13 Apr 2010 13:30:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 87BD828C16C; Tue, 13 Apr 2010 13:30:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1mee-0008WN-MA for namedroppers-data0@psg.com; Tue, 13 Apr 2010 20:24:16 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1meX-0008UB-Ba for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 20:24:09 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3DKO0oT047736; Tue, 13 Apr 2010 16:24:00 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Tue, 13 Apr 2010 16:24:07 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 13 Apr 2010 16:24:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 13 Apr 2010 16:23:55 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] matching begin/end SOA in AXFR Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 MUST comes from antiquity. Equivalence means bit-for-bit the same. Everything else I'll say is conjecture. On send, it's easy to "just require it" as a end of transfer sentinel. What if it isn't there? What if the SOA isn't the same? What if the SOA has the same serial number but other elements change? All fair questions. But I don't know if they are "major" questions. (Are they?) It's not exactly a case where you might confuse it with an IXFR (because the IXFR starts with the ending serial number, then lists deletes-SOA-adds by zone increment. What if the SOA at the end (of the transmission, that is before the TCP is torn down) isn't right? I think if the client sees the transport fall, then they should consider there's a problem. If the transport just goes quiet, the client has to decide how much time to allot an inactive connection. In either case, is the transfer accepted. I'd vote no. Because this would make the slave fall behind and then expire the zone. In that case, the admins would have something obvious to fix. The fact that BIND and NSD don't check this, probably isn't a earth shattering problem. But if you had to include a failure handler there, I'd say if the SOA isnt' exactly the same, fail the transfer. Or is there some advantage to be loose here and say that any SOA ends the transfer and leave for the future some semantics if the SOAs do differ? At 12:34 -0700 4/13/10, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >Hello, > >I've recently found something not very clear in >draft-ietf-dnsext-axfr-clarify-14. I think it's quite minor and >doesn't affect the current state of the document (in RFC editor >queue), but I'd like to see clarification here. > >In Section 2.2 the I-D states: > > An AXFR response that is transferring the zone's contents will > consist of a series (which could be a series of length 1) of DNS > messages. In such a series, the first message MUST begin with the > SOA resource record of the zone, the last message MUST conclude with > the same SOA resource record. > >In general this seems to be a reasonable requirement, but some details >are not clear to me: > >1. why the first and last SOAs "MUST" be the same in the first place? >2. what's the definition of same? Does this mean SOA RRs that have > the same owner name and class (and perhaps TTL?). Or does this > require the RDATA be the same, too? If the comparison covers any > domain name (some or all of owner name, mname and rname), is it > case sensitive or not? >3. what should the recipient do if these two SOA RRs are not "same"? > Should it abort the AXFR or just ignore the mismatch and keep > going? > >As for 1, someone told me that this would probably be to "cover the >case of an authoritative nameserver that didn't lock down zones while >serving AXFR, so there was some possibility that the SOA serial number >of the second SOA in an AXFR would not match the first SOA". If >that's the intent, it makes sense to me (although I suspect it's >unlikely we have had or will this type of buggy authoritative server >implementation). > >Regarding question #2: If point 1 is the rationale of the requirement, >it would probably be sufficient to match the SOA serial field in >practice, ignoring all other fields even including the owner name. >But, assuming we should at least match one field of the RDATA >(i.e. serial), a more natural interpretation would be that all fields >of the two SOA RRs including the class and TTL should match, and names >are to be compared (after de-compression) in case insensitive manner. > >I'm still not sure about question #3. If we introduced this >requirement to catch a bug of the primary server implementation of the >AXFR as described above, I believe the AXFR session should be aborted; >otherwise the primary and secondary servers would have inconsistent >contents for the same serial version of the zone. On the other hand, >if we actually didn't care about such an unlikely bug and this >requirement was for some minor purpose like predictability, maybe >"MUST" might have been too strong (although I'm not opposing to the >keyword, especially at this stage). > >BTW, from my quick read of source code, neither of two commonly used >authoritative server implementations, namely BIND 9 and NSD, even >compares the two SOAs. So, even if a serial mismatch happened these >implementation simply accept the AXFR'ed data. > >--- >JINMEI, Tatuya -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From dmailer.ok@ietf.org Tue Apr 13 13:31:10 2010 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 74FEA28C18B for ; Tue, 13 Apr 2010 13:31:09 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 13 Apr 2010 13:31:05 -0700 (PDT) Received: from 93-45-80-11.ip101.fastwebnet.it (93-45-80-11.ip101.fastwebnet.it [93.45.80.11]) by core3.amsl.com (Postfix) with SMTP id 4E6F028C157 for ; Tue, 13 Apr 2010 13:30:32 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100413203036.4E6F028C157@core3.amsl.com> Date: Tue, 13 Apr 2010 13:30:32 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 79349 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Tue Apr 13 15:07:58 2010 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 8A53528C214; Tue, 13 Apr 2010 15:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_42=0.6] 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 upsZzkWsj8zi; Tue, 13 Apr 2010 15:07:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C42E28C210; Tue, 13 Apr 2010 15:07:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1oCi-0001Av-O9 for namedroppers-data0@psg.com; Tue, 13 Apr 2010 22:03:32 +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.71 (FreeBSD)) (envelope-from ) id 1O1oCe-0001AQ-LA for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 22:03:28 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C0D8DA1DD8; Tue, 13 Apr 2010 22:03:27 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: JINMEI Tatuya / =?us-ascii?Q?=3D=3FISO-2022-JP=3FB=3FGyRCP0BMQEMjOkgbK?= =?us-ascii?Q?EI=3D=3F=3D?= cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] matching begin/end SOA in AXFR In-Reply-To: Your message of "Tue\, 13 Apr 2010 12\:34\:23 MST." References: X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Apr 2010 22:03:27 +0000 Message-ID: <73005.1271196207@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: Tue, 13 Apr 2010 12:34:23 -0700 > From: JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 > ... > As for 1, someone told me that this would probably be to "cover the case > of an authoritative nameserver that didn't lock down zones while serving > AXFR, so there was some possibility that the SOA serial number of the > second SOA in an AXFR would not match the first SOA". If that's the > intent, it makes sense to me (although I suspect it's unlikely we have > had or will this type of buggy authoritative server implementation). very early BIND (before 4.8) could show this behaviour. > Regarding question #2: If point 1 is the rationale of the requirement, it > would probably be sufficient to match the SOA serial field in practice, > ignoring all other fields even including the owner name. But, assuming > we should at least match one field of the RDATA (i.e. serial), a more > natural interpretation would be that all fields of the two SOA RRs > including the class and TTL should match, and names are to be compared > (after de-compression) in case insensitive manner. i agree. there's supposed to be an identity mapping between the SOA.SERIAL and the content of the zone. the other fields of the SOA, and its TTL, are part of the zone. > I'm still not sure about question #3. If we introduced this requirement > to catch a bug of the primary server implementation of the AXFR as > described above, I believe the AXFR session should be aborted; otherwise > the primary and secondary servers would have inconsistent contents for > the same serial version of the zone. On the other hand, if we actually > didn't care about such an unlikely bug and this requirement was for some > minor purpose like predictability, maybe "MUST" might have been too > strong (although I'm not opposing to the keyword, especially at this > stage). i think MUST and "abort" are right. otherwise we can theoretically have incoherent authorities. > BTW, from my quick read of source code, neither of two commonly used > authoritative server implementations, namely BIND 9 and NSD, even > compares the two SOAs. So, even if a serial mismatch happened these > implementation simply accept the AXFR'ed data. BIND>=3D4.9 through BIND<9 only compared the serials. BIND<4.9 didn't look at the second serial number at all but did require a final SOA. From owner-namedroppers@ops.ietf.org Tue Apr 13 16:18:37 2010 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 1C02B3A6B61; Tue, 13 Apr 2010 16:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.396 X-Spam-Level: *** X-Spam-Status: No, score=3.396 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, J_CHICKENPOX_42=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 eEt6BHmjShVl; Tue, 13 Apr 2010 16:18:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C49E33A6B5E; Tue, 13 Apr 2010 16:18:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1pG7-000DHB-Ao for namedroppers-data0@psg.com; Tue, 13 Apr 2010 23:11:07 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1pG4-000DGb-QT for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 23:11:05 +0000 Received: (qmail 57988 invoked from network); 13 Apr 2010 23:15:48 -0000 Received: from softbank219001188004.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.4) by necom830.hpcl.titech.ac.jp with SMTP; 13 Apr 2010 23:15:48 -0000 Message-ID: <4BC4F9D3.9090408@necom830.hpcl.titech.ac.jp> Date: Wed, 14 Apr 2010 08:10:11 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] matching begin/end SOA in AXFR References: In-Reply-To: Content-Type: text/plain; charset=us-ascii 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: JINMEI Tatuya wrote: > 1. why the first and last SOAs "MUST" be the same in the first place? > So, even if a serial mismatch happened these > implementation simply accept the AXFR'ed data. It's no DNS specific. "Be liberal in what you accept. Be conservative in what you send." That's all. Masataka Ohta From owner-namedroppers@ops.ietf.org Tue Apr 13 17:36:19 2010 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 9656C3A67A5; Tue, 13 Apr 2010 17:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.38 X-Spam-Level: X-Spam-Status: No, score=0.38 tagged_above=-999 required=5 tests=[AWL=0.875, 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 2MYeMoTTcTfd; Tue, 13 Apr 2010 17:36:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C88BB3A6ADF; Tue, 13 Apr 2010 17:36:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1qVZ-000Pqi-2o for namedroppers-data0@psg.com; Wed, 14 Apr 2010 00:31:09 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1qVW-000PqH-J4 for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 00:31:06 +0000 Received: (qmail 4998 invoked by uid 399); 14 Apr 2010 00:31:05 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 14 Apr 2010 00:31:05 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BC50CC7.4090702@dougbarton.us> Date: Tue, 13 Apr 2010 17:31:03 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF DNSEXT WG Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries References: <4BB3E324.2050207@isc.org> In-Reply-To: <4BB3E324.2050207@isc.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 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: M) This draft proposes changing the DNS protocol to benefit latency-sensitive applications. m) Not all applications that use DNS are latency-sensitive. C) Latency-sensitive applications should use application layer mitigation strategies, and this draft should not be adopted. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Tue Apr 13 18:17:59 2010 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 3B81128C163; Tue, 13 Apr 2010 18:17:59 -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 BWi-rOxA2WQ8; Tue, 13 Apr 2010 18:17:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F78128C1DC; Tue, 13 Apr 2010 18:17:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1rAi-0007zI-Rb for namedroppers-data0@psg.com; Wed, 14 Apr 2010 01:13:40 +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.71 (FreeBSD)) (envelope-from ) id 1O1rAg-0007xm-L8 for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 01:13:38 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5A2A9A1E03 for ; Wed, 14 Apr 2010 01:13:38 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries In-Reply-To: Your message of "Tue, 13 Apr 2010 17:31:03 MST." <4BC50CC7.4090702@dougbarton.us> References: <4BB3E324.2050207@isc.org> <4BC50CC7.4090702@dougbarton.us> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Wed, 14 Apr 2010 01:13:38 +0000 Message-ID: <81226.1271207618@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: Tue, 13 Apr 2010 17:31:03 -0700 > From: Doug Barton > > M) This draft proposes changing the DNS protocol to benefit > latency-sensitive applications. > m) Not all applications that use DNS are latency-sensitive. > C) Latency-sensitive applications should use application layer > mitigation strategies, and this draft should not be adopted. +1 on this, though i still think there are better reasons for nonadoption. From owner-namedroppers@ops.ietf.org Tue Apr 13 18:22:04 2010 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 D84A63A6970; Tue, 13 Apr 2010 18:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.26 X-Spam-Level: X-Spam-Status: No, score=0.26 tagged_above=-999 required=5 tests=[AWL=0.133, 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 e8rRTnN012Cx; Tue, 13 Apr 2010 18:22:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 46ED33A6837; Tue, 13 Apr 2010 18:22:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1rFx-0008oQ-Dh for namedroppers-data0@psg.com; Wed, 14 Apr 2010 01:19:05 +0000 Received: from [209.85.160.180] (helo=mail-gy0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1rFv-0008o5-F6 for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 01:19:03 +0000 Received: by gyb13 with SMTP id 13so3626897gyb.11 for ; Tue, 13 Apr 2010 18:19:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Tue, 13 Apr 2010 18:19:02 -0700 (PDT) In-Reply-To: <4BC50CC7.4090702@dougbarton.us> References: <4BB3E324.2050207@isc.org> <4BC50CC7.4090702@dougbarton.us> Date: Tue, 13 Apr 2010 18:19:02 -0700 Received: by 10.151.92.9 with SMTP id u9mr4573819ybl.336.1271207942330; Tue, 13 Apr 2010 18:19:02 -0700 (PDT) Message-ID: Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries From: Matthew Dempsky To: IETF DNSEXT WG 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 Tue, Apr 13, 2010 at 5:31 PM, Doug Barton wrote: > M) This draft proposes changing the DNS protocol to benefit > latency-sensitive applications. The draft adds an *option* to the DNS protocol. The great thing about options is you don't have to implement them. From owner-namedroppers@ops.ietf.org Tue Apr 13 18:33:27 2010 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 A48023A6B6E; Tue, 13 Apr 2010 18:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.235 X-Spam-Level: X-Spam-Status: No, score=0.235 tagged_above=-999 required=5 tests=[AWL=0.730, 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 t4F64sJUt4sP; Tue, 13 Apr 2010 18:33:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D3693A6AEE; Tue, 13 Apr 2010 18:33:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1rQL-000Ad3-PC for namedroppers-data0@psg.com; Wed, 14 Apr 2010 01:29:49 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1rQJ-000AcY-5g for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 01:29:47 +0000 Received: (qmail 17668 invoked by uid 399); 14 Apr 2010 01:29:46 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 14 Apr 2010 01:29:46 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BC51A88.5090708@dougbarton.us> Date: Tue, 13 Apr 2010 18:29:44 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Matthew Dempsky CC: IETF DNSEXT WG Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries References: <4BB3E324.2050207@isc.org> <4BC50CC7.4090702@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 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: On 4/13/2010 6:19 PM, Matthew Dempsky wrote: > On Tue, Apr 13, 2010 at 5:31 PM, Doug Barton wrote: >> M) This draft proposes changing the DNS protocol to benefit >> latency-sensitive applications. > > The draft adds an *option* to the DNS protocol. Even setting aside the other concerns I've already raised about this "option," the fact that it is "optional" doesn't change my argument. -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Tue Apr 13 18:39:43 2010 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 9B1323A6A7A; Tue, 13 Apr 2010 18:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.83 X-Spam-Level: X-Spam-Status: No, score=-4.83 tagged_above=-999 required=5 tests=[AWL=0.218, 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 ndPPSyu0Wjr5; Tue, 13 Apr 2010 18:39:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2FACB3A6AE3; Tue, 13 Apr 2010 18:39:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1rVo-000Bba-Fi for namedroppers-data0@psg.com; Wed, 14 Apr 2010 01:35:28 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1rVm-000BbG-BE for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 01:35:26 +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 o3E1Z7fF005265; Tue, 13 Apr 2010 18:35:07 -0700 (PDT) Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <81226.1271207618@nsa.vix.com> Date: Tue, 13 Apr 2010 18:35:06 -0700 Cc: Nicholas Weaver , IETF DNSEXT WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BB3E324.2050207@isc.org> <4BC50CC7.4090702@dougbarton.us> <81226.1271207618@nsa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.1078) 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 Apr 13, 2010, at 6:13 PM, Paul Vixie wrote: >> Date: Tue, 13 Apr 2010 17:31:03 -0700 >> From: Doug Barton >>=20 >> M) This draft proposes changing the DNS protocol to benefit >> latency-sensitive applications. >> m) Not all applications that use DNS are latency-sensitive. >> C) Latency-sensitive applications should use application layer >> mitigation strategies, and this draft should not be adopted. >=20 > +1 on this, though i still think there are better reasons for = nonadoption. Almost no applications currently existing that use DNS benefit from = DNSSEC, do we want to use that as an argument? Additionally, as I explained, the latency mitigation strategies can't be = done at the application layer (redirects eliminate the latency savings), = and at this point, these DNS tricks are well established and do actually = seem to work well for those who stick with their ISP's DNS resolver. From owner-namedroppers@ops.ietf.org Tue Apr 13 19:23:51 2010 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 702C43A6A69; Tue, 13 Apr 2010 19:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[AWL=0.294, 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 WKMwos+6K2nl; Tue, 13 Apr 2010 19:23:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2721A3A6810; Tue, 13 Apr 2010 19:23:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1sC8-000JIV-9c for namedroppers-data0@psg.com; Wed, 14 Apr 2010 02:19:12 +0000 Received: from [74.125.82.180] (helo=mail-wy0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1sC2-000JHP-Hl for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 02:19:06 +0000 Received: by wyf22 with SMTP id 22so1470200wyf.11 for ; Tue, 13 Apr 2010 19:19:05 -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:received:message-id:subject:from:to:cc:content-type; bh=q3n/KLh0kI9Yu+cc0Pde9WxWOC780h8+SDY5xhpQ8bo=; b=TIsfTnc9xHo4TX5OHiuiniEvxFxzFK34RgO2Wy4JhRUAv+zZnfNzLaJxP5GZM48xg+ /CJd0JIdIIOY1NhFk5/wlZfhHqHN8ZIrxceqP54j4ScCCbLbIAwtdhm3PzlpxxeDERDl LXghHy+y8hFVNX6x+HKsPN16v5JPdGNbM4LVg= 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 :cc:content-type; b=mcC8JBg9kpDOgIuTB3jcyoZ8SqxAFYNmMnlhmisuZDGCivw3UFifzAd354Dgd+1mXE aMW8XAjFN5Fhsbvl+r/Jpw2X2T/3r1FrbiooR2FxyKaa//nDSeUxZ52DeNC3PexLnHgr 9mPV4ByUyGvy91M0CrjyVh55hP0z+VlbmuIaA= MIME-Version: 1.0 Received: by 10.216.6.90 with HTTP; Tue, 13 Apr 2010 19:19:04 -0700 (PDT) In-Reply-To: <4BC50CC7.4090702@dougbarton.us> References: <4BB3E324.2050207@isc.org> <4BC50CC7.4090702@dougbarton.us> Date: Tue, 13 Apr 2010 22:19:04 -0400 Received: by 10.216.89.195 with SMTP id c45mr434989wef.98.1271211544847; Tue, 13 Apr 2010 19:19:04 -0700 (PDT) Message-ID: Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries From: Donald Eastlake To: Doug Barton Cc: IETF DNSEXT WG Content-Type: multipart/alternative; boundary=0016e6d99d4690a81f0484290074 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: --0016e6d99d4690a81f0484290074 Content-Type: text/plain; charset=ISO-8859-1 Hi Doug, On Tue, Apr 13, 2010 at 8:31 PM, Doug Barton wrote: > M) This draft proposes changing the DNS protocol to benefit > latency-sensitive applications. > m) Not all applications that use DNS are latency-sensitive. > So? I don't see why you would think anything can be deduced from the above two statements. Protocols are changed all the time, particularly when the change is in the form of adding a backward compatible extension or option, for the benefit of only some users of the protocol. You have to weigh the various present and future costs and benefits of the change to be able to decide if it is a net benefit. > C) Latency-sensitive applications should use application layer > mitigation strategies, and this draft should not be adopted. > Your point "C" above is an opinion. Seems very general and is presented with no supporting facts or arguments (certainly I don't consider your points M and m to be an argument in favor of C), but you are welcome to your opinion. Doug Thanks, Donald --0016e6d99d4690a81f0484290074 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Doug,

On Tue, Apr 13, 2010= at 8:31 PM, Doug Barton <dougb@dougbarton.us> wrote:
M) This draft proposes changing the DNS protocol to benefit
latency-sensitive applications.
m) Not all applications that use DNS are latency-sensitive.

So? I don't see why you would think anything can b= e deduced from the above two statements. Protocols are changed all the time= , particularly when the change is in the form of adding a backward compatib= le extension or option, for the benefit of only some users of the protocol.= You have to weigh the various present and future costs and benefits of the= change to be able to decide if it is a net benefit.
=A0
C) Latency-sensitive applications should use application layer
mitigation strategies, and this draft should not be adopted.

Your point "C" above is an opinion. Seems v= ery general and is presented with no supporting facts or arguments (certain= ly I don't consider your points M and m to be an argument in favor of C= ), but you are welcome to your opinion.

Doug

Thanks,
Donald=A0
--0016e6d99d4690a81f0484290074-- From owner-namedroppers@ops.ietf.org Tue Apr 13 22:02:18 2010 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 6FB8028C1F3; Tue, 13 Apr 2010 22:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 q7vbcpvTx7iE; Tue, 13 Apr 2010 22:02:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 859FB3A6816; Tue, 13 Apr 2010 22:02:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1ufL-000KcJ-4d for namedroppers-data0@psg.com; Wed, 14 Apr 2010 04:57:31 +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.71 (FreeBSD)) (envelope-from ) id 1O1ufI-000Kbn-Lx for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 04:57:28 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5F6BEA1E5F for ; Wed, 14 Apr 2010 04:57:28 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries In-Reply-To: Your message of "Tue, 13 Apr 2010 18:19:02 MST." References: <4BB3E324.2050207@isc.org> <4BC50CC7.4090702@dougbarton.us> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Wed, 14 Apr 2010 04:57:28 +0000 Message-ID: <90723.1271221048@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: Tue, 13 Apr 2010 18:19:02 -0700 > From: Matthew Dempsky > > On Tue, Apr 13, 2010 at 5:31 PM, Doug Barton wrote: > > M) This draft proposes changing the DNS protocol to benefit > > latency-sensitive applications. > > The draft adds an *option* to the DNS protocol. The great thing about > options is you don't have to implement them. that's not true. i'm not calling you a liar, i am sure you believe this. but it's just not true, especially in the case of a stupid-dns-tricks option. From owner-namedroppers@ops.ietf.org Tue Apr 13 22:09:44 2010 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 96EBF3A6765; Tue, 13 Apr 2010 22:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 NfhTwYu2rxUX; Tue, 13 Apr 2010 22:09:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D5A6B3A6876; Tue, 13 Apr 2010 22:09:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1umU-000M2B-Nk for namedroppers-data0@psg.com; Wed, 14 Apr 2010 05:04: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.71 (FreeBSD)) (envelope-from ) id 1O1umS-000M1o-7k for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 05:04:52 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 04ED6A1E52 for ; Wed, 14 Apr 2010 05:04:52 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries In-Reply-To: Your message of "Tue, 13 Apr 2010 18:35:06 MST." References: <4BB3E324.2050207@isc.org> <4BC50CC7.4090702@dougbarton.us> <81226.1271207618@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Wed, 14 Apr 2010 05:04:51 +0000 Message-ID: <91048.1271221491@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: Nicholas Weaver > Date: Tue, 13 Apr 2010 18:35:06 -0700 > > >> From: Doug Barton > >> > >> M) This draft proposes changing the DNS protocol to benefit > >> latency-sensitive applications. > >> m) Not all applications that use DNS are latency-sensitive. > >> C) Latency-sensitive applications should use application layer > >> mitigation strategies, and this draft should not be adopted. > > Almost no applications currently existing that use DNS benefit from > DNSSEC, do we want to use that as an argument? you're saying there could be a new breed of new applications in orbit waiting for a chance to land, which will benefit from latency-optimized dns incoherency? can you give us a ferinstance? (in supposedly parallel case you pointed to, i'd like to replace the x509 CA system with dnssec-signed records, but even without that, the ability to be sure the nameserver i'm talking to really is authoritative and that the mx i'm processing really is the real one will eventually lower my insurance rates.) > Additionally, as I explained, the latency mitigation strategies can't be > done at the application layer (redirects eliminate the latency savings), did you not know about permanent redirects? that's how ibm websphere works. perhaps if it's not beneficial you should notify them that you think they are selling snake oil? (yes, there's web client-to-server optimization in the world that isn't based on dns incoherency.) > and at this point, these DNS tricks are well established and do actually > seem to work well for those who stick with their ISP's DNS resolver. you have a very high onus of proof barrier to overcome before that statement will be generally accepted beyond those who won't be fired for buying akamai. From owner-namedroppers@ops.ietf.org Tue Apr 13 23:33:51 2010 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 6B7D73A6B9A; Tue, 13 Apr 2010 23:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.027 X-Spam-Level: *** X-Spam-Status: No, score=3.027 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 y01iDZONYBT6; Tue, 13 Apr 2010 23:33:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 713F33A67FE; Tue, 13 Apr 2010 23:33:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1w4n-000BbQ-Bk for namedroppers-data0@psg.com; Wed, 14 Apr 2010 06:27:53 +0000 Received: from [74.125.83.52] (helo=mail-gw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1w4j-000Bb1-Gw for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 06:27:49 +0000 Received: by gwj19 with SMTP id 19so289900gwj.11 for ; Tue, 13 Apr 2010 23:27:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.169.1 with HTTP; Tue, 13 Apr 2010 23:27:46 -0700 (PDT) In-Reply-To: <91048.1271221491@nsa.vix.com> References: <4BB3E324.2050207@isc.org> <4BC50CC7.4090702@dougbarton.us> <81226.1271207618@nsa.vix.com> <91048.1271221491@nsa.vix.com> Date: Tue, 13 Apr 2010 23:27:46 -0700 Received: by 10.150.183.4 with SMTP id g4mr6554714ybf.71.1271226466642; Tue, 13 Apr 2010 23:27:46 -0700 (PDT) Message-ID: Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Paul Vixie Cc: IETF DNSEXT WG 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 Tue, Apr 13, 2010 at 10:04 PM, Paul Vixie wrote: >> Additionally, as I explained, the latency mitigation strategies can't be >> done at the application layer (redirects eliminate the latency savings), > > did you not know about permanent redirects? =A0that's how ibm websphere > works. =A0perhaps if it's not beneficial you should notify them that you > think they are selling snake oil? =A0(yes, there's web client-to-server > optimization in the world that isn't based on dns incoherency.) Can you provide some references explaining this technique? I'd consider myself an experienced HTTP implementer (Apache httpd, if that counts) and know of no HTTP-level technique, using redirects or otherwise, that can rival the latency optimisations capable today at DNS level. Permanent redirects are URI specific, rather than domain specific, and have non-trivial interactions with caches. Even in the ideal case, let's say we minimise the surface area to a single portal url; http://myexampleportal.com/ and a HTTP request to it then 301 redirects to a new domain which is network-locality dependent, say; 301 -> http://new-york.myexampleportal.com/ and all embedded URLs are relative, and so on, so that subsequent links stick to the same new domain. There are still some clear problems; 1. Obviously the first request must incur a latency penalty to get the redirect in the first place. 2. Such redirects are, as the name suggests, permanent. When you add more destination network sites - what do you do? How do you tell the clients that have cached the redirect? And temporary redirects - which are generally not cached at all - are obviously even worse. 3. The burden of caching is thinly spread across browsers and proxies, and is not particularly efficient. >> and at this point, these DNS tricks are well established and do actually >> seem to work well for those who stick with their ISP's DNS resolver. > > you have a very high onus of proof barrier to overcome before that statem= ent > will be generally accepted beyond those who won't be fired for buying aka= mai. I again will repeat my suggestion; can you describe an experiment that can be practically run, or data that would be sufficient, to demonstrate to you that such tricks do or do not definitively seem to work. What would your burden of evidence look like? If you can commit to an experimental protocol, then this barrier may be overcome relatively trivially with data. --=20 Colm From owner-namedroppers@ops.ietf.org Wed Apr 14 05:43:30 2010 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 E806528C1CA; Wed, 14 Apr 2010 05:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.84 X-Spam-Level: * X-Spam-Status: No, score=1.84 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_50=0.001, 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 2i6WEJewt+UK; Wed, 14 Apr 2010 05:43:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1FA073A6BC5; Wed, 14 Apr 2010 05:37:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O21jf-000AOz-NL for namedroppers-data0@psg.com; Wed, 14 Apr 2010 12:30:27 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O21jb-000AOM-50 for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 12:30:23 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3ECU1P0054008; Wed, 14 Apr 2010 08:30:01 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Wed, 14 Apr 2010 08:30:07 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 14 Apr 2010 08:30:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 14 Apr 2010 08:28:18 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Edward Lewis Subject: Re: [dnsext] matching begin/end SOA in AXFR Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary="============_-940874295==_ma============" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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: --============_-940874295==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 20:59 -0700 4/13/10, JINMEI Tatuya wrote: >Hmm, so no one knows or remembers the real rationale? You may have to contact PVM, maybe Rob A. Don't know who else would have a memory that far back. And remember, that the "clarify" document is not out to redefine (any more than it does so already) the mechanism. So that's why I don't think the WG should spend much energy on this. >Okay, but "bit-for-bit" is still not very clear: is this "bit-for-bit >but case-insensitive for names" or "strict" bit-for-bit as opaque data >(so names are compared case-sensitively)? "bit-for-bit" could also be >unclear because some fields of the SOAs may be compressed. How about "bit-for-bit after undoing the compression" then? I.e., same RDATA. It's not like the SOA's are coming from different sources (servers). >I don't think these are major issues. I basically just wanted to be >sure about some unclear points of the specification. Are you unclear on the original specification or is it that major implementations differ from the specification? Looking at RFC 1034, s4.3.5: "The first and last messages must contain the data for the top authoritative node of the zone." and in 6.3: "If a master is sending a zone out via AXFR, and a new version is created during the transfer, the master should continue to send the old version if possible. In any case, it should never send part of one version and part of another. If completion is not possible, the master should reset the connection on which the zone transfer is taking place." From these two passages, I take it that the SOA is needed and is to be the same. Now, the "top authoritative node of the zone" could mean all apex records (those owned by the name with the SOA - the NS, DNSSEC stuff, ...). Is the question that the "clarify" is changing this by stating specifically just the SOA RR? Note that it is legal today (or it would work today to send this): zone.tld. SOA ser_no_4 www.zone.tld. A zone.tld. RRSIG NSEC www.zone.tld. RRSIG NSEC zone.tld. DNSKEY www.zone.tld RRSIG A zone.tld. NS zone.tld. RRSIG SOA zone.tld. RRSIG NS zone.tld. NS zone.tld RRSIG DNSKEY zone.tld. NS zone.tld. NSEC www.zone.tld. www.zone.tld. NSEC zone.tld. zone.tld. SOA ser_no_4 (Imagine each of these in a separate AXFR message unit too.) Given this from 5.2 in RFC 1035: 2. Exactly one SOA RR should be present at the top of the zone. That really only the SOA's mere presence can signal the end of the zone (as opposed to another NS to the NS set). So, I think there's little question that the start and end have to be the same SOA. If implementations don't check this, well, that's implementations being implementations. If they check and drop the transfer or check and keep it anyway, or don't check at all, well, that's implementations being implementations. Implementers have done worse things to the protocol in the past. ;) The answers to all this would lie in the "who does know why" this was set way back when, as the documents leave something to the imagination. >This is basically what I was thinking: It's probably not a big deal >anyway and can be considered an "implementation dependent behavior"; >but if we want to handle this case explicitly the right choice would >be to fail it (rather than ignore the mismatch). I thought about this after my last reply. Maybe the very next SOA seen (different owner, different serial number, same...) should "end" the transfer and if the SOA isn't the "same" then the transfer is considered a failure. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? --============_-940874295==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] matching begin/end SOA in AXFR
At 20:59 -0700 4/13/10, JINMEI Tatuya wrote:

>Hmm, so no one knows or remembers the real rationale?

You may have to contact PVM, maybe Rob A.  Don't know who else would have a memory that far back.

And remember, that the "clarify" document is not out to redefine (any more than it does so already) the mechanism.  So that's why I don't think the WG should spend much energy on this.

>Okay, but "bit-for-bit" is still not very clear: is this "bit-for-bit
>but case-insensitive for names" or "strict" bit-for-bit as opaque data
>(so names are compared case-sensitively)?  "bit-for-bit" could also be
>unclear because some fields of the SOAs may be compressed.
How about "bit-for-bit after undoing the compression" then?  I.e., same RDATA.

It's not like the SOA's are coming from different sources (servers).

>I don't think these are major issues.  I basically just wanted to be
>sure about some unclear points of the specification.

Are you unclear on the original specification or is it that major implementations differ from the specification?

Looking at RFC 1034, s4.3.5:

"The first and last messages must contain the data for the top authoritative node of the zone."

and in 6.3:

"If a master is sending a zone out via AXFR, and a new version is created
during the transfer, the master should continue to send the old version
if possible.  In any case, it should never send part of one version and
part of another.  If completion is not possible, the master should reset
the connection on which the zone transfer is taking place."

From these two passages, I take it that the SOA is needed and is to be the same.  Now, the "top authoritative node of the zone" could mean all apex records (those owned by the name with the SOA - the NS, DNSSEC stuff, ...).  Is the question that the "clarify" is changing this by stating specifically just the SOA RR?

Note that it is legal today (or it would work today to send this):

zone.tld.     SOA    ser_no_4
www.zone.tld. A
zone.tld.     RRSIG  NSEC
www.zone.tld. RRSIG  NSEC
zone.tld.     DNSKEY
www.zone.tld  RRSIG  A
zone.tld.     NS
zone.tld.     RRSIG  SOA
zone.tld.     RRSIG  NS
zone.tld.     NS
zone.tld      RRSIG  DNSKEY
zone.tld.     NS
zone.tld.     NSEC   www.zone.tld.
www.zone.tld. NSEC   zone.tld.
zone.tld.     SOA   ser_no_4

(Imagine each of these in a separate AXFR message unit too.)

Given this from 5.2 in RFC 1035:

   2. Exactly one SOA RR should be present at the top of the zone.
That really only the SOA's mere presence can signal the end of the zone (as opposed to another NS to the NS set).

So, I think there's little question that the start and end have to be the same SOA.  If implementations don't check this, well, that's implementations being implementations.  If they check and drop the transfer or check and keep it anyway, or don't check at all, well, that's implementations being implementations.

Implementers have done worse things to the protocol in the past. ;)

The answers to all this would lie in the "who does know why" this was set way back when, as the documents leave something to the imagination.

>This is basically what I was thinking: It's probably not a big deal
>anyway and can be considered an "implementation dependent behavior";
>but if we want to handle this case explicitly the right choice would
>be to fail it (rather than ignore the mismatch).

I thought about this after my last reply.  Maybe the very next SOA seen (different owner, different serial number, same...) should "end" the transfer and if the SOA isn't the "same" then the transfer is considered a failure.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Wouldn't it be nice if all of the definitions of equivalence were the same?
--============_-940874295==_ma============-- From owner-namedroppers@ops.ietf.org Wed Apr 14 05:46:36 2010 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 B55C428C2C3; Wed, 14 Apr 2010 05:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[AWL=-1.248, BAYES_50=0.001, 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 wx+coBZkYjxR; Wed, 14 Apr 2010 05:46:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9DA013A6C36; Wed, 14 Apr 2010 05:41:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O21qi-000C9d-Tw for namedroppers-data0@psg.com; Wed, 14 Apr 2010 12:37:45 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O21qg-000C6t-Cd for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 12:37:42 +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 o3ECbM12013818; Wed, 14 Apr 2010 05:37:22 -0700 (PDT) Subject: Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Nicholas Weaver In-Reply-To: Date: Wed, 14 Apr 2010 05:37:21 -0700 Cc: Nicholas Weaver , Paul Vixie , IETF DNSEXT WG Content-Transfer-Encoding: quoted-printable Message-Id: <64A9BA07-9F63-4556-8C65-1694955627CB@icsi.berkeley.edu> References: <4BB3E324.2050207@isc.org> <4BC50CC7.4090702@dougbarton.us> <81226.1271207618@nsa.vix.com> <91048.1271221491@nsa.vix.com> To: =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= X-Mailer: Apple Mail (2.1078) 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 Apr 13, 2010, at 11:27 PM, Colm MacC=E1rthaigh wrote: >=20 > 1. Obviously the first request must incur a latency penalty to get > the redirect in the first place. > 2. Such redirects are, as the name suggests, permanent. When you add > more destination network sites - what do you do? How do you tell the > clients that have cached the redirect? And temporary redirects - which > are generally not cached at all - are obviously even worse. > 3. The burden of caching is thinly spread across browsers and > proxies, and is not particularly efficient. 4. It exports visible URLs, which people will bookmark, and which may = need to be redirected when mobile clients move. >=20 >>> and at this point, these DNS tricks are well established and do = actually >>> seem to work well for those who stick with their ISP's DNS resolver. >>=20 >> you have a very high onus of proof barrier to overcome before that = statement >> will be generally accepted beyond those who won't be fired for buying = akamai. >=20 > I again will repeat my suggestion; can you describe an experiment that > can be practically > run, or data that would be sufficient, to demonstrate to you that such > tricks do or do not definitively seem to work. What would your burden > of evidence look like? >=20 > If you can commit to an experimental protocol, then this barrier may > be overcome relatively trivially with data. One can actually see the effect with a simple test for at least their = own case. Ping www.bing.com (a heavily akamaized' site) Ping the results returned for www.bing.com when fetched through google = public DNS instead (8.8.8.8). EG, I just saw 30 ms for the result returned by my ISP's resolver = (comcast), 90ms for Google public DNS! Even just a 20ms difference in latency is compounded, as a typical web = interaction will need several RTTs. In this case, it was 60ms. Same results apply for www.yahoo.com (40ms vs 100 ms, where the lookup = through the ISP's resolver puts me to a san jose yahoo cloud (although = the peering point with as6453 is down in LA) while the lookup through = Google Public DNS will route my packets to a washington yahoo cloud, but = through level 1 peering point so down to LA first!). =20 Yahoo doesn't use Akamai for this, but just uses Stupid DNS Tricks for = selecting the right subcloud. This doesn't apply to Google, which is sending all my packets to a texas = server irregardless, and therefore www.google.com is 70ms for both = cases. This may just be one datapoint, mind you, but this is exactly why people = push stuff towards the edge or to at least many-geographic distribution = and use stupid DNS tricks to ensure that the user gets to the right one: = 50ms counts for something in the world where the resulting interactions = will have several RTTs worth of latency. And so why should someone want to use Google Public DNS, which will = cause significant sites to slow down measurably on interactivity? From robustlyzxd@did.ru Wed Apr 14 09:24:11 2010 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 C5AB828C298; Wed, 14 Apr 2010 09:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.439 X-Spam-Level: X-Spam-Status: No, score=-81.439 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_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, 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, 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 aexiwHrGVBfl; Wed, 14 Apr 2010 09:24:05 -0700 (PDT) Received: from dslb-084-061-035-135.pools.arcor-ip.net (dslb-084-061-035-135.pools.arcor-ip.net [84.61.35.135]) by core3.amsl.com (Postfix) with ESMTP id AF00228C25C; Wed, 14 Apr 2010 09:24:02 -0700 (PDT) Received: from 84.61.35.135 by mail.did.ru; Wed, 14 Apr 2010 18:23:35 +0100 Date: Wed, 14 Apr 2010 18:23:35 +0100 From: dnsext-archive@lists.ietf.org Subject: Meet that special someone today To: Message-ID: <000d01cadbee$d50cb680$6400a8c0@robustlyzxd> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Meet that special someone today. It costs you nothing to check it out. All you have to do is press this web link and you'll be chatting with someone in no time. http://curricular286.spaces.live.com From directory-bounces@ietf.org Wed Apr 14 09:24:18 2010 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FA128C10D for ; Wed, 14 Apr 2010 09:24:18 -0700 (PDT) Subject: The results of your email commands From: directory-bounces@ietf.org To: dnsext-archive@lists.ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1986841080==" Message-ID: Date: Wed, 14 Apr 2010 09:24:17 -0700 Precedence: bulk X-BeenThere: directory@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of issues related to directories X-List-Administrivia: yes Sender: directory-bounces@ietf.org Errors-To: directory-bounces@ietf.org --===============1986841080== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://curricular286.spaces.live.com - Done. --===============1986841080== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: directory-request@core3.amsl.com Delivered-To: directory-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5AB828C298; Wed, 14 Apr 2010 09:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.439 X-Spam-Level: X-Spam-Status: No, score=-81.439 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_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, 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, 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 aexiwHrGVBfl; Wed, 14 Apr 2010 09:24:05 -0700 (PDT) Received: from dslb-084-061-035-135.pools.arcor-ip.net (dslb-084-061-035-135.pools.arcor-ip.net [84.61.35.135]) by core3.amsl.com (Postfix) with ESMTP id AF00228C25C; Wed, 14 Apr 2010 09:24:02 -0700 (PDT) Received: from 84.61.35.135 by mail.did.ru; Wed, 14 Apr 2010 18:23:35 +0100 Date: Wed, 14 Apr 2010 18:23:35 +0100 From: dnsext-archive@lists.ietf.org Subject: Meet that special someone today To: Message-ID: <000d01cadbee$d50cb680$6400a8c0@robustlyzxd> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Meet that special someone today. It costs you nothing to check it out. All you have to do is press this web link and you'll be chatting with someone in no time. http://curricular286.spaces.live.com --===============1986841080==-- From dnsop-bounces@ietf.org Wed Apr 14 09:24:18 2010 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2CA28C284 for ; Wed, 14 Apr 2010 09:24:18 -0700 (PDT) Subject: The results of your email commands From: dnsop-bounces@ietf.org To: dnsext-archive@lists.ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1631907047==" Message-ID: Date: Wed, 14 Apr 2010 09:24:17 -0700 Precedence: bulk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF DNSOP WG mailing list X-List-Administrivia: yes Sender: dnsop-bounces@ietf.org Errors-To: dnsop-bounces@ietf.org --===============1631907047== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://curricular286.spaces.live.com - Done. --===============1631907047== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: dnsop-request@core3.amsl.com Delivered-To: dnsop-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5AB828C298; Wed, 14 Apr 2010 09:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.439 X-Spam-Level: X-Spam-Status: No, score=-81.439 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_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, 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, 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 aexiwHrGVBfl; Wed, 14 Apr 2010 09:24:05 -0700 (PDT) Received: from dslb-084-061-035-135.pools.arcor-ip.net (dslb-084-061-035-135.pools.arcor-ip.net [84.61.35.135]) by core3.amsl.com (Postfix) with ESMTP id AF00228C25C; Wed, 14 Apr 2010 09:24:02 -0700 (PDT) Received: from 84.61.35.135 by mail.did.ru; Wed, 14 Apr 2010 18:23:35 +0100 Date: Wed, 14 Apr 2010 18:23:35 +0100 From: dnsext-archive@lists.ietf.org Subject: Meet that special someone today To: Message-ID: <000d01cadbee$d50cb680$6400a8c0@robustlyzxd> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Meet that special someone today. It costs you nothing to check it out. All you have to do is press this web link and you'll be chatting with someone in no time. http://curricular286.spaces.live.com --===============1631907047==-- From robustlyzxd@did.ru Wed Apr 14 09:24:11 2010 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 C5AB828C298; Wed, 14 Apr 2010 09:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.439 X-Spam-Level: X-Spam-Status: No, score=-81.439 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_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, 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, 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 aexiwHrGVBfl; Wed, 14 Apr 2010 09:24:05 -0700 (PDT) Received: from dslb-084-061-035-135.pools.arcor-ip.net (dslb-084-061-035-135.pools.arcor-ip.net [84.61.35.135]) by core3.amsl.com (Postfix) with ESMTP id AF00228C25C; Wed, 14 Apr 2010 09:24:02 -0700 (PDT) Received: from 84.61.35.135 by mail.did.ru; Wed, 14 Apr 2010 18:23:35 +0100 Date: Wed, 14 Apr 2010 18:23:35 +0100 From: dnsext-archive@lists.ietf.org Subject: Meet that special someone today To: Message-ID: <000d01cadbee$d50cb680$6400a8c0@robustlyzxd> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Meet that special someone today. It costs you nothing to check it out. All you have to do is press this web link and you'll be chatting with someone in no time. http://curricular286.spaces.live.com From dnsext-archive@ietf.org Wed Apr 14 11:59:58 2010 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 2A0D53A68F3 for ; Wed, 14 Apr 2010 11:59:58 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char A9 hex): From: USA \251 Doctor Christy[...] X-Spam-Flag: NO X-Spam-Score: -66.374 X-Spam-Level: X-Spam-Status: No, score=-66.374 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_8BIT_HEADER=0.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_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_BLACK=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 z8lBHNgXaeq0 for ; Wed, 14 Apr 2010 11:59:57 -0700 (PDT) Received: from brln-4d0cdc5b.pool.mediaWays.net (brln-4d0cdc5b.pool.mediaWays.net [77.12.220.91]) by core3.amsl.com (Postfix) with SMTP id 98BC03A67DA for ; Wed, 14 Apr 2010 11:59:56 -0700 (PDT) From: USA Doctor Christy To: dnsext-archive@ietf.org Subject: Dear dnsext-archive@ietf.org April 93% OFF MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100414185956.98BC03A67DA@core3.amsl.com> Date: Wed, 14 Apr 2010 11:59:56 -0700 (PDT)
Click here to view as a web page.

View image in browser now
To dnsext-archive@ietf.org | Privacy Policy | Contact Us

Copyright 2010 USozz Inc. All rights reserved.
From owner-namedroppers@ops.ietf.org Wed Apr 14 12:10:36 2010 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 86E743A6A38; Wed, 14 Apr 2010 12:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[AWL=-1.185, BAYES_50=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 Q7o7ypVOvLlB; Wed, 14 Apr 2010 12:10:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D5133A69F7; Wed, 14 Apr 2010 12:10:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O27pd-000Jn7-4o for namedroppers-data0@psg.com; Wed, 14 Apr 2010 19:01:01 +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.71 (FreeBSD)) (envelope-from ) id 1O27pa-000Jmj-Ne for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 19:00:58 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 232BEA1F74 for ; Wed, 14 Apr 2010 19:00:58 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: [dnsext] add support for latency-sensitive dns applications such as the web? X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Wed, 14 Apr 2010 19:00:58 +0000 Message-ID: <25542.1271271658@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 there are latency-sensitive dns applications (such as the web) who can't manage their routing efficiency at their application layer, and we want to add features to dns to support these applications, then the way to do this in a noncontroversial way is to make the new behaviour fully opt-in, end to end. for example, in the current proposal along these lines, if stub resolvers were required to add the new option before a full resolver (recursive dns) would behave differently, then it would just be a matter of rolling out a newer runtime (which happens very frequently for opera, firefox, explorer, safari, and konquerer, who between them represent 95% of the web market) in order to make this new feature near-universally available. if, further, a full resolver's "different behaviour" in the presence of this option included not only using a wider cache key (to given ip-range specific responses) but also the decisionmaking power to say that the client's represented IP address makes no sense (for example it's RFC 1918) and thus uses a different notion (for example, transport source address as provided by a NAT/ALG) as its cache key and as what it forwards to the authority server, then we still preserve the basic "opt-in" feature level as far as the enduser is concerned. if a browser, or stub resolver, or operating system, or NAT/ALG box, were to strip off this blob, or to add it without the user's permission, then the user would have recourse against those technology or service providers ("you are in violation of RFC XYZ, please fix your product/service") and the strippage/addage would be detectable using outside services like ICSI's. as a bonus, we could make it so that in the presence of this option (assuming that it was present in both the request and the response), rrset order was no longer incidental, and should be preserved from the authority all the way to the application. that would allow deliberate fallback/ priority to be expressed by web service operators, which has been long desired and often wrongly presumed. the option blob would ideally include more than just the client ip address (which might be useless or pessimal for predicting web performance anyway) and should contain a UUID for the enduser, their preferred human language, their GPS coordinates if known, their directional vector if mobile, and room for expansion within the blob if more ideas come later. in other words if we're going to do this at all, let's really do it right. i can write a -00 i-d along these lines if there's general interest in it. From owner-namedroppers@ops.ietf.org Wed Apr 14 12:36:07 2010 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 34E7C3A68C3; Wed, 14 Apr 2010 12:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=-1.443, BAYES_50=0.001, J_CHICKENPOX_33=0.6] 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 u1tfRp7FDoTz; Wed, 14 Apr 2010 12:36:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CCBDE3A6774; Wed, 14 Apr 2010 12:36:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O28Ih-000PXe-SC for namedroppers-data0@psg.com; Wed, 14 Apr 2010 19:31:03 +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.71 (FreeBSD)) (envelope-from ) id 1O28Ie-000PXQ-En for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 19:31:00 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 30F5EA1F6D for ; Wed, 14 Apr 2010 19:31:00 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: [dnsext] open issues on SHADOW X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Wed, 14 Apr 2010 19:31:00 +0000 Message-ID: <26794.1271273460@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: in INTERNET-DRAFT , i wrote: > 4. Open Issues > > 4.1. Using a different default origin and then not touching fully- > qualified names is weak. It plays especially poorly with fully > dynamic zone content or database back ends. We either need to tail- > replace the Amber apex with each Shadow apex, or we need to add new > signalling somehow. > > 4.2. Not allowing updates on shadows is weak. We should probably > just outlaw the use of Shadow names within zone content, and do the > substitution of Shadow apex by Amber apex. Note that this gets messy > if the update came with its own DNSSEC metadata for the new or > modified RRsets. > > 4.3. Doing full Shadow regeneration after each UPDATE is weak. We > need to figure out some way to, um, shadow the updates. This gets > messy if DNSSEC is involved and if the signer is external to the > primary master server (like if there are offline keys). > > 4.4. The Security Considerations section is empty, which seems wrong. let's take these one at a time. 4.1: as andreas pointed out, the problem identified in 4.1 produces an unfortunate dependency on "master file format", and it's generally known that a lot of zones are stored in database form, where there is not nec'ily an opportunity to fully qualify names at time of zone loading (since there is no loading.) i've been trying to think of a "new signalling" mechanism that would allow an Amber zone to contain names in RDATA that are sometimes tail-replaced with the Shadow zone (so, NS.VIX.COM may become NS.VIXIE.COM) but are sometimes not (so, sometimes an NS.VIX.COM remains NS.VIX.COM even in the Shadow zone.) it's noteworthy that the signalling that would control this does not appear on the wire -- Shadow zones are generated on the primary master server that the contents of transfers and queries are only of the generated content. as such, i think that any "database backend" nameserver implementation can simply invent its own signalling for this case, and that in the specification for SHADOW we can talk only about master file format since that's what RFC 1035 specifies. along those lines, i think that we can extend master file format to say that an extra dot on a name makes it fully qualified and also immune to Shadow zone transformation. so in my above example, "NS.VIX.COM." in an Amber zone master file would become "NS.VIX.COM." in the Amber zone but "NS.VIXIE.COM." in the shadow zone, whereas "NS.VIX.COM.." in the would become "NS.VIX.COM." in both the Amber and Shadow zones. objections and dunce caps welcome. 4.2: upon reflection i am inclined to just remove 4.2 and have it be that updates really have to take place on Amber zones, never Shadow zones. ideas on how to express substitutable vs. nonsubstitutable tail-domain's inside an UPDATE, which means a wire-visible protocol difference, would be interesting. however, i don't see this problem as worthy of the complexity required by any imaginable solution. objections to dismissing the concern and removing 4.2 should be accompanied by simple ideas of how to implement UPDATE on a Shadow zone. 4.3: upon reflection, the document overspecifies by saying "regenerate all Shadows on every UPDATE to the Amber zone." what the document should say is that the externally visible effect must be the same as if such regeneration had been done. implementors are free to either burn a lot of resources doing it the hard way, or do UPDATE propagation from an Amber zone to its Shadows in some way that respects the signalling indicated in my "4.1" comments above. any objections to removing 4.3 and changing the text to indicate the desired wire-visible result rather than mandating the activities that produce that result, should be accompanied by better motivation than i gave in "4.3" above. 4.4: the only security consideration that comes to mind is to remind folks that they have to utterly and completely trust their secondary name server operators, but that seems like spoon-fed pap. everybody should already know this. what else can somebody think of, as a serious security concern about SHADOW? From examiners0@ignitionfilms.com Wed Apr 14 12:44:04 2010 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 2D18528C10B for ; Wed, 14 Apr 2010 12:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -66.074 X-Spam-Level: X-Spam-Status: No, score=-66.074 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, PLING_QUERY=1.39, 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, SARE_RECV_SPAM_DOMN02=1.666, STOX_REPLY_TYPE=0.001, 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 uMvG-tbXSo8M for ; Wed, 14 Apr 2010 12:44:03 -0700 (PDT) Received: from 201-27-197-87.dsl.telesp.net.br (201-27-197-87.dsl.telesp.net.br [201.27.197.87]) by core3.amsl.com (Postfix) with ESMTP id B086928C0EC for ; Wed, 14 Apr 2010 12:44:02 -0700 (PDT) Received: from 201.27.197.87 by fltr-in1.mail.dreamhost.com; Wed, 14 Apr 2010 16:43:53 -0300 Date: Wed, 14 Apr 2010 16:43:53 -0300 From: dnsext-archive@lists.ietf.org Subject: Why we stopped our communication? I expected more, Olga! To: Message-ID: <000d01cadc0a$d080dc10$6400a8c0@examiners0> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal You don't have to change your life around just to get time to meet someone. There are over 7 million members on sexywebdating's online community. Hell in my state alone there are close to 200 THOUSAND active members meeting their perfect match 24 hours 7 days a week inside this tight knit match making heaven. http://regurgitate681.spaces.live.com Tammie, California From owner-namedroppers@ops.ietf.org Wed Apr 14 12:45:38 2010 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 B25D428C10E; Wed, 14 Apr 2010 12:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.4 X-Spam-Level: X-Spam-Status: No, score=-99.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, 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 mH6BFzO3Zk-R; Wed, 14 Apr 2010 12:45:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE94E28C112; Wed, 14 Apr 2010 12:45:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O28TJ-0001UH-3l for namedroppers-data0@psg.com; Wed, 14 Apr 2010 19:42:01 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O28TG-0001Tg-W7 for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 19:41:59 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:64:217:f2ff:fee0:a91f]) (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 84148E83C8; Wed, 14 Apr 2010 19:41:58 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Wed, 14 Apr 2010 12:41:57 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] matching begin/end SOA in AXFR In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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 Wed, 14 Apr 2010 08:28:18 -0400, Edward Lewis wrote: > Are you unclear on the original specification or is it that major > implementations differ from the specification? It was primarily about unclear on the specification, but at that point I wasn't aware of the "original specification" in RFC1034 (I only checked RFC1035 for a relevant "original" spec, unsuccessfully): > Looking at RFC 1034, s4.3.5: > > "The first and last messages must contain the data for the top > authoritative node of the zone." > > and in 6.3: [...] > From these two passages, I take it that the SOA is needed and is to > be the same. Now, the "top authoritative node of the zone" could > mean all apex records (those owned by the name with the SOA - the NS, > DNSSEC stuff, ...). Is the question that the "clarify" is changing > this by stating specifically just the SOA RR? No, I just didn't know the statement of axfr-clarify draft in question came from this part of RFC1034. With this reference the meaning of "same" is clearer. > I thought about this after my last reply. Maybe the very next SOA > seen (different owner, different serial number, same...) should "end" > the transfer and if the SOA isn't the "same" then the transfer is > considered a failure. That's what I would do for a newer implementation if I chose to "do something" about the SOA mismatch case. Thanks, --- JINMEI, Tatuya Internet Systems Consortium, Inc. From owner-namedroppers@ops.ietf.org Wed Apr 14 12:54:11 2010 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 B97BA28C14B; Wed, 14 Apr 2010 12:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.134 X-Spam-Level: X-Spam-Status: No, score=0.134 tagged_above=-999 required=5 tests=[AWL=-1.230, 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 qtn+KBTx4FTR; Wed, 14 Apr 2010 12:54:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F71828C112; Wed, 14 Apr 2010 12:54:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O28bn-00036q-Re for namedroppers-data0@psg.com; Wed, 14 Apr 2010 19:50:47 +0000 Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O28bl-000358-9y for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 19:50:45 +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 9A7FD15427EB; Wed, 14 Apr 2010 20:50:41 +0100 (BST) Cc: namedroppers@ops.ietf.org Message-Id: <1B6ACFDB-E3AE-4106-8510-76FA238CC776@rfc1035.com> From: Jim Reid To: Paul Vixie In-Reply-To: <26794.1271273460@nsa.vix.com> 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] open issues on SHADOW Date: Wed, 14 Apr 2010 20:50:39 +0100 References: <26794.1271273460@nsa.vix.com> 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 14 Apr 2010, at 20:31, Paul Vixie wrote: > what else can somebody think of, as a serious security concern about > SHADOW? DoS attacks on the slave? You rightly mentioned master servers trusting their slave operators. Though I'm not if this has ever been written down somewhere. But what about slaves trusting the master? Suppose an evil master server provisions a bazillion shadow zones to take out some slave. I'm thinking here of cases where the victim is hosting other, more important zones as well as the evil master's zone and its shadows. Perhaps there should be an opcode for signalling "this is too many shadow zones" or something like that? From owner-namedroppers@ops.ietf.org Wed Apr 14 13:02:12 2010 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 91B6E3A6801; Wed, 14 Apr 2010 13:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.182 X-Spam-Level: X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[AWL=-0.218, 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 3HP6bc7+ilV6; Wed, 14 Apr 2010 13:02:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E58A63A67D2; Wed, 14 Apr 2010 13:02:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O28hq-0004Ip-5l for namedroppers-data0@psg.com; Wed, 14 Apr 2010 19:57:02 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O28hn-0004IN-0Q for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 19:56:59 +0000 Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id DA4001ECB533 for ; Wed, 14 Apr 2010 19:56:57 +0000 (UTC) Date: Wed, 14 Apr 2010 15:56:51 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] matching begin/end SOA in AXFR Message-ID: <20100414195650.GE18195@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.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, Apr 14, 2010 at 12:41:57PM -0700, JINMEI Tatuya / 神明達哉 wrote: > > No, I just didn't know the statement of axfr-clarify draft in question > came from this part of RFC1034. With this reference the meaning of > "same" is clearer. Does this suggest a clarifying reference maybe ought to be added to the draft? That's certainly easy enough to add even at this late stage. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Apr 14 13:15:13 2010 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 3A5993A69F2; Wed, 14 Apr 2010 13:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=-0.922, BAYES_40=-0.185, 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 10s+iQCzxm7J; Wed, 14 Apr 2010 13:15:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B61928B56A; Wed, 14 Apr 2010 13:13:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O28tT-0006e0-Bs for namedroppers-data0@psg.com; Wed, 14 Apr 2010 20:09:03 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O28tQ-0006dZ-Fc for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 20:09:00 +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 o3EK8esV001092; Wed, 14 Apr 2010 13:08:40 -0700 (PDT) References: <25542.1271271658@nsa.vix.com> In-Reply-To: <25542.1271271658@nsa.vix.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Date: Wed, 14 Apr 2010 13:08:40 -0700 To: Paul Vixie X-Mailer: Apple Mail (2.1078) 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: Uhh, why? We already have a model that actually WORKS, and is shown to work: you = don't need end-to-end behavior or changes to handle latency sensitive = applications already, you simply have to have a reasonably good = understanding that "users behind resolver X are on network Y, because = resolver X is affiliated with network Y". I know you hate this on a near religious ground, and it is based on a = very ugly assumption, but it does WORK. =20 Adding in more detail might help a little, but only at the edges, since = almost all of the win is simply identifying network provider Y (or for a = national ISP, what region of the nation within Y), not where the user is = in detail in Y's network.=20 And measure for yourself: what is the latency to www.bing.com, = www.yahoo.com, and www.google.com, when you use your network's resolver = and the result from Google Public DNS? All three play these DNS games on the authority side to various degrees. And the only major case where this doesn't work is when the user wishes = to use resolver Z, which is not affiliated with network Y. Thus requiring the stub resolver to change FIRST is really a polite way = of saying "kill this alltogether", because you know and I know that such = extensions aren't going to happen. Furthermore, this option is useful when the stub resolver has already = opted in to using resolver Z: should clients have to opt-in TWICE? = Should ALL clients change just so the few who don't want to use their = ISP provided resolvers will see benefit? (because the only way the = stubs will change is if ALL of a large set change, not just those who = would receive benefit) Finally, clients actually have very poor notions of where they are in = network space, thanks to NATs, tunnels, etc. Far better to have the = resolver identify where the client is in network space, as they = implicitly do in most cases anyway. And if you want to encode MORE information about the client in an = app-dependent manner beyond where they are in the network topology = space, simply add garbage within the intermediate domains (eg, = hey.i.am.at.1947.center.street.amazon.com) and thus only the final = authority and the client applications have to do anything about it, and = no protocol changes are required. From owner-namedroppers@ops.ietf.org Wed Apr 14 14:01:57 2010 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 2E2D53A6A6A; Wed, 14 Apr 2010 14:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.052 X-Spam-Level: ** X-Spam-Status: No, score=2.052 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 K6sVv3eB7bda; Wed, 14 Apr 2010 14:01:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3BFB53A68B7; Wed, 14 Apr 2010 14:01:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O29ea-000H1R-QB for namedroppers-data0@psg.com; Wed, 14 Apr 2010 20:57:44 +0000 Received: from [209.85.218.212] (helo=mail-bw0-f212.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O29eY-000H10-E7 for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 20:57:42 +0000 Received: by bwz4 with SMTP id 4so646999bwz.19 for ; Wed, 14 Apr 2010 13:57:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.49.15 with HTTP; Wed, 14 Apr 2010 13:57:39 -0700 (PDT) In-Reply-To: <25542.1271271658@nsa.vix.com> References: <25542.1271271658@nsa.vix.com> Date: Wed, 14 Apr 2010 13:57:39 -0700 Received: by 10.103.4.25 with SMTP id g25mr4522280mui.59.1271278660093; Wed, 14 Apr 2010 13:57:40 -0700 (PDT) Message-ID: Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Paul Vixie , IETF DNSEXT WG 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, Apr 14, 2010 at 12:00 PM, Paul Vixie wrote: > for example, in the current proposal along these lines, if stub resolvers > were required to add the new option before a full resolver (recursive dns= ) > would behave differently, then it would just be a matter of rolling out a > newer runtime (which happens very frequently for opera, firefox, explorer= , > safari, and konquerer, who between them represent 95% of the web market) > in order to make this new feature near-universally available. Surely hiding the option in the code of browsers is less privacy and user friendly than people simply choosing the resolvers they use? > as a bonus, we could make it so that in the presence of this option > (assuming that it was present in both the request and the response), rrse= t > order was no longer incidental, and should be preserved from the authorit= y > all the way to the application. =A0that would allow deliberate fallback/ > priority to be expressed by web service operators, which has been long > desired and often wrongly presumed. Another attempt at RFC3484? why not simply rewrite web browsers to use _http SRV ? > the option blob would ideally include more than just the client ip addres= s > (which might be useless or pessimal for predicting web performance anyway= ) > and should contain a UUID for the enduser, their preferred human language= , > their GPS coordinates if known, their directional vector if mobile, and > room for expansion within the blob if more ideas come later. =A0in other > words if we're going to do this at all, let's really do it right. Based on discussion on this list, I think it would also need to include the possibility that the user and client does not reside on this planet. So, GPS may not suffice :) --=20 Colm From owner-namedroppers@ops.ietf.org Wed Apr 14 14:16:12 2010 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 59BBB28C14E; Wed, 14 Apr 2010 14:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.354 X-Spam-Level: X-Spam-Status: No, score=-102.354 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 SJ2o2u2rk5Fc; Wed, 14 Apr 2010 14:16:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 40C5828C16A; Wed, 14 Apr 2010 14:13:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O29pi-000JBa-2l for namedroppers-data0@psg.com; Wed, 14 Apr 2010 21:09:14 +0000 Received: from [2001:4f8:3:36::28] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O29pf-000JBG-NL for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 21:09:11 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id EBFD417D1DD; Wed, 14 Apr 2010 21:09:10 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [IPv6:2001:470:b8d7:13:21d:4fff:fe47:6790]) (using SSLv3 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTPSA id 423E917D19F; Wed, 14 Apr 2010 21:09:09 +0000 (UTC) Message-ID: <4BC62EF5.70106@isc.org> Date: Wed, 14 Apr 2010 16:09:09 -0500 From: Michael Graff User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= CC: IETF DNSEXT WG Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? References: <25542.1271271658@nsa.vix.com> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 2010-04-14 3:57 PM, Colm MacCrthaigh wrote: > Based on discussion on this list, I think it would also need to > include the possibility that the user and client does not reside on > this planet. So, GPS may not suffice :) Ironically enough, I have issued DNS queries from space. Well, I wasn't in space, but the CPU running the code was. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvGLvUACgkQ+NNi0s9NRJ3bYACfWiQn2trkm0e9xNorw2WuCybV 7rEAoKO0GDvm0g0Y/9UZUUt00X0Kfonc =dQY/ -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Wed Apr 14 14:17:12 2010 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 3020B28C1BC; Wed, 14 Apr 2010 14:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.393 X-Spam-Level: X-Spam-Status: No, score=0.393 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 RaT+7AuPI5iX; Wed, 14 Apr 2010 14:17:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B88628C1E8; Wed, 14 Apr 2010 14:15:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O29sD-000JbJ-Kx for namedroppers-data0@psg.com; Wed, 14 Apr 2010 21:11:49 +0000 Received: from [209.85.222.173] (helo=mail-pz0-f173.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O29sB-000Jao-4X for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 21:11:47 +0000 Received: by pzk3 with SMTP id 3so596870pzk.26 for ; Wed, 14 Apr 2010 14:11:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Wed, 14 Apr 2010 14:11:45 -0700 (PDT) In-Reply-To: References: <25542.1271271658@nsa.vix.com> Date: Wed, 14 Apr 2010 14:11:45 -0700 Received: by 10.114.21.15 with SMTP id 15mr4362381wau.156.1271279506017; Wed, 14 Apr 2010 14:11:46 -0700 (PDT) Message-ID: Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? From: Matthew Dempsky To: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= Cc: IETF DNSEXT WG 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: 2010/4/14 Colm MacC=E1rthaigh : > Another attempt at RFC3484? why not simply rewrite web browsers to use > _http SRV ? I don't think SRV handles localized resources any better than A records do now. They add priority and weighting and alternate ports, but none of those help guide users to the geographically nearest server. From owner-namedroppers@ops.ietf.org Wed Apr 14 14:55:16 2010 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 0541028C117; Wed, 14 Apr 2010 14:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=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 0w7IazsUQfWx; Wed, 14 Apr 2010 14:55:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DAB4428C127; Wed, 14 Apr 2010 14:55:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2AUi-00023y-IQ for namedroppers-data0@psg.com; Wed, 14 Apr 2010 21:51:36 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2AUb-0001ou-An for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 21:51:34 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o3ELnaDW005247; Wed, 14 Apr 2010 21:49:46 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o3ELnP99005246; Wed, 14 Apr 2010 21:49:25 GMT Date: Wed, 14 Apr 2010 21:49:25 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= , IETF DNSEXT WG Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Message-ID: <20100414214925.GE3766@vacation.karoshi.com.> References: <25542.1271271658@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i 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, Apr 14, 2010 at 02:11:45PM -0700, Matthew Dempsky wrote: > 2010/4/14 Colm MacCarthaigh : > > Another attempt at RFC3484? why not simply rewrite web browsers to use > > _http SRV ? > > I don't think SRV handles localized resources any better than A > records do now. They add priority and weighting and alternate ports, > but none of those help guide users to the geographically nearest > server. > just for fun... many moons ago, there was much hue and cry over the fact that a law office in a building in Seattle had nearly 800ms latency to the partner firm one floor down. Seems they used different ISPs, different long-haul carriers, and the only place these two peered was someplace in Northern Europe. (a canonical argument for local peering, e.g. exchange points). I suspect that geographic proximity is not really what you are after... I think topological proximity might be a better first metric. --bill From owner-namedroppers@ops.ietf.org Wed Apr 14 15:05:53 2010 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 DE1E53A685A; Wed, 14 Apr 2010 15:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.665 X-Spam-Level: ** X-Spam-Status: No, score=2.665 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_50=0.001, 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 ERUbfg6pPeLx; Wed, 14 Apr 2010 15:05:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F11C23A68EE; Wed, 14 Apr 2010 15:05:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2AeU-0003rS-W3 for namedroppers-data0@psg.com; Wed, 14 Apr 2010 22:01:42 +0000 Received: from [209.85.211.194] (helo=mail-yw0-f194.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2AeS-0003r8-EF for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 22:01:40 +0000 Received: by ywh32 with SMTP id 32so283567ywh.33 for ; Wed, 14 Apr 2010 15:01:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Wed, 14 Apr 2010 15:01:36 -0700 (PDT) In-Reply-To: <20100414214925.GE3766@vacation.karoshi.com.> References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> Date: Wed, 14 Apr 2010 15:01:36 -0700 Received: by 10.101.126.3 with SMTP id d3mr14335987ann.92.1271282496638; Wed, 14 Apr 2010 15:01:36 -0700 (PDT) Message-ID: Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? From: Matthew Dempsky To: bmanning@vacation.karoshi.com Cc: IETF DNSEXT WG 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: > =A0 =A0 =A0 =A0I suspect that geographic proximity is not really what you > =A0 =A0 =A0 =A0are after... I think topological proximity might be a bett= er > =A0 =A0 =A0 =A0first metric. Right, I had already meant "geographically nearest" in the abstract sense, but I realize now "topologically nearest" would have been a better phrase to use. Sorry for any confusion. From owner-namedroppers@ops.ietf.org Wed Apr 14 15:46:56 2010 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 CC1FB3A67D1; Wed, 14 Apr 2010 15:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.812 X-Spam-Level: X-Spam-Status: No, score=0.812 tagged_above=-999 required=5 tests=[AWL=-1.293, BAYES_50=0.001, 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 OkISdHBfUJ0Q; Wed, 14 Apr 2010 15:46:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D5523A693E; Wed, 14 Apr 2010 15:46:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2BIg-000Azb-BC for namedroppers-data0@psg.com; Wed, 14 Apr 2010 22:43:14 +0000 Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2BId-000AzN-Pg for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 22:43:12 +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 4545615427EB; Wed, 14 Apr 2010 23:43:09 +0100 (BST) Cc: bmanning@vacation.karoshi.com, IETF DNSEXT WG Message-Id: <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> From: Jim Reid To: Matthew Dempsky In-Reply-To: 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] add support for latency-sensitive dns applications such as the web? Date: Wed, 14 Apr 2010 23:43:07 +0100 References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> 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 14 Apr 2010, at 23:01, Matthew Dempsky wrote: > Right, I had already meant "geographically nearest" in the abstract > sense, but I realize now "topologically nearest" would have been a > better phrase to use. Sorry for any confusion. Either could be valid, depending on the circumstances and use case. As a for instance, wi-fi on the train between Scotland and London goes through some Swedish ISP. [No, I don't understand this either...] That means I get to browse the ad-splattered version of the BBC web site rather than the ad-free one enjoyed by the customers of UK ISPs. Those customers presumably pay the TV licence fee that funds the BBC and should get free access to all the BBC's services. And the BBC only has UK Internet rights for some of that content. So I don't get to see or listen to some stuff I should be able to get while on the train. For this case, if stupid DNS tricks were used, I'd want them to be using a metric of "geographically nearest" (if such a thing was viable) instead of "topologically nearest". That way I might be able to signal to the web server or the train's resolver that I was in the UK even if the network thought I wasn't. IMO DNS is not the place to solve these sorts of irritants because they should be something for the web server and browser to work out betweem themselves. From owner-namedroppers@ops.ietf.org Wed Apr 14 15:54:50 2010 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 9FC933A67AD; Wed, 14 Apr 2010 15:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.671 X-Spam-Level: ** X-Spam-Status: No, score=2.671 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_50=0.001, 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 TRTpxOYWFqFw; Wed, 14 Apr 2010 15:54:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3FB3C3A68BE; Wed, 14 Apr 2010 15:54:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2BQc-000COu-BH for namedroppers-data0@psg.com; Wed, 14 Apr 2010 22:51:26 +0000 Received: from [209.85.211.194] (helo=mail-yw0-f194.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2BQZ-000COW-Qq for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 22:51:23 +0000 Received: by ywh32 with SMTP id 32so314320ywh.33 for ; Wed, 14 Apr 2010 15:51:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Wed, 14 Apr 2010 15:51:20 -0700 (PDT) In-Reply-To: <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> Date: Wed, 14 Apr 2010 15:51:20 -0700 Received: by 10.101.175.15 with SMTP id c15mr10087655anp.59.1271285480490; Wed, 14 Apr 2010 15:51:20 -0700 (PDT) Message-ID: Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? From: Matthew Dempsky To: Jim Reid Cc: bmanning@vacation.karoshi.com, IETF DNSEXT WG 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, Apr 14, 2010 at 3:43 PM, Jim Reid wrote: > On 14 Apr 2010, at 23:01, Matthew Dempsky wrote: > >> Right, I had already meant "geographically nearest" in the abstract >> sense, but I realize now "topologically nearest" would have been a >> better phrase to use. =A0Sorry for any confusion. > > Either could be valid, depending on the circumstances and use case. Clarifying again, I meant "topologically" in the mathematical sense; i.e., abstracting away from any particular topology such as either "network topology" or "geographic topology". From owner-namedroppers@ops.ietf.org Wed Apr 14 16:19:29 2010 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 CC12E3A6ACC; Wed, 14 Apr 2010 16:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 OaHLozik1s9P; Wed, 14 Apr 2010 16:19:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 571E93A6AB3; Wed, 14 Apr 2010 16:19:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Bmz-000GyW-Vv for namedroppers-data0@psg.com; Wed, 14 Apr 2010 23:14:33 +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.71 (FreeBSD)) (envelope-from ) id 1O2Bmx-000GyG-Nr for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 23:14:31 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 2B3A5A1FCB for ; Wed, 14 Apr 2010 23:14:31 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? In-Reply-To: Your message of "Wed, 14 Apr 2010 21:49:25 GMT." <20100414214925.GE3766@vacation.karoshi.com.> References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Wed, 14 Apr 2010 23:14:31 +0000 Message-ID: <42609.1271286871@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: Wed, 14 Apr 2010 21:49:25 +0000 > From: bmanning@vacation.karoshi.com > ... > I suspect that geographic proximity is not really what you > are after... I think topological proximity might be a better > first metric. address similarity is by itself a poor predictor of topological proximity, even for evaluators who are holding a "full routing table". that's why my proposal is to include many attributes including geo, ip, uuid, and language, and to let the authority server decide what to do. it's possible that an authority server will want to send a response that directs tcp/80 to a low-rtt server, or, given knowledge of the end user's language and of their location and direction, may wish to send them to a server that's "better" in some other way than just "low latency". good internet engineering means not overspecifying. i should have titled my message as follows: "Subject: support for user-context-sensitive dns applications (e.g.: web)" From owner-namedroppers@ops.ietf.org Wed Apr 14 16:22:12 2010 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 CA2583A6ABF; Wed, 14 Apr 2010 16:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.229 X-Spam-Level: X-Spam-Status: No, score=-0.229 tagged_above=-999 required=5 tests=[AWL=0.266, 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 253ArIKRLHz1; Wed, 14 Apr 2010 16:22:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 000223A6AD9; Wed, 14 Apr 2010 16:22:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Bpk-000HS9-Dq for namedroppers-data0@psg.com; Wed, 14 Apr 2010 23:17:24 +0000 Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Bph-000HRi-Ud for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 23:17:22 +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 E640D15427EB; Thu, 15 Apr 2010 00:17:17 +0100 (BST) Cc: bmanning@vacation.karoshi.com, IETF DNSEXT WG Message-Id: <8381F1C3-E5E5-436E-8B3F-0B569DCA966D@rfc1035.com> From: Jim Reid To: Matthew Dempsky In-Reply-To: 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] add support for latency-sensitive dns applications such as the web? Date: Thu, 15 Apr 2010 00:17:15 +0100 References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> 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 14 Apr 2010, at 23:51, Matthew Dempsky wrote: > Clarifying again, I meant "topologically" in the mathematical sense; > i.e., abstracting away from any particular topology such as either > "network topology" or "geographic topology". OK. So we're making progress. I think. IIUC the problem is now about how to use DNS to provide answers that are topologically optimal in a mathematical sense (for some definition of these terms) that can, depending on context, apply to network or geographic topology? Or some combination of these and any other types of topology which might apply? Have I got this right? From dnsext-archive@ietf.org Wed Apr 14 16:32:14 2010 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 56AE83A6ACC for ; Wed, 14 Apr 2010 16:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.285 X-Spam-Level: X-Spam-Status: No, score=-22.285 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_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, FM_SEX_HELODDDD=10.357, FM_SEX_HOSTDDDD=10.357, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, 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, SARE_HTML_A_BODY=0.742, URIBL_AB_SURBL=10, URIBL_BLACK=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 WJ+tmsPe2sKL for ; Wed, 14 Apr 2010 16:32:13 -0700 (PDT) Received: from pool-96-245-205-69.phlapa.fios.verizon.net (pool-96-245-205-69.phlapa.fios.verizon.net [96.245.205.69]) by core3.amsl.com (Postfix) with SMTP id 31D8F3A6AD7 for ; Wed, 14 Apr 2010 16:32:06 -0700 (PDT) To: Subject: Daily updates From: Benedicto HINOJOS MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100414233207.31D8F3A6AD7@core3.amsl.com> Date: Wed, 14 Apr 2010 16:32:06 -0700 (PDT) Paris Hilton Video.
Information and links about the public scandal around Paris Hilton's alleged sex tape. From owner-namedroppers@ops.ietf.org Wed Apr 14 17:00:21 2010 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 C88873A69D7; Wed, 14 Apr 2010 17:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.092 X-Spam-Level: X-Spam-Status: No, score=-100.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, 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 mJmSllASajq1; Wed, 14 Apr 2010 17:00:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DF49F3A6452; Wed, 14 Apr 2010 17:00:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2COj-000NJw-Q3 for namedroppers-data0@psg.com; Wed, 14 Apr 2010 23:53:33 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2COe-000N9i-2c for namedroppers@ops.ietf.org; Wed, 14 Apr 2010 23:53:29 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o3ENpHDW006270; Wed, 14 Apr 2010 23:51:17 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o3ENpHDI006269; Wed, 14 Apr 2010 23:51:17 GMT Date: Wed, 14 Apr 2010 23:51:17 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: IETF DNSEXT WG Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Message-ID: <20100414235117.GA6167@vacation.karoshi.com.> References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <42609.1271286871@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42609.1271286871@nsa.vix.com> User-Agent: Mutt/1.4.1i 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, Apr 14, 2010 at 11:14:31PM +0000, Paul Vixie wrote: > > Date: Wed, 14 Apr 2010 21:49:25 +0000 > > From: bmanning@vacation.karoshi.com > > ... > > I suspect that geographic proximity is not really what you > > are after... I think topological proximity might be a better > > first metric. > > address similarity is by itself a poor predictor of topological proximity, > even for evaluators who are holding a "full routing table". that's why my I did not state or even infer address similarity was indicative of topological proximity. for topology, the best indicator is RTT. which does not seem to make your short list. perhaps it is in the "includes many attributes". > proposal is to include many attributes including geo, ip, uuid, and language, > and to let the authority server decide what to do. well - i suspect that the agony of choice is going to be this proposals undoing, UNLESS some bright bulb steps up and proposes a rank ordering .. in my case, I think that RTT for topological proximity is the first, best metric. the rest is icing. (well, except for my requested addition to this sausage of mishmashed demnads... I want a hash of the software version of the resolver handed out....) some logic will need to be agreed on as to search order for evaluating the range of options or chaos will ensue. > > it's possible that an authority server will want to send a response that > directs tcp/80 to a low-rtt server, or, given knowledge of the end user's > language and of their location and direction, may wish to send them to a > server that's "better" in some other way than just "low latency". good > internet engineering means not overspecifying. i should have titled my > message as follows: > > "Subject: support for user-context-sensitive dns applications (e.g.: web)" From owner-namedroppers@ops.ietf.org Wed Apr 14 17:08:40 2010 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 556523A6800; Wed, 14 Apr 2010 17:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=0.558, 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 xYqgHlFmmy6F; Wed, 14 Apr 2010 17:08:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E2D3B3A6452; Wed, 14 Apr 2010 17:08:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2CYs-000P89-0p for namedroppers-data0@psg.com; Thu, 15 Apr 2010 00:04:02 +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.71 (FreeBSD)) (envelope-from ) id 1O2CYo-000P6m-Tu for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 00:03:58 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 90286A1FCF; Thu, 15 Apr 2010 00:03:58 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: bmanning@vacation.karoshi.com cc: IETF DNSEXT WG Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? In-Reply-To: Your message of "Wed, 14 Apr 2010 23:51:17 GMT." <20100414235117.GA6167@vacation.karoshi.com.> References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <42609.1271286871@nsa.vix.com> <20100414235117.GA6167@vacation.karoshi.com.> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 15 Apr 2010 00:03:58 +0000 Message-ID: <47311.1271289838@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: Wed, 14 Apr 2010 23:51:17 +0000 > From: bmanning@vacation.karoshi.com > > > proposal is to include many attributes including geo, ip, uuid, and > > language, and to let the authority server decide what to do. > > well - i suspect that the agony of choice is going to be this > proposals undoing, UNLESS some bright bulb steps up and proposes a > rank ordering .. no, that would be fatal to the effort, being an overspecification. From owner-namedroppers@ops.ietf.org Wed Apr 14 17:09:39 2010 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 D6B253A684D; Wed, 14 Apr 2010 17:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.675 X-Spam-Level: ** X-Spam-Status: No, score=2.675 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_50=0.001, 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 TiCU4p0g7+7P; Wed, 14 Apr 2010 17:09:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F08EE3A6452; Wed, 14 Apr 2010 17:09:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2CZl-000PJY-HC for namedroppers-data0@psg.com; Thu, 15 Apr 2010 00:04:57 +0000 Received: from [209.85.160.180] (helo=mail-gy0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2CZi-000PJ0-PO for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 00:04:54 +0000 Received: by gyb13 with SMTP id 13so349078gyb.11 for ; Wed, 14 Apr 2010 17:04:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Wed, 14 Apr 2010 17:04:53 -0700 (PDT) In-Reply-To: <8381F1C3-E5E5-436E-8B3F-0B569DCA966D@rfc1035.com> References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <8381F1C3-E5E5-436E-8B3F-0B569DCA966D@rfc1035.com> Date: Wed, 14 Apr 2010 17:04:53 -0700 Received: by 10.231.146.144 with SMTP id h16mr3626550ibv.18.1271289893468; Wed, 14 Apr 2010 17:04:53 -0700 (PDT) Message-ID: Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? From: Matthew Dempsky To: Jim Reid Cc: IETF DNSEXT WG 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 Wed, Apr 14, 2010 at 4:17 PM, Jim Reid wrote: > On 14 Apr 2010, at 23:51, Matthew Dempsky wrote: > >> Clarifying again, I meant "topologically" in the mathematical sense; >> i.e., abstracting away from any particular topology such as either >> "network topology" or "geographic topology". > > OK. So we're making progress. I think. > > IIUC the problem is now about how to use DNS to provide answers that are > topologically optimal in a mathematical sense (for some definition of these > terms) that can, depending on context, apply to network or geographic > topology? Or some combination of these and any other types of topology which > might apply? Have I got this right? Well, I was just trying to be general in pointing out that SRV records don't support any sort of topological optimization, which as a corollary means it's insufficient for tackling the problem edns-client-ip is trying to address. But yes, there is a general problem of how to improve the topological awareness of DNS. I can readily see value in extending it to be network-topology-aware, but I'm not yet convinced there's any use in extending it beyond that. As such, I'm happy for now to adopt a simple and reasonably adequate solution to that subproblem (e.g., edns-client-ip), rather than wait for a more general (and most likely far more complex) solution. From dm@ietf.org Wed Apr 14 17:18:34 2010 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 E33DC28C17D for ; Wed, 14 Apr 2010 17:18:33 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Wed, 14 Apr 2010 17:18:32 -0700 (PDT) Received: from advest.com (unknown [62.182.64.5]) by core3.amsl.com (Postfix) with SMTP id D60C33A6AB1 for ; Wed, 14 Apr 2010 17:17:55 -0700 (PDT) From: Approved VIAGRA® Store Subject: Sales Event get 76% off To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100415001756.D60C33A6AB1@core3.amsl.com> Date: Wed, 14 Apr 2010 17:17:55 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 90269 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Wed Apr 14 20:54:02 2010 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 4625128C173; Wed, 14 Apr 2010 20:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.346 X-Spam-Level: X-Spam-Status: No, score=-101.346 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, 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 9x0Q5A-GH5H3; Wed, 14 Apr 2010 20:54:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B9B228C15C; Wed, 14 Apr 2010 20:54:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2G2K-000DSa-JX for namedroppers-data0@psg.com; Thu, 15 Apr 2010 03:46:40 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2G2F-000DK1-Ci for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 03:46:37 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o3F3iRDW007857; Thu, 15 Apr 2010 03:44:33 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o3F3iBGp007855; Thu, 15 Apr 2010 03:44:11 GMT Date: Thu, 15 Apr 2010 03:44:11 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: bmanning@vacation.karoshi.com, IETF DNSEXT WG Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Message-ID: <20100415034411.GA7600@vacation.karoshi.com.> References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <42609.1271286871@nsa.vix.com> <20100414235117.GA6167@vacation.karoshi.com.> <47311.1271289838@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47311.1271289838@nsa.vix.com> User-Agent: Mutt/1.4.1i 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, Apr 15, 2010 at 12:03:58AM +0000, Paul Vixie wrote: > > Date: Wed, 14 Apr 2010 23:51:17 +0000 > > From: bmanning@vacation.karoshi.com > > > > > proposal is to include many attributes including geo, ip, uuid, and > > > language, and to let the authority server decide what to do. > > > > well - i suspect that the agony of choice is going to be this > > proposals undoing, UNLESS some bright bulb steps up and proposes a > > rank ordering .. > > no, that would be fatal to the effort, being an overspecification. sort of like the fatal rank ordering of BGP evaluation, IPv6 soure address selection, etc. I will step back and watch this trainwreck... or see vendors "legislate from the bench" on "the" defacto packing of attributes. --bill From owner-namedroppers@ops.ietf.org Wed Apr 14 21:50:05 2010 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 A6D863A6ABD; Wed, 14 Apr 2010 21:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.541, 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 x5dLzSeKZGUT; Wed, 14 Apr 2010 21:50:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6476A3A6813; Wed, 14 Apr 2010 21:50:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2GwV-000O5q-VA for namedroppers-data0@psg.com; Thu, 15 Apr 2010 04:44:43 +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.71 (FreeBSD)) (envelope-from ) id 1O2GwS-000O5Z-Tt for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 04:44:40 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A51DDA202E for ; Thu, 15 Apr 2010 04:44:40 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? In-Reply-To: Your message of "Thu, 15 Apr 2010 00:03:27 -0400." References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <42609.1271286871@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 15 Apr 2010 04:44:40 +0000 Message-ID: <68305.1271306680@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: John Payne > Date: Thu, 15 Apr 2010 00:03:27 -0400 > > Sorry if I missed the problem statement, but are you trying to guess at > what "stupid dns tricks" are used for and why the client IP is useful in > some limited corner cases and design to that, or is this an entirely > different issue than the edns-client-subnet proposal? neither. From owner-namedroppers@ops.ietf.org Wed Apr 14 21:50:06 2010 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 999CA3A6813; Wed, 14 Apr 2010 21:50:06 -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=0.524, 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 Gih6KSCcPF7l; Wed, 14 Apr 2010 21:50:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8410C3A687C; Wed, 14 Apr 2010 21:50:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2GvY-000Nsd-4P for namedroppers-data0@psg.com; Thu, 15 Apr 2010 04:43:44 +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.71 (FreeBSD)) (envelope-from ) id 1O2GvU-000Nqz-L3 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 04:43:40 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id F421AA203D for ; Thu, 15 Apr 2010 04:43:38 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? In-Reply-To: Your message of "Thu, 15 Apr 2010 03:44:11 GMT." <20100415034411.GA7600@vacation.karoshi.com.> References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <42609.1271286871@nsa.vix.com> <20100414235117.GA6167@vacation.karoshi.com.> <47311.1271289838@nsa.vix.com> <20100415034411.GA7600@vacation.karoshi.com.> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 15 Apr 2010 04:43:38 +0000 Message-ID: <68226.1271306618@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 Apr 2010 03:44:11 +0000 > From: bmanning@vacation.karoshi.com > > > no, that would be fatal to the effort, being an overspecification. > > sort of like the fatal rank ordering of BGP evaluation, > IPv6 soure address selection, etc. nothing like those. > I will step back and > watch this trainwreck... or see vendors "legislate from the > bench" on "the" defacto packing of attributes. some web sites will care about language, others won't. some end users will send language, others won't. this is nothing like bgp tiebreaking. From beseechedv@whiskeypool.com Thu Apr 15 00:00:24 2010 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 496733A67FE for ; Thu, 15 Apr 2010 00:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -85.649 X-Spam-Level: X-Spam-Status: No, score=-85.649 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, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, 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 0Zylb5VSd8MF for ; Thu, 15 Apr 2010 00:00:23 -0700 (PDT) Received: from triband-mum-59.182.159.47.mtnl.net.in (triband-mum-59.182.159.47.mtnl.net.in [59.182.159.47]) by core3.amsl.com (Postfix) with ESMTP id CF82D3A689D for ; Thu, 15 Apr 2010 00:00:21 -0700 (PDT) Received: from 59.182.159.47 by mail.whiskeypool.com; Thu, 15 Apr 2010 12:28:10 +0530 Date: Thu, 15 Apr 2010 12:28:10 +0530 From: dnsext-archive@lists.ietf.org Subject: You are my good, my handsome - write me, I'm waiting! To: Message-ID: <000d01cadc69$024c44b0$6400a8c0@beseechedv> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal You don't have to change your life around just to get time to meet someone. There are over 7 million members on sexywebdating's online community. Hell in my state alone there are close to 200 THOUSAND active members meeting their perfect match 24 hours 7 days a week inside this tight knit match making heaven. http://smalltime8775.spaces.live.com Michele, Pennsylvania From owner-namedroppers@ops.ietf.org Thu Apr 15 01:44:45 2010 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 4751D3A6961; Thu, 15 Apr 2010 01:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.471 X-Spam-Level: X-Spam-Status: No, score=0.471 tagged_above=-999 required=5 tests=[AWL=-0.523, 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 WXe5NDZZd2+k; Thu, 15 Apr 2010 01:44:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4146C3A6956; Thu, 15 Apr 2010 01:44:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2KZL-000Jqm-IC for namedroppers-data0@psg.com; Thu, 15 Apr 2010 08:37:03 +0000 Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2KZI-000JqB-1x for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 08:37:00 +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 7541E15427EB; Thu, 15 Apr 2010 09:36:56 +0100 (BST) Cc: IETF DNSEXT WG Message-Id: From: Jim Reid To: John Payne In-Reply-To: <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> 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] add support for latency-sensitive dns applications such as the web? Date: Thu, 15 Apr 2010 09:36:55 +0100 References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> 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 15 Apr 2010, at 04:55, John Payne wrote: > And again, you are confusing server selection with content. I'm not. I think you've not been paying attention. > In most geo-restricted setups, what matters is your client IP for > content selection and localization (if there aren't any application > layer hints). > The "stupid DNS" tricks only select a server for you not the content. Which means I'm directed to whatever server is "optimal" for someone in Sweden. Which probably isn't optimal for my packets or the content I'm served. > For whatever reason, the BBC thinks that your client is in Sweden. > Try using opendns or google public dns... You'll likely get > different servers than the train ISP's resolvers return... That's not allowed: you have to use the train's resolving server. [I know this because my laptop already runs a resolving server to work around the usual hotel network brain damage.] So in this example, I'd be relying on the train's network to do the Right Thing with its stupid DNS tricks which seems unlikely. Or I'd be hoping it allowed me to add the location info of my choice to the outbound queries -- how would I know what's optimal for where the train is? -- which is even less likely. Or, if I could send location info to the resolver, it didn't "optimise" that data before making the query. Which doesn't seem likely either. From owner-namedroppers@ops.ietf.org Thu Apr 15 02:26:00 2010 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 6B3483A6885; Thu, 15 Apr 2010 02:26:00 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.683 X-Spam-Level: ** X-Spam-Status: No, score=2.683 tagged_above=-999 required=5 tests=[AWL=-1.466, BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 BuG5svG51v13; Thu, 15 Apr 2010 02:25:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C43053A6941; Thu, 15 Apr 2010 02:25:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2LDe-0002gG-2a for namedroppers-data0@psg.com; Thu, 15 Apr 2010 09:18:42 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2LDa-0002eB-M5 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 09:18:39 +0000 Received: (eyou send program); Thu, 15 Apr 2010 17:18:37 +0800 Message-ID: <471323117.21296@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 15 Apr 2010 17:18:37 +0800 Message-ID: <451D7DB04B81453799CB4C53265F13FA@LENOVO47E041CF> From: "YAO Jiankang" To: Subject: [dnsext] Unsigned Synthesized CNAME issues in dname-bis draft Date: Thu, 15 Apr 2010 17:18:42 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" 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: aW4gc2VjdGlvbiAgNS4zLjEuICBTaWduZWQgRE5BTUUsIFVuc2lnbmVkIFN5bnRoZXNpemVkIENO QU1FIG9mIGRyYWZ0IGRyYWZ0LWlldGYtZG5zZXh0LXJmYzI2NzJiaXMtZG5hbWUtMTg6DQoNCiAg SW4gYW55IHJlc3BvbnNlLCBhIHNpZ25lZCBETkFNRSBSUiBpbmRpY2F0ZXMgYSBub24tdGVybWlu YWwNCiAgIHJlZGlyZWN0aW9uIG9mIHRoZSBxdWVyeS4gIFRoZXJlIG1pZ2h0IG9yIG1pZ2h0IG5v dCBiZSBhIHNlcnZlcg0KICAgc3ludGhlc2l6ZWQgQ05BTUUgaW4gdGhlIGFuc3dlciBzZWN0aW9u OyBpZiB0aGVyZSBpcywgdGhlIENOQU1FIHdpbGwNCiAgIG5ldmVyIGJlIHNpZ25lZC4NCg0KY291 bGQgSSBzdWdnZXN0IHRvIA0KDQpjaGFuZ2UgImlmIHRoZXJlIGlzLCB0aGUgQ05BTUUgd2lsbCBu ZXZlciBiZSBzaWduZWQuIg0KDQp0byB0aGUgZm9sbG93ICJpZiB0aGVyZSBpcywgdGhlIENOQU1F IG1heSAoc2hvdWxkKSBiZSBzaWduZWQgaWYgdGhlIG9ubGluZSBzaWduaW5nIGlzIHN1cHBvcnRl ZCBvbiB0aGUgc2VydmVyLiIgPw0KDQp3ZSBjYW4gZG8gaXQgb3Igbm90Pw0KDQoNCg0KSmlhbmth bmcgWWFv From owner-namedroppers@ops.ietf.org Thu Apr 15 03:25:11 2010 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 DFF2D3A6AE6; Thu, 15 Apr 2010 03:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.005 X-Spam-Level: X-Spam-Status: No, score=-96.005 tagged_above=-999 required=5 tests=[AWL=-0.255, 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, 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 t5XWZL6zP906; Thu, 15 Apr 2010 03:25:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 51B9D3A6B8A; Thu, 15 Apr 2010 03:24:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2M8b-000FJq-PE for namedroppers-data0@psg.com; Thu, 15 Apr 2010 10:17:33 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2M8Y-000FIX-12 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 10:17:30 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA193486608; Thu, 15 Apr 2010 12:16:48 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA22295; Thu, 15 Apr 2010 12:16:46 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004151016.MAA22295@TR-Sys.de> Subject: Re: [dnsext] matching begin/end SOA in AXFR To: ajs@shinkuro.com, ed.lewis@neustar.biz Date: Thu, 15 Apr 2010 12:16:46 +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: Andrew Sullivan wrote: > On Wed, Apr 14, 2010 at 12:41:57PM -0700, JINMEI Tatuya wrote: >> >> No, I just didn't know the statement of axfr-clarify draft in question >> came from this part of RFC1034. With this reference the meaning of >> "same" is clearer. > > Does this suggest a clarifying reference maybe ought to be added to > the draft? That's certainly easy enough to add even at this late stage. > > A I run entirely out of IETF time this week and did not have the time yet to follow this thread in detail. Will do next weekend and come up with a more precise proposal (to change or not to change ...). Basically, the bulk of Section 1.4 once had been added to axfr-clarify just to point to _all_ text related to AXFR that I was able to locate in both RFC 1034 and RFC 1035. Section 4.3.5 of RFC 1034 and Section 6.3 of RFC 1035 are both called out in the second paragraph of Section 1.4 of the draft. Kind regards, Alfred. From offings@law-service.ru Thu Apr 15 03:36:15 2010 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 654653A67F5; Thu, 15 Apr 2010 03:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.247 X-Spam-Level: X-Spam-Status: No, score=-69.247 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_CHARTER=2.175, 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, HOST_EQ_CHARTER=1.295, HOST_EQ_DHCP=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, 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 37SJSDswEMZo; Thu, 15 Apr 2010 03:36:14 -0700 (PDT) Received: from 75-131-228-166.dhcp.slid.la.charter.com (75-131-228-166.dhcp.slid.la.charter.com [75.131.228.166]) by core3.amsl.com (Postfix) with ESMTP id 621C03A65A6; Thu, 15 Apr 2010 03:36:08 -0700 (PDT) Received: from 75.131.228.166 by relay.valuehost.ru; Thu, 15 Apr 2010 05:35:10 -0600 Date: Thu, 15 Apr 2010 05:35:10 -0600 From: dnsext-archive@ietf.org Subject: Meet that special someone today To: Message-ID: <000d01cadc87$52cf6660$6400a8c0@offings> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Meet that special someone today. It costs you nothing to check it out. All you have to do is press this web link and you'll be chatting with someone in no time. http://genotype0802.spaces.live.com From dnsop-bounces@ietf.org Thu Apr 15 03:36:17 2010 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98FA3A65A6 for ; Thu, 15 Apr 2010 03:36:17 -0700 (PDT) Subject: The results of your email commands From: dnsop-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1699332315==" Message-ID: Date: Thu, 15 Apr 2010 03:36:16 -0700 Precedence: bulk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF DNSOP WG mailing list X-List-Administrivia: yes Sender: dnsop-bounces@ietf.org Errors-To: dnsop-bounces@ietf.org --===============1699332315== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://genotype0802.spaces.live.com - Done. --===============1699332315== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: dnsop-request@core3.amsl.com Delivered-To: dnsop-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654653A67F5; Thu, 15 Apr 2010 03:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.247 X-Spam-Level: X-Spam-Status: No, score=-69.247 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_CHARTER=2.175, 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, HOST_EQ_CHARTER=1.295, HOST_EQ_DHCP=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, 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 37SJSDswEMZo; Thu, 15 Apr 2010 03:36:14 -0700 (PDT) Received: from 75-131-228-166.dhcp.slid.la.charter.com (75-131-228-166.dhcp.slid.la.charter.com [75.131.228.166]) by core3.amsl.com (Postfix) with ESMTP id 621C03A65A6; Thu, 15 Apr 2010 03:36:08 -0700 (PDT) Received: from 75.131.228.166 by relay.valuehost.ru; Thu, 15 Apr 2010 05:35:10 -0600 Date: Thu, 15 Apr 2010 05:35:10 -0600 From: dnsext-archive@ietf.org Subject: Meet that special someone today To: Message-ID: <000d01cadc87$52cf6660$6400a8c0@offings> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Meet that special someone today. It costs you nothing to check it out. All you have to do is press this web link and you'll be chatting with someone in no time. http://genotype0802.spaces.live.com --===============1699332315==-- From offings@law-service.ru Thu Apr 15 03:36:15 2010 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 654653A67F5; Thu, 15 Apr 2010 03:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.247 X-Spam-Level: X-Spam-Status: No, score=-69.247 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_CHARTER=2.175, 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, HOST_EQ_CHARTER=1.295, HOST_EQ_DHCP=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, 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 37SJSDswEMZo; Thu, 15 Apr 2010 03:36:14 -0700 (PDT) Received: from 75-131-228-166.dhcp.slid.la.charter.com (75-131-228-166.dhcp.slid.la.charter.com [75.131.228.166]) by core3.amsl.com (Postfix) with ESMTP id 621C03A65A6; Thu, 15 Apr 2010 03:36:08 -0700 (PDT) Received: from 75.131.228.166 by relay.valuehost.ru; Thu, 15 Apr 2010 05:35:10 -0600 Date: Thu, 15 Apr 2010 05:35:10 -0600 From: dnsext-archive@ietf.org Subject: Meet that special someone today To: Message-ID: <000d01cadc87$52cf6660$6400a8c0@offings> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Meet that special someone today. It costs you nothing to check it out. All you have to do is press this web link and you'll be chatting with someone in no time. http://genotype0802.spaces.live.com From owner-namedroppers@ops.ietf.org Thu Apr 15 04:38:44 2010 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 C8A2C3A6901; Thu, 15 Apr 2010 04:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.881 X-Spam-Level: X-Spam-Status: No, score=0.881 tagged_above=-999 required=5 tests=[AWL=-0.783, 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 FPpNDsynpzDY; Thu, 15 Apr 2010 04:38:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4080A3A68C1; Thu, 15 Apr 2010 04:38:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2NK4-0004bF-FA for namedroppers-data0@psg.com; Thu, 15 Apr 2010 11:33:28 +0000 Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2NK1-0004an-CD for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 11:33:25 +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 9FFC315427EB; Thu, 15 Apr 2010 12:33:22 +0100 (BST) Cc: Paul Vixie , IETF DNSEXT WG Message-Id: From: Jim Reid To: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= In-Reply-To: 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: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Date: Thu, 15 Apr 2010 12:33:21 +0100 References: <25542.1271271658@nsa.vix.com> 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 14 Apr 2010, at 21:57, Colm MacC=E1rthaigh wrote: > Surely hiding the option in the code of browsers is less privacy and > user friendly than people simply choosing the resolvers they use? Colm, I just don't get it. Sorry. If a web server/browser needs =20 location or language info or whatever for some reason, surely the =20 sensible place to configure that info is in the web software, not the =20= DNS? To rephrase the old joke about DEC Field Service, would you =20 change a car's battery because the tyres were flat?= From owner-namedroppers@ops.ietf.org Thu Apr 15 04:55:37 2010 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 B95AF28C189; Thu, 15 Apr 2010 04:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.763 X-Spam-Level: X-Spam-Status: No, score=-101.763 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, 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 9ZsBO9WHzZ11; Thu, 15 Apr 2010 04:55:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DBF9728C18A; Thu, 15 Apr 2010 04:54:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2NaA-0008GK-N6 for namedroppers-data0@psg.com; Thu, 15 Apr 2010 11:50:06 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Na4-00081q-Kg for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 11:50:03 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o3FBlwDW012896; Thu, 15 Apr 2010 11:48:03 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o3FBlwBR012895; Thu, 15 Apr 2010 11:47:58 GMT Date: Thu, 15 Apr 2010 11:47:58 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: IETF DNSEXT WG Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Message-ID: <20100415114758.GA12836@vacation.karoshi.com.> References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <42609.1271286871@nsa.vix.com> <20100414235117.GA6167@vacation.karoshi.com.> <47311.1271289838@nsa.vix.com> <20100415034411.GA7600@vacation.karoshi.com.> <68226.1271306618@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68226.1271306618@nsa.vix.com> User-Agent: Mutt/1.4.1i 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, Apr 15, 2010 at 04:43:38AM +0000, Paul Vixie wrote: > > Date: Thu, 15 Apr 2010 03:44:11 +0000 > > From: bmanning@vacation.karoshi.com > > > > > no, that would be fatal to the effort, being an overspecification. > > > > sort of like the fatal rank ordering of BGP evaluation, > > IPv6 soure address selection, etc. > > nothing like those. > > > I will step back and > > watch this trainwreck... or see vendors "legislate from the > > bench" on "the" defacto packing of attributes. > > some web sites will care about language, others won't. some end users > will send language, others won't. this is nothing like bgp tiebreaking. if you say so. I don't believe you. --bill From owner-namedroppers@ops.ietf.org Thu Apr 15 05:01:57 2010 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 95C2E3A69BB; Thu, 15 Apr 2010 05:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Vfi6+V6o6K-V; Thu, 15 Apr 2010 05:01:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 45BF228C0FB; Thu, 15 Apr 2010 05:01:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2NhU-0009x6-Pk for namedroppers-data0@psg.com; Thu, 15 Apr 2010 11:57:40 +0000 Received: from [2001:470:1f05:a0f::1] (helo=tigger.mamista.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2NhS-0009vY-61 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 11:57:38 +0000 Received: by tigger.mamista.net (Postfix, from userid 1012) id 8FD38110474; Thu, 15 Apr 2010 21:57:37 +1000 (EST) Received: from merboo.mamista.net (merboo.mamista.net [IPv6:2001:470:1f0b:1055::1]) by tigger.mamista.net (Postfix) with ESMTP id 4B7E3110243 for ; Thu, 15 Apr 2010 21:57:37 +1000 (EST) Received: by merboo.mamista.net (Postfix, from userid 1000) id 7AECF9721C0; Thu, 15 Apr 2010 13:57:36 +0200 (CEST) Date: Thu, 15 Apr 2010 13:57:36 +0200 From: Martin Barry To: namedroppers@ops.ietf.org Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Message-ID: <20100415115735.GA10252@merboo.mamista.net> References: <25542.1271271658@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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: $quoted_author = "Jim Reid" ; > > Colm, I just don't get it. Sorry. If a web server/browser needs > location or language info or whatever for some reason, surely the > sensible place to configure that info is in the web software, not > the DNS? And web browsers can and do send some of that very information to web servers. But the issue here is that the current implementation of "stupid DNS tricks" performs selection of a server / cluster at the point when DNS is used to translate a name to an IP. Delaying this redirection till after the application connects is likely to negate any of the benefits of doing so. It also can add new issues such as caching and bookmarking of specific server / cluster URIs. Also, the use of these "tricks" is not limited to the web and as such pushing the implementation of it out to the application does not make sense. cheers Marty From owner-namedroppers@ops.ietf.org Thu Apr 15 05:27:45 2010 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 B8E2B28C2B7; Thu, 15 Apr 2010 05:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 6BA4AvB+jF30; Thu, 15 Apr 2010 05:27:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7CFB528C2BC; Thu, 15 Apr 2010 05:22:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2NyQ-000EFI-K1 for namedroppers-data0@psg.com; Thu, 15 Apr 2010 12:15:10 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2NyL-000EEM-7D for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 12:15:05 +0000 Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 4CDFDC56834; Thu, 15 Apr 2010 13:15:03 +0100 (BST) Date: Thu, 15 Apr 2010 13:15:02 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Martin Barry , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Message-ID: In-Reply-To: <20100415115735.GA10252@merboo.mamista.net> References: <25542.1271271658@nsa.vix.com> <20100415115735.GA10252@merboo.mamista.net> 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 April 2010 13:57:36 +0200 Martin Barry wrote: > But the issue here is that the current implementation of "stupid DNS > tricks" performs selection of a server / cluster at the point when DNS is > used to translate a name to an IP. This whole discussion to me bears comparison to the railways. In the UK we have different people running the trains to those that own the tracks. This discussion is a bit like: Various rail operating companies have decided to deploy rolling-stock with wider loads. This was much cheaper for them than putting on more wagons or using more trains. They've found that occasionally the wagons now crash into other wagons and trackside infrastructure, and are thus proposing those who own the tracks move them a bit further apart. They emphasise use of the new wider wagons will be entirely optional. -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Apr 15 05:28:40 2010 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 88FC528C308; Thu, 15 Apr 2010 05:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_05=-1.11, 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 7pGhT29ST12u; Thu, 15 Apr 2010 05:28:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2AC9328C229; Thu, 15 Apr 2010 05:23:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2O3X-000FLv-0k for namedroppers-data0@psg.com; Thu, 15 Apr 2010 12:20:27 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2O3Q-000FKY-VF for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 12:20:21 +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 o3FCIXAf026871; Thu, 15 Apr 2010 05:18:33 -0700 (PDT) Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Thu, 15 Apr 2010 05:18:33 -0700 Cc: Nicholas Weaver , John Payne , IETF DNSEXT WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> To: Jim Reid X-Mailer: Apple Mail (2.1078) 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 Apr 15, 2010, at 1:36 AM, Jim Reid wrote: >=20 >> For whatever reason, the BBC thinks that your client is in Sweden. = Try using opendns or google public dns... You'll likely get different = servers than the train ISP's resolvers return... >=20 > That's not allowed: you have to use the train's resolving server. [I = know this because my laptop already runs a resolving server to work = around the usual hotel network brain damage.] So in this example, I'd be = relying on the train's network to do the Right Thing with its stupid DNS = tricks which seems unlikely. Or I'd be hoping it allowed me to add the = location info of my choice to the outbound queries -- how would I know = what's optimal for where the train is? -- which is even less likely. Or, = if I could send location info to the resolver, it didn't "optimise" that = data before making the query. Which doesn't seem likely either. Guys, such localization is usually NOT done in DNS but at the HTTP = layer, when the client IP is actually available and its looked up in a = GeoIP database, as such tricks are NOT nearly so latency critical. My suggestion in the BBC case is look up the external IP you get in the = Maxmind GeoIP database (there is an online interface) and if its getting = the wrong answer, talk to them (they are the biggest supplier of this = data IIRC, although there may be others). From owner-namedroppers@ops.ietf.org Thu Apr 15 05:55:13 2010 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 261CB3A6A29; Thu, 15 Apr 2010 05:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 q8eh-daXoVgu; Thu, 15 Apr 2010 05:55:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B05328C218; Thu, 15 Apr 2010 05:51:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2OQz-000Km3-Ux for namedroppers-data0@psg.com; Thu, 15 Apr 2010 12:44:41 +0000 Received: from [2001:470:1f05:a0f::1] (helo=tigger.mamista.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2OQx-000Kla-9O for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 12:44:39 +0000 Received: by tigger.mamista.net (Postfix, from userid 1012) id C2881110474; Thu, 15 Apr 2010 22:44:38 +1000 (EST) Received: from merboo.mamista.net (merboo.mamista.net [IPv6:2001:470:1f0b:1055::1]) by tigger.mamista.net (Postfix) with ESMTP id 5A91E110215 for ; Thu, 15 Apr 2010 22:44:38 +1000 (EST) Received: by merboo.mamista.net (Postfix, from userid 1000) id 944849721C0; Thu, 15 Apr 2010 14:44:37 +0200 (CEST) Date: Thu, 15 Apr 2010 14:44:37 +0200 From: Martin Barry To: namedroppers@ops.ietf.org Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Message-ID: <20100415124437.GA13005@merboo.mamista.net> References: <25542.1271271658@nsa.vix.com> <20100415115735.GA10252@merboo.mamista.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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: $quoted_author = "Alex Bligh" ; > > --On 15 April 2010 13:57:36 +0200 Martin Barry wrote: > > >But the issue here is that the current implementation of "stupid DNS > >tricks" performs selection of a server / cluster at the point when DNS is > >used to translate a name to an IP. > > This whole discussion to me bears comparison to the railways. Actually, it doesn't. Alex, not to pick on you personally, but analogies are not really cutting it in trying to move this discussion forwards to either acceptance, compromise or rejection. The benefits of this proposal accrue to those using DNS resolvers that are not topologically close to the client and the services they are using that employ "stupid dns tricks". Implementation of it only really makes sense for the operators of those resolvers and services. For everyone else it is completely optional. There is some privacy concerns with exposing more information about the client to the authorative DNS server but I am of the opinion that users would trade that for the better performance of the service they are connecting to. cheers Marty From owner-namedroppers@ops.ietf.org Thu Apr 15 05:59:06 2010 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 DF01928C1F8; Thu, 15 Apr 2010 05:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[AWL=0.394, 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 1toqSqeMZ8wk; Thu, 15 Apr 2010 05:59:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A051D3A697F; Thu, 15 Apr 2010 05:57:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2OZP-000N2u-A0 for namedroppers-data0@psg.com; Thu, 15 Apr 2010 12:53:23 +0000 Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2OZM-000N2D-FM for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 12:53:20 +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 C202615427EB; Thu, 15 Apr 2010 13:53:16 +0100 (BST) Cc: IETF DNSEXT WG Message-Id: <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> From: Jim Reid To: John Payne In-Reply-To: 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] add support for latency-sensitive dns applications such as the web? Date: Thu, 15 Apr 2010 13:53:14 +0100 References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> 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 15 Apr 2010, at 13:48, John Payne wrote: > You're not relying on the train's network to do anything with DNS > tricks. You're relying on the train to have decent Internet > connectivity which it sounds like for some use cases, it doesn't. You still don't seem to understand. So let me spell it out. Once this WG legislates for stupid DNS tricks, the train's network will use them. This will not improve my browsing experience. It won't help me improve it because I will be unable to know what stupid DNS tricks I can configure (ie stub resolver hooks) will work for the network I'm using. From owner-namedroppers@ops.ietf.org Thu Apr 15 06:28:40 2010 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 475BC3A6847; Thu, 15 Apr 2010 06:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.752 X-Spam-Level: X-Spam-Status: No, score=-3.752 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_20=-0.74, 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 DH9uMIbPpRUu; Thu, 15 Apr 2010 06:28:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 34C493A69A6; Thu, 15 Apr 2010 06:24:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Ozv-0003tC-6X for namedroppers-data0@psg.com; Thu, 15 Apr 2010 13:20:47 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Ozs-0003sb-QN for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 13:20:45 +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 o3FDKhgK003394; Thu, 15 Apr 2010 06:20:44 -0700 (PDT) Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> Date: Thu, 15 Apr 2010 06:20:43 -0700 Cc: Nicholas Weaver , John Payne , IETF DNSEXT WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> To: Jim Reid X-Mailer: Apple Mail (2.1078) 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 Apr 15, 2010, at 5:53 AM, Jim Reid wrote: > On 15 Apr 2010, at 13:48, John Payne wrote: >=20 >> You're not relying on the train's network to do anything with DNS = tricks. You're relying on the train to have decent Internet = connectivity which it sounds like for some use cases, it doesn't. >=20 > You still don't seem to understand. So let me spell it out. Once this = WG legislates for stupid DNS tricks, the train's network will use them. = This will not improve my browsing experience. It won't help me improve = it because I will be unable to know what stupid DNS tricks I can = configure (ie stub resolver hooks) will work for the network I'm using. The train network is ALREADY seeing stupid DNS Tricks (TM), and = actually, they work for the train network because the DNS does match the = data path. Thats the point, the basic trick: That resolver X indicates the user is = on network Y, works like a charm EXCEPT if the user is using a resolver = NOT AFFILIATED with the network provider. Since the train network = forces you to use resolver X, the DNS tricks work perfectly (its just = the routing thats fubared) Thus the question is not should DNS enable stupid DNS tricks: it already = does, simply by the fact that, for most users, the resolver is part of = the network provider's infrastructure and can be identified as such. The question is, should users be penalized for using NON AFFILIATED DNS = resolvers: Namely, should OpenDNS and Google Public DNS continue to = return consistently inferior results? And there are three simple choices: a) Standardize a way for third party resolvers to explicitly convey = this information (edns-client-ip) WITHOUT requiring client changes. b) Watch as OpenDNS and/or Google Public DNS make pairwise agreements = with the major authorities doing these tricks (and therefore lock out = other third-party resolvers.) c) Let these services be inferior in user experience in the name of DNS = purity. Because without something standard for A, you will get a combination of = B and C. Is that what this working group really wants? From owner-namedroppers@ops.ietf.org Thu Apr 15 06:35:53 2010 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 42ECE3A69FB; Thu, 15 Apr 2010 06:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[AWL=0.350, 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 okZm4ckg4i0O; Thu, 15 Apr 2010 06:35:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 60C4428C191; Thu, 15 Apr 2010 06:33:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2P8d-0005qr-RZ for namedroppers-data0@psg.com; Thu, 15 Apr 2010 13:29:47 +0000 Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2P8b-0005q9-9M for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 13:29:45 +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 1D05615427EB; Thu, 15 Apr 2010 14:29:43 +0100 (BST) Cc: John Payne , IETF DNSEXT WG Message-Id: From: Jim Reid To: Nicholas Weaver In-Reply-To: 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] add support for latency-sensitive dns applications such as the web? Date: Thu, 15 Apr 2010 14:29:41 +0100 References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> 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 15 Apr 2010, at 14:20, Nicholas Weaver wrote: > The question is, should users be penalized for using NON AFFILIATED > DNS resolvers: Namely, should OpenDNS and Google Public DNS continue > to return consistently inferior results? IMO, people should be free to choose for themselves. If they select providers that do evil/stupid things, economic Darwinism will take care of that without any help from this WG. From owner-namedroppers@ops.ietf.org Thu Apr 15 06:37:06 2010 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 7908328C224; Thu, 15 Apr 2010 06:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.972 X-Spam-Level: X-Spam-Status: No, score=-101.972 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, 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 0HoDKS4r8Zw8; Thu, 15 Apr 2010 06:37:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 897573A6829; Thu, 15 Apr 2010 06:35:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2P9V-0006Az-NP for namedroppers-data0@psg.com; Thu, 15 Apr 2010 13:30:41 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2P9S-0005xC-An for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 13:30:39 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o3FDTsDW014053; Thu, 15 Apr 2010 13:29:54 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o3FDThK0014052; Thu, 15 Apr 2010 13:29:43 GMT Date: Thu, 15 Apr 2010 13:29:43 +0000 From: bmanning@vacation.karoshi.com To: Martin Barry Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Message-ID: <20100415132943.GB12836@vacation.karoshi.com.> References: <25542.1271271658@nsa.vix.com> <20100415115735.GA10252@merboo.mamista.net> <20100415124437.GA13005@merboo.mamista.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100415124437.GA13005@merboo.mamista.net> User-Agent: Mutt/1.4.1i 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, Apr 15, 2010 at 02:44:37PM +0200, Martin Barry wrote: > $quoted_author = "Alex Bligh" ; > > > > --On 15 April 2010 13:57:36 +0200 Martin Barry wrote: > > > > >But the issue here is that the current implementation of "stupid DNS > > >tricks" performs selection of a server / cluster at the point when DNS is > > >used to translate a name to an IP. > > > > This whole discussion to me bears comparison to the railways. > > Actually, it doesn't. Alex, not to pick on you personally, but analogies are > not really cutting it in trying to move this discussion forwards to either > acceptance, compromise or rejection. > > The benefits of this proposal accrue to those using DNS resolvers that are > not topologically close to the client and the services they are using that > employ "stupid dns tricks". Implementation of it only really makes sense for > the operators of those resolvers and services. For everyone else it is > completely optional. so... if the primary benefit is for stubs that are topologically distant from their cache, then much of the justification seems hinged on the fact that so many people are in the path between the stub and the cache and everyone wants to "help" the stub with the "right" information... wouldn't a simpler approach be to reduce the distance between the cache and stub? i mean if the current "distance" between the two is order 7000microseconds, wouldn't be easier to just move the cache closer to the stub, say under 300microseconds? Then the whole point of futzing w/ the protocol, backward compatability, unused/underused code paths, adnasua just goes away... > There is some privacy concerns with exposing more information about the > client to the authorative DNS server but I am of the opinion that users > would trade that for the better performance of the service they are > connecting to. bad tradeoff imho... just move the cache closer to the stub and most of the world will be happy. > > cheers > Marty --bill From owner-namedroppers@ops.ietf.org Thu Apr 15 06:53:32 2010 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 36D1928C1CF; Thu, 15 Apr 2010 06:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.86 X-Spam-Level: * X-Spam-Status: No, score=1.86 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_50=0.001, 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 KcWs9p9Tb61r; Thu, 15 Apr 2010 06:53:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F085E28C1CC; Thu, 15 Apr 2010 06:53:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2PP6-0009zb-2h for namedroppers-data0@psg.com; Thu, 15 Apr 2010 13:46:48 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2PP2-0009yx-Vp for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 13:46:45 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3FDkZwt064425; Thu, 15 Apr 2010 09:46:36 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Thu, 15 Apr 2010 09:46:42 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 15 Apr 2010 09:46:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <8381F1C3-E5E5-436E-8B3F-0B569DCA966D@rfc1035.com> References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <8381F1C3-E5E5-436E-8B3F-0B569DCA966D@rfc1035.com> Date: Thu, 15 Apr 2010 09:36:46 -0400 To: IETF DNSEXT WG From: Edward Lewis Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 0:17 +0100 4/15/10, Jim Reid wrote: >IIUC the problem is now about how to use DNS to provide answers that are >topologically optimal in a mathematical sense (for some definition of these >terms) that can, depending on context, apply to network or geographic >topology? Or some combination of these and any other types of topology which >might apply? Have I got this right? No, not quite. "optimal in the business sense." At 13:15 +0100 4/15/10, Alex Bligh wrote: >This whole discussion to me bears comparison to the railways. A double hit to Alex on this...(referring to the other message saying this isn't the right analogy). The discussion might relate to a view of the railways but the discussion is off the mark with respect to edns-client-ip. IP addresses are used, in the edns-client-ip case, to make networks run better. This isn't just fast browser page loads, it includes directing traffic to different data centers for whatever reason - load, etc. - known at design time, or even later, if traffic monitoring is happening. PS - Why is is that we say "the web is not the net" and then try to come up with solutions that benefit the web? (Referring to the subj line.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From owner-namedroppers@ops.ietf.org Thu Apr 15 07:28:42 2010 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 B42E73A6A85; Thu, 15 Apr 2010 07:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.3 X-Spam-Level: X-Spam-Status: No, score=-97.3 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, 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 xrVEuLE4VdQF; Thu, 15 Apr 2010 07:28:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B5B6D28C1DD; Thu, 15 Apr 2010 07:26:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Pwa-000Job-IC for namedroppers-data0@psg.com; Thu, 15 Apr 2010 14:21:24 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2PwX-000Jns-Bn for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 14:21:21 +0000 Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 21D61734479 for ; Thu, 15 Apr 2010 16:21:19 +0200 (CEST) Message-ID: <4BC720DE.8080900@nic.cz> Date: Thu, 15 Apr 2010 16:21:18 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "namedroppers@ops.ietf.org" Subject: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 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: Hi, I hereby present the "other" solution to name sameness (we all call it CNAME+DNAME, aren't we?). It's little bit competing with BNAME proposal, but it should be simpler to implement. It doesn't introduce new RTYPE, it just loosens the singleton rule of CNAME to allow DNAME for the same name (we did this before with NSEC+RRSIG, remember?) Just FYI, try digging idos.cz (or jizdnirady.cz) before you start writing this email and think if this proposal really breaks existing behaviour (if the existing resolvers are able to cope with this). Ondrej -------- Original Message -------- Subject: New Version Notification for draft-sury-dnsext-cname-dname-00 Date: Thu, 15 Apr 2010 07:16:25 -0700 (PDT) From: IETF I-D Submission Tool To: ondrej.sury@nic.cz A new version of I-D, draft-sury-dnsext-cname-dname-00.txt has been successfully submitted by Ondrej Sury and posted to the IETF repository. Filename: draft-sury-dnsext-cname-dname Revision: 00 Title: CNAME+DNAME Name Redirection Creation_date: 2010-04-15 WG ID: Independent Submission Number_of_pages: 5 Abstract: This document proposes a modification to CNAME record to coexist with DNAME record, which provides redirection for a sub-tree of the domain name tree in the DNS system. By allowing this cooexistence, DNS system will have a way how to create a sub-tree redirection together with record owner. This would allow parent zones to create full domain aliases. The IETF Secretariat. -- Ondřej Surý vedoucí výzkumu/R&D manager ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From owner-namedroppers@ops.ietf.org Thu Apr 15 07:28:47 2010 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 20F313A6A21; Thu, 15 Apr 2010 07:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 7lPBy5UAjIWs; Thu, 15 Apr 2010 07:28:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E12528C1C2; Thu, 15 Apr 2010 07:26:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2PyG-000KEB-Sv for namedroppers-data0@psg.com; Thu, 15 Apr 2010 14:23:08 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2PyC-000KD5-TI for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 14:23:05 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3FEN37f064769 for ; Thu, 15 Apr 2010 10:23:03 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id o3FEN3PA064768 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 10:23:03 -0400 (EDT) (envelope-from namedroppers) Received: from [140.186.190.103] (helo=haybaler.sackheads.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2GB5-000F2U-Hl for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 03:55:43 +0000 Received: from localhost (localhost.sackheads.org [127.0.0.1]) by haybaler.sackheads.org (Postfix) with ESMTP id 7735B28D36; Wed, 14 Apr 2010 23:55:41 -0400 (EDT) Authentication-Results: haybaler.sackheads.org; domainkeys=pass (testing) header.from=john@sackheads.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1271303741; bh=tyAn2Gyefpkk4hv5AXDtR1SBW7Ws/qbKo7fMk2grr6k=; h=References:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:Cc; b=Dn5Lg6SqEKSq//nsTiDCa+pCZ82zzgn7PWkjAzhFrXkEWT6cjhSQ2hbUot+f9+inu rYYUl4ekbNKjHYYRvETcxlcKLiIbR0v67jVRn6miPD9VIQn19CFtQk2pzEdoVN4bAV 9QiDi7fsc7Cxd+dKdTpYsXOt/Ie94jdvkmDUoWjM= Received: from haybaler.sackheads.org ([127.0.0.1]) by localhost (haybaler.sackheads.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCaV6q9VIK11; Wed, 14 Apr 2010 23:55:41 -0400 (EDT) Received: by haybaler.sackheads.org (Postfix, from userid 65534) id 33B5D28C10; Wed, 14 Apr 2010 23:55:41 -0400 (EDT) Received: from [192.168.1.20] (c-76-19-188-107.hsd1.ma.comcast.net [76.19.188.107]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: john@sackheads.org) by haybaler.sackheads.org (Postfix) with ESMTP id 6A69328B6D; Wed, 14 Apr 2010 23:55:40 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=haybaler; d=sackheads.org; c=nofws; q=dns; h=dkim-signature:references:message-id:from:to:in-reply-to: content-type:content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=xTKSVTywQVCGWkYY4Q2i+YZ5qTvgBDX164+s8WgIipEk75YCo+EQwyQs+gJwzBVsq G7k4WQJdOSpaO1pgG6dqFTYjPYbsYFqO45sZPFHh7fc9F7kL+h7o5owEeHcTO+5juUl p706Dl83FovmK1x82EZN0IByHuLdBsp0/hGMO9s= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1271303740; bh=tyAn2Gyefpkk4hv5AXDtR1SBW7Ws/qbKo7fMk2grr6k=; h=References:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:Cc; b=LbdhrtUbSs0TaiSV+9caQr+OXr1OKspwKHy/kLbV3nlMmlJVqw0lLdIuREcEhfFZm CUb7j7axM6xdm5ahX6fEWomnrVTls9bhB5iqhhZOLafESWbubFnLamWnT1HdK/kwJG qB35D6WoDGYJE84IVhoRvwQ7vW0TmWb32VSNo+AY= References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> Message-Id: <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> From: John Payne To: Jim Reid In-Reply-To: <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Date: Wed, 14 Apr 2010 23:55:35 -0400 Cc: Matthew Dempsky , "bmanning@vacation.karoshi.com" , IETF DNSEXT WG X-Scanned-By: MIMEDefang 2.67 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 Apr 14, 2010, at 6:43 PM, Jim Reid wrote: > On 14 Apr 2010, at 23:01, Matthew Dempsky wrote: > >> Right, I had already meant "geographically nearest" in the abstract >> sense, but I realize now "topologically nearest" would have been a >> better phrase to use. Sorry for any confusion. > > Either could be valid, depending on the circumstances and use case. > > As a for instance, wi-fi on the train between Scotland and London > goes through some Swedish ISP. [No, I don't understand this > either...] That means I get to browse the ad-splattered version of > the BBC web site rather than the ad-free one enjoyed by the > customers of UK ISPs. Those customers presumably pay the TV licence > fee that funds the BBC and should get free access to all the BBC's > services. And the BBC only has UK Internet rights for some of that > content. So I don't get to see or listen to some stuff I should be > able to get while on the train. > > For this case, if stupid DNS tricks were used, I'd want them to be > using a metric of "geographically nearest" (if such a thing was > viable) instead of "topologically nearest". That way I might be able > to signal to the web server or the train's resolver that I was in > the UK even if the network thought I wasn't. > > IMO DNS is not the place to solve these sorts of irritants because > they should be something for the web server and browser to work out > betweem themselves. And again, you are confusing server selection with content. In most geo-restricted setups, what matters is your client IP for content selection and localization (if there aren't any application layer hints). The "stupid DNS" tricks only select a server for you not the content. For whatever reason, the BBC thinks that your client is in Sweden. Try using opendns or google public dns... You'll likely get different servers than the train ISP's resolvers return... but I'd be surprised if you got different content. From owner-namedroppers@ops.ietf.org Thu Apr 15 07:28:47 2010 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 EBB403A6A21; Thu, 15 Apr 2010 07:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.377 X-Spam-Level: X-Spam-Status: No, score=-103.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 1OjD-Wj8w5x3; Thu, 15 Apr 2010 07:28:47 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id C7B5A28C258; Thu, 15 Apr 2010 07:26:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Pwx-000Jt4-O1 for namedroppers-data0@psg.com; Thu, 15 Apr 2010 14:21:47 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Pws-000Jrc-B1 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 14:21:44 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3FELeUt064740 for ; Thu, 15 Apr 2010 10:21:40 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id o3FELeIl064739 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 10:21:40 -0400 (EDT) (envelope-from namedroppers) Received: from [2001:888:2000:1d::2] (helo=xs.powerdns.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O1hsk-0009cD-Nv for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 15:18:31 +0000 Received: from mail-ww0-f52.google.com ([74.125.82.52]) by xs.powerdns.com with esmtpsa (TLS1.0:RSA_ARCFOUR_MD5:16) (Exim 4.69) (envelope-from ) id 1O1hse-0003GR-Mb for namedroppers@ops.ietf.org; Tue, 13 Apr 2010 17:18:25 +0200 Received: by wwb39 with SMTP id 39so582262wwb.11 for ; Tue, 13 Apr 2010 08:18:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.48.208 with HTTP; Tue, 13 Apr 2010 08:17:57 -0700 (PDT) In-Reply-To: <6FA6F5C6827C49D59FBC91736FC4685B@localhost> References: <6FA6F5C6827C49D59FBC91736FC4685B@localhost> From: bert hubert Date: Tue, 13 Apr 2010 17:17:57 +0200 Received: by 10.216.161.146 with SMTP id w18mr3460504wek.100.1271171899317; Tue, 13 Apr 2010 08:18:19 -0700 (PDT) Message-ID: Subject: Re: [dnsext] New defence to Kaminsky attack To: George Barwood , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam_score: -3.7 X-Spam_score_int: -36 X-Spam_bar: --- X-Spam_report: Spam detection software, running on the system "xs.powerdns.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi George, I want to implement this strategy, but I'm not quite seeing how it would work. This is in all likelihood because of me. When you query 123.www.example.com, the authentic answer comes in carrying an NXDOMAIN error status, and a SOA record for example.com. [...] Content analysis details: (-3.7 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.7 AWL AWL: From: address is in the auto white-list X-Scanned-By: MIMEDefang 2.67 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. ] Hi George, I want to implement this strategy, but I'm not quite seeing how it would work. This is in all likelihood because of me. When you query 123.www.example.com, the authentic answer comes in carrying an NXDOMAIN error status, and a SOA record for example.com. This teaches us that there is no www.example.com zone and no 123.www.example.com zone (because in that case, either we would've gotten a response, or a delegation). Now we mark www.example.com as 'not a zone'. When we now get an NS record for www.example.com (from an attacker), in response to a query for 124.www.example.com, we ignore that record, since we've stored that www.example.com is not a zone. Ok - this works. However, what about if you get a new NS record for 'example.com'? Normally we would accept 'more specifics', and this needs to be blocked too. Or does your proposal deal with this situation too? I'm aiming to implement your strategy, but I would appreciate your thoughts= ! Bert On Tue, Mar 16, 2010 at 5:14 PM, George Barwood wrote: > I think I have discovered a new defence to the Kaminsky attack that avoid= s > any extra queries in normal operation. > > A typical Kaminsky attack is to attack a domain, say > > www.example.com > > by asking a series of questions > > .www.example.com > > and sending spoof referral responses ( "Phantom Referrals" ) with a > delegation to a machine controlled by the attacker, e.g. > > www.example.com NS ns1.bad.net > > The true response=A0will be=A0NxDomain, normally=A0with a SOA record > > example.com SOA ...... > > To defend, when we get a NxDomain response, we mark the domains below the > zone=A0with a NZ flag ( "Not a Zone" ). > If there is no SOA record ( should be=A0unusual ), we assume the zone is = the > Bailiwick ( the Owner of the=A0NS record > that was used to select the name server=A0for the query ). > > If unexpectedly we later get a NS record for a NZ domain, we=A0reject NS= =A0the > record, clear the NZ flag, and retry ( if necessary ). > > Complete Acceptance rules > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > When reading a response, only the following records are accepted > > (1) Records in the Answer section of an Authoritative response (AA=3D1) t= hat > have > Owner =3D QNAME ( the domain of the Question ). > > (2) NS records in the Authority section that have Owner strictly below th= e > Bailiwick, > and with the Owner NZ flag clear. > > (3) A / AAAA records in the Additional section that resolve an accepted N= S > record. > > HTH, > -- George > From owner-namedroppers@ops.ietf.org Thu Apr 15 07:29:03 2010 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 9666B28C258; Thu, 15 Apr 2010 07:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.04 X-Spam-Level: X-Spam-Status: No, score=-101.04 tagged_above=-999 required=5 tests=[AWL=3.145, BAYES_40=-0.185, 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 ysXt3upgqLYh; Thu, 15 Apr 2010 07:29:02 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 5AB303A6B33; Thu, 15 Apr 2010 07:26:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Pxk-000K6K-RP for namedroppers-data0@psg.com; Thu, 15 Apr 2010 14:22:36 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Pxh-000K5Q-P0 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 14:22:33 +0000 Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 40A10C5684C; Thu, 15 Apr 2010 15:22:31 +0100 (BST) Date: Thu, 15 Apr 2010 15:22:30 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Edward Lewis , IETF DNSEXT WG cc: Alex Bligh Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Message-ID: In-Reply-To: References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <8381F1C3-E5E5-436E-8B3F-0B569DCA966D@rfc1035.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 April 2010 09:36:46 -0400 Edward Lewis wrote: >> This whole discussion to me bears comparison to the railways. > > A double hit to Alex on this...(referring to the other message saying > this isn't the right analogy). The discussion might relate to a view of > the railways but the discussion is off the mark with respect to > edns-client-ip. OK, railway analogy aside (it amused me), Paul Vixie has described what is being done as "stupid DNS tricks" at the authoritative server. Ignoring the pejorative label, it seems strange to me we should be considering changing the behaviour of recursive resolvers, rather than solving the problem these "stupid DNS tricks" were designed to solve another way. Martin Barry objected to my characterisation of optionality: > For everyone else it is completely optional." I'm not sure that's true. Firstly, it's yet more protocol complexity, and that hurts everyone. Secondlym is this EDNS0 option not going to be found in every query originated by a recursive resolver that supports it? Receiving EDNS0 options does not appear to be optional for authoritative servers, yet 99% of authoritative servers will not process them. -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Apr 15 07:30:46 2010 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 67B9028C223; Thu, 15 Apr 2010 07:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[AWL=1.300, 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 6wT45zoFZv9p; Thu, 15 Apr 2010 07:30:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 49CA23A691B; Thu, 15 Apr 2010 07:27:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Pyh-000KLs-S4 for namedroppers-data0@psg.com; Thu, 15 Apr 2010 14:23:35 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2PyZ-000KJK-W7 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 14:23:28 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3FENRb1064779 for ; Thu, 15 Apr 2010 10:23:27 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id o3FENR1I064778 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 10:23:27 -0400 (EDT) (envelope-from namedroppers) Received: from [140.186.190.103] (helo=haybaler.sackheads.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2GIh-000GtB-3D for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 04:03:35 +0000 Received: from localhost (localhost.sackheads.org [127.0.0.1]) by haybaler.sackheads.org (Postfix) with ESMTP id 8591728D45; Thu, 15 Apr 2010 00:03:33 -0400 (EDT) Authentication-Results: haybaler.sackheads.org; domainkeys=pass (testing) header.from=john@sackheads.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1271304213; bh=oE8ZOTONXoZDnvju0Rf30KnNblqajjs8HvcJWappdgc=; h=References:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:Cc; b=Hdv5qup+4yxta5k/ZyEuiARx/xLgLJn+nBW4IYvc40mmudtRZV3jqSbhAlyBeDLer XaTpZ6VFguYyx8KniAuKzAv7mSDa+Yd8LWj8O8SEU0WENVPVFrT9aDZKBWhUkHc9I7 Uoq6MGGVbuDjc/8i+bAFpMl0/RM/PWoFtcgLEWb4= Received: from haybaler.sackheads.org ([127.0.0.1]) by localhost (haybaler.sackheads.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OzrvTgkk2WF; Thu, 15 Apr 2010 00:03:33 -0400 (EDT) Received: by haybaler.sackheads.org (Postfix, from userid 65534) id 6051028D42; Thu, 15 Apr 2010 00:03:33 -0400 (EDT) Received: from [192.168.1.20] (c-76-19-188-107.hsd1.ma.comcast.net [76.19.188.107]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: john@sackheads.org) by haybaler.sackheads.org (Postfix) with ESMTP id 9D99328D3D; Thu, 15 Apr 2010 00:03:32 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=haybaler; d=sackheads.org; c=nofws; q=dns; h=dkim-signature:references:message-id:from:to:in-reply-to: content-type:content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=Nk7z/u/iO2Ey17WXmhBhtKWhqo8nl1PIeLTuj8FKnK97pAIuedecsikhi1z9XYk8p Yabl4eDRNUos9tfTSB4bSp3pLsf2ggBbGddLSR7KMGH4/aVS1P1y0KIEtty0zSmnGhq RwktsFxHWE5BG5EmFTeIT0eKkSnz3x9s4vjfOGg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1271304213; bh=oE8ZOTONXoZDnvju0Rf30KnNblqajjs8HvcJWappdgc=; h=References:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:Cc; b=Hdv5qup+4yxta5k/ZyEuiARx/xLgLJn+nBW4IYvc40mmudtRZV3jqSbhAlyBeDLer XaTpZ6VFguYyx8KniAuKzAv7mSDa+Yd8LWj8O8SEU0WENVPVFrT9aDZKBWhUkHc9I7 Uoq6MGGVbuDjc/8i+bAFpMl0/RM/PWoFtcgLEWb4= References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <42609.1271286871@nsa.vix.com> Message-Id: From: John Payne To: Paul Vixie In-Reply-To: <42609.1271286871@nsa.vix.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Date: Thu, 15 Apr 2010 00:03:27 -0400 Cc: IETF DNSEXT WG X-Scanned-By: MIMEDefang 2.67 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 Apr 14, 2010, at 7:14 PM, Paul Vixie wrote: >> Date: Wed, 14 Apr 2010 21:49:25 +0000 >> From: bmanning@vacation.karoshi.com >> ... >> I suspect that geographic proximity is not really what you >> are after... I think topological proximity might be a better >> first metric. > > address similarity is by itself a poor predictor of topological > proximity, > even for evaluators who are holding a "full routing table". that's > why my > proposal is to include many attributes including geo, ip, uuid, and > language, > and to let the authority server decide what to do. > > it's possible that an authority server will want to send a response > that > directs tcp/80 to a low-rtt server, or, given knowledge of the end > user's > language and of their location and direction, may wish to send them > to a > server that's "better" in some other way than just "low latency". > good > internet engineering means not overspecifying. i should have titled > my > message as follows: > > "Subject: support for user-context-sensitive dns applications (e.g.: > web)" Sorry if I missed the problem statement, but are you trying to guess at what "stupid dns tricks" are used for and why the client IP is useful in some limited corner cases and design to that, or is this an entirely different issue than the edns-client-subnet proposal? From owner-namedroppers@ops.ietf.org Thu Apr 15 07:31:26 2010 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 6A6C728C27A; Thu, 15 Apr 2010 07:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.425 X-Spam-Level: * X-Spam-Status: No, score=1.425 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619, 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 GRXNgbpkyydx; Thu, 15 Apr 2010 07:31:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 644F628C28D; Thu, 15 Apr 2010 07:28:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Pz7-000KRS-Ru for namedroppers-data0@psg.com; Thu, 15 Apr 2010 14:24:01 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Pz4-000KQa-2n for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 14:23:58 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3FENuUT064789 for ; Thu, 15 Apr 2010 10:23:56 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id o3FENuku064788 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 10:23:56 -0400 (EDT) (envelope-from namedroppers) Received: from [140.186.190.103] (helo=haybaler.sackheads.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2OUY-000LVa-Ue for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 12:48:23 +0000 Received: from localhost (localhost.sackheads.org [127.0.0.1]) by haybaler.sackheads.org (Postfix) with ESMTP id 3382528C4F; Thu, 15 Apr 2010 08:48:21 -0400 (EDT) Authentication-Results: haybaler.sackheads.org; domainkeys=pass (testing) header.from=john@sackheads.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1271335701; bh=OFsJl3Wi4QsAS+u38GVjIo0KmKh57YLyyLlDhJ4H7bU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=x6Lhm+AitP+g7uQ30nK8bZfqd1F+7ZutOGIZ9GLWY17E3bx3p5ckkOlgAHc8eXFYz MKt2/ipT0wzMinX9hZC5CFYFsSAU6ytIpPAaSY3A2wt/CxngbP0TH9gX81O25Igw4S iAeX00i7rZwSOQoWPVfiEBdaqrVi2yWAifB5U+eM= Received: from haybaler.sackheads.org ([127.0.0.1]) by localhost (haybaler.sackheads.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXQQynhnTv8h; Thu, 15 Apr 2010 08:48:20 -0400 (EDT) Received: by haybaler.sackheads.org (Postfix, from userid 65534) id 8227F28C4E; Thu, 15 Apr 2010 08:48:20 -0400 (EDT) Received: from mobilehost200000.internet.mymmode.com (unknown [72.246.0.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: john@sackheads.org) by haybaler.sackheads.org (Postfix) with ESMTP id 076F228B8D; Thu, 15 Apr 2010 08:48:17 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=haybaler; d=sackheads.org; c=nofws; q=dns; h=dkim-signature:subject:mime-version:content-type:from: in-reply-to:date:cc:message-id:references:to:x-mailer; b=GdO+TOpSv+cHWkJZFW2NVNzFaqVUxNcubWAWMnGf6hzpbhcOY6GYtk14jZ3JrOa8V guuuSKXDUA83uDCs7hCBwfNcMK3/zjMnSJcCe6paiGx4ASiid5zKGEtQmL3iiFh4Jmk UAeQ91kV1velUc3R7JwoFt6W2AS4ASFUODdra6o= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1271335700; bh=OFsJl3Wi4QsAS+u38GVjIo0KmKh57YLyyLlDhJ4H7bU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=ivuC6JNCxmKEvUUoz9PlVDGbDnCec8Bm6DkdZk71aLrMF6RnG33C0fbATJ1rzgKfp C2runw1lgc+kyzc+BFuLHSARqV7K25DTEcl7ZMyO38qud0tTy81RK1EmRlz0kss3VF 2BXYxfQ8F0A/hzAsL9nzEK3BczpY5O9pHnW09RpU= Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-97-970708484 From: John Payne In-Reply-To: Date: Thu, 15 Apr 2010 08:48:04 -0400 Cc: IETF DNSEXT WG Message-Id: References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> To: Jim Reid X-Mailer: Apple Mail (2.1077) X-Scanned-By: MIMEDefang 2.67 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. ] --Apple-Mail-97-970708484 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 15, 2010, at 4:36 AM, Jim Reid wrote: > On 15 Apr 2010, at 04:55, John Payne wrote: >=20 >> And again, you are confusing server selection with content. >=20 > I'm not. I think you've not been paying attention. Besides the unoptimal server selection, you were complaining about = content (ad laden and UK only stuff). >=20 >> In most geo-restricted setups, what matters is your client IP for = content selection and localization (if there aren't any application = layer hints). >> The "stupid DNS" tricks only select a server for you not the content. >=20 > Which means I'm directed to whatever server is "optimal" for someone = in Sweden. Which probably isn't optimal for my packets or the content = I'm served. Which is an issue, yes. But it's probably still better than a server in = Asia or the Western US (which wouldn't make sense for BBC content, but = other popular content without "stupid DNS tricks" would have that = problem). How do you know that latency-wise Sweden isn't the best choice for your = packets? If, for example, the train is bouncing packets off a satellite = to a downlink in Stockholm, it's almost certainly going to be better to = serve you from Sweden than London or Manchester.=20 >=20 >> For whatever reason, the BBC thinks that your client is in Sweden. = Try using opendns or google public dns... You'll likely get different = servers than the train ISP's resolvers return... >=20 > That's not allowed: you have to use the train's resolving server. [I = know this because my laptop already runs a resolving server to work = around the usual hotel network brain damage.] So in this example, I'd be = relying on the train's network to do the Right Thing with its stupid DNS = tricks which seems unlikely. Or I'd be hoping it allowed me to add the = location info of my choice to the outbound queries -- how would I know = what's optimal for where the train is? -- which is even less likely. Or, = if I could send location info to the resolver, it didn't "optimise" that = data before making the query. Which doesn't seem likely either. You're not relying on the train's network to do anything with DNS = tricks. You're relying on the train to have decent Internet = connectivity which it sounds like for some use cases, it doesn't.= --Apple-Mail-97-970708484 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 15 = Apr 2010, at 04:55, John Payne wrote:

And= again, you are confusing server selection with = content.

I'm not. I think you've not been paying = attention.

Besides the = unoptimal server selection, you were complaining about content (ad laden = and UK only stuff).


In most geo-restricted = setups, what matters is your client IP for content selection and = localization (if there aren't any application layer = hints).
The "stupid DNS" = tricks only select a server for you not the = content.

Which means I'm directed to whatever server = is "optimal" for someone in Sweden. Which probably isn't optimal for my = packets or the content I'm = served.

Which is an issue, = yes.  But it's probably still better than a server in Asia or the = Western US (which wouldn't make sense for BBC content, but other popular = content without "stupid DNS tricks" would have that = problem).

How do you know that latency-wise = Sweden isn't the best choice for your packets?  If, for example, = the train is bouncing packets off a satellite to a downlink in = Stockholm, it's almost certainly going to be better to serve you from = Sweden than London or = Manchester. 



For whatever reason, = the BBC thinks that your client is in Sweden. Try using opendns or = google public dns... You'll likely get different servers than the train = ISP's resolvers return...

That's not allowed: you = have to use the train's resolving server. [I know this because my laptop = already runs a resolving server to work around the usual hotel network = brain damage.] So in this example, I'd be relying on the train's network = to do the Right Thing with its stupid DNS tricks which seems unlikely. = Or I'd be hoping it allowed me to add the location info of my choice to = the outbound queries -- how would I know what's optimal for where the = train is? -- which is even less likely. Or, if I could send location = info to the resolver, it didn't "optimise" that data before making the = query. Which doesn't seem likely either.

You'= re not relying on the train's network to do anything with DNS tricks. =  You're relying on the train to have decent Internet connectivity = which it sounds like for some use cases, it doesn't.
= --Apple-Mail-97-970708484-- From owner-namedroppers@ops.ietf.org Thu Apr 15 07:32:44 2010 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 766D73A6B00; Thu, 15 Apr 2010 07:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[AWL=0.743, 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 NYoyawOGshUf; Thu, 15 Apr 2010 07:32:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 74F8928C18C; Thu, 15 Apr 2010 07:30:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Q0E-000Kz3-RM for namedroppers-data0@psg.com; Thu, 15 Apr 2010 14:25:10 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Q05-000KvO-1S for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 14:25:01 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3FEP0fk064828 for ; Thu, 15 Apr 2010 10:25:00 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id o3FEP0ru064826 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 10:25:00 -0400 (EDT) (envelope-from namedroppers) Received: from [140.186.190.103] (helo=haybaler.sackheads.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2PGv-00080B-Bc for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 13:38:21 +0000 Received: from localhost (localhost.sackheads.org [127.0.0.1]) by haybaler.sackheads.org (Postfix) with ESMTP id 9009828D98; Thu, 15 Apr 2010 09:38:19 -0400 (EDT) Authentication-Results: haybaler.sackheads.org; domainkeys=pass (testing) header.from=john@sackheads.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1271338699; bh=kE75Us9uQyXZXihWcomOHdyb+Td9JPCQQNbBzib7ivI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=UdqOmCkItDlx/OdybFVnIXzrOd+Tr+Wp/ZZaMHwh4rXPpx1iNIkWEp3UUHeaHQxWA ybhwOmSrARisxsbwB33v1mHZuM2yOHZjIDecvLJ0LMTIPDyafHEAmdwqeZ7fsJnNSI wVUfwWRzkAnvfyEBskqbcL5eFkqis6doO7sll9xQ= Received: from haybaler.sackheads.org ([127.0.0.1]) by localhost (haybaler.sackheads.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QbZ2nXaF10i; Thu, 15 Apr 2010 09:38:19 -0400 (EDT) Received: by haybaler.sackheads.org (Postfix, from userid 65534) id DC52428D8A; Thu, 15 Apr 2010 09:38:18 -0400 (EDT) Received: from usma1mc-0f6642.8cc-neteng.corp.akamai.com (unknown [72.246.0.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: john@sackheads.org) by haybaler.sackheads.org (Postfix) with ESMTP id 9060928BFB; Thu, 15 Apr 2010 09:38:18 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=haybaler; d=sackheads.org; c=nofws; q=dns; h=dkim-signature:subject:mime-version:content-type:from: in-reply-to:date:cc:content-transfer-encoding:message-id:references:to:x-mailer; b=AgB/Z6o9fAWWoV/guNkks1z5jipFlI6IE4QVfOdHj4I80ZG0XvyeXffZe4irtUFRv Ylx68/3IgHkllIRwyIOTShOtvp5I9EUpth12zbdFdYO/1oQJxnoNWby+t25UYxvHFTW jPLbT/Vv/4g6ER0b52Jgbj7C/ciG4TZUo5EsyNA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1271338698; bh=kE75Us9uQyXZXihWcomOHdyb+Td9JPCQQNbBzib7ivI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=obfYIi/VI09Ppmog3wQ5uQEAqtJMWr3oImVwGxbpNyTYa+0kSn5y1ruOKBd1fOPcM J4C8eMgA+gDg8HF8+uRlLAJEcBjjgF0D5wQVN+hFrwsVrfGOIrYBLltUpIhahj1xwH 5zKdONut73LXivS8q7stqRjm6CAFB2/YTbv0iEO0= Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: John Payne In-Reply-To: <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> Date: Thu, 15 Apr 2010 09:15:10 -0400 Cc: IETF DNSEXT WG Content-Transfer-Encoding: quoted-printable Message-Id: <2B7ACBED-B7DA-4A0D-9520-8ED0A135DFF8@sackheads.org> References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> To: Jim Reid X-Mailer: Apple Mail (2.1077) X-Scanned-By: MIMEDefang 2.67 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 Apr 15, 2010, at 8:53 AM, Jim Reid wrote: > On 15 Apr 2010, at 13:48, John Payne wrote: >=20 >> You're not relying on the train's network to do anything with DNS = tricks. You're relying on the train to have decent Internet = connectivity which it sounds like for some use cases, it doesn't. >=20 > You still don't seem to understand. So let me spell it out. Once this = WG legislates for stupid DNS tricks, the train's network will use them. = This will not improve my browsing experience. It won't help me improve = it because I will be unable to know what stupid DNS tricks I can = configure (ie stub resolver hooks) will work for the network I'm using. As far as the edns-client-subnet option is concerned, if your train's = resolver is "close" to you, then it has no incentive to enable it. If = it does, the people that care about such things have no incentive to = listen to it. In the worst possible case, it doesn't help you, no. But = it also doesn't hurt you. As far as Paul's proposal is concerned, as far as I can make out, it = isn't at all useful and is only designed to try and kill the = edns-client-subnet option.= From owner-namedroppers@ops.ietf.org Thu Apr 15 07:35:33 2010 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 2012328C1B2; Thu, 15 Apr 2010 07:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] 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 At9T1FTlBDQO; Thu, 15 Apr 2010 07:35:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F08C128C1F0; Thu, 15 Apr 2010 07:33:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Q3N-000MF7-MU for namedroppers-data0@psg.com; Thu, 15 Apr 2010 14:28:25 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Q3J-000MDh-KU for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 14:28:21 +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 85B38E8554; Thu, 15 Apr 2010 14:28:20 +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 o3FESCfI079886; Fri, 16 Apr 2010 00:28:13 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004151428.o3FESCfI079886@drugs.dv.isc.org> To: "YAO Jiankang" Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <471323117.21296@cnnic.cn> <451D7DB04B81453799CB4C53265F13FA@LENOVO47E041CF> Subject: Re: [dnsext] Unsigned Synthesized CNAME issues in dname-bis draft In-reply-to: Your message of "Thu, 15 Apr 2010 17:18:42 +0800." <471323117.21296@cnnic.cn> <451D7DB04B81453799CB4C53265F13FA@LENOVO47E041CF> Date: Fri, 16 Apr 2010 00:28:12 +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 <471323117.21296@cnnic.cn> <451D7DB04B81453799CB4C53265F13FA@LENOVO4 7E041CF>, "YAO Jiankang" writes: > in section 5.3.1. Signed DNAME, Unsigned Synthesized CNAME of draft draft-ietf-dnsext-rfc2672bis-dname-18: > > In any response, a signed DNAME RR indicates a non-terminal > redirection of the query. There might or might not be a server > synthesized CNAME in the answer section; if there is, the CNAME will > never be signed. > > could I suggest to > > change "if there is, the CNAME will never be signed." > > to the follow "if there is, the CNAME may (should) be signed if the online signing is supported on the server." ? > > we can do it or not? You don't need to do it. The client will most probably ignore it. named does. The CNAME is just there to make the non DNAME aware clients happy. 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 Apr 15 07:42:32 2010 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 64B8F3A6AF6; Thu, 15 Apr 2010 07:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.65 X-Spam-Level: X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[AWL=0.398, 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 JBLiGr0Mrz1f; Thu, 15 Apr 2010 07:42:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 196803A69F5; Thu, 15 Apr 2010 07:42:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2QC8-000Ocr-1N for namedroppers-data0@psg.com; Thu, 15 Apr 2010 14:37:28 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2QBz-000Oar-31 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 14:37:19 +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 o3FEbIR0013076; Thu, 15 Apr 2010 07:37:18 -0700 (PDT) References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <685B8131-2A3F-4B07-AD56-2CA999EE0BBF@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , John Payne , IETF DNSEXT WG From: Nicholas Weaver Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Date: Thu, 15 Apr 2010 07:37:17 -0700 To: Jim Reid X-Mailer: Apple Mail (2.1078) 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 Apr 15, 2010, at 6:29 AM, Jim Reid wrote: > On 15 Apr 2010, at 14:20, Nicholas Weaver wrote: >=20 >> The question is, should users be penalized for using NON AFFILIATED = DNS resolvers: Namely, should OpenDNS and Google Public DNS continue to = return consistently inferior results? >=20 > IMO, people should be free to choose for themselves. If they select = providers that do evil/stupid things, economic Darwinism will take care = of that without any help from this WG. Economoic darwinism has a market failure here. THe existing status quo is "You use your ISP's recursive resolver, you = get good results because these tricks work. Only if you use a third = party resolver service do your results suffer". Do you actually mean to say "Using a third party resolver is a stupid = thing and shouldn't happen?" or "You should only be able to use third = party resolvers that make pairwise agreements with major authorities, = limiting other market entries?" =20 Because that is the equilibrium position you are advocating, because the = DNS tricks themselves are now entrenched and won't go away. =20 These tricks would only go away if most people switched to third party = resolvers, and people won't switch to third party resolvers because=20 a: its an explicit act and=20 b: the performance gets worse because, among other things, these DNS = tricks stop working! From owner-namedroppers@ops.ietf.org Thu Apr 15 07:57:10 2010 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 5C96C28C1E7; Thu, 15 Apr 2010 07:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.18 X-Spam-Level: X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[AWL=0.315, 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 92zat6VGlLeu; Thu, 15 Apr 2010 07:57:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8A5DC28C1DD; Thu, 15 Apr 2010 07:57:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2QOB-0002Hb-Cn for namedroppers-data0@psg.com; Thu, 15 Apr 2010 14:49:55 +0000 Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2QO5-0002Fx-6u for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 14:49:50 +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 6E35F15427EB; Thu, 15 Apr 2010 15:49:45 +0100 (BST) Cc: John Payne , IETF DNSEXT WG Message-Id: <9A60997E-2F1D-4AE2-AD7E-310F46ED4E9C@rfc1035.com> From: Jim Reid To: Nicholas Weaver In-Reply-To: <685B8131-2A3F-4B07-AD56-2CA999EE0BBF@ICSI.Berkeley.EDU> 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] stupid DNS tricks for fun and profit Date: Thu, 15 Apr 2010 15:49:43 +0100 References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> <685B8131-2A3F-4B07-AD56-2CA999EE0BBF@ICSI.Berkeley.EDU> 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 15 Apr 2010, at 15:37, Nicholas Weaver wrote: > Do you actually mean to say "Using a third party resolver is a > stupid thing and shouldn't happen?" or "You should only be able to > use third party resolvers that make pairwise agreements with major > authorities, limiting other market entries?" Neither. I'm saying using a third party resolver is a stupid thing to do. [Everyone here should have first-hand experience why that's the case.] It's even more stupid because DNSSEC is lurking around the corner and that'll mean edge devices validating stuff for themselves. But if people want to do stupid things and know what they're buying into, they should be free to do that. There's an abundance of that sort of thing on the Internet already. Similarly, providers who want to offer stupid DNS tricks are welcome to do so. The market will take care of them and their business models if DNSSEC deployment doesn't kill them first. Can we now get back to defining requirements and specifying an actual problem? From owner-namedroppers@ops.ietf.org Thu Apr 15 08:17:51 2010 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 E31543A693F; Thu, 15 Apr 2010 08:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.027 X-Spam-Level: *** X-Spam-Status: No, score=3.027 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 g5-HVDVwWbM2; Thu, 15 Apr 2010 08:17:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C55A13A692D; Thu, 15 Apr 2010 08:17:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Ql4-0008uY-7D for namedroppers-data0@psg.com; Thu, 15 Apr 2010 15:13:34 +0000 Received: from [74.125.83.180] (helo=mail-pv0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Qku-0008qD-Ju for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 15:13:24 +0000 Received: by pvc22 with SMTP id 22so865244pvc.11 for ; Thu, 15 Apr 2010 08:13:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.169.1 with HTTP; Thu, 15 Apr 2010 08:13:17 -0700 (PDT) In-Reply-To: References: <25542.1271271658@nsa.vix.com> Date: Thu, 15 Apr 2010 08:13:17 -0700 Received: by 10.114.54.1 with SMTP id c1mr201467waa.61.1271344397895; Thu, 15 Apr 2010 08:13:17 -0700 (PDT) Message-ID: Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Jim Reid Cc: Paul Vixie , IETF DNSEXT WG 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: 2010/4/15 Jim Reid : > On 14 Apr 2010, at 21:57, Colm MacC=E1rthaigh wrote: > >> Surely hiding the option in the code of browsers is less privacy and >> user friendly than people simply choosing the resolvers they use? > > Colm, I just don't get it. Sorry. If a web server/browser needs location = or > language info or whatever for some reason, surely the sensible place to > configure that info is in the web software, not the DNS? To rephrase the = old > joke about DEC Field Service, would you change a car's battery because th= e > tyres were flat? This is already the case. HTTP provides many of this information already, and there's a rich and expressive syntax using Accept and Vary headers to negotiate such things. Because it's relatively easy to extend HTTP, and to build applications on top of it, implementers now also support other information - including GPS data, something browsers can typically provide now. It is sensible, and it occurs already. But we are not talking about giving users different data depending on all of these sorts of things; that is a solved problem. We are talking about routing clients to their topologically closest node. I would argue that the average path is stable for long enough, and enough of internet topology is knowable, that address-based proximity is not snake-oil. Real-world operators, including the drafters and contributors of this I-D, to this today - and it seems to work for them. This is how the real internet operators right now today. I don't see how it is not sensible to afford them an option code and a reference text for the technique so that at least implementations are not fragmented. It is very hard to build applications on top of DNS in the way that protocols such as HTTP can be extended. Most of the properties you raise did not arise in HTTP through standardisation, but instead through experimentation. Even the direct analogue of this proposal, the X-Forwarded-For: header is an "X-" header - it arose through private experimentation. DNS would seem like culturally the worst possible place to try and do this. We now have contributors here arguing that EDNS options are not in fact optional. There is also no private use range for option codes. The message seems to be ; all EDNS options have to be universally suitable, achieve consensus on rationality and meet a technical bar of perfect. Faced with that attitude, if browsers were to radically overhaul their lookup mechanisms, it would make more sense to fork DNS entirely. Strangely enough, that's essentially what CDNs have already done. --=20 Colm From owner-namedroppers@ops.ietf.org Thu Apr 15 08:21:41 2010 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 0F40D3A6955; Thu, 15 Apr 2010 08:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.507 X-Spam-Level: * X-Spam-Status: No, score=1.507 tagged_above=-999 required=5 tests=[AWL=0.143, 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 d4k7P1ZWpd+H; Thu, 15 Apr 2010 08:21:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B2F363A6845; Thu, 15 Apr 2010 08:21:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2QoO-0009r0-ME for namedroppers-data0@psg.com; Thu, 15 Apr 2010 15:17:00 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2QoJ-0009p7-At for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 15:16:55 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3FFGYg0065638; Thu, 15 Apr 2010 11:16:34 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Thu, 15 Apr 2010 11:16:41 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 15 Apr 2010 11:16:41 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <8381F1C3-E5E5-436E-8B3F-0B569DCA966D@rfc1035.com> Date: Thu, 15 Apr 2010 11:14:14 -0400 To: Alex Bligh From: Edward Lewis Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Cc: Edward Lewis , IETF DNSEXT WG , Alex Bligh Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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:22 +0100 4/15/10, Alex Bligh wrote: >OK, railway analogy aside (it amused me), Paul Vixie has described what >is being done as "stupid DNS tricks" at the authoritative server. >Ignoring the pejorative label, it seems strange to me we should >be considering changing the behaviour of recursive resolvers, rather >than solving the problem these "stupid DNS tricks" were designed to >solve another way. In the context of authorities that tailor responses to where the query is purported to be coming from: The issue is that for the most part recursive servers sit topologically close to the users they serve. This option's goal is to make topologically remote (server to stub) recursive servers provide service to the stubs (etal) on par with what they would get with topologically close (server to stub) servers. That's why this is built into the DNS and not in the applications. >Martin Barry objected to my characterisation of optionality: >> For everyone else it is completely optional." >I'm not sure that's true. Firstly, it's yet more protocol >complexity, and that hurts everyone. I disagree that it hurts everyone. I've said this in an earlier message, complexity is another word for optimizations. Before declaring complexity as "bad" I would want to see specific reasons why. Complexity does have a cost, but is the benefit of the corresponding optimization exceed the cost of the complexity? >Secondly, >is this EDNS0 option not going to be found in every query >originated by a recursive resolver that supports it? Receiving >EDNS0 options does not appear to be optional for authoritative >servers, yet 99% of authoritative servers will not process them. If the problem is that an unrecognized EDNS0 option causes an issue for servers that recognize EDNS0 but not the specific option, we might as well trash EDNS0 extensions from here on out. Is EDNS0 pretty much un-extensible? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From owner-namedroppers@ops.ietf.org Thu Apr 15 08:22:30 2010 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 4441E3A6847; Thu, 15 Apr 2010 08:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.671 X-Spam-Level: X-Spam-Status: No, score=-4.671 tagged_above=-999 required=5 tests=[AWL=0.377, 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 5PSLnbiKRAHi; Thu, 15 Apr 2010 08:22:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0FAD73A69ED; Thu, 15 Apr 2010 08:21:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2QpL-0009z0-B7 for namedroppers-data0@psg.com; Thu, 15 Apr 2010 15:17:59 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2QpG-0009y9-PS for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 15:17:54 +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 o3FFHsbk018933; Thu, 15 Apr 2010 08:17:54 -0700 (PDT) References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> <685B8131-2A3F-4B07-AD56-2CA999EE0BBF@ICSI.Berkeley.EDU> <9A60997E-2F1D-4AE2-AD7E-310F46ED4E9C@rfc1035.com> In-Reply-To: <9A60997E-2F1D-4AE2-AD7E-310F46ED4E9C@rfc1035.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <58470CC8-8973-43ED-8BC6-CD00FBC51095@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , John Payne , IETF DNSEXT WG From: Nicholas Weaver Subject: [dnsext] Re: stupid DNS tricks for fun and profit Date: Thu, 15 Apr 2010 08:17:53 -0700 To: Jim Reid X-Mailer: Apple Mail (2.1078) 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 Apr 15, 2010, at 7:49 AM, Jim Reid wrote: > On 15 Apr 2010, at 15:37, Nicholas Weaver wrote: >=20 >> Do you actually mean to say "Using a third party resolver is a stupid = thing and shouldn't happen?" or "You should only be able to use third = party resolvers that make pairwise agreements with major authorities, = limiting other market entries?" >=20 > Neither. I'm saying using a third party resolver is a stupid thing to = do. [Everyone here should have first-hand experience why that's the = case.] It's even more stupid because DNSSEC is lurking around the corner = and that'll mean edge devices validating stuff for themselves. But if = people want to do stupid things and know what they're buying into, they = should be free to do that. There's an abundance of that sort of thing on = the Internet already. Similarly, providers who want to offer stupid DNS = tricks are welcome to do so. The market will take care of them and their = business models if DNSSEC deployment doesn't kill them first. >=20 > Can we now get back to defining requirements and specifying an actual = problem? The problem statement: For several purposes, DNS authorities will operate under the assumption = that a request from resolver X is associated with a client on network Y, = and uses this assumption to provide higher-quality results. This assumption is generally valid and useful, except in cases where the = user either: a: Sends DNS traffic over a different path than the rest of the traffic = (boneheaded proxying) b: Uses a third party resolver service rather than the network-provided = recursive resolver In such cases, users still get correct results, but the results are of = lower quality (usually, higher latency, but also perhaps more costly to = the content provider). [1] The problem statement: Should such cases be able to convey to the = authority servers which care enough information about the client's = actual network location, to allow the authority to give the same quality = results that the client would receive if they used the network's = resolver? And there is a proposal which solves this problem: = edns-client-ip/edns-client-subnet (call it what you will). There are two other alternatives on the table: 1: The third party resolvers make pairwise agreements with authorities = without creating a standard, acting as a lock-in for just these third = party resolvers 2: Say "third party resolvers should be at a fundamental disadvantage = when compared with ISP resolvers" And not all third party resolvers muck with results: EG, Google Public = DNS does not. =20 And DNSSEC, even validated on the client, does not prevent the third = party resolver from mucking with results, when the value-added is site = blocking (which is OpenDNS's real value-add for paid-service): just = instead of a redirect to a site that says "this was blocked", the = validating client throws up an error. So the service works in either = case: blocking 'undesired' sites from properly resolving. [1] You can validate this phenomenon for yourself. Ping www.bing.com, = www.yahoo.com, and www.google.com, and ping the systems who's IPs are = returned by Google Public DNS's server (8.8.8.8), and compare. From dmailer.ok@ietf.org Thu Apr 15 08:48:09 2010 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 C2EDF3A6AB9 for ; Thu, 15 Apr 2010 08:48:09 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Thu, 15 Apr 2010 08:48:07 -0700 (PDT) Received: from 24hourmall.com (unknown [85.105.156.233]) by core3.amsl.com (Postfix) with SMTP id 0D4DB3A6BB3 for ; Thu, 15 Apr 2010 08:46:50 -0700 (PDT) From: Approved VIAGRA® Store Subject: News on myspace To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100415154654.0D4DB3A6BB3@core3.amsl.com> Date: Thu, 15 Apr 2010 08:46:50 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 73789 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Thu Apr 15 08:54:24 2010 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 BA42D3A69A4; Thu, 15 Apr 2010 08:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[AWL=-0.507, 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 P38awuIhuAWP; Thu, 15 Apr 2010 08:54:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E35CA3A682F; Thu, 15 Apr 2010 08:54:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2RJT-000IRi-Qm for namedroppers-data0@psg.com; Thu, 15 Apr 2010 15:49:07 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2RJP-000IRA-PN for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 15:49:04 +0000 Received: from [75.101.18.87] (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 o3FFn06J023791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Apr 2010 08:49:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <58470CC8-8973-43ED-8BC6-CD00FBC51095@ICSI.Berkeley.EDU> References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> <685B8131-2A3F-4B07-AD56-2CA999EE0BBF@ICSI.Berkeley.EDU> <9A60997E-2F1D-4AE2-AD7E-310F46ED4E9C@rfc1035.com> <58470CC8-8973-43ED-8BC6-CD00FBC51095@ICSI.Berkeley.EDU> Date: Thu, 15 Apr 2010 08:48:58 -0700 To: Nicholas Weaver From: Paul Hoffman Subject: [dnsext] Re: stupid DNS tricks for fun and profit Cc: IETF DNSEXT WG 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 8:17 AM -0700 4/15/10, Nicholas Weaver wrote: >There are two other alternatives on the table: > >1: The third party resolvers make pairwise agreements with authorities without creating a standard, acting as a lock-in for just these third party resolvers > >2: Say "third party resolvers should be at a fundamental disadvantage when compared with ISP resolvers" The third alternative mentioned (one that I support) is "This should not be dealt with in the DNS, it should be dealt with in application protocols using their built-in redirection functionality". --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Thu Apr 15 09:19:07 2010 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 4FA983A6767; Thu, 15 Apr 2010 09:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.69 X-Spam-Level: X-Spam-Status: No, score=-4.69 tagged_above=-999 required=5 tests=[AWL=0.358, 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 g2F+2Q4XsHYu; Thu, 15 Apr 2010 09:19:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 086883A693F; Thu, 15 Apr 2010 09:19:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Rhn-000Oti-VG for namedroppers-data0@psg.com; Thu, 15 Apr 2010 16:14:16 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Rhk-000OtF-W0 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 16:14:13 +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 o3FGECoK025999; Thu, 15 Apr 2010 09:14:12 -0700 (PDT) References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> <685B8131-2A3F-4B07-AD56-2CA999EE0BBF@ICSI.Berkeley.EDU> <9A60997E-2F1D-4AE2-AD7E-310F46ED4E9C@rfc1035.com> <58470CC8-8973-43ED-8BC6-CD00FBC51095@ICSI.Berkeley.EDU> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <9FF40521-55EF-4AC1-A52A-1907AF8D9525@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , IETF DNSEXT WG From: Nicholas Weaver Subject: Re: [dnsext] Re: stupid DNS tricks for fun and profit Date: Thu, 15 Apr 2010 09:14:12 -0700 To: Paul Hoffman X-Mailer: Apple Mail (2.1078) 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 Apr 15, 2010, at 8:48 AM, Paul Hoffman wrote: > At 8:17 AM -0700 4/15/10, Nicholas Weaver wrote: >> There are two other alternatives on the table: >>=20 >> 1: The third party resolvers make pairwise agreements with = authorities without creating a standard, acting as a lock-in for just = these third party resolvers >>=20 >> 2: Say "third party resolvers should be at a fundamental = disadvantage when compared with ISP resolvers" >=20 > The third alternative mentioned (one that I support) is "This should = not be dealt with in the DNS, it should be dealt with in application = protocols using their built-in redirection functionality". That is NOT a viable alternative. a: Application level redirects do not work: the additional RTTs = involved will often offset the latency savings of being redirected to = the proper server. Remember, an application-level redirect requires two = wasted RTTs to the bad-latency server before the application gets to the = good-latency server. b: Even if the RTTs did not swamp the latency savings, you'd need to = change ALL the web browsers to replace a mechanism that ALREADY WORKS = TODAY using "stupid DNS tricks" for everyone except those using third = party resolvers. This is because HTTP redirects (the 3xx status codes) are all designed = to specify a new URL location, and none of them provide the necessary = mechanism: telling the browser to use the SAME URL but to use a = different IP address for the hostname portion of the URL. From owner-namedroppers@ops.ietf.org Thu Apr 15 09:50:12 2010 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 BF5C63A6BA8; Thu, 15 Apr 2010 09:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.977 X-Spam-Level: X-Spam-Status: No, score=-4.977 tagged_above=-999 required=5 tests=[AWL=-0.482, 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 HP+FH+0NBxP2; Thu, 15 Apr 2010 09:50:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6A463A683B; Thu, 15 Apr 2010 09:50:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2SDG-0006C1-Qz for namedroppers-data0@psg.com; Thu, 15 Apr 2010 16:46:46 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2SDE-0006BW-9V for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 16:46:44 +0000 Received: from [75.101.18.87] (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 o3FGkfs7028177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Apr 2010 09:46:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <9FF40521-55EF-4AC1-A52A-1907AF8D9525@ICSI.Berkeley.EDU> References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> <685B8131-2A3F-4B07-AD56-2CA999EE0BBF@ICSI.Berkeley.EDU> <9A60997E-2F1D-4AE2-AD7E-310F46ED4E9C@rfc1035.com> <58470CC8-8973-43ED-8BC6-CD00FBC51095@ICSI.Berkeley.EDU> <9FF40521-55EF-4AC1-A52A-1907AF8D9525@ICSI.Berkeley.EDU> Date: Thu, 15 Apr 2010 09:46:40 -0700 To: Nicholas Weaver From: Paul Hoffman Subject: Re: [dnsext] Re: stupid DNS tricks for fun and profit Cc: Nicholas Weaver , IETF DNSEXT WG 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:14 AM -0700 4/15/10, Nicholas Weaver wrote: >a: Application level redirects do not work: Soooo, the last 15 years of HTTP deployment is a failure? I'm not sure how you justify that statement. > the additional RTTs involved will often offset the latency savings of being redirected to the proper server. How did you measure "often" there? To be specific, why would an HTTP server use a redirect that would make the user's experience worse? These are people who measure such things much more carefully than the DNS world does. To be sure, it is easy to make bad choices for application-level redirection, but that doesn't mean that those bad choices happen often. > Remember, an application-level redirect requires two wasted RTTs to the bad-latency server before the application gets to the good-latency server. For some applications, such as the web, two wasted RTTs is minor relative to the gain achieved for a web page with a dozen images on it. For others, two wasted RTTs is always just waste. >b: Even if the RTTs did not swamp the latency savings, you'd need to change ALL the web browsers to replace a mechanism that ALREADY WORKS TODAY using "stupid DNS tricks" for everyone except those using third party resolvers. > >This is because HTTP redirects (the 3xx status codes) are all designed to specify a new URL location, and none of them provide the necessary mechanism: telling the browser to use the SAME URL but to use a different IP address for the hostname portion of the URL. This is a complete non sequitur. The desire of the web site is to give the user the data at the closes location. They could care less whether that is done with the same domain name in the URL. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Thu Apr 15 10:14:07 2010 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 C5A7E3A69C3; Thu, 15 Apr 2010 10:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.707 X-Spam-Level: X-Spam-Status: No, score=-4.707 tagged_above=-999 required=5 tests=[AWL=0.341, 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 2zpW8NPgTkCt; Thu, 15 Apr 2010 10:14:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B7E9F3A6B09; Thu, 15 Apr 2010 10:13:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2SZN-000CBW-Nx for namedroppers-data0@psg.com; Thu, 15 Apr 2010 17:09:37 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2SZL-000C9k-2R for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 17:09:35 +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 o3FH9XPB006149; Thu, 15 Apr 2010 10:09:33 -0700 (PDT) References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> <685B8131-2A3F-4B07-AD56-2CA999EE0BBF@ICSI.Berkeley.EDU> <9A60997E-2F1D-4AE2-AD7E-310F46ED4E9C@rfc1035.com> <58470CC8-8973-43ED-8BC6-CD00FBC51095@ICSI.Berkeley.EDU> <9FF40521-55EF-4AC1-A52A-1907AF8D9525@ICSI.Berkeley.EDU> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , IETF DNSEXT WG From: Nicholas Weaver Subject: Re: [dnsext] Re: stupid DNS tricks for fun and profit Date: Thu, 15 Apr 2010 10:09:33 -0700 To: Paul Hoffman X-Mailer: Apple Mail (2.1078) 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 Apr 15, 2010, at 9:46 AM, Paul Hoffman wrote: > At 9:14 AM -0700 4/15/10, Nicholas Weaver wrote: >> a: Application level redirects do not work: >=20 > Soooo, the last 15 years of HTTP deployment is a failure? I'm not sure = how you justify that statement. For the purpose of shaving 20-50ms off of the RTTs it doesn't work. = Because if it did, there wouldn't be a call for the "stupid DNS tricks". >> Remember, an application-level redirect requires two wasted RTTs to = the bad-latency server before the application gets to the good-latency = server. >=20 > For some applications, such as the web, two wasted RTTs is minor = relative to the gain achieved for a web page with a dozen images on it. = For others, two wasted RTTs is always just waste. With a dozen images to the same host, you aren't necessarily dealing = with 1+ RTT per image because the browser will fetch over multiple = parallel TCP streams, not to mention HTTP pipelining (Opera does it = quite happily. Chrome will probably add it rather soon, given the = performance-obsession Google has). And why waste two RTTs at all, when the authority can just redirect the = user to the right place, WHICH WORKS TODAY! >> b: Even if the RTTs did not swamp the latency savings, you'd need to = change ALL the web browsers to replace a mechanism that ALREADY WORKS = TODAY using "stupid DNS tricks" for everyone except those using third = party resolvers. >>=20 >> This is because HTTP redirects (the 3xx status codes) are all = designed to specify a new URL location, and none of them provide the = necessary mechanism: telling the browser to use the SAME URL but to use = a different IP address for the hostname portion of the URL. >=20 > This is a complete non sequitur. The desire of the web site is to give = the user the data at the closes location. They could care less whether = that is done with the same domain name in the URL. It is not a non-sequiter: URLs are items which are exported to the user = through various means. =20 Because there is no way to change just the notion of "host identity" in = the redirects, redirects don't work for this fine-grained load-balancing = unless it is OK to export node identity to the user, while actually = exposing such items in the URL is very VERY bad site design. Do you honestly think it would be OK for www.google.com to redirect to = 1e100-32471.google.com in the URL? Because the problem is, any HTTP redirect to a different IP address must = export a DIFFERENT hostname in the URL, and this shows up to the user in = many different places (address bar, cut & paste of URLs, etc). From owner-namedroppers@ops.ietf.org Thu Apr 15 10:31:37 2010 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 5200C3A683B; Thu, 15 Apr 2010 10:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.954 X-Spam-Level: X-Spam-Status: No, score=-4.954 tagged_above=-999 required=5 tests=[AWL=-0.459, 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 s09kVP0N51F0; Thu, 15 Apr 2010 10:31:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 39AC43A6B88; Thu, 15 Apr 2010 10:31:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2SqO-000GVS-Gj for namedroppers-data0@psg.com; Thu, 15 Apr 2010 17:27:12 +0000 Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2SqL-000GV7-NB for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 17:27:09 +0000 Received: from [75.101.18.87] (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 o3FHR6Ll031459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Apr 2010 10:27:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> <685B8131-2A3F-4B07-AD56-2CA999EE0BBF@ICSI.Berkeley.EDU> <9A60997E-2F1D-4AE2-AD7E-310F46ED4E9C@rfc1035.com> <58470CC8-8973-43ED-8BC6-CD00FBC51095@ICSI.Berkeley.EDU> <9FF40521-55EF-4AC1-A52A-1907AF8D9525@ICSI.Berkeley.EDU> Date: Thu, 15 Apr 2010 10:27:04 -0700 To: Nicholas Weaver From: Paul Hoffman Subject: Re: [dnsext] Re: stupid DNS tricks for fun and profit Cc: Nicholas Weaver , IETF DNSEXT WG 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:09 AM -0700 4/15/10, Nicholas Weaver wrote: >For the purpose of shaving 20-50ms off of the RTTs it doesn't work. Because if it did, there wouldn't be a call for the "stupid DNS tricks". This is, in my mind, the crux of the issue. The reason that there is a call for "stupid DNS tricks" is because DNS people see themselves and their technology as the saviors of applications. Application people (of which I used to be one) have our own bag of "stupid application protocol tricks". Is this work motivated by applications people asking for help? If so, I apologize for missing it. >And why waste two RTTs at all, when the authority can just redirect the user to the right place, WHICH WORKS TODAY! Because "the right place" is being determined by someone who, if they make a mistake, are not the ones being hurt by the mistake. >Do you honestly think it would be OK for www.google.com to redirect to 1e100-32471.google.com in the URL? Yes, I do. I honestly think that is up to Google. If Google wants help from the DNS folk so that they don't have to do that redirection, I would want to hear their requirements and then design a protocol from it. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Thu Apr 15 10:35:37 2010 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 C36973A66B4; Thu, 15 Apr 2010 10:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.723 X-Spam-Level: X-Spam-Status: No, score=-4.723 tagged_above=-999 required=5 tests=[AWL=0.325, 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 TH+WJN-VmHpw; Thu, 15 Apr 2010 10:35:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C13433A6781; Thu, 15 Apr 2010 10:35:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2SvN-000HkS-S8 for namedroppers-data0@psg.com; Thu, 15 Apr 2010 17:32:21 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2SvL-000Hjw-8b for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 17:32:19 +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 o3FHWIRT010833; Thu, 15 Apr 2010 10:32:18 -0700 (PDT) References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> <685B8131-2A3F-4B07-AD56-2CA999EE0BBF@ICSI.Berkeley.EDU> <9A60997E-2F1D-4AE2-AD7E-310F46ED4E9C@rfc1035.com> <58470CC8-8973-43ED-8BC6-CD00FBC51095@ICSI.Berkeley.EDU> <9FF40521-55EF-4AC1-A52A-1907AF8D9525@ICSI.Berkeley.EDU> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , IETF DNSEXT WG From: Nicholas Weaver Subject: Re: [dnsext] Re: stupid DNS tricks for fun and profit Date: Thu, 15 Apr 2010 10:32:17 -0700 To: Paul Hoffman X-Mailer: Apple Mail (2.1078) 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 Apr 15, 2010, at 10:27 AM, Paul Hoffman wrote: > At 10:09 AM -0700 4/15/10, Nicholas Weaver wrote: >> For the purpose of shaving 20-50ms off of the RTTs it doesn't work. = Because if it did, there wouldn't be a call for the "stupid DNS tricks". >=20 > This is, in my mind, the crux of the issue. The reason that there is a = call for "stupid DNS tricks" is because DNS people see themselves and = their technology as the saviors of applications. Application people (of = which I used to be one) have our own bag of "stupid application protocol = tricks". >=20 > Is this work motivated by applications people asking for help? If so, = I apologize for missing it. No, its motivated by third party resolver providers wanting to be on an = equal footing with ISP-provided resolvers in terms of total user = experience. >> Do you honestly think it would be OK for www.google.com to redirect = to 1e100-32471.google.com in the URL? >=20 > Yes, I do. I honestly think that is up to Google. If Google wants help = from the DNS folk so that they don't have to do that redirection, I = would want to hear their requirements and then design a protocol from = it. You've got to be kidding. You mean you want URLs like http://1e100-32715.google.com/ exported to the user and spewed throughout the browser? Because thats = what happens if you try to use HTTP-redirects for this purpose without = changing both the browsers and the servers. From owner-namedroppers@ops.ietf.org Thu Apr 15 10:58:13 2010 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 77D613A6B02; Thu, 15 Apr 2010 10:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=0.509, 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 seKFS935G5l4; Thu, 15 Apr 2010 10:58:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F7AE28C1EF; Thu, 15 Apr 2010 10:58:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2TFf-000MwC-GE for namedroppers-data0@psg.com; Thu, 15 Apr 2010 17:53:19 +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.71 (FreeBSD)) (envelope-from ) id 1O2TFd-000Mvl-8G for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 17:53:17 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 3200BA2145 for ; Thu, 15 Apr 2010 17:53:16 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? In-Reply-To: Your message of "Thu, 15 Apr 2010 14:44:37 +0200." <20100415124437.GA13005@merboo.mamista.net> References: <25542.1271271658@nsa.vix.com> <20100415115735.GA10252@merboo.mamista.net> <20100415124437.GA13005@merboo.mamista.net> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 15 Apr 2010 17:53:16 +0000 Message-ID: <1725.1271353996@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 Apr 2010 14:44:37 +0200 > From: Martin Barry > ... > There is some privacy concerns with exposing more information about the > client to the authorative DNS server but I am of the opinion that users > would trade that for the better performance of the service they are > connecting to. for several reasons, i am of the opinion that this preference ("would trade") be expressed explicitly, with an option that must be presented by the application and stub resolver. see my basenote on this thread. From owner-namedroppers@ops.ietf.org Thu Apr 15 11:05:15 2010 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 D5CCA3A684A; Thu, 15 Apr 2010 11:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=0.494, 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 iRdXjXG-XWEw; Thu, 15 Apr 2010 11:05:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 918BA3A68E2; Thu, 15 Apr 2010 11:05:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2TNu-000PTo-OT for namedroppers-data0@psg.com; Thu, 15 Apr 2010 18:01:50 +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.71 (FreeBSD)) (envelope-from ) id 1O2TNq-000PSK-L0 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 18:01:46 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5EC24A213B for ; Thu, 15 Apr 2010 18:01:46 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? In-Reply-To: Your message of "Thu, 15 Apr 2010 09:22:09 -0400." References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <42609.1271286871@nsa.vix.com> <68305.1271306680@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 15 Apr 2010 18:01:46 +0000 Message-ID: <2183.1271354506@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: John Payne > Date: Thu, 15 Apr 2010 09:22:09 -0400 > > >> Sorry if I missed the problem statement, but are you trying to guess > >> at what "stupid dns tricks" are used for and why the client IP is > >> useful in some limited corner cases and design to that, or is this an > >> entirely different issue than the edns-client-subnet proposal? > > > > neither. > > So what is it? the internet is much older and larger than the web, and dns serves many applications other than the web. from dns's perspective, the web is just a flash in the pan. my problem statement is, how can we address the needs of enduser-context-sensitive applications, of which the web is an example but so is voip and the sky's the limit for future such apps, in a way that does not change today's default for enduser privacy and which admits the use of many factors not just ip addresses as enduser context data. see my basenote on this thread. in the time since writing it nobody has shown any interest in a real i-d, so i'll repeat my final statement again: > i can write a -00 i-d along these lines if there's general interest in it. From owner-namedroppers@ops.ietf.org Thu Apr 15 11:31:53 2010 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 451363A6B6E; Thu, 15 Apr 2010 11:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.944 X-Spam-Level: X-Spam-Status: No, score=-102.944 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 wwK7e14WMxVc; Thu, 15 Apr 2010 11:31:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 469513A6A1C; Thu, 15 Apr 2010 11:31:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Tkv-0005Gs-NV for namedroppers-data0@psg.com; Thu, 15 Apr 2010 18:25:37 +0000 Received: from [216.239.44.51] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2Tkp-0005En-V2 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 18:25:32 +0000 Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o3FIPSs8017389 for ; Thu, 15 Apr 2010 11:25:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1271355930; bh=ZQ84irs3VHPBw0BGGxfHbPCDoxE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=e6Xr2j7mzgP5WEwL+FOaGO4X4qjOoDFIdVYKRaS3BDAJoYcZRPhCrjfWuN/NzMaL2 qeX5/680ht2AfQJlVLa4A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=IXHed3ULs6ErkhMPLwPdlVHRtLzrpnzuHPmZkAvqBs044w5NZy7LTXdUBPx2xnU7A zICbL56g687/K0ReVMp7Q== Received: from ywh31 (ywh31.prod.google.com [10.192.8.31]) by wpaz13.hot.corp.google.com with ESMTP id o3FIPRiL014223 for ; Thu, 15 Apr 2010 11:25:27 -0700 Received: by ywh31 with SMTP id 31so809272ywh.3 for ; Thu, 15 Apr 2010 11:25:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.202.2 with HTTP; Thu, 15 Apr 2010 11:25:07 -0700 (PDT) In-Reply-To: References: <25542.1271271658@nsa.vix.com> <685B8131-2A3F-4B07-AD56-2CA999EE0BBF@ICSI.Berkeley.EDU> <9A60997E-2F1D-4AE2-AD7E-310F46ED4E9C@rfc1035.com> <58470CC8-8973-43ED-8BC6-CD00FBC51095@ICSI.Berkeley.EDU> <9FF40521-55EF-4AC1-A52A-1907AF8D9525@ICSI.Berkeley.EDU> From: Carlo Contavalli Date: Thu, 15 Apr 2010 11:25:07 -0700 Received: by 10.151.29.6 with SMTP id g6mr593452ybj.314.1271355927109; Thu, 15 Apr 2010 11:25:27 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Re: stupid DNS tricks for fun and profit To: Paul Hoffman Cc: Nicholas Weaver , IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true 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: Regardless of the reason behind those tricks, those tricks are being used by *a whole lot of sites*, and impact a *whole lot of users*. Those sites do not use http redirects. 3rd party resolvers are victims of those tricks as well, as they can't provide good latency and good locality to their users. IMHO, we have 3 alternatives: 1 - ignore the problem, leave 3rd party resolvers on their own, 2 - get rid of dns tricks, 3 - provide a standardized mechanism so those tricks can at least be worked around. 2 - I don't believe is achievable by any of us, regardless of it being a good or bad idea. 1 - I think in the long term is bad, there's already proprietary protocols to try to work around those problems, which is not good for the market, for the internet, or for its users. 3 - that's what we've been trying to do with the edns-client-ip draft. Carlo From owner-namedroppers@ops.ietf.org Thu Apr 15 11:34:06 2010 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 1FA083A69D6; Thu, 15 Apr 2010 11:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.885 X-Spam-Level: ** X-Spam-Status: No, score=2.885 tagged_above=-999 required=5 tests=[AWL=4.722, BAYES_50=0.001, 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 dDYpvrpxE3Li; Thu, 15 Apr 2010 11:34:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 28F383A6A1A; Thu, 15 Apr 2010 11:34:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2ToN-00065M-Vb for namedroppers-data0@psg.com; Thu, 15 Apr 2010 18:29:11 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2ToK-00064y-Iw for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 18:29:08 +0000 Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 1877CA94547; Thu, 15 Apr 2010 18:29:08 +0000 (UTC) Message-ID: <4BC75AF3.4070408@mail-abuse.org> Date: Thu, 15 Apr 2010 11:29:07 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Hoffman CC: Nicholas Weaver , IETF DNSEXT WG Subject: Re: [dnsext] Re: stupid DNS tricks for fun and profit References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> <685B8131-2A3F-4B07-AD56-2CA999EE0BBF@ICSI.Berkeley.EDU> <9A60997E-2F1D-4AE2-AD7E-310F46ED4E9C@rfc1035.com> <58470CC8-8973-43ED-8BC6-CD00FBC51095@ICSI.Berkeley.EDU> 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 4/15/10 8:48 AM, Paul Hoffman wrote: > At 8:17 AM -0700 4/15/10, Nicholas Weaver wrote: > >> There are two other alternatives on the table: >> >> 1: The third party resolvers make pairwise agreements with authorities without creating a standard, acting as a lock-in for just these third party resolvers >> >> 2: Say "third party resolvers should be at a fundamental disadvantage when compared with ISP resolvers" >> > The third alternative mentioned (one that I support) is "This should not be dealt with in the DNS, it should be dealt with in application protocols using their built-in redirection functionality". > Paul, I admit to being confused by your statement. Say someone has a business card with a domain name published in DNS using A-Labels printed using easier to read upper-case font. For IDNA2003, it would help people to generate valid A-Labels. With IDNA2008, would a person be expected to enter the name using lower case input? Are you suggesting for say a Cyrillic domain of "example", there should be servers located at "EXAMPLE", "Example", "eXample", etc that redirect or forward back to "example"? Of course even this solution still faces the task of generating zones that service aliases for IDNA2008 names. In other words, incompatibility resolution still largely represents an administrative effort mainly within DNS. The Amber/Shadow zone approach seems to offer the fewest issues related to security, and support of existing standards. Unless DNS is able to collapse many aliases of "Example" back into "example", this will cause an otherwise "surprising" NXDOMAIN result instead of locating desired services and likely require an expensive level of support. At least once a server is located, it will likely already deal with its many new aliases by default. Once again, the simplest solution appears to be the Amber/Shadow zone approach. I could be wrong, and perhaps we are agreeing that applications are not ready to rewrite aliased domains. -Doug From owner-namedroppers@ops.ietf.org Thu Apr 15 11:34:33 2010 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 A77743A6A1A; Thu, 15 Apr 2010 11:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[AWL=-0.309, 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 mmXnPsKsAVTE; Thu, 15 Apr 2010 11:34:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B7203A69D6; Thu, 15 Apr 2010 11:34:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2TlY-0005Ps-LJ for namedroppers-data0@psg.com; Thu, 15 Apr 2010 18:26:16 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2TlU-0005Nk-JJ for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 18:26:13 +0000 Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3FIQBHh067389 for ; Thu, 15 Apr 2010 14:26:11 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4BC75A3B.8070605@ogud.com> Date: Thu, 15 Apr 2010 14:26:03 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "DNSEXT IETF wg" Subject: Re: [dnsext] Re: stupid DNS tricks for fun and profit References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> <685B8131-2A3F-4B07-AD56-2CA999EE0BBF@ICSI.Berkeley.EDU> <9A60997E-2F1D-4AE2-AD7E-310F46ED4E9C@rfc1035.com> <58470CC8-8973-43ED-8BC6-CD00FBC51095@ICSI.Berkeley.EDU> <9FF40521-55EF-4AC1-A52A-1907AF8D9525@ICSI.Berkeley.EDU> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 noise to signal level in this thread is quite low. Please stop sending content light/free messages and wasting everyone's time to the mailing list. As a matter of working group process, please refrain from posting any more on topics related to draft-vandergaast-edns-client-ip-00.txt until/if version 01 is posted. Olafur From owner-namedroppers@ops.ietf.org Thu Apr 15 12:15:24 2010 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 A7CF13A6818; Thu, 15 Apr 2010 12:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.311 X-Spam-Level: * X-Spam-Status: No, score=1.311 tagged_above=-999 required=5 tests=[AWL=3.148, BAYES_50=0.001, 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 Q7oRrhJZ7avT; Thu, 15 Apr 2010 12:15:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F0DE63A67FF; Thu, 15 Apr 2010 12:15:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2USU-000G0h-Ep for namedroppers-data0@psg.com; Thu, 15 Apr 2010 19:10:38 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2USS-000Fy4-2M for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 19:10:36 +0000 Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id CB6DDA9457E; Thu, 15 Apr 2010 19:10:35 +0000 (UTC) Message-ID: <4BC764AB.6030504@mail-abuse.org> Date: Thu, 15 Apr 2010 12:10:35 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] open issues on SHADOW References: <26794.1271273460@nsa.vix.com> <46386.1271289256@nsa.vix.com> In-Reply-To: <46386.1271289256@nsa.vix.com> 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 4/14/10 4:54 PM, Paul Vixie wrote: >> Date: Wed, 14 Apr 2010 15:16:01 -0700 >> From: Douglas Otis >> >> Just as there is meta information placed in the Amber zones to enumerate >> Shadow zones, there could be meta information placed in Shadows to >> confirm expected receipt of the Amber zone. Perhaps the Shadow meta >> information could include a time frame where at least a null transfer >> must occur or an error would be reported. >> > this amounts to a maximum time limit enforced in the secondary as to how > much time can elapse between a NOTIFY for the Amber and the last NOTIFY > for a Shadow, and i think this should be a server level configuration > item since the secondary server operator is the one who will get the > error notifications. > The set of Shadow zones should be fairly constant, where administrative saving occurs when content of Amber zones change. Currently, this scheme has an open definition with respect to update rates and access allowance delays. A simple interval statement could help suppress errors generated by the respective Amber or Shadow servers, since configurations that relate to update rates and access control delays are not likely visible between servers. There is also the possible side effect of making the Shadow recognizable with the presences of a vector to the Amber zone containing an error hold-off interval. The idea is to make it easier to manage by affording a way to suppress errors. -Doug From owner-namedroppers@ops.ietf.org Thu Apr 15 12:45:48 2010 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 1AC1E3A6B80; Thu, 15 Apr 2010 12:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 dpq7S2f6n2-C; Thu, 15 Apr 2010 12:45:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 06BAC3A6B02; Thu, 15 Apr 2010 12:45:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2UvU-000MSW-UT for namedroppers-data0@psg.com; Thu, 15 Apr 2010 19:40:36 +0000 Received: from [216.239.44.51] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2UvS-000MPq-DH for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 19:40:34 +0000 Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o3FJeVEv020121 for ; Thu, 15 Apr 2010 12:40:32 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1271360432; bh=/pc6CyZcFESIbsdgk0SIsR5FE0o=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=P/0wCErIrQ93sxq9ViKXSwmh+wPOBJ083Vg/vnrQrSfEvgdw4xPH84Uxyc42BMC0K WJMgyAQeLz8HkiZzezJzA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=TAcwc4qIKmT3d9zgirDn/tjSUAXW3BJ4zyoSXhrtz8J6TGKbAuGGJ4nngFRKVbt+O JHfPwtpjkYOYP6FOXczEQ== Received: from yxe42 (yxe42.prod.google.com [10.190.2.42]) by wpaz13.hot.corp.google.com with ESMTP id o3FJeUqq016007 for ; Thu, 15 Apr 2010 12:40:30 -0700 Received: by yxe42 with SMTP id 42so931870yxe.24 for ; Thu, 15 Apr 2010 12:40:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.202.2 with HTTP; Thu, 15 Apr 2010 12:40:09 -0700 (PDT) In-Reply-To: <2183.1271354506@nsa.vix.com> References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <42609.1271286871@nsa.vix.com> <68305.1271306680@nsa.vix.com> <2183.1271354506@nsa.vix.com> From: Carlo Contavalli Date: Thu, 15 Apr 2010 12:40:09 -0700 Received: by 10.150.187.6 with SMTP id k6mr643456ybf.254.1271360430151; Thu, 15 Apr 2010 12:40:30 -0700 (PDT) Message-ID: Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? To: Paul Vixie Cc: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true 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, Apr 15, 2010 at 11:01 AM, Paul Vixie wrote: >> i can write a -00 i-d along these lines if there's general interest in it. uhm .. a draft defining a single option, that can carry structured data, which would probably look something like 'type-of-information' (however expressed), 'length-of-data', 'arbitrary-data', in a way that servers can ignore fields they can't parse? isn't this edns0? eg, today we're defining an edns0 option to carry the subnet of the client. Tomorrow, if you really believe it's a good idea and there's the need for it, you're free to define an edns0 option to carry the gps coordinates of the client? or the language of the client? Why an additional draft? Also, earlier I read: """ if a browser, or stub resolver, or operating system, or NAT/ALG box, were to strip off this blob, or to add it without the user's permission, then the user would have recourse against those technology or service providers ("you are in violation of RFC XYZ, please fix your product/service") and the strippage/addage would be detectable using outside services like ICSI's. """ the strippage/addage would be as detectable using outside services like ICSI's as with the current edns-client-ip draft, especially if those stub resolvers or NAT box only twiddle those options when talking to certain servers. The only difference I can see here is that instead of allowing recursive resolvers to add the option, you tell the clients to do so. Which IMHO is worse in terms of complexity - now *all* recursive resolvers and caches need to deal with it. "you are in violation of RFC xyz" is also a pretty weak form of protection. Eg, every time I connect to a hotspot, download my emails, or go to bbc.co.uk there are *several* rfcs being *violated*. If this line of defense worked, we could probably just ask any of those sites to get rid of the dns tricks. I strongly disagree that this would be better for privacy. It would mostly create a false sense of security. As I was pointing out in other threads, there's nothing to prevent a provider, isp, or recursive resolver from using arbitrary extensions or proprietary protocols when talking to other 3rd parties, regardless of the existence of a standardized protocol to do so. What you're really looking for is an agreement with your ISP saying "you will not give my data to 3rd parties without my consent". If anything, a standardized protocol brings awareness and visibility into those issues, and encourages open policies. Carlo From owner-namedroppers@ops.ietf.org Thu Apr 15 13:53:20 2010 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 827973A691A; Thu, 15 Apr 2010 13:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.445 X-Spam-Level: X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=0.050, 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 um9MuzKNeGv7; Thu, 15 Apr 2010 13:53:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C5B093A68C3; Thu, 15 Apr 2010 13:53:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2VyY-000Csy-79 for namedroppers-data0@psg.com; Thu, 15 Apr 2010 20:47:50 +0000 Received: from [209.85.210.186] (helo=mail-yx0-f186.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2VyR-000CpR-O0 for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 20:47:43 +0000 Received: by yxe16 with SMTP id 16so1025442yxe.9 for ; Thu, 15 Apr 2010 13:47:42 -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:received:message-id:subject:from:to:cc:content-type; bh=OfaJ4odMgi3SqPiaBCfgbb+J0nCTVsKEHUFyBNj/qHM=; b=n9vjku5BEYTdtoHi9/xh7pGc1mruNbYRFGVWXxIbDeyiFHsiL0yD9ebpEFXDqrjuty saMohDxHdVH3w7Jj5WGMCu/vg0hXT55UuEgKcJIHJxDZuz34arKrjaL9SP0PDnXqZZzQ Ka4iPA6AQuVpPAnzOWM75ZaADHpAVUwv7X7gg= 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 :cc:content-type; b=CXEdsjfPEs8efg54+Rw8KlEcNbhq92G13Gj4BJQ1PGcqCHwxPxJqxxznoGRiWD3gNp /zKaoIP1kmk9Qv8QtX4xoV87UZ5cEoshplwpa85UqX/rxWZiOn2qxFSnqyahKsziHV7v QGerN1+UZT8woLU7wKQ1ljleDtqdLQunMpNPc= MIME-Version: 1.0 Received: by 10.100.91.5 with HTTP; Thu, 15 Apr 2010 13:47:35 -0700 (PDT) In-Reply-To: References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> Date: Thu, 15 Apr 2010 17:47:35 -0300 Received: by 10.101.192.2 with SMTP id u2mr1209420anp.202.1271364456214; Thu, 15 Apr 2010 13:47:36 -0700 (PDT) Message-ID: Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? From: Brian Dickson To: Jim Reid Cc: Nicholas Weaver , John Payne , IETF DNSEXT WG 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: The issue of "third-party" resolvers is a misnomer, in some necessary, common use cases: Split-network VPN (where VPN traffic goes over a tunnel of some kind, and "Internet" traffic goes directly out the end-user's ISP). In those instances, it is strictly necessary that DNS resolvers on the VPN-side of things (i.e. over the tunnel to arbitrarily-distant resolver(s)) be used. And this exposes the user to DNS/data path divergence, and the attendant problems if DNS tricks (stupid or otherwise) get used. Please keep this in mind when discussing issues like this. A significant portion of the on-line users (and a very significant portion of corporate-supported users) have this as a firm requirement. Just in case the straw-man of "google DNS" or "openDNS" distracts from the fact that real issues exist and are not (strictly or otherwise) "opt-in" - and neither are they "opt-out". They are "this needs to work". Brian On Thu, Apr 15, 2010 at 10:29 AM, Jim Reid wrote: > On 15 Apr 2010, at 14:20, Nicholas Weaver wrote: > >> The question is, should users be penalized for using NON AFFILIATED DNS >> resolvers: Namely, should OpenDNS and Google Public DNS continue to return >> consistently inferior results? > > IMO, people should be free to choose for themselves. If they select > providers that do evil/stupid things, economic Darwinism will take care of > that without any help from this WG. > > From cravatshk@jkcs.net Thu Apr 15 13:55:47 2010 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 2DB693A694A; Thu, 15 Apr 2010 13:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.64 X-Spam-Level: X-Spam-Status: No, score=-76.64 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RELAY_IS_220=2.118, 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 o2PVz+kNliqY; Thu, 15 Apr 2010 13:55:46 -0700 (PDT) Received: from p2011-ipbffx01kyoto.kyoto.ocn.ne.jp (p2011-ipbffx01kyoto.kyoto.ocn.ne.jp [220.97.97.139]) by core3.amsl.com (Postfix) with ESMTP id 7C8253A6908; Thu, 15 Apr 2010 13:55:45 -0700 (PDT) Received: from 220.97.97.139 by mail.jkcs.net; Fri, 16 Apr 2010 05:55:15 +0900 Date: Fri, 16 Apr 2010 05:55:15 +0900 From: dnsext-archive@ietf.org Subject: Hundreds of profiles of Russian hotties. To: Message-ID: <000d01cadcdd$f2f6bca0$6400a8c0@cravatshk> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal You don't have to change your life around just to get time to meet someone. There are over 7 million members on sexywebdating's online community. Hell in my state alone there are close to 200 THOUSAND active members meeting their perfect match 24 hours 7 days a week inside this tight knit match making heaven. http://breccia004.spaces.live.com Jefferson, Montana From diffserv-interest-bounces@ietf.org Thu Apr 15 13:55:49 2010 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F073A6807 for ; Thu, 15 Apr 2010 13:55:49 -0700 (PDT) Subject: The results of your email commands From: diffserv-interest-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0094345206==" Message-ID: Date: Thu, 15 Apr 2010 13:55:47 -0700 Precedence: bulk X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.1.9 List-Id: Differentiated services general discussion X-List-Administrivia: yes Sender: diffserv-interest-bounces@ietf.org Errors-To: diffserv-interest-bounces@ietf.org --===============0094345206== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://breccia004.spaces.live.com Jefferson, Montana - Done. --===============0094345206== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: diffserv-interest-request@core3.amsl.com Delivered-To: diffserv-interest-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DB693A694A; Thu, 15 Apr 2010 13:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.64 X-Spam-Level: X-Spam-Status: No, score=-76.64 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RELAY_IS_220=2.118, 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 o2PVz+kNliqY; Thu, 15 Apr 2010 13:55:46 -0700 (PDT) Received: from p2011-ipbffx01kyoto.kyoto.ocn.ne.jp (p2011-ipbffx01kyoto.kyoto.ocn.ne.jp [220.97.97.139]) by core3.amsl.com (Postfix) with ESMTP id 7C8253A6908; Thu, 15 Apr 2010 13:55:45 -0700 (PDT) Received: from 220.97.97.139 by mail.jkcs.net; Fri, 16 Apr 2010 05:55:15 +0900 Date: Fri, 16 Apr 2010 05:55:15 +0900 From: dnsext-archive@ietf.org Subject: Hundreds of profiles of Russian hotties. To: Message-ID: <000d01cadcdd$f2f6bca0$6400a8c0@cravatshk> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal You don't have to change your life around just to get time to meet someone. There are over 7 million members on sexywebdating's online community. Hell in my state alone there are close to 200 THOUSAND active members meeting their perfect match 24 hours 7 days a week inside this tight knit match making heaven. http://breccia004.spaces.live.com Jefferson, Montana --===============0094345206==-- From dnsop-bounces@ietf.org Thu Apr 15 13:55:49 2010 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E22A3A691A for ; Thu, 15 Apr 2010 13:55:49 -0700 (PDT) Subject: The results of your email commands From: dnsop-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0598367795==" Message-ID: Date: Thu, 15 Apr 2010 13:55:48 -0700 Precedence: bulk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF DNSOP WG mailing list X-List-Administrivia: yes Sender: dnsop-bounces@ietf.org Errors-To: dnsop-bounces@ietf.org --===============0598367795== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: http://breccia004.spaces.live.com Jefferson, Montana - Done. --===============0598367795== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: dnsop-request@core3.amsl.com Delivered-To: dnsop-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DB693A694A; Thu, 15 Apr 2010 13:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.64 X-Spam-Level: X-Spam-Status: No, score=-76.64 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RELAY_IS_220=2.118, 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 o2PVz+kNliqY; Thu, 15 Apr 2010 13:55:46 -0700 (PDT) Received: from p2011-ipbffx01kyoto.kyoto.ocn.ne.jp (p2011-ipbffx01kyoto.kyoto.ocn.ne.jp [220.97.97.139]) by core3.amsl.com (Postfix) with ESMTP id 7C8253A6908; Thu, 15 Apr 2010 13:55:45 -0700 (PDT) Received: from 220.97.97.139 by mail.jkcs.net; Fri, 16 Apr 2010 05:55:15 +0900 Date: Fri, 16 Apr 2010 05:55:15 +0900 From: dnsext-archive@ietf.org Subject: Hundreds of profiles of Russian hotties. To: Message-ID: <000d01cadcdd$f2f6bca0$6400a8c0@cravatshk> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal You don't have to change your life around just to get time to meet someone. There are over 7 million members on sexywebdating's online community. Hell in my state alone there are close to 200 THOUSAND active members meeting their perfect match 24 hours 7 days a week inside this tight knit match making heaven. http://breccia004.spaces.live.com Jefferson, Montana --===============0598367795==-- From cravatshk@jkcs.net Thu Apr 15 13:55:47 2010 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 2DB693A694A; Thu, 15 Apr 2010 13:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.64 X-Spam-Level: X-Spam-Status: No, score=-76.64 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RELAY_IS_220=2.118, 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 o2PVz+kNliqY; Thu, 15 Apr 2010 13:55:46 -0700 (PDT) Received: from p2011-ipbffx01kyoto.kyoto.ocn.ne.jp (p2011-ipbffx01kyoto.kyoto.ocn.ne.jp [220.97.97.139]) by core3.amsl.com (Postfix) with ESMTP id 7C8253A6908; Thu, 15 Apr 2010 13:55:45 -0700 (PDT) Received: from 220.97.97.139 by mail.jkcs.net; Fri, 16 Apr 2010 05:55:15 +0900 Date: Fri, 16 Apr 2010 05:55:15 +0900 From: dnsext-archive@ietf.org Subject: Hundreds of profiles of Russian hotties. To: Message-ID: <000d01cadcdd$f2f6bca0$6400a8c0@cravatshk> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal You don't have to change your life around just to get time to meet someone. There are over 7 million members on sexywebdating's online community. Hell in my state alone there are close to 200 THOUSAND active members meeting their perfect match 24 hours 7 days a week inside this tight knit match making heaven. http://breccia004.spaces.live.com Jefferson, Montana From chive@lists.ietf.org Thu Apr 15 15:35:45 2010 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 AD3F73A690F for ; Thu, 15 Apr 2010 15:35:45 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Thu, 15 Apr 2010 15:35:44 -0700 (PDT) Received: from a-lehdet.fi (unknown [189.73.26.177]) by core3.amsl.com (Postfix) with SMTP id 8A27F3A67B4 for ; Thu, 15 Apr 2010 15:35:40 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100415223542.8A27F3A67B4@core3.amsl.com> Date: Thu, 15 Apr 2010 15:35:40 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 47961 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Thu Apr 15 16:34:20 2010 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 296553A6A6E; Thu, 15 Apr 2010 16:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.652 X-Spam-Level: X-Spam-Status: No, score=-9.652 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HABEAS_ACCREDITED_SOI=-4.3, HELO_MISMATCH_COM=0.553, RCVD_IN_BSP_TRUSTED=-4.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 f+Kgd9-1ea-L; Thu, 15 Apr 2010 16:34:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C907A3A6A97; Thu, 15 Apr 2010 16:34:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2YUe-000MGQ-Fi for namedroppers-data0@psg.com; Thu, 15 Apr 2010 23:29:08 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2YUb-000MG2-5f for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 23:29:05 +0000 Received: (qmail 34827 invoked from network); 15 Apr 2010 23:29:03 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 15 Apr 2010 23:29:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k1004; olt=johnl@user.iecc.com; bh=HSJtq1SgXGCneiYGIkEz8moHA1+Vn0KvfH89iTmB/cU=; b=C7Lz2du+2gYQSt+eIbn+duuvw9PZu9xhUvj+SL8rOaD8mm8tB8CBDgm3laS4j/FPe4Pw7ZpgH9Wk6+wnokdmQZw5nXRSL+3CIHzRro3ASsrIx7sXGRax+5Y1iemP5AtY0vBGWD3rqMee5h43ho2hB7Ospshpf1dUNkPtGXgiYqk= Date: 15 Apr 2010 23:29:00 -0000 Message-ID: <20100415232900.36217.qmail@simone.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: stupid DNS tricks for fun and profit In-Reply-To: Organization: Cc: nweaver@ICSI.Berkeley.EDU X-Headerized: yes Mime-Version: 1.0 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: >You've got to be kidding. You mean you want URLs like > >http://1e100-32715.google.com/ > >exported to the user and spewed throughout the browser? Because >thats what happens if you try to use HTTP-redirects for this purpose >without changing both the browsers and the servers. You say this as though it doesn't already happen several million times a day. R's, John From owner-namedroppers@ops.ietf.org Thu Apr 15 16:35:12 2010 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 E61863A68A0; Thu, 15 Apr 2010 16:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.156 X-Spam-Level: X-Spam-Status: No, score=-0.156 tagged_above=-999 required=5 tests=[AWL=-2.071, BAYES_40=-0.185, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_55=0.6, 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 SpJHhz8C7x+U; Thu, 15 Apr 2010 16:35:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CCC3B3A696C; Thu, 15 Apr 2010 16:35:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2YS8-000Liw-7y for namedroppers-data0@psg.com; Thu, 15 Apr 2010 23:26:32 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2YS4-000LhA-PR for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 23:26:28 +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 A6CA8E8605; Thu, 15 Apr 2010 23:26:26 +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 o3FNQJG1088028; Fri, 16 Apr 2010 09:26:20 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004152326.o3FNQJG1088028@drugs.dv.isc.org> To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Cc: "namedroppers@ops.ietf.org" From: Mark Andrews References: <4BC720DE.8080900@nic.cz> Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 In-reply-to: Your message of "Thu, 15 Apr 2010 16:21:18 +0200." <4BC720DE.8080900@nic.cz> Date: Fri, 16 Apr 2010 09:26:19 +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 <4BC720DE.8080900@nic.cz>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= writes: > Hi, > > I hereby present the "other" solution to name sameness (we all call it > CNAME+DNAME, aren't we?). It's little bit competing with BNAME > proposal, but it should be simpler to implement. It doesn't introduce > new RTYPE, it just loosens the singleton rule of CNAME to allow DNAME > for the same name (we did this before with NSEC+RRSIG, remember?) It doesn't matter if it can be made to work with some resolvers. It is just plain out a bad idea to change the behaviour of existing records unless you really have no choice. With DNSSEC there was no choice because you want to secure the CNAME record. There is a choice here however. > Just FYI, try digging idos.cz (or jizdnirady.cz) before you start > writing this email and think if this proposal really breaks existing > behaviour (if the existing resolvers are able to cope with this). Where's the DNAME in the response? If you want us to believe that it works the DNAME needs to be returned. For good measure it also has to work with a signed zone. It's relatively easy to change named to allow a DNAME and CNAME to co-exist see lib/dns/rbtdb.c:cname_and_other_data(). ; <<>> DiG 9.3.6-P1 <<>> www.idos.cz @ns.dmz.cd.cz +norec ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57649 ;; flags: qr aa ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.idos.cz. IN A ;; ANSWER SECTION: www.idos.cz. 14400 IN CNAME idos.timetable.cz. idos.timetable.cz. 91 IN CNAME cluster.timetable.cz. cluster.timetable.cz. 195 IN A 77.93.209.54 cluster.timetable.cz. 195 IN A 77.93.209.53 ;; Query time: 344 msec ;; SERVER: 81.19.46.20#53(81.19.46.20) ;; WHEN: Fri Apr 16 08:35:47 2010 ;; MSG SIZE rcvd: 112 ; <<>> DiG 9.3.6-P1 <<>> any idos.cz @ns.dmz.cd.cz ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46373 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4 ;; QUESTION SECTION: ;idos.cz. IN ANY ;; ANSWER SECTION: idos.cz. 14400 IN NS mail.dmz.cd.cz. idos.cz. 14400 IN NS ns.dmz.cd.cz. idos.cz. 14400 IN CNAME idos.timetable.cz. idos.cz. 14400 IN SOA ns.dmz.cd.cz. hostmaster.dmz.cd.cz. 2008062337 3600 900 604800 14400 ;; ADDITIONAL SECTION: mail.dmz.cd.cz. 14400 IN A 81.19.46.25 mail.dmz.cd.cz. 14400 IN A 81.19.46.24 ns.dmz.cd.cz. 14400 IN A 81.19.46.19 ns.dmz.cd.cz. 14400 IN A 81.19.46.20 ;; Query time: 344 msec ;; SERVER: 81.19.46.20#53(81.19.46.20) ;; WHEN: Fri Apr 16 08:38:29 2010 ;; MSG SIZE rcvd: 208 ; <<>> DiG 9.3.6-P1 <<>> ns idos.cz +norec @ns.dmz.cd.cz ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38001 ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;idos.cz. IN NS ;; ANSWER SECTION: idos.cz. 14400 IN CNAME idos.timetable.cz. ;; Query time: 340 msec ;; SERVER: 81.19.46.20#53(81.19.46.20) ;; WHEN: Fri Apr 16 08:39:31 2010 ;; MSG SIZE rcvd: 54 > Ondrej 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 Apr 15 16:49:22 2010 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 D70693A68AC; Thu, 15 Apr 2010 16:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.768 X-Spam-Level: X-Spam-Status: No, score=-0.768 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 JELtc7GjJLcm; Thu, 15 Apr 2010 16:49:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A997C3A6AC3; Thu, 15 Apr 2010 16:49:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2YjE-000PNh-Nw for namedroppers-data0@psg.com; Thu, 15 Apr 2010 23:44:12 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2YjC-000PNO-6U for namedroppers@ops.ietf.org; Thu, 15 Apr 2010 23:44:10 +0000 Received: from [192.168.100.155] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 93A0AC5684C; Fri, 16 Apr 2010 00:44:08 +0100 (BST) Date: Fri, 16 Apr 2010 00:44:36 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Edward Lewis cc: Edward Lewis , IETF DNSEXT WG , Alex Bligh Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Message-ID: <588722461269B0D297D03891@nimrod.local> In-Reply-To: References: <25542.1271271658@nsa.vix.com> <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <8381F1C3-E5E5-436E-8B3F-0B569DCA966D@rfc1035.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 April 2010 11:14:14 -0400 Edward Lewis wrote: >> Martin Barry objected to my characterisation of optionality: >>> For everyone else it is completely optional." >> I'm not sure that's true. Firstly, it's yet more protocol >> complexity, and that hurts everyone. > > I disagree that it hurts everyone. I've said this in an earlier message, > complexity is another word for optimizations. Before declaring > complexity as "bad" I would want to see specific reasons why. Complexity > does have a cost, but is the benefit of the corresponding optimization > exceed the cost of the complexity? To be clear, I meant it hurts everyone in the sense of it having a cost. I wasn't arguing it had no benefits. However, the benefits are restricted to those using third party resolvers, which I believe to be a minority. I am guessing if this option did something more widely helpful (traceroute functionality?) and third party resolvers just hung off it, it might have more support. -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Apr 15 17:28:27 2010 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 ADCAF3A68B5; Thu, 15 Apr 2010 17:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.481, 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 9bX4xq94+kCy; Thu, 15 Apr 2010 17:28:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 853183A690C; Thu, 15 Apr 2010 17:28:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2ZLn-0007ja-50 for namedroppers-data0@psg.com; Fri, 16 Apr 2010 00:24:03 +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.71 (FreeBSD)) (envelope-from ) id 1O2ZLk-0007jN-LN for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 00:24:00 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5FFEDA21A5 for ; Fri, 16 Apr 2010 00:24:00 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 In-Reply-To: Your message of "Fri, 16 Apr 2010 09:26:19 +1000." <201004152326.o3FNQJG1088028@drugs.dv.isc.org> References: <4BC720DE.8080900@nic.cz> <201004152326.o3FNQJG1088028@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Fri, 16 Apr 2010 00:24:00 +0000 Message-ID: <18285.1271377440@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: > ; <<>> DiG 9.3.6-P1 <<>> www.idos.cz @ns.dmz.cd.cz +norec > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57649 > ;; flags: qr aa ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.idos.cz. IN A > > ;; ANSWER SECTION: > www.idos.cz. 14400 IN CNAME idos.timetable.cz. > idos.timetable.cz. 91 IN CNAME cluster.timetable.cz. > cluster.timetable.cz. 195 IN A 77.93.209.54 > cluster.timetable.cz. 195 IN A 77.93.209.53 > > ;; Query time: 344 msec > ;; SERVER: 81.19.46.20#53(81.19.46.20) > ;; WHEN: Fri Apr 16 08:35:47 2010 > ;; MSG SIZE rcvd: 112 the proper response by a full resolver who received an answer like this would be to process the first CNAME, throw everything else away, and restart the query at the target of the CNAME. i'm amazed when i see out-of-zone CNAME responses on the wire like this, even when the server is authoritative for both zones. (yes, i know BIND sends the same thing, but i consider it a bug now that we've survived kaminsky's Summer of Fear.) From owner-namedroppers@ops.ietf.org Thu Apr 15 18:11:56 2010 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 2B8C13A6933; Thu, 15 Apr 2010 18:11:56 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.801 X-Spam-Level: ** X-Spam-Status: No, score=2.801 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 vb4TcoW0nc1I; Thu, 15 Apr 2010 18:11:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 244823A6868; Thu, 15 Apr 2010 18:11:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2a2b-000I0h-P8 for namedroppers-data0@psg.com; Fri, 16 Apr 2010 01:08:17 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2a2Y-000I08-Ea for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 01:08:14 +0000 Received: (eyou send program); Fri, 16 Apr 2010 09:08:14 +0800 Message-ID: <471380094.27427@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 16 Apr 2010 09:08:14 +0800 Message-ID: From: "YAO Jiankang" To: "Mark Andrews" Cc: References: <471323117.21296@cnnic.cn> <451D7DB04B81453799CB4C53265F13FA@LENOVO47E041CF> <471343971.17261@cnnic.cn> Subject: Re: [dnsext] Unsigned Synthesized CNAME issues in dname-bis draft Date: Fri, 16 Apr 2010 09:08:17 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmsgQW5kcmV3cyIgPG1h cmthQGlzYy5vcmc+DQpUbzogIllBTyBKaWFua2FuZyIgPHlhb2prQGNubmljLmNuPg0KQ2M6IDxu YW1lZHJvcHBlcnNAb3BzLmlldGYub3JnPg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDE1LCAyMDEw IDEwOjI4IFBNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gVW5zaWduZWQgU3ludGhlc2l6ZWQgQ05B TUUgaXNzdWVzIGluIGRuYW1lLWJpcyBkcmFmdCANCg0KDQo+IA0KPiBJbiBtZXNzYWdlIDw0NzEz MjMxMTcuMjEyOTZAY25uaWMuY24+IDw0NTFEN0RCMDRCODE0NTM3OTlDQjRDNTMyNjVGMTNGQUBM RU5PVk80DQo+IDdFMDQxQ0Y+LCAiWUFPIEppYW5rYW5nIiB3cml0ZXM6DQo+PiBpbiBzZWN0aW9u ICA1LjMuMS4gIFNpZ25lZCBETkFNRSwgVW5zaWduZWQgU3ludGhlc2l6ZWQgQ05BTUUgb2YgZHJh ZnQgZHJhZnQtaWV0Zi1kbnNleHQtcmZjMjY3MmJpcy1kbmFtZS0xODoNCj4+IA0KPj4gICBJbiBh bnkgcmVzcG9uc2UsIGEgc2lnbmVkIEROQU1FIFJSIGluZGljYXRlcyBhIG5vbi10ZXJtaW5hbA0K Pj4gICAgcmVkaXJlY3Rpb24gb2YgdGhlIHF1ZXJ5LiAgVGhlcmUgbWlnaHQgb3IgbWlnaHQgbm90 IGJlIGEgc2VydmVyDQo+PiAgICBzeW50aGVzaXplZCBDTkFNRSBpbiB0aGUgYW5zd2VyIHNlY3Rp b247IGlmIHRoZXJlIGlzLCB0aGUgQ05BTUUgd2lsbA0KPj4gICAgbmV2ZXIgYmUgc2lnbmVkLg0K Pj4gDQo+PiBjb3VsZCBJIHN1Z2dlc3QgdG8gDQo+PiANCj4+IGNoYW5nZSAiaWYgdGhlcmUgaXMs IHRoZSBDTkFNRSB3aWxsIG5ldmVyIGJlIHNpZ25lZC4iDQo+PiANCj4+IHRvIHRoZSBmb2xsb3cg ImlmIHRoZXJlIGlzLCB0aGUgQ05BTUUgbWF5IChzaG91bGQpIGJlIHNpZ25lZCBpZiB0aGUgb25s aW5lIHNpZ25pbmcgaXMgc3VwcG9ydGVkIG9uIHRoZSBzZXJ2ZXIuIiA/DQo+PiANCj4+IHdlIGNh biBkbyBpdCBvciBub3Q/DQo+IA0KPiBZb3UgZG9uJ3QgbmVlZCB0byBkbyBpdC4gIFRoZSBjbGll bnQgd2lsbCBtb3N0IHByb2JhYmx5IGlnbm9yZSBpdC4NCj4gbmFtZWQgZG9lcy4NCg0KYXJlIHRo ZXJlIHNvbWUgY2xpZW50cyB3aGljaCBkb24ndCBpZ25vcmUgaXQ/DQoNCg0KPiAgVGhlIENOQU1F IGlzIGp1c3QgdGhlcmUgdG8gbWFrZSB0aGUgbm9uIEROQU1FIGF3YXJlDQo+IGNsaWVudHMgaGFw cHkuDQoNCisxLg0KDQppZiB0aGVyZSBhcmUgc2lnbmVkIENOQU1FLCBpdCBtYXkgYnJpbmcgbW9y ZSBoYXBweSB0byB0aG9zZSBjbGllbnRzIHdoaWNoICBkb24ndCBpZ25vcmUgc2lnbmVkIENOQU1F Lg0KDQo6KQ0KDQoNCg0KPiANCj4gTWFyaw0KPiANCj4gLS0gDQo+IE1hcmsgQW5kcmV3cywgSVND DQo+IDEgU2V5bW91ciBTdC4sIER1bmRhcyBWYWxsZXksIE5TVyAyMTE3LCBBdXN0cmFsaWENCj4g UEhPTkU6ICs2MSAyIDk4NzEgNDc0MiAgICAgICAgICAgICAgICAgSU5URVJORVQ6IG1hcmthQGlz Yy5vcmcNCj4= From owner-namedroppers@ops.ietf.org Thu Apr 15 18:11:59 2010 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 7A8C73A6982; Thu, 15 Apr 2010 18:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 MUpR90i7MD-s; Thu, 15 Apr 2010 18:11:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 471A53A6868; Thu, 15 Apr 2010 18:11:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2a0r-000Hcf-1X for namedroppers-data0@psg.com; Fri, 16 Apr 2010 01:06:29 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2a0o-000HcQ-6s for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 01:06: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 5A8B7E861A; Fri, 16 Apr 2010 01:06:25 +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 o3G16Hfu089826; Fri, 16 Apr 2010 11:06:18 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004160106.o3G16Hfu089826@drugs.dv.isc.org> To: Paul Vixie Cc: "namedroppers@ops.ietf.org" From: Mark Andrews References: <4BC720DE.8080900@nic.cz> <201004152326.o3FNQJG1088028@drugs.dv.isc.org> <18285.1271377440@nsa.vix.com> Subject: [dnsext] CNAME chains and iterative queries. In-reply-to: Your message of "Fri, 16 Apr 2010 00:24:00 GMT." <18285.1271377440@nsa.vix.com> Date: Fri, 16 Apr 2010 11:06:17 +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 <18285.1271377440@nsa.vix.com>, Paul Vixie writes: > > ; <<>> DiG 9.3.6-P1 <<>> www.idos.cz @ns.dmz.cd.cz +norec > > ;; global options: printcmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57649 > > ;; flags: qr aa ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 > > > > ;; QUESTION SECTION: > > ;www.idos.cz. IN A > > > > ;; ANSWER SECTION: > > www.idos.cz. 14400 IN CNAME idos.timetable.cz. > > idos.timetable.cz. 91 IN CNAME cluster.timetable.cz. > > cluster.timetable.cz. 195 IN A 77.93.209.54 > > cluster.timetable.cz. 195 IN A 77.93.209.53 > > > > ;; Query time: 344 msec > > ;; SERVER: 81.19.46.20#53(81.19.46.20) > > ;; WHEN: Fri Apr 16 08:35:47 2010 > > ;; MSG SIZE rcvd: 112 > > the proper response by a full resolver who received an answer like this > would be to process the first CNAME, throw everything else away, and > restart the query at the target of the CNAME. i'm amazed when i see > out-of-zone CNAME responses on the wire like this, even when the server is > authoritative for both zones. (yes, i know BIND sends the same thing, but > i consider it a bug now that we've survived kaminsky's Summer of Fear.) [note the Subject: change] And a stub needs the full response. Changing the algorithm to only restart the query if RD is set and recursion is permitted may be one way to address this. 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 Apr 15 18:49:29 2010 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 B534F3A6986; Thu, 15 Apr 2010 18:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[AWL=-1.046, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_55=0.6, 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 Wtw96-lpRnB4; Thu, 15 Apr 2010 18:49:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF5973A685D; Thu, 15 Apr 2010 18:49:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2acR-0001Jx-CN for namedroppers-data0@psg.com; Fri, 16 Apr 2010 01:45:19 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2acO-0001JN-Rx for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 01:45: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 DDB74E8634; Fri, 16 Apr 2010 01:45:15 +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 o3G1j6cq090668; Fri, 16 Apr 2010 11:45:09 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004160145.o3G1j6cq090668@drugs.dv.isc.org> Cc: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , "namedroppers@ops.ietf.org" From: Mark Andrews Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 In-reply-to: Your message of "Fri, 16 Apr 2010 09:26:19 +1000." Date: Fri, 16 Apr 2010 11:45:06 +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: Mark Andrews writes: > In message <4BC720DE.8080900@nic.cz>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= writes > : > > Hi, > > > > I hereby present the "other" solution to name sameness (we all call it > > CNAME+DNAME, aren't we?). It's little bit competing with BNAME > > proposal, but it should be simpler to implement. It doesn't introduce > > new RTYPE, it just loosens the singleton rule of CNAME to allow DNAME > > for the same name (we did this before with NSEC+RRSIG, remember?) > > It doesn't matter if it can be made to work with some resolvers. > It is just plain out a bad idea to change the behaviour of existing > records unless you really have no choice. With DNSSEC there was > no choice because you want to secure the CNAME record. There is a > choice here however. > > > Just FYI, try digging idos.cz (or jizdnirady.cz) before you start > > writing this email and think if this proposal really breaks existing > > behaviour (if the existing resolvers are able to cope with this). > > Where's the DNAME in the response? If you want us to believe that > it works the DNAME needs to be returned. For good measure it also > has to work with a signed zone. It's relatively easy to change > named to allow a DNAME and CNAME to co-exist see > lib/dns/rbtdb.c:cname_and_other_data(). Needed one other conditional needed to be changed to make the authoritative side provide consistent signed results. None of this however is to say I think this is a good idea but if you want to experiment then you need to do a proper experiment. And if one is relaxing CNAME and other data rules then NS and SOA are also obvious candidates. Mark Index: lib/dns/rbtdb.c =================================================================== RCS file: /proj/cvs/prod/bind9/lib/dns/rbtdb.c,v retrieving revision 1.300 diff -u -r1.300 rbtdb.c --- lib/dns/rbtdb.c 26 Feb 2010 00:18:06 -0000 1.300 +++ lib/dns/rbtdb.c 16 Apr 2010 01:28:10 -0000 @@ -3679,7 +3679,8 @@ * We don't check for RRSIG, because we don't store RRSIG records * directly. */ - if (type == dns_rdatatype_key || type == dns_rdatatype_nsec) + if (type == dns_rdatatype_key || type == dns_rdatatype_nsec || + type == dns_rdatatype_dname) cname_ok = ISC_FALSE; /* @@ -5513,6 +5514,7 @@ if (rdtype != dns_rdatatype_key && rdtype != dns_rdatatype_sig && rdtype != dns_rdatatype_nsec && + rdtype != dns_rdatatype_dname && rdtype != dns_rdatatype_rrsig) { /* * Is it active and extant? -- 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 Apr 15 19:50:41 2010 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 F34B73A67E6; Thu, 15 Apr 2010 19:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.379 X-Spam-Level: * X-Spam-Status: No, score=1.379 tagged_above=-999 required=5 tests=[AWL=1.252, 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 Zmkit7CIwTTy; Thu, 15 Apr 2010 19:50:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EFA273A6A7A; Thu, 15 Apr 2010 19:50:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2bXW-000FpR-1P for namedroppers-data0@psg.com; Fri, 16 Apr 2010 02:44:18 +0000 Received: from [209.85.210.186] (helo=mail-yx0-f186.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2bXT-000Fp7-M8 for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 02:44:15 +0000 Received: by yxe16 with SMTP id 16so1225674yxe.9 for ; Thu, 15 Apr 2010 19:44:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Thu, 15 Apr 2010 19:44:14 -0700 (PDT) In-Reply-To: <201004160145.o3G1j6cq090668@drugs.dv.isc.org> References: <201004160145.o3G1j6cq090668@drugs.dv.isc.org> Date: Thu, 15 Apr 2010 19:44:14 -0700 Received: by 10.101.197.14 with SMTP id z14mr2230798anp.57.1271385854359; Thu, 15 Apr 2010 19:44:14 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 From: Matthew Dempsky To: Mark Andrews Cc: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , "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 Thu, Apr 15, 2010 at 6:45 PM, Mark Andrews wrote: > And if one is relaxing CNAME and other data rules then NS and SOA > are also obvious candidates. And DS? From owner-namedroppers@ops.ietf.org Thu Apr 15 20:07:17 2010 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 D12BA3A6AC9; Thu, 15 Apr 2010 20:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 frn9tKSptT-j; Thu, 15 Apr 2010 20:07:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA0EA3A6A7A; Thu, 15 Apr 2010 20:07:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2bq5-000K8f-Uy for namedroppers-data0@psg.com; Fri, 16 Apr 2010 03:03:29 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2bq3-000K8K-FB for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 03:03:27 +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 B6251E864F; Fri, 16 Apr 2010 03:03:26 +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 o3G33JaD091369; Fri, 16 Apr 2010 13:03:20 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004160303.o3G33JaD091369@drugs.dv.isc.org> To: Matthew Dempsky Cc: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , "namedroppers@ops.ietf.org" From: Mark Andrews References: <201004160145.o3G1j6cq090668@drugs.dv.isc.org> Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 In-reply-to: Your message of "Thu, 15 Apr 2010 19:44:14 MST." Date: Fri, 16 Apr 2010 13:03:19 +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 , Ma tthew Dempsky writes: > On Thu, Apr 15, 2010 at 6:45 PM, Mark Andrews wrote: > > And if one is relaxing CNAME and other data rules then NS and SOA > > are also obvious candidates. > > And DS? No. DS only co-exists with delegating NS's. If it wasn't obvious that is NS and SOA at the apex of a zone. CNAME at a delegation would not be visible. The cache might see DS/NS/SOA/CNAME/DNAME all co-existing together but the authorative side would not under this regime. 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 Apr 15 20:11:07 2010 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 5CC1F3A6AEA; Thu, 15 Apr 2010 20:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.385 X-Spam-Level: X-Spam-Status: No, score=-1.385 tagged_above=-999 required=5 tests=[AWL=-0.078, 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 SngZrgmSDotA; Thu, 15 Apr 2010 20:11:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5CB273A6AE4; Thu, 15 Apr 2010 20:11:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2btp-000Kzt-Mf for namedroppers-data0@psg.com; Fri, 16 Apr 2010 03:07:21 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2btj-000Kx3-RT for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 03:07:15 +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 48DD9E8649; Fri, 16 Apr 2010 03:07:14 +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 o3G37Boh091390; Fri, 16 Apr 2010 13:07:11 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004160307.o3G37Boh091390@drugs.dv.isc.org> Cc: Matthew Dempsky , =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , "namedroppers@ops.ietf.org" From: Mark Andrews Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 In-reply-to: Your message of "Fri, 16 Apr 2010 13:03:19 +1000." Date: Fri, 16 Apr 2010 13:07:11 +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: Mark Andrews writes: > > In message , > Ma > tthew Dempsky writes: > > On Thu, Apr 15, 2010 at 6:45 PM, Mark Andrews wrote: > > > And if one is relaxing CNAME and other data rules then NS and SOA > > > are also obvious candidates. > > > > And DS? > > No. DS only co-exists with delegating NS's. If it wasn't obvious > that is NS and SOA at the apex of a zone. CNAME at a delegation > would not be visible. > > The cache might see DS/NS/SOA/CNAME/DNAME all co-existing together > but the authorative side would not under this regime. Make that DS/NS/SOA/CNAME/DNAME/DNSKEY/NSEC/KEY/SIG/RRSIG. 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 Apr 16 00:49:56 2010 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 1A2E33A6ABA; Fri, 16 Apr 2010 00:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.29 X-Spam-Level: * X-Spam-Status: No, score=1.29 tagged_above=-999 required=5 tests=[AWL=1.163, 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 duHpt6yF92Ok; Fri, 16 Apr 2010 00:49:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E4C633A69D1; Fri, 16 Apr 2010 00:49:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2gBx-000BGE-HI for namedroppers-data0@psg.com; Fri, 16 Apr 2010 07:42:21 +0000 Received: from [209.85.223.175] (helo=mail-iw0-f175.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2gBv-000BFn-57 for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 07:42:19 +0000 Received: by iwn5 with SMTP id 5so1197450iwn.9 for ; Fri, 16 Apr 2010 00:42:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Fri, 16 Apr 2010 00:42:17 -0700 (PDT) In-Reply-To: <201004160303.o3G33JaD091369@drugs.dv.isc.org> References: <201004160145.o3G1j6cq090668@drugs.dv.isc.org> <201004160303.o3G33JaD091369@drugs.dv.isc.org> Date: Fri, 16 Apr 2010 00:42:17 -0700 Received: by 10.231.173.129 with SMTP id p1mr431484ibz.85.1271403737982; Fri, 16 Apr 2010 00:42:17 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 From: Matthew Dempsky To: Mark Andrews Cc: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , "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 Thu, Apr 15, 2010 at 8:03 PM, Mark Andrews wrote: > No. =A0DS only co-exists with delegating NS's. =A0If it wasn't obvious > that is NS and SOA at the apex of a zone. =A0CNAME at a delegation > would not be visible. > > The cache might see DS/NS/SOA/CNAME/DNAME all co-existing together > but the authorative side would not under this regime. Ah, got it. I didn't catch that we were talking about authoritative only, rather than in-general what records might need to coexist at an owner name with CNAME records. From dnsext-archive@lists.ietf.org Fri Apr 16 01:41:02 2010 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 5EA123A67CC for ; Fri, 16 Apr 2010 01:41:02 -0700 (PDT) X-Quarantine-ID: <9IoqkU3JyAIG> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Fri, 16 Apr 2010 01:41:00 -0700 (PDT) Received: from 161-117-207-82.ip.ukrtel.net (161-117-207-82.ip.ukrtel.net [82.207.117.161]) by core3.amsl.com (Postfix) with SMTP id ABC193A6ABA for ; Fri, 16 Apr 2010 01:40:50 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100416084050.ABC193A6ABA@core3.amsl.com> Date: Fri, 16 Apr 2010 01:40:50 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@lists.ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 59493 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Fri Apr 16 02:07:28 2010 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 C48E33A68D1; Fri, 16 Apr 2010 02:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.681 X-Spam-Level: X-Spam-Status: No, score=-94.681 tagged_above=-999 required=5 tests=[AWL=-1.531, BAYES_50=0.001, 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, 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 x-4ta3HrtbGD; Fri, 16 Apr 2010 02:07:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D547C3A67F7; Fri, 16 Apr 2010 02:07:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2hQ4-0007w7-QU for namedroppers-data0@psg.com; Fri, 16 Apr 2010 09:01:00 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2hPy-0007um-RF for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 09:00:56 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA202718413; Fri, 16 Apr 2010 11:00:13 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA23540; Fri, 16 Apr 2010 11:00:12 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004160900.LAA23540@TR-Sys.de> Subject: [dnsext] draft-ietf-dnsext-dnssec-registry-fixes-03 To: scottr.nist@gmail.com Date: Fri, 16 Apr 2010 11:00:11 +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: 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 have revisited the DNSSEC Registry Fixes draft that you have updated this week. Below are a couple of editorial notes that hopefully will help to improve the memo further. (1) running page headers I suggest to make the "short title" of the document more specific: s/IANA-Registry-Fix/DNSSEC Registry Fixes/ (2) section structure According to the authoring guidelines valid since several years, "Requirements Language" shall be a numbered section, but not the first one of a document. I suggest to move it from the boilerplate part of the draft into a new section 1.1. (3) Copyright Notice IMO, the draft does not borrow substantially from pre-5378 material (IANA registry content does not fall under the pre-5378 regime, and all of {author, contributors/reviewers} operate under RFC 5378 rules). So I suggest to get rid of the pre-5378 exceptional clause (3rd paragraph of the Copyright Notice) -- its use should remain an exceptional case that needs evidence to justify, according to the TLP. (4) Outline of section 2 and acronym expansion According to the RFC Editor material, "DNS" is not one of the "very well known" acronyms that do not need expansion on first use. Therefore, I suggest to expand "DNS" in the first sentence of section 1: | The Domain Name System (DNS) Security Extensions (DNSSEC, [RFC4033], | [RFC4034], and [RFC4034]) uses ... Then, "DNS" can be used freely in the text. In particular, the (sub)section headlines of section 2 should be spell-corrected, shortened, and made more specific. I propose to change the outline: v | 2. DNS Security Algorithm Number Subregisitry Fixes | 2.1. Individual Domain Name System Security (DNSSEC) | Algorithm Number Registry Entry Fixes | 2.2. Domain Name System Security (DNSSEC) Algorithm Number | Registry to: | 2. DNS Security Algorithm Number Subregistry Fixes | 2.1. Individual Fixes | 2.2. Updated Registry Snapshot (5) Section 2.1 The adaption to the updated registry content has introduced confusing text. Since code point 11 now is split off the range 13-251 anyway, no change is needed for it and it should not be listed as a change any more; the previous entry for 11-251, that could be counted for the "three entries" being changed does not exist any more. Further, "allocation" for IANA regularly means sub-delegation of an entire range of code points to another entity; "assignment" is the precise term for a single code point being handed out for some purpose. Therefore, the term "allocation" should be replaced by "assignment". Therefore, I suggest to revise the content of section 2.1 as follows: This document changes three entries in the Domain Name System Security (DNSSEC) Algorithm Registry. They are: | The description for allocation number 4 is changed to "Reserved until | 2020". | | The description for allocation number 9 is changed to "Reserved until | 2020". | | The description for numbers 11, 13-251 are changed from Unassigned to | the following: | | * Allocation number 11 is changed to "Reserved until 2020". | | * Allocations 13-251 remains Unassigned. The status of RSASHA1-NSEC3-SHA1 and DSA-NSEC3-SHA1 are both set to DISCRETIONARY. The status of RSA/SHA-256 and RSA/SHA-512 are set to ENCOURAGED as it is believed that these algorithms will replace older algorithms (e.g. RSA/SHA-1) that have a perceived weakness in their hash algorithm (SHA-1). --- This document changes three entries in the Domain Name System Security (DNSSEC) Algorithm Registry. They are: | o The description for assignment number 4 is changed to | "Reserved until 2020". | | o The description for assignment number 9 is changed to | "Reserved until 2020". | | o The description for assignment number 11 is changed to | "Reserved until 2020". The status of RSASHA1-NSEC3-SHA1 and DSA-NSEC3-SHA1 are both set to DISCRETIONARY. The status of RSA/SHA-256 and RSA/SHA-512 are set to ENCOURAGED as it is believed that these algorithms will replace older algorithms (e.g. RSA/SHA-1) that have a perceived weakness in their hash algorithm (SHA-1). (6) Section 3 Similar restructuring and clarification is needed for section 3. I suggest to modify the first part of the section as follows: This document consists entirely of DNS IANA Considerations and includes the following changes detailed in Section 2.1: | The description of allocation 4 is changed from "Reserved for ECC" to | "Reserved until 2020". | | The description of allocation 9 is changed from "Unassigned" to | "Reserved until 2020". | | The description for numbers 11, 13-251 are changed from Unassigned to | the following: | | * Allocation number 11 is changed to "Reserved until 2020". | | * Allocations 13-251 remains Unassigned. --- This document consists entirely of DNS IANA Considerations and includes the following changes detailed in Section 2.1: | o The description of assignment 4 is changed from "Reserved for ECC" | to "Reserved until 2020". | | o The description of assignment 9 is changed from "Unassigned" to | "Reserved until 2020". | | o The description of assignment 11 is changed from "Unassigned" to | "Reserved until 2020". The second-to-last paragraph of section 3 somehow misrepresents the FIPS updates it refers to. Both FIPS 180 and FIPS 186 have been _amended_ -- so it is not correct to state that their "main content" has not changed; what counts for the current context is that the "_relevant_ content" has not changed. Therefore, I suggest to change: The references to FIPS 180 and FIPS 186 have been updated (to FIPS 180-3 and FIPS 186-3 respectively) to reflect the latest versions. | These revisions are maintenance updates and the main content of the FIPS documents have not changed. --- The references to FIPS 180 and FIPS 186 have been updated (to FIPS 180-3 and FIPS 186-3 respectively) to reflect the latest versions. | These revisions are maintenance updates and the relevant content of the FIPS documents have not changed. (7) Section 5.2 The registry snapshot in Setcion 2.2 contains a pointer to the GOST DNSSEC memo as "[RFCTBD]". In order to not forget the pending update, a corresponding Informative Reference entry should be added to section 5.2. Kind regards, Alfred Hnes. -- +------------------------+--------------------------------------------+ | 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 complaineddt8@fch.median.ru Fri Apr 16 03:52:40 2010 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 D565F3A69EE; Fri, 16 Apr 2010 03:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -71.481 X-Spam-Level: X-Spam-Status: No, score=-71.481 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_DSL=1.129, HELO_EQ_DYNAMIC=1.144, 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, STOX_REPLY_TYPE=0.001, 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 b1RcyveX1PaU; Fri, 16 Apr 2010 03:52:40 -0700 (PDT) Received: from 88-106-152-239.dynamic.dsl.as9105.com (88-106-188-119.dynamic.dsl.as9105.com [88.106.188.119]) by core3.amsl.com (Postfix) with ESMTP id 9DA8A28C125; Fri, 16 Apr 2010 03:52:38 -0700 (PDT) Received: from 88.106.188.119 by acc0.median.ru; Fri, 16 Apr 2010 11:52:30 +0000 Date: Fri, 16 Apr 2010 11:52:30 +0000 From: dnsext-archive@ietf.org Subject: Meet that special someone today To: Message-ID: <000d01cadd52$e92bd0a0$6400a8c0@complaineddt8> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Meet that special someone today. It costs you nothing to check it out. All you have to do is press this web link and you'll be chatting with someone in no time. http://whittaker79.spaces.live.com From grubbiestv75@profmashrb.ru Fri Apr 16 03:52:41 2010 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 7622328C125 for ; Fri, 16 Apr 2010 03:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.704 X-Spam-Level: X-Spam-Status: No, score=-65.704 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_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, 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, STOX_REPLY_TYPE=0.001, 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 nQA8g-u4w5sg for ; Fri, 16 Apr 2010 03:52:40 -0700 (PDT) Received: from 88-106-152-239.dynamic.dsl.as9105.com (88-106-188-119.dynamic.dsl.as9105.com [88.106.188.119]) by core3.amsl.com (Postfix) with ESMTP id 2F5593A6957 for ; Fri, 16 Apr 2010 03:52:38 -0700 (PDT) Received: from 88.106.188.119 by ASPMX5.GOOGLEMAIL.COM; Fri, 16 Apr 2010 11:52:31 +0000 Date: Fri, 16 Apr 2010 11:52:31 +0000 From: dnsext-archive@lists.ietf.org Subject: It costs you nothing to check it out To: Message-ID: <000d01cadd52$e9e360d0$6400a8c0@grubbiestv75> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="us-ascii"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Meet that special someone today. It costs you nothing to check it out. All you have to do is press this web link and you'll be chatting with someone in no time. http://whittaker79.spaces.live.com From owner-namedroppers@ops.ietf.org Fri Apr 16 11:16:51 2010 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 61E493A6AC0; Fri, 16 Apr 2010 11:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.236 X-Spam-Level: X-Spam-Status: No, score=0.236 tagged_above=-999 required=5 tests=[AWL=-0.164, 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 YtDf6uPkryCg; Fri, 16 Apr 2010 11:16:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F2C6D3A67D1; Fri, 16 Apr 2010 11:16:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2q0B-0006vj-Jl for namedroppers-data0@psg.com; Fri, 16 Apr 2010 18:10:51 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2q07-0006uC-Hz for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 18:10:47 +0000 Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 36A3F1ECB533 for ; Fri, 16 Apr 2010 18:10:46 +0000 (UTC) Date: Fri, 16 Apr 2010 14:10:44 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Unsigned Synthesized CNAME issues in dname-bis draft Message-ID: <20100416181044.GP37239@shinkuro.com> References: <471323117.21296@cnnic.cn> <451D7DB04B81453799CB4C53265F13FA@LENOVO47E041CF> <471343971.17261@cnnic.cn> 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, Apr 16, 2010 at 09:08:17AM +0800, YAO Jiankang wrote: > > if there are signed CNAME, it may bring more happy to those clients which don't ignore signed CNAME. Why wouldn't they ignore the signed CNAME, since they can deal with the DNAME? 5.3.4 of the draft points out that "DNSSEC validators MUST understand DNAME." The assumption that validators would understand DNAME is an old one, and I think that it would be a bad idea to try to change that now. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Apr 16 11:25:43 2010 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 C45F43A6A9D; Fri, 16 Apr 2010 11:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.212 X-Spam-Level: * X-Spam-Status: No, score=1.212 tagged_above=-999 required=5 tests=[AWL=1.085, 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 jQ5jvWzf5BDY; Fri, 16 Apr 2010 11:25:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3D57E3A69A6; Fri, 16 Apr 2010 11:24:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2q8p-0009b5-ML for namedroppers-data0@psg.com; Fri, 16 Apr 2010 18:19:47 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2q8l-0009Zk-UW for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 18:19:44 +0000 Received: by pwi1 with SMTP id 1so2124441pwi.11 for ; Fri, 16 Apr 2010 11:19:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Fri, 16 Apr 2010 11:19:42 -0700 (PDT) Date: Fri, 16 Apr 2010 11:19:42 -0700 Received: by 10.141.101.17 with SMTP id d17mr1010018rvm.265.1271441982851; Fri, 16 Apr 2010 11:19:42 -0700 (PDT) Message-ID: Subject: [dnsext] edns-client-ip and NXDOMAIN From: Matthew Dempsky To: IETF DNSEXT WG 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: It's not stated explicitly in draft-vandergaast-edns-client-ip how to cache an NXDOMAIN response. Section 4.3 says that only the answer section resource records are tied to the edns-client-ip parameter, and since NXDOMAIN is indicated by the header and not the answer section, I'm led to believe NXDOMAIN responses can be cached for all client IPs, regardless of the edns-client-ip option. On the other hand, NODATA responses would seem to still be cached per-client-IP. As it's still possible to send NODATA responses, and I don't know any reason why it'd be desirable to send NXDOMAIN (as opposed to NODATA) for a name to some clients but not to others, I'm fine with the above interpretation. However, I think it would be good then to explicitly state this to help avoid problems due to authoritative servers sending unintentional NXDOMAIN responses. (E.g., some broken authoritative servers sent NXDOMAIN rather than NODATA responses to AAAA queries for names that didn't have AAAA records but did have A records; the consequence being dual-stack IPv6/IPv4 clients that started asking for AAAA records first would never see the A records either.) From owner-namedroppers@ops.ietf.org Fri Apr 16 11:25:53 2010 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 05BA928C0E9; Fri, 16 Apr 2010 11:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.144 X-Spam-Level: * X-Spam-Status: No, score=1.144 tagged_above=-999 required=5 tests=[AWL=1.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 cPYF1sfJ+LJB; Fri, 16 Apr 2010 11:25:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EBBC728C0D9; Fri, 16 Apr 2010 11:25:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2qAC-0009sK-US for namedroppers-data0@psg.com; Fri, 16 Apr 2010 18:21:12 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2qA9-0009rY-Py for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 18:21:09 +0000 Received: by pwi1 with SMTP id 1so2125729pwi.11 for ; Fri, 16 Apr 2010 11:21:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Fri, 16 Apr 2010 11:21:08 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Apr 2010 11:21:08 -0700 Received: by 10.114.86.16 with SMTP id j16mr1998349wab.128.1271442069004; Fri, 16 Apr 2010 11:21:09 -0700 (PDT) Message-ID: Subject: [dnsext] Re: Reserved EDNS0 option codes for private use From: Matthew Dempsky To: IETF DNSEXT WG 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: No one? On Mon, Apr 12, 2010 at 3:21 PM, Matthew Dempsky wrot= e: > On Fri, Apr 9, 2010 at 1:47 AM, Matthew Dempsky wro= te: >> According to http://www.iana.org/assignments/dns-parameters, there are >> no EDNS0 option codes reserved for private use. =A0As every other 16-bit >> DNS parameter reserves 65280--65534 for private use, I suggest the >> same range be similarly reserved for EDNS0 option codes. > > I've submitted the below draft requesting IANA reserve this range for > private use: > > =A0 =A0http://www.ietf.org/id/draft-dempsky-edns0-options-for-private-use= -00.txt > > Comments? > From owner-namedroppers@ops.ietf.org Fri Apr 16 11:38:28 2010 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 885793A63EB; Fri, 16 Apr 2010 11:38:28 -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.520, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 f3WTRNlvs-Nc; Fri, 16 Apr 2010 11:38:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D53B28C0ED; Fri, 16 Apr 2010 11:38:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2qLj-000DKt-Ch for namedroppers-data0@psg.com; Fri, 16 Apr 2010 18:33:07 +0000 Received: from [209.85.223.175] (helo=mail-iw0-f175.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2qLf-000DII-75 for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 18:33:03 +0000 Received: by iwn5 with SMTP id 5so1549149iwn.9 for ; Fri, 16 Apr 2010 11:33:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.169.1 with HTTP; Fri, 16 Apr 2010 11:33:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Apr 2010 11:33:01 -0700 Received: by 10.231.156.65 with SMTP id v1mr675638ibw.67.1271442781788; Fri, 16 Apr 2010 11:33:01 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Re: Reserved EDNS0 option codes for private use From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Matthew Dempsky Cc: IETF DNSEXT WG 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, Apr 12, 2010 at 3:21 PM, Matthew Dempsky wrot= e: > =A0 =A0http://www.ietf.org/id/draft-dempsky-edns0-options-for-private-use= -00.txt > > Comments? In general, I think this is a good idea, and should be adopted. However I would also like to know what the existing IANA practices are and what level of specification is required to be assigned a number (e.g. is only a full RFC sufficient? or a public draft alone?). --=20 Colm From owner-namedroppers@ops.ietf.org Fri Apr 16 12:30:19 2010 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 BA2D228C178; Fri, 16 Apr 2010 12:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.235 X-Spam-Level: * X-Spam-Status: No, score=1.235 tagged_above=-999 required=5 tests=[AWL=0.808, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 LpEucEte9Hal; Fri, 16 Apr 2010 12:30:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DF92D28C187; Fri, 16 Apr 2010 12:30:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2r9z-00022S-Th for namedroppers-data0@psg.com; Fri, 16 Apr 2010 19:25:03 +0000 Received: from [209.85.222.182] (helo=mail-pz0-f182.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2r9x-000229-9Q for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 19:25:01 +0000 Received: by pzk12 with SMTP id 12so2328458pzk.32 for ; Fri, 16 Apr 2010 12:25:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Fri, 16 Apr 2010 12:25:00 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Apr 2010 12:25:00 -0700 Received: by 10.141.53.10 with SMTP id f10mr2291655rvk.134.1271445900348; Fri, 16 Apr 2010 12:25:00 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Re: Reserved EDNS0 option codes for private use From: Matthew Dempsky To: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= Cc: IETF DNSEXT WG 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: 2010/4/16 Colm MacC=E1rthaigh : > However I would also like to know what the existing IANA practices are > and what level of specification is required to be assigned a number > (e.g. is only a full RFC sufficient? or a public draft alone?). It varies on a per-registry basis. Below is the email that I received when I tried to reserve a range of numbers through the IANA registration form (which prompted me to post the EDNS0 Options for Private Use draft). On Mon, Apr 12, 2010 at 12:02 PM, Amanda Baber via RT wrote: > Hi Matthew, > > DNS EDNS0 Options is a "Specification Required" registry, which means > that in order to modify it, we need to receive a request that's > supported by a permanent and readily available reference, as > described in RFC 5226, which in turn must be approved by an > IESG-designated expert. > > The people to talk to about this idea would actually be the IETF's > DNSEXT Working Group, which was responsible for the RFC that defines > this registry. Contact information for the DNSEXT WG is available here: > > http://datatracker.ietf.org/wg/dnsext/charter/ > > Best regards, > > Amanda Baber > Internet Assigned Numbers Authority > ICANN From owner-namedroppers@ops.ietf.org Fri Apr 16 12:30:27 2010 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 715D63A67FB; Fri, 16 Apr 2010 12:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.346 X-Spam-Level: ** X-Spam-Status: No, score=2.346 tagged_above=-999 required=5 tests=[AWL=-0.715, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, 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 20NkghTDJy8o; Fri, 16 Apr 2010 12:30:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 588AE28C178; Fri, 16 Apr 2010 12:30:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2rBK-0002GQ-6T for namedroppers-data0@psg.com; Fri, 16 Apr 2010 19:26:26 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2rBH-0002Fr-7M for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 19:26:23 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3GJQ6Q8078392; Fri, 16 Apr 2010 15:26:14 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Fri, 16 Apr 2010 15:26:20 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 16 Apr 2010 15:26:20 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 16 Apr 2010 15:26:05 -0400 To: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= From: Edward Lewis Subject: Re: [dnsext] Re: Reserved EDNS0 option codes for private use Cc: Matthew Dempsky , IETF DNSEXT WG Content-Type: multipart/alternative; boundary="============_-940676521==_ma============" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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: --============_-940676521==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable At 11:33 -0700 4/16/10, Colm MacC=E1rthaigh wrote: >In general, I think this is a good idea, and should be adopted. >However I would also like to know what the existing IANA practices are >and what level of specification is required to be assigned a number >(e.g. is only a full RFC sufficient? or a public draft alone?). =46rom RFC 2671 (heavily cropped to focus on Option code): # 7 - IANA Considerations =2E.. # It is the recommendation of this document and its working group # that IANA create a registry for EDNS Extended Label Types, for EDNS # Option Codes, and for EDNS Version Numbers. =2E.. # any published RFC (including Informational, Experimental, or BCP) # should be grounds for allocation of an EDNS Option Code. That is IANA's official instructions. -- -=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-=3D-=3D- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? --============_-940676521==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dnsext] Re: Reserved EDNS0 option codes for private u
At 11:33 -0700 4/16/10, Colm MacC=E1rthaigh wrote:

>In general, I think this is a good idea, and should be adopted.
>However I would also like to know what the existing IANA practices are
>and what level of specification is required to be assigned a number
>(e.g. is only a full RFC sufficient? or a public draft alone?).

From RFC 2671 (heavily cropped to focus on Option code):

# 7 - IANA Considerations
...
#     It is the recommendation of this document and its working group
#     that IANA create a registry for EDNS Extended Label Types, for EDNS
#     Option Codes, and for EDNS Version Numbers.
...
#     any published RFC (including Informational, Experimental, or BCP)
#     should be grounds for allocation of an EDNS Option Code.

That is IANA's official instructions.
--
-=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-=3D-=3D-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Wouldn't it be nice if all of the definitions of equivalence were the same?
--============_-940676521==_ma============-- From owner-namedroppers@ops.ietf.org Fri Apr 16 15:12:48 2010 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 29ACE3A6988; Fri, 16 Apr 2010 15:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 Ksy8x91glRNF; Fri, 16 Apr 2010 15:12:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 820FA3A68DE; Fri, 16 Apr 2010 15:12:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2tfS-000J7Y-9A for namedroppers-data0@psg.com; Fri, 16 Apr 2010 22:05:42 +0000 Received: from [74.125.149.77] (helo=na3sys009aog106.obsmtp.com) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2tfP-000J4t-Q6 for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 22:05:40 +0000 Received: from source ([209.85.223.183]) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKS8jfMgDKoPq9XIgGbuIxE8JpP40DFu9f@postini.com; Fri, 16 Apr 2010 15:05:39 PDT Received: by mail-iw0-f183.google.com with SMTP id 13so1741386iwn.10 for ; Fri, 16 Apr 2010 15:05:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.155.19 with HTTP; Fri, 16 Apr 2010 15:05:38 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Apr 2010 15:05:38 -0700 Received: by 10.231.159.143 with SMTP id j15mr647476ibx.73.1271455538784; Fri, 16 Apr 2010 15:05:38 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Re: Reserved EDNS0 option codes for private use From: David Ulevitch To: Edward Lewis Cc: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= , Matthew Dempsky , IETF DNSEXT WG 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: 2010/4/16 Edward Lewis : > At 11:33 -0700 4/16/10, Colm MacC=E1rthaigh wrote: >>In general, I think this is a good idea, and should be adopted. >>However I would also like to know what the existing IANA practices are >>and what level of specification is required to be assigned a number >>(e.g. is only a full RFC sufficient? or a public draft alone?). > From RFC 2671 (heavily cropped to focus on Option code): > # 7 - IANA Considerations > ... > #=A0=A0=A0=A0 It is the recommendation of this document and its working g= roup > #=A0=A0=A0=A0 that IANA create a registry for EDNS Extended Label Types, = for EDNS > #=A0=A0=A0=A0 Option Codes, and for EDNS Version Numbers. > ... > #=A0=A0=A0=A0 any published RFC (including Informational, Experimental, o= r BCP) > #=A0=A0=A0=A0 should be grounds for allocation of an EDNS Option Code. > That is IANA's official instructions. > Yep, and that should change to make it easier. Or at the very least, allow a reserved range for private use. From owner-namedroppers@ops.ietf.org Fri Apr 16 15:31:14 2010 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 C4FC23A6A55; Fri, 16 Apr 2010 15:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.724 X-Spam-Level: X-Spam-Status: No, score=-0.724 tagged_above=-999 required=5 tests=[AWL=-0.229, 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 duYgcaC9O4g8; Fri, 16 Apr 2010 15:31:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E8A3E3A6964; Fri, 16 Apr 2010 15:31:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2tyc-000Nwj-4I for namedroppers-data0@psg.com; Fri, 16 Apr 2010 22:25:30 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2tyZ-000NwT-A1 for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 22:25:27 +0000 Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3GMPOXe079463; Fri, 16 Apr 2010 18:25:24 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4BC8E3CC.7020402@ogud.com> Date: Fri, 16 Apr 2010 18:25:16 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Edward Lewis CC: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= , Matthew Dempsky , IETF DNSEXT WG Subject: Re: [dnsext] Re: Reserved EDNS0 option codes for private use References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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/04/2010 3:26 PM, Edward Lewis wrote: > At 11:33 -0700 4/16/10, Colm MacCrthaigh wrote: > > >In general, I think this is a good idea, and should be adopted. > >However I would also like to know what the existing IANA practices are > >and what level of specification is required to be assigned a number > >(e.g. is only a full RFC sufficient? or a public draft alone?). > > From RFC 2671 (heavily cropped to focus on Option code): > > # 7 - IANA Considerations > ... > # It is the recommendation of this document and its working group > # that IANA create a registry for EDNS Extended Label Types, for EDNS > # Option Codes, and for EDNS Version Numbers. > ... > # any published RFC (including Informational, Experimental, or BCP) > # should be grounds for allocation of an EDNS Option Code. > > That is IANA's official instructions. > And IANA ignored the instructions :-) I had the registries created around the time of the DO bit and NSID RFC's. Olafur From owner-namedroppers@ops.ietf.org Fri Apr 16 17:04:48 2010 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 5DA063A68A0; Fri, 16 Apr 2010 17:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.468, 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 uCjmCoEyRhJ9; Fri, 16 Apr 2010 17:04:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D6503A6803; Fri, 16 Apr 2010 17:04:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2vQ3-000LLK-Mf for namedroppers-data0@psg.com; Fri, 16 Apr 2010 23:57:55 +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.71 (FreeBSD)) (envelope-from ) id 1O2vPx-000LKr-Gq for namedroppers@ops.ietf.org; Fri, 16 Apr 2010 23:57:49 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 6ACB4A239F for ; Fri, 16 Apr 2010 23:57:48 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] Re: Reserved EDNS0 option codes for private use In-Reply-To: Your message of "Fri, 16 Apr 2010 11:21:08 MST." References: X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Fri, 16 Apr 2010 23:57:48 +0000 Message-ID: <29471.1271462268@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: Fri, 16 Apr 2010 11:21:08 -0700 > From: Matthew Dempsky > > No one? i am uncomfortable with private code point ranges in general. i didn't oppose it for rr type codes and i won't oppose it for edns0 option codes. but i sure hope that somebody else will (oppose it). From owner-namedroppers@ops.ietf.org Fri Apr 16 17:18:48 2010 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 5FF6E3A6358; Fri, 16 Apr 2010 17:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.455, 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 1+X9xgj1LNdn; Fri, 16 Apr 2010 17:18:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4CAEF3A69A4; Fri, 16 Apr 2010 17:18:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2vfv-000PUP-WD for namedroppers-data0@psg.com; Sat, 17 Apr 2010 00:14:20 +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.71 (FreeBSD)) (envelope-from ) id 1O2vfn-000PR0-En for namedroppers@ops.ietf.org; Sat, 17 Apr 2010 00:14:11 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 34431A238F for ; Sat, 17 Apr 2010 00:14:11 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] Re: Reserved EDNS0 option codes for private use In-Reply-To: Your message of "Fri\, 16 Apr 2010 15\:05\:38 MST." References: X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 17 Apr 2010 00:14:11 +0000 Message-ID: <30238.1271463251@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: Fri, 16 Apr 2010 15:05:38 -0700 > From: David Ulevitch >=20 > > From RFC 2671 (heavily cropped to focus on Option code): > > # 7 - IANA Considerations > > ... > > #=C2=A0=C2=A0=C2=A0=C2=A0 It is the recommendation of this document and= its working group > > #=C2=A0=C2=A0=C2=A0=C2=A0 that IANA create a registry for EDNS Extended= Label Types, for EDNS > > #=C2=A0=C2=A0=C2=A0=C2=A0 Option Codes, and for EDNS Version Numbers. > > ... > > #=C2=A0=C2=A0=C2=A0=C2=A0 any published RFC (including Informational, E= xperimental, or BCP) > > #=C2=A0=C2=A0=C2=A0=C2=A0 should be grounds for allocation of an EDNS O= ption Code. > > That is IANA's official instructions. > > >=20 > Yep, and that should change to make it easier. Or at the very least, > allow a reserved range for private use. 2671 says that noone can be denied but they have to document their blobs in RFC's, which can be individual submissions that do not require consensus. how much easier would you like it to be, and why? From owner-namedroppers@ops.ietf.org Fri Apr 16 19:40:14 2010 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 09E9A3A6A39; Fri, 16 Apr 2010 19:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.784 X-Spam-Level: * X-Spam-Status: No, score=1.784 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_05=-1.11, 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 hS3UfwVNMxu5; Fri, 16 Apr 2010 19:40:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 149103A6994; Fri, 16 Apr 2010 19:40:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2xrB-0006yD-BV for namedroppers-data0@psg.com; Sat, 17 Apr 2010 02:34:05 +0000 Received: from [209.85.223.175] (helo=mail-iw0-f175.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O2xr5-0006xj-Nl for namedroppers@ops.ietf.org; Sat, 17 Apr 2010 02:33:59 +0000 Received: by iwn5 with SMTP id 5so1845754iwn.9 for ; Fri, 16 Apr 2010 19:33:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Fri, 16 Apr 2010 19:33:58 -0700 (PDT) In-Reply-To: <30238.1271463251@nsa.vix.com> References: <30238.1271463251@nsa.vix.com> Date: Fri, 16 Apr 2010 19:33:58 -0700 Received: by 10.231.60.19 with SMTP id n19mr816621ibh.79.1271471638400; Fri, 16 Apr 2010 19:33:58 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Re: Reserved EDNS0 option codes for private use From: Matthew Dempsky To: IETF DNSEXT WG 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 Fri, Apr 16, 2010 at 5:14 PM, Paul Vixie wrote: > 2671 says that noone can be denied but they have to document their blobs > in RFC's, which can be individual submissions that do not require consensus. > > how much easier would you like it to be, and why? My opinion depends mostly on what the current distinction of "on-hold" vs "standard" vs "reserved" in the IANA registry means. Of the 4 options currently assigned by IANA, 2 are named and on-hold, 1 is named and standard, and 1 is simply reserved. Further, of these, only one is RFC assigned, whereas the other three are mere drafts (and expired at that). If, as my understanding suggests, those four values are all truly assigned, hold more or less equal weight, and will not be (at least without serious consideration for backwards compatibility) reappropriated later, then I'm happy with the current IANA procedure. That said, I still think there's merit to reserving a range of values for private use. From owner-namedroppers@ops.ietf.org Fri Apr 16 22:36:05 2010 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 B27033A68D5; Fri, 16 Apr 2010 22:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 Ypoff2X4bwkz; Fri, 16 Apr 2010 22:36:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1CFE93A68C0; Fri, 16 Apr 2010 22:36:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O30aW-000NXz-Tw for namedroppers-data0@psg.com; Sat, 17 Apr 2010 05:29:04 +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.71 (FreeBSD)) (envelope-from ) id 1O30aR-000NXU-6Z for namedroppers@ops.ietf.org; Sat, 17 Apr 2010 05:28:59 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id EE971A23FD; Sat, 17 Apr 2010 05:28:56 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Matthew Dempsky cc: IETF DNSEXT WG Subject: Re: [dnsext] Re: Reserved EDNS0 option codes for private use In-Reply-To: Your message of "Fri, 16 Apr 2010 19:33:58 MST." References: <30238.1271463251@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Sat, 17 Apr 2010 05:28:56 +0000 Message-ID: <35319.1271482136@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: Fri, 16 Apr 2010 19:33:58 -0700 > From: Matthew Dempsky > ... > If, as my understanding suggests, those four values are all truly > assigned, hold more or less equal weight, and will not be (at least > without serious consideration for backwards compatibility) reappropriated > later, then I'm happy with the current IANA procedure. that's my understanding. > That said, I still think there's merit to reserving a range of values > for private use. why? From faunasn611@catsan.ru Fri Apr 16 23:18:01 2010 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 EE8613A6A1D; Fri, 16 Apr 2010 23:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.937 X-Spam-Level: X-Spam-Status: No, score=-86.937 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 8euREEWrwKUf; Fri, 16 Apr 2010 23:18:00 -0700 (PDT) Received: from host-79.173.26.82.tesatnet.pl (host-79.173.26.82.tesatnet.pl [79.173.26.82]) by core3.amsl.com (Postfix) with ESMTP id CBAD53A6A43; Fri, 16 Apr 2010 23:17:59 -0700 (PDT) Received: from 79.173.26.82 by uukmx01.mars-inc.com; Sat, 17 Apr 2010 08:17:50 +0100 Date: Sat, 17 Apr 2010 08:17:50 +0100 From: dnsext-archive@ietf.org Subject: Meet that special someone today To: Message-ID: <000d01caddf5$b4aec8c0$6400a8c0@faunasn611> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Meet that special someone today. It costs you nothing to check it out. All you have to do is press this web link and you'll be chatting with someone in no time. http://veto432.spaces.live.com From meadowsk8@pifl.ru Fri Apr 16 23:18:08 2010 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 060E73A6A43 for ; Fri, 16 Apr 2010 23:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.937 X-Spam-Level: X-Spam-Status: No, score=-86.937 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 RSe3uVQraBco for ; Fri, 16 Apr 2010 23:18:07 -0700 (PDT) Received: from host-79.173.26.82.tesatnet.pl (host-79.173.26.82.tesatnet.pl [79.173.26.82]) by core3.amsl.com (Postfix) with ESMTP id 54EC93A6A1D for ; Fri, 16 Apr 2010 23:18:03 -0700 (PDT) Received: from 79.173.26.82 by de1.bquadro.com; Sat, 17 Apr 2010 08:17:54 +0100 Date: Sat, 17 Apr 2010 08:17:54 +0100 From: dnsext-archive@lists.ietf.org Subject: Meet that special someone today To: Message-ID: <000d01caddf5$b76499f0$6400a8c0@meadowsk8> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Meet that special someone today. It costs you nothing to check it out. All you have to do is press this web link and you'll be chatting with someone in no time. http://veto432.spaces.live.com From owner-namedroppers@ops.ietf.org Fri Apr 16 23:22:57 2010 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 944913A6A14; Fri, 16 Apr 2010 23:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.96 X-Spam-Level: * X-Spam-Status: No, score=1.96 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_20=-0.74, 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 dzjtkAWxxPaI; Fri, 16 Apr 2010 23:22:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3BE8A3A6A50; Fri, 16 Apr 2010 23:22:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O31M0-0008ee-Bd for namedroppers-data0@psg.com; Sat, 17 Apr 2010 06:18:08 +0000 Received: from [209.85.210.186] (helo=mail-yx0-f186.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O31Ls-0008e4-Jl for namedroppers@ops.ietf.org; Sat, 17 Apr 2010 06:18:00 +0000 Received: by yxe16 with SMTP id 16so1934337yxe.9 for ; Fri, 16 Apr 2010 23:17:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.212 with HTTP; Fri, 16 Apr 2010 23:17:59 -0700 (PDT) In-Reply-To: <35319.1271482136@nsa.vix.com> References: <30238.1271463251@nsa.vix.com> <35319.1271482136@nsa.vix.com> Date: Fri, 16 Apr 2010 23:17:59 -0700 Received: by 10.101.21.13 with SMTP id y13mr5863686ani.210.1271485079558; Fri, 16 Apr 2010 23:17:59 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Re: Reserved EDNS0 option codes for private use From: Matthew Dempsky To: IETF DNSEXT WG 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 Fri, Apr 16, 2010 at 10:28 PM, Paul Vixie wrote: >> Date: Fri, 16 Apr 2010 19:33:58 -0700 >> From: Matthew Dempsky >> ... >> If, as my understanding suggests, those four values are all truly >> assigned, hold more or less equal weight, and will not be (at least >> without serious consideration for backwards compatibility) reappropriated >> later, then I'm happy with the current IANA procedure. > > that's my understanding. Cool, good to know. >> That said, I still think there's merit to reserving a range of values >> for private use. > > why? So an example would be right now with edns-client-ip. I'd like to be experimenting with it and getting some operational experience, but no code point has been assigned yet. Fortunately, the allocation rules for the EDNS0 Option registry is loose enough that IANA could already assign a code for use, but the protocol (in particular, the wire format) isn't fully solidified yet. So what happens when -01 is released and isn't compatible with -00? Or when -02 isn't compatible with either, etc? The best solution I see is for experimenters to make pairwise agreements using new private option codes for each incompatible change until the protocol extension has stabilized, and then start using an IANA assigned code. Otherwise you risk either compatibility issues as experimenters independently revise their software, or polluting the registry with assignments that will most likely be short lived. (Perhaps there's a way to 'garbage collect' these assignments later, but I'm concerned about how well positioned IANA is to do this; at least private parties are in a position to know which private codes they're actually using.) From owner-namedroppers@ops.ietf.org Fri Apr 16 23:51:58 2010 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 8C7153A6998; Fri, 16 Apr 2010 23:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 sQuykRcpXotc; Fri, 16 Apr 2010 23:51:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 65DE03A6960; Fri, 16 Apr 2010 23:51:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O31nr-000El6-Tb for namedroppers-data0@psg.com; Sat, 17 Apr 2010 06:46:55 +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.71 (FreeBSD)) (envelope-from ) id 1O31np-000Ekm-TN for namedroppers@ops.ietf.org; Sat, 17 Apr 2010 06:46:53 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id BB6FEA2405 for ; Sat, 17 Apr 2010 06:46:52 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] Re: Reserved EDNS0 option codes for private use In-Reply-To: Your message of "Fri, 16 Apr 2010 23:17:59 MST." References: <30238.1271463251@nsa.vix.com> <35319.1271482136@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Sat, 17 Apr 2010 06:46:52 +0000 Message-ID: <43613.1271486812@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: Fri, 16 Apr 2010 23:17:59 -0700 > From: Matthew Dempsky > > So an example would be right now with edns-client-ip. I'd like to be > experimenting with it and getting some operational experience, but no > code point has been assigned yet. Fortunately, the allocation rules for > the EDNS0 Option registry is loose enough that IANA could already assign > a code for use, but the protocol (in particular, the wire format) isn't > fully solidified yet. So what happens when -01 is released and isn't > compatible with -00? Or when -02 isn't compatible with either, etc? i see the problem. > The best solution I see is for experimenters to make pairwise agreements > using new private option codes for each incompatible change until the > protocol extension has stabilized, and then start using an IANA assigned > code. Otherwise you risk either compatibility issues as experimenters > independently revise their software, or polluting the registry with > assignments that will most likely be short lived. (Perhaps there's a way > to 'garbage collect' these assignments later, but I'm concerned about how > well positioned IANA is to do this; at least private parties are in a > position to know which private codes they're actually using.) ietf isn't well set up for incremental experimentation. that should change. you should be able to publish a draft, spend no more than a couple of weeks getting "experimental consensus" on it, and then have it posted as an RFC with an "experimental codepoint" or "experimental codepoint range". when you get done trying out ideas and you have something that you and your pairwise buddies all like, you should be able to publish a draft and have it either adopted (put on the standards track) or published as a bcp or experimental, with a (new) codepoint assigned. all of which is 2.5 orders of magnitude than ietf's wheels can currently spin. and on that lone basis i can understand why a private range makes sense. but from iab's standpoint it would be better to fix the process so that a private range wasn't needed, than to reserve a private range. for one thing it would enable robust open experimentation, and for another thing it would rule out the possibility that once opendns and google and akamai all privately agreed on what they wanted and how it should work they would stop trying to publish the results openly since their business problem had already been solved. From owner-namedroppers@ops.ietf.org Sat Apr 17 08:24:28 2010 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 5B8083A67C0; Sat, 17 Apr 2010 08:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.913 X-Spam-Level: * X-Spam-Status: No, score=1.913 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_50=0.001, 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 YXd18-8V56Ev; Sat, 17 Apr 2010 08:24:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E0323A6826; Sat, 17 Apr 2010 08:24:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O39m7-000PnH-Ug for namedroppers-data0@psg.com; Sat, 17 Apr 2010 15:17:39 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O39m4-000Pmy-Lz for namedroppers@ops.ietf.org; Sat, 17 Apr 2010 15:17:37 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3HFHRkR084889; Sat, 17 Apr 2010 11:17:27 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.104] by Work-Laptop-2.local (PGP Universal service); Sat, 17 Apr 2010 11:17:33 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Sat, 17 Apr 2010 11:17:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <30238.1271463251@nsa.vix.com> <35319.1271482136@nsa.vix.com> Date: Sat, 17 Apr 2010 11:16:47 -0400 To: Matthew Dempsky From: Edward Lewis Subject: [dnsext] the protocol registry assignment dilemma Cc: IETF DNSEXT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 23:17 -0700 4/16/10, Matthew Dempsky wrote: >I'd like to be >experimenting with it and getting some operational experience, but no >code point has been assigned yet. Fortunately, the allocation rules >for the EDNS0 Option registry is loose enough that IANA could already >assign a code for use, but the protocol (in particular, the wire >format) isn't fully solidified yet. So what happens when -01 is >released and isn't compatible with -00? Or when -02 isn't compatible >with either, etc? You are raising an issue that has lingered for a long time. A while back it was over the assignment of resource record types, and the trouble with TXT records. (In the expired MARID WG, SPF vs. TXT wars for one.) You are right in what you want to do. And your observation is right too. To adequately test something, you need to release it into the wild. If you don't assign a good number and the idea catches fire, it's too late to renumber. But if it dies on the vine then you've assigned a good number, the number is marked for life. Because there's always someone somewhere that will claim that the idea is being used in some village somewhere out in the plains. >(Perhaps there's a way to 'garbage collect' these assignments later, >but I'm concerned about how well positioned IANA is to do this; at I wish there was too, but it's not entirely IANA's fault. The IETF could direct IANA to return a value to the available space but there is always reluctance. >least private parties are in a position to know which private codes >they're actually using.) In some cases, using private types would be a good idea before writing up the ideas to result in a real IANA assignment. (But, there's got to be a better way...I mean to the general management of registry assignments.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From dnsext-archive@ietf.org Sat Apr 17 08:25:59 2010 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 9B85E3A67C0 for ; Sat, 17 Apr 2010 08:25:59 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char A9 hex): From: \251 Pfizer Inc \256 1[...] X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_GET_MEDS=2.75, HS_INDEX_PARAM=0.001, MIME_8BIT_HEADER=0.3, 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, TVD_QUAL_MEDS=3.568, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_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 lSuPt7sdVrx6 for ; Sat, 17 Apr 2010 08:25:59 -0700 (PDT) Received: from tony09-114-31.inter.net.il (tony09-114-31.inter.net.il [213.8.114.31]) by core3.amsl.com (Postfix) with SMTP id EC88C3A6826 for ; Sat, 17 Apr 2010 08:25:56 -0700 (PDT) From: Pfizer Inc 1871-2010 To: dnsext-archive@ietf.org Subject: RE: dnsext-archive@ietf.org April 82% off Mime-Version: 1.0 Content-type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100417152556.EC88C3A6826@core3.amsl.com> Date: Sat, 17 Apr 2010 08:25:56 -0700 (PDT) Dear dnsext-archive@ietf.org Get ready to make her happy. Discount price store: ID73149 http://kuy.tabsam.ru?xwh We do guarantee high-quality medications, instant worldwide delivery and friendly support. 2001-2010 Pfizer Inc. All rights reserved. From dmanet@ietf.org Sat Apr 17 09:05:30 2010 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 7D2963A689A for ; Sat, 17 Apr 2010 09:05:30 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sat, 17 Apr 2010 09:05:28 -0700 (PDT) Received: from alliance-mortgage.com (unknown [122.167.154.44]) by core3.amsl.com (Postfix) with SMTP id B89FE3A6925 for ; Sat, 17 Apr 2010 09:05:24 -0700 (PDT) From: Approved VIAGRA® Store Subject: News on myspace To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100417160526.B89FE3A6925@core3.amsl.com> Date: Sat, 17 Apr 2010 09:05:24 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 02512 Inc. All rights reserved.

From dnsext-archive@ietf.org Sat Apr 17 12:30:15 2010 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 3C0343A6926 for ; Sat, 17 Apr 2010 12:30:15 -0700 (PDT) X-Quarantine-ID: <6IQ-4QNC7jE0> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char A9 hex): From: \251 Pfizer Inc \256 1[...] X-Spam-Flag: NO X-Spam-Score: -34.825 X-Spam-Level: X-Spam-Status: No, score=-34.825 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_GET_MEDS=2.75, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HS_INDEX_PARAM=0.001, MIME_8BIT_HEADER=0.3, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_QUAL_MEDS=3.568, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_PH_SURBL=1.787, 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 6IQ-4QNC7jE0 for ; Sat, 17 Apr 2010 12:30:09 -0700 (PDT) Received: from 178.182.70.112.nat.umts.dynamic.eranet.pl (178.182.70.112.nat.umts.dynamic.eranet.pl [178.182.70.112]) by core3.amsl.com (Postfix) with SMTP id 441B93A684A for ; Sat, 17 Apr 2010 12:30:06 -0700 (PDT) From: Pfizer Inc 1873-2010 To: dnsext-archive@ietf.org Subject: RE: dnsext-archive@ietf.org April 83% off Mime-Version: 1.0 Content-type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100417193007.441B93A684A@core3.amsl.com> Date: Sat, 17 Apr 2010 12:30:06 -0700 (PDT) Dear dnsext-archive@ietf.org Get ready to make her happy. Discount price store: ID0687517 http://ltk.speakabove.ru?siu We do guarantee high-quality medications, instant worldwide delivery and friendly support. 2001-2010 Pfizer Inc. All rights reserved. From dnsdelta@genehmigung.guestbook.selfip.com Sat Apr 17 16:24:56 2010 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 F280D3A69F6 for ; Sat, 17 Apr 2010 16:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.159 X-Spam-Level: X-Spam-Status: No, score=-16.159 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_GET_MEDS=2.75, 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_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, TVD_QUAL_MEDS=3.568, 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 T5Nyjlwad-+q for ; Sat, 17 Apr 2010 16:24:55 -0700 (PDT) Received: from IGLD-84-228-105-114.inter.net.il (IGLD-84-228-105-114.inter.net.il [84.228.105.114]) by core3.amsl.com (Postfix) with SMTP id 3C3CF3A6AA7 for ; Sat, 17 Apr 2010 16:24:53 -0700 (PDT) TO: From:ED-Tabl's Subject: Discount 51% MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <20100417232454.3C3CF3A6AA7@core3.amsl.com> Date: Sat, 17 Apr 2010 16:24:53 -0700 (PDT) Dear (dnsext-archive@ietf.org)=3B
Get ready to make her happy.
Discount pric= e store:
http://ox.drugsjordan.ru
We do guaran= tee high-quality medications=2C instant worldwide delivery and friendly sup= port.
2001-2010 Pfizer Inc. All rights reserved.
The New Busy is not the old busy. Search=2C chat and e-mail from your inbo= x. Get started.<= /body> = From dnsext-archive@ietf.org Sun Apr 18 00:12:21 2010 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 2B7463A693B for ; Sun, 18 Apr 2010 00:12:21 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char A9 hex): From: \251 Pfizer Inc \256 1[...] X-Spam-Flag: NO X-Spam-Score: -37.297 X-Spam-Level: X-Spam-Status: No, score=-37.297 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_GET_MEDS=2.75, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HS_INDEX_PARAM=0.001, MIME_8BIT_HEADER=0.3, 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_DUL=0.877, RCVD_IN_XBL=3.033, TVD_QUAL_MEDS=3.568, 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 fk9XrS1-c6PR for ; Sun, 18 Apr 2010 00:12:19 -0700 (PDT) Received: from akr154.internetdsl.tpnet.pl (akr154.internetdsl.tpnet.pl [83.17.21.154]) by core3.amsl.com (Postfix) with SMTP id 384F53A677D for ; Sun, 18 Apr 2010 00:12:19 -0700 (PDT) From: Pfizer Inc 1874-2010 To: dnsext-archive@ietf.org Subject: RE: dnsext-archive@ietf.org April 75% off Mime-Version: 1.0 Content-type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100418071219.384F53A677D@core3.amsl.com> Date: Sun, 18 Apr 2010 00:12:19 -0700 (PDT) Dear dnsext-archive@ietf.org Get ready to make her happy. Discount price store: ID0365965 http://jsc.mapshoe.ru?shq We do guarantee high-quality medications, instant worldwide delivery and friendly support. 2001-2010 Pfizer Inc. All rights reserved. From dm@ietf.org Sun Apr 18 01:09:08 2010 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 C20DC28C148 for ; Sun, 18 Apr 2010 01:09:08 -0700 (PDT) X-Quarantine-ID: <6HbtsAHTq1Sr> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sun, 18 Apr 2010 01:09:06 -0700 (PDT) Received: from aguero.com (unknown [79.140.11.123]) by core3.amsl.com (Postfix) with SMTP id 273C028C14A for ; Sun, 18 Apr 2010 01:07:33 -0700 (PDT) From: Approved VIAGRA® Store Subject: News on myspace To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100418080735.273C028C14A@core3.amsl.com> Date: Sun, 18 Apr 2010 01:07:33 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 46134 Inc. All rights reserved.

From dnsext-archive@ietf.org Sun Apr 18 06:28:39 2010 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 296183A693C for ; Sun, 18 Apr 2010 06:28:39 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char A9 hex): From: \251 Pfizer Inc \256 1[...] X-Spam-Flag: NO X-Spam-Score: 2.613 X-Spam-Level: ** X-Spam-Status: No, score=2.613 tagged_above=-999 required=5 tests=[BANG_GUAR=0.939, BAYES_99=3.5, FB_NO_SCRIP_NEEDED=10.357, FH_HOST_EQ_D_D_D_D=0.765, GB_NOSCRIP=2, GB_PHARMACY=1, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, NO_PRESCRIPTION=2.619, ONLINE_PHARMACY=0.001, 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_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_VISIT_PHARMA=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, 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 P6XXBsLVEdlb for ; Sun, 18 Apr 2010 06:28:38 -0700 (PDT) Received: from dnm.17.35.188.95.dsl.krasnet.ru (dnm.17.35.188.95.dsl.krasnet.ru [95.188.35.17]) by core3.amsl.com (Postfix) with SMTP id 5277A3A6914 for ; Sun, 18 Apr 2010 06:28:37 -0700 (PDT) From: Pfizer Inc 1806-2010 To: dnsext-archive@ietf.org Subject: 18.4.2010 Discount ID1094 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100418132837.5277A3A6914@core3.amsl.com> Date: Sun, 18 Apr 2010 06:28:37 -0700 (PDT)
Online pharmacy. No prescription needed! Cheapest price!. View this email on a mobile device, or web browser.
  PHARMACY Catalogue Quick Order Forward to a Friend
Save huge 80% http://refillpatten.ru
Online Pharmacy 80% OFF Everything.

Order Now While Quantities Last!

30 Day Money Back Satisfaction Guarantee!

http://refillpatten.ru

 

VIEW PRIVACY POLICY
This email was sent to: dnsext-archive@ietf.org

CLICK HERE TO UNSUBSCRIBE
Please allow 24 - 48 hours for processing.

Products limited and may sell out at any time. Prices are subject to change.
From dminnn@ietf.org Sun Apr 18 14:30:44 2010 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 264593A6942 for ; Sun, 18 Apr 2010 14:30:44 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Sun, 18 Apr 2010 14:30:42 -0700 (PDT) Received: from aandl-labs.com (h1716.n2.ips.mtn.co.ug [212.88.119.22]) by core3.amsl.com (Postfix) with SMTP id BF1413A67AF for ; Sun, 18 Apr 2010 14:30:19 -0700 (PDT) From: Approved VIAGRA® Store Subject: News on myspace To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100418213036.BF1413A67AF@core3.amsl.com> Date: Sun, 18 Apr 2010 14:30:19 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 65530 Inc. All rights reserved.

From dmin@ietf.org Mon Apr 19 10:17:08 2010 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 535C43A6855 for ; Mon, 19 Apr 2010 10:17:08 -0700 (PDT) X-Quarantine-ID: <6i3t4Q3ohc9u> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 19 Apr 2010 10:17:01 -0700 (PDT) Received: from 173-161-201-157-Philadelphia.hfc.comcastbusiness.net (173-161-201-157-Philadelphia.hfc.comcastbusiness.net [173.161.201.157]) by core3.amsl.com (Postfix) with SMTP id 6439128C1AC for ; Mon, 19 Apr 2010 10:12:02 -0700 (PDT) From: Approved VIAGRA® Store Subject: Special Code for 75% for dnsext-archive@ietf.org To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100419171205.6439128C1AC@core3.amsl.com> Date: Mon, 19 Apr 2010 10:12:02 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 74700 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Mon Apr 19 11:11:54 2010 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 3758B3A695D; Mon, 19 Apr 2010 11:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.798 X-Spam-Level: X-Spam-Status: No, score=-100.798 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_50=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 fhupI0pwF3bg; Mon, 19 Apr 2010 11:11:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 083743A68CF; Mon, 19 Apr 2010 11:11:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O3vLP-000NKv-Rx for namedroppers-data0@psg.com; Mon, 19 Apr 2010 18:05:15 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O3vLH-000MvD-Nm for namedroppers@ops.ietf.org; Mon, 19 Apr 2010 18:05:12 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o3JI3wDW005270; Mon, 19 Apr 2010 18:04:00 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o3JI3qTZ005265; Mon, 19 Apr 2010 18:03:52 GMT Date: Mon, 19 Apr 2010 18:03:47 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: Matthew Dempsky , IETF DNSEXT WG Subject: Re: [dnsext] the protocol registry assignment dilemma Message-ID: <20100419180347.GC4262@vacation.karoshi.com.> References: <30238.1271463251@nsa.vix.com> <35319.1271482136@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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, Apr 17, 2010 at 11:16:47AM -0400, Edward Lewis wrote: > At 23:17 -0700 4/16/10, Matthew Dempsky wrote: > > >I'd like to be > >experimenting with it and getting some operational experience, but no > >code point has been assigned yet. Fortunately, the allocation rules > >for the EDNS0 Option registry is loose enough that IANA could already > >assign a code for use, but the protocol (in particular, the wire > >format) isn't fully solidified yet. So what happens when -01 is > >released and isn't compatible with -00? Or when -02 isn't compatible > >with either, etc? > > You are raising an issue that has lingered for a long time. A while > back it was over the assignment of resource record types, and the > trouble with TXT records. (In the expired MARID WG, SPF vs. TXT wars > for one.) [wonderful prose elided] > Edward Lewis back in the mysts of time, a credible proposal (an ID even) would merit the assignment of a code point with the IANA. This model has much to its credit. However, over time, it was deemed reasonable to withhold code points for a variety of reasons... not all of them sane or credible. And today we are in this wonderful situation where it is often easier/simpler to just "pick" a code point and run with it. Paul Vixies plan, to release with testpoints and then when proven successful, -re- release with "real" code points is not credible given software refresh cycles by endusers. --bill From dm@ietf.org Mon Apr 19 12:05:23 2010 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 2ED743A6A0D for ; Mon, 19 Apr 2010 12:05:23 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 19 Apr 2010 12:05:16 -0700 (PDT) Received: from gprs-clientes00.claro.com.gt (gprs-clientes00.claro.com.gt [216.230.133.69]) by core3.amsl.com (Postfix) with SMTP id 13F283A67C2 for ; Mon, 19 Apr 2010 12:05:07 -0700 (PDT) From: Approved VIAGRA® Store Subject: Your Future Order with 72% off retail To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100419190512.13F283A67C2@core3.amsl.com> Date: Mon, 19 Apr 2010 12:05:07 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 66793 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Mon Apr 19 14:10:24 2010 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 52ED63A68D4; Mon, 19 Apr 2010 14:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.737 X-Spam-Level: X-Spam-Status: No, score=0.737 tagged_above=-999 required=5 tests=[AWL=-1.368, BAYES_50=0.001, 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 kSY0kJ-jKi6J; Mon, 19 Apr 2010 14:10:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 208C03A68BA; Mon, 19 Apr 2010 14:10:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O3y8u-0005oi-4j for namedroppers-data0@psg.com; Mon, 19 Apr 2010 21:04:32 +0000 Received: from [208.83.67.149] (helo=klovia.htt-consult.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O3y8p-0005mT-8F for namedroppers@ops.ietf.org; Mon, 19 Apr 2010 21:04:27 +0000 Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 7614568CDF; Mon, 19 Apr 2010 20:58:48 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnwF0zlZopeu; Mon, 19 Apr 2010 16:58:38 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm-ietf@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 720A368C39; Mon, 19 Apr 2010 16:58:38 -0400 (EDT) Message-ID: <4BCCC54D.4030805@htt-consult.com> Date: Mon, 19 Apr 2010 17:04:13 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Hoffman CC: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-hoffman-dnssec-ecdsa-01 References: <201001271230.NAA07971@TR-Sys.de> In-Reply-To: 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 01/27/2010 11:23 AM, Paul Hoffman wrote: > At 1:30 PM +0100 1/27/10, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: > >> I have a few technical points to be discussed for the DNSSEC >> EDCDA draft, draft-hoffman-dnssec-ecdsa-01. >> >> >> (1) bit string vs. octet strings >> >> Cryptographers are used to think in bit strings of arbitrary >> bit size. DNS folks usually deal with octet strings. >> >> Since the introduction of bit strings does not incur any visible >> benefit here, I suggest to avoid the notion of bit strings entirely >> throughout the draft and use octet string oriented language and >> octet string sizes for field descriptions. >> > I figured that keeping the cryptographers happy while not hurting the DNS folks was a good idea. I'm happy to change, however. > Paul, is there some reason you did not include P-521? I might think it should be here for completeness. It is in RFCs like 4753. > >> (2) representation of EC keys >> >> Section 3 of the draft says (in its first paragraph): >> >> | ECDSA public keys consist of a single value, called "Q" in FIPS >> | 186-3. In DNSSEC keys, Q is a simple bit string that represents >> | the uncompressed form of a curve point. >> >> This is by far underspecified for the intended audience of this memo. >> >> Section 2.3.3 of the SEC-1 Standard specifies the precise algorithm >> to convert an EC point to a 'normalized' octet string. >> This algorithm is widely adopted (IEEE, ANSI, NIST, IETF PKIX, etc.). >> Making explicit reference to the resulting data format should >> provide benefits for re-using existing crypto-APIs as well. >> >> I recommend to normatively quote this specification in a similar >> way as it is done in various new RFCs, including this week's >> RFC 575? series. >> > That sounds good. > > >> Further, the restriction to uncompressed form seems unnecessary, >> or even detrimental to the intended benefit of savings in DNS >> response packet size as well as consumed bandwidth and delay. >> The use of the compressed form essentially would cut down the >> EC key size to half the size of the uncompressed form. >> > Some IPR claims have been made on the compressed form, and none on the uncompressed form. I chose to avoid that problem. > > >> The draft text also is silent about the 'quality' requirements. >> SEC-1 and various NIST publications contain verification procedures >> and requirements for key generators, signers, and verifiers. >> Such requirements are already imported in recent IETF documents, >> cf. the abovementioned RFC 575? series. >> I suggest that the draft be amended by related normative text, >> after discussion of the assurance level the WG deems needed for >> this application of ECC. >> > The current DNSSEC documents do not reference the NIST material on provable and probable primes in the discussion of RSA. The material you suggest is parallel. I'm happy to add it, but it will likely cause people to think that ECC is harder than RSA. > > >> (3) Precision if data element/field specification >> >> Given the intended audience of the draft, the size of the data >> elements used in the specification should be made explicit. >> >> I suggest to introduce a parameter 'm' (this is 'mlen' in SEC-1) >> into the table in Section 3 and make systematical use of it in >> Section 4. >> > Given how few people understand NIST's m values, I think this will lead to more confusion for no benefit. > > > --Paul Hoffman, Director > --VPN Consortium > > > From owner-namedroppers@ops.ietf.org Mon Apr 19 14:30:25 2010 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 F20163A68BA; Mon, 19 Apr 2010 14:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=-3.572, BAYES_50=0.001, 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 Cz9KDZhQPrUp; Mon, 19 Apr 2010 14:30:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D56093A68AA; Mon, 19 Apr 2010 14:30:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O3ySr-0009Tq-FB for namedroppers-data0@psg.com; Mon, 19 Apr 2010 21:25:09 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O3ySl-0009SQ-5D for namedroppers@ops.ietf.org; Mon, 19 Apr 2010 21:25:03 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o3JLOw0Z003185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Apr 2010 14:24:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4BCCC54D.4030805@htt-consult.com> References: <201001271230.NAA07971@TR-Sys.de> <4BCCC54D.4030805@htt-consult.com> Date: Mon, 19 Apr 2010 14:24:57 -0700 To: Robert Moskowitz From: Paul Hoffman Subject: Re: [dnsext] draft-hoffman-dnssec-ecdsa-01 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 5:04 PM -0400 4/19/10, Robert Moskowitz wrote: >On 01/27/2010 11:23 AM, Paul Hoffman wrote: >>At 1:30 PM +0100 1/27/10, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >> >>>I have a few technical points to be discussed for the DNSSEC >>>EDCDA draft, draft-hoffman-dnssec-ecdsa-01. >>> >>> >>>(1) bit string vs. octet strings >>> >>>Cryptographers are used to think in bit strings of arbitrary >>>bit size. DNS folks usually deal with octet strings. >>> >>>Since the introduction of bit strings does not incur any visible >>>benefit here, I suggest to avoid the notion of bit strings entirely >>>throughout the draft and use octet string oriented language and >>>octet string sizes for field descriptions. >>> >>I figured that keeping the cryptographers happy while not hurting the DNS folks was a good idea. I'm happy to change, however. >> > >Paul, is there some reason you did not include P-521? I might think it should be here for completeness. It is in RFCs like 4753. "Completeness" when you are talking about signature algorithms is not necessarily a good thing. What possible thread model are you concerned with that requires a symmetric strength greater than 192 bits? --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Mon Apr 19 14:42:28 2010 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 EAF3D3A68DB; Mon, 19 Apr 2010 14:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.524 X-Spam-Level: X-Spam-Status: No, score=0.524 tagged_above=-999 required=5 tests=[AWL=2.361, BAYES_50=0.001, 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 SSl6xAkIiSpZ; Mon, 19 Apr 2010 14:42:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DDB1F3A696D; Mon, 19 Apr 2010 14:42:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O3yeY-000BPf-E1 for namedroppers-data0@psg.com; Mon, 19 Apr 2010 21:37:14 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O3yeS-000BOT-9Y for namedroppers@ops.ietf.org; Mon, 19 Apr 2010 21:37:08 +0000 Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id AD046A944D9; Mon, 19 Apr 2010 21:37:07 +0000 (UTC) Message-ID: <4BCCCD01.6090602@mail-abuse.org> Date: Mon, 19 Apr 2010 14: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.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Edward Lewis , Matthew Dempsky , IETF DNSEXT WG Subject: Re: [dnsext] the protocol registry assignment dilemma References: <30238.1271463251@nsa.vix.com> <35319.1271482136@nsa.vix.com> <20100419180347.GC4262@vacation.karoshi.com.> In-Reply-To: <20100419180347.GC4262@vacation.karoshi.com.> 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 4/19/10 11:03 AM, bmanning@vacation.karoshi.com wrote: > On Sat, Apr 17, 2010 at 11:16:47AM -0400, Edward Lewis wrote: > >> You are raising an issue that has lingered for a long time. A while >> back it was over the assignment of resource record types, and the >> trouble with TXT records. (In the expired MARID WG, SPF vs. TXT wars >> for one.) >> > [wonderful prose elided] > >> Edward Lewis >> > back in the mysts of time, a credible proposal (an ID even) > would merit the assignment of a code point with the IANA. This model > has much to its credit. However, over time, it was deemed reasonable > to withhold code points for a variety of reasons... not all of them > sane or credible. And today we are in this wonderful situation where > it is often easier/simpler to just "pick" a code point and run with > it. > > Paul Vixies plan, to release with testpoints and then when proven > successful, -re- release with "real" code points is not credible > given software refresh cycles by endusers. > SPF and Sender-ID have incompatible semantics for the same TXT RR. There were no new code points or label prefixes. Utilizing the _same_ preamble within the TXT RR allowed claims of higher adoption rates for either use, with loss of clarity of which message element use had been authorized (not authenticated). There was no shortage of TXT RR preambles since TXT RR preambles have no registry. There does not appear to be any easy way to overcome limitations imposed by proprietary environments that might make it difficult to introduce new RR types, or a means to avoid two groups claiming to have defined semantics for identical resources and to be thereby leading the parade. If there had been code points defined as private, the IETF may have had an opportunity to subsequently ensure adoption of separate non-private code points for records having different semantics. -Doug From owner-namedroppers@ops.ietf.org Mon Apr 19 15:43:22 2010 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 281403A67AF; Mon, 19 Apr 2010 15:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.107 X-Spam-Level: X-Spam-Status: No, score=-0.107 tagged_above=-999 required=5 tests=[AWL=0.388, 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 7wMepQNVxoZo; Mon, 19 Apr 2010 15:43:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A7A43A67A3; Mon, 19 Apr 2010 15:43:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O3zbX-000LEm-4K for namedroppers-data0@psg.com; Mon, 19 Apr 2010 22:38:11 +0000 Received: from [208.83.67.149] (helo=klovia.htt-consult.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O3zbU-000LEN-Jp for namedroppers@ops.ietf.org; Mon, 19 Apr 2010 22:38:08 +0000 Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id AD84968C39; Mon, 19 Apr 2010 22:32:28 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ck70HuW-eLJ; Mon, 19 Apr 2010 18:32:19 -0400 (EDT) Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm-ietf@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 8ECBC68C34; Mon, 19 Apr 2010 18:32:19 -0400 (EDT) Message-ID: <4BCCDB43.3080907@htt-consult.com> Date: Mon, 19 Apr 2010 18:37:55 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Hoffman CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-hoffman-dnssec-ecdsa-01 References: <201001271230.NAA07971@TR-Sys.de> <4BCCC54D.4030805@htt-consult.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 04/19/2010 05:24 PM, Paul Hoffman wrote: > At 5:04 PM -0400 4/19/10, Robert Moskowitz wrote: > >> On 01/27/2010 11:23 AM, Paul Hoffman wrote: >> >>> At 1:30 PM +0100 1/27/10, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >>> >>> >>>> I have a few technical points to be discussed for the DNSSEC >>>> EDCDA draft, draft-hoffman-dnssec-ecdsa-01. >>>> >>>> >>>> (1) bit string vs. octet strings >>>> >>>> Cryptographers are used to think in bit strings of arbitrary >>>> bit size. DNS folks usually deal with octet strings. >>>> >>>> Since the introduction of bit strings does not incur any visible >>>> benefit here, I suggest to avoid the notion of bit strings entirely >>>> throughout the draft and use octet string oriented language and >>>> octet string sizes for field descriptions. >>>> >>>> >>> I figured that keeping the cryptographers happy while not hurting the DNS folks was a good idea. I'm happy to change, however. >>> >>> >> Paul, is there some reason you did not include P-521? I might think it should be here for completeness. It is in RFCs like 4753. >> > "Completeness" when you are talking about signature algorithms is not necessarily a good thing. What possible thread model are you concerned with that requires a symmetric strength greater than 192 bits? Just need the DNSKEY RR, not the SIG RR; for HIP. RFC 5201 uses the DNSSEC format for the HOST_ID TLV as does RFC 5205. So as we rev them to add ECDSA, we would benefit from an already described P-521 format. From owner-namedroppers@ops.ietf.org Mon Apr 19 16:40:31 2010 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 158F73A689C; Mon, 19 Apr 2010 16:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.664 X-Spam-Level: X-Spam-Status: No, score=-100.664 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_50=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 wb0SEpyIWpYW; Mon, 19 Apr 2010 16:40:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1441A3A67A3; Mon, 19 Apr 2010 16:40:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O40VT-0004j0-Sg for namedroppers-data0@psg.com; Mon, 19 Apr 2010 23:35:59 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O40VR-0004fA-L3 for namedroppers@ops.ietf.org; Mon, 19 Apr 2010 23:35:57 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o3JNZBDW008250; Mon, 19 Apr 2010 23:35:11 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o3JNZ9i9008249; Mon, 19 Apr 2010 23:35:09 GMT Date: Mon, 19 Apr 2010 23:35:09 +0000 From: bmanning@vacation.karoshi.com To: John Payne Cc: Jim Reid , IETF DNSEXT WG Subject: Re: [dnsext] add support for latency-sensitive dns applications such as the web? Message-ID: <20100419233509.GD6110@vacation.karoshi.com.> References: <20100414214925.GE3766@vacation.karoshi.com.> <5FA6B45C-53E3-4FA3-B40D-9A55CB3B830A@rfc1035.com> <22D8C6B5-BEEB-4073-A9C5-62F07BC40B47@sackheads.org> <43C3953C-5077-4A14-9275-C189C08F8A35@rfc1035.com> <2B7ACBED-B7DA-4A0D-9520-8ED0A135DFF8@sackheads.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B7ACBED-B7DA-4A0D-9520-8ED0A135DFF8@sackheads.org> User-Agent: Mutt/1.4.1i 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, Apr 15, 2010 at 09:15:10AM -0400, John Payne wrote: > > On Apr 15, 2010, at 8:53 AM, Jim Reid wrote: > > > On 15 Apr 2010, at 13:48, John Payne wrote: > > > >> You're not relying on the train's network to do anything with DNS tricks. You're relying on the train to have decent Internet connectivity which it sounds like for some use cases, it doesn't. > > > > You still don't seem to understand. So let me spell it out. Once this WG legislates for stupid DNS tricks, the train's network will use them. This will not improve my browsing experience. It won't help me improve it because I will be unable to know what stupid DNS tricks I can configure (ie stub resolver hooks) will work for the network I'm using. > > As far as the edns-client-subnet option is concerned, if your train's resolver is "close" to you, then it has no incentive to enable it. If it does, the people that care about such things have no incentive to listen to it. In the worst possible case, it doesn't help you, no. But it also doesn't hurt you. > > As far as Paul's proposal is concerned, as far as I can make out, it isn't at all useful and is only designed to try and kill the edns-client-subnet option. may I? RTT is a good first metric to select between IMRs - but topologiclly close is not the only reason for IMR selection. As has been pointed out many times, the closest IMR might be tainted with "helpful" information, like rewriting all of my queries or providing a single answer, regardless of the question asked, or... other "helpful" responses used to monitize my use of the service. So RTT can only be one of the metrics used in IMR selection by a stub. My second metric is (currently) SIG(0)/TSIG matching. Yes, this is a problem for IMRs with (tens, hundreds of) thousands of stubs... But I reject that design and all its works (when I can)... I will go to a trusted IMR with at most 100 stubs, over an untrusted one most of the time. Anything else and then we start to seriously blur the distinction between a Stub and an IMR... which is fine by me... :) --bill From owner-namedroppers@ops.ietf.org Mon Apr 19 16:57:32 2010 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 C63913A6874; Mon, 19 Apr 2010 16:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.427 X-Spam-Level: * X-Spam-Status: No, score=1.427 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 v-N3Bq+8wNPf; Mon, 19 Apr 2010 16:57:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A6773A67F7; Mon, 19 Apr 2010 16:57:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O40lp-0007Dt-SN for namedroppers-data0@psg.com; Mon, 19 Apr 2010 23:52:53 +0000 Received: from [74.125.83.52] (helo=mail-gw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O40ln-0007Dd-Ld for namedroppers@ops.ietf.org; Mon, 19 Apr 2010 23:52:51 +0000 Received: by gwaa20 with SMTP id a20so1964782gwa.11 for ; Mon, 19 Apr 2010 16:52:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.214.209 with HTTP; Mon, 19 Apr 2010 16:52:50 -0700 (PDT) In-Reply-To: <4BCCCD01.6090602@mail-abuse.org> References: <30238.1271463251@nsa.vix.com> <35319.1271482136@nsa.vix.com> <20100419180347.GC4262@vacation.karoshi.com.> <4BCCCD01.6090602@mail-abuse.org> Date: Mon, 19 Apr 2010 16:52:50 -0700 Received: by 10.101.181.21 with SMTP id i21mr4293084anp.106.1271721170284; Mon, 19 Apr 2010 16:52:50 -0700 (PDT) Message-ID: Subject: Re: [dnsext] the protocol registry assignment dilemma From: Matthew Dempsky To: IETF DNSEXT WG 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, Apr 19, 2010 at 2:37 PM, Douglas Otis wrote: > If there had been code points defined as private, the IETF may have had an > opportunity to subsequently ensure adoption of separate non-private code > points for records having different semantics. Well, there's already a reserved range of code points for private RR types. I think the reasoning for going with TXT records was a matter of tools support for provisioning new resource records. Most web interfaces that I've used support the standard types (e.g., always A, NS, MX, CNAME, maybe AAAA, TXT, SRV), but I've never seen a web interface with support for entering the equivalent of generic TYPEnn records. However, this is somewhat off topic. The motivating issue at hand was simply that EDNS0 Option Codes have no reserved range of values for private use (unlike DNS classes, RR types, and even RCODEs, which each have private use ranges). From dmin@ietf.org Mon Apr 19 20:31:40 2010 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 3EB8A28C121 for ; Mon, 19 Apr 2010 20:31:40 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Mon, 19 Apr 2010 20:31:37 -0700 (PDT) Received: from agence-plage.com (unknown [190.40.204.234]) by core3.amsl.com (Postfix) with SMTP id 879EC28C0E8 for ; Mon, 19 Apr 2010 20:22:54 -0700 (PDT) From: Approved VIAGRA® Store Subject: Important notice: Google Apps browser support To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100420032256.879EC28C0E8@core3.amsl.com> Date: Mon, 19 Apr 2010 20:22:54 -0700 (PDT)
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 48288 Inc. All rights reserved.

From dmanet@ietf.org Tue Apr 20 02:59:05 2010 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 1EF0C28C1E4 for ; Tue, 20 Apr 2010 02:59:05 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 20 Apr 2010 02:58:58 -0700 (PDT) Received: from accredhome.com (unknown [202.45.147.126]) by core3.amsl.com (Postfix) with SMTP id 6202328C1E3 for ; Tue, 20 Apr 2010 02:41:51 -0700 (PDT) From: Approved VIAGRA® Store Subject: You have a new personal message To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=neXtPaRt_1271755406" Message-Id: <20100420094215.6202328C1E3@core3.amsl.com> Date: Tue, 20 Apr 2010 02:41:51 -0700 (PDT) ------=neXtPaRt_1271755406 Content-Type: text/html
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 39902 Inc. All rights reserved.

------=neXtPaRt_1271755406 Content-Type: text/plain; This e-mail, including attachments, constitutes non-public information intended to be conveyed only to the designated recipient(s). If you are not an intended recipient, please delete this e-mail, including attachments, and notify me. The unauthorized use, dissemination,distribution or reproduction of this e-mail, including attachments, is prohibited and may be unlawful ------=neXtPaRt_1271755406-- From dnsext-archive@ietf.org Tue Apr 20 06:31:02 2010 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 1DAED3A6A4B for ; Tue, 20 Apr 2010 06:31:02 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -74.149 X-Spam-Level: X-Spam-Status: No, score=-74.149 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_DE=0.35, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, TVD_SPACE_RATIO=2.219, 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 fP+RJPlkOJik for ; Tue, 20 Apr 2010 06:31:01 -0700 (PDT) Received: from 95-91-239-222-dynip.superkabel.de (95-91-239-222-dynip.superkabel.de [95.91.239.222]) by core3.amsl.com (Postfix) with SMTP id 394893A69BD for ; Tue, 20 Apr 2010 06:30:59 -0700 (PDT) From: VIAGRA Official Seller To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org April 67% off Mime-Version: 1.0 Content-type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100420133100.394893A69BD@core3.amsl.com> Date: Tue, 20 Apr 2010 06:30:59 -0700 (PDT) From owner-namedroppers@ops.ietf.org Tue Apr 20 11:52:00 2010 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 4C86F3A6876; Tue, 20 Apr 2010 11:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_05=-1.11, 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 PbpM-GaDlT2Y; Tue, 20 Apr 2010 11:51:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F8103A6783; Tue, 20 Apr 2010 11:51:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4IUT-000H85-P1 for namedroppers-data0@psg.com; Tue, 20 Apr 2010 18:48:09 +0000 Received: from [129.6.18.19] (helo=WSXGHUB2.xchange.nist.gov) by psg.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4IUR-000H3C-9F for namedroppers@ops.ietf.org; Tue, 20 Apr 2010 18:48:07 +0000 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 20 Apr 2010 14:47:51 -0400 From: "Rose, Scott W." To: namedroppers Date: Tue, 20 Apr 2010 14:48:04 -0400 Subject: [dnsext] dname-bis-19 posted Thread-Topic: dname-bis-19 posted Thread-Index: AcrgugJDK1wsav/K4EefDbevW6ChtA== 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 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 version of dname-bis has been posted. Changes: 1. basic "keep-alive" update 2. changed examples to have correct DO bit representation 3. text to cover corner cases (i.e. when QTYPE =3D ANY, etc.) based on comments originally from Ed Lewis. Not all comments were included. 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 Apr 20 12:02:58 2010 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 5E4413A6B98; Tue, 20 Apr 2010 12:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.99 X-Spam-Level: * X-Spam-Status: No, score=1.99 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 fi7FkhHs+jGj; Tue, 20 Apr 2010 12:02:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B3CB828C155; Tue, 20 Apr 2010 12:02:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4IfQ-000JnJ-Mz for namedroppers-data0@psg.com; Tue, 20 Apr 2010 18:59:28 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4IfO-000Jmi-23 for namedroppers@ops.ietf.org; Tue, 20 Apr 2010 18:59:26 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3KIxGI2012706; Tue, 20 Apr 2010 14:59:17 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Tue, 20 Apr 2010 14:59:23 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 20 Apr 2010 14:59:23 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <7AB16A29015644F48753C982367B5F0E@local> References: <7AB16A29015644F48753C982367B5F0E@local> Date: Tue, 20 Apr 2010 14:59:08 -0400 To: "George Barwood" From: Edward Lewis Subject: Re: [dnsext] RFC 4035 section 3.1.6 - security hole? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 19:15 +0100 4/20/10, George Barwood wrote: >Why this odd exception? It's certainly not hard. 1. The goal is to protect the data from the signer to the validator. A server acting in an authoritative role (= setting the AD bit) doesn't need to care. 2. Validating what could be millions of signatures when loading a zone from disk takes a while. 3. As far as zone transfers, use of TSIG or VPN or secure file transfers are a lot more efficient than individual verifications. I'd encourage you to look at this page: http://www.ops.ietf.org/lists/namedroppers/namedroppers.2001/threads.html and pull up all of the messages with this in the subject line: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt There are 80 of them. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From owner-namedroppers@ops.ietf.org Tue Apr 20 12:03:18 2010 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 D619D3A67E5; Tue, 20 Apr 2010 12:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.18 X-Spam-Level: X-Spam-Status: No, score=-102.18 tagged_above=-999 required=5 tests=[AWL=0.420, 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 klEh85DWATzs; Tue, 20 Apr 2010 12:03:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 98ABE28C1AC; Tue, 20 Apr 2010 12:03:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4Ifs-000Jqy-Cb for namedroppers-data0@psg.com; Tue, 20 Apr 2010 18:59:56 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4Ifq-000JqO-3Q for namedroppers@ops.ietf.org; Tue, 20 Apr 2010 18:59:54 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id D582C3A6B91; Tue, 20 Apr 2010 12: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-rfc2672bis-dname-19.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100420190001.D582C3A6B91@core3.amsl.com> Date: Tue, 20 Apr 2010 12: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 : Update to DNAME Redirection in the DNS Author(s) : S. Rose, W. Wijngaards Filename : draft-ietf-dnsext-rfc2672bis-dname-19.txt Pages : 18 Date : 2010-04-20 The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-19.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-rfc2672bis-dname-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-20114823.I-D@ietf.org> --NextPart-- From swelteringhh30@ehhenry.com Tue Apr 20 13:20:41 2010 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 991A328C200; Tue, 20 Apr 2010 13:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.906 X-Spam-Level: X-Spam-Status: No, score=-23.906 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_REPLICA_ROLEX=3.157, FH_FAKE_RCVD_LINE_B=5.777, GB_ROLEX=5, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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_XBL=3.033, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=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 abHz7T2DCwSZ; Tue, 20 Apr 2010 13:20:37 -0700 (PDT) Received: from mail.giantimpressions.com (mail.giantimpressions.com [67.152.81.75]) by core3.amsl.com (Postfix) with ESMTP id 45E2828C1B6; Tue, 20 Apr 2010 13:19:56 -0700 (PDT) Received: from 67.152.81.75 by mail2.mywebcompany.com; Tue, 20 Apr 2010 13:19:47 -0800 Message-ID: <000d01cae0c6$d2988dc0$6400a8c0@swelteringhh30> From: dnsext-archive@ietf.org To: Subject: Impress your colleagues with bling-bling Date: Tue, 20 Apr 2010 13:19:47 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAE0C6.D2988DC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2800.1158 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAE0C6.D2988DC0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Swiss Replica & Co. is offering all Rolex Watches Replica and also the Brei= tling Replica Watches.Our approach is to match the practices of the origina= l watchmaker to the closest degree of replica rolex and breitling, ensuring= the end result is virtually indistinguishable. Designer replica watches ar= e a craft that we take seriously and take pride in. Quality is essential bo= th for Rolex and Breitling.Replica watches are the best solution if you can= not afford to purchase so expensive original Rolex and Breitling watches.Ou= r online shop can offer you wonderful replica watches collections.Visit UsP= rice: $229Price: $244Price: $249Price: $399Price: $229Price: $244Price: $24= 9Price: $389Swiss Replica & Co. is about honesty and integrity; a straightf= orward approach to replica watch sales. As a partnership in this business w= e made it our very first priority to establish fair, transparent business p= ractices for our clientele. We=92d each been involved in various online mer= chant initiatives previously and knew the traps some online businesses fall= into=2E ------=_NextPart_000_0007_01CAE0C6.D2988DC0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Swiss Replica= & Co. is offering all Rolex Watches Replica and also the Breitling Replica= Watches.

Our approach is to match the practices of the ori= ginal watchmaker to the closest degree of replica rolex and breitling, ensu= ring the end result is virtually indistinguishable. Designer replica watche= s are a craft that we take seriously and take pride in. Quality is essentia= l both for Rolex and Breitling.

Replica watches are the best= solution if you cannot afford to purchase so expensive original Rolex and = Breitling watches.

Our online shop can offer you wonderful= replica watches collections.

Visit Us

3D""<= /a>

Price: $249

<= td bgcolor=3D"#000000" width=3D"158px" valign=3D"top" align=3D"center" back= ground=3D"http://wf0534.gubajoven.cn/swwatbg.png">3D""<= /a>

Price: $229

3D""

Price: $229

3D""

Price: $244

3D""

Price: $399

3D""

Price: $244

3D""

Price: $249

= 3D""

Price: $389

Swiss= Replica & Co. is about honesty and integrity; a straightforward approach t= o replica watch sales. As a partnership in this business we made it our ver= y first priority to establish fair, transparent business practices for our = clientele. We=92d each been involved in various online merchant initiatives= previously and knew the traps some online businesses fall into.

------=_NextPart_000_0007_01CAE0C6.D2988DC0-- From dnsop-bounces@ietf.org Tue Apr 20 13:20:44 2010 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19FF03A6AFB for ; Tue, 20 Apr 2010 13:20:44 -0700 (PDT) Subject: The results of your email commands From: dnsop-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1257731800==" Message-ID: Date: Tue, 20 Apr 2010 13:20:42 -0700 Precedence: bulk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF DNSOP WG mailing list X-List-Administrivia: yes Sender: dnsop-bounces@ietf.org Errors-To: dnsop-bounces@ietf.org --===============1257731800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Unprocessed: tling Replica Watches.Our approach is to match the practices of the origina= l watchmaker to the closest degree of replica rolex and breitling, ensuring= the end result is virtually indistinguishable. Designer replica watches ar= e a craft that we take seriously and take pride in. Quality is essential bo= th for Rolex and Breitling.Replica watches are the best solution if you can= not afford to purchase so expensive original Rolex and Breitling watches.Ou= r online shop can offer you wonderful replica watches collections.Visit UsP= rice: $229Price: $244Price: $249Price: $399Price: $229Price: $244Price: $24= 9Price: $389Swiss Replica & Co. is about honesty and integrity; a straightf= orward approach to replica watch sales. As a partnership in this business w= e made it our very first priority to establish fair, transparent business p= ractices for our clientele. We=92d each been involved in various online mer= chant initiatives previously and knew the traps some online businesses fall= into=2E - Done. --===============1257731800== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: dnsop-request@core3.amsl.com Delivered-To: dnsop-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991A328C200; Tue, 20 Apr 2010 13:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.906 X-Spam-Level: X-Spam-Status: No, score=-23.906 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_REPLICA_ROLEX=3.157, FH_FAKE_RCVD_LINE_B=5.777, GB_ROLEX=5, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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_XBL=3.033, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=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 abHz7T2DCwSZ; Tue, 20 Apr 2010 13:20:37 -0700 (PDT) Received: from mail.giantimpressions.com (mail.giantimpressions.com [67.152.81.75]) by core3.amsl.com (Postfix) with ESMTP id 45E2828C1B6; Tue, 20 Apr 2010 13:19:56 -0700 (PDT) Received: from 67.152.81.75 by mail2.mywebcompany.com; Tue, 20 Apr 2010 13:19:47 -0800 Message-ID: <000d01cae0c6$d2988dc0$6400a8c0@swelteringhh30> From: dnsext-archive@ietf.org To: Subject: Impress your colleagues with bling-bling Date: Tue, 20 Apr 2010 13:19:47 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAE0C6.D2988DC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2800.1158 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAE0C6.D2988DC0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Swiss Replica & Co. is offering all Rolex Watches Replica and also the Brei= tling Replica Watches.Our approach is to match the practices of the origina= l watchmaker to the closest degree of replica rolex and breitling, ensuring= the end result is virtually indistinguishable. Designer replica watches ar= e a craft that we take seriously and take pride in. Quality is essential bo= th for Rolex and Breitling.Replica watches are the best solution if you can= not afford to purchase so expensive original Rolex and Breitling watches.Ou= r online shop can offer you wonderful replica watches collections.Visit UsP= rice: $229Price: $244Price: $249Price: $399Price: $229Price: $244Price: $24= 9Price: $389Swiss Replica & Co. is about honesty and integrity; a straightf= orward approach to replica watch sales. As a partnership in this business w= e made it our very first priority to establish fair, transparent business p= ractices for our clientele. We=92d each been involved in various online mer= chant initiatives previously and knew the traps some online businesses fall= into=2E ------=_NextPart_000_0007_01CAE0C6.D2988DC0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Swiss Replica= & Co. is offering all Rolex Watches Replica and also the Breitling Replica= Watches.

Our approach is to match the practices of the ori= ginal watchmaker to the closest degree of replica rolex and breitling, ensu= ring the end result is virtually indistinguishable. Designer replica watche= s are a craft that we take seriously and take pride in. Quality is essentia= l both for Rolex and Breitling.

Replica watches are the best= solution if you cannot afford to purchase so expensive original Rolex and = Breitling watches.

Our online shop can offer you wonderful= replica watches collections.

Visit Us

3D""<= /a>

Price: $249

<= td bgcolor=3D"#000000" width=3D"158px" valign=3D"top" align=3D"center" back= ground=3D"http://wf0534.gubajoven.cn/swwatbg.png">3D""<= /a>

Price: $229

3D""

Price: $229

3D""

Price: $244

3D""

Price: $399

3D""

Price: $244

3D""

Price: $249

= 3D""

Price: $389

Swiss= Replica & Co. is about honesty and integrity; a straightforward approach t= o replica watch sales. As a partnership in this business we made it our ver= y first priority to establish fair, transparent business practices for our = clientele. We=92d each been involved in various online merchant initiatives= previously and knew the traps some online businesses fall into.

------=_NextPart_000_0007_01CAE0C6.D2988DC0-- --===============1257731800==-- From abalone3@caelestium.com Tue Apr 20 13:20:47 2010 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 907763A6AFB for ; Tue, 20 Apr 2010 13:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.411 X-Spam-Level: X-Spam-Status: No, score=-22.411 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_DSN=1.495, FB_REPLICA_ROLEX=3.157, FH_FAKE_RCVD_LINE_B=5.777, GB_ROLEX=5, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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_XBL=3.033, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=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 HbYlVksTvZgz for ; Tue, 20 Apr 2010 13:20:44 -0700 (PDT) Received: from mail.giantimpressions.com (mail.giantimpressions.com [67.152.81.75]) by core3.amsl.com (Postfix) with ESMTP id B2FFB28C1F9 for ; Tue, 20 Apr 2010 13:20:18 -0700 (PDT) Received: from 67.152.81.75 by mail.caelestium.com; Tue, 20 Apr 2010 13:19:56 -0800 Message-ID: <000d01cae0c6$d7db9980$6400a8c0@abalone3> From: dnsext-archive@lists.ietf.org To: Subject: Look like a movie star Date: Tue, 20 Apr 2010 13:19:56 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAE0C6.D7DB9980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE 6.00.2800.1807 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAE0C6.D7DB9980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Swiss Replica & Co. is offering all Rolex Watches Replica and also the Brei= tling Replica Watches.Our approach is to match the practices of the origina= l watchmaker to the closest degree of replica rolex and breitling, ensuring= the end result is virtually indistinguishable. Designer replica watches ar= e a craft that we take seriously and take pride in. Quality is essential bo= th for Rolex and Breitling.Replica watches are the best solution if you can= not afford to purchase so expensive original Rolex and Breitling watches.Ou= r online shop can offer you wonderful replica watches collections.More Info= rmationPrice: $229Price: $244Price: $249Price: $399Price: $229Price: $244Pr= ice: $249Price: $389Swiss Replica & Co. is about honesty and integrity; a s= traightforward approach to replica watch sales. As a partnership in this bu= siness we made it our very first priority to establish fair, transparent bu= siness practices for our clientele. We=92d each been involved in various on= line merchant initiatives previously and knew the traps some online busines= ses fall into=2E ------=_NextPart_000_0007_01CAE0C6.D7DB9980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <= td>

Swiss Replica & = Co. is offering all Rolex Watches Replica and also the Breitling Replica Wa= tches.

Our approach is to match the practices of the origin= al watchmaker to the closest degree of replica rolex and breitling, ensurin= g the end result is virtually indistinguishable. Designer replica watches a= re a craft that we take seriously and take pride in. Quality is essential b= oth for Rolex and Breitling.

Replica watches are the best so= lution if you cannot afford to purchase so expensive original Rolex and Bre= itling watches.

Our online shop can offer you wonderful re= plica watches collections.

More Information

3D""

Price: $229

3D""

Price: $2= 44

3D""

Price: $249

3D""

Price: $399

3D""

Price: $229

3D""

Price: $244

3D""<= /a>

Price: $249

3D""

Price: $389

<= /td>

Swiss Replica & Co. is about honesty and integrity; a straightforward appr= oach to replica watch sales. As a partnership in this business we made it o= ur very first priority to establish fair, transparent business practices fo= r our clientele. We=92d each been involved in various online merchant initi= atives previously and knew the traps some online businesses fall into.

<= /td>= ------=_NextPart_000_0007_01CAE0C6.D7DB9980-- From wainscotingg0@mediastom.ru Tue Apr 20 14:29:01 2010 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 9D03728C216; Tue, 20 Apr 2010 14:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.4 X-Spam-Level: X-Spam-Status: No, score=-12.4 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FB_REPLICA_ROLEX=3.157, GB_ROLEX=5, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, URIBL_AB_SURBL=10, 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 Fsx0PZ466TBN; Tue, 20 Apr 2010 14:29:00 -0700 (PDT) Received: from chello089076109238.chello.pl (chello089076109238.chello.pl [89.76.109.238]) by core3.amsl.com (Postfix) with ESMTP id B64863A6881; Tue, 20 Apr 2010 14:27:36 -0700 (PDT) Message-ID: <000d01cae0d0$1f66a340$6400a8c0@wainscotingg0> From: To: Subject: your sparkling new timepiece. Date: Tue, 20 Apr 2010 23:26:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAE0D0.1F66A340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAE0D0.1F66A340 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Swiss Replica & Co. is offering all Rolex Watches Replica and also the Brei= tling Replica Watches.Our approach is to match the practices of the origina= l watchmaker to the closest degree of replica rolex and breitling, ensuring= the end result is virtually indistinguishable. Designer replica watches ar= e a craft that we take seriously and take pride in. Quality is essential bo= th for Rolex and Breitling.Replica watches are the best solution if you can= not afford to purchase so expensive original Rolex and Breitling watches.Ou= r online shop can offer you wonderful replica watches collections.More Info= rmationPrice: $229Price: $244Price: $249Price: $399Price: $229Price: $244Pr= ice: $249Price: $389Swiss Replica & Co. is about honesty and integrity; a s= traightforward approach to replica watch sales. As a partnership in this bu= siness we made it our very first priority to establish fair, transparent bu= siness practices for our clientele. We=92d each been involved in various on= line merchant initiatives previously and knew the traps some online busines= ses fall into=2E ------=_NextPart_000_0007_01CAE0D0.1F66A340 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <= tr>

Swiss Replica & = Co. is offering all Rolex Watches Replica and also the Breitling Replica Wa= tches.

Our approach is to match the practices of the origin= al watchmaker to the closest degree of replica rolex and breitling, ensurin= g the end result is virtually indistinguishable. Designer replica watches a= re a craft that we take seriously and take pride in. Quality is essential b= oth for Rolex and Breitling.

Replica watches are the best so= lution if you cannot afford to purchase so expensive original Rolex and Bre= itling watches.

Our online shop can offer you wonderful re= plica watches collections.

More Information

3D""

Price: $249

3D""

Price: $229

3D""

Price: $2= 44

3D""

Price: $249

3D""

Price: $399

<= /td>
3D""

Price: $229

3D""

Price: $244

3D""

Price: $389

<= /td>

= Swiss Replica & Co. is about honesty and integrity; a straightforward appro= ach to replica watch sales. As a partnership in this business we made it ou= r very first priority to establish fair, transparent business practices for= our clientele. We=92d each been involved in various online merchant initia= tives previously and knew the traps some online businesses fall into.

------=_NextPart_000_0007_01CAE0D0.1F66A340-- From guatemalanso16@fincor.ru Tue Apr 20 14:33:36 2010 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 2BB283A68D9; Tue, 20 Apr 2010 14:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FB_REPLICA_ROLEX=3.157, FH_HELO_ALMOST_IP=5.417, FH_HOST_ALMOST_IP=1.889, GB_ROLEX=5, HELO_DYNAMIC_SPLIT_IP=3.493, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, URIBL_AB_SURBL=10, 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 2Ewy99v9Kwxt; Tue, 20 Apr 2010 14:33:35 -0700 (PDT) Received: from 231.Red-213-96-206.staticIP.rima-tde.net (231.Red-213-96-206.staticIP.rima-tde.net [213.96.206.231]) by core3.amsl.com (Postfix) with ESMTP id 42A933A6893; Tue, 20 Apr 2010 14:33:26 -0700 (PDT) Message-ID: <000d01cae0ce$b93ba8a0$6400a8c0@guatemalanso16> From: To: Subject: The definitive mark of your arrival. Date: Tue, 20 Apr 2010 23:16:20 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAE0CE.B93BA8A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAE0CE.B93BA8A0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Swiss Replica & Co. is offering all Rolex Watches Replica and also the Brei= tling Replica Watches.Our approach is to match the practices of the origina= l watchmaker to the closest degree of replica rolex and breitling, ensuring= the end result is virtually indistinguishable. Designer replica watches ar= e a craft that we take seriously and take pride in. Quality is essential bo= th for Rolex and Breitling.Replica watches are the best solution if you can= not afford to purchase so expensive original Rolex and Breitling watches.Ou= r online shop can offer you wonderful replica watches collections.Visit UsP= rice: $229Price: $244Price: $249Price: $399Price: $229Price: $244Price: $24= 9Price: $389Swiss Replica & Co. is about honesty and integrity; a straightf= orward approach to replica watch sales. As a partnership in this business w= e made it our very first priority to establish fair, transparent business p= ractices for our clientele. We=92d each been involved in various online mer= chant initiatives previously and knew the traps some online businesses fall= into=2E ------=_NextPart_000_0007_01CAE0CE.B93BA8A0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
=

Swiss Replica= & Co. is offering all Rolex Watches Replica and also the Breitling Replica= Watches.

Our approach is to match the practices of the ori= ginal watchmaker to the closest degree of replica rolex and breitling, ensu= ring the end result is virtually indistinguishable. Designer replica watche= s are a craft that we take seriously and take pride in. Quality is essentia= l both for Rolex and Breitling.

Replica watches are the best= solution if you cannot afford to purchase so expensive original Rolex and = Breitling watches.

Our online shop can offer you wonderful= replica watches collections.

Visit Us

3D""

Price: $229

3D""

Price: $244

3D""

Price: $249

3D""

Price: $399

3D""

Price: $229

3D""

Price: $244

3D""

Price: $389

Swiss Replica & Co. is about honesty and integrity; a straightforward appr= oach to replica watch sales. As a partnership in this business we made it o= ur very first priority to establish fair, transparent business practices fo= r our clientele. We=92d each been involved in various online merchant initi= atives previously and knew the traps some online businesses fall into.

<= /td>
------=_NextPart_000_0007_01CAE0CE.B93BA8A0-- From sinningy92@idea2.ru Tue Apr 20 14:34:01 2010 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 480F13A6977 for ; Tue, 20 Apr 2010 14:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FB_REPLICA_ROLEX=3.157, FH_HELO_ALMOST_IP=5.417, FH_HOST_ALMOST_IP=1.889, GB_ROLEX=5, HELO_DYNAMIC_SPLIT_IP=3.493, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, URIBL_AB_SURBL=10, 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 ejhjcNNT-Gb6 for ; Tue, 20 Apr 2010 14:34:00 -0700 (PDT) Received: from 231.Red-213-96-206.staticIP.rima-tde.net (231.Red-213-96-206.staticIP.rima-tde.net [213.96.206.231]) by core3.amsl.com (Postfix) with ESMTP id 52B063A6893 for ; Tue, 20 Apr 2010 14:33:59 -0700 (PDT) Message-ID: <000d01cae0d1$1afaa120$6400a8c0@sinningy92> From: To: Subject: worlds largest online store for branded timepieces and jewelry Date: Tue, 20 Apr 2010 23:33:23 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CAE0D1.1AFAA120" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAE0D1.1AFAA120 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Swiss Replica & Co. is offering all Rolex Watches Replica and also the Brei= tling Replica Watches.Our approach is to match the practices of the origina= l watchmaker to the closest degree of replica rolex and breitling, ensuring= the end result is virtually indistinguishable. Designer replica watches ar= e a craft that we take seriously and take pride in. Quality is essential bo= th for Rolex and Breitling.Replica watches are the best solution if you can= not afford to purchase so expensive original Rolex and Breitling watches.Ou= r online shop can offer you wonderful replica watches collections.Visit UsP= rice: $229Price: $244Price: $249Price: $399Price: $229Price: $244Price: $24= 9Price: $389Swiss Replica & Co. is about honesty and integrity; a straightf= orward approach to replica watch sales. As a partnership in this business w= e made it our very first priority to establish fair, transparent business p= ractices for our clientele. We=92d each been involved in various online mer= chant initiatives previously and knew the traps some online businesses fall= into=2E ------=_NextPart_000_0007_01CAE0D1.1AFAA120 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable = ------=_NextPart_000_0007_01CAE0D1.1AFAA120-- From dmin@ietf.org Tue Apr 20 23:41:46 2010 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 7C8E73A6A7D for ; Tue, 20 Apr 2010 23:41:46 -0700 (PDT) X-Quarantine-ID: <7LdvXHcyijj1> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char C2 hex): From: Approved VIAGRA\302\256 Store ; Tue, 20 Apr 2010 23:41:45 -0700 (PDT) Received: from abs.co.il (unknown [122.173.192.16]) by core3.amsl.com (Postfix) with SMTP id A397D3A6C3D for ; Tue, 20 Apr 2010 23:39:36 -0700 (PDT) From: Approved VIAGRA® Store Subject: News on myspace To: MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100421063939.A397D3A6C3D@core3.amsl.com> Date: Tue, 20 Apr 2010 23:39:36 -0700 (PDT)

Swiss Replica & Co.= is offering all Rolex Watches Replica and also the Breitling Replica Watch= es.

Our approach is to match the practices of the original = watchmaker to the closest degree of replica rolex and breitling, ensuring t= he end result is virtually indistinguishable. Designer replica watches are = a craft that we take seriously and take pride in. Quality is essential both= for Rolex and Breitling.

Replica watches are the best solut= ion if you cannot afford to purchase so expensive original Rolex and Breitl= ing watches.

Our online shop can offer you wonderful repli= ca watches collections.

Visit Us

<= tr>
3D""

Price: $229

3D""

Price: $244

3D""

Price: $249

3D""

Price: $399

3D""

Price: $229

3D""

Price: $244

3D""Price: $249

3D""

Price: $389

<= /td>

Swiss Replica & Co. is about honesty and integrity; a straightforward appr= oach to replica watch sales. As a partnership in this business we made it o= ur very first priority to establish fair, transparent business practices fo= r our clientele. We=92d each been involved in various online merchant initi= atives previously and knew the traps some online businesses fall into.

<= /td>
Trouble viewing this mail? Read it online

No graphics displayed? Click here
 

The e-mail address is dnsext-archive@ietf.org
Unsubscribe from this e-mail | FAQ | Advertise | Privacy Policy

Copyright 24222 Inc. All rights reserved.

From owner-namedroppers@ops.ietf.org Wed Apr 21 02:15:52 2010 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 3F61528C148; Wed, 21 Apr 2010 02:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_55=0.6, J_CHICKENPOX_61=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 pSY16POM-vvD; Wed, 21 Apr 2010 02:15:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 169B028C0F6; Wed, 21 Apr 2010 02:15:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4Vvj-000H40-Dg for namedroppers-data0@psg.com; Wed, 21 Apr 2010 09:09:11 +0000 Received: from [139.91.1.2] (helo=mailgate.ics.forth.gr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4Vvg-000H3I-1Q for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 09:09:08 +0000 X-DNSBL-MILTER: Passed Received: from webmail.ics.forth.gr (sphinx.ics.forth.gr [139.91.1.4]) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id o3L995j1008550; Wed, 21 Apr 2010 12:09:05 +0300 (EEST) Received: from Thanatos ([139.91.88.160]) (authenticated bits=0) by webmail.ics.forth.gr (8.12.9//ICS-FORTH/V10.1.0C-EXTNULL-PLUS-SASL) with ESMTP id o3L98tqt003273; Wed, 21 Apr 2010 12:09:00 +0300 (EEST) From: "Vaggelis Segredakis" To: "'Niall O'Reilly'" , "'Andrew Sullivan'" Cc: , "'Sotiris Panaretou'" References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> Subject: RE: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Date: Wed, 21 Apr 2010 12:08:45 +0300 Message-ID: <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcrZxU5dvSp42myyQSWJBjgmX1M73QHacgWA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <4BC24639.7000202@ucd.ie> X-j-chkmail-Score: MSGID : 4BCEC0B1.000 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-ICS-JCHK-SCL: Ham 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 Niall, Dear Andrew, Dear DNSEXT members, I am sorry I have not been able to answer this email sooner. I noticed by reading this that the xNAME discussion has taken a slippery road to oblivion but for the wrong reasons. I am happy our request for xNAME has found some allies due to the ICANN request but in reality we are talking about issues that are close but not the same. I am pretty sure nobody will ever wish to set up an email account of the type mail@tld1 and wish to make it operative for mail@tld2. If you do not face such a problem then why not using the DNAME for this equality issue? However, this is not the case if you discuss domain names under a TLD. If there where two ways to spell shinkuro.com, both of them correct, would Andrew wish to receive all of his emails correctly? I believe he would. In this case you have to set up a mechanism that redirects all emails to the email he considers the correct one. This could happen by setting up the same email in each domain. What if this was the case for each email account of a company and you had four ways of typing the company domain name, each one of them correct, depending on character case or set? What if this was the case for the domain name itself in the http protocol? The user experience is significant if you wish the IDNs to move forward in each language. It would be a great benefit if this equality mechanism was set up in the DNS because it is really needed. It is the same need that created DNAME, which in reality is a sub-mechanism of our request. We would like DNAME to start right from the top, as it was discussed before(a mechanism that operates like DNAME+CNAME from the first level of equality and below that). Please do not consider this discussion over because ICANNs request for TLD equality could easily be bypassed by proposing DNAME as a solution. The DNAME option is not enough for our ccTLD needs. Kind Regards, Vaggelis Segredakis -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Niall O'Reilly Sent: Monday, April 12, 2010 12:59 AM To: Andrew Sullivan Cc: namedroppers@ops.ietf.org; Niall O'Reilly Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work On 09/04/10 15:51, Andrew Sullivan wrote: > Dear colleagues, > > I'm speaking only for myself, here, in trying to come to some > conclusions in light of the discussion we had in Anaheim about DNS > "name equivalences" and so on. Importantly, I want to convey that I > haven't discussed this with Olafur and that I have not reached any > conclusion. > > We have been investigating two things in parallel: > > 1. What the requirements would be for some kind of additional > aliasing mechanism for the DNS. > > 2. Whether there is any protocol work that DNSEXT should do in > support of (1). [...] > ICANN's plan might be understood to suggest that, even if there is a > problem here to be solved (and I guess there is, or ICANN wouldn't be > doing something about it), no protocol work is needed in order that it > could be addressed. Are others in agreement with that? Yes, but a subsequent message from Kim Davies clarifies this as intended to be an interim position. > If so, then > it would appear that the WG does not need to consider this topic any > more as a possible work item. This doesn't follow, because it's a general conclusion drawn from a particular case. ICANN is just one of the players on the DNS stage. > If you do not agree with that conclusion, it would be interesting to > me to hear why not, and what you think needs support in the protocol > that cannot be accommodated in ICANN's plan. I believe that ICANN's plan is only of marginal relevance to the questions mentioned at (1) and (2) above. At most, ICANN's plan may give rise to an additional opportunity to avail of any solution which may emerge for question (1). On the other hand, the question arises already in existing ccTLD operations, prior to, and independently of, the implementation of ICANN's plan. Possible use cases which would be served "by some kind of additional aliasing mechanism for the DNS" seem to me to be well covered in Paul Vixie's slide-set for the interim audio meeting held on 16 Feb 2010, and (very usefully) include an example which is not related to variant IDNA strings. Drafts (BNAME and SHADOW) are already available addressing these suggested use cases. It seems to me that it would be useful for a number of those with a material interest in the outcome to make clear statements on this list (as some have already done privately) in respect of the following questions: What their interest is; In what way existing aliasing (replication or indirection) mechanisms are (or appear to be) inadequate for them; What size of "equivalence cluster" they anticipate needing respectively for a single label and for an FQDN; Whether (with reasons) SHADOW appears a useful solution; Whether (with reasons) BNAME appears a useful solution. This should give a clear impression of what benefit, if any, might flow from any further work on this topic. So far, the discussion on this list of this topic seems to have been dominated by people either whose native language is English, or for whom the Latin alphabet is a close enough approximation to meeting their needs. Without meaning either to impugn anyone's acquired expertise or to play down the value of proxy advocacy, I suggest that two observations are pertinent: first, that such a group is likely not best qualified by experience to articulate the problem; secondly, that dominance by such a group may tend to marginalize those who are so qualified. If no-one speaks up, I'm inclined to agree with Andrew that "it would appear that the WG does not need to consider this topic any more as a possible work item", but not because of anything to do with ICANN's plan. I hope this helps. Niall O'Reilly From owner-namedroppers@ops.ietf.org Wed Apr 21 02:34:47 2010 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 7B00A3A689F; Wed, 21 Apr 2010 02:34:47 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 3.567 X-Spam-Level: *** X-Spam-Status: No, score=3.567 tagged_above=-999 required=5 tests=[AWL=-1.041, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, J_CHICKENPOX_55=0.6, J_CHICKENPOX_61=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 c+JEmvefVvJ4; Wed, 21 Apr 2010 02:34:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E222F3A6804; Wed, 21 Apr 2010 02:34:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4WGn-000LNb-Cz for namedroppers-data0@psg.com; Wed, 21 Apr 2010 09:30:57 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4WGh-000LMP-UT for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 09:30:53 +0000 Received: (eyou send program); Wed, 21 Apr 2010 17:30:48 +0800 Message-ID: <471842248.08286@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 21 Apr 2010 17:30:48 +0800 Message-ID: <891693F935914FC783CCC1306254B530@LENOVO47E041CF> From: "YAO Jiankang" To: "Vaggelis Segredakis" , "'Niall O'Reilly'" , "'Andrew Sullivan'" Cc: , "'Sotiris Panaretou'" References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Date: Wed, 21 Apr 2010 17:30:45 +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.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: KzENCg0KZXZlbiBpZiAgVExEIGRvZXMgbm90IHdhbnQgInhuYW1lIiwgIHRoZSAybmQgbGV2ZWwg ZG9tYWluIG5hbWUgd2lsbCB3YW50IGl0LCB0aGUgM3JkIGxldmVsIGFuZCBtb3JlIHdpbGwgbmVl ZCBpdC4NCiJ4bmFtZSIgaXMgYSBnZW5lcmFsIHNvbHV0aW9uIGZvciBhbGwgbGV2ZWxzJyBkb21h aW4gbmFtZXMuDQoNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlZh Z2dlbGlzIFNlZ3JlZGFraXMiIDxzZWdyZWRAaWNzLmZvcnRoLmdyPg0KVG86ICInTmlhbGwgTydS ZWlsbHknIiA8TmlhbGwub1JlaWxseUB1Y2QuaWU+OyAiJ0FuZHJldyBTdWxsaXZhbiciIDxhanNA c2hpbmt1cm8uY29tPg0KQ2M6IDxuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnPjsgIidTb3Rpcmlz IFBhbmFyZXRvdSciIDxzb3RpcmlzQHVjeS5hYy5jeT4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwg MjEsIDIwMTAgNTowOCBQTQ0KU3ViamVjdDogUkU6IFtkbnNleHRdIElDQU5OJ3MgInN5bmNocm9u aXplZCBkb21haW5zIiBhbmQgdGhlIEROU0VYVCBhbGlhcyBtYXliZS13b3JrDQoNCg0KPiBEZWFy IE5pYWxsLCBEZWFyIEFuZHJldywgRGVhciBETlNFWFQgbWVtYmVycywNCj4gDQo+IEkgYW0gc29y cnkgSSBoYXZlIG5vdCBiZWVuIGFibGUgdG8gYW5zd2VyIHRoaXMgZW1haWwgc29vbmVyLg0KPiAN Cj4gSSBub3RpY2VkIGJ5IHJlYWRpbmcgdGhpcyB0aGF0IHRoZSB4TkFNRSBkaXNjdXNzaW9uIGhh cyB0YWtlbiBhIHNsaXBwZXJ5DQo+IHJvYWQgdG8gb2JsaXZpb24gYnV0IGZvciB0aGUgd3Jvbmcg cmVhc29ucy4NCj4gDQo+IEkgYW0gaGFwcHkgb3VyIHJlcXVlc3QgZm9yIHhOQU1FIGhhcyBmb3Vu ZCBzb21lIGFsbGllcyBkdWUgdG8gdGhlIElDQU5ODQo+IHJlcXVlc3QgYnV0IGluIHJlYWxpdHkg d2UgYXJlIHRhbGtpbmcgYWJvdXQgaXNzdWVzIHRoYXQgYXJlIGNsb3NlIGJ1dCBub3QNCj4gdGhl IHNhbWUuIEkgYW0gcHJldHR5IHN1cmUgbm9ib2R5IHdpbGwgZXZlciB3aXNoIHRvIHNldCB1cCBh biBlbWFpbCBhY2NvdW50DQo+IG9mIHRoZSB0eXBlIG1haWxAdGxkMSBhbmQgd2lzaCB0byBtYWtl IGl0IG9wZXJhdGl2ZSBmb3IgbWFpbEB0bGQyLiBJZiB5b3UgZG8NCj4gbm90IGZhY2Ugc3VjaCBh IHByb2JsZW0gdGhlbiB3aHkgbm90IHVzaW5nIHRoZSBETkFNRSBmb3IgdGhpcyBlcXVhbGl0eQ0K PiBpc3N1ZT8NCj4gDQo+IEhvd2V2ZXIsIHRoaXMgaXMgbm90IHRoZSBjYXNlIGlmIHlvdSBkaXNj dXNzIGRvbWFpbiBuYW1lcyB1bmRlciBhIFRMRC4gSWYNCj4gdGhlcmUgd2hlcmUgdHdvIHdheXMg dG8gc3BlbGwgc2hpbmt1cm8uY29tLCBib3RoIG9mIHRoZW0gY29ycmVjdCwgd291bGQNCj4gQW5k cmV3IHdpc2ggdG8gcmVjZWl2ZSBhbGwgb2YgaGlzIGVtYWlscyBjb3JyZWN0bHk/IEkgYmVsaWV2 ZSBoZSB3b3VsZC4NCj4gDQo+IEluIHRoaXMgY2FzZSB5b3UgaGF2ZSB0byBzZXQgdXAgYSBtZWNo YW5pc20gdGhhdCByZWRpcmVjdHMgYWxsIGVtYWlscyB0byB0aGUNCj4gZW1haWwgaGUgY29uc2lk ZXJzIHRoZSBjb3JyZWN0IG9uZS4gVGhpcyBjb3VsZCBoYXBwZW4gYnkgc2V0dGluZyB1cCB0aGUg c2FtZQ0KPiBlbWFpbCBpbiBlYWNoIGRvbWFpbi4gV2hhdCBpZiB0aGlzIHdhcyB0aGUgY2FzZSBm b3IgZWFjaCBlbWFpbCBhY2NvdW50IG9mIGENCj4gY29tcGFueSBhbmQgeW91IGhhZCBmb3VyIHdh eXMgb2YgdHlwaW5nIHRoZSBjb21wYW55IGRvbWFpbiBuYW1lLCBlYWNoIG9uZSBvZg0KPiB0aGVt IGNvcnJlY3QsIGRlcGVuZGluZyBvbiBjaGFyYWN0ZXIgY2FzZSBvciBzZXQ/IFdoYXQgaWYgdGhp cyB3YXMgdGhlIGNhc2UNCj4gZm9yIHRoZSBkb21haW4gbmFtZSBpdHNlbGYgaW4gdGhlIGh0dHAg cHJvdG9jb2w/DQo+IA0KPiBUaGUgdXNlciBleHBlcmllbmNlIGlzIHNpZ25pZmljYW50IGlmIHlv dSB3aXNoIHRoZSBJRE5zIHRvIG1vdmUgZm9yd2FyZCBpbg0KPiBlYWNoIGxhbmd1YWdlLiBJdCB3 b3VsZCBiZSBhIGdyZWF0IGJlbmVmaXQgaWYgdGhpcyBlcXVhbGl0eSBtZWNoYW5pc20gd2FzDQo+ IHNldCB1cCBpbiB0aGUgRE5TIGJlY2F1c2UgaXQgaXMgcmVhbGx5IG5lZWRlZC4gSXQgaXMgdGhl IHNhbWUgbmVlZCB0aGF0DQo+IGNyZWF0ZWQgRE5BTUUsIHdoaWNoIGluIHJlYWxpdHkgaXMgYSBz dWItbWVjaGFuaXNtIG9mIG91ciByZXF1ZXN0LiBXZSB3b3VsZA0KPiBsaWtlIEROQU1FIHRvIHN0 YXJ0IHJpZ2h0IGZyb20gdGhlIHRvcCwgYXMgaXQgd2FzIGRpc2N1c3NlZCBiZWZvcmUoYQ0KPiBt ZWNoYW5pc20gdGhhdCBvcGVyYXRlcyBsaWtlIEROQU1FK0NOQU1FIGZyb20gdGhlIGZpcnN0IGxl dmVsIG9mIGVxdWFsaXR5DQo+IGFuZCBiZWxvdyB0aGF0KS4NCj4gDQo+IFBsZWFzZSBkbyBub3Qg Y29uc2lkZXIgdGhpcyBkaXNjdXNzaW9uIG92ZXIgYmVjYXVzZSBJQ0FOTnMgcmVxdWVzdCBmb3Ig VExEDQo+IGVxdWFsaXR5IGNvdWxkIGVhc2lseSBiZSBieXBhc3NlZCBieSBwcm9wb3NpbmcgRE5B TUUgYXMgYSBzb2x1dGlvbi4gVGhlDQo+IEROQU1FIG9wdGlvbiBpcyBub3QgZW5vdWdoIGZvciBv dXIgY2NUTEQgbmVlZHMuDQo+IA0KPiBLaW5kIFJlZ2FyZHMsDQo+IA0KPiBWYWdnZWxpcyBTZWdy ZWRha2lzDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvd25lci1u YW1lZHJvcHBlcnNAb3BzLmlldGYub3JnDQo+IFttYWlsdG86b3duZXItbmFtZWRyb3BwZXJzQG9w cy5pZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5pYWxsIE8nUmVpbGx5DQo+IFNlbnQ6IE1vbmRheSwg QXByaWwgMTIsIDIwMTAgMTI6NTkgQU0NCj4gVG86IEFuZHJldyBTdWxsaXZhbg0KPiBDYzogbmFt ZWRyb3BwZXJzQG9wcy5pZXRmLm9yZzsgTmlhbGwgTydSZWlsbHkNCj4gU3ViamVjdDogUmU6IFtk bnNleHRdIElDQU5OJ3MgInN5bmNocm9uaXplZCBkb21haW5zIiBhbmQgdGhlIEROU0VYVCBhbGlh cw0KPiBtYXliZS13b3JrDQo+IA0KPiBPbiAwOS8wNC8xMCAxNTo1MSwgQW5kcmV3IFN1bGxpdmFu IHdyb3RlOg0KPj4gRGVhciBjb2xsZWFndWVzLA0KPj4gDQo+PiBJJ20gc3BlYWtpbmcgb25seSBm b3IgbXlzZWxmLCBoZXJlLCBpbiB0cnlpbmcgdG8gY29tZSB0byBzb21lDQo+PiBjb25jbHVzaW9u cyBpbiBsaWdodCBvZiB0aGUgZGlzY3Vzc2lvbiB3ZSBoYWQgaW4gQW5haGVpbSBhYm91dCBETlMN Cj4+ICJuYW1lIGVxdWl2YWxlbmNlcyIgYW5kIHNvIG9uLiAgSW1wb3J0YW50bHksIEkgd2FudCB0 byBjb252ZXkgdGhhdCBJDQo+PiBoYXZlbid0IGRpc2N1c3NlZCB0aGlzIHdpdGggT2xhZnVyIGFu ZCB0aGF0IEkgaGF2ZSBub3QgcmVhY2hlZCBhbnkNCj4+IGNvbmNsdXNpb24uDQo+PiANCj4+IFdl IGhhdmUgYmVlbiBpbnZlc3RpZ2F0aW5nIHR3byB0aGluZ3MgaW4gcGFyYWxsZWw6DQo+PiANCj4+ ICAgICAxLiAgV2hhdCB0aGUgcmVxdWlyZW1lbnRzIHdvdWxkIGJlIGZvciBzb21lIGtpbmQgb2Yg YWRkaXRpb25hbA0KPj4gICAgIGFsaWFzaW5nIG1lY2hhbmlzbSBmb3IgdGhlIEROUy4NCj4+IA0K Pj4gICAgIDIuICBXaGV0aGVyIHRoZXJlIGlzIGFueSBwcm90b2NvbCB3b3JrIHRoYXQgRE5TRVhU IHNob3VsZCBkbyBpbg0KPj4gICAgIHN1cHBvcnQgb2YgKDEpLg0KPiANCj4gWy4uLl0NCj4gDQo+ PiBJQ0FOTidzIHBsYW4gbWlnaHQgYmUgdW5kZXJzdG9vZCB0byBzdWdnZXN0IHRoYXQsIGV2ZW4g aWYgdGhlcmUgaXMgYQ0KPj4gcHJvYmxlbSBoZXJlIHRvIGJlIHNvbHZlZCAoYW5kIEkgZ3Vlc3Mg dGhlcmUgaXMsIG9yIElDQU5OIHdvdWxkbid0IGJlDQo+PiBkb2luZyBzb21ldGhpbmcgYWJvdXQg aXQpLCBubyBwcm90b2NvbCB3b3JrIGlzIG5lZWRlZCBpbiBvcmRlciB0aGF0IGl0DQo+PiBjb3Vs ZCBiZSBhZGRyZXNzZWQuICBBcmUgb3RoZXJzIGluIGFncmVlbWVudCB3aXRoIHRoYXQ/IA0KPiAN Cj4gWWVzLCBidXQgYSBzdWJzZXF1ZW50IG1lc3NhZ2UgZnJvbSBLaW0gRGF2aWVzIGNsYXJpZmll cyB0aGlzIGFzIA0KPiBpbnRlbmRlZCB0byBiZSBhbiBpbnRlcmltIHBvc2l0aW9uLg0KPiANCj4+ IElmIHNvLCB0aGVuDQo+PiBpdCB3b3VsZCBhcHBlYXIgdGhhdCB0aGUgV0cgZG9lcyBub3QgbmVl ZCB0byBjb25zaWRlciB0aGlzIHRvcGljIGFueQ0KPj4gbW9yZSBhcyBhIHBvc3NpYmxlIHdvcmsg aXRlbS4NCj4gDQo+IFRoaXMgZG9lc24ndCBmb2xsb3csIGJlY2F1c2UgaXQncyBhIGdlbmVyYWwg Y29uY2x1c2lvbiBkcmF3bg0KPiBmcm9tIGEgcGFydGljdWxhciBjYXNlLiAgSUNBTk4gaXMganVz dCBvbmUgb2YgdGhlIHBsYXllcnMgb24gDQo+IHRoZSBETlMgc3RhZ2UuICANCj4gDQo+PiBJZiB5 b3UgZG8gbm90IGFncmVlIHdpdGggdGhhdCBjb25jbHVzaW9uLCBpdCB3b3VsZCBiZSBpbnRlcmVz dGluZyB0bw0KPj4gbWUgdG8gaGVhciB3aHkgbm90LCBhbmQgd2hhdCB5b3UgdGhpbmsgbmVlZHMg c3VwcG9ydCBpbiB0aGUgcHJvdG9jb2wNCj4+IHRoYXQgY2Fubm90IGJlIGFjY29tbW9kYXRlZCBp biBJQ0FOTidzIHBsYW4uDQo+IA0KPiBJIGJlbGlldmUgdGhhdCBJQ0FOTidzIHBsYW4gaXMgb25s eSBvZiBtYXJnaW5hbCByZWxldmFuY2UgdG8gDQo+IHRoZSBxdWVzdGlvbnMgbWVudGlvbmVkIGF0 ICgxKSBhbmQgKDIpIGFib3ZlLiAgQXQgbW9zdCwgSUNBTk4ncw0KPiBwbGFuIG1heSBnaXZlIHJp c2UgdG8gYW4gYWRkaXRpb25hbCBvcHBvcnR1bml0eSB0byBhdmFpbCBvZiBhbnkNCj4gc29sdXRp b24gd2hpY2ggbWF5IGVtZXJnZSBmb3IgcXVlc3Rpb24gKDEpLiAgT24gdGhlIG90aGVyIGhhbmQs IA0KPiB0aGUgcXVlc3Rpb24gYXJpc2VzIGFscmVhZHkgaW4gZXhpc3RpbmcgY2NUTEQgb3BlcmF0 aW9ucywgcHJpb3IgDQo+IHRvLCBhbmQgaW5kZXBlbmRlbnRseSBvZiwgdGhlIGltcGxlbWVudGF0 aW9uIG9mIElDQU5OJ3MgcGxhbi4NCj4gDQo+IFBvc3NpYmxlIHVzZSBjYXNlcyB3aGljaCB3b3Vs ZCBiZSBzZXJ2ZWQgImJ5IHNvbWUga2luZCBvZiANCj4gYWRkaXRpb25hbCBhbGlhc2luZyBtZWNo YW5pc20gZm9yIHRoZSBETlMiIHNlZW0gdG8gbWUgdG8gYmUgDQo+IHdlbGwgY292ZXJlZCBpbiBQ YXVsIFZpeGllJ3Mgc2xpZGUtc2V0IGZvciB0aGUgaW50ZXJpbSBhdWRpbyANCj4gbWVldGluZyBo ZWxkIG9uIDE2IEZlYiAyMDEwLCBhbmQgKHZlcnkgdXNlZnVsbHkpIGluY2x1ZGUgYW4gDQo+IGV4 YW1wbGUgd2hpY2ggaXMgbm90IHJlbGF0ZWQgdG8gdmFyaWFudCBJRE5BIHN0cmluZ3MuDQo+IA0K PiBEcmFmdHMgKEJOQU1FIGFuZCBTSEFET1cpIGFyZSBhbHJlYWR5IGF2YWlsYWJsZSBhZGRyZXNz aW5nDQo+IHRoZXNlIHN1Z2dlc3RlZCB1c2UgY2FzZXMuICBJdCBzZWVtcyB0byBtZSB0aGF0IGl0 IHdvdWxkIGJlIA0KPiB1c2VmdWwgZm9yIGEgbnVtYmVyIG9mIHRob3NlIHdpdGggYSBtYXRlcmlh bCBpbnRlcmVzdCBpbiB0aGUNCj4gb3V0Y29tZSB0byBtYWtlIGNsZWFyIHN0YXRlbWVudHMgb24g dGhpcyBsaXN0IChhcyBzb21lIGhhdmUgDQo+IGFscmVhZHkgZG9uZSBwcml2YXRlbHkpIGluIHJl c3BlY3Qgb2YgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnM6DQo+IA0KPiBXaGF0IHRoZWlyIGludGVy ZXN0IGlzOw0KPiBJbiB3aGF0IHdheSBleGlzdGluZyBhbGlhc2luZyAocmVwbGljYXRpb24gb3Ig aW5kaXJlY3Rpb24pDQo+ICAgbWVjaGFuaXNtcyBhcmUgKG9yIGFwcGVhciB0byBiZSkgaW5hZGVx dWF0ZSBmb3IgdGhlbTsNCj4gV2hhdCBzaXplIG9mICJlcXVpdmFsZW5jZSBjbHVzdGVyIiB0aGV5 IGFudGljaXBhdGUgbmVlZGluZw0KPiAgIHJlc3BlY3RpdmVseSBmb3IgYSBzaW5nbGUgbGFiZWwg YW5kIGZvciBhbiBGUUROOw0KPiBXaGV0aGVyICh3aXRoIHJlYXNvbnMpIFNIQURPVyBhcHBlYXJz IGEgdXNlZnVsIHNvbHV0aW9uOw0KPiBXaGV0aGVyICh3aXRoIHJlYXNvbnMpIEJOQU1FIGFwcGVh cnMgYSB1c2VmdWwgc29sdXRpb24uDQo+IA0KPiBUaGlzIHNob3VsZCBnaXZlIGEgY2xlYXIgaW1w cmVzc2lvbiBvZiB3aGF0IGJlbmVmaXQsIGlmIGFueSwNCj4gbWlnaHQgZmxvdyBmcm9tIGFueSBm dXJ0aGVyIHdvcmsgb24gdGhpcyB0b3BpYy4NCj4gDQo+IFNvIGZhciwgdGhlIGRpc2N1c3Npb24g b24gdGhpcyBsaXN0IG9mIHRoaXMgdG9waWMgc2VlbXMgdG8NCj4gaGF2ZSBiZWVuIGRvbWluYXRl ZCBieSBwZW9wbGUgZWl0aGVyIHdob3NlIG5hdGl2ZSBsYW5ndWFnZQ0KPiBpcyBFbmdsaXNoLCBv ciBmb3Igd2hvbSB0aGUgTGF0aW4gYWxwaGFiZXQgaXMgYSBjbG9zZSBlbm91Z2gNCj4gYXBwcm94 aW1hdGlvbiB0byBtZWV0aW5nIHRoZWlyIG5lZWRzLiAgV2l0aG91dCBtZWFuaW5nIGVpdGhlciAN Cj4gdG8gaW1wdWduIGFueW9uZSdzIGFjcXVpcmVkIGV4cGVydGlzZSBvciB0byBwbGF5IGRvd24g dGhlDQo+IHZhbHVlIG9mIHByb3h5IGFkdm9jYWN5LCBJIHN1Z2dlc3QgdGhhdCB0d28gb2JzZXJ2 YXRpb25zIGFyZSANCj4gcGVydGluZW50OiBmaXJzdCwgdGhhdCBzdWNoIGEgZ3JvdXAgaXMgbGlr ZWx5IG5vdCBiZXN0IA0KPiBxdWFsaWZpZWQgYnkgZXhwZXJpZW5jZSB0byBhcnRpY3VsYXRlIHRo ZSBwcm9ibGVtOyAgc2Vjb25kbHksIA0KPiB0aGF0IGRvbWluYW5jZSBieSBzdWNoIGEgZ3JvdXAg bWF5IHRlbmQgdG8gbWFyZ2luYWxpemUgdGhvc2UgDQo+IHdobyBhcmUgc28gcXVhbGlmaWVkLg0K PiANCj4gSWYgbm8tb25lIHNwZWFrcyB1cCwgSSdtIGluY2xpbmVkIHRvIGFncmVlIHdpdGggQW5k cmV3IHRoYXQNCj4gIml0IHdvdWxkIGFwcGVhciB0aGF0IHRoZSBXRyBkb2VzIG5vdCBuZWVkIHRv IGNvbnNpZGVyIHRoaXMgDQo+IHRvcGljIGFueSBtb3JlIGFzIGEgcG9zc2libGUgd29yayBpdGVt IiwgYnV0IG5vdCBiZWNhdXNlIG9mDQo+IGFueXRoaW5nIHRvIGRvIHdpdGggSUNBTk4ncyBwbGFu Lg0KPiANCj4gSSBob3BlIHRoaXMgaGVscHMuDQo+IA0KPiBOaWFsbCBPJ1JlaWxseQ0KPiANCj4g DQo+IA0KPiANCj4= From owner-namedroppers@ops.ietf.org Wed Apr 21 07:39:23 2010 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 33AED3A6CA4; Wed, 21 Apr 2010 07:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.334 X-Spam-Level: * X-Spam-Status: No, score=1.334 tagged_above=-999 required=5 tests=[AWL=-2.125, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_55=0.6, J_CHICKENPOX_61=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 hGKMF1LLYG6v; Wed, 21 Apr 2010 07:39:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 19E243A6CAD; Wed, 21 Apr 2010 07:09:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4aWI-0000Db-MV for namedroppers-data0@psg.com; Wed, 21 Apr 2010 14:03:14 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4aWF-0000Ck-Pe for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 14:03:12 +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 F3B671ECB400; Wed, 21 Apr 2010 14:03:09 +0000 (UTC) Date: Wed, 21 Apr 2010 10:03:08 -0400 From: Andrew Sullivan To: Vaggelis Segredakis Cc: 'Niall O'Reilly' , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Message-ID: <20100421140307.GB47807@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> 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, Apr 21, 2010 at 12:08:45PM +0300, Vaggelis Segredakis wrote: > the same. I am pretty sure nobody will ever wish to set up an email account > of the type mail@tld1 and wish to make it operative for mail@tld2. If you do > not face such a problem then why not using the DNAME for this equality > issue? > > However, this is not the case if you discuss domain names under a TLD. If > there where two ways to spell shinkuro.com, both of them correct, would > Andrew wish to receive all of his emails correctly? I believe he would. But the BNAME proposal, as written, wouldn't allow this either. That is, if you had (some.label.tld BNAME other.label.tld), then you could not use some.label.tld as the target of an MX record, any more than you'd be allowed to do that with a CNAME. BNAME clearly does not solve the "mail server issue" for aliasing any more than CNAME does. > created DNAME, which in reality is a sub-mechanism of our request. We would > like DNAME to start right from the top, as it was discussed before(a > mechanism that operates like DNAME+CNAME from the first level of equality > and below that). Given the three types of redirection that I previously outlined, which of them (and to what extent) do you think the BNAME proposal solves? To remind, I offered these three candidates (see http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00890.html). I repeat what I previously wrote, with a modification to avoid this ratholing into a question about TLDs. It's fully generalizable: Suppose that we have [name1] and [name2], and they're supposed to be equivalent. These names may be made of more than one label. [name1] comes from one repetoire of Unicode characters. Call it range1. [name2] comes from another repetoire of Unicode characters. Call it range2. The only restriction is that range1 and range2 have at least one character that differs between them (they're not equivalent sets. In the unlikely event that any people who know about writing systems are reading this, I understand that this simplifying assumption is already really bad. Never mind that). Now, suppose we have any sets of labels, each of which is either in range1 (symbolized r1) or range2 (symbolized r2). Which of the following behaviours is desired: a. Should DNS names in the zones underneath the two synchronized zones be exactly (bit-for-bit) equivalent to one another? For example, for a fully qualified domain name of the form r1.r1.[name1], must there always and only be a synchronized entry r1.r1.[name2]? b. Should all and every label under [name1] be expressed in LE1 and all and every label under TLD2 be expressed in [name2]? For example, for a fully qualified domain of the form r1.r1.[name1] must there always and only be a synchronized entry r2.r2.[name2]? c. Should every label at every level of the DNS be expressed in both LE1 and LE2 (the combinatorial case)? For example, for a fully qualified domain name of the form r1.r1.r1.[name1], would it be necessary also to have r1.r1.r1.[name2], r2.r1.r1.[name2], r2.r2.r1.[name2, r2.r2.r2.[name2], r1.r2.r2.[name2], and so on? My understanding of the BNAME proposal is that it will work fine for (a) and (c) but not (b), that for (c) it requires no less work than just using DNAME except that for DNAME you also need an A record at [name1] and [name2] for every DNAME, and that exactly one of the alternative trees will be allowed as a target for MX records. Is that your reading as well? Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Apr 21 10:05:53 2010 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 521213A6BC0; Wed, 21 Apr 2010 10:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[AWL=1.300, 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 pA+MIfx3wwaN; Wed, 21 Apr 2010 10:05:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5295528C14C; Wed, 21 Apr 2010 09:51:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4d3B-000BQz-8y for namedroppers-data0@psg.com; Wed, 21 Apr 2010 16:45:21 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4d38-000BQd-Gm for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 16:45:18 +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 <0L1800G01JKAOU00@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 17:45:15 +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 <0L1800BB8JVC0J00@dakota.ucd.ie>; Wed, 21 Apr 2010 17:45:13 +0100 (IST) Date: Wed, 21 Apr 2010 17:45:12 +0100 From: Niall O'Reilly Subject: [dnsext] Aliasing and MX In-reply-to: <20100421140307.GB47807@shinkuro.com> To: Andrew Sullivan Cc: Vaggelis Segredakis , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Message-id: <4BCF2B98.1030000@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) 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: Fragmentary replies follow, each with a different subject header. [Scary: maybe I'm channeling Jim? 8-)] I'll try to be brief and candid. Please don't infer any disrespect. On 21/04/10 15:03, Andrew Sullivan wrote: > But the BNAME proposal, as written, wouldn't allow this either. That > is, if you had (some.label.tld BNAME other.label.tld), then you could > not use some.label.tld as the target of an MX record, any more than > you'd be allowed to do that with a CNAME. BNAME clearly does not > solve the "mail server issue" for aliasing any more than CNAME does. The "mail server issue" is a non-issue. Owner names matter; they're visible to end-users. MX targets shouldn't matter; they're for zone admins and mail-service admins to worry about. Likewise for the name used in an SMTP command. BNAME may marginally raise the required-clue threshold for such people. So what? Best regards, Niall O'Reilly From owner-namedroppers@ops.ietf.org Wed Apr 21 10:23:02 2010 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 DC9503A6AB9; Wed, 21 Apr 2010 10:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.138 X-Spam-Level: X-Spam-Status: No, score=-0.138 tagged_above=-999 required=5 tests=[AWL=-0.538, 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 kIOt6dHlFvol; Wed, 21 Apr 2010 10:23:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F4AE3A6B7E; Wed, 21 Apr 2010 10:07:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4dKI-000FJL-Ok for namedroppers-data0@psg.com; Wed, 21 Apr 2010 17:03:02 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4dKF-000FHh-Uz for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 17:03: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 88DF41ECB400; Wed, 21 Apr 2010 17:02:58 +0000 (UTC) Date: Wed, 21 Apr 2010 13:02:56 -0400 From: Andrew Sullivan To: Niall O'Reilly Cc: Vaggelis Segredakis , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Subject: [dnsext] Re: Aliasing and MX Message-ID: <20100421170256.GM47807@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF2B98.1030000@ucd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4BCF2B98.1030000@ucd.ie> 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, Apr 21, 2010 at 05:45:12PM +0100, Niall O'Reilly wrote: > > The "mail server issue" is a non-issue. > > Owner names matter; they're visible to end-users. > > MX targets shouldn't matter; they're for zone admins > and mail-service admins to worry about. Likewise > for the name used in an SMTP command. BNAME may > marginally raise the required-clue threshold for such > people. So what? So what is the mail problem? My impression was that the problem had to do with people mistakenly setting up their mail under the _wrong_ domain, because they try to set it up under their preferred spelling and not in the canonical zone. If that's not the problem, what is the problem? It can't be that a CNAME target is not allowed to be the target domain for mail, because §5.1 of RFC 5321 makes clear that it can be (and what to do when encountering a CNAME there). It might be that it's sort of a pain to make multiple A & AAAA entries in multiple zones for the target domain, if one were to use DNAME. That would be a compelling argument, except that to make BNAME work all resolvers for MTAs in the world would need to be updated to understand BNAME _and_ RFC 5321 would need to be updated (by some other WG) to say what to do with such cases. This goal seems to me to be fantastically unlikely within the next 10 years, which means that some other provisioning-type workaround will be needed until then, and so we might as well just work on the provisioning stuff and be done with it. So I'm still not sure what the problem is the WG is asked to solve. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Apr 21 10:58:03 2010 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 881AA3A6C53; Wed, 21 Apr 2010 10:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.949, BAYES_05=-1.11, 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 PKX95SQz7D8D; Wed, 21 Apr 2010 10:58:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 14A003A6AC6; Wed, 21 Apr 2010 10:51:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4dzw-000Oe8-ME for namedroppers-data0@psg.com; Wed, 21 Apr 2010 17:46:04 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4dzt-000OdH-R2 for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 17:46:01 +0000 Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 47620A94513; Wed, 21 Apr 2010 17:46:01 +0000 (UTC) Message-ID: <4BCF39D9.9090905@mail-abuse.org> Date: Wed, 21 Apr 2010 10:46:01 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Vaggelis Segredakis CC: 'Niall O'Reilly' , 'Andrew Sullivan' , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> In-Reply-To: <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> 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 4/21/10 2:08 AM, Vaggelis Segredakis wrote: > I am happy our request for xNAME has found some allies due to the ICANN > request but in reality we are talking about issues that are close but not > the same. I am pretty sure nobody will ever wish to set up an email account > of the type mail@tld1 and wish to make it operative for mail@tld2. If you do > not face such a problem then why not using the DNAME for this equality > issue? > DNAME and CNAME cannot coexist at the same node, and DNAME does not offer an alias for itself. Names registered at either a TLD or SLD, can not include DNAME RRs, as this would inhibit delegations to other domains. On the other hand, BNAME copies NS RRs into the alias, and will likely synthesize CNAMEs whenever a client indicates, through the lack of a new option, that it does not support a new BNAME paradigm. Synthesized CNAMEs within MX RRs could cause a problem with some MTAs, which might depend upon non-aliased names to avoid mail loops or excessive overhead. In today's email environments, CNAMEs as targets for border MTAs do not appear to cause significant issues, however John Klensin promised such a change will not be acceptable, nor is it clear how synthesized CNAMEs will be supported by DNSSEC. The Shadow zone solution does not appear to suffer from these problems while also offering a means to provide "equivalent" domains. John Klensin also suggested there was a need to determine the bundle members of equivalent domains. While Paul said something different in this regard, it seems possible to request RRs at relative name boundaries within the shadow zone that could contain information aimed at facilitating the management of shadow zone replication, such as access control info, the name of the Amber zone, replication error hold-off. Finding the Amber Zone name at the relative name boundary might provide a partial solution, however John did not explain what problem was needing solved with respect to the name-set. -Doug From owner-namedroppers@ops.ietf.org Wed Apr 21 11:16:38 2010 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 499113A68BC; Wed, 21 Apr 2010 11:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=2.415, 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 nzEClV2keNDP; Wed, 21 Apr 2010 11:16:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7E0763A6AC3; Wed, 21 Apr 2010 11:11:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4eK2-0003mq-MG for namedroppers-data0@psg.com; Wed, 21 Apr 2010 18:06:50 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4eK0-0003ma-JG for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 18:06:48 +0000 Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 458FCA947B7; Wed, 21 Apr 2010 18:06:48 +0000 (UTC) Message-ID: <4BCF3EB7.6050703@mail-abuse.org> Date: Wed, 21 Apr 2010 11:06:47 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Sullivan CC: Niall O'Reilly , Vaggelis Segredakis , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Subject: Re: [dnsext] Re: Aliasing and MX References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF2B98.1030000@ucd.ie> <20100421170256.GM47807@shinkuro.com> In-Reply-To: <20100421170256.GM47807@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: On 4/21/10 10:02 AM, Andrew Sullivan wrote: > On Wed, Apr 21, 2010 at 05:45:12PM +0100, Niall O'Reilly wrote: > >> The "mail server issue" is a non-issue. >> >> Owner names matter; they're visible to end-users. >> >> MX targets shouldn't matter; they're for zone admins >> and mail-service admins to worry about. Likewise >> for the name used in an SMTP command. BNAME may >> marginally raise the required-clue threshold for such >> people. So what? >> > So what is the mail problem? > > My impression was that the problem had to do with people mistakenly > setting up their mail under the _wrong_ domain, because they try to > set it up under their preferred spelling and not in the canonical > zone. If that's not the problem, what is the problem? > > It can't be that a CNAME target is not allowed to be the target domain > for mail, because §5.1 of RFC 5321 makes clear that it can be (and > what to do when encountering a CNAME there). Don't confuse using CNAME for a mail domain, as opposed to having CNAME as a target for the MX record. -Doug From owner-namedroppers@ops.ietf.org Wed Apr 21 11:39:04 2010 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 5011F3A6C55; Wed, 21 Apr 2010 11:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_20=-0.74, 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 nqCY9zMUby87; Wed, 21 Apr 2010 11:39:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D28628C170; Wed, 21 Apr 2010 11:33:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4eg8-0008Ss-9B for namedroppers-data0@psg.com; Wed, 21 Apr 2010 18:29:40 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4eg5-0008S4-KX for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 18:29:37 +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 <0L1800901OD1FB00@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 19:29:36 +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 <0L1800BCTOPB0J00@dakota.ucd.ie>; Wed, 21 Apr 2010 19:29:35 +0100 (IST) Date: Wed, 21 Apr 2010 19:29:35 +0100 From: Niall O'Reilly Subject: [dnsext] Use the layers, Luke! In-reply-to: <20100421140307.GB47807@shinkuro.com> To: Andrew Sullivan Cc: Vaggelis Segredakis , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Message-id: <4BCF440F.1090501@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) 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, with intended brevity, candour, and respect ... On 21/04/10 15:03, Andrew Sullivan wrote: > I repeat what I previously wrote, with a modification to avoid this > ratholing into a question about TLDs. It's fully generalizable: > > Suppose that we have [name1] and [name2], and they're supposed to be > equivalent. These names may be made of more than one label. [name1] > comes from one repetoire of Unicode characters. Call it range1. > [name2] comes from another repetoire of Unicode characters. Call it > range2. The only restriction is that range1 and range2 have at least > one character that differs between them (they're not equivalent sets. > In the unlikely event that any people who know about writing systems > are reading this, I understand that this simplifying assumption is > already really bad. Never mind that). Now, suppose we have any sets > of labels, each of which is either in range1 (symbolized r1) or > range2 (symbolized r2). Which of the following behaviours is > desired: [suggestions a, b, and c are elided here] This question ("Which of the following ...") is a matter of registry policy, whether that registry be ICANN, a TLD, or the administrator of some deep subsidiary zone. It's not the problem we're looking for, and we should best avoid it. Articulating, supporting, and (even!) policing such policy is for the registry concerned. This WG need not concern itself with repertoires or writing systems. Such things belong in a different layer. [Choosing a number for that layer is left as an exercise for the reader. 8-)] An outcome of each such registry policy is that a requirement arises to support a number of sets (equivalence classes, but that's not important just now) of administratively equivalent domain names. Each such set has properties such as multiplicity and fan-out. The latter may have to be considered at either or both (!) the label and zone levels. For a registry to deal with such a set of domain names, the first question is, how to do the provisioning. The second is, how this can be simplified by adding sophistication to the protocol. That's where this WG comes in: downstream of the black box which accepts names expressed in repertoires and writing systems, and produces clusters of equivalent names. Best regards, Niall O'Reilly From owner-namedroppers@ops.ietf.org Wed Apr 21 11:47:41 2010 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 BDF903A6944; Wed, 21 Apr 2010 11:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.239 X-Spam-Level: ** X-Spam-Status: No, score=2.239 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_40=-0.185, 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 Hv-YM9drNm-1; Wed, 21 Apr 2010 11:47:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECEB53A6B7E; Wed, 21 Apr 2010 11:44:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4er4-000Ac0-5K for namedroppers-data0@psg.com; Wed, 21 Apr 2010 18:40:58 +0000 Received: from [209.85.222.174] (helo=mail-pz0-f174.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4eqV-000AVI-PV for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 18:40:23 +0000 Received: by pzk4 with SMTP id 4so1073755pzk.9 for ; Wed, 21 Apr 2010 11:40:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.15.10 with HTTP; Wed, 21 Apr 2010 11:40:22 -0700 (PDT) In-Reply-To: <4BCF3EB7.6050703@mail-abuse.org> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF2B98.1030000@ucd.ie> <20100421170256.GM47807@shinkuro.com> <4BCF3EB7.6050703@mail-abuse.org> Date: Wed, 21 Apr 2010 11:40:22 -0700 Received: by 10.115.64.21 with SMTP id r21mr7934944wak.23.1271875222378; Wed, 21 Apr 2010 11:40:22 -0700 (PDT) Message-ID: Subject: Re: [dnsext] Re: Aliasing and MX From: Matthew Dempsky To: Douglas Otis 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: On Wed, Apr 21, 2010 at 11:06 AM, Douglas Otis wrote: > Don't confuse using CNAME for a mail domain, as opposed to having CNAME as a > target for the MX record. What's the big deal in supporting CNAME records in MX record targets? The entire argument for not allowing MX records to point to CNAME records is because it's not handled by additional section processing, but aside from delegations, additional section processing is an *optimization*. Maybe they think the Internet will fall apart if this optimization wasn't available, but a huge number of domains use third-party mail hosting providers which don't work with additional section processing either. Even gmail.com doesn't use in-bailiwick mail exchangers. Clearly even today MTAs can't rely on caches including A/AAAA records for the mail exchanges in the additional section of their MX query responses, so they'll have to do explicit queries anyway. So why forbid the usual CNAME processing in those extra explicit queries? From owner-namedroppers@ops.ietf.org Wed Apr 21 11:55:16 2010 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 645FA3A6B79; Wed, 21 Apr 2010 11:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.305 X-Spam-Level: X-Spam-Status: No, score=-4.305 tagged_above=-999 required=5 tests=[AWL=0.743, 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 qlM7kE8z8Dc6; Wed, 21 Apr 2010 11:55:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8A7193A6B56; Wed, 21 Apr 2010 11:51:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4ewx-000BtF-05 for namedroppers-data0@psg.com; Wed, 21 Apr 2010 18:47:03 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4ewu-000Bou-N0 for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 18:47:00 +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 <0L1800201PBRE200@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 19:46:59 +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 <0L1800BD8PIA0J00@dakota.ucd.ie>; Wed, 21 Apr 2010 19:46:59 +0100 (IST) Date: Wed, 21 Apr 2010 19:46:58 +0100 From: Niall O'Reilly Subject: [dnsext] Fully generalizable? In-reply-to: <20100421140307.GB47807@shinkuro.com> To: Andrew Sullivan Cc: Vaggelis Segredakis , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Message-id: <4BCF4822.2060205@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) 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 21/04/10 15:03, Andrew Sullivan wrote: > I repeat what I previously wrote, with a modification to avoid this > ratholing into a question about TLDs. It's fully generalizable: It may be fully generalizable, but your examples don't seem to cover the gamut of cases. I'm not certain that this matters, as serendipitous implementation may drag them in anyway. The additional cases I'm thinking of are the following. (d?) Equivalence arises between names with different label counts (Vixie example); and (e?) a common suffix (TLD label, or sequence of more significant labels nearest the root) has multiplicity of unity (current situation under .GR). ATB, Niall O'Reilly From owner-namedroppers@ops.ietf.org Wed Apr 21 12:03:16 2010 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 EF2F13A6B00; Wed, 21 Apr 2010 12:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.491 X-Spam-Level: X-Spam-Status: No, score=-4.491 tagged_above=-999 required=5 tests=[AWL=0.557, 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 FUkMlWPPGgoo; Wed, 21 Apr 2010 12:03:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE87D3A67A4; Wed, 21 Apr 2010 12:01:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4f6z-000EC0-1y for namedroppers-data0@psg.com; Wed, 21 Apr 2010 18:57:25 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4f6v-000E87-OO for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 18:57:21 +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 <0L1800C01PVZ8O00@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 19:57:20 +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 <0L1800BCGPZJ0I00@dakota.ucd.ie>; Wed, 21 Apr 2010 19:57:19 +0100 (IST) Date: Wed, 21 Apr 2010 19:57:19 +0100 From: Niall O'Reilly Subject: Re: [dnsext] Re: Aliasing and MX In-reply-to: <20100421170256.GM47807@shinkuro.com> To: Andrew Sullivan Cc: Vaggelis Segredakis , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Message-id: <4BCF4A8F.6090401@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF2B98.1030000@ucd.ie> <20100421170256.GM47807@shinkuro.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) 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 21/04/10 18:02, Andrew Sullivan wrote: > On Wed, Apr 21, 2010 at 05:45:12PM +0100, Niall O'Reilly wrote: >> The "mail server issue" is a non-issue. >> >> Owner names matter; they're visible to end-users. >> >> MX targets shouldn't matter; they're for zone admins >> and mail-service admins to worry about. Likewise >> for the name used in an SMTP command. BNAME may >> marginally raise the required-clue threshold for such >> people. So what? > > So what is the mail problem? A distraction. A non-issue. There is none. To paraphrase the message from Doug Otis: it's about (LHS) keys, not about (RHS, RDATA) values. ATB, Niall O'Reilly From owner-namedroppers@ops.ietf.org Wed Apr 21 12:09:07 2010 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 DE91D3A6863; Wed, 21 Apr 2010 12:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.999 X-Spam-Level: X-Spam-Status: No, score=0.999 tagged_above=-999 required=5 tests=[AWL=-0.920, 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 Lq4R4DYBvL44; Wed, 21 Apr 2010 12:09:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 61A263A68A8; Wed, 21 Apr 2010 12:08:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4fDw-000Fe4-RL for namedroppers-data0@psg.com; Wed, 21 Apr 2010 19:04:36 +0000 Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4fDt-000Fcx-Pm for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 19:04:34 +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 E206C15427EB; Wed, 21 Apr 2010 20:04:28 +0100 (BST) Cc: Douglas Otis , namedroppers@ops.ietf.org Message-Id: <1596F065-1C13-4324-8AA9-AC397A85653A@rfc1035.com> From: Jim Reid To: Matthew Dempsky In-Reply-To: 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] Re: Aliasing and MX Date: Wed, 21 Apr 2010 20:04:27 +0100 References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF2B98.1030000@ucd.ie> <20100421170256.GM47807@shinkuro.com> <4BCF3EB7.6050703@mail-abuse.org> 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 21 Apr 2010, at 19:40, Matthew Dempsky wrote: > What's the big deal in supporting CNAME records in MX record targets? Well for starters it's a protocol violation. See Section 10.3 of RFC2181. Bad Things can also happen with MTAs when the target of an MX record is not the canonical host name. A common misconfiguration is to use a CNAME which the MTA then finds points at itself, causing loops or erroneously bounced mail. When sendmail is involved, this gives rise to the delightful "I refuse to talk to myself" error: http://www.sendmail.org/faq/section4#4.5 . Changing the DNS protocol here would be unwise because of the impact it would have on broken MTAs that do The Wrong Thing. A protocol change would also break the installed base of MTAs that do The Right Thing and can't/won't go chasing CNAMEs. From owner-namedroppers@ops.ietf.org Wed Apr 21 12:28:42 2010 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 7BCE23A6A83; Wed, 21 Apr 2010 12:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[AWL=0.446, 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 BcD+szzHbi5D; Wed, 21 Apr 2010 12:28:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 54BB43A6B1C; Wed, 21 Apr 2010 12:26:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4fVt-000Jd2-BL for namedroppers-data0@psg.com; Wed, 21 Apr 2010 19:23:09 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4fVq-000Jcj-Vu for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 19:23:07 +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 <0L1800601QXAF100@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 20:23:05 +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 <0L1800BDFR6G0J00@dakota.ucd.ie>; Wed, 21 Apr 2010 20:23:05 +0100 (IST) Date: Wed, 21 Apr 2010 20:23:04 +0100 From: Niall O'Reilly Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-reply-to: <4BCF39D9.9090905@mail-abuse.org> To: Douglas Otis Cc: Vaggelis Segredakis , 'Andrew Sullivan' , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Message-id: <4BCF5098.9060109@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) 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 21/04/10 18:46, Douglas Otis wrote: > [...] On the other hand, BNAME copies NS RRs into the alias I've never thought of making a zone apex the target of a CNAME. This may be unusual, or even perverse, but is it actually forbidden? If not we have the potential effect already since RFCs 1034 and 1035. And a zone cut could be below the target of a DNAME, couldn't it? ATB, Niall O'Reilly From owner-namedroppers@ops.ietf.org Wed Apr 21 12:47:11 2010 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 DE2553A6B18; Wed, 21 Apr 2010 12:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[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 OVAchdeShoFl; Wed, 21 Apr 2010 12:47:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B5ED83A6B00; Wed, 21 Apr 2010 12:47:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4fpE-000Nfn-H6 for namedroppers-data0@psg.com; Wed, 21 Apr 2010 19:43:08 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4fpA-000NeD-Tr for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 19:43:05 +0000 Received: from crankycanuck.ca (CPE002127da73a9-CM00195eefd958.cpe.net.cable.rogers.com [99.255.2.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 49C201ECB400 for ; Wed, 21 Apr 2010 19:43:03 +0000 (UTC) Date: Wed, 21 Apr 2010 15:42:56 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Aliasing and MX Message-ID: <20100421194255.GA912@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF2B98.1030000@ucd.ie> <20100421170256.GM47807@shinkuro.com> <4BCF3EB7.6050703@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BCF3EB7.6050703@mail-abuse.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: On Wed, Apr 21, 2010 at 11:06:47AM -0700, Douglas Otis wrote: > Don't confuse using CNAME for a mail domain, as opposed to having CNAME > as a target for the MX record. I don't believe I did. I was pointing out that that couldn't be "the mail problem". The only mail problem we might have is that an MX can't point to a CNAME. -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Apr 21 12:47:22 2010 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 3B8373A6B0D; Wed, 21 Apr 2010 12:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[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 gOmhP5rUa3ZI; Wed, 21 Apr 2010 12:47:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 16C523A68E3; Wed, 21 Apr 2010 12:47:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4fqR-000Nxu-PX for namedroppers-data0@psg.com; Wed, 21 Apr 2010 19:44:23 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4fqO-000NxO-Rv for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 19:44:20 +0000 Received: from crankycanuck.ca (CPE002127da73a9-CM00195eefd958.cpe.net.cable.rogers.com [99.255.2.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CFF4E1ECB400; Wed, 21 Apr 2010 19:44:17 +0000 (UTC) Date: Wed, 21 Apr 2010 15:44:14 -0400 From: Andrew Sullivan To: Niall O'Reilly Cc: Vaggelis Segredakis , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Subject: Re: [dnsext] Re: Aliasing and MX Message-ID: <20100421194413.GB912@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF2B98.1030000@ucd.ie> <20100421170256.GM47807@shinkuro.com> <4BCF4A8F.6090401@ucd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BCF4A8F.6090401@ucd.ie> 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, Apr 21, 2010 at 07:57:19PM +0100, Niall O'Reilly wrote: >> So what is the mail problem? > > A distraction. > A non-issue. > There is none. Ok, except since Vaggelis is the one who says there is this problem, I'd like to know what it's supposed to be. Remember, we're trying to figure out whether there's a problem to solve. Step 1 in that is "describe problem", I think. -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Apr 21 12:56:21 2010 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 F33E03A67FC; Wed, 21 Apr 2010 12:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.676 X-Spam-Level: X-Spam-Status: No, score=-4.676 tagged_above=-999 required=5 tests=[AWL=0.372, 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 W+g-JoBoCbJI; Wed, 21 Apr 2010 12:56:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 728AC3A68E6; Wed, 21 Apr 2010 12:56:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4fxL-000POI-6y for namedroppers-data0@psg.com; Wed, 21 Apr 2010 19:51:31 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4fxI-000PNn-By for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 19:51:28 +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 <0L1800601SB30500@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 20:51:26 +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 <0L1800BDOSHQ0J00@dakota.ucd.ie>; Wed, 21 Apr 2010 20:51:26 +0100 (IST) Date: Wed, 21 Apr 2010 20:51:26 +0100 From: Niall O'Reilly Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-reply-to: <4BCF5098.9060109@ucd.ie> To: Douglas Otis Cc: Vaggelis Segredakis , 'Andrew Sullivan' , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Message-id: <4BCF573E.2060806@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <4BCF5098.9060109@ucd.ie> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) 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 21/04/10 20:23, Niall O'Reilly wrote: > On 21/04/10 18:46, Douglas Otis wrote: >> [...] On the other hand, BNAME copies NS RRs into the alias > > I've never thought of making a zone apex the target > of a CNAME. This may be unusual, Doh! Thinking in wrong layer. Hubris. ... www IN CNAME @ OTOH, copying NS RRs into the alias isn't a new phenomenon. ATB, Niall O'Reilly From owner-namedroppers@ops.ietf.org Wed Apr 21 13:01:02 2010 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 D31B83A6B71; Wed, 21 Apr 2010 13:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 H2asAg5-Yuy1; Wed, 21 Apr 2010 13:01:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B55053A6B73; Wed, 21 Apr 2010 13:01:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4g2f-0000SE-DY for namedroppers-data0@psg.com; Wed, 21 Apr 2010 19:57:01 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4g2b-0000Qj-Cm for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 19:56:57 +0000 Received: from crankycanuck.ca (CPE002127da73a9-CM00195eefd958.cpe.net.cable.rogers.com [99.255.2.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 55C2B1ECB400 for ; Wed, 21 Apr 2010 19:56:56 +0000 (UTC) Date: Wed, 21 Apr 2010 15:56:54 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Re: Use the layers, Luke! Message-ID: <20100421195653.GD912@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF440F.1090501@ucd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BCF440F.1090501@ucd.ie> 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: Thanks for the continued effort in clarifying these issues. It's really very helpful. I'll try to be terse too. On Wed, Apr 21, 2010 at 07:29:35PM +0100, Niall O'Reilly wrote: > This question ("Which of the following ...") is a matter of registry > policy, whether that registry be ICANN, a TLD, or the administrator of > some deep subsidiary zone. It's not the problem we're looking for, and > we should best avoid it. It's exactly the problem we're supposed to be solving, in that those are three possible meanings of "equivalent" and they are nowise the same thing. If we're going to claim that we're supporting aliasing, we need to be crystal clear on what we can and cannot do. If it turns out that all the things we actually can do solve no actual problem that actual users actually have, then I do not believe the WG will ever complete the work, and I will conclude we should not add it to the charter. > such policy is for the registry concerned. This WG need not concern > itself with repertoires or writing systems. Such things belong in a > different layer. On this we completely agree. I'm trying to understand use-cases, but I am not pretending that we will be able to "solve" some linguistic problem. > domain names. Each such set has properties such as multiplicity and > fan-out. The latter may have to be considered at either or both (!) the > label and zone levels. Exactly right. So, what among the possible properties here are we capable of solving, and do those align with the needs of the potential user population? I maintain that the latter question is more important than the former. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Apr 21 14:45:35 2010 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 D59CA28C0F5; Wed, 21 Apr 2010 14:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.577, 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 uiFBZw5r8aqY; Wed, 21 Apr 2010 14:45:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 34C423A683E; Wed, 21 Apr 2010 14:45:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4hdc-000JbC-Bp for namedroppers-data0@psg.com; Wed, 21 Apr 2010 21:39:16 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4hdW-000JZf-LW for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 21:39:10 +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 10B32E9126; Wed, 21 Apr 2010 21:39: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 o3LLcuBp013410; Thu, 22 Apr 2010 07:38:57 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004212138.o3LLcuBp013410@drugs.dv.isc.org> To: "Niall O'Reilly" Cc: Andrew Sullivan , Vaggelis Segredakis , namedroppers@ops.ietf.org, "'Sotiris Panaretou'" From: Mark Andrews References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF2B98.1030000@ucd.ie> <20100421170256.GM47807@shinkuro.com> <4BCF4A8F.6090401@ucd.ie> Subject: Re: [dnsext] Re: Aliasing and MX In-reply-to: Your message of "Wed, 21 Apr 2010 19:57:19 +0100." <4BCF4A8F.6090401@ucd.ie> Date: Thu, 22 Apr 2010 07:38:56 +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 <4BCF4A8F.6090401@ucd.ie>, "Niall O'Reilly" writes: > On 21/04/10 18:02, Andrew Sullivan wrote: > > On Wed, Apr 21, 2010 at 05:45:12PM +0100, Niall O'Reilly wrote: > >> The "mail server issue" is a non-issue. > >> > >> Owner names matter; they're visible to end-users. > >> > >> MX targets shouldn't matter; they're for zone admins > >> and mail-service admins to worry about. Likewise > >> for the name used in an SMTP command. BNAME may > >> marginally raise the required-clue threshold for such > >> people. So what? > > > > So what is the mail problem? > > A distraction. > A non-issue. > There is none. > > To paraphrase the message from Doug Otis: it's > about (LHS) keys, not about (RHS, RDATA) values. > > ATB, > Niall O'Reilly Aliases are a issue on *both* sides. If you use addresses as aliases then you need to configure the MTA to know all the possible permutations so accept the email as the sending MTA won't re-write the mail domain component as it does when presented with a CNAME. If you use CNAME or addresss as aliases then you need to configure the MTA to know all the possible permutations for MX processing. This is critical when the MTA is *not* the best preference MX. If the MTA is the best preference MX then the mail gets delivered before MX processing occurs but that assumes the MTA knows the aliases for all the domains it is supposed to accept email for. The same thing *may* apply with SRV. It depends if the target is store-and-forward or not. 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 Apr 21 15:20:16 2010 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 A51903A683E; Wed, 21 Apr 2010 15:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=-0.981, BAYES_50=0.001, 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 s0x-DZZAMPqY; Wed, 21 Apr 2010 15:20:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD9293A694C; Wed, 21 Apr 2010 15:20:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4iCC-0000uU-MI for namedroppers-data0@psg.com; Wed, 21 Apr 2010 22:15:00 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4iC8-0000tf-CH for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 22:14:56 +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 <0L1800I01YVFTP00@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 23:14:53 +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 <0L1800BG4Z4S0J00@dakota.ucd.ie>; Wed, 21 Apr 2010 23:14:52 +0100 (IST) Date: Wed, 21 Apr 2010 23:14:52 +0100 From: Niall O'Reilly Subject: Re: [dnsext] Re: Use the layers, Luke! In-reply-to: <20100421195653.GD912@shinkuro.com> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Message-id: <4BCF78DC.4000405@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF440F.1090501@ucd.ie> <20100421195653.GD912@shinkuro.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) 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 21/04/10 20:56, Andrew Sullivan wrote: > [...] So, what among the possible properties here are we > capable of solving, and do those align with the needs of the potential > user population? I maintain that the latter question is more > important than the former. Absolutely! Would you attach even more importance to alignment of a solution to the needs of an actual user population? http://www.ίδρυματεχνολογίασέρευνασ.gr/ http://www.xn--ixadahbbkgke5djpgxb1al0bfgtp0b.gr/ is one element of an eight-fold bundle, actually in use, but implemented (IIUC) as a four-fold bundle to save on overhead. Potentially, when .GR implements IDNA2008, this becomes a 32-fold bundle, as two additional character-equi-ambivalences (sic!) will be introduced, increasing the binary logarithm of the multiplicity from 3 to 5. Whenever a [dot-Greece-in-Greek] TLD appears, there is potential for a 2- (or, if the existing .GR is counted in, 3-) fold increase in multiplicity. That's an anticipated need for nearly 100 "images" of a zone to be projected into the DNS. Vaggelis has told us that he sees BNAME as a better solution for what he has to deal with already today than the awkward current solution of using DNAME with apex (not zone apex, but DNAME apex) back-filling. IMHO, BNAME is worth doing because it meets an existing, rather than potential need. In addition, by avoiding the replication of data, BNAME promises to contain the combinatorial explosion. This problem seems not to be well contained by the SHADOW concept. I'm not suggesting that there are no converse reasons for preferring SHADOW. ATB, Niall O'Reilly From owner-namedroppers@ops.ietf.org Wed Apr 21 15:39:02 2010 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 DFDB23A69D3; Wed, 21 Apr 2010 15:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.607 X-Spam-Level: X-Spam-Status: No, score=-4.607 tagged_above=-999 required=5 tests=[AWL=0.441, 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 ZmRP+uXVL-SE; Wed, 21 Apr 2010 15:39:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 20AB93A69A0; Wed, 21 Apr 2010 15:39:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4iVx-0004lX-Jz for namedroppers-data0@psg.com; Wed, 21 Apr 2010 22:35:25 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4iVt-0004jP-1v for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 22:35:21 +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 <0L1900A0101CK400@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 23:35:19 +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 <0L1900BGP02U0J00@dakota.ucd.ie>; Wed, 21 Apr 2010 23:35:18 +0100 (IST) Date: Wed, 21 Apr 2010 23:35:18 +0100 From: Niall O'Reilly Subject: Re: [dnsext] Re: Aliasing and MX In-reply-to: <201004212138.o3LLcuBp013410@drugs.dv.isc.org> To: Mark Andrews Cc: Andrew Sullivan , Vaggelis Segredakis , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Message-id: <4BCF7DA6.8050105@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF2B98.1030000@ucd.ie> <20100421170256.GM47807@shinkuro.com> <4BCF4A8F.6090401@ucd.ie> <201004212138.o3LLcuBp013410@drugs.dv.isc.org> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) 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 21/04/10 22:38, Mark Andrews wrote: > Aliases are a issue on *both* sides. Indeed, but respectively separable as (OT1H) DNS and (OTO) application issues. Of course we need to keep an eye to consequences, but we probably also need to partition the problem(s). ATB, Niall O'Reilly From owner-namedroppers@ops.ietf.org Wed Apr 21 16:06:06 2010 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 1E4F03A69A5; Wed, 21 Apr 2010 16:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.116 X-Spam-Level: X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_40=-0.185, 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 2CiaKweqb4EL; Wed, 21 Apr 2010 16:06:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 22DA63A6898; Wed, 21 Apr 2010 16:06:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4iuT-0009io-Bh for namedroppers-data0@psg.com; Wed, 21 Apr 2010 23:00:45 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4iuP-0009iB-Pt for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 23:00:41 +0000 Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 74CFAA94593; Wed, 21 Apr 2010 23:00:41 +0000 (UTC) Message-ID: <4BCF8399.5030901@mail-abuse.org> Date: Wed, 21 Apr 2010 16:00:41 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: George Barwood CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Comments on draft-ietf-dnsext-rfc2672bis-dname-19 References: <789FDC5525B446C0ABCCD9CA105D27BE@local> In-Reply-To: <789FDC5525B446C0ABCCD9CA105D27BE@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 4/21/10 1:06 PM, George Barwood wrote: > Section 2.3 > > It would be sensible to allow CNAME to co-exist with DNAME. There is > no conflict, since DNAME matchs below the owner, and CNAME matchs at > the owner. Forbidding CNAME doesn't seem to have any justification > (albeit this was a restriction in the original specification ). CNAME indicates resources for the name, except those related to DNSSEC, are found at the held alias. DNAME indicates any downward looking node holding a DNAME will cause the name being sought be the query name, the result of a CNAME being followed, or DNAME's replacing suffix labels of the name being sought that match the owner name of the DNAME with the held alias. Seeing DNAME and CNAME at the same node requires CNAME be ignored, except for exact matches. The prohibition still seems justified, as this prevents difficulty in assigning the source of a resource. Seems critical, since accurately matching names against resources is important when there may be doubts in how this might be cached. When the goal is to provide equivalent names, a lack of CNAME signatures whenever BNAME or DNAME is not understood suggests "equivalency" is not possible on that basis. Section 5.1. "Canonical hostnames cannot be below DNAME owners" makes it clear use of name aliases will not result in "equivalently" capable domains as well. Imagine the effect of aliasing two ideograms that mean country at a TLD. IMHO, these issues suggest the Shadow zone scheme has greater merit, with the expense of multiple certs. Do you seen another way for security to be retained? -Doug From owner-namedroppers@ops.ietf.org Wed Apr 21 16:18:31 2010 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 C26B93A69E0; Wed, 21 Apr 2010 16:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.519, 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 ta2EaztHB37Y; Wed, 21 Apr 2010 16:18:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B27463A68F9; Wed, 21 Apr 2010 16:18:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4j7r-000D8Y-QG for namedroppers-data0@psg.com; Wed, 21 Apr 2010 23:14:35 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4j7n-000D7v-34 for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 23:14:31 +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 B711EE9145; Wed, 21 Apr 2010 23:14:29 +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 o3LNEQKl069128; Thu, 22 Apr 2010 09:14:26 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004212314.o3LNEQKl069128@drugs.dv.isc.org> To: Douglas Otis Cc: Vaggelis Segredakis , "'Niall O'Reilly'" , "'Andrew Sullivan'" , namedroppers@ops.ietf.org, "'Sotiris Panaretou'" From: Mark Andrews References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-reply-to: Your message of "Wed, 21 Apr 2010 10:46:01 MST." <4BCF39D9.9090905@mail-abuse.org> Date: Thu, 22 Apr 2010 09:14:26 +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 <4BCF39D9.9090905@mail-abuse.org>, Douglas Otis writes: > On 4/21/10 2:08 AM, Vaggelis Segredakis wrote: > > I am happy our request for xNAME has found some allies due to the ICANN > > request but in reality we are talking about issues that are close but not > > the same. I am pretty sure nobody will ever wish to set up an email account > > of the type mail@tld1 and wish to make it operative for mail@tld2. If you d > o > > not face such a problem then why not using the DNAME for this equality > > issue? > > > DNAME and CNAME cannot coexist at the same node, and DNAME does not > offer an alias for itself. Names registered at either a TLD or SLD, can > not include DNAME RRs, as this would inhibit delegations to other > domains. On the other hand, BNAME copies NS RRs into the alias, and > will likely synthesize CNAMEs whenever a client indicates, through the > lack of a new option, that it does not support a new BNAME paradigm. What NS's? BNAME is a singleton like CNAME is a singleton. It exists with itself and DNSSEC records proving its existance. It does not co-exist with NS, SOA, A, MX, AAAA or any non-DNSSEC records. > Synthesized CNAMEs within MX RRs could cause a problem with some MTAs, > which might depend upon non-aliased names to avoid mail loops or > excessive overhead. In today's email environments, CNAMEs as targets > for border MTAs do not appear to cause significant issues, however John > Klensin promised such a change will not be acceptable, nor is it clear > how synthesized CNAMEs will be supported by DNSSEC. Actually it is perfectly clear on how we do this. We have done a similar exercise before and know exactly how to do this. DNSSECbis servers don't support NSEC3 but somehow we managed to introduce NSEC3 without breaking all the DNSSECbis servers. We just do the same thing when we introduce BNAME. i.e. use DNSSEC algorithms to signal if the zone may contain a BNAME and only those validators that understand BNAME will treat it as secure. Everyone else will treat the zones as insecure. How to do this has been pointed out multiple times now. > The Shadow zone solution does not appear to suffer from these problems > while also offering a means to provide "equivalent" domains. John > Klensin also suggested there was a need to determine the bundle members > of equivalent domains. Shadow zones are just as bad, if not worse for MTA's. You don't get the self repairing properties of the CNAME so more email will bounce. > While Paul said something different in this regard, it seems possible to > request RRs at relative name boundaries within the shadow zone that > could contain information aimed at facilitating the management of shadow > zone replication, such as access control info, the name of the Amber > zone, replication error hold-off. Finding the Amber Zone name at the > relative name boundary might provide a partial solution, however John > did not explain what problem was needing solved with respect to the > name-set. > > -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 Wed Apr 21 16:41:23 2010 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 B62753A68BD; Wed, 21 Apr 2010 16:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 O5urC7bYkyH7; Wed, 21 Apr 2010 16:41:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 634BF3A6869; Wed, 21 Apr 2010 16:41:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4jTg-000H6T-3U for namedroppers-data0@psg.com; Wed, 21 Apr 2010 23:37:08 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4jTa-000H48-LH for namedroppers@ops.ietf.org; Wed, 21 Apr 2010 23:37:02 +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 BE772E9150 for ; Wed, 21 Apr 2010 23:37:01 +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 o3LNat6K081644 for ; Thu, 22 Apr 2010 09:36:59 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004212336.o3LNat6K081644@drugs.dv.isc.org> Date: Thu, 22 Apr 2010 09:36:55 +1000 From: Mark Andrews Subject: [dnsext] Re: CNAME Issue - Whether to use CNAME-data or Response-Flag To: undisclosed-recipients:; 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: ------- Blind-Carbon-Copy To: Dave Sparro Cc: bind-users@lists.isc.org From: Mark Andrews References: <4BBF84D4.7060501@dougbarton.us> <0E411B009EB24BBDBC961C2D8F1EFE4C@sw2> <4BCF4A6C.8050608@gmail.com> Subject: Re: CNAME Issue - Whether to use CNAME-data or Response-Flag In-reply-to: Your message of "Wed, 21 Apr 2010 14:56:44 -0400." <4BCF4A6C.8050608@gmail.com> Date: Thu, 22 Apr 2010 09:36:55 +1000 Sender: marka@drugs.dv.isc.org In message <4BCF4A6C.8050608@gmail.com>, Dave Sparro writes: > On 4/9/2010 8:59 PM, Steven Wilmot wrote: > > > > 1 - The original server-configuration (or response) from "primary-dns.co.uk > " > > is NOT VALID > > > > If this is the case, could you please help let me know exactly which RFC or > > configuration that you believe is not valid. > > > > Note: 'primary-dns.co.uk is owned and maintained by my ISP (aaisp.net.uk), > > and I'm fairly certain that they would be quick to implement any > > "corrections" if you were able to demonstrate a SPECIFIC bug > > > > The server at primary-dns.co.uk (81.187.30.41) considers itself > authoritative for the 'wilmot.me.uk.mail.aaisp.net.uk' name, but has not > been configured with any data for that name. > > The domain registration for 'aaisp.net.uk' seems to indicate that > auth.primary-dns.co.uk (81.187.30.42) is actually one of the servers > that is supposed to be authoritative. > > This can be fixed several ways: > > * ISP removes false authority from 81.187.30.41. > > * ISP syncs data between the real authority (81.187.30.42), and 81.187.30.41 > > * YOU remove forwarding configuration on your DNS server so that you're > not relying on somebody's mis-managed DNS server ( I suspect that is the > reason that the 81.187.30.41 server got involved in the first place) > > * MS fixes their server such that it doesn't accept data that is > incorrectly marked authoritative. * The IETF updated RFC 1034 so that authoritative servers to not follow CNAME if recursion is not desired. Then misconfigurations like this will not be visible. Mark - -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org ------- End of Blind-Carbon-Copy From owner-namedroppers@ops.ietf.org Wed Apr 21 17:27:17 2010 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 D91263A6987; Wed, 21 Apr 2010 17:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=2.013, 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 D5RofvCfVHqD; Wed, 21 Apr 2010 17:27:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D40993A696D; Wed, 21 Apr 2010 17:27:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4kAQ-000OXS-M1 for namedroppers-data0@psg.com; Thu, 22 Apr 2010 00:21:18 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4kAN-000OX9-DE for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 00:21:15 +0000 Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 07909A94540; Thu, 22 Apr 2010 00:21:15 +0000 (UTC) Message-ID: <4BCF967A.3000109@mail-abuse.org> Date: Wed, 21 Apr 2010 17:21:14 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mark Andrews CC: Vaggelis Segredakis , 'Niall O'Reilly' , 'Andrew Sullivan' , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> In-Reply-To: <201004212314.o3LNEQKl069128@drugs.dv.isc.org> 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 4/21/10 4:14 PM, Mark Andrews wrote: > What NS's? BNAME is a singleton like CNAME is a singleton. It exists with itself and DNSSEC records proving its existance. It does not co-exist with NS, SOA, A, MX, AAAA or any non-DNSSEC records. > http://tools.ietf.org/html/draft-yao-dnsext-bname-01 While the introduction makes a singleton type claim, it defines this as meaning there can be only one BNAME per node. The process defined in section 4.1 "Processing by Servers" for item b of step 3 indicates inclusion of the NS records. To permit aliasing an entire domain, the NS and BNAME resources will appear at the same node. It does seem there might need to be exceptions with respect to CNAME synthesis, however the current BNAME draft offers little guidance in that respect. >> The Shadow zone solution does not appear to suffer from these problems while also offering a means to provide "equivalent" domains. JohnKlensin also suggested there was a need to determine the bundle members of equivalent domains. > Shadow zones are just as bad, if not worse for MTA's. You don't get the self repairing properties of the CNAME so more email will bounce. > You have said this before, but we have experienced problems with perhaps >1% of email senders refusing aliased MX target, against tens of thousands of domains. This had been done following advice given by a content delivery provider. Alternatively, there isn't any difficulty in setting up MTAs to forward to a desired domain. It would seem both John and I disagree that CNAMEs provide a better solution for MX records. This will also be true with NS, SRV, and PTR records. :^( MX records are normally located at the same name as NS, and SOA, which is also where the BNAME will need to reside. But this is problematic, since it is indeed illegal for CNAMEs to coexist with these other resources? -Doug From owner-namedroppers@ops.ietf.org Wed Apr 21 18:07:45 2010 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 940BB3A68EA; Wed, 21 Apr 2010 18:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.400, 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 FrvqV0a+v8Qu; Wed, 21 Apr 2010 18:07:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D9413A676A; Wed, 21 Apr 2010 18:07:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4koN-0006U5-2R for namedroppers-data0@psg.com; Thu, 22 Apr 2010 01:02:35 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4koK-0006TR-BB for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 01:02:32 +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 88EFEE9168; Thu, 22 Apr 2010 01:02:30 +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 o3M124ht097291; Thu, 22 Apr 2010 11:02:21 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004220102.o3M124ht097291@drugs.dv.isc.org> To: Douglas Otis Cc: Vaggelis Segredakis , "'Niall O'Reilly'" , "'Andrew Sullivan'" , namedroppers@ops.ietf.org, "'Sotiris Panaretou'" From: Mark Andrews References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <4BCF967A.3000109@mail-abuse.org> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-reply-to: Your message of "Wed, 21 Apr 2010 17:21:14 MST." <4BCF967A.3000109@mail-abuse.org> Date: Thu, 22 Apr 2010 11:02:04 +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 <4BCF967A.3000109@mail-abuse.org>, Douglas Otis writes: > On 4/21/10 4:14 PM, Mark Andrews wrote: > > What NS's? BNAME is a singleton like CNAME is a singleton. It exists with > itself and DNSSEC records proving its existance. It does not co-exist with > NS, SOA, A, MX, AAAA or any non-DNSSEC records. > > > http://tools.ietf.org/html/draft-yao-dnsext-bname-01 > > While the introduction makes a singleton type claim, it defines this as > meaning there can be only one BNAME per node. The process defined in > section 4.1 "Processing by Servers" for item b of step 3 indicates > inclusion of the NS records. You failed to take into account Section 3.3. The relevent sentence has been isolated below. 3.3. The BNAME Rules There are two rules which governs the use of BNAMEs in a zone file. The first one is that there SHOULD be no descendants under the owner of the BNAME. The second one is that no resource records can co- exist with the BNAME for the same name. It means that if a BNAME RR is present at a node N, there MUST be no other data at N and no data at any descendant of N. This restriction applies only to records of the same class as the BNAME record. > To permit aliasing an entire domain, the > NS and BNAME resources will appear at the same node. No. BNAME gets added to the "parent" zone. When we were designing DNAME we needed to decide if it aliased itself and we decided not to as aliases of itself required the "parent" to support DNAME. BNAME still needs more work. A non-BNAME aware client should never see a BNAME record unless it is explicitly requested. Conversly a BNAME aware client should never see a synthesised CNAME as long it is is talking to BNAME aware servers. Sending both the DNAME and CNAME is one of the things we got wrong with DNAME. Another thing we got wrong was not signaling DNAME understanding from the start. We also didn't understand how to introduce a change like DNAME with DNSSEC. We don't need to repeat these problems with BNAME. The current BNAME draft also fails to account for DNAME in the processing rules. 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 Apr 21 20:00:26 2010 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 5FD653A697D; Wed, 21 Apr 2010 20:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=1.812, 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 mQS64U2bOJvZ; Wed, 21 Apr 2010 20:00:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 70FC93A696D; Wed, 21 Apr 2010 20:00:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4mYp-00005G-9K for namedroppers-data0@psg.com; Thu, 22 Apr 2010 02:54:39 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4mYm-00004s-OM for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 02:54:36 +0000 Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 30E31A94753; Thu, 22 Apr 2010 02:54:36 +0000 (UTC) Message-ID: <4BCFBA6C.5000607@mail-abuse.org> Date: Wed, 21 Apr 2010 19:54:36 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mark Andrews CC: Vaggelis Segredakis , 'Niall O'Reilly' , 'Andrew Sullivan' , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <4BCF967A.3000109@mail-abuse.org> <201004220102.o3M124ht097291@drugs.dv.isc.org> In-Reply-To: <201004220102.o3M124ht097291@drugs.dv.isc.org> 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 4/21/10 6:02 PM, Mark Andrews wrote: >> > To permit aliasing an entire domain, the >> > NS and BNAME resources will appear at the same node. >> > No. BNAME gets added to the "parent" zone. When we were designing > DNAME we needed to decide if it aliased itself and we decided not to > as aliases of itself required the "parent" to support DNAME. > > BNAME still needs more work. A non-BNAME aware client should never > see a BNAME record unless it is explicitly requested. Conversly a > BNAME aware client should never see a synthesised CNAME as long it > is is talking to BNAME aware servers. > > Thank you for the clarification. It seems most domains are fairly flat, but this seem to suggest a departure from current practices of being flat and referencing MX records at zone apexes. For example, take the domain "example.com." Most domains locate MX records at the zone apex, where in this instance, it would be at "example.com." It would not be practical to place a BNAME in ".com" which needs to contain NS records for delegation. But BNAME could reside in a sub-domain of say "2.example.net" to be BNAME aliased with "example.com." is that right? So... # example.net using BNAME might look like: example.net. IN NS dns-svr.example.net. 2.example.com. IN BNAME example.com. # example.com supporting BNAME might then look like: example.com IN NS dns-svr.example.com. example.com IN MX 10 mail-svr.example.com. However, since a subdomain is needed to isolate BNAME from other resources, a similar structure is possible using DNAME as follows: # example.net using DNAME might look like: example.net IN NS dns-svr.example.net. example.net IN DNAME example.com. # example.com supporting DNAME might then look like: example.com IN NS dns-svr.example.com. 2.example.com IN MX 10 mail-svr.example.com. The difference between BNAME and DNAME would be an ability to tailor the isolation labels within name bundles. However Shadow zones could eliminate pesky isolation labels all together. :^) -Doug From owner-namedroppers@ops.ietf.org Wed Apr 21 21:07:27 2010 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 F04BD3A6993; Wed, 21 Apr 2010 21:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 J6Pq6Uh0v3BS; Wed, 21 Apr 2010 21:07:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2326F3A6922; Wed, 21 Apr 2010 21:07:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4nc4-000Bln-IO for namedroppers-data0@psg.com; Thu, 22 Apr 2010 04:02:04 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4nc1-000Bin-RI for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 04:02:01 +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 63FFCE919D; Thu, 22 Apr 2010 04:02:00 +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 o3M41mmK002880; Thu, 22 Apr 2010 14:01:50 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004220401.o3M41mmK002880@drugs.dv.isc.org> To: Douglas Otis Cc: Vaggelis Segredakis , "'Niall O'Reilly'" , "'Andrew Sullivan'" , namedroppers@ops.ietf.org, "'Sotiris Panaretou'" From: Mark Andrews References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <4BCF967A.3000109@mail-abuse.org> <201004220102.o3M124ht097291@drugs.dv.isc.org> <4BCFBA6C.5000607@mail-abuse.org> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-reply-to: Your message of "Wed, 21 Apr 2010 19:54:36 MST." <4BCFBA6C.5000607@mail-abuse.org> Date: Thu, 22 Apr 2010 14:01:48 +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 <4BCFBA6C.5000607@mail-abuse.org>, Douglas Otis writes: > On 4/21/10 6:02 PM, Mark Andrews wrote: > >> > To permit aliasing an entire domain, the > >> > NS and BNAME resources will appear at the same node. > >> > > No. BNAME gets added to the "parent" zone. When we were designing > > DNAME we needed to decide if it aliased itself and we decided not to > > as aliases of itself required the "parent" to support DNAME. > > > > BNAME still needs more work. A non-BNAME aware client should never > > see a BNAME record unless it is explicitly requested. Conversly a > > BNAME aware client should never see a synthesised CNAME as long it > > is is talking to BNAME aware servers. > > > > > Thank you for the clarification. > > It seems most domains are fairly flat, but this seem to suggest a > departure from current practices of being flat and referencing MX > records at zone apexes. No, it doesn't. > For example, take the domain "example.com." Most domains locate MX > records at the zone apex, where in this instance, it would be at > "example.com." It would not be practical to place a BNAME in ".com" > which needs to contain NS records for delegation. Why not? It should be no harder to add BNAME records to com once the servers support BNAME than it is to add NS records. > But BNAME could > reside in a sub-domain of say "2.example.net" to be BNAME aliased with > "example.com." is that right? So... You are making this much more complicated than it really is. > # example.net using BNAME might look like: > example.net. IN NS dns-svr.example.net. > 2.example.com. IN BNAME example.com. > > # example.com supporting BNAME might then look like: > example.com IN NS dns-svr.example.com. > example.com IN MX 10 mail-svr.example.com. > > However, since a subdomain is needed to isolate BNAME from other > resources, a similar structure is possible using DNAME as follows: > > # example.net using DNAME might look like: > example.net IN NS dns-svr.example.net. > example.net IN DNAME example.com. > > # example.com supporting DNAME might then look like: > example.com IN NS dns-svr.example.com. > 2.example.com IN MX 10 mail-svr.example.com. > > The difference between BNAME and DNAME would be an ability to tailor the > isolation labels within name bundles. However Shadow zones could > eliminate pesky isolation labels all together. :^) > > -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 Wed Apr 21 23:27:02 2010 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 CA01A3A6A0A; Wed, 21 Apr 2010 23:27:02 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.211 X-Spam-Level: ** X-Spam-Status: No, score=2.211 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 HWlCWR0OX86I; Wed, 21 Apr 2010 23:27:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8FFA13A6990; Wed, 21 Apr 2010 23:27:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4plM-000B82-64 for namedroppers-data0@psg.com; Thu, 22 Apr 2010 06:19:48 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4plH-000B7Y-PP for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 06:19:44 +0000 Received: (eyou send program); Thu, 22 Apr 2010 14:19:42 +0800 Message-ID: <471917182.14523@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 22 Apr 2010 14:19:42 +0800 Message-ID: <2196717A437E4E05B75B590D1214F3CB@LENOVO47E041CF> From: "YAO Jiankang" To: "Andrew Sullivan" , "Vaggelis Segredakis" Cc: "'Niall O'Reilly'" , , "'Sotiris Panaretou'" References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT aliasmaybe-work Date: Thu, 22 Apr 2010 14:19:25 +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.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: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFuZHJldyBTdWxsaXZhbiIg PGFqc0BzaGlua3Vyby5jb20+DQpUbzogIlZhZ2dlbGlzIFNlZ3JlZGFraXMiIDxzZWdyZWRAaWNz LmZvcnRoLmdyPg0KQ2M6ICInTmlhbGwgTydSZWlsbHknIiA8TmlhbGwub1JlaWxseUB1Y2QuaWU+ OyA8bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZz47ICInU290aXJpcyBQYW5hcmV0b3UnIiA8c290 aXJpc0B1Y3kuYWMuY3k+DQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDIxLCAyMDEwIDEwOjAzIFBN DQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gSUNBTk4ncyAic3luY2hyb25pemVkIGRvbWFpbnMiIGFu ZCB0aGUgRE5TRVhUIGFsaWFzbWF5YmUtd29yaw0KDQoNCj4gT24gV2VkLCBBcHIgMjEsIDIwMTAg YXQgMTI6MDg6NDVQTSArMDMwMCwgVmFnZ2VsaXMgU2VncmVkYWtpcyB3cm90ZToNCj4gDQo+PiB0 aGUgc2FtZS4gSSBhbSBwcmV0dHkgc3VyZSBub2JvZHkgd2lsbCBldmVyIHdpc2ggdG8gc2V0IHVw IGFuIGVtYWlsIGFjY291bnQNCj4+IG9mIHRoZSB0eXBlIG1haWxAdGxkMSBhbmQgd2lzaCB0byBt YWtlIGl0IG9wZXJhdGl2ZSBmb3IgbWFpbEB0bGQyLiBJZiB5b3UgZG8NCj4+IG5vdCBmYWNlIHN1 Y2ggYSBwcm9ibGVtIHRoZW4gd2h5IG5vdCB1c2luZyB0aGUgRE5BTUUgZm9yIHRoaXMgZXF1YWxp dHkNCj4+IGlzc3VlPw0KPj4gDQo+PiBIb3dldmVyLCB0aGlzIGlzIG5vdCB0aGUgY2FzZSBpZiB5 b3UgZGlzY3VzcyBkb21haW4gbmFtZXMgdW5kZXIgYSBUTEQuIElmDQo+PiB0aGVyZSB3aGVyZSB0 d28gd2F5cyB0byBzcGVsbCBzaGlua3Vyby5jb20sIGJvdGggb2YgdGhlbSBjb3JyZWN0LCB3b3Vs ZA0KPj4gQW5kcmV3IHdpc2ggdG8gcmVjZWl2ZSBhbGwgb2YgaGlzIGVtYWlscyBjb3JyZWN0bHk/ IEkgYmVsaWV2ZSBoZSB3b3VsZC4NCj4gDQo+IEJ1dCB0aGUgQk5BTUUgcHJvcG9zYWwsIGFzIHdy aXR0ZW4sIHdvdWxkbid0IGFsbG93IHRoaXMgZWl0aGVyLiAgVGhhdA0KPiBpcywgaWYgeW91IGhh ZCAoc29tZS5sYWJlbC50bGQgQk5BTUUgb3RoZXIubGFiZWwudGxkKSwgdGhlbiB5b3UgY291bGQN Cj4gbm90IHVzZSBzb21lLmxhYmVsLnRsZCBhcyB0aGUgdGFyZ2V0IG9mIGFuIE1YIHJlY29yZCwg YW55IG1vcmUgdGhhbg0KPiB5b3UnZCBiZSBhbGxvd2VkIHRvIGRvIHRoYXQgd2l0aCBhIENOQU1F LiAgQk5BTUUgY2xlYXJseSBkb2VzIG5vdA0KPiBzb2x2ZSB0aGUgIm1haWwgc2VydmVyIGlzc3Vl IiBmb3IgYWxpYXNpbmcgYW55IG1vcmUgdGhhbiBDTkFNRSBkb2VzLg0KPiANCg0KSSB0aGluayB0 aGF0IFZhZ2dlbGlzIGlzIGhvcGluZyB0byBtYWtlIG5hbWVAc2hpbmt1cm8xLmNvbSBhbmQgbmFt ZUBzaGlua3VybzIuY29tIHRvIHJlc29sdmUgdG8gdGhlIHNhbWUgTVggcmVjb3JkcyBvciBhZGRy ZXNzIGlmIHlvdSB3YW50IHRvIG1ha2Ugc2hpbmt1cm8xLmNvbSB0byBiZSBlcXVhbCB3aXRoIHNo aW5rdXJvMi5jb20uDQpIZSBoYXMgbm8gaW50ZW50aW9uIHRvIG1ha2Ugc2hpbmt1cm8xLmNvbSAg dG8gYmUgdGhlICB0YXJnZXQgb2YgYW4gTVggcmVjb3JkIGluIHJlYWwgY29uZmlndXJhdGlvbi4g SW4geW91ciBleGFtcGxlLCAgeWVzLCB3ZSBjb3VsZA0KIG5vdCB1c2Ugc29tZS5sYWJlbC50bGQg YXMgdGhlIHRhcmdldCBvZiBhbiBNWCByZWNvcmQgaW4gcmVhbCBjb25maWd1cmF0aW9uLCBidXQg d2UgY2FuIHVzZSBzaGlua3VybzIuY29tIChvciBvdGhlci5sYWJlbC50bGQgaW4geW91ciBleGFt cGxlKSBhcyB0aGUgIHRhcmdldCBvZiBhbiBNWCByZWNvcmQuDQpib3RoIHNoaW5rdXJvMS5jb20g YW5kIHNoaW5rdXJvMi5jb20gd2lsbCBnZXQgdGhlIHNhbWUgTVggcmVjb3JkIGlmIHNoaW5rdXJv MS5jb20gQk5BTUUgc2hpbmt1cm8yLmNvbSBpcyBhcHBsaWVkLg0KYm90aCBzb21lLmxhYmVsLnRs ZCBhbmQgIG90aGVyLmxhYmVsLnRsZCB3aWxsIGdldCB0aGUgc2FtZSBNWCByZWNvcmQgaWYgc29t ZS5sYWJlbC50bGQgQk5BTUUgb3RoZXIubGFiZWwudGxkIGlzIGFwcGxpZWQuDQoNCmlmIGJuYW1l IGlzIHVzZWQsIFZhZ2dlbGlzJyB3b3JyeSB3aWxsIGRpc2FwcGVhciBzaW5jZSB0aGUgbWFpbCB0 byAgbmFtZUBzaGlua3VybzEuY29tIGFuZCBuYW1lQHNoaW5rdXJvMi5jb20gd2lsbCBnbyB0byB0 aGUgc2FtZSBlbWFpbCBzZXJ2ZSBhbmQgYmUgZGlsdmVyZWQgdG8gc2FtZSBlbWFpbCBib3guDQoN Cg0KSmlhbmthbmcgWWFvDQo= From owner-namedroppers@ops.ietf.org Thu Apr 22 00:05:05 2010 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 146B33A6A79; Thu, 22 Apr 2010 00:05:05 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.117 X-Spam-Level: ** X-Spam-Status: No, score=2.117 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 soFC4uRPXq5Y; Thu, 22 Apr 2010 00:05:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B5E833A6990; Thu, 22 Apr 2010 00:05:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4qOc-000JjW-Ht for namedroppers-data0@psg.com; Thu, 22 Apr 2010 07:00:22 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4qOW-000Jhh-1w for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 07:00:16 +0000 Received: (eyou send program); Thu, 22 Apr 2010 15:00:14 +0800 Message-ID: <471919614.27801@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 22 Apr 2010 15:00:14 +0800 Message-ID: From: "YAO Jiankang" To: "Douglas Otis" , "Mark Andrews" Cc: "Vaggelis Segredakis" , "'Niall O'Reilly'" , "'Andrew Sullivan'" , , "'Sotiris Panaretou'" References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <4BCF967A.3000109@mail-abuse.org> <201004220102.o3M124ht097291@drugs.dv.isc.org> <471905827.11998@cnnic.cn> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Date: Thu, 22 Apr 2010 15:00:15 +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.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: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRvdWdsYXMgT3RpcyIgPGRv dGlzQG1haWwtYWJ1c2Uub3JnPg0KVG86ICJNYXJrIEFuZHJld3MiIDxtYXJrYUBpc2Mub3JnPg0K Q2M6ICJWYWdnZWxpcyBTZWdyZWRha2lzIiA8c2VncmVkQGljcy5mb3J0aC5ncj47ICInTmlhbGwg TydSZWlsbHknIiA8TmlhbGwub1JlaWxseUB1Y2QuaWU+OyAiJ0FuZHJldyBTdWxsaXZhbiciIDxh anNAc2hpbmt1cm8uY29tPjsgPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+OyAiJ1NvdGlyaXMg UGFuYXJldG91JyIgPHNvdGlyaXNAdWN5LmFjLmN5Pg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDIy LCAyMDEwIDEwOjU0IEFNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gSUNBTk4ncyAic3luY2hyb25p emVkIGRvbWFpbnMiIGFuZCB0aGUgRE5TRVhUIGFsaWFzIG1heWJlLXdvcmsNCg0KDQoNCj4gIyBl eGFtcGxlLm5ldCB1c2luZyBCTkFNRSBtaWdodCBsb29rIGxpa2U6DQo+IGV4YW1wbGUubmV0LiBJ TiBOUyBkbnMtc3ZyLmV4YW1wbGUubmV0Lg0KPiAyLmV4YW1wbGUuY29tLiBJTiBCTkFNRSBleGFt cGxlLmNvbS4NCj4gDQo+ICMgZXhhbXBsZS5jb20gc3VwcG9ydGluZyBCTkFNRSBtaWdodCB0aGVu IGxvb2sgbGlrZToNCj4gZXhhbXBsZS5jb20gSU4gTlMgZG5zLXN2ci5leGFtcGxlLmNvbS4NCj4g ZXhhbXBsZS5jb20gSU4gTVggMTAgbWFpbC1zdnIuZXhhbXBsZS5jb20uDQo+IA0KPiBIb3dldmVy LCBzaW5jZSBhIHN1YmRvbWFpbiBpcyBuZWVkZWQgdG8gaXNvbGF0ZSBCTkFNRSBmcm9tIG90aGVy IA0KPiByZXNvdXJjZXMsIGEgc2ltaWxhciBzdHJ1Y3R1cmUgaXMgcG9zc2libGUgdXNpbmcgRE5B TUUgYXMgZm9sbG93czoNCj4gDQo+ICMgZXhhbXBsZS5uZXQgdXNpbmcgRE5BTUUgbWlnaHQgbG9v ayBsaWtlOg0KPiBleGFtcGxlLm5ldCBJTiBOUyBkbnMtc3ZyLmV4YW1wbGUubmV0Lg0KPiBleGFt cGxlLm5ldCBJTiBETkFNRSBleGFtcGxlLmNvbS4NCj4gDQo+ICMgZXhhbXBsZS5jb20gc3VwcG9y dGluZyBETkFNRSBtaWdodCB0aGVuIGxvb2sgbGlrZToNCj4gZXhhbXBsZS5jb20gSU4gTlMgZG5z LXN2ci5leGFtcGxlLmNvbS4NCj4gMi5leGFtcGxlLmNvbSBJTiBNWCAxMCBtYWlsLXN2ci5leGFt cGxlLmNvbS4NCj4gDQoNCnlvdXIgZXhhbXBsZSBpcyAgc28gY29tcGxleCBzbyB0aGF0IEkgY2Fu IG5vdCBoYXZlIHRoZSBjbGVhciBpZGVhIG9mIHdoYXQgaXQgaXMuDQoNCg0KPiBUaGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIEJOQU1FIGFuZCBETkFNRSB3b3VsZCBiZSBhbiBhYmlsaXR5IHRvIHRhaWxv ciB0aGUgDQo+IGlzb2xhdGlvbiBsYWJlbHMgd2l0aGluIG5hbWUgYnVuZGxlcy4gIA0KDQp0aGUg ZGlmZmVyZW5jZSBCTkFNRSBhbmQgRE5BTUUgIGlzIG5vdCB3aGF0IHlvdSBzYWlkLg0KDQp0aGUg QWJzdHJhY3QgaW4gYm5hbWUgZHJhZnQgc2FpZDoNCiINCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5l cyBhIG5ldyBETlMgUmVzb3VyY2UgUmVjb3JkIGNhbGxlZCAiQk5BTUUiLCB3aGljaA0KICAgcHJv dmlkZXMgdGhlIGNhcGFiaWxpdHkgdG8gbWFwIGl0c2VsZiBhbmQgaXRzIHN1YnRyZWUgb2YgdGhl IEROUyBuYW1lDQogICBzcGFjZSB0byBhbm90aGVyIGRvbWFpbi4gIEl0IGRpZmZlcnMgZnJvbSB0 aGUgQ05BTUUgcmVjb3JkIHdoaWNoIG1hcHMNCiAgIGEgc2luZ2xlIG5vZGUgb2YgdGhlIEROUyBu YW1lIHNwYWNlLCBmcm9tIHRoZSBETkFNRSB3aGljaCBtYXBzIHRoZQ0KICAgc3VidHJlZSBvZiB0 aGUgRE5TIG5hbWUgc3BhY2UgdG8gYW5vdGhlciBkb21haW4uDQoiDQoNCmZvciBleGFtcGxlLA0K DQppZiBkbmFtZSBpcyB1c2VkLA0KIGNvbG9yLmNvbSBkbmFtZSBjb2xvdXIuY29tDQoNCnF1ZXJ5 IGZvciBldmVyeSBzdWJkb21haW4gb2YgY29sb3IuY29tIHN1Y2ggYXMgdDEuY29sb3IuY29tIHdp bGwgZ28gdG8gY29sb3VyLmNvbSBkb21haW4gZm9yIGFuc3dlci4NCnF1ZXJ5IGZvciBjb2xvci5j b20gd2lsbCBnbyB0byBpdHMgb3duIGRvbWFpbiBjb2xvci5jb20gZm9yIGFuc3dlci4NCg0KDQpp ZiBibmFtZSBpcyB1c2VkLA0KIGNvbG9yLmNvbSBibmFtZSBjb2xvdXIuY29tDQoNCnF1ZXJ5IGZv ciBjb2xvci5jb20gIGFuZCBldmVyeSBzdWJkb21haW4gb2YgY29sb3IuY29tIHN1Y2ggYXMgdDEu Y29sb3IuY29tIHdpbGwgZ28gdG8gY29sb3VyLmNvbSBkb21haW4gZm9yIGFuc3dlci4NCg0KDQoN Cg0KZm9yIHlvdXIgY29uY2VybiBvZiAgQ05BTUUgbGVhZGluZyB0byBNWCwgeWVzLCB3ZSBzaG91 bGQgYmUgY2F1dGlvbiBvZiBDTkFNRS9ETkFNRS9CTkFNRSBsb29wcy4NCg0KaWYgdGhlcmUgYXJl IG5vIGxvb3BzLCB0aGUgc3ludGhlc2l6ZWQgQ05BTUUgd2lsbCBmaW5hbGx5IGxlYWQgdG8gdGhl IE1YIHJlY29yZCBvciBhZGRyZXNzLA0KDQp0aGUgZmlyc3Qgc2VudGVuc2Ugb2YgdGhlIHNlY29u ZCBwYXJhZ3JhcGggaW4gc2VjdGlvbiA1LjEgaW4gUkZDIDUzMjEgc2FpZCwgDQoiDQogICBUaGUg bG9va3VwIGZpcnN0IGF0dGVtcHRzIHRvIGxvY2F0ZSBhbiBNWCByZWNvcmQgYXNzb2NpYXRlZCB3 aXRoIHRoZQ0KICAgbmFtZS4gIElmIGEgQ05BTUUgcmVjb3JkIGlzIGZvdW5kLCB0aGUgcmVzdWx0 aW5nIG5hbWUgaXMgcHJvY2Vzc2VkIGFzDQogICBpZiBpdCB3ZXJlIHRoZSBpbml0aWFsIG5hbWUu DQoiDQoNCg0KSmlhbmthbmcgWWFvDQoNCg0KDQoNCj5Ib3dldmVyIFNoYWRvdyB6b25lcyBjb3Vs ZCANCj4gZWxpbWluYXRlIHBlc2t5IGlzb2xhdGlvbiBsYWJlbHMgYWxsIHRvZ2V0aGVyLiA6XikN Cj4gDQo+IC1Eb3VnDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPg== From owner-namedroppers@ops.ietf.org Thu Apr 22 03:30:09 2010 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 363EB3A6A93; Thu, 22 Apr 2010 03:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[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 D7srAwM5jguZ; Thu, 22 Apr 2010 03:30:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B07D3A6A8D; Thu, 22 Apr 2010 03:30:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4tYo-0008Ai-BI for namedroppers-data0@psg.com; Thu, 22 Apr 2010 10:23:06 +0000 Received: from [131.111.8.133] (helo=ppsw-33.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4tYk-00088d-7m for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 10:23:02 +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 [93.16.204.122] (port=49221 helo=[192.168.1.89]) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1O4tYY-0004Db-BT (Exim 4.70) (return-path ); Thu, 22 Apr 2010 11:22:51 +0100 References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> Message-Id: <7B564176-9791-4A5C-8026-223EA8DD07ED@dotat.at> From: Tony Finch To: Vaggelis Segredakis In-Reply-To: <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPod Mail (7E18) Mime-Version: 1.0 (iPod Mail 7E18) Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Date: Thu, 22 Apr 2010 11:22:55 +0100 Cc: Niall O'Reilly , Andrew Sullivan , "" , Sotiris Panaretou 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 21 Apr 2010, at 10:08, "Vaggelis Segredakis" wrote: > > In this case you have to set up a mechanism that redirects all > emails to the email he considers the correct one. This could happen > by setting up the same email in each domain. What if this was the > case for each email account of a company and you had four ways of > typing the company domain name, each one of them correct, depending > on character case or set? Any decent mail server will make it easy to configure domain-level aliases with one line of configuration per domain. > What if this was the case for the domain name itself in the http > protocol? For HTTP you are better off doing a client-side redirect to the preferred domain. Again it's one line of configuration per domain. Tony. -- f.anthony.n.finch http://dotat.at/ From owner-namedroppers@ops.ietf.org Thu Apr 22 03:59:56 2010 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 02B9D3A68CD; Thu, 22 Apr 2010 03:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_40=-0.185, 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 SDKDpJVzEH+r; Thu, 22 Apr 2010 03:59:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7FA7C3A6407; Thu, 22 Apr 2010 03:59:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4u2m-000E8F-Q9 for namedroppers-data0@psg.com; Thu, 22 Apr 2010 10:54:04 +0000 Received: from [139.91.1.2] (helo=mailgate.ics.forth.gr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4u2h-000E5l-9b for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 10:53:59 +0000 X-DNSBL-MILTER: Passed Received: from webmail.ics.forth.gr (sphinx.ics.forth.gr [139.91.1.4]) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id o3MArlBA018116; Thu, 22 Apr 2010 13:53:48 +0300 (EEST) Received: from Thanatos ([139.91.88.160]) (authenticated bits=0) by webmail.ics.forth.gr (8.12.9//ICS-FORTH/V10.1.0C-EXTNULL-PLUS-SASL) with ESMTP id o3MArbqt017383; Thu, 22 Apr 2010 13:53:42 +0300 (EEST) From: "Vaggelis Segredakis" To: "'Tony Finch'" Cc: "'Niall O'Reilly'" , "'Andrew Sullivan'" , , "'Sotiris Panaretou'" References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <7B564176-9791-4A5C-8026-223EA8DD07ED@dotat.at> Subject: RE: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Date: Thu, 22 Apr 2010 13:53:28 +0300 Message-ID: <8EB8BFA76A0541248D4CA086344EAF18@ics.forth.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7B564176-9791-4A5C-8026-223EA8DD07ED@dotat.at> Thread-Index: AcriBct6JjLSazdzQxyITWOCk2M6QQAAoKEg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-j-chkmail-Score: MSGID : 4BD02ABB.000 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-ICS-JCHK-SCL: Ham 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 Tony, I have no objection that you can work around these issues on the client side. However, the IDNA and IDNA2008 protocols were created to allow users who would like to use domain names in their native character sets to do so without any strange behavior from the domain name side. Further more, I would say without extra cost and complexity. This is not the case with Greek IDNs and I think other languages as well. If you need multiple domain names to represent *each* word in your language it is necessary to get all the help you can get as a user to keep things simple and cost effective. We as a registry and many registries who have to bundle domain names will appreciate the ability of DNS to make these domains act as one on user request. This way the IDNA protocol will have the chance to really serve the users and become a useful alternative to the Latin domain names. Since the bundling option could not be a part of the IDNA2008, it was necessary to bring our request to the DNSEXT group. From our side it is obvious that the DNAME has something missing, we ask for this to be remedied with xNAME. The solution has to come from within the DNS itself so that the registry can be a part of it. Kind Regards, Vaggelis Segredakis -----Original Message----- From: Tony Finch [mailto:fanf2@hermes.cam.ac.uk] On Behalf Of Tony Finch Sent: Thursday, April 22, 2010 1:23 PM To: Vaggelis Segredakis Cc: Niall O'Reilly; Andrew Sullivan; ; Sotiris Panaretou Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work On 21 Apr 2010, at 10:08, "Vaggelis Segredakis" wrote: > > In this case you have to set up a mechanism that redirects all > emails to the email he considers the correct one. This could happen > by setting up the same email in each domain. What if this was the > case for each email account of a company and you had four ways of > typing the company domain name, each one of them correct, depending > on character case or set? Any decent mail server will make it easy to configure domain-level aliases with one line of configuration per domain. > What if this was the case for the domain name itself in the http > protocol? For HTTP you are better off doing a client-side redirect to the preferred domain. Again it's one line of configuration per domain. Tony. -- f.anthony.n.finch http://dotat.at/ From owner-namedroppers@ops.ietf.org Thu Apr 22 06:38:02 2010 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 43CFB28C14C; Thu, 22 Apr 2010 06:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.7 X-Spam-Level: X-Spam-Status: No, score=-96.7 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_50=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, 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 Sz0w5S3lNCBp; Thu, 22 Apr 2010 06:38:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 55AA83A6AC8; Thu, 22 Apr 2010 06:36:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4wSg-000LMG-8s for namedroppers-data0@psg.com; Thu, 22 Apr 2010 13:28:58 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4wSc-000LK5-VW for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 13:28:55 +0000 Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id B2A997343EA for ; Thu, 22 Apr 2010 15:28:50 +0200 (CEST) Message-ID: <4BD04F12.2060805@nic.cz> Date: Thu, 22 Apr 2010 15:28:50 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 References: <4BC720DE.8080900@nic.cz> <201004152326.o3FNQJG1088028@drugs.dv.isc.org> In-Reply-To: <201004152326.o3FNQJG1088028@drugs.dv.isc.org> 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 16.4.2010 01:26, Mark Andrews wrote: > In message<4BC720DE.8080900@nic.cz>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= writes: >> Hi, >> >> I hereby present the "other" solution to name sameness (we all call it >> CNAME+DNAME, aren't we?). It's little bit competing with BNAME >> proposal, but it should be simpler to implement. It doesn't introduce >> new RTYPE, it just loosens the singleton rule of CNAME to allow DNAME >> for the same name (we did this before with NSEC+RRSIG, remember?) > > It doesn't matter if it can be made to work with some resolvers. > It is just plain out a bad idea to change the behaviour of existing > records unless you really have no choice. With DNSSEC there was > no choice because you want to secure the CNAME record. There is a > choice here however. What I am trying to point out, that we are not changing any existing "behaviour" _in the wild_. We are just changing the specs, but existing DNS resolvers behaviour will stay same. But I differ from your view. My opinion is that we could change existing behaviour if it doesn't have any regressions and it will improve/simplify existing state of things. >> Just FYI, try digging idos.cz (or jizdnirady.cz) before you start >> writing this email and think if this proposal really breaks existing >> behaviour (if the existing resolvers are able to cope with this). > > Where's the DNAME in the response? If you want us to believe that > it works the DNAME needs to be returned. For good measure it also > has to work with a signed zone. It's relatively easy to change > named to allow a DNAME and CNAME to co-exist see > lib/dns/rbtdb.c:cname_and_other_data(). Point taken. dname.cz nameservers are running patched bind (thanks for the patch) and open XFR from any. If anybody wants more test cases or some record to be added, just ping me. I'll add DNSSEC later today. Right now the contents of the zone is: dname.cz. 60 IN SOA cool.nic.cz. hostmaster.udp53.cz. ( 3 ; serial 604800 ; refresh (1 week) 86400 ; retry (1 day) 2419200 ; expire (4 weeks) 604800 ; minimum (1 week) ) dname.cz. 60 IN NS cool.nic.cz. dname.cz. 60 IN NS ignum.nic.cz. bar.dname.cz. 60 IN CNAME foo.dname.cz. bar.dname.cz. 60 IN DNAME foo.dname.cz. foo.dname.cz. 60 IN MX 10 blackhole.nic.cz. www.foo.dname.cz. 60 IN A 217.31.205.50 www.foo.dname.cz. 60 IN AAAA 2001:1488:0:3::2 nic.dname.cz. 60 IN CNAME nic.cz. nic.dname.cz. 60 IN DNAME nic.cz. udp53.dname.cz. 60 IN CNAME udp53.cz. udp53.dname.cz. 60 IN DNAME udp53.cz. I have also configured website at conficker.nic.cz to also accept conficker.nic.dname.cz and eyechart.nic.dname.cz, if you want to test your browser/stub/resolver combo. Ondrej -- Ondřej Surý vedoucí výzkumu/R&D manager ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From owner-namedroppers@ops.ietf.org Thu Apr 22 06:46:42 2010 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 39CD63A6909; Thu, 22 Apr 2010 06:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.6 X-Spam-Level: X-Spam-Status: No, score=-97.6 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_50=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, 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 R5c1out7qSVb; Thu, 22 Apr 2010 06:46:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E4FBD3A6AFC; Thu, 22 Apr 2010 06:45:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4wfE-000O3A-Mt for namedroppers-data0@psg.com; Thu, 22 Apr 2010 13:41:56 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4wfB-000O2h-R1 for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 13:41:54 +0000 Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id C343E73C13B; Thu, 22 Apr 2010 15:41:47 +0200 (CEST) Message-ID: <4BD0521B.9090803@nic.cz> Date: Thu, 22 Apr 2010 15:41:47 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: George Barwood CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 References: <4BC720DE.8080900@nic.cz> <5C8B7499CFD24579BD7B75CB8050FDA1@local> In-Reply-To: <5C8B7499CFD24579BD7B75CB8050FDA1@local> 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: George, On 18.4.2010 08:02, George Barwood wrote: > Ondrej > I have looked at this proposal. Thanks for your comments. > I think maybe you need to clarify > what is returned in response to DNAME and ANY queries with owner matching > the DNAME record ( answer : only the CNAME is returned, I think ). Well, I think that existing behaviour is already OK: ondrej@ookami:~$ dig IN ANY bar.dname.cz @cool.nic.cz bar.dname.cz. CNAME foo.dname.cz. bar.dname.cz. DNAME foo.dname.cz. ondrej@ookami:~$ dig IN DNAME bar.dname.cz @cool.nic.cz bar.dname.cz. DNAME foo.dname.cz. ondrej@ookami:~$ dig IN CNAME bar.dname.cz @cool.nic.cz bar.dname.cz. CNAME foo.dname.cz. But I agree that it deserves clarification. > Also, is it the case that the CNAME and DNAME MUST agree, I don't understand what you mean here, can you clarify? > NSEC, NSEC3 CNAME and DNAME bits are set in NSEC and NSEC3. I don't think that this changes anything from current state. > However, from a zone administration point of view, BNAME is simpler. Is it? I would agree that BNAME would be simpler if it would replace CNAME and DNAME, and not complement them. BNAME alone is simpler, but CNAME+DNAME+BNAME is not (at least in my eyes). But after all it's just matter of presentation layer - the registrar could offer the registrant an option to create full alias and it would expand to CNAME+DNAME in the provisioning system. > I therefore suggest the possibility of BNAME in the unsigned zone file, > BNAME+CNAME+DNAME in the signed zone file and CNAME+DNAME on the wire > as an interim measure, allowing compatibility with existing validating > resolvers until BNAME is implemented by clients. [...stripped the table...] I have looked at your table and it seems to me that you have demonstrated that there is no real need for BNAME, if you can easily replace it with CNAME+DNAME combo. But I understand your point, I am just not convinced that it's a right way to go. Ondrej -- Ondřej Surý vedoucí výzkumu/R&D manager ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From owner-namedroppers@ops.ietf.org Thu Apr 22 06:50:16 2010 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 46FC128C159; Thu, 22 Apr 2010 06:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.9 X-Spam-Level: X-Spam-Status: No, score=-97.9 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_50=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, 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 ltKTqSRF-8Vl; Thu, 22 Apr 2010 06:50:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A5F128C168; Thu, 22 Apr 2010 06:48:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4wiC-000Onj-Eh for namedroppers-data0@psg.com; Thu, 22 Apr 2010 13:45:00 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4wiA-000OkW-3o for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 13:44:58 +0000 Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 15AB27342A4; Thu, 22 Apr 2010 15:44:52 +0200 (CEST) Message-ID: <4BD052D3.5080704@nic.cz> Date: Thu, 22 Apr 2010 15:44:51 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mark Andrews CC: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 References: <201004160145.o3G1j6cq090668@drugs.dv.isc.org> In-Reply-To: <201004160145.o3G1j6cq090668@drugs.dv.isc.org> 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 16.4.2010 03:45, Mark Andrews wrote: > And if one is relaxing CNAME and other data rules then NS and SOA > are also obvious candidates. Sounds interesting. I am little afraid that this could have bigger impact than just allowing CNAME+DNAME. But let me think of it for some time and I'll try to do some testing. Another thing I am afraid of is that allowing CNAME+DNAME in the zone apex is "too radical" for dnsext, so it might kill the lighter proposal for CNAME+DNAME. You can always put CNAME+DNAME to a parent zone. Ondrej -- Ondřej Surý vedoucí výzkumu/R&D manager ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From owner-namedroppers@ops.ietf.org Thu Apr 22 08:05:45 2010 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 6FA1028C19D; Thu, 22 Apr 2010 08:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.05 X-Spam-Level: X-Spam-Status: No, score=-98.05 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_50=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, 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 WTMK8sV4h9+5; Thu, 22 Apr 2010 08:05:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EEFB828C134; Thu, 22 Apr 2010 08:05:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4xum-000HZx-LY for namedroppers-data0@psg.com; Thu, 22 Apr 2010 15:02:04 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4xug-000HWI-3t for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 15:01:58 +0000 Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id F2860734398; Thu, 22 Apr 2010 17:01:56 +0200 (CEST) Message-ID: <4BD064E4.9060700@nic.cz> Date: Thu, 22 Apr 2010 17:01:56 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: George Barwood CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 References: <4BC720DE.8080900@nic.cz> <5C8B7499CFD24579BD7B75CB8050FDA1@local> <4BD0521B.9090803@nic.cz> <986F4044CBEE422BB769C7BA94B90BF2@local> In-Reply-To: <986F4044CBEE422BB769C7BA94B90BF2@local> 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 22.4.2010 16:46, George Barwood wrote: > > ----- Original Message ----- > From: "Ondřej Surý" > To: "George Barwood" > Cc: > Sent: Thursday, April 22, 2010 2:41 PM > Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 > > >> George, >> >> On 18.4.2010 08:02, George Barwood wrote: >>> Ondrej >>> I have looked at this proposal. >> >> Thanks for your comments. >> >> >>> I think maybe you need to clarify >>> what is returned in response to DNAME and ANY queries with owner matching >>> the DNAME record ( answer : only the CNAME is returned, I think ). >> >> Well, I think that existing behaviour is already OK: >> >> ondrej@ookami:~$ dig IN ANY bar.dname.cz @cool.nic.cz >> bar.dname.cz. CNAME foo.dname.cz. >> bar.dname.cz. DNAME foo.dname.cz. >> >> ondrej@ookami:~$ dig IN DNAME bar.dname.cz @cool.nic.cz >> bar.dname.cz. DNAME foo.dname.cz. >> >> ondrej@ookami:~$ dig IN CNAME bar.dname.cz @cool.nic.cz >> bar.dname.cz. CNAME foo.dname.cz. >> >> But I agree that it deserves clarification. > > Well we disagree here a bit. I was expecting just the CNAME to be returned in every case, > my thinking is that the CNAME matching takes precedence over everything else, and > once the CNAME is found, no other processing is performed. Nope, that would be different behaviour for RRSIG/NSEC/NSEC3 and DNAME. Try: $ dig +norec IN ANY www.udp53.cz @rfc1034.udp53.cz. [...] $ dig +norec IN CNAME www.udp53.cz @rfc1034.udp53.cz. [...] $ dig +norec IN RRSIG www.udp53.cz @rfc1034.udp53.cz. [...] $ dig +norec IN NSEC www.udp53.cz @rfc1034.udp53.cz. [...] Answers are stripped to not clutter this list. >>> Also, is it the case that the CNAME and DNAME MUST agree, >> >> I don't understand what you mean here, can you clarify? > > I mean is it legal to have > > bar.dname.cz CNAME foo1.dname.cz. > bar.dname.cz. DNAME foo2.dname.cz. Yes, why not? There could be possible a warning in named-checkzone (and other check tools), but it's perfectly legal in my view. >>> However, from a zone administration point of view, BNAME is simpler. >> >> Is it? I would agree that BNAME would be simpler if it would replace >> CNAME and DNAME, and not complement them. BNAME alone is simpler, but >> CNAME+DNAME+BNAME is not (at least in my eyes). >> >> But after all it's just matter of presentation layer - the registrar >> could offer the registrant an option to create full alias and it would >> expand to CNAME+DNAME in the provisioning system. > > Right, that is certainly an option. Which is better is a matter of judgement. > If we were starting from scratch, BNAME would be best. Ok, we agree on that. > From where we are, I don't know. Well, my proposal is just two hunk patch in bind9 and I guess for nsd (and others) it would be same amount of work. It's compatible with current resolvers (althought more testing is needed). BNAME proposal needs new RRTYPE allocated by IANA and implemented in all resolvers (with new logic) and all authoritative servers. >>> I therefore suggest the possibility of BNAME in the unsigned zone file, >>> BNAME+CNAME+DNAME in the signed zone file and CNAME+DNAME on the wire >>> as an interim measure, allowing compatibility with existing validating >>> resolvers until BNAME is implemented by clients. >> [...stripped the table...] >> >> I have looked at your table and it seems to me that you have >> demonstrated that there is no real need for BNAME, if you can easily >> replace it with CNAME+DNAME combo. >> >> But I understand your point, I am just not convinced that it's a right >> way to go. > > I was only proposing this as a possibility to be considered. > I'm not expressing an opinion on which way is best. Ok, thanks for all your comments. > I would like to see a "clean" solution, even if it takes a long while to get there. Here it depends what each of us consider to be "clean" :). I don't mind changing protocol if it maintains backwards compatibility and I still consider it to be "clean". Ondrej -- Ondřej Surý vedoucí výzkumu/R&D manager ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From owner-namedroppers@ops.ietf.org Thu Apr 22 08:13:23 2010 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 1B11628C143; Thu, 22 Apr 2010 08:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.904 X-Spam-Level: X-Spam-Status: No, score=-2.904 tagged_above=-999 required=5 tests=[AWL=-1.095, BAYES_05=-1.11, 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 kWCtKmt0Gcee; Thu, 22 Apr 2010 08:13:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 18F573A6B76; Thu, 22 Apr 2010 08:12:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4y1L-000J5g-Es for namedroppers-data0@psg.com; Thu, 22 Apr 2010 15:08:51 +0000 Received: from [131.111.8.132] (helo=ppsw-32.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4y1I-000J5O-Mm for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 15:08:49 +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-2.csi.cam.ac.uk ([131.111.8.54]:47311) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1O4y17-0005KP-Bg (Exim 4.70) (return-path ); Thu, 22 Apr 2010 16:08:37 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1O4y17-00017e-JY (Exim 4.67) (return-path ); Thu, 22 Apr 2010 16:08:37 +0100 Date: Thu, 22 Apr 2010 16:08:37 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Vaggelis Segredakis cc: 'Niall O'Reilly' , 'Andrew Sullivan' , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Subject: RE: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-Reply-To: <8EB8BFA76A0541248D4CA086344EAF18@ics.forth.gr> Message-ID: References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <7B564176-9791-4A5C-8026-223EA8DD07ED@dotat.at> <8EB8BFA76A0541248D4CA086344EAF18@ics.forth.gr> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) 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: On Thu, 22 Apr 2010, Vaggelis Segredakis wrote: > > I have no objection that you can work around these issues on the client > side. However, the IDNA and IDNA2008 protocols were created to allow users > who would like to use domain names in their native character sets to do so > without any strange behavior from the domain name side. Further more, I > would say without extra cost and complexity. I was under the impression that the point of IDNA was that application software has to do the work, not the DNS :-) There's no way that a new feature in the DNS can trigger the kinds of application-level redirects that you asked about. Your question might be more properly directed at the IMA working group for email; I'm not sure where would be right for HTTP. I note that in the 1980s, SMTP clients were required to canonicalize domain names by resolving CNAME records. This practice was dropped in the 1990s. Current practise is that MXs must be aware of all the domains that they wish to accept email for, including CNAME aliases, and these will typically be configured explicitly. HTTP name-based virtual hosting is in a similar situation to email. With IP-based virtual hosting the HTTP server doesn't need to care about what name it is called by; however there are a number of reasons it is better for the server to redirect requests to the preferred spelling: to ensure that bookmarks and links from other pages use the preferred name; to avoid duplicate entries in caches; to simplify x.509 certificate requirements; etc. Having said that, perhaps the DNS can be used to simplify the server-side configuration. Instead of explicitly configuring all the aliases for a domain, the server could be configured to accept any BNAME pointing at the preferred name. (This is different from the old SMTP CNAME canonicalization since it's opt-in for each server that wishes to support it, rather that being globally (un)implemented by clients.) Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From owner-namedroppers@ops.ietf.org Thu Apr 22 08:38:54 2010 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 A1D1C3A6B91; Thu, 22 Apr 2010 08:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.124 X-Spam-Level: X-Spam-Status: No, score=-0.124 tagged_above=-999 required=5 tests=[AWL=-0.524, 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 HWLI1XyDDM9W; Thu, 22 Apr 2010 08:38:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B1FC53A6B61; Thu, 22 Apr 2010 08:38:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4yPK-000Oru-QD for namedroppers-data0@psg.com; Thu, 22 Apr 2010 15:33:38 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4yPI-000OrW-6y for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 15:33:36 +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 878191ECB400 for ; Thu, 22 Apr 2010 15:33:34 +0000 (UTC) Date: Thu, 22 Apr 2010 11:33:32 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Use the layers, Luke! Message-ID: <20100422153332.GE1362@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF440F.1090501@ucd.ie> <20100421195653.GD912@shinkuro.com> <4BCF78DC.4000405@ucd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4BCF78DC.4000405@ucd.ie> 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, Apr 21, 2010 at 11:14:52PM +0100, Niall O'Reilly wrote: > Would you attach even more importance to alignment of a solution to the > needs of an actual user population? Yes. And I'm with you so far. > http://www.ίδρυματεχνολογίασέρευνασ.gr/ > http://www.xn--ixadahbbkgke5djpgxb1al0bfgtp0b.gr/ > > is one element of an eight-fold bundle, actually in use, > but implemented (IIUC) as a four-fold bundle to save on overhead. Right. I understand the problem. What I do not understand is what it is we're supposed to be able to do about it. > Vaggelis has told us that he sees BNAME as a better solution for what > he has to deal with already today > than the awkward current solution of using DNAME with apex (not zone > apex, but DNAME apex) back-filling. And I want to know how it's better. The BNAME at xn--ixadahbbkgke5djpgxb1al0bfgtp0b.gr is going to occlude things underneath it, I think. If that's right, then what does one do with xn--ixadahbbkgke5djpgxb1al0bfgtp0b.xn--ixadahbbkgke5djpgxb1al0bfgtp0b.gr? Does this work out to be a combinatorial explosion anyway? If so, would it be better to work on improved provisioning tools, so that provisioning with the DNAME+back-filling approach (which is what's possible today) is just easier? This latter approach has the notable benefit that exactly zero additional deployed resolvers need to be upgraded to make it work. It isn't plain to me how that will be the case for BNAME. Note that a resolver that only undersntands CNAME might get annoyed by a BNAME, since the BNAME is at the same name as the CNAME, and that's not supposed to be allowed. Moreover, we have a DNSSEC problem with BNAME, because we have existing deployed validators that know nothing about BNAME. If we use the same signing approach as was used with DNAME, then, we might expect validation failures. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Apr 22 09:48:19 2010 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 624DF3A6BE6; Thu, 22 Apr 2010 09:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.356 X-Spam-Level: X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_50=0.001, 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 hH3hYt-0qq-I; Thu, 22 Apr 2010 09:48:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7CC2328C143; Thu, 22 Apr 2010 09:48:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4zVM-000FF9-OA for namedroppers-data0@psg.com; Thu, 22 Apr 2010 16:43:56 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4zVF-000FCN-Eu for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 16:43:49 +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 <0L1A00K01EAXBO00@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 17:43:47 +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 <0L1A00I8BEGYP600@dakota.ucd.ie>; Thu, 22 Apr 2010 17:43:47 +0100 (IST) Date: Thu, 22 Apr 2010 17:43:46 +0100 From: Niall O'Reilly Subject: Re: [dnsext] Re: Use the layers, Luke! In-reply-to: <20100422153332.GE1362@shinkuro.com> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Message-id: <4BD07CC2.7050103@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF440F.1090501@ucd.ie> <20100421195653.GD912@shinkuro.com> <4BCF78DC.4000405@ucd.ie> <20100422153332.GE1362@shinkuro.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) 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 22/04/10 16:33, Andrew Sullivan wrote: > On Wed, Apr 21, 2010 at 11:14:52PM +0100, Niall O'Reilly wrote: [...] >> Vaggelis has told us that he sees BNAME as a better solution for >> what he has to deal with already today than the awkward current >> solution of using DNAME with apex (not zone apex, but DNAME apex) >> back-filling. > > And I want to know how it's better. The BNAME at > xn--ixadahbbkgke5djpgxb1al0bfgtp0b.gr is going to occlude things > underneath it, I think. If that's right, then what does one do with > xn--ixadahbbkgke5djpgxb1al0bfgtp0b.xn--ixadahbbkgke5djpgxb1al0bfgtp0b.gr? > Does this work out to be a combinatorial explosion anyway? If the BNAME were used in the parent zone as a pseudo-delegation, only the canonical zone instance would need to be maintained and supported, rather than all the stub-apices carrying SOA/NS/DNAME (DNS metadata) and possibly A/AAAA/MX/whatnot (node data) which are needed today. With BNAME, each additional member of the bundle would require just one extra BNAME RR, not an extra zone. With cascaded bundled zones, delegation would only needed from each canonical zone to the child canonical zone. This promises to avoid the combinatorial explosion. > If so, > would it be better to work on improved provisioning tools, so that > provisioning with the DNAME+back-filling approach (which is what's > possible today) is just easier? At scale, I doubt it. At some stage, and I don't know where the break point would lie, a large number of lightweight zones just becomes too heavy. Moreover, distance from the root, measured by label count, increases the burden of the combinatorial effect. I suggest that distance from the root is probably also strongly correlated with dilution of clue and scarcity of resources. Thus, the burden would fall on those least prepared to bear it. > This latter approach has the notable > benefit that exactly zero additional deployed resolvers need to be > upgraded to make it work. It isn't plain to me how that will be the > case for BNAME. Mark Andrews seems to thing that tailoring the response according to an opt-in flag in the query is enough to make BNAME fly, and to allow appropriate assistance to be offered to BNAME-ignorant resolvers. >> Note that a resolver that only undersntands CNAME might get annoyed by > a BNAME, since the BNAME is at the same name as the CNAME, and that's > not supposed to be allowed. Moreover, we have a DNSSEC problem with > BNAME, because we have existing deployed validators that know nothing > about BNAME. If we use the same signing approach as was used with > DNAME, then, we might expect validation failures. I think MarkA has addressed all of this in a recent message. ATB Niall O'Reilly From owner-namedroppers@ops.ietf.org Thu Apr 22 10:12:04 2010 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 95F3E3A68B3; Thu, 22 Apr 2010 10:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[AWL=-0.503, 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 Q6Wmv4R6wyRL; Thu, 22 Apr 2010 10:12:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 39AD13A69BA; Thu, 22 Apr 2010 10:11:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4zsR-000KjN-Gm for namedroppers-data0@psg.com; Thu, 22 Apr 2010 17:07:47 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4zsN-000Kip-Mq for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 17:07:43 +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 6C9301ECB400 for ; Thu, 22 Apr 2010 17:07:42 +0000 (UTC) Date: Thu, 22 Apr 2010 13:07:40 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Use the layers, Luke! Message-ID: <20100422170740.GJ1362@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF440F.1090501@ucd.ie> <20100421195653.GD912@shinkuro.com> <4BCF78DC.4000405@ucd.ie> <20100422153332.GE1362@shinkuro.com> <4BD07CC2.7050103@ucd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD07CC2.7050103@ucd.ie> 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, Apr 22, 2010 at 05:43:46PM +0100, Niall O'Reilly wrote: > If the BNAME were used in the parent zone as a pseudo-delegation, > only the canonical zone instance would need to be maintained and > supported, rather than all the stub-apices carrying SOA/NS/DNAME > (DNS metadata) and possibly A/AAAA/MX/whatnot (node data) which are > needed today. But if you did this on the parent side of the zone cut with DNAME and A and AAAAs for the synonyms, why wouldn't that work as well? Note that in this case, the A and AAAA isn't glue: it's authoritative data in the parent, I think. (The A and AAAA are only needed so that direct lookups for, say, http://synonym, rather than e.g. http://www.synonym, will work.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Apr 22 10:28:03 2010 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 DC1F73A692C; Thu, 22 Apr 2010 10:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=-0.491, 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 nYxSYg537efI; Thu, 22 Apr 2010 10:28:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC3B93A6C04; Thu, 22 Apr 2010 10:19:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4zzu-000Mul-8a for namedroppers-data0@psg.com; Thu, 22 Apr 2010 17:15:30 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O4zzq-000MtG-6a for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 17:15: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 55FE31ECB400 for ; Thu, 22 Apr 2010 17:15:23 +0000 (UTC) Date: Thu, 22 Apr 2010 13:15:21 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: BNAME, Synthesized CNAME, and DNSSEC (was: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work) Message-ID: <20100422171521.GK1362@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201004212314.o3LNEQKl069128@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: No hat. On Thu, Apr 22, 2010 at 09:14:26AM +1000, Mark Andrews wrote: > just do the same thing when we introduce BNAME. i.e. use DNSSEC > algorithms to signal if the zone may contain a BNAME and only those > validators that understand BNAME will treat it as secure. Everyone > else will treat the zones as insecure. I find it a little strange that on the one hand we've had people wringing their hands about us potentially running out of algorithm numbers, and on the other hand we're prepared to use up twice as many numbers as we have allocated on the day a new RRTYPE of this sort is used. I'm not saying that's the wrong answer, but surely all the people who were uncomfortable with the algorithm allocation document are going to be unhappy with the above answer too, right? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Apr 22 11:20:27 2010 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 B0BF23A6A6C; Thu, 22 Apr 2010 11:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.565 X-Spam-Level: X-Spam-Status: No, score=-4.565 tagged_above=-999 required=5 tests=[AWL=0.483, 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 XDODhap2K2JK; Thu, 22 Apr 2010 11:20:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3D79E3A6BF2; Thu, 22 Apr 2010 11:13:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O50pP-0009Kd-8b for namedroppers-data0@psg.com; Thu, 22 Apr 2010 18:08:43 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O50pM-0009KD-Sv for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 18:08:41 +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 <0L1A00301I918800@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 19:08:38 +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 <0L1A00I9HIEEP700@dakota.ucd.ie>; Thu, 22 Apr 2010 19:08:38 +0100 (IST) Date: Thu, 22 Apr 2010 19:08:37 +0100 From: Niall O'Reilly Subject: Re: [dnsext] Re: Use the layers, Luke! In-reply-to: <20100422170740.GJ1362@shinkuro.com> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Message-id: <4BD090A5.9040704@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF440F.1090501@ucd.ie> <20100421195653.GD912@shinkuro.com> <4BCF78DC.4000405@ucd.ie> <20100422153332.GE1362@shinkuro.com> <4BD07CC2.7050103@ucd.ie> <20100422170740.GJ1362@shinkuro.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) 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 22/04/10 18:07, Andrew Sullivan wrote: > On Thu, Apr 22, 2010 at 05:43:46PM +0100, Niall O'Reilly wrote: > >> If the BNAME were used in the parent zone as a pseudo-delegation, >> only the canonical zone instance would need to be maintained and >> supported, rather than all the stub-apices carrying SOA/NS/DNAME >> (DNS metadata) and possibly A/AAAA/MX/whatnot (node data) which are >> needed today. > > But if you did this on the parent side of the zone cut with DNAME and > A and AAAAs for the synonyms, why wouldn't that work as well? Note > that in this case, the A and AAAA isn't glue: it's authoritative data > in the parent, I think. (The A and AAAA are only needed so that > direct lookups for, say, http://synonym, rather than e.g. > http://www.synonym, will work.) 1x zone update (n-1)x transaction request to parent Parental latency and clumsiness Ask any teenager! 8-) ATB Niall O'Reilly From owner-namedroppers@ops.ietf.org Thu Apr 22 11:31:55 2010 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 E44443A6BB2; Thu, 22 Apr 2010 11:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=0.717, BAYES_20=-0.74, 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 jahC7zyNG-bK; Thu, 22 Apr 2010 11:31:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 653D528C224; Thu, 22 Apr 2010 11:24:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O510j-000C9E-Tk for namedroppers-data0@psg.com; Thu, 22 Apr 2010 18:20:25 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O510h-000C8i-Kb for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 18:20:23 +0000 Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id DF8ACA9452A; Thu, 22 Apr 2010 18:20:21 +0000 (UTC) Message-ID: <4BD09365.508@mail-abuse.org> Date: Thu, 22 Apr 2010 11:20:21 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mark Andrews CC: Vaggelis Segredakis , 'Niall O'Reilly' , 'Andrew Sullivan' , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <4BCF967A.3000109@mail-abuse.org> <201004220102.o3M124ht097291@drugs.dv.isc.org> <4BCFBA6C.5000607@mail-abuse.org> <201004220401.o3M41mmK002880@drugs.dv.isc.org> In-Reply-To: <201004220401.o3M41mmK002880@drugs.dv.isc.org> 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 4/21/10 9:01 PM, Mark Andrews wrote: > In message <4BCFBA6C.5000607@mail-abuse.org>, Douglas Otis writes: > > It seems most domains are fairly flat, but this seem to suggest a > > departure from current practices of being flat and referencing MX > > records at zone apexes. > > No, it doesn't. I am confused then and need your help. > > For example, take the domain "example.com." Most domains locate > > MX records at the zone apex, where in this instance, it would be > > at "example.com." It would not be practical to place a BNAME in > > ".com" which needs to contain NS records for delegation. > > Why not? It should be no harder to add BNAME records to com once > the servers support BNAME than it is to add NS records. Doesn't section 3.3 rule 2 exclude this possibility? There are 13 NS records at ".com" pointing to root name servers? What would it mean to have just a CNAME at ".com" and wouldn't an aliased domain still need to include resources that will exclude CNAME or BNAME? What am I missing? 3.3. The BNAME Rules There are two rules which governs the use of BNAMEs in a zone file. The first one is that there SHOULD be no descendants under the owner of the BNAME. The second one is that _no_ resource records can co- exist with the BNAME for the same name. (except resources for DNSSEC). > > But BNAME could reside in a sub-domain of say "2.example.net" to > > be BNAME aliased with "example.com." is that right? So... > > You are making this much more complicated than it really is. Resource records at zone apexes will exclude inclusion of BNAME RR and will also prevent any language specific descendants down this path. This would suggest BNAME requires conventions for resource isolation labels of perhaps always using numbers such as "200" to reference email, "201" to reference http, "202" to reference SRV, etc. Conventions to allow users a means to guess the locations of redirected services, much like "www" locates http, other services being redirected will then need conventions specific for each language, or perhaps this could be number based. By making it numbers based, BNAME would not needed, and just DNAME could be used. IMHO, the shadow draft appears able to deal with existing practices, and BNAME does not. In addition, BNAME works against having a flatter name space and being able to use the zone apex for locating services such as email, im, etc. -Doug From nitcoindore@airtelbroadband.in Thu Apr 22 11:40:28 2010 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 1E35A28C21E for ; Thu, 22 Apr 2010 11:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.805 X-Spam-Level: X-Spam-Status: No, score=-18.805 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, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, 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_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_FORGED_AMAZON=3, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, 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 vbCIp-FuuhYb for ; Thu, 22 Apr 2010 11:40:19 -0700 (PDT) Received: from h109-187-19-174.dyn.bashtel.ru (h109-187-19-174.dyn.bashtel.ru [109.187.19.174]) by core3.amsl.com (Postfix) with SMTP id C38073A6C30 for ; Thu, 22 Apr 2010 11:33:38 -0700 (PDT) From: "Amazon.com Email Subscriptions" To: "dnsext-archive@ietf.org" Subject: Amazon.com Deal of the Day X-AMAZON-MAIL-RELAY-TYPE: subscription X-AMAZON-RTE-VERSION: 2.0 MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100422183344.C38073A6C30@core3.amsl.com> Date: Thu, 22 Apr 2010 11:33:38 -0700 (PDT)
Please click here if the e-mail below is not displayed correctly.
amazon.com
Free Two-Day Shipping with   › Amazon Prime
Your Amazon.com Today's Deals See All Departments
Tiffen Dfx Digital Filter Software V2
$149.95 $79.99 (47% off)
4.28571428571429
This Tiffen Dfx digital filter suite is a powerful but user-friendly stand alone application for still images. It offers a definitive set of digital optical filters, including simulations of many popular award-winning Tiffen glass filters, specialized lenses, optical lab processes, film grain, exacting color correction plus natural light and photographic effects, all in a controlled digital environment. Whether you are an amateur or professional photographer, a video or film editor, or graphic designer, Dfx's visual workflow and easy to use tools will help you create stunning images. Windows XP, Vista or Macintosh v10.4.6 and higher required for use.
Explore Other Great Gold Box Deals
Save $20 on Adobe Photoshop Elements 8
Great gift for Mom! Dbest Quick Cart
Lunar: Silver Star Harmony Limited Edition for $25.98
100 Albums for $5 Each
Save $20 on Adobe Photoshop Elements 8
$99.99 $59.99 (40% off)
 
 
Great gift for Mom! Dbest Quick Cart
$34.95 $29.99 (14% off)
 
 
Lunar: Silver Star Harmony Limited Edition for $25.98
$39.99 $25.98 (35% off)
 
 
100 Albums for $5 Each
 
Save up to $500 off the combined purchase of select Canon cameras and printers
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
Save $10 on "Alice in Wonderland Combo Pack"
Save up to 40% on Our Bestselling Fitness Products
Save up to $500 off the combined purchase of select Canon cameras and printers
 
 
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
 
 
Save $10 on "Alice in Wonderland Combo Pack"
 
 
Save up to 40% on Our Bestselling Fitness Products
 


This message was sent to the following e-mail address: dnsext-archive@ietf.org

You're receiving this e-mail because you subscribed to Gold Box Deals. If you do not want any more e-mails of this kind, it's easy to unsubscribe.

Please note that product prices and availability are subject to change. Prices and availability were accurate at the time this newsletter was sent; however, they may differ from those you see when you visit Amazon.com. The List Price represents the full retail price listed on the product itself, suggested by the manufacturer or supplier, or estimated in accordance with standard industry practice. For items offered as a set, List Price may represent open-stock prices.

© 2010 Amazon.com. All rights reserved.
Amazon.com is a registered trademark of Amazon.com, Inc.
Amazon.com, 1200 12th Ave. S., Suite 1200, Seattle, WA 98144-2734.
Reference: 15067840
From owner-namedroppers@ops.ietf.org Thu Apr 22 11:57:07 2010 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 A459C28C1F3; Thu, 22 Apr 2010 11:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.756 X-Spam-Level: X-Spam-Status: No, score=0.756 tagged_above=-999 required=5 tests=[AWL=-1.663, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 8+AgKakaPtwU; Thu, 22 Apr 2010 11:57:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D19D23A6C38; Thu, 22 Apr 2010 11:36:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O51BE-000Ead-VB for namedroppers-data0@psg.com; Thu, 22 Apr 2010 18:31:16 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O51BB-000EZb-E5 for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 18:31:13 +0000 Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3MIV8EC033027; Thu, 22 Apr 2010 14:31:08 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4BD095E9.60008@ogud.com> Date: Thu, 22 Apr 2010 14:31:05 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: George Barwood CC: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: [dnsext] RFC 4035 section 3.1.6 - security hole? References: <7AB16A29015644F48753C982367B5F0E@local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 20/04/2010 6:05 PM, George Barwood wrote: > > ----- Original Message ----- > From: "Edward Lewis" > To: "George Barwood" > Cc: > Sent: Tuesday, April 20, 2010 7:59 PM > Subject: Re: [dnsext] RFC 4035 section 3.1.6 - security hole? > > >> At 19:15 +0100 4/20/10, George Barwood wrote: >> >>> Why this odd exception? It's certainly not hard. >> >> 1. The goal is to protect the data from the signer to the validator. >> A server acting in an authoritative role (= setting the AD bit) >> doesn't need to care. > > Agreed. But if the server is responding to a recursive query ( RD=1 ), > it should validate ( if it is a validating resolver ). If stub is asking a mixed-mode DNS responder (i.e. both authoritative and recursive) the stub has no idea if RD=1 or RD=0 is more appropriate for each question, for that reason it will always use RD=1. > >> 2. Validating what could be millions of signatures when loading a >> zone from disk takes a while. > > There is no need to do that. If a server is authoritative for a large > zone, it probably shouldn't be offering recursive service, except perhaps > to itself and possibly a very limited set of local clients. Certainly not to a > large number of clients, which could generate a large validation load. > Signatures need only be validated on demand. > > To be clear : if RD=0, validation does not happen. That's authoritative service. > Validation is not expected or desired. If RD=1, validation must happen, if the server > is a validating server, in my view. See comment above, why does authoritative server have to validate data just because a query arrives with RD=1? > > An example where this would be important if where a server wishes to authenticate > a software upgrade using a certificate published securely in the DNS. It's bad if the > validation doesn't happen simply because the server in question is a slave for the > zone in question. That would probably cause the upgrade to abort ( since AD = 0 ), > causing general chaos. > >> 3. As far as zone transfers, use of TSIG or VPN or secure file >> transfers are a lot more efficient than individual verifications. > > Those are link-level secure. The objective of DNSSEC is end-to-end security. > To verify that the data is what was signed. If say the master server has been > compromised, TSIG and VPN won't help. > Yes if the distribution server is compromised all bets are off IFF zone is unsigned or master server contains private part of the zone signing key. >> I'd encourage you to look at this page: >> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2001/threads.html >> >> and pull up all of the messages with this in the subject line: >> I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt >> >> There are 80 of them. > > I looked at about 20 or so quickly. > Obviously this was a contentious issue for some reason that I cannot fathom. > It's quite bizarre to have end-to-end security with unpredictable exceptions. > Hopefully no actual implementations do this, I'd certainly classify it as a major security bug. please explain clearly what you can not fathom? Until you clearly state what exactly the issue is it is hard to accept your assessment that this is "a major security issue". Olafur From owner-namedroppers@ops.ietf.org Thu Apr 22 15:18:06 2010 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 05D043A6908; Thu, 22 Apr 2010 15:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.422, 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 cUyaFnoDCys2; Thu, 22 Apr 2010 15:18:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 84A9E3A6969; Thu, 22 Apr 2010 15:18:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O54bn-000Apt-5G for namedroppers-data0@psg.com; Thu, 22 Apr 2010 22:10:55 +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.71 (FreeBSD)) (envelope-from ) id 1O54bk-000AoA-Su for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 22:10:52 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A2FAEA2EB3 for ; Thu, 22 Apr 2010 22:10:51 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: CNAME Issue - Whether to use CNAME-data or Response-Flag In-Reply-To: Your message of "Thu, 22 Apr 2010 09:36:55 +1000." <201004212336.o3LNat6K081644@drugs.dv.isc.org> References: <201004212336.o3LNat6K081644@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 22 Apr 2010 22:10:51 +0000 Message-ID: <50262.1271974251@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, 22 Apr 2010 09:36:55 +1000 > From: Mark Andrews > ... > * The IETF updated RFC 1034 so that authoritative servers to not follow > CNAME if recursion is not desired. Then misconfigurations like this > will not be visible. s/not desired/either not desired or not available/. From owner-namedroppers@ops.ietf.org Thu Apr 22 16:13:34 2010 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 EDA963A689B; Thu, 22 Apr 2010 16:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.346, 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 u7788EKL6Ugg; Thu, 22 Apr 2010 16:13:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E6C263A6783; Thu, 22 Apr 2010 16:13:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O55W3-000MRU-Sf for namedroppers-data0@psg.com; Thu, 22 Apr 2010 23:09:03 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O55W1-000MQv-DT for namedroppers@ops.ietf.org; Thu, 22 Apr 2010 23:09:01 +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 1C241E9308; Thu, 22 Apr 2010 23:08:59 +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 o3MN8j31068013; Fri, 23 Apr 2010 09:08:47 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004222308.o3MN8j31068013@drugs.dv.isc.org> To: Douglas Otis Cc: Vaggelis Segredakis , "'Niall O'Reilly'" , "'Andrew Sullivan'" , namedroppers@ops.ietf.org, "'Sotiris Panaretou'" From: Mark Andrews References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <4BCF967A.3000109@mail-abuse.org> <201004220102.o3M124ht097291@drugs.dv.isc.org> <4BCFBA6C.5000607@mail-abuse.org> <201004220401.o3M41mmK002880@drugs.dv.isc.org> <4BD09365.508@mail-abuse.org> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work In-reply-to: Your message of "Thu, 22 Apr 2010 11:20:21 MST." <4BD09365.508@mail-abuse.org> Date: Fri, 23 Apr 2010 09:08:45 +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 <4BD09365.508@mail-abuse.org>, Douglas Otis writes: > On 4/21/10 9:01 PM, Mark Andrews wrote: > > In message <4BCFBA6C.5000607@mail-abuse.org>, Douglas Otis writes: > > > It seems most domains are fairly flat, but this seem to suggest a > > > departure from current practices of being flat and referencing MX > > > records at zone apexes. > > > > No, it doesn't. > > I am confused then and need your help. > > > > For example, take the domain "example.com." Most domains locate > > > MX records at the zone apex, where in this instance, it would be > > > at "example.com." It would not be practical to place a BNAME in > > > ".com" which needs to contain NS records for delegation. > > > > Why not? It should be no harder to add BNAME records to com once > > the servers support BNAME than it is to add NS records. > > Doesn't section 3.3 rule 2 exclude this possibility? There are 13 NS > records at ".com" pointing to root name servers? What would it mean to > have just a CNAME at ".com" When you buy a .COM domain you would get the choice of adding NS records for .COM *or* adding a BNAME for .COM. You don't add *both* NS records and a BNAME. Adding a BNAME would remove the NS records from the COM zone, adding a NS RRset would remove the BNAME from the COM zone. This is not rocket science. It does require registries and registrars to update their processes but that is nothing new. AAAA and DNSSEC required updates to the processes. > and wouldn't an aliased domain still need to > include resources that will exclude CNAME or BNAME? What am I missing? I can't think of any records that would be needed. There is no glue required for a BNAME. You would be dependent on COM being signed if you wanted .COM to be signed rather than being able to sign it yourself. A signed BNAME takes less resources than a signed delegation and would be roughly equivalent to a unsigned delegation once you add up the multiple NS records and glue. BNAME + RRSIG(BNAME) + NSEC{3} + RRSIG(NSEC{3}) NS + DS + RRSIG(DS) + NSEC{3} + RRSIG(NSEC{3}) 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 Apr 22 17:37:11 2010 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 8C6E43A67AD; Thu, 22 Apr 2010 17:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.175, 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 D1OzXoXadyvc; Thu, 22 Apr 2010 17:37:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D19103A689A; Thu, 22 Apr 2010 17:37:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O56o2-000Ane-D9 for namedroppers-data0@psg.com; Fri, 23 Apr 2010 00:31:42 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O56ny-000AnL-Sf for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 00:31:38 +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 D4022E9342; Fri, 23 Apr 2010 00:31:37 +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 o3N0VRQb069783; Fri, 23 Apr 2010 10:31:30 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004230031.o3N0VRQb069783@drugs.dv.isc.org> To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <4BC720DE.8080900@nic.cz> <5C8B7499CFD24579BD7B75CB8050FDA1@local> <4BD0521B.9090803@nic.cz> <986F4044CBEE422BB769C7BA94B90BF2@local> <4BD064E4.9060700@nic.cz> Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 In-reply-to: Your message of "Thu, 22 Apr 2010 17:01:56 +0200." <4BD064E4.9060700@nic.cz> Date: Fri, 23 Apr 2010 10:31:27 +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 <4BD064E4.9060700@nic.cz>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= writes: > Well, my proposal is just two hunk patch in bind9 and I guess for nsd > (and others) it would be same amount of work. It's compatible with > current resolvers (althought more testing is needed). Except it isn't a two hunk patch. It was a two hunk patch to make named act correctly as a *authoritative* server. The resolver side of named also needs to be changed to support the new sematics of CNAME. Given what I saw on the authoritative side I'm not sure that I could succesfully validate signed answers from a forwarder. 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 Apr 22 19:33:40 2010 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 25DBE3A67A7; Thu, 22 Apr 2010 19:33:40 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.005 X-Spam-Level: ** X-Spam-Status: No, score=2.005 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 r262Kx9kthzY; Thu, 22 Apr 2010 19:33:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EAE933A67E2; Thu, 22 Apr 2010 19:33:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O58bw-000346-Kn for namedroppers-data0@psg.com; Fri, 23 Apr 2010 02:27:20 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O58bt-00033m-BZ for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 02:27:17 +0000 Received: (eyou send program); Fri, 23 Apr 2010 10:27:15 +0800 Message-ID: <471989635.01441@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 23 Apr 2010 10:27:15 +0800 Message-ID: <4BCFA12F20554D30BEB86C7D0C2FD060@LENOVO47E041CF> From: "YAO Jiankang" To: "Douglas Otis" , "Mark Andrews" Cc: "Vaggelis Segredakis" , "'Niall O'Reilly'" , "'Andrew Sullivan'" , , "'Sotiris Panaretou'" References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <4BCF967A.3000109@mail-abuse.org> <201004220102.o3M124ht097291@drugs.dv.isc.org> <4BCFBA6C.5000607@mail-abuse.org> <201004220401.o3M41mmK002880@drugs.dv.isc.org> <471961403.09650@cnnic.cn> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Date: Fri, 23 Apr 2010 10:27:19 +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.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: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRvdWdsYXMgT3RpcyIgPGRv dGlzQG1haWwtYWJ1c2Uub3JnPg0KVG86ICJNYXJrIEFuZHJld3MiIDxtYXJrYUBpc2Mub3JnPg0K Q2M6ICJWYWdnZWxpcyBTZWdyZWRha2lzIiA8c2VncmVkQGljcy5mb3J0aC5ncj47ICInTmlhbGwg TydSZWlsbHknIiA8TmlhbGwub1JlaWxseUB1Y2QuaWU+OyAiJ0FuZHJldyBTdWxsaXZhbiciIDxh anNAc2hpbmt1cm8uY29tPjsgPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+OyAiJ1NvdGlyaXMg UGFuYXJldG91JyIgPHNvdGlyaXNAdWN5LmFjLmN5Pg0KU2VudDogRnJpZGF5LCBBcHJpbCAyMywg MjAxMCAyOjIwIEFNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gSUNBTk4ncyAic3luY2hyb25pemVk IGRvbWFpbnMiIGFuZCB0aGUgRE5TRVhUIGFsaWFzIG1heWJlLXdvcmsNCg0KDQo+IE9uIDQvMjEv MTAgOTowMSBQTSwgTWFyayBBbmRyZXdzIHdyb3RlOg0KPj4gIEluIG1lc3NhZ2UgPDRCQ0ZCQTZD LjUwMDA2MDdAbWFpbC1hYnVzZS5vcmc+LCBEb3VnbGFzIE90aXMgd3JpdGVzOg0KPj4gPiBJdCBz ZWVtcyBtb3N0IGRvbWFpbnMgYXJlIGZhaXJseSBmbGF0LCBidXQgdGhpcyBzZWVtIHRvIHN1Z2dl c3QgYQ0KPj4gPiBkZXBhcnR1cmUgZnJvbSBjdXJyZW50IHByYWN0aWNlcyBvZiBiZWluZyBmbGF0 IGFuZCByZWZlcmVuY2luZyBNWA0KPj4gPiByZWNvcmRzIGF0IHpvbmUgYXBleGVzLg0KPj4NCj4+ ICBObywgaXQgZG9lc24ndC4NCj4gDQo+IEkgYW0gY29uZnVzZWQgdGhlbiBhbmQgbmVlZCB5b3Vy IGhlbHAuDQo+IA0KPj4gPiBGb3IgZXhhbXBsZSwgIHRha2UgdGhlIGRvbWFpbiAiZXhhbXBsZS5j b20uIiAgTW9zdCBkb21haW5zIGxvY2F0ZQ0KPj4gPiBNWCByZWNvcmRzIGF0IHRoZSB6b25lIGFw ZXgsIHdoZXJlIGluIHRoaXMgaW5zdGFuY2UsIGl0IHdvdWxkIGJlDQo+PiA+IGF0ICJleGFtcGxl LmNvbS4iICBJdCB3b3VsZCBub3QgYmUgcHJhY3RpY2FsIHRvIHBsYWNlIGEgQk5BTUUgaW4NCj4+ ID4gIi5jb20iIHdoaWNoIG5lZWRzIHRvIGNvbnRhaW4gTlMgcmVjb3JkcyBmb3IgZGVsZWdhdGlv bi4NCj4+DQo+PiAgV2h5IG5vdD8gIEl0IHNob3VsZCBiZSBubyBoYXJkZXIgdG8gYWRkIEJOQU1F IHJlY29yZHMgdG8gY29tIG9uY2UNCj4+ICB0aGUgc2VydmVycyBzdXBwb3J0IEJOQU1FIHRoYW4g aXQgaXMgdG8gYWRkIE5TIHJlY29yZHMuDQo+IA0KPiBEb2Vzbid0IHNlY3Rpb24gMy4zIHJ1bGUg MiBleGNsdWRlIHRoaXMgcG9zc2liaWxpdHk/ICBUaGVyZSBhcmUgMTMgTlMgDQo+IHJlY29yZHMg YXQgIi5jb20iIHBvaW50aW5nIHRvIHJvb3QgbmFtZSBzZXJ2ZXJzPyAgV2hhdCB3b3VsZCBpdCBt ZWFuIHRvIA0KPiBoYXZlIGp1c3QgYSBDTkFNRSBhdCAiLmNvbSIgYW5kIHdvdWxkbid0IGFuIGFs aWFzZWQgZG9tYWluIHN0aWxsIG5lZWQgdG8gDQo+IGluY2x1ZGUgcmVzb3VyY2VzIHRoYXQgd2ls bCBleGNsdWRlIENOQU1FIG9yIEJOQU1FPyAgV2hhdCBhbSBJIG1pc3Npbmc/DQoNCmRvIHlvdSBt ZWFuIHRoYXQgaW4gdGhlIHJvb3Qgem9uZSB0aGVyZSBjYW4gaGF2ZSAxMyBOUyByZWNvcmRzIGZv ciAuY29tIHdoaWxlIHRoZXJlIHdpbGwgb25seSBvbmUgQk5BTUUgcmVjb3JkIGZvciAuY29tIGlm IEJOQU1FIGlzIGFwcGxpZWQ/DQpzbyB5b3UgdGhpbmsgdGhhdCAxMyBpcyBzYWZlciBvciByb2J1 c3RlciB0aGFuIDE/DQoNCnllcywgeW91IGNhbiBoYXZlIG1hbnkgTlMgcmVjb3JkcyBhcyB5b3Ug d2FudDsgYnV0IHlvdSBjYW4gaGF2ZSBvbmx5IG9uZSBCTkFNRSByZWNvcmQuDQoNCmluIHRoZSBy b290IHpvbmUsDQoNCnlvdSBjYW4gaGF2ZQ0KDQpDT00uIE5TIEEuR1RMRC1TRVJWRVJTLk5FVC4N CkNPTS4gTlMgRy5HVExELVNFUlZFUlMuTkVULg0KQ09NLiBOUyBILkdUTEQtU0VSVkVSUy5ORVQu DQpDT00uIE5TIEMuR1RMRC1TRVJWRVJTLk5FVC4NCkNPTS4gTlMgSS5HVExELVNFUlZFUlMuTkVU Lg0KQ09NLiBOUyBCLkdUTEQtU0VSVkVSUy5ORVQuDQpDT00uIE5TIEQuR1RMRC1TRVJWRVJTLk5F VC4NCkNPTS4gTlMgTC5HVExELVNFUlZFUlMuTkVULg0KQ09NLiBOUyBGLkdUTEQtU0VSVkVSUy5O RVQuDQpDT00uIE5TIEouR1RMRC1TRVJWRVJTLk5FVC4NCkNPTS4gTlMgSy5HVExELVNFUlZFUlMu TkVULg0KQ09NLiBOUyBFLkdUTEQtU0VSVkVSUy5ORVQuDQpDT00uIE5TIE0uR1RMRC1TRVJWRVJT Lk5FVC4NCg0KaWYgeW91IHdhbnQgQ09NUEFOWS4gdG8gYmUgc2FtZSB3aXRoIENPTS4sDQp5b3Ug bmVlZCB0byBoYXZlIHRoaXMgcmVjb3JkIGluIHRoZSByb290IHpvbmU6DQoNCkNPTVBBTlkuICBC TkFNRSBDT00uDQoNCmFsdGhvdWdoIHRoZXJlIGlzIG9ubHkgb25lIHJlY29yZCBmb3IgQk5BTUUs DQoNCnRoZSByb2J1c3RuZXNzIENPTVBBTlkuIGdldHMgaXMgYXMgc2FtZSBhcyB3aGF0IHRoZSAu Q09NIGdldHMgc2luY2UgZXZlcnkgcXVlcnkgZm9yIC5DT01QQU5ZIHdpbGwgYmUgZGlyZWN0ZWQg dG8gLkNPTSB3aGlsZSAuQ09NIGhhcyAxMyBOUyByZWNvcmRzLg0KDQoNCg0KSmlhbmthbmcgWWFv DQpDTk5JQw0KDQoNCg0KDQoNCj4gDQo+IDMuMy4gVGhlIEJOQU1FIFJ1bGVzDQo+IA0KPiAgICBU aGVyZSBhcmUgdHdvIHJ1bGVzIHdoaWNoIGdvdmVybnMgdGhlIHVzZSBvZiBCTkFNRXMgaW4gYSB6 b25lIGZpbGUuDQo+ICAgIFRoZSBmaXJzdCBvbmUgaXMgdGhhdCB0aGVyZSBTSE9VTEQgYmUgbm8g ZGVzY2VuZGFudHMgdW5kZXIgdGhlIG93bmVyDQo+ICAgIG9mIHRoZSBCTkFNRS4gIFRoZSBzZWNv bmQgb25lIGlzIHRoYXQgX25vXyByZXNvdXJjZSByZWNvcmRzIGNhbiBjby0NCj4gICAgZXhpc3Qg d2l0aCB0aGUgQk5BTUUgZm9yIHRoZSBzYW1lIG5hbWUuIChleGNlcHQgcmVzb3VyY2VzIGZvciBE TlNTRUMpLg0KPiANCg== From owner-namedroppers@ops.ietf.org Thu Apr 22 19:43:30 2010 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 2692B3A685A; Thu, 22 Apr 2010 19:43:30 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 1.96 X-Spam-Level: * X-Spam-Status: No, score=1.96 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 Nx40-V3uI8pZ; Thu, 22 Apr 2010 19:43:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 06FCF3A67F4; Thu, 22 Apr 2010 19:43:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O58o6-0004tO-05 for namedroppers-data0@psg.com; Fri, 23 Apr 2010 02:39:54 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O58o3-0004rR-38 for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 02:39:51 +0000 Received: (eyou send program); Fri, 23 Apr 2010 10:39:49 +0800 Message-ID: <471990389.24655@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 23 Apr 2010 10:39:49 +0800 Message-ID: From: "YAO Jiankang" To: "Andrew Sullivan" , "Niall O'Reilly" Cc: "Vaggelis Segredakis" , , "'Sotiris Panaretou'" References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF2B98.1030000@ucd.ie> <20100421170256.GM47807@shinkuro.com> <4BCF4A8F.6090401@ucd.ie> <471879699.15774@cnnic.cn> Subject: Re: [dnsext] Re: Aliasing and MX Date: Fri, 23 Apr 2010 10:39:53 +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.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: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFuZHJldyBTdWxsaXZhbiIg PGFqc0BzaGlua3Vyby5jb20+DQpUbzogIk5pYWxsIE8nUmVpbGx5IiA8TmlhbGwub1JlaWxseUB1 Y2QuaWU+DQpDYzogIlZhZ2dlbGlzIFNlZ3JlZGFraXMiIDxzZWdyZWRAaWNzLmZvcnRoLmdyPjsg PG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+OyAiJ1NvdGlyaXMgUGFuYXJldG91JyIgPHNvdGly aXNAdWN5LmFjLmN5Pg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDIyLCAyMDEwIDM6NDQgQU0NClN1 YmplY3Q6IFJlOiBbZG5zZXh0XSBSZTogQWxpYXNpbmcgYW5kIE1YDQoNCg0KPiBPbiBXZWQsIEFw ciAyMSwgMjAxMCBhdCAwNzo1NzoxOVBNICswMTAwLCBOaWFsbCBPJ1JlaWxseSB3cm90ZToNCj4+ PiBTbyB3aGF0IGlzIHRoZSBtYWlsIHByb2JsZW0/ICANCj4+DQo+PiBBIGRpc3RyYWN0aW9uLg0K Pj4gQSBub24taXNzdWUuDQo+PiBUaGVyZSBpcyBub25lLg0KPiANCj4gT2ssIGV4Y2VwdCBzaW5j ZSBWYWdnZWxpcyBpcyB0aGUgb25lIHdobyBzYXlzIHRoZXJlIGlzIHRoaXMgcHJvYmxlbSwNCj4g SSdkIGxpa2UgdG8ga25vdyB3aGF0IGl0J3Mgc3VwcG9zZWQgdG8gYmUuICANCg0KYXMgYSByZWdp c3RyeSwgd2UgaGF2ZSBzb21lIGV4cGVyaWVuY2Ugb2Ygd2h5IGRuYW1lIGlzIG5vdCB1c2VkIGlu IG1hbnkgcmVnaXN0cmllcy4NCi5nciBpcyBhIHJlZ2lzdHJ5Lg0KDQpub3JtYWxseSwgdGhlIHJl Z2lzdHJ5IG9ubHkgcHJvdmlkZSB0aGUgTlMgcmVjb3JkcyBpbiB0aGUgVExEIHpvbmUsIG5vIEEg cmVjb3JkIG9yIE1YIHJlY29yZC4NCg0Kc29tZW9uZSByZWdpc3RlcnMgIGNvbG9yLnRsZCBhbmQg Y29sb3VyLnRsZC4NCmluIGN1cnJlbnQgcHJhY3Rpc2UsIHdlIHdpbGwgcHV0IGluIFRMRCB6b25l DQpjb2xvci50bGQuIE5TIG5hbWVyc2VydmVyOw0KY29sb3VyLnRsZC4gTlMgbmFtZXNlcnZlcjsN Cg0KaWYgd2Ugd2FudCBjb2xvci50bGQgYW5kIGNvbG91ci50bGQuIHRvIGdldCB0aGUgaWRlbnRp Y2FsIHJlc2xvdXRpb24sDQp3ZSBtYXkgcHV0ICBpbiBUTEQgem9uZQ0KDQpjb2xvci50bGQuIE5T IG5hbWVyc2VydmVyOw0KY29sb3VyLnRsZC4gRE5BTUUgY29sb3IudGxkOw0KDQpub3cgdGhlIHVz ZXIgZXhwZWN0IG5hbWVAY29sb3IudGxkIGFuZCBuYW1lQGNvbG91ci50bGQgdG8gYmUgc2FtZS4N Cg0KaW4gb3JkZXIgdG8gZ2V0IHRoZSBzYW1lIGFkZHJlc3MgZm9yIG5hbWVAY29sb3IudGxkIGFu ZCBuYW1lQGNvbG91ci50bGQgLA0KDQppbiB0aGUgY29sb3IudGxkIHpvbmUsIHdlIG5lZWQNCmNv bG9yLnRsZCBNWCBhLmNvbG9yLnRsZA0KYS5jb2xvci50bGQgQSAxOTIuMTY4LjEuMQ0KDQppbiB0 aGUgVExEIHpvbmUsDQoNCndlIG5lZWQgDQpjb2xvdXIudGxkIE1YIGEuY29sb3IudGxkDQoNCmJ1 dCB1bmZvcnR1bmF0ZWx5LCBtb3N0IHJlZ2lzdHJpZXMgZG8gbm90IHByb3ZpZGUgdGhlIEEgcmVj b3JkIG9yIE1YIHJlY29yZCBzZXJ2aWNlLg0KDQpldmVuIHRoZSByZWdpc3RyeSBwcm92aWRlcyB0 aGUgc2VydmljZSBvZiBNWCByZWNvcmQsIGl0IGlzIG5vdCBjb21mb3J0YWJsZSBmb3IgY3VzdG9t ZXJzIHdobyBtdXN0IHVwZGF0ZSB0aGUgTVggcmVjb3JkcyBpbiB0aGUgcmVnaXN0cnkgZXZlcnkg dGltZSBoZSB3YW50cyB0byB1cGRhdGUgaXQuDQoNCnNvIGlmIHRoZXJlIGhhcyBhIEJOQU1FLA0K DQp3ZSBtYXkgcHV0ICBpbiBUTEQgem9uZQ0KDQpjb2xvci50bGQuIE5TIG5hbWVyc2VydmVyOw0K Y29sb3VyLnRsZC4gQk5BTUUgY29sb3IudGxkOw0KDQpub3cgdGhlIHVzZXIgZXhwZWN0IG5hbWVA Y29sb3IudGxkIGFuZCBuYW1lQGNvbG91ci50bGQgdG8gYmUgc2FtZS4NCg0KdGhlIHVzZXIgb25s eSBjb25maWd1cmUgZXZlcnl0aGluZyBpbiB0aGUgY29sb3IudGxkIHpvbmUsIG5vdCBpbiBUTEQg em9uZS4NCg0KDQpKaWFua2FuZyBZYW8NCg0KDQo+UmVtZW1iZXIsIHdlJ3JlIHRyeWluZyB0bw0K PiBmaWd1cmUgb3V0IHdoZXRoZXIgdGhlcmUncyBhIHByb2JsZW0gdG8gc29sdmUuICBTdGVwIDEg aW4gdGhhdCBpcw0KPiAiZGVzY3JpYmUgcHJvYmxlbSIsIEkgdGhpbmsuDQo+IA0KPiAtLSANCj4g QW5kcmV3IFN1bGxpdmFuDQo+IGFqc0BzaGlua3Vyby5jb20NCj4gU2hpbmt1cm8sIEluYy4NCj4= From owner-namedroppers@ops.ietf.org Thu Apr 22 19:50:15 2010 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 7E2833A6894; Thu, 22 Apr 2010 19:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.552 X-Spam-Level: * X-Spam-Status: No, score=1.552 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 2QkHsWDRxvx1; Thu, 22 Apr 2010 19:50:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3714A3A6874; Thu, 22 Apr 2010 19:50:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O58u0-0005wQ-Au for namedroppers-data0@psg.com; Fri, 23 Apr 2010 02:46:00 +0000 Received: from [202.46.183.22] (helo=srsomail.nzrs.net.nz) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O58tx-0005st-L8 for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 02:45:57 +0000 Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 87E112CE42B; Fri, 23 Apr 2010 14:45:55 +1200 (NZST) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eER8aLl9ontX; Fri, 23 Apr 2010 14:45:55 +1200 (NZST) Received: from [192.168.22.190] (unknown [202.46.183.35]) (Authenticated sender: sebastian) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 4E5232CE41D; Fri, 23 Apr 2010 14:45:55 +1200 (NZST) Message-ID: <4BD109E2.7010101@nzrs.net.nz> Date: Fri, 23 Apr 2010 14:45:54 +1200 From: Sebastian Castro User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Rose, Scott W." CC: namedroppers Subject: Re: [dnsext] dname-bis-19 posted References: In-Reply-To: X-Enigmail-Version: 0.95.7 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: Rose, Scott W. wrote: Hi Scott, > A new version of dname-bis has been posted. Changes: > > 1. basic "keep-alive" update > > 2. changed examples to have correct DO bit representation > > 3. text to cover corner cases (i.e. when QTYPE = ANY, etc.) based on > comments originally from Ed Lewis. Not all comments were included. Two comments: In Section 3.1 a typo was added: it reads "When the owner name name matches" with a duplicated 'name'. In the same section, what's the rationale to change the TTL=0 for the synthesized CNAMEs and start using the TTL of the original DNAME? Take advantage of caching? Kind Regards > > Scott > =================================== > Scott Rose > NIST > scottr@nist.gov > ph: +1 301-975-8439 > Google Voice: +1-571-249-3671 > > http://www.dnsops.gov/ > =================================== > > > -- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535 From owner-namedroppers@ops.ietf.org Thu Apr 22 20:02:46 2010 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 E43833A6821; Thu, 22 Apr 2010 20:02:46 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 3.129 X-Spam-Level: *** X-Spam-Status: No, score=3.129 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 VnxBnJoWjSnM; Thu, 22 Apr 2010 20:02:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E8E013A6847; Thu, 22 Apr 2010 20:02:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O595w-0007xd-Sj for namedroppers-data0@psg.com; Fri, 23 Apr 2010 02:58:20 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O595t-0007x8-Qs for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 02:58:18 +0000 Received: (eyou send program); Fri, 23 Apr 2010 10:58:16 +0800 Message-ID: <471991496.22574@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 23 Apr 2010 10:58:16 +0800 Message-ID: From: "YAO Jiankang" To: "Andrew Sullivan" , References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <20100422171521.GK1362@shinkuro.com> Subject: Re: BNAME, Synthesized CNAME, and DNSSEC (was: [dnsext] ICANN's"synchronized domains" and the DNSEXT alias maybe-work) Date: Fri, 23 Apr 2010 10:58:20 +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.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: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFuZHJldyBTdWxsaXZhbiIg PGFqc0BzaGlua3Vyby5jb20+DQpUbzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50 OiBGcmlkYXksIEFwcmlsIDIzLCAyMDEwIDE6MTUgQU0NClN1YmplY3Q6IEJOQU1FLCBTeW50aGVz aXplZCBDTkFNRSwgYW5kIEROU1NFQyAod2FzOiBbZG5zZXh0XSBJQ0FOTidzInN5bmNocm9uaXpl ZCBkb21haW5zIiBhbmQgdGhlIEROU0VYVCBhbGlhcyBtYXliZS13b3JrKQ0KDQoNCj4gTm8gaGF0 Lg0KPiANCj4gT24gVGh1LCBBcHIgMjIsIDIwMTAgYXQgMDk6MTQ6MjZBTSArMTAwMCwgTWFyayBB bmRyZXdzIHdyb3RlOg0KPiANCj4+IGp1c3QgZG8gdGhlIHNhbWUgdGhpbmcgd2hlbiB3ZSBpbnRy b2R1Y2UgQk5BTUUuICBpLmUuIHVzZSBETlNTRUMNCj4+IGFsZ29yaXRobXMgdG8gc2lnbmFsIGlm IHRoZSB6b25lIG1heSBjb250YWluIGEgQk5BTUUgYW5kIG9ubHkgdGhvc2UNCj4+IHZhbGlkYXRv cnMgdGhhdCB1bmRlcnN0YW5kIEJOQU1FIHdpbGwgdHJlYXQgaXQgYXMgc2VjdXJlLiAgRXZlcnlv bmUNCj4+IGVsc2Ugd2lsbCB0cmVhdCB0aGUgem9uZXMgYXMgaW5zZWN1cmUuDQo+IA0KPiBJIGZp bmQgaXQgYSBsaXR0bGUgc3RyYW5nZSB0aGF0IG9uIHRoZSBvbmUgaGFuZCB3ZSd2ZSBoYWQgcGVv cGxlDQo+IHdyaW5naW5nIHRoZWlyIGhhbmRzIGFib3V0IHVzIHBvdGVudGlhbGx5IHJ1bm5pbmcg b3V0IG9mIGFsZ29yaXRobQ0KPiBudW1iZXJzLCBhbmQgb24gdGhlIG90aGVyIGhhbmQgd2UncmUg cHJlcGFyZWQgdG8gdXNlIHVwIHR3aWNlIGFzIG1hbnkNCj4gbnVtYmVycyBhcyB3ZSBoYXZlIGFs bG9jYXRlZCBvbiB0aGUgZGF5IGEgbmV3IFJSVFlQRSBvZiB0aGlzIHNvcnQgaXMNCj4gdXNlZC4N Cj4gDQo+IEknbSBub3Qgc2F5aW5nIHRoYXQncyB0aGUgd3JvbmcgYW5zd2VyLCBidXQgc3VyZWx5 IGFsbCB0aGUgcGVvcGxlIHdobw0KPiB3ZXJlIHVuY29tZm9ydGFibGUgd2l0aCB0aGUgYWxnb3Jp dGhtIGFsbG9jYXRpb24gZG9jdW1lbnQgYXJlIGdvaW5nIHRvDQo+IGJlIHVuaGFwcHkgd2l0aCB0 aGUgYWJvdmUgYW5zd2VyIHRvbywgcmlnaHQ/DQoNCklQdjQgYWRkcmVzcyBpcyBleGhhdXN0aW5n IHNvb24sIGJ1dCAgSSBoYXZlIG5ldmVyIGhlYXJkIHRoYXQgSUFOQSB3aWxsIHJlZnVzZSB0byBh bGxvY2F0ZSB0aGUgSVB2NCBhZGRyZXNzIHRvIGN1c3RvbWVycy4NCg0KSSBvbmx5IGhlYXJkIHRo YXQgSUFOQSBpcyB0cnlpbmcgdG8gYWxsb2NhdGUgdGhlIGFkZHJlc3MgdG8gdGhvc2Ugd2hvIG5l ZWQgaXQuDQoNCndoZW4gSVB2NCBhZGRyZXNzIGlzIHJ1bm5pbmcgb3V0LCB0aGUgSVB2NiB3aWxs IGNvbWUuDQoNCkRvZXMgcHJvdG9jb2wgZGVzaWduIGZvbGxvdyB0aGUgY3VzdG9tZXIncyBuZWVk cz8NCg0KSWYgd2UgZG8gbm90IHNhdGlzZnkgdGhlIG5lZWRzIG9mIGN1c3RvbWVycywgIGl0IG1h eSBjYXVzZSBtb3JlIHVuaGFwcHkuDQoNCkkgdGhpbmsgdGhhdCB0aGUgSVB2NCBhZGRyZXNzIGV4 YW1wbGUgbWF5IGFwcGx5IGhlcmUuDQoNCjopDQoNCg0KSmlhbmthbmcgWWFvDQoNCiANCg0KDQoN Cj4gDQo+IEENCj4gLS0gDQo+IEFuZHJldyBTdWxsaXZhbg0KPiBhanNAc2hpbmt1cm8uY29tDQo+ IFNoaW5rdXJvLCBJbmMuDQo+ From owner-namedroppers@ops.ietf.org Thu Apr 22 21:55:26 2010 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 CABD13A6954; Thu, 22 Apr 2010 21:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] 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 Jtzme1+Ar5Ao; Thu, 22 Apr 2010 21:55:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9534D28C0D7; Thu, 22 Apr 2010 21:53:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5AoA-000PIz-3J for namedroppers-data0@psg.com; Fri, 23 Apr 2010 04:48:06 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5Ao7-000PIZ-LQ for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 04:48: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 34F54E9394; Fri, 23 Apr 2010 04:48: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 o3N4lsSv071899; Fri, 23 Apr 2010 14:47:55 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004230447.o3N4lsSv071899@drugs.dv.isc.org> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <20100422171521.GK1362@shinkuro.com> Subject: Re: BNAME, Synthesized CNAME, and DNSSEC (was: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work) In-reply-to: Your message of "Thu, 22 Apr 2010 13:15:21 -0400." <20100422171521.GK1362@shinkuro.com> Date: Fri, 23 Apr 2010 14:47:54 +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 <20100422171521.GK1362@shinkuro.com>, Andrew Sullivan writes: > No hat. > > On Thu, Apr 22, 2010 at 09:14:26AM +1000, Mark Andrews wrote: > > > just do the same thing when we introduce BNAME. i.e. use DNSSEC > > algorithms to signal if the zone may contain a BNAME and only those > > validators that understand BNAME will treat it as secure. Everyone > > else will treat the zones as insecure. > > I find it a little strange that on the one hand we've had people > wringing their hands about us potentially running out of algorithm > numbers, and on the other hand we're prepared to use up twice as many > numbers as we have allocated on the day a new RRTYPE of this sort is > used. Firstly it wouldn't be double. You would create aliases for RSASHA256, RSASHA512, NSEC3DSA and ECC-GOST. RSAMD5, DSA, RSASHA1 and NSEC3RSASHA1 would not get aliases. One could argue about NSEC3RSASHA1 but I believe it is reasonable not to create a alias for it. That leaves 4 new algorithms B-RSASHA256, B-RSASHA512, B-DSA, B-ECC-GOST which all support NSEC3 and BNAME. Secondly one very rarely changes the rules associated with validation. This shouldn't be thought of as a new type but a new method of synthesis. Mark > I'm not saying that's the wrong answer, but surely all the people who > were uncomfortable with the algorithm allocation document are going to > be unhappy with the above answer too, right? > > A > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > -- 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 Apr 22 23:00:03 2010 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 578593A67B6; Thu, 22 Apr 2010 23:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.314, 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 aXCwnl3Pbd3s; Thu, 22 Apr 2010 23:00:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1A81C3A67A1; Thu, 22 Apr 2010 22:59:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5BqL-000AmU-M6 for namedroppers-data0@psg.com; Fri, 23 Apr 2010 05:54:25 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5BqJ-000AmE-7I for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 05:54:23 +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 26E0FE93AA; Fri, 23 Apr 2010 05: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 o3N5sCR2048685; Fri, 23 Apr 2010 15:54:12 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004230554.o3N5sCR2048685@drugs.dv.isc.org> To: Sebastian Castro Cc: "Rose, Scott W." , namedroppers From: Mark Andrews References: <4BD109E2.7010101@nzrs.net.nz> Subject: Re: [dnsext] dname-bis-19 posted In-reply-to: Your message of "Fri, 23 Apr 2010 14:45:54 +1200." <4BD109E2.7010101@nzrs.net.nz> Date: Fri, 23 Apr 2010 15:54:12 +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 <4BD109E2.7010101@nzrs.net.nz>, Sebastian Castro writes: > In the same section, what's the rationale to change the TTL=0 for the > synthesized CNAMEs and start using the TTL of the original DNAME? Take > advantage of caching? Yes. -- 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 Apr 23 01:15:37 2010 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 477713A68F6; Fri, 23 Apr 2010 01:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.14 X-Spam-Level: X-Spam-Status: No, score=-98.14 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_50=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, 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 WNX3UQotGBgi; Fri, 23 Apr 2010 01:15:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F8163A6877; Fri, 23 Apr 2010 01:15:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5DwV-000A7M-B4 for namedroppers-data0@psg.com; Fri, 23 Apr 2010 08:08:55 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5DwP-000A5D-1t for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 08:08:49 +0000 Received: from [IPv6:2001:1488:ac14:1400:ac14:1a29:0:2] (unknown [IPv6:2001:1488:ac14:1400:ac14:1a29:0:2]) by mail.nic.cz (Postfix) with ESMTPSA id 68F70734430; Fri, 23 Apr 2010 10:08:45 +0200 (CEST) Message-ID: <4BD1558D.5090703@nic.cz> Date: Fri, 23 Apr 2010 10:08:45 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mark Andrews CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 References: <4BC720DE.8080900@nic.cz> <5C8B7499CFD24579BD7B75CB8050FDA1@local> <4BD0521B.9090803@nic.cz> <986F4044CBEE422BB769C7BA94B90BF2@local> <4BD064E4.9060700@nic.cz> <201004230031.o3N0VRQb069783@drugs.dv.isc.org> In-Reply-To: <201004230031.o3N0VRQb069783@drugs.dv.isc.org> 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 23.4.2010 02:31, Mark Andrews wrote: > In message<4BD064E4.9060700@nic.cz>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= > writes: >> Well, my proposal is just two hunk patch in bind9 and I guess for >> nsd (and others) it would be same amount of work. It's compatible >> with current resolvers (althought more testing is needed). > > Except it isn't a two hunk patch. It was a two hunk patch to make > named act correctly as a *authoritative* server. True, but at least Bind and Unbound work fine just as they are. > The resolver side of named also needs to be changed to support the > new sematics of CNAME. I'll do more extensive testing with all free resolvers (which support DNAME) next week (I have vacation today and on Monday). If somebody can test Microsoft DNS resolver and CNS, it would be great. > Given what I saw on the authoritative side I'm not sure that I could > successfully validate signed answers from a forwarder. Ok, let's give it a try. target.dname.cz. IN CNAME ccccc.dname.cz. target.dname.cz. IN DNAME ddddd.dname.cz. dname.cz zone is signed and DS is published in .CZ. I am using DNS-OARC resolvers (.20 is BIND 9, .21 is Unbound). Dig options are: +noall +comment +adflag ondrej@ookami:~$ dig IN A target.dname.cz @149.20.64.20 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13559 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0 ondrej@ookami:~$ dig IN A target.dname.cz @149.20.64.21 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64158 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0 ondrej@ookami:~$ dig IN A www.target.dname.cz @149.20.64.20 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60920 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 0 ondrej@ookami:~$ dig IN A www.target.dname.cz @149.20.64.21 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16900 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 0 So it looks like those two common existing implementation are already ready for CNAME+DNAME. And that's exacly my point - with very simple change in CNAME semantics we can get full alias in the DNS tree, which is already supported by majority of DNS servers in the wild (at least those supporting DNAME). I am sure that this will break something somewhere, but those place would be broken with BNAME as well. But BNAME has to be implemented everywhere - authoritative DNS, resolvers, firewalls, etc. Don't get me wrong, I think that BNAME is fine proposal, but I think that we have much simpler option right before us. Also it not something new, we did change semantics of CNAME before, because of DNSSEC, so I am not proposing revolution, just merging of two existing working principles. O. -- Ondřej Surý vedoucí výzkumu/R&D manager ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From owner-namedroppers@ops.ietf.org Fri Apr 23 01:53:54 2010 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 182913A69B3; Fri, 23 Apr 2010 01:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.402 X-Spam-Level: X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5 tests=[AWL=-0.768, BAYES_40=-0.185, 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 Lc2Wm7KuUEZR; Fri, 23 Apr 2010 01:53:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C1CE83A693D; Fri, 23 Apr 2010 01:53:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5EZe-000He5-Ra for namedroppers-data0@psg.com; Fri, 23 Apr 2010 08:49:22 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5EZW-000HZD-HQ for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 08:49:14 +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 <0L1B00301MM3N600@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 09:49:12 +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 <0L1B00IOHN5ZP700@dakota.ucd.ie>; Fri, 23 Apr 2010 09:49:12 +0100 (IST) Date: Fri, 23 Apr 2010 09:49:11 +0100 From: Niall O'Reilly Subject: Re: [dnsext] Re: Use the layers, Luke! In-reply-to: <20100421195653.GD912@shinkuro.com> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Message-id: <4BD15F07.2070801@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF440F.1090501@ucd.ie> <20100421195653.GD912@shinkuro.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) 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 21/04/10 20:56, Andrew Sullivan wrote: > Thanks for the continued effort in clarifying these issues. It's > really very helpful. I'll try to be terse too. > > On Wed, Apr 21, 2010 at 07:29:35PM +0100, Niall O'Reilly wrote: > >> This question ("Which of the following ...") is a matter of registry >> policy, whether that registry be ICANN, a TLD, or the administrator of >> some deep subsidiary zone. It's not the problem we're looking for, and >> we should best avoid it. > > It's exactly the problem we're supposed to be solving, I'm sorry. I see what you mean. I wasn't seeing the wood for the trees. [ I should heed my own choice of Subject: line. 8-) ] > in that those are three possible meanings of "equivalent" Two of them, yes; the other, arguably not. > and they are nowise the same thing. Agreed. Now, back to what they were, to save people some searching ... On 21/04/10 15:03, Andrew Sullivan wrote: > I repeat what I previously wrote, with a modification to avoid this > ratholing into a question about TLDs. It's fully generalizable: > > Suppose that we have [name1] and [name2], and they're supposed to be > equivalent. These names may be made of more than one label. [name1] > comes from one repetoire of Unicode characters. Call it range1. > [name2] comes from another repetoire of Unicode characters. Call it > range2. The only restriction is that range1 and range2 have at least > one character that differs between them (they're not equivalent sets. > In the unlikely event that any people who know about writing systems > are reading this, I understand that this simplifying assumption is > already really bad. Never mind that). Now, suppose we have any sets > of labels, each of which is either in range1 (symbolized r1) or > range2 (symbolized r2). Which of the following behaviours is > desired: > > a. Should DNS names in the zones underneath the two > synchronized zones be exactly (bit-for-bit) equivalent to one > another? For example, for a fully qualified domain name of > the form r1.r1.[name1], must there always and only be a > synchronized entry r1.r1.[name2]? > > b. Should all and every label under [name1] be expressed in LE1 > and all and every label under TLD2 be expressed in [name2]? For > example, for a fully qualified domain of the form r1.r1.[name1] > must there always and only be a synchronized entry > r2.r2.[name2]? > > c. Should every label at every level of the DNS be expressed > in both LE1 and LE2 (the combinatorial case)? For example, > for a fully qualified domain name of the form > r1.r1.r1.[name1], would it be necessary also to have > r1.r1.r1.[name2], r2.r1.r1.[name2], r2.r2.r1.[name2, > r2.r2.r2.[name2], r1.r2.r2.[name2], and so on? In (a) and (c), [name1] and [name2] are equivalent, and (a) may (modulo some fine detail) be seen as a degenerate case of (c). Case (b) is so pathological that I believe it is best placed explicitly out of scope. This case represents a giant cluster of equivalences between corresponding pairs of FQDNs. These pairwise equivalences are not hierarchically aggregable, even at the level of a leaf zone. Case (b) is an excellent example of how a particular choice at the policy level may lead to an intractable "requirement" for implementation. IHTH ATB Niall O'Reilly From owner-namedroppers@ops.ietf.org Fri Apr 23 02:02:45 2010 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 034AC3A687C; Fri, 23 Apr 2010 02:02:45 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 3.165 X-Spam-Level: *** X-Spam-Status: No, score=3.165 tagged_above=-999 required=5 tests=[AWL=-0.731, BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_23=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.041, MSGID_FROM_MTA_HEADER=0.803, 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 RqzKJDzOXE5R; Fri, 23 Apr 2010 02:02:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6DED3A68EA; Fri, 23 Apr 2010 02:02:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5Eim-000JOR-Qh for namedroppers-data0@psg.com; Fri, 23 Apr 2010 08:58:48 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5Eij-000JO2-G0 for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 08:58:45 +0000 Received: (eyou send program); Fri, 23 Apr 2010 16:58:44 +0800 Message-ID: <472013124.07253@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 23 Apr 2010 16:58:44 +0800 Message-ID: From: "YAO Jiankang" To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , "Mark Andrews" Cc: References: <4BC720DE.8080900@nic.cz> <5C8B7499CFD24579BD7B75CB8050FDA1@local> <4BD0521B.9090803@nic.cz> <986F4044CBEE422BB769C7BA94B90BF2@local> <4BD064E4.9060700@nic.cz> <201004230031.o3N0VRQb069783@drugs.dv.isc.org> <4BD1558D.5090703@nic.cz> Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 Date: Fri, 23 Apr 2010 16:58:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk9uZMWZZWogU3Vyw70iIDxv bmRyZWouc3VyeUBuaWMuY3o+DQpUbzogIk1hcmsgQW5kcmV3cyIgPG1hcmthQGlzYy5vcmc+DQpD YzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXksIEFwcmlsIDIzLCAy MDEwIDQ6MDggUE0NClN1YmplY3Q6IFJlOiBbZG5zZXh0XSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtc3VyeS1kbnNleHQtY25hbWUtZG5hbWUtMDANCg0KDQo+IA0KPiBT byBpdCBsb29rcyBsaWtlIHRob3NlIHR3byBjb21tb24gZXhpc3RpbmcgaW1wbGVtZW50YXRpb24g YXJlIGFscmVhZHkNCj4gcmVhZHkgZm9yIENOQU1FK0ROQU1FLg0KPiANCj4gQW5kIHRoYXQncyBl eGFjbHkgIG15IHBvaW50IC0gd2l0aCB2ZXJ5IHNpbXBsZSBjaGFuZ2UgaW4gQ05BTUUgc2VtYW50 aWNzDQo+IHdlIGNhbiBnZXQgZnVsbCBhbGlhcyBpbiB0aGUgRE5TIHRyZWUsIHdoaWNoIGlzIGFs cmVhZHkgc3VwcG9ydGVkIGJ5DQo+IG1ham9yaXR5IG9mIEROUyBzZXJ2ZXJzIGluIHRoZSB3aWxk IChhdCBsZWFzdCB0aG9zZSBzdXBwb3J0aW5nIEROQU1FKS4NCj4gDQoNCnRoZSBDTkFNRSBpcyB0 aGUgYmFzaWMgcmVjb3JkLiBtYW55IHByb3RvY29scyBiYXNlIG9uIGl0Lg0KDQppZiB5b3Ugd2Fu dCB0byBicmVhayBDTkFNRSwgIHlvdSBhcmUgdHJ5aW5nIHRvIHNoYWtlIHRoZSBiYXNpcyBvZiBE TlMuDQoNCmlmIHlvdSBidWlsZCBhIHJ1bGUsIDEwMDAgdXNlcnMgaGF2ZSBmb2xsb3dlZCBpdCBh bmQgeW91IG1heSB1cGRhdGUgb3IgbW9kaWZ5IHRoZSBydWxlLg0KDQppZiB5b3UgYnVpbGQgYSBy dWxlLCAxMDAwLDAwMCwwMDAgdXNlcnMgaGF2ZSBmb2xsb3dlZCBpdCBhbmQgeW91IHNob3VsZCBi ZSBDQVVUSU9OIHdoZW4geW91IHdpc2ggdG8gdXBkYXRlIG9yIG1vZGlmeSB0aGUgcnVsZS4NCg0K aWYgYSBuZXcgUmVjb3JkIGlzIHN1Ym1pdHRlZCwgc29tZW9uZSBtYXkgY2hvb3NlIHRvIGZvbGxv dyBvciBub3QuDQpidXQgaWYgeW91IGNoYW5nZSB0aGUgYmFzaWMgcnVsZSwgeW91IG11c3QgcHVz aCBlYWNoIG9mIDEwMDAsMDAwLDAwMCB1c2VycyAgdG8gZm9sbG93IGl0Lg0KDQpob3cgdG8gZGVj aWRlIGl0LCB3ZSBzaG91bGQgY29uc2lkZXIgdGhlIHRyYWRlIG9mZi4NCg0KSmlhbmthbmcgWWFv DQoNCg0KDQo+IEkgYW0gc3VyZSB0aGF0IHRoaXMgd2lsbCBicmVhayBzb21ldGhpbmcgc29tZXdo ZXJlLCBidXQgdGhvc2UgcGxhY2UNCj4gd291bGQgYmUgYnJva2VuIHdpdGggQk5BTUUgYXMgd2Vs bC4gIEJ1dCBCTkFNRSBoYXMgdG8gYmUgaW1wbGVtZW50ZWQNCj4gZXZlcnl3aGVyZSAtIGF1dGhv cml0YXRpdmUgRE5TLCByZXNvbHZlcnMsIGZpcmV3YWxscywgZXRjLg0KPiANCj4gRG9uJ3QgZ2V0 IG1lIHdyb25nLCBJIHRoaW5rIHRoYXQgQk5BTUUgaXMgZmluZSBwcm9wb3NhbCwgYnV0IEkgdGhp bmsNCj4gdGhhdCB3ZSBoYXZlIG11Y2ggc2ltcGxlciBvcHRpb24gcmlnaHQgYmVmb3JlIHVzLiAg QWxzbyBpdCBub3Qgc29tZXRoaW5nDQo+IG5ldywgd2UgZGlkIGNoYW5nZSBzZW1hbnRpY3Mgb2Yg Q05BTUUgYmVmb3JlLCBiZWNhdXNlIG9mIEROU1NFQywgc28gSSBhbQ0KPiBub3QgcHJvcG9zaW5n IHJldm9sdXRpb24sIGp1c3QgbWVyZ2luZyBvZiB0d28gZXhpc3Rpbmcgd29ya2luZyBwcmluY2lw bGVzLg0KPiANCj4gTy4NCj4gLS0gDQo+ICBPbmTFmWVqIFN1csO9DQo+ICB2ZWRvdWPDrSB2w716 a3VtdS9SJkQgbWFuYWdlcg0KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiAgQ1ouTklDLCB6LnMucC5vLiAgICAtLSAgICBMYWJvcmF0b8WZZSBDWi5OSUMN Cj4gIEFtZXJpY2thIDIzLCAxMjAgMDAgUHJhaGEgMiwgQ3plY2ggUmVwdWJsaWMNCj4gIG1haWx0 bzpvbmRyZWouc3VyeUBuaWMuY3ogICAgaHR0cDovL25pYy5jei8NCj4gIHRlbDorNDIwLjIyMjc0 NTExMCAgICAgICBmYXg6KzQyMC4yMjI3NDUxMTINCj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4= From dnsext-archive@ietf.org Fri Apr 23 02:47:44 2010 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 C09EB28C210 for ; Fri, 23 Apr 2010 02:47:44 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: USA VIAGRA \256 ; Fri, 23 Apr 2010 02:47:44 -0700 (PDT) Received: from ppp-94-65-128-249.home.otenet.gr (ppp-94-65-128-249.home.otenet.gr [94.65.128.249]) by core3.amsl.com (Postfix) with SMTP id AB95328C20C for ; Fri, 23 Apr 2010 02:32:07 -0700 (PDT) Received: 0f6401c54800$7450f630$f980415e@astrapi Date: Fri, 23 Apr 2010 12:26:34 +0400 Message-ID: <0f6401c54800$7450f630$f980415e@astrapi> To: dnsext-archive@ietf.org Subject: April Discount #33977 From: USA VIAGRA Reply-To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit hykvavee.ru?5353842304693=dnsext-archive@ietf.org From owner-namedroppers@ops.ietf.org Fri Apr 23 03:22:38 2010 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 6E23D28C37C; Fri, 23 Apr 2010 03:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.3 X-Spam-Level: X-Spam-Status: No, score=-97.3 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_50=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, 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 sQtuY-44vS8C; Fri, 23 Apr 2010 03:22:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 275F528C379; Fri, 23 Apr 2010 02:43:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5FKT-0000j2-RV for namedroppers-data0@psg.com; Fri, 23 Apr 2010 09:37:45 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5FKQ-0000ih-Jr for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 09:37:42 +0000 Received: from [IPv6:2001:1488:ac14:1400:ac14:1a29:0:2] (unknown [IPv6:2001:1488:ac14:1400:ac14:1a29:0:2]) by mail.nic.cz (Postfix) with ESMTPSA id 24602734430; Fri, 23 Apr 2010 11:37:38 +0200 (CEST) Message-ID: <4BD16A61.90301@nic.cz> Date: Fri, 23 Apr 2010 11:37:37 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: YAO Jiankang CC: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 References: <4BC720DE.8080900@nic.cz> <5C8B7499CFD24579BD7B75CB8050FDA1@local> <4BD0521B.9090803@nic.cz> <986F4044CBEE422BB769C7BA94B90BF2@local> <4BD064E4.9060700@nic.cz> <201004230031.o3N0VRQb069783@drugs.dv.isc.org> <4BD1558D.5090703@nic.cz> <472013124.07253@cnnic.cn> In-Reply-To: <472013124.07253@cnnic.cn> 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 23.4.2010 10:58, YAO Jiankang wrote: > >> So it looks like those two common existing implementation are already >> ready for CNAME+DNAME. >> >> And that's exacly my point - with very simple change in CNAME semantics >> we can get full alias in the DNS tree, which is already supported by >> majority of DNS servers in the wild (at least those supporting DNAME). >> > > the CNAME is the basic record. many protocols base on it. That's not true. No protocol I know except DNS rely on CNAME. All other protocols asks for A,AAAA (usually via getaddrinfo via your resolver), MX, SRV, etc. I am not aware of any protocol directly asking for CNAME records. > if you want to break CNAME, you are trying to shake the basis of DNS. I am not breaking CNAME. If you think I am breaking CNAME please prove it or stop saying that. I am enhancing CNAME semantics to allow coexistence with DNAME. CNAME and DNAME don't share same alias space. Also there is no change by default - it could only affect other party in case you also add DNAME. > if you build a rule, 1000 users have followed it and you may update or modify the rule. > > if you build a rule, 1000,000,000 users have followed it and you should be CAUTION when you wish to update or modify the rule. > > if a new Record is submitted, someone may choose to follow or not. > but if you change the basic rule, you must push each of 1000,000,000 users to follow it. Sorry, but no, that's not true either. This could possibly break some authoritative and/or recursive DNS server. But in a way which is exactly same as adding new RRTYPE - since nobody is forced to add CNAME+DNAME to it's zone. And I have already proven that it doesn't break Bind 9 or Unbound functioning as resolvers, and that's mainly because there are already much worse scenarios in DNS tree - as I have also shown with idos.cz case. And I am willing to retest more resolvers (including older versions of Bind9), I just don't have a time for it right now. It will have no impact on common end user - because in normal circumstances CNAME is not used directly - it's handled by resolvers. Also loosening CNAME rules will not break anything for 1.000.000.000 users already using CNAMEs. It will only affect: 1) users adding CNAME+DNAME to their zones 2) users using such zones But that's not different from BNAME. I know I am touching the very basics of DNS and I also consider RFC1034 and RFC1034 to be sacred :-), but please let's work with facts, test cases, test scenarios etc. If you feel that CNAME+DNAME proposal breaks anything, please provide a test case. I would be first to say we should drop CNAME+DNAME if there is a serious breakage somewhere, but we should not reject the proposal based on Fear, Uncertainty, Doubt (tm). Also anybody is free to use experimental dname.cz zone, I am willing to add any combination of records to the zone, so you can test whatever protocol and test case you want. I could add simplified/mandarIDN f.e. if you want. BTW let me show you something, try pasting these into your browser: www.cnnic.测试.dname.cz www.cnnic.測試.dname.cz in punycode: www.cnnic.xn--0zwm56d.dname.cz www.cnnic.xn--g6w251d.dname.cz And check your mail log for rejected mail sent to: yaojk@cnnic.xn--0zwm56d.dname.cz and yaojk@cnnic.xn--g6w251d.dname.cz I put those two email addresses to Bcc:, so we don't keep them in next conversation. Ondrej > Jiankang Yao > > > >> I am sure that this will break something somewhere, but those place >> would be broken with BNAME as well. But BNAME has to be implemented >> everywhere - authoritative DNS, resolvers, firewalls, etc. >> >> Don't get me wrong, I think that BNAME is fine proposal, but I think >> that we have much simpler option right before us. Also it not something >> new, we did change semantics of CNAME before, because of DNSSEC, so I am >> not proposing revolution, just merging of two existing working principles. Ondrej -- Ondřej Surý vedoucí výzkumu/R&D manager ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From owner-namedroppers@ops.ietf.org Fri Apr 23 06:07:39 2010 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 1139328C10A; Fri, 23 Apr 2010 06:07:39 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 3.221 X-Spam-Level: *** X-Spam-Status: No, score=3.221 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_14=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.041, MSGID_FROM_MTA_HEADER=0.803, 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 EsUqGsGmpAPa; Fri, 23 Apr 2010 06:07:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 43D9428C305; Fri, 23 Apr 2010 05:52:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5IDx-000FRm-CV for namedroppers-data0@psg.com; Fri, 23 Apr 2010 12:43:13 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5IDs-000FOU-0q for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 12:43:08 +0000 Received: (eyou send program); Fri, 23 Apr 2010 20:43:06 +0800 Message-ID: <472026586.10639@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO abc) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 23 Apr 2010 20:43:06 +0800 Message-ID: <49477589D2854564BE7F22875E2E4BCE@abc> From: "Yao Jiankang" To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Cc: "Mark Andrews" , References: <4BC720DE.8080900@nic.cz> <5C8B7499CFD24579BD7B75CB8050FDA1@local> <4BD0521B.9090803@nic.cz> <986F4044CBEE422BB769C7BA94B90BF2@local> <4BD064E4.9060700@nic.cz> <201004230031.o3N0VRQb069783@drugs.dv.isc.org> <4BD1558D.5090703@nic.cz> <472013124.07253@cnnic.cn> <472015463.07253@cnnic.cn> Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 Date: Fri, 23 Apr 2010 20:43:02 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk9uZMWZZWogU3Vyw70iIDxv bmRyZWouc3VyeUBuaWMuY3o+DQpUbzogIllBTyBKaWFua2FuZyIgPHlhb2prQGNubmljLmNuPg0K Q2M6ICJNYXJrIEFuZHJld3MiIDxtYXJrYUBpc2Mub3JnPjsgPG5hbWVkcm9wcGVyc0BvcHMuaWV0 Zi5vcmc+DQpTZW50OiBGcmlkYXksIEFwcmlsIDIzLCAyMDEwIDU6MzcgUE0NClN1YmplY3Q6IFJl OiBbZG5zZXh0XSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3VyeS1k bnNleHQtY25hbWUtZG5hbWUtMDANCg0KDQo+IE9uIDIzLjQuMjAxMCAxMDo1OCwgWUFPIEppYW5r YW5nIHdyb3RlOg0KPj4NCj4+PiBTbyBpdCBsb29rcyBsaWtlIHRob3NlIHR3byBjb21tb24gZXhp c3RpbmcgaW1wbGVtZW50YXRpb24gYXJlIGFscmVhZHkNCj4+PiByZWFkeSBmb3IgQ05BTUUrRE5B TUUuDQo+Pj4NCj4+PiBBbmQgdGhhdCdzIGV4YWNseSAgbXkgcG9pbnQgLSB3aXRoIHZlcnkgc2lt cGxlIGNoYW5nZSBpbiBDTkFNRSBzZW1hbnRpY3MNCj4+PiB3ZSBjYW4gZ2V0IGZ1bGwgYWxpYXMg aW4gdGhlIEROUyB0cmVlLCB3aGljaCBpcyBhbHJlYWR5IHN1cHBvcnRlZCBieQ0KPj4+IG1ham9y aXR5IG9mIEROUyBzZXJ2ZXJzIGluIHRoZSB3aWxkIChhdCBsZWFzdCB0aG9zZSBzdXBwb3J0aW5n IEROQU1FKS4NCj4+Pg0KPj4NCj4+IHRoZSBDTkFNRSBpcyB0aGUgYmFzaWMgcmVjb3JkLiBtYW55 IHByb3RvY29scyBiYXNlIG9uIGl0Lg0KPiANCj4gVGhhdCdzIG5vdCB0cnVlLiAgTm8gcHJvdG9j b2wgSSBrbm93IGV4Y2VwdCBETlMgcmVseSBvbiBDTkFNRS4gIEFsbCANCj4gb3RoZXIgcHJvdG9j b2xzIGFza3MgZm9yIEEsQUFBQSAodXN1YWxseSB2aWEgZ2V0YWRkcmluZm8gdmlhIHlvdXIgDQo+ IHJlc29sdmVyKSwgTVgsIFNSViwgZXRjLiAgSSBhbSBub3QgYXdhcmUgb2YgYW55IHByb3RvY29s IGRpcmVjdGx5IGFza2luZyANCj4gZm9yIENOQU1FIHJlY29yZHMuDQoNCg0KYnV0IG1hbnkgcHJ0 b3RvY29scyB3aWxsIGRlYWwgd2l0aCB0aGUgQ05BTUUgaXNzdWVzLiANCg0KZm9yIGV4YW1wbGUg UkZDIDI4MjEgNTMyMQ0KPiANCj4+IGlmIHlvdSB3YW50IHRvIGJyZWFrIENOQU1FLCAgeW91IGFy ZSB0cnlpbmcgdG8gc2hha2UgdGhlIGJhc2lzIG9mIEROUy4NCj4gDQo+IEkgYW0gbm90IGJyZWFr aW5nIENOQU1FLiAgSWYgeW91IHRoaW5rIEkgYW0gYnJlYWtpbmcgQ05BTUUgcGxlYXNlIHByb3Zl IA0KPiBpdCBvciBzdG9wIHNheWluZyB0aGF0LiAgSSBhbSBlbmhhbmNpbmcgQ05BTUUgc2VtYW50 aWNzIHRvIGFsbG93IA0KPiBjb2V4aXN0ZW5jZSB3aXRoIEROQU1FLiAgDQoNCndoZXRoZXIgeW91 IHVzZSAiYnJlYWtpbmciIG9yICJlbmhhbmNpbmciLCB0aGUgZmFjdCBpcyB0aGF0IHlvdSB3aWxs IGNoYW5nZSBzb21lIHJ1bGVzIHNldCBmb3IgQ05BTUUuDQoNCg0KPkNOQU1FIGFuZCBETkFNRSBk b24ndCBzaGFyZSBzYW1lIGFsaWFzIHNwYWNlLiANCj4gQWxzbyB0aGVyZSBpcyBubyBjaGFuZ2Ug YnkgZGVmYXVsdCAtIGl0IGNvdWxkIG9ubHkgYWZmZWN0IG90aGVyIHBhcnR5IGluIA0KPiBjYXNl IHlvdSBhbHNvIGFkZCBETkFNRS4NCj4gDQo+PiBpZiB5b3UgYnVpbGQgYSBydWxlLCAxMDAwIHVz ZXJzIGhhdmUgZm9sbG93ZWQgaXQgYW5kIHlvdSBtYXkgdXBkYXRlIG9yIG1vZGlmeSB0aGUgcnVs ZS4NCj4+DQo+PiBpZiB5b3UgYnVpbGQgYSBydWxlLCAxMDAwLDAwMCwwMDAgdXNlcnMgaGF2ZSBm b2xsb3dlZCBpdCBhbmQgeW91IHNob3VsZCBiZSBDQVVUSU9OIHdoZW4geW91IHdpc2ggdG8gdXBk YXRlIG9yIG1vZGlmeSB0aGUgcnVsZS4NCj4+DQo+PiBpZiBhIG5ldyBSZWNvcmQgaXMgc3VibWl0 dGVkLCBzb21lb25lIG1heSBjaG9vc2UgdG8gZm9sbG93IG9yIG5vdC4NCj4+IGJ1dCBpZiB5b3Ug Y2hhbmdlIHRoZSBiYXNpYyBydWxlLCB5b3UgbXVzdCBwdXNoIGVhY2ggb2YgMTAwMCwwMDAsMDAw IHVzZXJzICB0byBmb2xsb3cgaXQuDQo+IA0KPiBTb3JyeSwgYnV0IG5vLCB0aGF0J3Mgbm90IHRy dWUgZWl0aGVyLiAgVGhpcyBjb3VsZCBwb3NzaWJseSBicmVhayBzb21lIA0KPiBhdXRob3JpdGF0 aXZlIGFuZC9vciByZWN1cnNpdmUgRE5TIHNlcnZlci4gDQoNCmhlcmUsIHlvdSdkIGJldHRlciBz YXkgInlvdSBhcmUgZW5oYW5jaW5nLi4uIiBpbnN0ZWFkIG9mICBzYXlpbmcgImJyZWFrIHNvbWUg YXV0aG9yaXRhdGl2ZSAuLi4uLi4iDQo6KQ0KDQoNCkppYW5rYW5nIFlhbw0K From owner-namedroppers@ops.ietf.org Fri Apr 23 06:14:51 2010 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 B0E0F3A69AA; Fri, 23 Apr 2010 06:14:51 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.696 X-Spam-Level: ** X-Spam-Status: No, score=2.696 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_55=0.6, J_CHICKENPOX_61=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 dyF4faBNAtKy; Fri, 23 Apr 2010 06:14:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 621423A6A6A; Fri, 23 Apr 2010 06:04:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5IUQ-000Jt9-6D for namedroppers-data0@psg.com; Fri, 23 Apr 2010 13:00:14 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5IUM-000JsT-7C for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 13:00:10 +0000 Received: (eyou send program); Fri, 23 Apr 2010 21:00:09 +0800 Message-ID: <472027609.32676@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO abc) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 23 Apr 2010 21:00:09 +0800 Message-ID: <960980B4EA9244D7901B20019153D559@abc> From: "Yao Jiankang" To: "Andrew Sullivan" , "Vaggelis Segredakis" Cc: "'Niall O'Reilly'" , , "'Sotiris Panaretou'" References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <471859708.23475@cnnic.cn> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT aliasmaybe-work Date: Fri, 23 Apr 2010 21:00:07 +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.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: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFuZHJldyBTdWxsaXZhbiIg PGFqc0BzaGlua3Vyby5jb20+DQpUbzogIlZhZ2dlbGlzIFNlZ3JlZGFraXMiIDxzZWdyZWRAaWNz LmZvcnRoLmdyPg0KQ2M6ICInTmlhbGwgTydSZWlsbHknIiA8TmlhbGwub1JlaWxseUB1Y2QuaWU+ OyA8bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZz47ICInU290aXJpcyBQYW5hcmV0b3UnIiA8c290 aXJpc0B1Y3kuYWMuY3k+DQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDIxLCAyMDEwIDEwOjAzIFBN DQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gSUNBTk4ncyAic3luY2hyb25pemVkIGRvbWFpbnMiIGFu ZCB0aGUgRE5TRVhUIGFsaWFzbWF5YmUtd29yaw0KDQoNCj4gT24gV2VkLCBBcHIgMjEsIDIwMTAg YXQgMTI6MDg6NDVQTSArMDMwMCwgVmFnZ2VsaXMgU2VncmVkYWtpcyB3cm90ZToNCj4gDQo+PiB0 aGUgc2FtZS4gSSBhbSBwcmV0dHkgc3VyZSBub2JvZHkgd2lsbCBldmVyIHdpc2ggdG8gc2V0IHVw IGFuIGVtYWlsIGFjY291bnQNCj4+IG9mIHRoZSB0eXBlIG1haWxAdGxkMSBhbmQgd2lzaCB0byBt YWtlIGl0IG9wZXJhdGl2ZSBmb3IgbWFpbEB0bGQyLiBJZiB5b3UgZG8NCj4+IG5vdCBmYWNlIHN1 Y2ggYSBwcm9ibGVtIHRoZW4gd2h5IG5vdCB1c2luZyB0aGUgRE5BTUUgZm9yIHRoaXMgZXF1YWxp dHkNCj4+IGlzc3VlPw0KPj4gDQo+PiBIb3dldmVyLCB0aGlzIGlzIG5vdCB0aGUgY2FzZSBpZiB5 b3UgZGlzY3VzcyBkb21haW4gbmFtZXMgdW5kZXIgYSBUTEQuIElmDQo+PiB0aGVyZSB3aGVyZSB0 d28gd2F5cyB0byBzcGVsbCBzaGlua3Vyby5jb20sIGJvdGggb2YgdGhlbSBjb3JyZWN0LCB3b3Vs ZA0KPj4gQW5kcmV3IHdpc2ggdG8gcmVjZWl2ZSBhbGwgb2YgaGlzIGVtYWlscyBjb3JyZWN0bHk/ IEkgYmVsaWV2ZSBoZSB3b3VsZC4NCj4gDQo+IEJ1dCB0aGUgQk5BTUUgcHJvcG9zYWwsIGFzIHdy aXR0ZW4sIHdvdWxkbid0IGFsbG93IHRoaXMgZWl0aGVyLiAgVGhhdA0KPiBpcywgaWYgeW91IGhh ZCAoc29tZS5sYWJlbC50bGQgQk5BTUUgb3RoZXIubGFiZWwudGxkKSwgdGhlbiB5b3UgY291bGQN Cj4gbm90IHVzZSBzb21lLmxhYmVsLnRsZCBhcyB0aGUgdGFyZ2V0IG9mIGFuIE1YIHJlY29yZCwg YW55IG1vcmUgdGhhbg0KPiB5b3UnZCBiZSBhbGxvd2VkIHRvIGRvIHRoYXQgd2l0aCBhIENOQU1F LiAgQk5BTUUgY2xlYXJseSBkb2VzIG5vdA0KPiBzb2x2ZSB0aGUgIm1haWwgc2VydmVyIGlzc3Vl IiBmb3IgYWxpYXNpbmcgYW55IG1vcmUgdGhhbiBDTkFNRSBkb2VzLg0KPiANCj4+IGNyZWF0ZWQg RE5BTUUsIHdoaWNoIGluIHJlYWxpdHkgaXMgYSBzdWItbWVjaGFuaXNtIG9mIG91ciByZXF1ZXN0 LiBXZSB3b3VsZA0KPj4gbGlrZSBETkFNRSB0byBzdGFydCByaWdodCBmcm9tIHRoZSB0b3AsIGFz IGl0IHdhcyBkaXNjdXNzZWQgYmVmb3JlKGENCj4+IG1lY2hhbmlzbSB0aGF0IG9wZXJhdGVzIGxp a2UgRE5BTUUrQ05BTUUgZnJvbSB0aGUgZmlyc3QgbGV2ZWwgb2YgZXF1YWxpdHkNCj4+IGFuZCBi ZWxvdyB0aGF0KS4NCj4gDQo+IEdpdmVuIHRoZSB0aHJlZSB0eXBlcyBvZiByZWRpcmVjdGlvbiB0 aGF0IEkgcHJldmlvdXNseSBvdXRsaW5lZCwgd2hpY2gNCj4gb2YgdGhlbSAoYW5kIHRvIHdoYXQg ZXh0ZW50KSBkbyB5b3UgdGhpbmsgdGhlIEJOQU1FIHByb3Bvc2FsIHNvbHZlcz8NCj4gVG8gcmVt aW5kLCBJIG9mZmVyZWQgdGhlc2UgdGhyZWUgY2FuZGlkYXRlcyAoc2VlDQo+IGh0dHA6Ly9vcHMu aWV0Zi5vcmcvbGlzdHMvbmFtZWRyb3BwZXJzL25hbWVkcm9wcGVycy4yMDEwL21zZzAwODkwLmh0 bWwpLg0KPiBJIHJlcGVhdCB3aGF0IEkgcHJldmlvdXNseSB3cm90ZSwgd2l0aCBhIG1vZGlmaWNh dGlvbiB0byBhdm9pZCB0aGlzDQo+IHJhdGhvbGluZyBpbnRvIGEgcXVlc3Rpb24gYWJvdXQgVExE cy4gIEl0J3MgZnVsbHkgZ2VuZXJhbGl6YWJsZToNCj4gDQo+IFN1cHBvc2UgdGhhdCB3ZSBoYXZl IFtuYW1lMV0gYW5kIFtuYW1lMl0sIGFuZCB0aGV5J3JlIHN1cHBvc2VkIHRvIGJlDQo+IGVxdWl2 YWxlbnQuICBUaGVzZSBuYW1lcyBtYXkgYmUgbWFkZSBvZiBtb3JlIHRoYW4gb25lIGxhYmVsLiAg W25hbWUxXQ0KPiBjb21lcyBmcm9tIG9uZSByZXBldG9pcmUgb2YgVW5pY29kZSBjaGFyYWN0ZXJz LiAgQ2FsbCBpdCByYW5nZTEuDQo+IFtuYW1lMl0gY29tZXMgZnJvbSBhbm90aGVyIHJlcGV0b2ly ZSBvZiBVbmljb2RlIGNoYXJhY3RlcnMuICBDYWxsIGl0DQo+IHJhbmdlMi4gIFRoZSBvbmx5IHJl c3RyaWN0aW9uIGlzIHRoYXQgcmFuZ2UxIGFuZCByYW5nZTIgaGF2ZSBhdCBsZWFzdA0KPiBvbmUg Y2hhcmFjdGVyIHRoYXQgZGlmZmVycyBiZXR3ZWVuIHRoZW0gKHRoZXkncmUgbm90IGVxdWl2YWxl bnQgc2V0cy4NCj4gSW4gdGhlIHVubGlrZWx5IGV2ZW50IHRoYXQgYW55IHBlb3BsZSB3aG8ga25v dyBhYm91dCB3cml0aW5nIHN5c3RlbXMNCj4gYXJlIHJlYWRpbmcgdGhpcywgSSB1bmRlcnN0YW5k IHRoYXQgdGhpcyBzaW1wbGlmeWluZyBhc3N1bXB0aW9uIGlzDQo+IGFscmVhZHkgcmVhbGx5IGJh ZC4gIE5ldmVyIG1pbmQgdGhhdCkuICBOb3csIHN1cHBvc2Ugd2UgaGF2ZSBhbnkgc2V0cw0KPiBv ZiBsYWJlbHMsIGVhY2ggb2Ygd2hpY2ggaXMgZWl0aGVyIGluIHJhbmdlMSAoc3ltYm9saXplZCBy MSkgb3INCj4gcmFuZ2UyIChzeW1ib2xpemVkIHIyKS4gIFdoaWNoIG9mIHRoZSBmb2xsb3dpbmcg YmVoYXZpb3VycyBpcw0KPiBkZXNpcmVkOg0KPiANCj4gICAgICAgICBhLiAgU2hvdWxkIEROUyBu YW1lcyBpbiB0aGUgem9uZXMgdW5kZXJuZWF0aCB0aGUgdHdvDQo+ICAgICAgICAgc3luY2hyb25p emVkIHpvbmVzIGJlIGV4YWN0bHkgKGJpdC1mb3ItYml0KSBlcXVpdmFsZW50IHRvIG9uZQ0KPiAg ICAgICAgIGFub3RoZXI/ICBGb3IgZXhhbXBsZSwgZm9yIGEgZnVsbHkgcXVhbGlmaWVkIGRvbWFp biBuYW1lIG9mDQo+ICAgICAgICAgdGhlIGZvcm0gcjEucjEuW25hbWUxXSwgbXVzdCB0aGVyZSBh bHdheXMgYW5kIG9ubHkgYmUgYQ0KPiAgICAgICAgIHN5bmNocm9uaXplZCBlbnRyeSByMS5yMS5b bmFtZTJdPw0KPiANCj4gICAgICAgICBiLiAgU2hvdWxkIGFsbCBhbmQgZXZlcnkgbGFiZWwgdW5k ZXIgW25hbWUxXSBiZSBleHByZXNzZWQgaW4gTEUxDQo+ICAgICAgICAgYW5kIGFsbCBhbmQgZXZl cnkgbGFiZWwgdW5kZXIgVExEMiBiZSBleHByZXNzZWQgaW4gW25hbWUyXT8gIEZvcg0KPiAgICAg ICAgIGV4YW1wbGUsIGZvciBhIGZ1bGx5IHF1YWxpZmllZCBkb21haW4gb2YgdGhlIGZvcm0gcjEu cjEuW25hbWUxXQ0KPiAgICAgICAgIG11c3QgdGhlcmUgYWx3YXlzIGFuZCBvbmx5IGJlIGEgc3lu Y2hyb25pemVkIGVudHJ5DQo+ICAgICAgICAgcjIucjIuW25hbWUyXT8NCj4gDQo+ICAgICAgICAg Yy4gIFNob3VsZCBldmVyeSBsYWJlbCBhdCBldmVyeSBsZXZlbCBvZiB0aGUgRE5TIGJlIGV4cHJl c3NlZA0KPiAgICAgICAgIGluIGJvdGggTEUxIGFuZCBMRTIgKHRoZSBjb21iaW5hdG9yaWFsIGNh c2UpPyAgRm9yIGV4YW1wbGUsDQo+ICAgICAgICAgZm9yIGEgZnVsbHkgcXVhbGlmaWVkIGRvbWFp biBuYW1lIG9mIHRoZSBmb3JtDQo+ICAgICAgICAgcjEucjEucjEuW25hbWUxXSwgd291bGQgaXQg YmUgbmVjZXNzYXJ5IGFsc28gdG8gaGF2ZQ0KPiAgICAgICAgIHIxLnIxLnIxLltuYW1lMl0sIHIy LnIxLnIxLltuYW1lMl0sIHIyLnIyLnIxLltuYW1lMiwNCj4gICAgICAgICByMi5yMi5yMi5bbmFt ZTJdLCByMS5yMi5yMi5bbmFtZTJdLCBhbmQgc28gb24/DQo+IA0KPiBNeSB1bmRlcnN0YW5kaW5n IG9mIHRoZSBCTkFNRSBwcm9wb3NhbCBpcyB0aGF0IGl0IHdpbGwgd29yayBmaW5lIGZvcg0KPiAo YSkgYW5kIChjKSBidXQgbm90IChiKSwNCg0KbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IEJOQU1F IHdvcmtzIGZvciBjYXNlIChiKSB0b28uDQoNCmlmIHlvdSB3YW50ICByMS5yMS5bbmFtZTFdIHRv IGJlIGVxdWFsIHdpdGggcjIucjIuW25hbWUyXSwgeW91ciBhc3N1bXB0aW9uIGlzIHIxPXIyLg0K DQpzbyB3ZSBzZXQNCg0KIC5uYW1lMSBCTkFNRSAuIG5hbWUyIGluIHRoZSB0b3Agem9uZS4NCg0K aW4gLm5hbWUyIHpvbmUsDQp3ZSBqdXN0IHNldA0KIHIyLnIyLm5hbWUyIEJOQU1FIHIxLnIxLm5h bWUyDQpvciANCiAgIHIyLm5hbWUyIEJOQU1FICByMS5uYW1lMg0KDQoNCkppYW5rYW5nIFlhbw0K DQoNCg0KDQo+IHRoYXQgZm9yIChjKSBpdCByZXF1aXJlcyBubyBsZXNzIHdvcmsgdGhhbg0KPiBq dXN0IHVzaW5nIEROQU1FIGV4Y2VwdCB0aGF0IGZvciBETkFNRSB5b3UgYWxzbyBuZWVkIGFuIEEg cmVjb3JkIGF0DQo+IFtuYW1lMV0gYW5kIFtuYW1lMl0gZm9yIGV2ZXJ5IEROQU1FLCBhbmQgdGhh dCBleGFjdGx5IG9uZSBvZiB0aGUNCj4gYWx0ZXJuYXRpdmUgdHJlZXMgd2lsbCBiZSBhbGxvd2Vk IGFzIGEgdGFyZ2V0IGZvciBNWCByZWNvcmRzLiAgSXMgdGhhdA0KPiB5b3VyIHJlYWRpbmcgYXMg d2VsbD8NCj4gDQo+IEJlc3QsDQo+IA0KPiBBDQo+IA0KPiAtLSANCj4gQW5kcmV3IFN1bGxpdmFu DQo+IGFqc0BzaGlua3Vyby5jb20NCj4gU2hpbmt1cm8sIEluYy4NCj4gDQo+ From owner-namedroppers@ops.ietf.org Fri Apr 23 08:59:20 2010 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 BFEE63A6A86; Fri, 23 Apr 2010 08:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.085 X-Spam-Level: X-Spam-Status: No, score=-0.085 tagged_above=-999 required=5 tests=[AWL=-0.485, 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 2b3HTlXy90uO; Fri, 23 Apr 2010 08:59:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D260C3A6A85; Fri, 23 Apr 2010 08:59:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5LCV-0006jI-Ac for namedroppers-data0@psg.com; Fri, 23 Apr 2010 15:53:55 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5LCQ-0006dE-KI for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 15:53:50 +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 B88DB1ECB400 for ; Fri, 23 Apr 2010 15:53:48 +0000 (UTC) Date: Fri, 23 Apr 2010 11:53:47 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Use the layers, Luke! Message-ID: <20100423155346.GE3611@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF440F.1090501@ucd.ie> <20100421195653.GD912@shinkuro.com> <4BD15F07.2070801@ucd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD15F07.2070801@ucd.ie> 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 Fri, Apr 23, 2010 at 09:49:11AM +0100, Niall O'Reilly wrote: > Case (b) is so pathological that I believe it is best placed > explicitly out of scope. This case represents a giant cluster of > equivalences between corresponding pairs of FQDNs. These > pairwise equivalences are not hierarchically aggregable, even > at the level of a leaf zone. > > Case (b) is an excellent example of how a particular choice > at the policy level may lead to an intractable "requirement" > for implementation. It's interesting that you might want to rule (b) out of scope, because one of the most plausible interpretations I was able to construct of the ICANN "synchronized domains" plan was in fact this one. Several people told me that (c) was for sure out of scope, and others told me that (a) wouldn't actually solve the problem people had. I'm sorry it's taken me this long to get across what I'm worried about. I agree with you that (b) is a serious problem, and is probably something we're not going to be able to accommodate very easily (unless I've missed something in the BNAME proposal. More on this down-thread). But this is why I think it very important we come to some agreement on what the problems are we're trying to solve (or even simply that we can't solve). A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Apr 23 09:06:35 2010 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 564483A6872; Fri, 23 Apr 2010 09:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.074 X-Spam-Level: X-Spam-Status: No, score=-0.074 tagged_above=-999 required=5 tests=[AWL=-0.474, 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 ZdWdPR-gh7oE; Fri, 23 Apr 2010 09:06:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DFD8A3A6A88; Fri, 23 Apr 2010 09:06:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5LKv-0008bZ-OS for namedroppers-data0@psg.com; Fri, 23 Apr 2010 16:02:37 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5LKt-0008bA-27 for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 16:02: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 CC72A1ECB400 for ; Fri, 23 Apr 2010 16:02:33 +0000 (UTC) Date: Fri, 23 Apr 2010 12:02:32 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT aliasmaybe-work Message-ID: <20100423160231.GF3611@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <471859708.23475@cnnic.cn> <960980B4EA9244D7901B20019153D559@abc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <960980B4EA9244D7901B20019153D559@abc> 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 Fri, Apr 23, 2010 at 09:00:07PM +0800, Yao Jiankang wrote: > > b. Should all and every label under [name1] be expressed in LE1 > > and all and every label under TLD2 be expressed in [name2]? For > > example, for a fully qualified domain of the form r1.r1.[name1] > > must there always and only be a synchronized entry > > r2.r2.[name2]? > > my understanding is that BNAME works for case (b) too. > > if you want r1.r1.[name1] to be equal with r2.r2.[name2], your assumption is r1=r2. > > so we set > > .name1 BNAME . name2 in the top zone. > > in .name2 zone, > we just set > r2.r2.name2 BNAME r1.r1.name2 > or > r2.name2 BNAME r1.name2 That collapses to case (c), because both zones end up with a copy of everything, all the way down, right? That is, if you look up r2.name1, you get redirected to r2.name2, no? So, to be strict, this doesn't meet the rule because of the "always and only" restriction. If that's acceptable, then ok. But I'd been led to believe that it was not. On the contrary, I'd been let to believe that one implementation, actually the target of the synchronized domains proposal, implements two completely different trees. In that particular case, one tree uses one subset of a script, and the other tree uses a different subset of the same script. If you're in the "script subset 1 tree", and you use a character from "script subset 2", you don't get anywhere. Perhaps you have details of a use case in mind that would be more relevant, though? Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Apr 23 09:16:04 2010 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 EE9FA3A6A79; Fri, 23 Apr 2010 09:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.236 X-Spam-Level: X-Spam-Status: No, score=0.236 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 aj8NzM0zeTTy; Fri, 23 Apr 2010 09:16:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A6FC3A6A9B; Fri, 23 Apr 2010 09:15:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5LTx-000AnX-8n for namedroppers-data0@psg.com; Fri, 23 Apr 2010 16:11:57 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5LTu-000An6-Ug for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 16:11:55 +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 CA5EF1ECB400 for ; Fri, 23 Apr 2010 16:11:53 +0000 (UTC) Date: Fri, 23 Apr 2010 12:11:52 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: BNAME, Synthesized CNAME, and DNSSEC (was: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work) Message-ID: <20100423161151.GH3611@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <20100422171521.GK1362@shinkuro.com> <201004230447.o3N4lsSv071899@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201004230447.o3N4lsSv071899@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: No hat. On Fri, Apr 23, 2010 at 02:47:54PM +1000, Mark Andrews wrote: > Firstly it wouldn't be double. You would create aliases for > RSASHA256, RSASHA512, NSEC3DSA and ECC-GOST. RSAMD5, DSA, RSASHA1 > and NSEC3RSASHA1 would not get aliases. One could argue about > NSEC3RSASHA1 but I believe it is reasonable not to create a alias > for it. Why are those ones special? I can probably see the argument for MD5, but the rest look to me to increase fragility. Note, also, that we have recently sent a document about assignment of code points out to the IESG. I'd be astonished if we didn't allocate some more code points before BNAME is standardized. > Secondly one very rarely changes the rules associated with validation. > This shouldn't be thought of as a new type but a new method of > synthesis. I can accept this argument. I'm just pointing out that people were pretty uncomfortable with the potential to go through code points to allocate, and if this is our answer we're going to use them up even faster. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Apr 23 09:32:15 2010 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 2028E3A68DF; Fri, 23 Apr 2010 09:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] 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 NH4-DwLMvZx6; Fri, 23 Apr 2010 09:32:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 23C623A68C7; Fri, 23 Apr 2010 09:32:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5LjK-000EJp-Ca for namedroppers-data0@psg.com; Fri, 23 Apr 2010 16:27:50 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5LjI-000EJC-4g for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 16:27:48 +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 20AFDE947F; Fri, 23 Apr 2010 16:27:46 +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 o3NGRiPr066090; Sat, 24 Apr 2010 02:27:44 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004231627.o3NGRiPr066090@drugs.dv.isc.org> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <20100422171521.GK1362@shinkuro.com> <201004230447.o3N4lsSv071899@drugs.dv.isc.org> <20100423161151.GH3611@shinkuro.com> Subject: Re: BNAME, Synthesized CNAME, and DNSSEC (was: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work) In-reply-to: Your message of "Fri, 23 Apr 2010 12:11:52 -0400." <20100423161151.GH3611@shinkuro.com> Date: Sat, 24 Apr 2010 02:27:44 +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 <20100423161151.GH3611@shinkuro.com>, Andrew Sullivan writes: > No hat. > > On Fri, Apr 23, 2010 at 02:47:54PM +1000, Mark Andrews wrote: > > Firstly it wouldn't be double. You would create aliases for > > RSASHA256, RSASHA512, NSEC3DSA and ECC-GOST. RSAMD5, DSA, RSASHA1 > > and NSEC3RSASHA1 would not get aliases. One could argue about > > NSEC3RSASHA1 but I believe it is reasonable not to create a alias > > for it. > > Why are those ones special? I can probably see the argument for MD5, > but the rest look to me to increase fragility. NSEC3DSA is a superset of DSA so you don't need a alias for DSA that only does BNAME and not NSEC3. > Note, also, that we have recently sent a document about assignment of > code points out to the IESG. I'd be astonished if we didn't allocate > some more code points before BNAME is standardized. > > Secondly one very rarely changes the rules associated with validation. > > This shouldn't be thought of as a new type but a new method of > > synthesis. > > I can accept this argument. I'm just pointing out that people were > pretty uncomfortable with the potential to go through code points to > allocate, and if this is our answer we're going to use them up even > faster. Not really. Just a step not a multiplication. > A > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > -- 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 Apr 23 09:44:49 2010 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 C65F23A6A24; Fri, 23 Apr 2010 09:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.814 X-Spam-Level: X-Spam-Status: No, score=-97.814 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_50=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, 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 R6+utYsR+Umx; Fri, 23 Apr 2010 09:44:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8A0FB3A69A2; Fri, 23 Apr 2010 09:44:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5LwO-000HAT-Ux for namedroppers-data0@psg.com; Fri, 23 Apr 2010 16:41:20 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5LwL-000H9J-Tw for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 16:41:18 +0000 Received: from [IPv6:2001:1488:ac14:1400:ac14:1a29:0:2] (unknown [IPv6:2001:1488:ac14:1400:ac14:1a29:0:2]) by mail.nic.cz (Postfix) with ESMTPSA id EB407734365; Fri, 23 Apr 2010 18:41:15 +0200 (CEST) Message-ID: <4BD1CDAB.6080809@nic.cz> Date: Fri, 23 Apr 2010 18:41:15 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Yao Jiankang CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 References: <4BC720DE.8080900@nic.cz> <5C8B7499CFD24579BD7B75CB8050FDA1@local> <4BD0521B.9090803@nic.cz> <986F4044CBEE422BB769C7BA94B90BF2@local> <4BD064E4.9060700@nic.cz> <201004230031.o3N0VRQb069783@drugs.dv.isc.org> <4BD1558D.5090703@nic.cz> <472013124.07253@cnnic.cn> <472015463.07253@cnnic.cn> <472026586.10639@cnnic.cn> In-Reply-To: <472026586.10639@cnnic.cn> 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 23.4.2010 14:43, Yao Jiankang wrote: > > ----- Original Message ----- > From: "Ondřej Surý" > To: "YAO Jiankang" > Cc: "Mark Andrews"; > Sent: Friday, April 23, 2010 5:37 PM > Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 > > >> On 23.4.2010 10:58, YAO Jiankang wrote: >>> >>>> So it looks like those two common existing implementation are already >>>> ready for CNAME+DNAME. >>>> >>>> And that's exacly my point - with very simple change in CNAME semantics >>>> we can get full alias in the DNS tree, which is already supported by >>>> majority of DNS servers in the wild (at least those supporting DNAME). >>>> >>> >>> the CNAME is the basic record. many protocols base on it. >> >> That's not true. No protocol I know except DNS rely on CNAME. All >> other protocols asks for A,AAAA (usually via getaddrinfo via your >> resolver), MX, SRV, etc. I am not aware of any protocol directly asking >> for CNAME records. > > but many protocols will deal with the CNAME issues. > > for example RFC 2821 5321 I think that this part of SMTP standard is wrong. Users (applications or end users) of DNS should not resolve CNAMEs on their own. It should be handled either by full resolver or stub resolver in standard system library. Anyway the only breakage which could happen (AFAIK) is when: a) MTA implements a query cache b) the query cache is very strict on CNAMEs c) mail is sent to target.dname.cz and CNAME for target.dname.cz is stored in the cache d) mail is sent to www.target.dname.cz and the query cache tries to store everything received (including the DNAME) into the query cache. => error is reported when storing the DNAME record into the query cache But I dare to say that such implementation of dns client is broken. In normal circumstances all cases will be handled by DNAME compatibility layer (ie. returning autogenerated CNAMEs), so I still don't see where the breakage can be. Again I checked my MTA source code - postfix - there is not query cache in the code, there is no handling of DNAMEs, so I don't see how any breakage could occur by allowing CNAME+DNAME to live together. >>> if you want to break CNAME, you are trying to shake the basis of DNS. >> >> I am not breaking CNAME. If you think I am breaking CNAME please prove >> it or stop saying that. I am enhancing CNAME semantics to allow >> coexistence with DNAME. > > whether you use "breaking" or "enhancing", > the fact is that you will change some rules set for CNAME. I do, and I could change "enhancing" to "changing/modifying", but I am convinced that this change will have no bad impact on general internet, and I am not breaking CNAME in any way. Ondrej -- Ondřej Surý vedoucí výzkumu/R&D manager ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From owner-namedroppers@ops.ietf.org Fri Apr 23 09:52:47 2010 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 871FD3A6927; Fri, 23 Apr 2010 09:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.693 X-Spam-Level: * X-Spam-Status: No, score=1.693 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=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 7NfqrgZqeCVE; Fri, 23 Apr 2010 09:52:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 47B743A6774; Fri, 23 Apr 2010 09:52:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5M3b-000Iv0-Fu for namedroppers-data0@psg.com; Fri, 23 Apr 2010 16:48:47 +0000 Received: from [65.99.1.130] (helo=abenaki.wabanaki.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5M3Y-000IuP-N9 for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 16:48:45 +0000 Received: from limpet.local (cpe-67-244-32-202.twcny.res.rr.com [67.244.32.202]) by abenaki.wabanaki.net (8.14.4/8.14.3) with ESMTP id o3NGf9Of049788; Fri, 23 Apr 2010 12:41:10 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4BD1CF65.8070602@abenaki.wabanaki.net> Date: Fri, 23 Apr 2010 12:48:37 -0400 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Use the layers, Luke! References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF440F.1090501@ucd.ie> <20100421195653.GD912@shinkuro.com> <4BD15F07.2070801@ucd.ie> <20100423155346.GE3611@shinkuro.com> In-Reply-To: <20100423155346.GE3611@shinkuro.com> 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: On 4/23/10 4:49 AM, Niall O'Reilly wrote: > ... > Case (b) is so pathological that I believe it is best placed > explicitly out of scope. This case represents a giant cluster > of equivalences between corresponding pairs of FQDNs. These > pairwise equivalences are not hierarchically aggregable, even > at the level of a leaf zone. > > Case (b) is an excellent example of how a particular choice > at the policy level may lead to an intractable "requirement" > for implementation. I thought I pointed out that label length, while arbitrary in theory, as identifiers may, like words are, be built as compounds of Han characters, is predominantly five or fewer total Han characters, and that, orthogonally in theory but not independent in fact, characters for which a SC form exists have a higher stroke count than many characters present in two and more character names, and therefore, identifiers. That is, the correct characterization is not powers of 2, and therefore bounded above by 9,223,372,036,854,775,808 (2^^63, "xn--" being tossed aside like the base of a stalk of celery), but something quite a bit smaller, as the frequency of characters for which no simplified equivalence exists will be (a) 1 in identifiers composed and intended to be resolved only in the PRC, and greater than zero in identifiers composed, or intended to be resolved, outside of the PRC. My wild-ass-guess is that for strlen(label) <= 5, that the average for equivalency classes is bounded above by 2^^3, that is, on average, at least two characters do not exist in a simplified form. My wild-ass-guess is also that registries that offer equivalence without length restriction venture into self-injury terrain. However, having offered this observation previously, I've no idea why the exponential explosion is still lying around, periodically being used to blow the feet off of any proposal to actually look at the SC/TC problem as anything other than inherently intractable. I suppose I should use darker electrons or something, to obtain a bold effect for legibility, or electrons with sufficient spin to obtain an italic effect, for the same purpose. Case (b) is an excellent example of using less intellect than is available to misstate a problem and arrive at a deliciously intractable outcome. Eric From owner-namedroppers@ops.ietf.org Fri Apr 23 10:01:00 2010 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 1AE423A6A8A; Fri, 23 Apr 2010 10:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.882 X-Spam-Level: X-Spam-Status: No, score=0.882 tagged_above=-999 required=5 tests=[AWL=-1.377, BAYES_20=-0.74, 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 HQ-V2YrkQQzN; Fri, 23 Apr 2010 10:00:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1471E3A6A0E; Fri, 23 Apr 2010 10:00:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5MBC-000Kkb-55 for namedroppers-data0@psg.com; Fri, 23 Apr 2010 16:56:38 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5MBA-000KkE-2G for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 16:56:36 +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 B37DB1ECB400 for ; Fri, 23 Apr 2010 16:56:34 +0000 (UTC) Date: Fri, 23 Apr 2010 12:56:32 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Use the layers, Luke! Message-ID: <20100423165632.GK3611@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF440F.1090501@ucd.ie> <20100421195653.GD912@shinkuro.com> <4BD15F07.2070801@ucd.ie> <20100423155346.GE3611@shinkuro.com> <4BD1CF65.8070602@abenaki.wabanaki.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD1CF65.8070602@abenaki.wabanaki.net> 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 Fri, Apr 23, 2010 at 12:48:37PM -0400, Eric Brunner-Williams wrote: > However, having offered this observation previously, I've no idea why > the exponential explosion is still lying around, periodically being > used to blow the feet off of any proposal to actually look at the > SC/TC problem as anything other than inherently intractable. I don't actually think a combinatorial case is inherently intractable, first. But second and more importantly, we're not here trying to solve the TC/SC problem. If we were, our lives would be easier. What we are trying to do is create what I've come to think of as synonymy in the DNS, and if we have a way in which the solutions we pursue become seriously intractable, we need to be aware of that, _even if_ those solutions happen to solve a different class of problems. > Case (b) is an excellent example of using less intellect than is > available to misstate a problem and arrive at a deliciously > intractable outcome. What is the misstatement in (b)? The point in (b) is that the trees are distinct from one another, that each FQDN in either is a synonym for something in another tree, and that at least one label that would be permitted in the one tree is not allowed in the other tree. Somebody might want that, and people have claimed to me that people _did_ want that. I don't know whether anyone does, but we can surely admit that it's a possible case even if we subsequenrly decide that it's not a problem worth solving. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Apr 23 10:11:32 2010 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 41BE23A6829; Fri, 23 Apr 2010 10:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.018 X-Spam-Level: X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[AWL=-0.418, 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 6pJNKiurEbLO; Fri, 23 Apr 2010 10:11:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D8B9D3A6A59; Fri, 23 Apr 2010 10:11:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5MLl-000NNs-Nm for namedroppers-data0@psg.com; Fri, 23 Apr 2010 17:07:33 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5MLj-000NNF-4x for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 17:07:31 +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 E19F31ECB400 for ; Fri, 23 Apr 2010 17:07:29 +0000 (UTC) Date: Fri, 23 Apr 2010 13:07:28 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 Message-ID: <20100423170728.GL3611@shinkuro.com> References: <5C8B7499CFD24579BD7B75CB8050FDA1@local> <4BD0521B.9090803@nic.cz> <986F4044CBEE422BB769C7BA94B90BF2@local> <4BD064E4.9060700@nic.cz> <201004230031.o3N0VRQb069783@drugs.dv.isc.org> <4BD1558D.5090703@nic.cz> <472013124.07253@cnnic.cn> <472015463.07253@cnnic.cn> <472026586.10639@cnnic.cn> <4BD1CDAB.6080809@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4BD1CDAB.6080809@nic.cz> 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 Fri, Apr 23, 2010 at 06:41:15PM +0200, Ondřej Surý wrote: > I think that this part of SMTP standard is wrong. Users (applications > or end users) of DNS should not resolve CNAMEs on their own. Woah, nelly. Let's not put ourselves in the position of telling other applications what they should or should not be doing with data in the DNS, if for no other reason than that it runs exactly opposite to years of other advice. > a) MTA implements a query cache > b) the query cache is very strict on CNAMEs > c) mail is sent to target.dname.cz and CNAME for target.dname.cz is > stored in the cache > d) mail is sent to www.target.dname.cz and the query cache tries to > store everything received (including the DNAME) into the query cache. > > => error is reported when storing the DNAME record into the query cache > > But I dare to say that such implementation of dns client is broken. Why is it broken? The CNAME rules say nothing else should be at the CNAME. Your proposal violates that rule. You can't then say that someone checking that the CNAME doesn't have anything else at that name is actually broken: it isn't, at least today. I'm not saying we shouldn't make this change to CNAME and DNAME, but let us not dismiss the objection that we're making a change by begging the question. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Apr 23 10:49:51 2010 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 2A12C3A6907; Fri, 23 Apr 2010 10:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.205 X-Spam-Level: * X-Spam-Status: No, score=1.205 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=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 J5oEiXPtaab7; Fri, 23 Apr 2010 10:49:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 521F43A6899; Fri, 23 Apr 2010 10:49:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5MwI-0005Lk-Hk for namedroppers-data0@psg.com; Fri, 23 Apr 2010 17:45:18 +0000 Received: from [65.99.1.130] (helo=abenaki.wabanaki.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5MwF-0005L7-Ar for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 17:45:15 +0000 Received: from limpet.local (cpe-67-244-32-202.twcny.res.rr.com [67.244.32.202]) by abenaki.wabanaki.net (8.14.4/8.14.3) with ESMTP id o3NHbePr050153; Fri, 23 Apr 2010 13:37:40 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4BD1DCA4.8090807@abenaki.wabanaki.net> Date: Fri, 23 Apr 2010 13:45:08 -0400 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Use the layers, Luke! References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF440F.1090501@ucd.ie> <20100421195653.GD912@shinkuro.com> <4BD15F07.2070801@ucd.ie> <20100423155346.GE3611@shinkuro.com> <4BD1CF65.8070602@abenaki.wabanaki.net> <20100423165632.GK3611@shinkuro.com> In-Reply-To: <20100423165632.GK3611@shinkuro.com> 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: Where, other than in the SC/TC problem, does this exist? > a giant cluster > of equivalences between corresponding pairs of FQDNs. These > pairwise equivalences are not hierarchically aggregable, even > at the level of a leaf zone. Eric From owner-namedroppers@ops.ietf.org Fri Apr 23 10:59:56 2010 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 248093A6A00; Fri, 23 Apr 2010 10:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[AWL=-0.409, 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 UQzK5lpfdZSS; Fri, 23 Apr 2010 10:59:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4ABF03A69A2; Fri, 23 Apr 2010 10:59:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5N6F-0007b0-2c for namedroppers-data0@psg.com; Fri, 23 Apr 2010 17:55:35 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5N6D-0007aj-31 for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 17:55: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 A08021ECB400 for ; Fri, 23 Apr 2010 17:55:31 +0000 (UTC) Date: Fri, 23 Apr 2010 13:55:30 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Use the layers, Luke! Message-ID: <20100423175529.GP3611@shinkuro.com> References: <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF440F.1090501@ucd.ie> <20100421195653.GD912@shinkuro.com> <4BD15F07.2070801@ucd.ie> <20100423155346.GE3611@shinkuro.com> <4BD1CF65.8070602@abenaki.wabanaki.net> <20100423165632.GK3611@shinkuro.com> <4BD1DCA4.8090807@abenaki.wabanaki.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD1DCA4.8090807@abenaki.wabanaki.net> 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 Fri, Apr 23, 2010 at 01:45:08PM -0400, Eric Brunner-Williams wrote: > Where, other than in the SC/TC problem, does this exist? It makes no difference. We can't start screwing with the protocol in order to solve that particular problem and no other. We have to solve the general problem if we're solving anything in the DNS. It's quite another matter when you're dealing with particular provisioning systems or policies. But as I put up on the screen in Anaheim (the slides are available from the meeting materials site), we are not undertaking to solve the linguistic variants problem in this WG. We are not linguistically competent to do that, and anyway we're at the wrong layer. That is not to say we ignore linguistic variants as a use-case: it's what tickled this topic into our laps. But if there's something to do here, it is simply more general than that. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Apr 23 11:09:13 2010 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 667503A6AA3; Fri, 23 Apr 2010 11:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.545 X-Spam-Level: X-Spam-Status: No, score=-4.545 tagged_above=-999 required=5 tests=[AWL=0.503, 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 W6HJb7-g1O-a; Fri, 23 Apr 2010 11:09:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F1C7A3A6A00; Fri, 23 Apr 2010 11:09:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5NFF-0009uX-MR for namedroppers-data0@psg.com; Fri, 23 Apr 2010 18:04:53 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5NFC-0009sr-Us for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 18:04:51 +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 <0L1C00H01CSM8D00@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 19:04:48 +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 <0L1C005JECW0OS00@cali.ucd.ie>; Fri, 23 Apr 2010 19:04:48 +0100 (IST) Date: Fri, 23 Apr 2010 19:04:47 +0100 From: Niall O'Reilly Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT aliasmaybe-work In-reply-to: <472027609.32676@cnnic.cn> To: Yao Jiankang Cc: Andrew Sullivan , Vaggelis Segredakis , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Message-id: <4BD1E13F.6010606@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <471859708.23475@cnnic.cn> <472027609.32676@cnnic.cn> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) 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 23/04/10 14:00, Yao Jiankang wrote: > if you want r1.r1.[name1] to be equal with r2.r2.[name2], your assumption is r1=r2. I think Andrew meant class (b) specifically to exclude r1=r2. ATB Niall O'Reilly From owner-namedroppers@ops.ietf.org Fri Apr 23 11:16:44 2010 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 9A2883A6A71; Fri, 23 Apr 2010 11:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.976 X-Spam-Level: * X-Spam-Status: No, score=1.976 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_20=-0.74, 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 DSrI++Ei4KHW; Fri, 23 Apr 2010 11:16:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6BFB33A69B6; Fri, 23 Apr 2010 11:16:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5NNX-000BoL-LK for namedroppers-data0@psg.com; Fri, 23 Apr 2010 18:13:27 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5NNV-000Bo7-Bu for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 18:13:25 +0000 Received: by pwi1 with SMTP id 1so6768825pwi.11 for ; Fri, 23 Apr 2010 11:13:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.20.33 with SMTP id x33mr320181wfi.116.1272046403396; Fri, 23 Apr 2010 11:13:23 -0700 (PDT) Received: by 10.231.214.209 with HTTP; Fri, 23 Apr 2010 11:13:23 -0700 (PDT) Date: Fri, 23 Apr 2010 11:13:23 -0700 Message-ID: Subject: [dnsext] DNSCurve name server selection From: Matthew Dempsky To: IETF DNSEXT WG 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: For the DNSCurve I-D, I limited wording about how a cache should behave to that it MAY use DNSCurve when querying a server with a DNSCurve public key, but no advise is offered on when it should or how it should behave when some-but-not-all of a zone's name servers support DNSCurve. In particular, I can see a number of possible cache behaviors such as: A. Existing query strategy, except caches send queries using DNSCurve to authoritative servers that have public keys. B. Same as A, but the cache sorts its list of name servers to put all DNSCurve-enabled authoritative servers before non-DNSCurve-enabled servers. C. Caches only contact DNSCurve-enabled authoritative servers and only use DNSCurve queries. D. Numerous variants on the above (e.g., one or two iterations of only contacting DNSCurve servers before falling back to sending plain DNS queries to all servers). I'd like to see C be a valid strategy, as it's the only one that can guarantee no MITM exposure, but I can see practical reasons why caches might prefer to use other strategies. Any thoughts? From owner-namedroppers@ops.ietf.org Fri Apr 23 11:54:50 2010 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 9BBAE3A6AB2; Fri, 23 Apr 2010 11:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_40=-0.185, 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 O3-JOG8i4IBX; Fri, 23 Apr 2010 11:54:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C964228C0D7; Fri, 23 Apr 2010 11:54:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5NxC-000JZH-O8 for namedroppers-data0@psg.com; Fri, 23 Apr 2010 18:50:18 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5NxA-000JYw-Lj for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 18:50:16 +0000 Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id B3244A94683; Fri, 23 Apr 2010 18:50:15 +0000 (UTC) Message-ID: <4BD1EBE5.7030608@mail-abuse.org> Date: Fri, 23 Apr 2010 11:50:13 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: YAO Jiankang CC: Mark Andrews , Vaggelis Segredakis , 'Niall O'Reilly' , 'Andrew Sullivan' , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <4BCF967A.3000109@mail-abuse.org> <201004220102.o3M124ht097291@drugs.dv.isc.org> <4BCFBA6C.5000607@mail-abuse.org> <201004220401.o3M41mmK002880@drugs.dv.isc.org> <471961403.09650@cnnic.cn> <471989635.01441@cnnic.cn> In-Reply-To: <471989635.01441@cnnic.cn> 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 4/22/10 7:27 PM, YAO Jiankang wrote: > do you mean that in the root zone there can have 13 NS records for > .com while there will only one BNAME record for .com if BNAME is > applied? so you think that 13 is safer or robuster than 1? Mark made it clear, once adopted, only one resource record is able to appear in a parent zone. That's impressive. It seems the intro and rules should better clarify the definition of singleton, which should also include exceptions for DNSSEC related resources. Perhaps I am wrong, but it seems there might also be a need to ensure possible CNAMEs returned be merged with any previous BNAME RR. There should also be a statement that this may require signing by different administrative entities. There should also be a warning that targets for NS, SRV, MX or PTR RR should not to be below a BNAME. Normally greater attention is given names higher in the hierarchy, especially since wildcards have already made it easy to diffuse a name. BNAME provides another diffusion property likely to have similar and perhaps greater impact when the top of the hierarchy is used to diffuse, as this will reduce effectiveness of URI normalization techniques that attempt to consolidate name diffusion. :^( The Shadow approach seems more likely to produce greater stability and also ensures signing can be accomplished by a single entity across all related names, and might also reduce transactional growth. Either way, a solution is necessary. -Doug From owner-namedroppers@ops.ietf.org Fri Apr 23 12:25:32 2010 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 901043A6AB5; Fri, 23 Apr 2010 12:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.125 X-Spam-Level: X-Spam-Status: No, score=-98.125 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_50=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, 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 YaLHI9sfw0wA; Fri, 23 Apr 2010 12:25:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 390373A6AD0; Fri, 23 Apr 2010 12:25:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5OPt-000Pzv-1Q for namedroppers-data0@psg.com; Fri, 23 Apr 2010 19:19:57 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5OPq-000Pyu-6N for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 19:19:54 +0000 Received: from [IPv6:2001:1488:ac14:1400:ac14:1a29:0:2] (unknown [IPv6:2001:1488:ac14:1400:ac14:1a29:0:2]) by mail.nic.cz (Postfix) with ESMTPSA id C02477343E8; Fri, 23 Apr 2010 21:19:52 +0200 (CEST) Message-ID: <4BD1F2D5.3020006@nic.cz> Date: Fri, 23 Apr 2010 21:19:49 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 References: <5C8B7499CFD24579BD7B75CB8050FDA1@local> <4BD0521B.9090803@nic.cz> <986F4044CBEE422BB769C7BA94B90BF2@local> <4BD064E4.9060700@nic.cz> <201004230031.o3N0VRQb069783@drugs.dv.isc.org> <4BD1558D.5090703@nic.cz> <472013124.07253@cnnic.cn> <472015463.07253@cnnic.cn> <472026586.10639@cnnic.cn> <4BD1CDAB.6080809@nic.cz> <20100423170728.GL3611@shinkuro.com> In-Reply-To: <20100423170728.GL3611@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: On 23.4.2010 19:07, Andrew Sullivan wrote: > On Fri, Apr 23, 2010 at 06:41:15PM +0200, Ondřej Surý wrote: >> I think that this part of SMTP standard is wrong. Users >> (applications or end users) of DNS should not resolve CNAMEs on >> their own. > > Woah, nelly. Let's not put ourselves in the position of telling > other applications what they should or should not be doing with data > in the DNS, if for no other reason than that it runs exactly opposite > to years of other advice. Ok, point taken. Take that as just my opinion how should that generally work. And I am not trying to push that into CNAME+DNAME. >> a) MTA implements a query cache b) the query cache is very strict >> on CNAMEs c) mail is sent to target.dname.cz and CNAME for >> target.dname.cz is stored in the cache d) mail is sent to >> www.target.dname.cz and the query cache tries to store everything >> received (including the DNAME) into the query cache. >> >> => error is reported when storing the DNAME record into the query >> cache >> >> But I dare to say that such implementation of dns client is >> broken. > > Why is it broken? Because it breaks Postel's principle, and because it does too much for a DNS-user application. So maybe not 'broken' per se, but too fragile. > The CNAME rules say nothing else should be at the CNAME. Your > proposal violates that rule. What about RRSIG/NSEC(3)? We have already broken that rule. > You can't then say that someone checking that the CNAME doesn't have > anything else at that name is actually broken: it isn't, at least > today. Well, maybe we just differ in view, what "broken" mean. For me "broken" means more "suboptimal", for you it is more "incorrect". So I will avoid using word "broken" in this context again. > I'm not saying we shouldn't make this change to CNAME and DNAME, but > let us not dismiss the objection that we're making a change by > begging the question. Maybe I was too zealous. If we take the approach "SMTP is CNAME aware, be careful here" and not "SMTP is CNAME aware, let's not touch CNAME", then I am perfectly OK with the way to go. Ondrej -- Ondřej Surý vedoucí výzkumu/R&D manager ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From owner-namedroppers@ops.ietf.org Fri Apr 23 12:54:09 2010 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 155013A6ADC; Fri, 23 Apr 2010 12:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.03 X-Spam-Level: ** X-Spam-Status: No, score=2.03 tagged_above=-999 required=5 tests=[AWL=-2.525, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, 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 9gfsK8AgVvNc; Fri, 23 Apr 2010 12:54:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8A5493A6AD1; Fri, 23 Apr 2010 12:53:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5Osk-00063s-8y for namedroppers-data0@psg.com; Fri, 23 Apr 2010 19:49:46 +0000 Received: from [209.85.212.52] (helo=mail-vw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5Osh-00063c-NG for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 19:49:43 +0000 Received: by vws20 with SMTP id 20so192707vws.11 for ; Fri, 23 Apr 2010 12:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xQetqLrTss2/aBtY+2QH47TlasssMx7B1PYhQW62YXE=; b=awX13NjKfAcbpjrpQkhflxBSa1pc8t1UmslpT+cFcV/hCag9SXQfxbTu2/NNfyQd8q unR9CVPyuvrn228a4iIg7eR0fe4/xe7bIMg2pYHgcdof+pcz8iKqQEM5uY5Zq44HgpDT cAw6h463+IBpnhsQLw/SPJdDjxKREMJ0c2hUs= 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 :cc:content-type:content-transfer-encoding; b=YqYVdotovh3GpYT9PamoNp4GXkPlXpsO/3oG2JP/VOqxAwr6CFb23azJUuxYqEQfU3 sQUw8Kpr1apXrb5P4iwcUXq8zsTmp4+ESDI5NiQLKyS+8ov0AwcNW+KJaJK411YzzxdN H1gUCXtiOzJxir7jk1hYEcAwZCr3rkWj+9nCE= MIME-Version: 1.0 Received: by 10.220.124.144 with SMTP id u16mr273277vcr.228.1272052182780; Fri, 23 Apr 2010 12:49:42 -0700 (PDT) Received: by 10.220.77.211 with HTTP; Fri, 23 Apr 2010 12:49:42 -0700 (PDT) In-Reply-To: <20100423175529.GP3611@shinkuro.com> References: <4BC24639.7000202@ucd.ie> <20100421140307.GB47807@shinkuro.com> <4BCF440F.1090501@ucd.ie> <20100421195653.GD912@shinkuro.com> <4BD15F07.2070801@ucd.ie> <20100423155346.GE3611@shinkuro.com> <4BD1CF65.8070602@abenaki.wabanaki.net> <20100423165632.GK3611@shinkuro.com> <4BD1DCA4.8090807@abenaki.wabanaki.net> <20100423175529.GP3611@shinkuro.com> Date: Fri, 23 Apr 2010 12:49:42 -0700 Message-ID: Subject: Re: [dnsext] Re: Use the layers, Luke! From: Ted Hardie To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=GB2312 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, Apr 23, 2010 at 10:55 AM, Andrew Sullivan wrote: > On Fri, Apr 23, 2010 at 01:45:08PM -0400, Eric Brunner-Williams wrote: >> Where, other than in the SC/TC problem, does this exist? > > It makes no difference. We can't start screwing with the protocol in > order to solve that particular problem and no other. We have to solve > the general problem if we're solving anything in the DNS. > > It's quite another matter when you're dealing with particular > provisioning systems or policies. But as I put up on the screen in > Anaheim (the slides are available from the meeting materials site), we > are not undertaking to solve the linguistic variants problem in this > WG. We are not linguistically competent to do that, and anyway we're > at the wrong layer. That is not to say we ignore linguistic variants > as a use-case: it's what tickled this topic into our laps. But if > there's something to do here, it is simply more general than that. > > A > I am still trying to parse Eric's upstream comment, but I will point out th= at there are two potential classes of variants here: ones for which there is a two-way mapping and one for which the transform is one way. In the first case labour maps to labor and labor maps to labour (or colour to colo= r and color to coulor). The trick is with languages for which this is not th= e case, because multiple characters collapse. The TC/SC problem is hard because multiple characters in TC map to the same character in SC, so going back from SC to TC requires context. This was pointed out as long ago as the Salt Lake City IETF discussions on it, when James Seng and I described one particular instance of it. That instance is where the "fa" in hair (=EE^=F3=8C=A3=A9(toufa) and the "fa" in economic developm= ent (=B0l=D5=B9=A3=A9 (fazhan) got mapped to the same simplified character =A3=A8=CD=B7=B7=A2 and= =B7=A2=D5=B9=A3=A9 respectively. If you are presented with only =B7=A2, you can't know which character to map to in TC by any automated means. Luckily, I don't think we're being asked for that. I think we're being ask= ed to create something that allows zone maintainers to say =B0l=D5=B9.example and= =B7=A2=D5=B9.example are declared to be equivalent (for whatever value of equivalent we mean). But I think I understand it to be something that the zone maintainer has to say for each equivalence and the querier has to discover for each equivalen= t entry. (There may be generation tools or online synthesis, but from the protocol perspective, the zone maintainer declares it for each equivalence and the querier discovers it for each.) Put another way, I cannot assume any time I encounter a =B7=A2 somewhere underneath =B7=A2=D5=B9.example that it also m= aps to =B0l; it has to be discovered each time, lest I screw up onthe occasion when the entry is for a site about the role of hair stylists in economic development. Is this how other people understanding what we're being asked here? regards, Ted From owner-namedroppers@ops.ietf.org Fri Apr 23 12:57:46 2010 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 3E6233A6AF3; Fri, 23 Apr 2010 12:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[AWL=-0.401, 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 8WthNsV10oHc; Fri, 23 Apr 2010 12:57:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 94A1328C11D; Fri, 23 Apr 2010 12:56:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5Ovs-0006pS-7x for namedroppers-data0@psg.com; Fri, 23 Apr 2010 19:53:00 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5Ovq-0006mf-3f for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 19:52:58 +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 C701B1ECB400 for ; Fri, 23 Apr 2010 19:52:55 +0000 (UTC) Date: Fri, 23 Apr 2010 15:52:53 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 Message-ID: <20100423195253.GR3611@shinkuro.com> References: <986F4044CBEE422BB769C7BA94B90BF2@local> <4BD064E4.9060700@nic.cz> <201004230031.o3N0VRQb069783@drugs.dv.isc.org> <4BD1558D.5090703@nic.cz> <472013124.07253@cnnic.cn> <472015463.07253@cnnic.cn> <472026586.10639@cnnic.cn> <4BD1CDAB.6080809@nic.cz> <20100423170728.GL3611@shinkuro.com> <4BD1F2D5.3020006@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4BD1F2D5.3020006@nic.cz> 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 Fri, Apr 23, 2010 at 09:19:49PM +0200, Ondřej Surý wrote: > >> The CNAME rules say nothing else should be at the CNAME. Your >> proposal violates that rule. > > What about RRSIG/NSEC(3)? We have already broken that rule. But we have something else that tells you whether you get the RRSIG/NSEC(3), and that's the DO bit. If you don't set the DO bit, then you don't get those additional RRs, and if you are checking and insisting on nothing else being at the owner name of that CNAME, you won't blow up. > Maybe I was too zealous. If we take the approach "SMTP is CNAME aware, > be careful here" and not "SMTP is CNAME aware, let's not touch CNAME", > then I am perfectly OK with the way to go. I think what we have to do is present this and the BNAME alternatives to the rest of the IETF community, with an indication of our preferences. I am really not trying to discourage work here. I just want to make sure we don't oversell anything. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From my@460mms.com Fri Apr 23 14:19:55 2010 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 2BD173A68EE for ; Fri, 23 Apr 2010 14:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.988 X-Spam-Level: X-Spam-Status: No, score=-23.988 tagged_above=-999 required=5 tests=[AWL=5.515, BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, 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_FORGED_AMAZON=3, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, 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 zbFr4xy1gxmS for ; Fri, 23 Apr 2010 14:19:53 -0700 (PDT) Received: from w02.intbel.ru (w02.intbel.ru [62.76.93.4]) by core3.amsl.com (Postfix) with SMTP id CE3CC3A6800 for ; Fri, 23 Apr 2010 14:19:19 -0700 (PDT) From: "Amazon.com Email Subscriptions" To: "dnsext-archive@lists.ietf.org" Subject: Amazon.com Deal of the Day X-AMAZON-MAIL-RELAY-TYPE: subscription X-AMAZON-RTE-VERSION: 2.0 MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100423211921.CE3CC3A6800@core3.amsl.com> Date: Fri, 23 Apr 2010 14:19:19 -0700 (PDT)
Please click here if the e-mail below is not displayed correctly.
amazon.com
Free Two-Day Shipping with   › Amazon Prime
Your Amazon.com Today's Deals See All Departments
Tiffen Dfx Digital Filter Software V2
$149.95 $79.99 (47% off)
4.28571428571429
This Tiffen Dfx digital filter suite is a powerful but user-friendly stand alone application for still images. It offers a definitive set of digital optical filters, including simulations of many popular award-winning Tiffen glass filters, specialized lenses, optical lab processes, film grain, exacting color correction plus natural light and photographic effects, all in a controlled digital environment. Whether you are an amateur or professional photographer, a video or film editor, or graphic designer, Dfx's visual workflow and easy to use tools will help you create stunning images. Windows XP, Vista or Macintosh v10.4.6 and higher required for use.
Explore Other Great Gold Box Deals
Save $20 on Adobe Photoshop Elements 8
Great gift for Mom! Dbest Quick Cart
Lunar: Silver Star Harmony Limited Edition for $25.98
100 Albums for $5 Each
Save $20 on Adobe Photoshop Elements 8
$99.99 $59.99 (40% off)
 
 
Great gift for Mom! Dbest Quick Cart
$34.95 $29.99 (14% off)
 
 
Lunar: Silver Star Harmony Limited Edition for $25.98
$39.99 $25.98 (35% off)
 
 
100 Albums for $5 Each
 
Save up to $500 off the combined purchase of select Canon cameras and printers
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
Save $10 on "Alice in Wonderland Combo Pack"
Save up to 40% on Our Bestselling Fitness Products
Save up to $500 off the combined purchase of select Canon cameras and printers
 
 
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
 
 
Save $10 on "Alice in Wonderland Combo Pack"
 
 
Save up to 40% on Our Bestselling Fitness Products
 


This message was sent to the following e-mail address: dnsext-archive@lists.ietf.org

You're receiving this e-mail because you subscribed to Gold Box Deals. If you do not want any more e-mails of this kind, it's easy to unsubscribe.

Please note that product prices and availability are subject to change. Prices and availability were accurate at the time this newsletter was sent; however, they may differ from those you see when you visit Amazon.com. The List Price represents the full retail price listed on the product itself, suggested by the manufacturer or supplier, or estimated in accordance with standard industry practice. For items offered as a set, List Price may represent open-stock prices.

© 2010 Amazon.com. All rights reserved.
Amazon.com is a registered trademark of Amazon.com, Inc.
Amazon.com, 1200 12th Ave. S., Suite 1200, Seattle, WA 98144-2734.
Reference: 15067840
From owner-namedroppers@ops.ietf.org Fri Apr 23 14:35:30 2010 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 CD6FB3A68AF; Fri, 23 Apr 2010 14:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.957 X-Spam-Level: X-Spam-Status: No, score=0.957 tagged_above=-999 required=5 tests=[AWL=-1.562, BAYES_40=-0.185, 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 VsoptmO-RaXa; Fri, 23 Apr 2010 14:35:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1F1133A67C1; Fri, 23 Apr 2010 14:35:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5QRE-0000Ol-A7 for namedroppers-data0@psg.com; Fri, 23 Apr 2010 21:29:28 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5QRB-0000OV-Ab for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 21:29:25 +0000 Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3NLTCiJ044921; Fri, 23 Apr 2010 17:29:13 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4BD21125.70307@ogud.com> Date: Fri, 23 Apr 2010 17:29:09 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mark Andrews CC: Andrew Sullivan , namedroppers@ops.ietf.org Subject: [dnsext] Side effect of DNS control plane changes Re: BNAME, Synthesized CNAME, and DNSSEC References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <20100422171521.GK1362@shinkuro.com> <201004230447.o3N4lsSv071899@drugs.dv.isc.org> In-Reply-To: <201004230447.o3N4lsSv071899@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 23/04/2010 12:47 AM, Mark Andrews wrote: > In message<20100422171521.GK1362@shinkuro.com>, Andrew Sullivan writes: >> No hat. >> >> On Thu, Apr 22, 2010 at 09:14:26AM +1000, Mark Andrews wrote: >> >>> just do the same thing when we introduce BNAME. i.e. use DNSSEC >>> algorithms to signal if the zone may contain a BNAME and only those >>> validators that understand BNAME will treat it as secure. Everyone >>> else will treat the zones as insecure. >> >> I find it a little strange that on the one hand we've had people >> wringing their hands about us potentially running out of algorithm >> numbers, and on the other hand we're prepared to use up twice as many >> numbers as we have allocated on the day a new RRTYPE of this sort is >> used. > > Firstly it wouldn't be double. You would create aliases for > RSASHA256, RSASHA512, NSEC3DSA and ECC-GOST. RSAMD5, DSA, RSASHA1 > and NSEC3RSASHA1 would not get aliases. One could argue about > NSEC3RSASHA1 but I believe it is reasonable not to create a alias > for it. > > That leaves 4 new algorithms B-RSASHA256, B-RSASHA512, B-DSA, B-ECC-GOST > which all support NSEC3 and BNAME. This assumes no new algorithms will be added until after BNAME is defined :-). Mark is right, when ever we change the DNS control plane, we need to renumber some DNSKEY algorithms that are in use. At the same time do we need to put in place a requirement that new algorithm specifications list what control plane version the algorithm is defined for? This is starting to smell like sub-typing of the worst kind, but I do not know how to do it differently. Changes in the DNS control plane are infrequent but we have had a few. > > Secondly one very rarely changes the rules associated with validation. > This shouldn't be thought of as a new type but a new method of > synthesis. > > Mark > >> I'm not saying that's the wrong answer, but surely all the people who >> were uncomfortable with the algorithm allocation document are going to >> be unhappy with the above answer too, right? >> I would phrase it differently, people unhappy with the algorithm allocation document realized this might happen and worried about the consequences. As we saw earlier this month, there are people that want to get an allocation of a DNS key algorithm number in order to be able to distribute keys used by an application (HIP) with no specification of DNSSEC use. Question: should this be allowed or should we tell them to go to a different number space? One item the working group needs to get a statement/evaluation to put a limit on explosion in hash algorithms. AFICT for all practical purposes due to the structured nature of records, size restrictions on RRset's and the relatively "short" lifetime of signatures. there is no need in foreseeable future to have stronger hash algorithms than x bit effective strength. I do not know what x is but SHA-256 should be sufficient for a long time. The advise from NIST on hash algorithm use is aimed at the general case. The DNSSEC use is so different that the recommendations are not applicable. Olafur From owner-namedroppers@ops.ietf.org Fri Apr 23 14:35:50 2010 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 0BD473A695D; Fri, 23 Apr 2010 14:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.007 X-Spam-Level: X-Spam-Status: No, score=0.007 tagged_above=-999 required=5 tests=[AWL=-0.393, 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 pdaIQDYxmcBO; Fri, 23 Apr 2010 14:35:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3BB713A68AF; Fri, 23 Apr 2010 14:35:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5QUa-000197-RJ for namedroppers-data0@psg.com; Fri, 23 Apr 2010 21:32:56 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5QUY-00016e-7G for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 21:32: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 08D561ECB400 for ; Fri, 23 Apr 2010 21:32:52 +0000 (UTC) Date: Fri, 23 Apr 2010 17:32:51 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Re: Side effect of DNS control plane changes Re: BNAME, Synthesized CNAME, and DNSSEC Message-ID: <20100423213251.GT3611@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <20100422171521.GK1362@shinkuro.com> <201004230447.o3N4lsSv071899@drugs.dv.isc.org> <4BD21125.70307@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD21125.70307@ogud.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 Fri, Apr 23, 2010 at 05:29:09PM -0400, Olafur Gudmundsson wrote: > Mark is right, when ever we change the DNS control plane, we need to > renumber some DNSKEY algorithms that are in use. Sure. But the cost of that is one of the things we are trading off in deciding whether we make those changes. That includes BNAME. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Apr 23 15:07:26 2010 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 73F843A6836; Fri, 23 Apr 2010 15:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.741 X-Spam-Level: * X-Spam-Status: No, score=1.741 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=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 Pd9oi0lUMRQP; Fri, 23 Apr 2010 15:07:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 915CA3A67FC; Fri, 23 Apr 2010 15:07:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5QxM-0007CG-Mh for namedroppers-data0@psg.com; Fri, 23 Apr 2010 22:02:40 +0000 Received: from [65.99.1.130] (helo=abenaki.wabanaki.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5QxJ-0007Bs-Sz for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 22:02:38 +0000 Received: from limpet.local (cpe-67-244-32-202.twcny.res.rr.com [67.244.32.202]) by abenaki.wabanaki.net (8.14.4/8.14.3) with ESMTP id o3NLsxiT051560; Fri, 23 Apr 2010 17:54:59 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4BD218F6.8060009@abenaki.wabanaki.net> Date: Fri, 23 Apr 2010 18:02:30 -0400 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Use the layers, Luke! References: <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <20100421140307.GB47807@shinkuro.com> <4BCF440F.1090501@ucd.ie> <20100421195653.GD912@shinkuro.com> <4BD15F07.2070801@ucd.ie> <20100423155346.GE3611@shinkuro.com> <4BD1CF65.8070602@abenaki.wabanaki.net> <20100423165632.GK3611@shinkuro.com> <4BD1DCA4.8090807@abenaki.wabanaki.net> <20100423175529.GP3611@shinkuro.com> In-Reply-To: <20100423175529.GP3611@shinkuro.com> 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: On 4/23/10 1:55 PM, Andrew Sullivan wrote: > On Fri, Apr 23, 2010 at 01:45:08PM -0400, Eric Brunner-Williams wrote: >> Where, other than in the SC/TC problem, does this exist? > > It makes no difference. That is not an answer. That is, if there were no other instance of the problem but the SC/TC equivalence problem (or bug or feature, as one's taste dictates), then "it makes no difference" would mean that working without clue would be just as efficient as working with clue. I presume it matters modestly that the request is not of the form "our labels are all of length 63 - strlen("xx--"), and each character of each label takes on a value from two totally disjoint sets", that is, that if the length is on the order of 5 characters, and the two sets are not totally disjoint, we actually get some problem statement improvement. We can't start screwing with the protocol in > order to solve that particular problem and no other. We have to solve > the general problem if we're solving anything in the DNS. > > It's quite another matter when you're dealing with particular > provisioning systems or policies. But as I put up on the screen in > Anaheim (the slides are available from the meeting materials site), we > are not undertaking to solve the linguistic variants problem in this > WG. We are not linguistically competent to do that, and anyway we're > at the wrong layer. That is not to say we ignore linguistic variants > as a use-case: it's what tickled this topic into our laps. But if > there's something to do here, it is simply more general than that. Heavens Andrew, this isn't about language or variants, its about some silly sodding string generators over some alphabets. It matters from a lot of engineering perspectives if we're looking at equivalence classes of size 576,460,752,303,423,488 or of size 8. Eric From owner-namedroppers@ops.ietf.org Fri Apr 23 16:02:01 2010 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 AD8E03A682F; Fri, 23 Apr 2010 16:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.792 X-Spam-Level: * X-Spam-Status: No, score=1.792 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_05=-1.11, 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 wYp6R3JlWxW0; Fri, 23 Apr 2010 16:02:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D1943A6818; Fri, 23 Apr 2010 16:02:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5Rmo-000Gmk-FN for namedroppers-data0@psg.com; Fri, 23 Apr 2010 22:55:50 +0000 Received: from [209.85.160.180] (helo=mail-gy0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5Rmm-000GjG-3z for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 22:55:48 +0000 Received: by gyb13 with SMTP id 13so4927649gyb.11 for ; Fri, 23 Apr 2010 15:55:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.170.38 with SMTP id x38mr773407ano.101.1272063346837; Fri, 23 Apr 2010 15:55:46 -0700 (PDT) Received: by 10.231.214.209 with HTTP; Fri, 23 Apr 2010 15:55:46 -0700 (PDT) In-Reply-To: <4BD21125.70307@ogud.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <20100422171521.GK1362@shinkuro.com> <201004230447.o3N4lsSv071899@drugs.dv.isc.org> <4BD21125.70307@ogud.com> Date: Fri, 23 Apr 2010 15:55:46 -0700 Message-ID: Subject: Re: [dnsext] Side effect of DNS control plane changes Re: BNAME, Synthesized CNAME, and DNSSEC From: Matthew Dempsky To: Olafur Gudmundsson Cc: Mark Andrews , Andrew Sullivan , 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 Fri, Apr 23, 2010 at 2:29 PM, Olafur Gudmundsson wrote: > Mark is right, when ever we change the DNS control plane, we need to > renumber some DNSKEY algorithms that are in use. > > At the same time do we need to put in place a requirement that new > algorithm specifications list what control plane version the > algorithm is defined for? Is there a reason for needing to renumber algorithms like this? E.g., is there a reason you couldn't just chain identifiers together? Suppose NSEC3 had defined a generic "NSEC3" key type. The public key field could then just embed another 8-bit algorithm field followed by that algorithm's respective public key data. So instead of foo.com DNSKEY ... RSA-NSEC3 [rsa-key] foo.com DNSKEY ... DSA-NSEC3 [dsa-key] you'd have foo.com DNSKEY NSEC3 RSA [rsa-key] foo.com DNSKEY NSEC3 DSA [dsa-key] Then new keys can continue to define just a specific algorithm, and new DNS control planes also only need one new identifier each. From owner-namedroppers@ops.ietf.org Fri Apr 23 17:08:46 2010 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 C557F3A68A9; Fri, 23 Apr 2010 17:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 aHJIWjSGHbOJ; Fri, 23 Apr 2010 17:08:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 875CE3A67B3; Fri, 23 Apr 2010 17:08:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5Sq4-0002WS-Ok for namedroppers-data0@psg.com; Sat, 24 Apr 2010 00:03:16 +0000 Received: from [209.85.221.199] (helo=mail-qy0-f199.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5Sq1-0002W4-Fv for namedroppers@ops.ietf.org; Sat, 24 Apr 2010 00:03:13 +0000 Received: by qyk37 with SMTP id 37so6265368qyk.8 for ; Fri, 23 Apr 2010 17:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=ZQMH+uSzCp8WhiD4Sc65DHLGW9Ro09kg91vRa75WlaY=; b=SYqkEbrEboIZUd0978p4VfDq6s5rImZ+4ZRUgIGVLLhJIy2RNSyzyOP7dC7zXhRXR3 pFzP3hE5Q4g+TTrVCtMPkpbnE/KKsYb3/eFlYm7bWl8zNXbK9JtUNyfMwDQWWwlmJ94w CiWge+UikWYST2jjVKzONRpAOVnDc/9d/UxiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=H/3AFv1HYVGPjegrWB39sUNvQzVtgvThVYZjg53d/kMQYqVggJRRSDrXBnTf8nZ+20 ksSXiyJtCMXHd5yeS1APO2jwzk2UqqY9H5/5WGJMEkM1QAiA00Sm61k1+Il73nIGK3zi sNDk2kLjJH6ftPA0+t/janzy0YgP+tZNfgOmk= MIME-Version: 1.0 Received: by 10.229.88.76 with SMTP id z12mr975333qcl.58.1272067391116; Fri, 23 Apr 2010 17:03:11 -0700 (PDT) Received: by 10.229.246.139 with HTTP; Fri, 23 Apr 2010 17:03:11 -0700 (PDT) Date: Fri, 23 Apr 2010 19:03:11 -0500 Message-ID: Subject: [dnsext] Same-server out-of-bailiwick data? From: Brandon Black To: namedroppers@ops.ietf.org Content-Type: text/plain; charset=UTF-8 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: My google-fu has come up short, so I'm hoping the experts here at namedroppers can shed some light... Consider the case where an authoritative nameserver is authoritative for two unrelated domains, example.com and example.net, and there are some references between the two sets of data that could cause some implementations to generate Additional/CNAME responses that cross zones and are thus technically out-of-zone (out of bailiwick, for at least some definitions of bailiwick?) I'll give an example using BIND. BIND is in a basic auth-only config serving these two zonefiles: --- example.com ---- @ SOA ns1 hostmaster 1 7200 30M 3D 900 @ NS ns1 ns1 A 192.0.2.1 www A 192.0.2.2 xd-ad MX 0 www.example.net. xd-cn CNAME www.example.net. --- end --- --- example.net --- @ SOA ns1 hostmaster 1 7200 30M 3D 900 @ NS ns1 ns1 A 192.0.2.1 www A 192.0.2.2 --- end --- It's responses include all possible data that it knows about on those two names that have cross-zone references, e.g. (dig outputs): ------- ;; QUESTION SECTION: ;xd-ad.example.com. IN MX ;; ANSWER SECTION: xd-ad.example.com. 900 IN MX 0 www.example.net. ;; AUTHORITY SECTION: example.com. 900 IN NS ns1.example.com. ;; ADDITIONAL SECTION: www.example.net. 900 IN A 192.0.2.2 ns1.example.com. 900 IN A 192.0.2.1 -------- ;; QUESTION SECTION: ;xd-cn.example.com. IN A ;; ANSWER SECTION: xd-cn.example.com. 900 IN CNAME www.example.net. www.example.net. 900 IN A 192.0.2.2 ;; AUTHORITY SECTION: example.net. 900 IN NS ns1.example.net. ;; ADDITIONAL SECTION: ns1.example.net. 900 IN A 192.0.2.1 -------- In both of the above cases, if a cache server were following the usual "in bailiwick" rules, it would ignore all of the example.net records it received in these responses to queries about example.com names, which makes it seem silly to send them in the first place. On the other hand, ns1.example.com and ns1.example.net actually use the same IP address. In theory, a cache could be smart enough to say "hey I cached a nameserver at 192.0.2.1 for example.net a few minutes ago, and now I've received example.net records from 192.0.2.1 when I was looking up an example.com name, so since the nameserver IPs are the same, we'll cache the example.net records as well". My questions are: Is there anything wrong with the cache's reasoning for accepting records that are technically out-of-bailiwick, but for which it knows both bailiwicks are served by the same server IP? Do any widely used caches employ this trick, or are the example.net records pretty much universally thrown out these days? I ask because I'm facing the decision of whether to include these "out-of-bailiwick, but authoritatively served by the same server" additional/cname references in an authoritative server, and I'm not really sure whether it's a better design decision to include them (as BIND does) or leave them out completely (since by most published writings on the subject, they would be universally ignored). Thanks, -- Brandon From owner-namedroppers@ops.ietf.org Fri Apr 23 17:16:57 2010 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 41B233A687E; Fri, 23 Apr 2010 17:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.039 X-Spam-Level: * X-Spam-Status: No, score=1.039 tagged_above=-999 required=5 tests=[AWL=0.912, 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 Itygz92avNTv; Fri, 23 Apr 2010 17:16:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B83E93A6783; Fri, 23 Apr 2010 17:16:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5Szo-0004hF-N0 for namedroppers-data0@psg.com; Sat, 24 Apr 2010 00:13:20 +0000 Received: from [209.85.223.175] (helo=mail-iw0-f175.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5Szm-0004dn-8X for namedroppers@ops.ietf.org; Sat, 24 Apr 2010 00:13:18 +0000 Received: by iwn5 with SMTP id 5so438398iwn.9 for ; Fri, 23 Apr 2010 17:13:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.160.135 with SMTP id n7mr227819ibx.26.1272067995790; Fri, 23 Apr 2010 17:13:15 -0700 (PDT) Received: by 10.231.214.209 with HTTP; Fri, 23 Apr 2010 17:13:15 -0700 (PDT) In-Reply-To: <20100423195253.GR3611@shinkuro.com> References: <986F4044CBEE422BB769C7BA94B90BF2@local> <201004230031.o3N0VRQb069783@drugs.dv.isc.org> <4BD1558D.5090703@nic.cz> <472013124.07253@cnnic.cn> <472015463.07253@cnnic.cn> <472026586.10639@cnnic.cn> <4BD1CDAB.6080809@nic.cz> <20100423170728.GL3611@shinkuro.com> <4BD1F2D5.3020006@nic.cz> <20100423195253.GR3611@shinkuro.com> Date: Fri, 23 Apr 2010 17:13:15 -0700 Message-ID: Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00 From: Matthew Dempsky To: Andrew Sullivan 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: On Fri, Apr 23, 2010 at 12:52 PM, Andrew Sullivan wrote: > But we have something else that tells you whether you get the > RRSIG/NSEC(3), and that's the DO bit. Not entirely true. DNSSEC caches still include RRSIG/NSEC in response to ANY queries that omit the DO bit even if the answer includes a CNAME record. From owner-namedroppers@ops.ietf.org Sat Apr 24 18:45:55 2010 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 96CD93A680A; Sat, 24 Apr 2010 18:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.352 X-Spam-Level: * X-Spam-Status: No, score=1.352 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_50=0.001, 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 dCryoMPYqghO; Sat, 24 Apr 2010 18:45:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB0AB3A677C; Sat, 24 Apr 2010 18:45:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5qqL-0008VT-39 for namedroppers-data0@psg.com; Sun, 25 Apr 2010 01:41:09 +0000 Received: from [204.14.89.6] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5qqG-0008V6-Ob for namedroppers@ops.ietf.org; Sun, 25 Apr 2010 01:41:05 +0000 Received: (qmail 14363 invoked by uid 399); 25 Apr 2010 01:41:02 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 25 Apr 2010 01:41:02 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BD39DAD.8070803@dougbarton.us> Date: Sat, 24 Apr 2010 18:41:01 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: George Barwood CC: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Fwd: New Version Notification fordraft-sury-dnsext-cname-dname-00 References: <986F4044CBEE422BB769C7BA94B90BF2@local> <4BD064E4.9060700@nic.cz> <201004230031.o3N0VRQb069783@drugs.dv.isc.org> <4BD1558D.5090703@nic.cz> <472013124.07253@cnnic.cn> <472015463.07253@cnnic.cn> <472026586.10639@cnnic.cn> <4BD1CDAB.6080809@nic.cz> <20100423170728.GL3611@shinkuro.com> <4BD1F2D5.3020006@nic.cz> <20100423195253.GR3611@shinkuro.com> <417EEB539EC046A0B878F6FEBC3FCC83@local> In-Reply-To: <417EEB539EC046A0B878F6FEBC3FCC83@local> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 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: On 04/24/10 17:48, George Barwood wrote: > > ----- Original Message ----- From: "Andrew Sullivan" > To: Sent: Friday, > April 23, 2010 8:52 PM Subject: Re: [dnsext] Fwd: New Version > Notification fordraft-sury-dnsext-cname-dname-00 > >>>> The CNAME rules say nothing else should be at the CNAME. Your >>>> proposal violates that rule. > > I don't seem to have received the original message, so I'm not quite > sure who said this. > > But this is a "should" not a "must", It's a pre-2119 "should," so you can't read !must there without examining the context. > so in fact the standard > explicitly allows for other records to be present at a CNAME. > > The actual passage is this: ( RFC 1034, section 3.6.2 ) > > << If a CNAME RR is present at a node, no other data should be > present; this ensures that the data for a canonical name and its > aliases cannot be different. This rule also insures that a cached > CNAME can be used without checking with an authoritative server for > other RR types. >> IMO the context (including, but not limited to the 2nd half of the sentence) clearly indicates that it really means "must" here. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Sat Apr 24 21:12:05 2010 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 C31E93A67EC; Sat, 24 Apr 2010 21:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=-0.910, BAYES_40=-0.185] 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 W-WBNEgsQioB; Sat, 24 Apr 2010 21:12:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 96E463A6B43; Sat, 24 Apr 2010 21:12:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5t6X-0005n2-9n for namedroppers-data0@psg.com; Sun, 25 Apr 2010 04:06:01 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5t6U-0005mX-3U for namedroppers@ops.ietf.org; Sun, 25 Apr 2010 04:05:58 +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 0F6BFE973E; Sun, 25 Apr 2010 04:05:54 +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 o3P45iwP083820; Sun, 25 Apr 2010 14:05:46 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004250405.o3P45iwP083820@drugs.dv.isc.org> To: "George Barwood" Cc: "Doug Barton" , "Andrew Sullivan" , namedroppers@ops.ietf.org From: Mark Andrews References: <986F4044CBEE422BB769C7BA94B90BF2@local> <4BD064E4.9060700@nic.cz> <201004230031.o3N0VRQb069783@drugs.dv.isc.org> <4BD1558D.5090703@nic.cz> <472013124.07253@cnnic.cn> <472015463.07253@cnnic.cn> <472026586.10639@cnnic.cn> <4BD1CDAB.6080809@nic.cz> <20100423170728.GL3611@shinkuro.com> <4BD1F2D5.3020006@nic.cz> <20100423195253.GR3611@shinkuro.com> <417EEB539EC046A0B878F6FEBC3FCC83@local> <4BD39DAD.8070803@dougbarton.us> Subject: Re: [dnsext] Fwd: New Version Notification fordraft-sury-dnsext-cname-dname-00 In-reply-to: Your message of "Sun, 25 Apr 2010 03:55:12 +0100." Date: Sun, 25 Apr 2010 14:05:44 +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" writes: > > ----- Original Message ----- > From: "Doug Barton" > To: "George Barwood" > Cc: "Andrew Sullivan" ; > Sent: Sunday, April 25, 2010 2:41 AM > Subject: Re: [dnsext] Fwd: New Version Notification fordraft-sury-dnsext-cname-dname-00 > > > > On 04/24/10 17:48, George Barwood wrote: > >> > >> ----- Original Message ----- From: "Andrew Sullivan" > >> To: Sent: Friday, > >> April 23, 2010 8:52 PM Subject: Re: [dnsext] Fwd: New Version > >> Notification fordraft-sury-dnsext-cname-dname-00 > >> > >>>>> The CNAME rules say nothing else should be at the CNAME. Your > >>>>> proposal violates that rule. > >> > >> I don't seem to have received the original message, so I'm not quite > >> sure who said this. > >> > >> But this is a "should" not a "must", > > > > It's a pre-2119 "should," so you can't read !must there without > > examining the context. > > Well 2199 says http://tools.ietf.org/html/rfc1122#page-12 > > "Adaptability to change must be designed into all levels of > Internet host software. As a simple example, consider a > protocol specification that contains an enumeration of values > for a particular header field -- e.g., a type field, a port > number, or an error code; this enumeration must be assumed to > be incomplete. Thus, if a protocol specification defines four > possible error codes, the software must not break when a fifth > code shows up. An undefined code might be logged (see below), > but it must not cause a failure." > > This is a typical example of an undefined condition, and DNSSEC post-dates 2199 by > a long time, so surely 2199 applies? > > The principle is that receivers MUST NOT fail when they encounter an undefined > code or condition ( they can log it ). I accept that implementors often get this wrong, but > the principle seems clear ( and plain common sense ). > > - George George when you change how existing records work (this proposal changes both CNAME and DNAME) you run the risk of breaking things. If this change goes through then when one makes a DNAME query and the is a CNAME at the QNAME you no longer know whether to follow the CNAME or not to answer the query. Do you follow old rules or new rules? Which did the client expect? With BNAME, especially with the changes I've been suggesting from the begining, you don't have that problem. A cache sees a CNAME or it sees a BNAME, it never sees both. Asking a non-BNAME aware cache for a BNAME gets a CNAME. Asking a BNAME aware cache for a BNAME from a non-BNAME aware client gets a CNAME. Only when you ask for a BNAME from BNAME aware client to a BNAME aware server do you get a BNAME. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mesa_ayudasarha@afip.gov.ar Sat Apr 24 23:55:17 2010 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 3C0AF28C0E8 for ; Sat, 24 Apr 2010 23:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.24 X-Spam-Level: X-Spam-Status: No, score=-20.24 tagged_above=-999 required=5 tests=[AWL=-0.596, 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, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, 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_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FORGED_AMAZON=3, SARE_RECV_SPAM_DOMN0b=1.666, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, 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 t5MvyDVOARNa for ; Sat, 24 Apr 2010 23:55:09 -0700 (PDT) Received: from 111-251-197-116.dynamic.hinet.net (111-251-197-116.dynamic.hinet.net [111.251.197.116]) by core3.amsl.com (Postfix) with SMTP id 104FA28C101 for ; Sat, 24 Apr 2010 23:49:44 -0700 (PDT) From: "Amazon.com Email Subscriptions" To: "dnsext-archive@ietf.org" Subject: Amazon.com Deal of the Day X-AMAZON-MAIL-RELAY-TYPE: subscription X-AMAZON-RTE-VERSION: 2.0 MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100425064954.104FA28C101@core3.amsl.com> Date: Sat, 24 Apr 2010 23:49:44 -0700 (PDT)
Please click here if the e-mail below is not displayed correctly.
amazon.com
Free Two-Day Shipping with   › Amazon Prime
Your Amazon.com Today's Deals See All Departments
Tiffen Dfx Digital Filter Software V2
$149.95 $79.99 (47% off)
4.28571428571429
This Tiffen Dfx digital filter suite is a powerful but user-friendly stand alone application for still images. It offers a definitive set of digital optical filters, including simulations of many popular award-winning Tiffen glass filters, specialized lenses, optical lab processes, film grain, exacting color correction plus natural light and photographic effects, all in a controlled digital environment. Whether you are an amateur or professional photographer, a video or film editor, or graphic designer, Dfx's visual workflow and easy to use tools will help you create stunning images. Windows XP, Vista or Macintosh v10.4.6 and higher required for use.
Explore Other Great Gold Box Deals
Save $20 on Adobe Photoshop Elements 8
Great gift for Mom! Dbest Quick Cart
Lunar: Silver Star Harmony Limited Edition for $25.98
100 Albums for $5 Each
Save $20 on Adobe Photoshop Elements 8
$99.99 $59.99 (40% off)
 
 
Great gift for Mom! Dbest Quick Cart
$34.95 $29.99 (14% off)
 
 
Lunar: Silver Star Harmony Limited Edition for $25.98
$39.99 $25.98 (35% off)
 
 
100 Albums for $5 Each
 
Save up to $500 off the combined purchase of select Canon cameras and printers
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
Save $10 on "Alice in Wonderland Combo Pack"
Save up to 40% on Our Bestselling Fitness Products
Save up to $500 off the combined purchase of select Canon cameras and printers
 
 
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
 
 
Save $10 on "Alice in Wonderland Combo Pack"
 
 
Save up to 40% on Our Bestselling Fitness Products
 


This message was sent to the following e-mail address: dnsext-archive@ietf.org

You're receiving this e-mail because you subscribed to Gold Box Deals. If you do not want any more e-mails of this kind, it's easy to unsubscribe.

Please note that product prices and availability are subject to change. Prices and availability were accurate at the time this newsletter was sent; however, they may differ from those you see when you visit Amazon.com. The List Price represents the full retail price listed on the product itself, suggested by the manufacturer or supplier, or estimated in accordance with standard industry practice. For items offered as a set, List Price may represent open-stock prices.

© 2010 Amazon.com. All rights reserved.
Amazon.com is a registered trademark of Amazon.com, Inc.
Amazon.com, 1200 12th Ave. S., Suite 1200, Seattle, WA 98144-2734.
Reference: 15067840
From owner-namedroppers@ops.ietf.org Sun Apr 25 01:10:54 2010 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 E1C723A689A; Sun, 25 Apr 2010 01:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=-0.182, 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 ayCjyGtM7VAt; Sun, 25 Apr 2010 01:10:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C9E873A68B0; Sun, 25 Apr 2010 01:10:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5wpF-000KlK-Nw for namedroppers-data0@psg.com; Sun, 25 Apr 2010 08:04:25 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O5wpD-000Kkw-4A for namedroppers@ops.ietf.org; Sun, 25 Apr 2010 08:04:23 +0000 Received: from [192.168.100.161] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id D9F93C566D8; Sun, 25 Apr 2010 09:04:20 +0100 (BST) Date: Sun, 25 Apr 2010 09:04:25 +0100 From: Alex Bligh Reply-To: Alex Bligh To: George Barwood , Mark Andrews cc: Doug Barton , Andrew Sullivan , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Fwd: New Version Notification fordraft-sury-dnsext-cname-dname-00 Message-ID: <3E4989A08CE2FFEFBE817115@nimrod.local> In-Reply-To: <2DC7C5CA1D304AE4AAC4D1A49AA987C1@local> References: <986F4044CBEE422BB769C7BA94B90BF2@local> <4BD064E4.9060700@nic.cz> <201004230031.o3N0VRQb069783@drugs.dv.isc.org> <4BD1558D.5090703@nic.cz> <472013124.07253@cnnic.cn> <472015463.07253@cnnic.cn> <472026586.10639@cnnic.cn> <4BD1CDAB.6080809@nic.cz> <20100423170728.GL3611@shinkuro.com> <4BD1F2D5.3020006@nic.cz> <20100423195253.GR3611@shinkuro.com> <417EEB539EC046A0B878F6FEBC3FCC83@local> <4BD39DAD.8070803@dougbarton.us> <201004250405.o3P45iwP083820@drugs.dv.isc.org> <2DC7C5CA1D304AE4AAC4D1A49AA987C1@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 25 April 2010 06:56:26 +0100 George Barwood wrote: > Like NSEC and RRSIG queries, there is never a reason for a client to > make an explicit query for a DNAME. It is quite ok for the result of such > a query to be undefined That will make debugging interesting. -- Alex Bligh From owner-namedroppers@ops.ietf.org Sun Apr 25 10:18:52 2010 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 C397D28C1CB; Sun, 25 Apr 2010 10:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.675 X-Spam-Level: * X-Spam-Status: No, score=1.675 tagged_above=-999 required=5 tests=[AWL=-1.675, BAYES_50=0.001, 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 yQyf16HOIswV; Sun, 25 Apr 2010 10:18:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6DE4B28C111; Sun, 25 Apr 2010 10:07:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O65De-000PoI-69 for namedroppers-data0@psg.com; Sun, 25 Apr 2010 17:02:10 +0000 Received: from [87.106.162.201] (helo=ka.mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O65Db-000Pnn-FY for namedroppers@ops.ietf.org; Sun, 25 Apr 2010 17:02:07 +0000 Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1O65DY-0008MH-3R; Sun, 25 Apr 2010 19:02:04 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.71) (envelope-from ) id 1O65DX-0003bf-T0; Sun, 25 Apr 2010 19:02:03 +0200 From: Florian Weimer To: "George Barwood" Cc: Subject: Re: [dnsext] "Proof" that CNAME + DNAME is safe References: <1A979899C32A42C7A8505FA3621D1342@local> Date: Sun, 25 Apr 2010 19:02:03 +0200 In-Reply-To: <1A979899C32A42C7A8505FA3621D1342@local> (George Barwood's message of "Sun, 25 Apr 2010 16:12:29 +0100") Message-ID: <87zl0rcvp0.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: > Therefore correct resolvers cannot fail, because that would mean > they are fundamentally incorrect, that is they would fail if the > zone had been updated between the two queries. If there is inconsistent data with overlapping time-to-live, resolvers are allowed to fail queries, so I don't think this argument is correct even from a formal point of view. In the end, actual deployed resolver behavior trumps these considerations anyway, especially this is about introducing a protocol incompatibility. From nagging@aennepress.it Sun Apr 25 16:21:24 2010 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 53C043A69D4 for ; Sun, 25 Apr 2010 16:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.618 X-Spam-Level: X-Spam-Status: No, score=-30.618 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, GB_PHARMACY=1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, 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_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_FORGED_AMAZON=3, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, 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 xl6497JvG3eP for ; Sun, 25 Apr 2010 16:21:09 -0700 (PDT) Received: from aktiv-sound.ch (unknown [186.84.210.121]) by core3.amsl.com (Postfix) with SMTP id 9C6903A62C1 for ; Sun, 25 Apr 2010 16:20:44 -0700 (PDT) From: "Amazon.com Email Subscriptions" To: "dnsext-archive@ietf.org" Subject: Amazon.com Deal of the Day X-AMAZON-MAIL-RELAY-TYPE: subscription X-AMAZON-RTE-VERSION: 2.0 MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100425232045.9C6903A62C1@core3.amsl.com> Date: Sun, 25 Apr 2010 16:20:44 -0700 (PDT)
Please click here if the e-mail below is not displayed correctly.
amazon.com
Free Two-Day Shipping with   › Amazon Prime
Your Amazon.com Today's Deals See All Departments
Tiffen Dfx Digital Filter Software V2
$149.95 $79.99 (47% off)
4.28571428571429
This Tiffen Dfx digital filter suite is a powerful but user-friendly stand alone application for still images. It offers a definitive set of digital optical filters, including simulations of many popular award-winning Tiffen glass filters, specialized lenses, optical lab processes, film grain, exacting color correction plus natural light and photographic effects, all in a controlled digital environment. Whether you are an amateur or professional photographer, a video or film editor, or graphic designer, Dfx's visual workflow and easy to use tools will help you create stunning images. Windows XP, Vista or Macintosh v10.4.6 and higher required for use.
Explore Other Great Gold Box Deals
Save $20 on Adobe Photoshop Elements 8
Great gift for Mom! Dbest Quick Cart
Lunar: Silver Star Harmony Limited Edition for $25.98
100 Albums for $5 Each
Save $20 on Adobe Photoshop Elements 8
$99.99 $59.99 (40% off)
 
 
Great gift for Mom! Dbest Quick Cart
$34.95 $29.99 (14% off)
 
 
Lunar: Silver Star Harmony Limited Edition for $25.98
$39.99 $25.98 (35% off)
 
 
100 Albums for $5 Each
 
Save up to $500 off the combined purchase of select Canon cameras and printers
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
Save $10 on "Alice in Wonderland Combo Pack"
Save up to 40% on Our Bestselling Fitness Products
Save up to $500 off the combined purchase of select Canon cameras and printers
 
 
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
 
 
Save $10 on "Alice in Wonderland Combo Pack"
 
 
Save up to 40% on Our Bestselling Fitness Products
 


This message was sent to the following e-mail address: dnsext-archive@ietf.org

You're receiving this e-mail because you subscribed to Gold Box Deals. If you do not want any more e-mails of this kind, it's easy to unsubscribe.

Please note that product prices and availability are subject to change. Prices and availability were accurate at the time this newsletter was sent; however, they may differ from those you see when you visit Amazon.com. The List Price represents the full retail price listed on the product itself, suggested by the manufacturer or supplier, or estimated in accordance with standard industry practice. For items offered as a set, List Price may represent open-stock prices.

© 2010 Amazon.com. All rights reserved.
Amazon.com is a registered trademark of Amazon.com, Inc.
Amazon.com, 1200 12th Ave. S., Suite 1200, Seattle, WA 98144-2734.
Reference: 15067840
From owner-namedroppers@ops.ietf.org Sun Apr 25 16:35:38 2010 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 52F963A6956; Sun, 25 Apr 2010 16:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.659 X-Spam-Level: X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5 tests=[AWL=-1.260, BAYES_50=0.001, J_CHICKENPOX_55=0.6] 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 k7QJSW0btDCe; Sun, 25 Apr 2010 16:35:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C74593A69A2; Sun, 25 Apr 2010 16:35:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6BFj-000NlH-MH for namedroppers-data0@psg.com; Sun, 25 Apr 2010 23:28:43 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6BFg-000Nl1-Ia for namedroppers@ops.ietf.org; Sun, 25 Apr 2010 23:28: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 481CBE98C4; Sun, 25 Apr 2010 23:28:38 +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 o3PNSGrw098670; Mon, 26 Apr 2010 09:28:17 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004252328.o3PNSGrw098670@drugs.dv.isc.org> To: "George Barwood" Cc: "Florian Weimer" , namedroppers@ops.ietf.org From: Mark Andrews References: <1A979899C32A42C7A8505FA3621D1342@local> <87zl0rcvp0.fsf@mid.deneb.enyo.de> Subject: Re: [dnsext] "Proof" that CNAME + DNAME is safe In-reply-to: Your message of "Sun, 25 Apr 2010 19:52:00 +0100." Date: Mon, 26 Apr 2010 09:28: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" writes: > Florian > > ----- Original Message ----- > From: "Florian Weimer" > To: "George Barwood" > Cc: > Sent: Sunday, April 25, 2010 6:02 PM > Subject: Re: [dnsext] "Proof" that CNAME + DNAME is safe > > > >* George Barwood: > > > >> Therefore correct resolvers cannot fail, because that would mean > >> they are fundamentally incorrect, that is they would fail if the > >> zone had been updated between the two queries. > > > > If there is inconsistent data with overlapping time-to-live, resolvers > > are allowed to fail queries, so I don't think this argument is correct > > even from a formal point of view. > > Temporal inconsistencies can arise, for example where an RRSIG references > a DNSKEY record. This means that new keys should not be used until the old > DNSKEY RRset has had time to expire ( or that old signatures be supplied in addition ). > And there are other cases, e.g. a NS RRset may reference A records, that must be served > until the old NS RRset has had time to expire, or failures can occur, etc. > > But I don't see how any temporal inconsistency can arise in this case, since > queries below the DNAME are independent of queries at the DNAME owner. > Neither one gives any information about the other ( non-trivial statement, but I think > it holds). The job of a resolver can be seen as obtaining an authoritative response > to QNAME:QTYPE, after following CNAME indirection, and that response may be cached. > http://tools.ietf.org/html/rfc4035#section-4.5 cautions against using results from one > response to infer facts about other queries ( although I don't rely on that here ). > > Perhaps you could be more explicit about what inconsistencies could have any effect here. > I don't see any ( but I accept that my "proof" could be seen as incomplete until all possible > cases have been enumerated - probably by someone more expert in the DNS standard than myself ). > > > In the end, actual deployed resolver behavior trumps these > > considerations anyway, especially this is about introducing a protocol > > incompatibility. > > Well yes. But what I'm saying is that there is no incompatibility, and demonstrating how > no such incompatibility can arise in correct resolvers. > > Not setting the DNAME bit in the NSEC record when the CNAME bit is set is the key - a resolver > could possibly reject an NSEC record with the CNAME and DNAME bits both set as bogus/invalid. > But having solved that, I cannot see how any incompatibility can arise. But that is exactly the NEC/NSEC3 record that MUST work. It is ridiculous to require the authoritative server to serve up different NSEC/NSEC3 records and their signatures. 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 Mon Apr 26 00:52:13 2010 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 DEBF33A68EA; Mon, 26 Apr 2010 00:52:13 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 4.616 X-Spam-Level: **** X-Spam-Status: No, score=4.616 tagged_above=-999 required=5 tests=[AWL=-1.933, BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_66=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 wwtBb3bGy6A3; Mon, 26 Apr 2010 00:52:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F62A3A68FA; Mon, 26 Apr 2010 00:52:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6J0k-000DQo-J6 for namedroppers-data0@psg.com; Mon, 26 Apr 2010 07:45:46 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6J0e-000DOj-0d for namedroppers@ops.ietf.org; Mon, 26 Apr 2010 07:45:40 +0000 Received: (eyou send program); Mon, 26 Apr 2010 15:45:38 +0800 Message-ID: <472267938.31588@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 26 Apr 2010 15:45:38 +0800 Message-ID: From: "YAO Jiankang" To: "Andrew Sullivan" , References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <471859708.23475@cnnic.cn> <960980B4EA9244D7901B20019153D559@abc> <472039311.32451@cnnic.cn> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXTaliasmaybe-work Date: Mon, 26 Apr 2010 15:45:42 +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.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: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFuZHJldyBTdWxsaXZhbiIg PGFqc0BzaGlua3Vyby5jb20+DQpUbzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50 OiBTYXR1cmRheSwgQXByaWwgMjQsIDIwMTAgMTI6MDIgQU0NClN1YmplY3Q6IFJlOiBbZG5zZXh0 XSBJQ0FOTidzICJzeW5jaHJvbml6ZWQgZG9tYWlucyIgYW5kIHRoZSBETlNFWFRhbGlhc21heWJl LXdvcmsNCg0KDQo+IE9uIEZyaSwgQXByIDIzLCAyMDEwIGF0IDA5OjAwOjA3UE0gKzA4MDAsIFlh byBKaWFua2FuZyB3cm90ZToNCj4gDQo+PiA+ICAgICAgICAgYi4gIFNob3VsZCBhbGwgYW5kIGV2 ZXJ5IGxhYmVsIHVuZGVyIFtuYW1lMV0gYmUgZXhwcmVzc2VkIGluIExFMQ0KPj4gPiAgICAgICAg IGFuZCBhbGwgYW5kIGV2ZXJ5IGxhYmVsIHVuZGVyIFRMRDIgYmUgZXhwcmVzc2VkIGluIFtuYW1l Ml0/ICBGb3INCj4+ID4gICAgICAgICBleGFtcGxlLCBmb3IgYSBmdWxseSBxdWFsaWZpZWQgZG9t YWluIG9mIHRoZSBmb3JtIHIxLnIxLltuYW1lMV0NCj4+ID4gICAgICAgICBtdXN0IHRoZXJlIGFs d2F5cyBhbmQgb25seSBiZSBhIHN5bmNocm9uaXplZCBlbnRyeQ0KPj4gPiAgICAgICAgIHIyLnIy LltuYW1lMl0/DQo+IA0KPj4gDQo+PiBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgQk5BTUUgd29y a3MgZm9yIGNhc2UgKGIpIHRvby4NCj4+IA0KPj4gaWYgeW91IHdhbnQgIHIxLnIxLltuYW1lMV0g dG8gYmUgZXF1YWwgd2l0aCByMi5yMi5bbmFtZTJdLCB5b3VyIGFzc3VtcHRpb24gaXMgcjE9cjIu DQo+PiANCj4+IHNvIHdlIHNldA0KPj4gDQo+PiAgLm5hbWUxIEJOQU1FIC4gbmFtZTIgaW4gdGhl IHRvcCB6b25lLg0KPj4gDQo+PiBpbiAubmFtZTIgem9uZSwNCj4+IHdlIGp1c3Qgc2V0DQo+PiAg cjIucjIubmFtZTIgQk5BTUUgcjEucjEubmFtZTINCj4+IG9yIA0KPj4gICAgcjIubmFtZTIgQk5B TUUgIHIxLm5hbWUyDQo+IA0KPiBUaGF0IGNvbGxhcHNlcyB0byBjYXNlIChjKSwgYmVjYXVzZSBi b3RoIHpvbmVzIGVuZCB1cCB3aXRoIGEgY29weSBvZg0KPiBldmVyeXRoaW5nLCBhbGwgdGhlIHdh eSBkb3duLCByaWdodD8gIFRoYXQgaXMsIGlmIHlvdSBsb29rIHVwDQo+IHIyLm5hbWUxLCB5b3Ug Z2V0IHJlZGlyZWN0ZWQgdG8gcjIubmFtZTIsIG5vPyAgU28sIHRvIGJlIHN0cmljdCwgdGhpcw0K PiBkb2Vzbid0IG1lZXQgdGhlIHJ1bGUgYmVjYXVzZSBvZiB0aGUgImFsd2F5cyBhbmQgb25seSIg cmVzdHJpY3Rpb24uDQo+IA0KPiBJZiB0aGF0J3MgYWNjZXB0YWJsZSwgdGhlbiBvay4gDQoNCkkg dGhpbmsgdGhhdCB0aGF0IGlzIHRoZSBjYXNlIGZvciBzeW5jaHJvbml6ZWQgZG9tYWlucy4NCg0K aWYgeW91IGhhdmUgdGltZSwgeW91IGNhbiB0YWtlIGEgbG9vayBhdCBSRkMgMzc0MyBhbmQgeW91 IHdpbGwgaGF2ZSBjbGVhcmVyIGltYWdlIGFib3V0IHRoaXMuDQoNCg0KPiBCdXQgSSdkIGJlZW4g bGVkIHRvIGJlbGlldmUgdGhhdCBpdA0KPiB3YXMgbm90LiAgT24gdGhlIGNvbnRyYXJ5LCBJJ2Qg YmVlbiBsZXQgdG8gYmVsaWV2ZSB0aGF0IG9uZQ0KPiBpbXBsZW1lbnRhdGlvbiwgYWN0dWFsbHkg dGhlIHRhcmdldCBvZiB0aGUgc3luY2hyb25pemVkIGRvbWFpbnMNCj4gcHJvcG9zYWwsIGltcGxl bWVudHMgdHdvIGNvbXBsZXRlbHkgZGlmZmVyZW50IHRyZWVzLiAgDQoNCiB0d28gY29tcGxldGVs eSBkaWZmZXJlbnQgdHJlZXMgYXJlIGp1c3QgaW5zdGFuY2VzIG9mIHN5bmNocm9uaXplZCBkb21h aW5zLg0KDQo+SW4gdGhhdA0KPiBwYXJ0aWN1bGFyIGNhc2UsIG9uZSB0cmVlIHVzZXMgb25lIHN1 YnNldCBvZiBhIHNjcmlwdCwgYW5kIHRoZSBvdGhlcg0KPiB0cmVlIHVzZXMgYSBkaWZmZXJlbnQg c3Vic2V0IG9mIHRoZSBzYW1lIHNjcmlwdC4gIElmIHlvdSdyZSBpbiB0aGUNCj4gInNjcmlwdCBz dWJzZXQgMSB0cmVlIiwgYW5kIHlvdSB1c2UgYSBjaGFyYWN0ZXIgZnJvbSAic2NyaXB0IHN1YnNl dA0KPiAyIiwgeW91IGRvbid0IGdldCBhbnl3aGVyZS4gIFBlcmhhcHMgeW91IGhhdmUgZGV0YWls cyBvZiBhIHVzZSBjYXNlIGluDQo+IG1pbmQgdGhhdCB3b3VsZCBiZSBtb3JlIHJlbGV2YW50LCB0 aG91Z2g/DQoNCmluIENoaW5lc2UgY2hhcmFjdGVyIGV4YW1wbGUsDQpzY3JpcHQgc3Vic2V0IDE6 IHNpbXBsaWZpZWQgY2hpbmVzZQ0Kc2NyaXB0IHN1YnNldCAyOiB0cmFkaXRvbmFsIGNoaW5lc2UN CmZvciBldmVyeSBjaGluZXNlIGNoYXJhY3RlciBSIFMgVCwgdGhlcmUgd2lsbCBoYXZlIHNpbXBs aWZpZWQgY2hpbmVzZSB2ZXJpb24gUjEsIFMxLCBUMTsNCnRyYWRpb25hbCBjaGluZXNlIHZlcnNp b24gUjIsIFMyLCBUMg0KDQpmb3IgdGhlIHNlY29uZCBsZXZlbCBDaGluZXNlIGRvbWFpbiByZWdp c3RyYXRpb24gdW5kZXIgLm9yZyBUTEQsDQoNCnRoZSByZWdpc3RyYW50IHJlcXVlc3RpbmcgZm9y IFIxUzEsIHdpbGwgZ2V0IFIxUzEub3JnLCBSMlMyLm9yZywgUjFTMi5vcmcsIGFuZCBSMlMxLm9y ZyB0b3RhbCBmb3VyIGRvbWFpbiBuYW1lcy4NCg0KdGhlcmUgd2lsbCBoYXZlICBSMVMxLm9yZyBh bmQgUjJTMi5vcmcgdHJlZXMsIHdoaWNoIGFyZSBpbiB5b3VyIGNhc2UgKGIpLg0KdGhlcmUgd2ls bCBhbHNvIGhhdmUgUjFTMi5vcmcsIGFuZCBSMlMxLm9yZyB0cmVlcy4gVGhlc2UgZm91ciB0cmVl cyBzaG91bGQgYmUgc2FtZSwgd2hpY2ggZmFsbCBpbiB5b3VyIGNhc2UgKGMpLg0KDQpzbyBjYXNl IChjKSBpcyB3aGF0IHRoZSBzeW5jaHJvbml6ZWQgZG9tYWlucyB3YW50IG9yIHRoZSBwcm9wZXIg ZGVzY3JpcHRpb24uDQoNCmlmIHVuZGVyIHRoZSBUTEQgVCwNCg0Kd2UgaG9wZSB0aGF0ICBSMVMx LlQxLCBSMlMyLlQxLCBSMVMyLlQxLCAgUjJTMS5UMSwgIFIxUzEuVDIsIFIyUzIuVDIsIFIxUzIu VDIsICBSMlMxLlQyIGFsbCA4IGRvbWFpbiBuYW1lcyAodHJlZXMpIHRvIGJlIHNhbWUuDQpSMVMx LlQxIGFuZCBSMlMyLlQyIGFyZSBqdXN0IGluc3RhbmNlcyBvZiBhbGwgOCBkb21haW4gbmFtZXMg KHRyZWVzKS4NCg0KZm9yIG1vcmUgaW5mb3JtYXRpb24sIHlvdSBjYW4gbG9vayBhdCByZmMzNzQz Lg0KDQoNCg0KZm9yIHRoZSBjb2xvciBleGFtcGxlLA0KDQp3ZSBleHBlY3QgY29sb3IuY29sb3Is IGNvbG91ci5jb2xvdXIsIGNvbG9yLmNvbG91ciBhbmQgY29sb3VyLmNvbG9yIGZvdXIgZG9tYWlu IG5hbWVzICAodHJlZXMpIHRvIGJlIHNhbWUuDQoNCg0KSmlhbmthbmcgWWFvDQoNCg0KDQoNCg0K DQoNCg0KPiANCj4gQmVzdCwNCj4gDQo+IEENCj4gDQo+IC0tIA0KPiBBbmRyZXcgU3VsbGl2YW4N Cj4gYWpzQHNoaW5rdXJvLmNvbQ0KPiBTaGlua3VybywgSW5jLg0KPg== From owner-namedroppers@ops.ietf.org Mon Apr 26 01:10:00 2010 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 5DBF03A6933; Mon, 26 Apr 2010 01:10:00 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.653 X-Spam-Level: ** X-Spam-Status: No, score=2.653 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MSGID_FROM_MTA_HEADER=0.803, 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 ndZv2ulPuxYl; Mon, 26 Apr 2010 01:09:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 986CF3A684F; Mon, 26 Apr 2010 01:09:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6JJo-000I6P-K3 for namedroppers-data0@psg.com; Mon, 26 Apr 2010 08:05:28 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6JJi-000I5S-PR for namedroppers@ops.ietf.org; Mon, 26 Apr 2010 08:05:23 +0000 Received: (eyou send program); Mon, 26 Apr 2010 16:05:21 +0800 Message-ID: <472269121.27591@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 26 Apr 2010 16:05:21 +0800 Message-ID: From: "YAO Jiankang" To: "Niall O'Reilly" Cc: "Andrew Sullivan" , "Vaggelis Segredakis" , , "'Sotiris Panaretou'" References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <471859708.23475@cnnic.cn> <472027609.32676@cnnic.cn> <472046634.28137@cnnic.cn> Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT aliasmaybe-work Date: Mon, 26 Apr 2010 16:05:33 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk5pYWxsIE8nUmVpbGx5IiA8 TmlhbGwub1JlaWxseUB1Y2QuaWU+DQpUbzogIllhbyBKaWFua2FuZyIgPHlhb2prQGNubmljLmNu Pg0KQ2M6ICJBbmRyZXcgU3VsbGl2YW4iIDxhanNAc2hpbmt1cm8uY29tPjsgIlZhZ2dlbGlzIFNl Z3JlZGFraXMiIDxzZWdyZWRAaWNzLmZvcnRoLmdyPjsgPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5v cmc+OyAiJ1NvdGlyaXMgUGFuYXJldG91JyIgPHNvdGlyaXNAdWN5LmFjLmN5Pg0KU2VudDogU2F0 dXJkYXksIEFwcmlsIDI0LCAyMDEwIDI6MDQgQU0NClN1YmplY3Q6IFJlOiBbZG5zZXh0XSBJQ0FO TidzICJzeW5jaHJvbml6ZWQgZG9tYWlucyIgYW5kIHRoZSBETlNFWFQgYWxpYXNtYXliZS13b3Jr DQoNCg0KPiBPbiAyMy8wNC8xMCAxNDowMCwgWWFvIEppYW5rYW5nIHdyb3RlOg0KPiANCj4+IGlm IHlvdSB3YW50ICByMS5yMS5bbmFtZTFdIHRvIGJlIGVxdWFsIHdpdGggcjIucjIuW25hbWUyXSwg eW91ciBhc3N1bXB0aW9uIGlzIHIxPXIyLg0KPiANCj4gSSB0aGluayBBbmRyZXcgbWVhbnQgY2xh c3MgKGIpIHNwZWNpZmljYWxseSB0bw0KPiBleGNsdWRlIHIxPXIyLg0KDQpoZSBtZWFucyByMT1y MiAocjEgYW5kIHIyIGFyZSBzYW1lIGluIHRoZSBtZWFuaW5nIG9yIGV4Y2hhbmdlYWJsZSksIGJ1 dCBkb2VzIG5vdCB3YW50ICByMS5yMi5bbmFtZTFdIHRvIGJlIGVxdWFsIHdpdGggcjIucjIuW25h bWUyXS4NCg0KaWYgcjE8PnIyLCAgd2h5IGRvZXMgdGhlcmUgaGF2ZSAgcjEucjEuW25hbWUxXSB0 byBiZSBlcXVhbCB3aXRoIHIyLnIyLltuYW1lMl0/DQoNCg0KSmlhbmthbmcgWWFvDQoNCj4gDQo+ IEFUQg0KPiBOaWFsbCBPJ1JlaWxseQ0KPiANCj4= From owner-namedroppers@ops.ietf.org Mon Apr 26 02:04:26 2010 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 A500E3A6AAE; Mon, 26 Apr 2010 02:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_40=-0.185, 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 cfVPw9BCutoe; Mon, 26 Apr 2010 02:04:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC3AB3A6A69; Mon, 26 Apr 2010 02:04:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6K9P-0003Tp-T1 for namedroppers-data0@psg.com; Mon, 26 Apr 2010 08:58:47 +0000 Received: from [193.1.169.34] (helo=dakota.ucd.ie) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6K9M-0003Rh-9T for namedroppers@ops.ietf.org; Mon, 26 Apr 2010 08:58:44 +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 <0L1H004016IA1900@dakota.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Mon, 26 Apr 2010 09:58:42 +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 <0L1H007IR7LSJJ00@dakota.ucd.ie>; Mon, 26 Apr 2010 09:58:41 +0100 (IST) Date: Mon, 26 Apr 2010 09:58:39 +0100 From: Niall O'Reilly Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT aliasmaybe-work In-reply-to: <472269121.27591@cnnic.cn> To: YAO Jiankang Cc: Andrew Sullivan , Vaggelis Segredakis , namedroppers@ops.ietf.org, 'Sotiris Panaretou' Message-id: <4BD555BF.6070603@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <471859708.23475@cnnic.cn> <472027609.32676@cnnic.cn> <472046634.28137@cnnic.cn> <472269121.27591@cnnic.cn> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) 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/04/10 09:05, YAO Jiankang wrote: > he means r1=r2 (r1 and r2 are same in the meaning or exchangeable), > but does not want r1.r2.[name1] to be equal with r2.r2.[name2]. > > if r1<>r2, why does there have r1.r1.[name1] to be equal with > r2.r2.[name2]? Andrew understood it was a requirement from someone. You've made it clear it's not one of yours. I think that's progress: one less thing to worry about, unless someone else shouts. ATB Niall O'Reilly From owner-namedroppers@ops.ietf.org Mon Apr 26 04:46:53 2010 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 380523A6B83; Mon, 26 Apr 2010 04:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.299 X-Spam-Level: X-Spam-Status: No, score=-7.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_HI=-8, 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 UiYieOm4hfkC; Mon, 26 Apr 2010 04:46:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 67F0A3A6BA9; Mon, 26 Apr 2010 04:42:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6Mbd-000BYX-Ur for namedroppers-data0@psg.com; Mon, 26 Apr 2010 11:36:05 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6Mba-000BY2-Ma for namedroppers@ops.ietf.org; Mon, 26 Apr 2010 11:36:03 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version: Return-Path; b=ZyqKjzYkmtkvGTi0VQvehcA4kx7FPbYSMGWXNrbGX5QL10WvHWloioJc c7IYtI+a2pgF+Feir4OrIKJR+QuweneaoG0gNWfuZ7YZXDpsXfEx9AZCM av/NxXUIcooWi8g; 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=1272281762; x=1303817762; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[dnsext]=20ICANN's=20"synchronized=20do mains"=20and=20the=20DNSEXT=20alias=0D=0A=20maybe-work |Date:=20Mon,=2026=20Apr=202010=2011:35:58=20+0000 |Message-ID:=20 |To:=20Niall=20O'Reilly=20,=20Dougl as=20Otis=20|CC:=20Vaggelis=20Segre dakis=20,=20'Andrew=20Sullivan'=0D =0A=09,=20"namedroppers@ops.ietf.org" =20,=0D=0A=09'Sotiris=20Panare tou'=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<085cb84a-ac5f-4e09-9261-12ad8dabf5eb> |In-Reply-To:=20<4BCF5098.9060109@ucd.ie>; bh=oWz0QNMexv8nfHg8FMeRPa7MRpTqB0vUm+cr2Hd5Fbw=; b=IYhqDreSTJULArIkP+8asc6CNEUKah+nkbjbMvLlM3SHirhpO+eN4J1E xYuexEEF7H/301gKYCQtmip623t4koJMEyCl9neYogDf5LcjlGR6RPtLp G1vC/MUobObC6Ao; X-IronPort-AV: E=Sophos;i="4.52,273,1270422000"; d="scan'208";a="23767283" Received: from host-213-248-197-145.nominet.org.uk (HELO wds-exc2.okna.nominet.org.uk) ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 26 Apr 2010 12:36:00 +0100 Received: from BDC-WDS-EXC1.okna.nominet.org.uk (2002:d5f8:c592::d5f8:c592) by wds-exc2.okna.nominet.org.uk (2002:d5f8:c591::d5f8:c591) with Microsoft SMTP Server (TLS) id 14.0.639.21; Mon, 26 Apr 2010 12:36:00 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by bdc-wds-exc1.okna.nominet.org.uk ([fe80::784f:9067:6a1a:ab8f%19]) with mapi; Mon, 26 Apr 2010 12:35:59 +0100 From: Ray Bellis To: Niall O'Reilly , Douglas Otis CC: Vaggelis Segredakis , 'Andrew Sullivan' , "namedroppers@ops.ietf.org" , 'Sotiris Panaretou' Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Thread-Topic: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work Thread-Index: AQHK2cI9f2crGFjIaUiDkTmx5KUfuJIsoDWAgACQhoCAABsdAIAHaeoA Date: Mon, 26 Apr 2010 11:35:58 +0000 Message-ID: In-Reply-To: <4BCF5098.9060109@ucd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <085cb84a-ac5f-4e09-9261-12ad8dabf5eb> 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 never thought of making a zone apex the target > of a CNAME. This may be unusual, or even perverse, > but is it actually forbidden? If not we have the > potential effect already since RFCs 1034 and 1035. It's often used by (less clueful) people wanting to make 'example.com' and 'www.example.com' point at the same web server. They put an A record in the apex, and then point 'www' back to the domain itself. Ray From owner-namedroppers@ops.ietf.org Mon Apr 26 05:10:52 2010 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 8A1B03A69B3; Mon, 26 Apr 2010 05:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.8 X-Spam-Level: X-Spam-Status: No, score=-98.8 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=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 HcKIezuSB7PG; Mon, 26 Apr 2010 05:10:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F0A83A69A4; Mon, 26 Apr 2010 05:10:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6N4h-000IxD-Dh for namedroppers-data0@psg.com; Mon, 26 Apr 2010 12:06:07 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6N4e-000IvD-Hl for namedroppers@ops.ietf.org; Mon, 26 Apr 2010 12:06:04 +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 o3QC61E0007590 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 26 Apr 2010 14:06:02 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4BD581A9.3030206@nlnetlabs.nl> Date: Mon, 26 Apr 2010 14:06:01 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc11 Thunderbird/3.0.4 MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: [dnsext] dnssec-bis-updates item about CNAME X-Enigmail-Version: 1.0.1 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 Apr 2010 14:06:02 +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 Hi, After a discussion with Ondrej about CNAME+DNAME, I realized that there may be an omission in the dnssec spec about CNAME and other metadata. The issue is easy to explain with this example. The domain name has CNAME and NSEC at the name. Recursor A connects to an upstream cache B that connects to the rest of the internet. Recursor A has to resolve qtype=NSEC. Cache B has the CNAME in cache, it picks up the CNAME, follows it and returns the wrong NSEC answer. It validates because the CNAME and cname-target NSEC verify. (quick authority sketch: NSEC3 signed zone, qtype=NSEC, follows a CNAME and returns the NSEC3 record for the wrong name.). The text is: There is a set of metadata types that are allowed next to CNAMEs, this set contains NSEC, RRSIG and NSEC3 (reference RFC403x, 5155). For queries for types in this set, a server MUST NOT follow a CNAME if that is present. More text is: For a validation proof a CNAME is not allowed when constructing a proof if the query type is in the set of metadata types allowed next to CNAMEs. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvVgakACgkQkDLqNwOhpPj9wgCcCBk5GLp/UrFIyRUVv5rBgNUI 70gAn0ctI96VVdQ7+lFBB3dqK6akE91p =cUJ9 -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Apr 26 07:06:41 2010 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 5ED3D28C161; Mon, 26 Apr 2010 07:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.887 X-Spam-Level: X-Spam-Status: No, score=-0.887 tagged_above=-999 required=5 tests=[AWL=-0.888, BAYES_50=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 GAZp3PzOeWYw; Mon, 26 Apr 2010 07:06:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 052F128C148; Mon, 26 Apr 2010 07:06:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6OtT-000LWt-1Q for namedroppers-data0@psg.com; Mon, 26 Apr 2010 14:02: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.71 (FreeBSD)) (envelope-from ) id 1O6OtP-000LVn-Bf for namedroppers@ops.ietf.org; Mon, 26 Apr 2010 14:02:35 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 218FAA3576 for ; Mon, 26 Apr 2010 14:02:33 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] dnssec-bis-updates item about CNAME In-Reply-To: Your message of "Mon, 26 Apr 2010 14:06:01 +0200." <4BD581A9.3030206@nlnetlabs.nl> References: <4BD581A9.3030206@nlnetlabs.nl> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Mon, 26 Apr 2010 14:02:33 +0000 Message-ID: <78409.1272290553@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: Mon, 26 Apr 2010 14:06:01 +0200 > From: "W.C.A. Wijngaards" > ... > The text is: There is a set of metadata types that are allowed next to > CNAMEs, this set contains NSEC, RRSIG and NSEC3 (reference RFC403x, > 5155). For queries for types in this set, a server MUST NOT follow a > CNAME if that is present. to me this is more evidence that we got DNSSEC wrong in as far as placement of our metadata. had we put OWNER(m) at BASENAME(x)."_DNSSEC_Z".DIRNAME(x) for m in NSEC NSEC3 RRSIG DNSKEY, and OWNER(m) at BASENAME(x)."_DNSSEC_P". DIRNAME(x) for m in DS, and required that "._DNSSEC_Z" and ".DNSSEC_P" be in-zone (never delegation points) then there would be no CNAME collocation fuzz nor NS/DS collocation fuzz, and dnssec metadata would be subject to normal queries, and we could make stub validators work. i realize that it's too late to change this, so this is not a proposal. "just saying." From owner-namedroppers@ops.ietf.org Mon Apr 26 08:24:42 2010 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 7A4BC28C166; Mon, 26 Apr 2010 08:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.7 X-Spam-Level: X-Spam-Status: No, score=-100.7 tagged_above=-999 required=5 tests=[AWL=1.900, 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 8VJEx7CofZNP; Mon, 26 Apr 2010 08:24:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8ADAF3A6C13; Mon, 26 Apr 2010 08:18:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6Pyq-000BZ9-35 for namedroppers-data0@psg.com; Mon, 26 Apr 2010 15:12:16 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6Pym-000BYg-56 for namedroppers@ops.ietf.org; Mon, 26 Apr 2010 15:12:12 +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 o3QFC7ac069083 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 26 Apr 2010 17:12:08 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4BD5AD47.7010207@nlnetlabs.nl> Date: Mon, 26 Apr 2010 17:12:07 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc11 Thunderbird/3.0.4 MIME-Version: 1.0 To: George Barwood CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] dnssec-bis-updates item about CNAME References: <4BD581A9.3030206@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.0.1 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 Apr 2010 17:12:08 +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 Hi George, On 04/26/2010 03:54 PM, George Barwood wrote: > I agree the standard does not appear to specify the response to NSEC and RRSIG > queries where there is a CNAME, as per my earlier message > > http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg01165.html Yes, my email is a rewording of the trouble you saw there, and dnssec-bis-updates could be a good place to document it. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvVrUcACgkQkDLqNwOhpPgNNwCbBnYahqerNuXXI3Jr4vzcOxAA MngAnjt5M/+7euzlZ+ufJiwmuMy3qbdO =+FLq -----END PGP SIGNATURE----- From klaus.lutter5@airtours.de Mon Apr 26 08:32:16 2010 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 2902628C146 for ; Mon, 26 Apr 2010 08:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.661 X-Spam-Level: X-Spam-Status: No, score=-28.661 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, 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_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FORGED_AMAZON=3, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, 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 0NlN59HKmYQh for ; Mon, 26 Apr 2010 08:32:06 -0700 (PDT) Received: from aketsolutions.com (186-24-23-3.genericrev.telcel.net.ve [186.24.23.3]) by core3.amsl.com (Postfix) with SMTP id CDF723A6BC2 for ; Mon, 26 Apr 2010 08:29:20 -0700 (PDT) From: "Amazon.com Email Subscriptions" To: "dnsext-archive@ietf.org" Subject: Amazon.com Deal of the Day X-AMAZON-MAIL-RELAY-TYPE: subscription X-AMAZON-RTE-VERSION: 2.0 MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100426152942.CDF723A6BC2@core3.amsl.com> Date: Mon, 26 Apr 2010 08:29:20 -0700 (PDT)
Please click here if the e-mail below is not displayed correctly.
amazon.com
Free Two-Day Shipping with   › Amazon Prime
Your Amazon.com Today's Deals See All Departments
Tiffen Dfx Digital Filter Software V2
$149.95 $79.99 (47% off)
4.28571428571429
This Tiffen Dfx digital filter suite is a powerful but user-friendly stand alone application for still images. It offers a definitive set of digital optical filters, including simulations of many popular award-winning Tiffen glass filters, specialized lenses, optical lab processes, film grain, exacting color correction plus natural light and photographic effects, all in a controlled digital environment. Whether you are an amateur or professional photographer, a video or film editor, or graphic designer, Dfx's visual workflow and easy to use tools will help you create stunning images. Windows XP, Vista or Macintosh v10.4.6 and higher required for use.
Explore Other Great Gold Box Deals
Save $20 on Adobe Photoshop Elements 8
Great gift for Mom! Dbest Quick Cart
Lunar: Silver Star Harmony Limited Edition for $25.98
100 Albums for $5 Each
Save $20 on Adobe Photoshop Elements 8
$99.99 $59.99 (40% off)
 
 
Great gift for Mom! Dbest Quick Cart
$34.95 $29.99 (14% off)
 
 
Lunar: Silver Star Harmony Limited Edition for $25.98
$39.99 $25.98 (35% off)
 
 
100 Albums for $5 Each
 
Save up to $500 off the combined purchase of select Canon cameras and printers
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
Save $10 on "Alice in Wonderland Combo Pack"
Save up to 40% on Our Bestselling Fitness Products
Save up to $500 off the combined purchase of select Canon cameras and printers
 
 
Save up to 25% on Sport Watches from Casio, Timex, and Armitron
 
 
Save $10 on "Alice in Wonderland Combo Pack"
 
 
Save up to 40% on Our Bestselling Fitness Products
 


This message was sent to the following e-mail address: dnsext-archive@ietf.org

You're receiving this e-mail because you subscribed to Gold Box Deals. If you do not want any more e-mails of this kind, it's easy to unsubscribe.

Please note that product prices and availability are subject to change. Prices and availability were accurate at the time this newsletter was sent; however, they may differ from those you see when you visit Amazon.com. The List Price represents the full retail price listed on the product itself, suggested by the manufacturer or supplier, or estimated in accordance with standard industry practice. For items offered as a set, List Price may represent open-stock prices.

© 2010 Amazon.com. All rights reserved.
Amazon.com is a registered trademark of Amazon.com, Inc.
Amazon.com, 1200 12th Ave. S., Suite 1200, Seattle, WA 98144-2734.
Reference: 15067840
From owner-namedroppers@ops.ietf.org Mon Apr 26 08:55:07 2010 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 D15273A697B; Mon, 26 Apr 2010 08:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.628 X-Spam-Level: *** X-Spam-Status: No, score=3.628 tagged_above=-999 required=5 tests=[AWL=-1.978, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, MANGLED_LOW=2.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 nOGd+cVyTOVJ; Mon, 26 Apr 2010 08:55:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D8293A6405; Mon, 26 Apr 2010 08:55:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6QYs-000K4d-4l for namedroppers-data0@psg.com; Mon, 26 Apr 2010 15:49:30 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6QYW-000Jzl-3G for namedroppers@ops.ietf.org; Mon, 26 Apr 2010 15:49:08 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3QFmwpd066736; Mon, 26 Apr 2010 11:48:58 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Mon, 26 Apr 2010 11:49:04 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 26 Apr 2010 11:49:04 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4BD581A9.3030206@nlnetlabs.nl> References: <4BD581A9.3030206@nlnetlabs.nl> Date: Mon, 26 Apr 2010 11:48:56 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] dnssec-bis-updates item about CNAME Cc: ed.lewis@neustar.biz Content-Type: multipart/alternative; boundary="============_-939825558==_ma============" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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: --============_-939825558==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" This impacts RFC 4592, section 3.3.3: # 3.3.3. Type Matching ... # The change is to add the following text to part 'c' prior to the # instructions to "go to step 6": # # If the data at the source of synthesis is a CNAME, and QTYPE # doesn't match CNAME, copy the CNAME RR into the answer section of # the response changing the owner name to the QNAME, change QNAME to # the canonical name in the CNAME RR, and go back to step 1. At 14:06 +0200 4/26/10, W.C.A. Wijngaards wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi, > >After a discussion with Ondrej about CNAME+DNAME, I realized that there >may be an omission in the dnssec spec about CNAME and other metadata. > >The issue is easy to explain with this example. The domain name has >CNAME and NSEC at the name. Recursor A connects to an upstream cache B >that connects to the rest of the internet. Recursor A has to resolve >qtype=NSEC. Cache B has the CNAME in cache, it picks up the CNAME, >follows it and returns the wrong NSEC answer. It validates because the >CNAME and cname-target NSEC verify. > >(quick authority sketch: NSEC3 signed zone, qtype=NSEC, follows a CNAME >and returns the NSEC3 record for the wrong name.). > >The text is: There is a set of metadata types that are allowed next to >CNAMEs, this set contains NSEC, RRSIG and NSEC3 (reference RFC403x, >5155). For queries for types in this set, a server MUST NOT follow a >CNAME if that is present. > >More text is: For a validation proof a CNAME is not allowed when >constructing a proof if the query type is in the set of metadata types >allowed next to CNAMEs. > >Best regards, > Wouter >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.9 (GNU/Linux) >Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > >iEYEARECAAYFAkvVgakACgkQkDLqNwOhpPj9wgCcCBk5GLp/UrFIyRUVv5rBgNUI >70gAn0ctI96VVdQ7+lFBB3dqK6akE91p >=cUJ9 >-----END PGP SIGNATURE----- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? --============_-939825558==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] dnssec-bis-updates item about CNAME
This impacts RFC 4592, section 3.3.3:

# 3.3.3.  Type Matching
...
#   The change is to add the following text to part 'c' prior to the
#   instructions to "go to step 6":
#
#       If the data at the source of synthesis is a CNAME, and QTYPE
#       doesn't match CNAME, copy the CNAME RR into the answer section of
#       the response changing the owner name to the QNAME, change QNAME to
#       the canonical name in the CNAME RR, and go back to step 1.


At 14:06 +0200 4/26/10, W.C.A. Wijngaards wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi,
>
>After a discussion with Ondrej about CNAME+DNAME, I realized that there
>may be an omission in the dnssec spec about CNAME and other metadata.
>
>The issue is easy to explain with this example.  The domain name has
>CNAME and NSEC at the name.  Recursor A connects to an upstream cache B
>that connects to the rest of the internet.  Recursor A has to resolve
>qtype=NSEC.  Cache B has the CNAME in cache, it picks up the CNAME,
>follows it and returns the wrong NSEC answer.  It validates because the
>CNAME and cname-target NSEC verify.
>
>(quick authority sketch: NSEC3 signed zone, qtype=NSEC, follows a CNAME
>and returns the NSEC3 record for the wrong name.).
>
>The text is: There is a set of metadata types that are allowed next to
>CNAMEs, this set contains NSEC, RRSIG and NSEC3 (reference RFC403x,
>5155).  For queries for types in this set, a server MUST NOT follow a
>CNAME if that is present.
>
>More text is: For a validation proof a CNAME is not allowed when
>constructing a proof if the query type is in the set of metadata types
>allowed next to CNAMEs.
>
>Best regards,
>   Wouter
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.9 (GNU/Linux)
>Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
>iEYEARECAAYFAkvVgakACgkQkDLqNwOhpPj9wgCcCBk5GLp/UrFIyRUVv5rBgNUI
>70gAn0ctI96VVdQ7+lFBB3dqK6akE91p
>=cUJ9
>-----END PGP SIGNATURE-----

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Wouldn't it be nice if all of the definitions of equivalence were the same?
--============_-939825558==_ma============-- From owner-namedroppers@ops.ietf.org Mon Apr 26 08:56:54 2010 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 926AC3A6981; Mon, 26 Apr 2010 08:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.944 X-Spam-Level: X-Spam-Status: No, score=0.944 tagged_above=-999 required=5 tests=[AWL=-1.315, BAYES_20=-0.74, 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 1fX9DegEZFnx; Mon, 26 Apr 2010 08:56:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AFA713A6405; Mon, 26 Apr 2010 08:56:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6QcR-000LCP-HV for namedroppers-data0@psg.com; Mon, 26 Apr 2010 15:53:11 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6QcM-000L8A-Ao for namedroppers@ops.ietf.org; Mon, 26 Apr 2010 15:53:06 +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 DF2FC1ECB533 for ; Mon, 26 Apr 2010 15:53:04 +0000 (UTC) Date: Mon, 26 Apr 2010 11:53:03 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXTaliasmaybe-work Message-ID: <20100426155302.GE11550@shinkuro.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <471859708.23475@cnnic.cn> <960980B4EA9244D7901B20019153D559@abc> <472039311.32451@cnnic.cn> 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, Apr 26, 2010 at 03:45:42PM +0800, YAO Jiankang wrote: > > if you have time, you can take a look at RFC 3743 and you will have clearer image about this. I'd read that before. I've been led to believe that only some of the IDLs at any given level that would normally have been generated under 3743 conventions were in fact being generated, in order to avoid a large fan-out of many domains. Perhaps that's the case anyway, but it's not actually a goal, just an effect of having to compromise. > > we hope that R1S1.T1, R2S2.T1, R1S2.T1, R2S1.T1, R1S1.T2, R2S2.T2, R1S2.T2, R2S1.T2 all 8 domain names (trees) to be same. > R1S1.T1 and R2S2.T2 are just instances of all 8 domain names (trees). And so, similarly, subsequebt delegations would have to be R1S1.R1S1.T1 R2S2.R1S1.T1 R1S2.R1S1.T1 R2S1.R1S1.T1 R1S1.R2S2.T1 and so on, all the way through, right? If that's ok, then that's indeed case (c) and case (b) just drops out. Yay! Is there _anyone_ who needs case (b), then? If not, we'll rule it out of the list of problems we're trying to solve. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Apr 26 13:03:39 2010 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 A33E93A689D; Mon, 26 Apr 2010 13:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.967 X-Spam-Level: * X-Spam-Status: No, score=1.967 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_50=0.001, 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 MLe5y7saaVF2; Mon, 26 Apr 2010 13:03:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A5B3B3A6944; Mon, 26 Apr 2010 13:03:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6UP2-000OvH-Gb for namedroppers-data0@psg.com; Mon, 26 Apr 2010 19:55:36 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6UOy-000Ouv-SA for namedroppers@ops.ietf.org; Mon, 26 Apr 2010 19:55:33 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3QJtKZ9076151; Mon, 26 Apr 2010 15:55:21 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Mon, 26 Apr 2010 15:55:30 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 26 Apr 2010 15:55:30 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 26 Apr 2010 15:55:15 -0400 To: Matthew Dempsky From: Edward Lewis Subject: Re: [dnsext] DNSCurve name server selection Cc: IETF DNSEXT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 11:13 -0700 4/23/10, Matthew Dempsky wrote: > A. > B. Same as A, but the cache sorts its list of name servers ... > C. Caches only contact DNSCurve-enabled servers... > D. >Any thoughts? First I'll say that it is fine to put recommendations in the draft, but until now, no one has put firm requirements on a resolver's actions. "Local policy" should always be allowed. Second, I'd recommend specifying simple strategies, but not to simple as to be random. I.e., D is over complicated and A is a waste of time to explain. Perhaps you can describe B & C and mention that a "general purpose implementation" might want to allow a user to choose. The reason for C is that the operator is really interested in applying this security. The reason for B is resiliency, sometimes, it's better to get anything as opposed to holding out for the provably safe answer. We've learned some lessons in deriving DNSSEC, A6 and bit labels. It's gotta be plum simple to work. Fancy policies means fancy specification languages are needed - and we aren't good parser writers. If you require a DNS element to think much, it can be tied up in knots easily. Ask anyone that really understands bit labels to explain it up on a chalkboard and you are guaranteed to see someone to get the example wrong. If you can't do it by hand, a DNS server won't be able to handle it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From owner-namedroppers@ops.ietf.org Mon Apr 26 19:38:15 2010 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 B535D28C111; Mon, 26 Apr 2010 19:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_50=0.001, J_CHICKENPOX_55=0.6] 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 kN3Fh9caQTDx; Mon, 26 Apr 2010 19:38:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 65AC828C10C; Mon, 26 Apr 2010 19:38:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6aZZ-000Kkz-Q9 for namedroppers-data0@psg.com; Tue, 27 Apr 2010 02:30:53 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6aZX-000Kkm-3w for namedroppers@ops.ietf.org; Tue, 27 Apr 2010 02:30:51 +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 E5F49E9ADB; Tue, 27 Apr 2010 02:30:48 +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 o3R2UZM8016346; Tue, 27 Apr 2010 12:30:38 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004270230.o3R2UZM8016346@drugs.dv.isc.org> To: "George Barwood" Cc: "Florian Weimer" , namedroppers@ops.ietf.org From: Mark Andrews References: <1A979899C32A42C7A8505FA3621D1342@local> <87zl0rcvp0.fsf@mid.deneb.enyo.de> <201004252328.o3PNSGrw098670@drugs.dv.isc.org> <66DE2F29E0C348D88A8851AE0E747819@local> Subject: Re: [dnsext] "Proof" that CNAME + DNAME is safe In-reply-to: Your message of "Mon, 26 Apr 2010 07:13:46 +0100." <66DE2F29E0C348D88A8851AE0E747819@local> Date: Tue, 27 Apr 2010 12:30:35 +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 <66DE2F29E0C348D88A8851AE0E747819@local>, "George Barwood" writes: > > ----- Original Message ----- > From: "Mark Andrews" > To: "George Barwood" > Cc: "Florian Weimer" ; > Sent: Monday, April 26, 2010 12:28 AM > Subject: Re: [dnsext] "Proof" that CNAME + DNAME is safe > > > > > > In message , "George Barwood" writes: > >> Florian > >> > >> ----- Original Message ----- > >> From: "Florian Weimer" > >> To: "George Barwood" > >> Cc: > >> Sent: Sunday, April 25, 2010 6:02 PM > >> Subject: Re: [dnsext] "Proof" that CNAME + DNAME is safe > >> > >> > >> >* George Barwood: > >> > > >> >> Therefore correct resolvers cannot fail, because that would mean > >> >> they are fundamentally incorrect, that is they would fail if the > >> >> zone had been updated between the two queries. > >> > > >> > If there is inconsistent data with overlapping time-to-live, resolvers > >> > are allowed to fail queries, so I don't think this argument is correct > >> > even from a formal point of view. > >> > >> Temporal inconsistencies can arise, for example where an RRSIG references > >> a DNSKEY record. This means that new keys should not be used until the old > >> DNSKEY RRset has had time to expire ( or that old signatures be supplied in addition ). > >> And there are other cases, e.g. a NS RRset may reference A records, that must be served > >> until the old NS RRset has had time to expire, or failures can occur, etc. > >> > >> But I don't see how any temporal inconsistency can arise in this case, since > >> queries below the DNAME are independent of queries at the DNAME owner. > >> Neither one gives any information about the other ( non-trivial statement, but I think > >> it holds). The job of a resolver can be seen as obtaining an authoritative response > >> to QNAME:QTYPE, after following CNAME indirection, and that response may be cached. > >> http://tools.ietf.org/html/rfc4035#section-4.5 cautions against using results from one > >> response to infer facts about other queries ( although I don't rely on that here ). > >> > >> Perhaps you could be more explicit about what inconsistencies could have any effect here. > >> I don't see any ( but I accept that my "proof" could be seen as incomplete until all possible > >> cases have been enumerated - probably by someone more expert in the DNS standard than myself ). > >> > >> > In the end, actual deployed resolver behavior trumps these > >> > considerations anyway, especially this is about introducing a protocol > >> > incompatibility. > >> > >> Well yes. But what I'm saying is that there is no incompatibility, and demonstrating how > >> no such incompatibility can arise in correct resolvers. > >> > >> Not setting the DNAME bit in the NSEC record when the CNAME bit is set is the key - a resolver > >> could possibly reject an NSEC record with the CNAME and DNAME bits both set as bogus/invalid. > >> But having solved that, I cannot see how any incompatibility can arise. > > > > But that is exactly the NEC/NSEC3 record that MUST work. It is > > ridiculous to require the authoritative server to serve up different > > NSEC/NSEC3 records and their signatures. > > It may be "disturbing", but why "ridiculous"? > > Note that the type bitmap of a NSEC record at a CNAME is never used, since the CNAME > redirects every type. The NSEC record is used only to prove non-existence of adjacent > non-existent domains, never NoData conditions at the CNAME owner ( since such conditions > cannot arise ). > > So why do you say it "MUST" work? > > George Because you should prove no DNAME to accept NXDOMAIN. This can require checking to see if the DNAME bit is set depending on whether the next name is below the owner name of the NSEC or not. e.g. foo.example.com NSEC foo.example.com SOA NS RRSIG NSEC foo.example.com NSEC example.com CNAME DNAME RRSIG NSEC So you can't remove DNAME. You also can't remove CNAME, to prevent spoofing away of the CNAME, as now CNAME can co-exist with DNAME. 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 Mon Apr 26 20:56:33 2010 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 9E46F28C11E; Mon, 26 Apr 2010 20:56:33 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 3.515 X-Spam-Level: *** X-Spam-Status: No, score=3.515 tagged_above=-999 required=5 tests=[AWL=-0.634, BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 hA2sMYKP2o5I; Mon, 26 Apr 2010 20:56:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC5A63A6823; Mon, 26 Apr 2010 20:56:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6bos-00095E-H7 for namedroppers-data0@psg.com; Tue, 27 Apr 2010 03:50:46 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6bop-00093V-Hp for namedroppers@ops.ietf.org; Tue, 27 Apr 2010 03:50:43 +0000 Received: (eyou send program); Tue, 27 Apr 2010 11:50:42 +0800 Message-ID: <472340242.23941@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 27 Apr 2010 11:50:42 +0800 Message-ID: From: "YAO Jiankang" To: "Andrew Sullivan" , References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <471859708.23475@cnnic.cn> <960980B4EA9244D7901B20019153D559@abc> <472039311.32451@cnnic.cn> <472297983.10270@cnnic.cn> Subject: Re: [dnsext] ICANN's "synchronized domains" and theDNSEXTaliasmaybe-work Date: Tue, 27 Apr 2010 11:50:56 +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.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: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFuZHJldyBTdWxsaXZhbiIg PGFqc0BzaGlua3Vyby5jb20+DQpUbzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50 OiBNb25kYXksIEFwcmlsIDI2LCAyMDEwIDExOjUzIFBNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0g SUNBTk4ncyAic3luY2hyb25pemVkIGRvbWFpbnMiIGFuZCB0aGVETlNFWFRhbGlhc21heWJlLXdv cmsNCg0KDQo+IE9uIE1vbiwgQXByIDI2LCAyMDEwIGF0IDAzOjQ1OjQyUE0gKzA4MDAsIFlBTyBK aWFua2FuZyB3cm90ZToNCj4+IA0KPj4gaWYgeW91IGhhdmUgdGltZSwgeW91IGNhbiB0YWtlIGEg bG9vayBhdCBSRkMgMzc0MyBhbmQgeW91IHdpbGwgaGF2ZSBjbGVhcmVyIGltYWdlIGFib3V0IHRo aXMuDQo+IA0KPiBJJ2QgcmVhZCB0aGF0IGJlZm9yZS4gIEkndmUgYmVlbiBsZWQgdG8gYmVsaWV2 ZSB0aGF0IG9ubHkgc29tZSBvZiB0aGUNCj4gSURMcyBhdCBhbnkgZ2l2ZW4gbGV2ZWwgdGhhdCB3 b3VsZCBub3JtYWxseSBoYXZlIGJlZW4gZ2VuZXJhdGVkIHVuZGVyDQo+IDM3NDMgY29udmVudGlv bnMgd2VyZSBpbiBmYWN0IGJlaW5nIGdlbmVyYXRlZCwgaW4gb3JkZXIgdG8gYXZvaWQgYQ0KPiBs YXJnZSBmYW4tb3V0IG9mIG1hbnkgZG9tYWlucy4gIFBlcmhhcHMgdGhhdCdzIHRoZSBjYXNlIGFu eXdheSwgYnV0DQo+IGl0J3Mgbm90IGFjdHVhbGx5IGEgZ29hbCwganVzdCBhbiBlZmZlY3Qgb2Yg aGF2aW5nIHRvIGNvbXByb21pc2UuDQo+IA0KPj4gDQo+PiB3ZSBob3BlIHRoYXQgIFIxUzEuVDEs IFIyUzIuVDEsIFIxUzIuVDEsICBSMlMxLlQxLCAgUjFTMS5UMiwgUjJTMi5UMiwgUjFTMi5UMiwg IFIyUzEuVDIgYWxsIDggZG9tYWluIG5hbWVzICh0cmVlcykgdG8gYmUgc2FtZS4NCj4+IFIxUzEu VDEgYW5kIFIyUzIuVDIgYXJlIGp1c3QgaW5zdGFuY2VzIG9mIGFsbCA4IGRvbWFpbiBuYW1lcyAo dHJlZXMpLg0KPiANCj4gQW5kIHNvLCBzaW1pbGFybHksIHN1YnNlcXVlYnQgZGVsZWdhdGlvbnMg d291bGQgaGF2ZSB0byBiZSANCj4gDQo+ICAgIFIxUzEuUjFTMS5UMQ0KPiAgICBSMlMyLlIxUzEu VDENCj4gICAgUjFTMi5SMVMxLlQxDQo+ICAgIFIyUzEuUjFTMS5UMQ0KPiAgICBSMVMxLlIyUzIu VDENCj4gDQo+IGFuZCBzbyBvbiwgYWxsIHRoZSB3YXkgdGhyb3VnaCwgcmlnaHQ/ICANCg0KeWVz LCB5b3UgY2FuIGRlbGVnYXRlIHRoZW0gYWxsLg0KDQoNCmZvciB0aG9zZSB3aG8gcmVxdWlyZSBS UyB1bmRlciB0aGUgZG9tYWluIFIxUzEuVDEsDQoNCnRoZSBjdXJyZW50IHByYWN0aXNlIGlzIHRo YXQgd2UgZGVsZWdhdGUgUjFTMS5SMVMxLlQxIGFuZCAgUjJTMi5SMVMxLlQxLg0KDQp0aGUgUjFT Mi5SMVMxLlQxIGFuZCAgUjJTMS5SMVMxLlQxIGFyZSBvcHRpb25hbCwgd2UgZGVsZWdhdGUgaXQg b3IgcmVzZXJ2ZSBpdCBmb3IgdGhlIHJlZ2lzdHJhbnQgYmFzZWQgb24gdGhlIHJlZ2lzdHJhbnRz JyByZXF1aXJlbWVudC4NCg0KDQoNCj5JZiB0aGF0J3Mgb2ssIHRoZW4gdGhhdCdzDQo+IGluZGVl ZCBjYXNlIChjKSBhbmQgY2FzZSAoYikganVzdCBkcm9wcyBvdXQuICBZYXkhDQo+IA0KDQorMQ0K DQoNCj4gSXMgdGhlcmUgX2FueW9uZV8gd2hvIG5lZWRzIGNhc2UgKGIpLCB0aGVuPyAgSWYgbm90 LCB3ZSdsbCBydWxlIGl0IG91dA0KPiBvZiB0aGUgbGlzdCBvZiBwcm9ibGVtcyB3ZSdyZSB0cnlp bmcgdG8gc29sdmUuDQo+IA0KPiBBDQo+IA0KPiAtLSANCj4gQW5kcmV3IFN1bGxpdmFuDQo+IGFq c0BzaGlua3Vyby5jb20NCj4gU2hpbmt1cm8sIEluYy4NCj4= From loan@vilab.hit.edu.cn Tue Apr 27 00:14:22 2010 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 910583A6A27 for ; Tue, 27 Apr 2010 00:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.622 X-Spam-Level: *** X-Spam-Status: No, score=3.622 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] 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 IRTEsec6d57H for ; Tue, 27 Apr 2010 00:14:21 -0700 (PDT) Received: from vilab.hit.edu.cn (vilab.hit.edu.cn [202.118.250.15]) by core3.amsl.com (Postfix) with ESMTP id 5120C3A6BC2 for ; Tue, 27 Apr 2010 00:14:21 -0700 (PDT) Received: from vilab.hit.edu.cn (localhost [127.0.0.1]) by vilab.hit.edu.cn (Postfix) with ESMTP id 1C2F46CE53E; Wed, 21 Apr 2010 05:13:39 +0800 (CST) From: "Global SpringerLink Finance Investments!" Reply-To: enquiries@hell-world.net Subject: Loan at 3% rate, Date: Wed, 21 Apr 2010 05:13:38 +0800 Message-Id: <20100420192111.M92221@vilab.hit.edu.cn> X-Mailer: OpenWebMail 2.53-B2D X-OriginatingIP: 41.203.64.241 (dcliu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 To: undisclosed-recipients:; Loan at 3% rate, if interested contact us now…….2010 Loan Offer. From loan@vilab.hit.edu.cn Tue Apr 27 00:14:30 2010 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 6506E3A6A27 for ; Tue, 27 Apr 2010 00:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.249 X-Spam-Level: *** X-Spam-Status: No, score=3.249 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5] 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 QKPZHzigKeS0 for ; Tue, 27 Apr 2010 00:14:29 -0700 (PDT) Received: from vilab.hit.edu.cn (vilab.hit.edu.cn [202.118.250.15]) by core3.amsl.com (Postfix) with ESMTP id 336C83A65A6 for ; Tue, 27 Apr 2010 00:14:29 -0700 (PDT) Received: from vilab.hit.edu.cn (localhost [127.0.0.1]) by vilab.hit.edu.cn (Postfix) with ESMTP id 1C2F46CE53E; Wed, 21 Apr 2010 05:13:39 +0800 (CST) From: "Global SpringerLink Finance Investments!" Reply-To: enquiries@hell-world.net Subject: Loan at 3% rate, Date: Wed, 21 Apr 2010 05:13:38 +0800 Message-Id: <20100420192111.M92221@vilab.hit.edu.cn> X-Mailer: OpenWebMail 2.53-B2D X-OriginatingIP: 41.203.64.241 (dcliu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 To: undisclosed-recipients:; Loan at 3% rate, if interested contact us now…….2010 Loan Offer. From owner-namedroppers@ops.ietf.org Tue Apr 27 06:41:10 2010 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 549C83A6A81; Tue, 27 Apr 2010 06:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.88 X-Spam-Level: X-Spam-Status: No, score=0.88 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_50=0.001, 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 plouCr0A60iC; Tue, 27 Apr 2010 06:41:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 00CC73A69CF; Tue, 27 Apr 2010 06:41:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6kuD-0005a8-0g for namedroppers-data0@psg.com; Tue, 27 Apr 2010 13:32:53 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6ku8-0005ZU-UR for namedroppers@ops.ietf.org; Tue, 27 Apr 2010 13:32:49 +0000 Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3RDWfEK082981; Tue, 27 Apr 2010 09:32:42 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4BD6E776.8020908@ogud.com> Date: Tue, 27 Apr 2010 09:32:38 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Matthew Dempsky CC: namedroppers Subject: Re: [dnsext] Side effect of DNS control plane changes Re: BNAME, Synthesized CNAME, and DNSSEC References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <20100422171521.GK1362@shinkuro.com> <201004230447.o3N4lsSv071899@drugs.dv.isc.org> <4BD21125.70307@ogud.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 23/04/2010 6:55 PM, Matthew Dempsky wrote: > On Fri, Apr 23, 2010 at 2:29 PM, Olafur Gudmundsson wrote: >> Mark is right, when ever we change the DNS control plane, we need to >> renumber some DNSKEY algorithms that are in use. >> >> At the same time do we need to put in place a requirement that new >> algorithm specifications list what control plane version the >> algorithm is defined for? > > Is there a reason for needing to renumber algorithms like this? E.g., > is there a reason you couldn't just chain identifiers together? > > Suppose NSEC3 had defined a generic "NSEC3" key type. The public key > field could then just embed another 8-bit algorithm field followed by > that algorithm's respective public key data. > > So instead of > > foo.com DNSKEY ... RSA-NSEC3 [rsa-key] > foo.com DNSKEY ... DSA-NSEC3 [dsa-key] > > you'd have > > foo.com DNSKEY NSEC3 RSA [rsa-key] > foo.com DNSKEY NSEC3 DSA [dsa-key] > > Then new keys can continue to define just a specific algorithm, and > new DNS control planes also only need one new identifier each. > > > Excellent question, at one point in DNSSEC development we talked about doing KEYALG + HASHALG as two different fields in the KEY Record (yes this was that long ago). I think the reason we decided to not go this direction was the fear of sub-typing (think TXT misuse). We wanted an explicit statement what was in use and no one thought we could possibly have an explosion in new Crypto algorithms. This discission was firmly based on our understanding of DNS at the time. Since then we have gained much better understanding of the "DNS control plane", and the implications that a changes in the control plane affect resolvers and zones. When we were arguing (in 2002-2003) about the type code rollover (KEY/SIG/NXT --> DNSKEY/RRSIG/NSEC) there was a proposal to use the protocol field in the DNS KEY record to indicate the change (i.e. use 4 instead of 3). I do not of the top of my head remember why the WG decided to renumber rather than change protocol, but it may have had to do with resolver could not decide what to do until after they had the DNSKEY record for a domain). DNAME and wild-card clarify became major forces during DNSSEC-bis in advancing the community understanding of the DNS control-plane issues, NSEC3 drove the point home. The most important point is to make sure that validating resolvers do not try to validate answers from zones the validator where "unknown" DNS "controls" are in use, thus we blind them with new algorithm numbers. So the long winded answer to your question is: "Yes if we decided to do that in 2001-2002, but the train has left the station". We still have the option of starting to take advantage of the "protocol number" IFF we know that current validators check the value and barf at unknown protocol versions, AND we replace the DS with one that includes the protocol number (another big control plane change). hope this helps Olafur (DNSEXT historian) From owner-namedroppers@ops.ietf.org Tue Apr 27 07:00:22 2010 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 DE6EE3A6B27; Tue, 27 Apr 2010 07:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.167 X-Spam-Level: X-Spam-Status: No, score=-98.167 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_50=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, 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 06BrUL2wjHRJ; Tue, 27 Apr 2010 07:00:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1F9483A6A60; Tue, 27 Apr 2010 07:00:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6lCg-000AAe-UV for namedroppers-data0@psg.com; Tue, 27 Apr 2010 13:51:58 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6lCd-000AAF-RN for namedroppers@ops.ietf.org; Tue, 27 Apr 2010 13:51:56 +0000 Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id AF1CD7343C0 for ; Tue, 27 Apr 2010 15:51:53 +0200 (CEST) Message-ID: <4BD6EBF9.2030508@nic.cz> Date: Tue, 27 Apr 2010 15:51:53 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] dnssec-bis-updates item about CNAME References: <4BD581A9.3030206@nlnetlabs.nl> In-Reply-To: <4BD581A9.3030206@nlnetlabs.nl> 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 26.4.2010 14:06, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > After a discussion with Ondrej about CNAME+DNAME, I realized that there > may be an omission in the dnssec spec about CNAME and other metadata. Just adding that this applies to BNAME as well (since it acts as CNAME for the owner) Ondrej -- Ondřej Surý vedoucí výzkumu/R&D manager ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From owner-namedroppers@ops.ietf.org Tue Apr 27 07:24:39 2010 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 BA4CD3A6B96; Tue, 27 Apr 2010 07:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.2 X-Spam-Level: X-Spam-Status: No, score=-98.2 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, 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 B2w+csUgGjT7; Tue, 27 Apr 2010 07:24:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0898528C158; Tue, 27 Apr 2010 07:18:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6lVW-000FIC-8q for namedroppers-data0@psg.com; Tue, 27 Apr 2010 14:11:26 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6lVT-000FE5-Ie for namedroppers@ops.ietf.org; Tue, 27 Apr 2010 14:11:23 +0000 Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 403A476C057; Tue, 27 Apr 2010 16:11:16 +0200 (CEST) Message-ID: <4BD6F083.6040201@nic.cz> Date: Tue, 27 Apr 2010 16:11:15 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: George Barwood CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] "Proof" that CNAME + DNAME is safe References: <1A979899C32A42C7A8505FA3621D1342@local> <87zl0rcvp0.fsf@mid.deneb.enyo.de> <201004252328.o3PNSGrw098670@drugs.dv.isc.org> <66DE2F29E0C348D88A8851AE0E747819@local> <201004270230.o3R2UZM8016346@drugs.dv.isc.org> <164C8EB632284D5C9BD28BE2000FBF02@local> In-Reply-To: <164C8EB632284D5C9BD28BE2000FBF02@local> 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 27.4.2010 08:17, George Barwood wrote: > So back to either hoping resolvers don't fail when they see > CNAME+DNAME set in an NSEC, or new algorithms. George, let's wait for my thorough testing I am planning to do, so we don't have to hope. Unfortunately I have only two days in work this week, so I will probably do that in RIPE week or week after that. That will hopefully remove some fears of general DNS breakage. Ondrej -- Ondřej Surý vedoucí výzkumu/R&D manager ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From jperezc@afasa.com.mx Tue Apr 27 07:50:13 2010 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 922A528C296 for ; Tue, 27 Apr 2010 07:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.276 X-Spam-Level: X-Spam-Status: No, score=-9.276 tagged_above=-999 required=5 tests=[AWL=3.666, 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, HOST_EQ_BR=1.295, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FORGED_AMAZON=3, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, 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 kUgyKpGzkttE for ; Tue, 27 Apr 2010 07:50:11 -0700 (PDT) Received: from 201-10-39-217.paemt704.dsl.brasiltelecom.net.br (201-10-39-217.paemt704.dsl.brasiltelecom.net.br [201.10.39.217]) by core3.amsl.com (Postfix) with SMTP id 78DE128C125 for ; Tue, 27 Apr 2010 07:43:24 -0700 (PDT) From: "Amazon.com Email Subscriptions" To: "dnsext-archive@ietf.org" Subject: Amazon.com Deal of the Day X-AMAZON-MAIL-RELAY-TYPE: subscription X-AMAZON-RTE-VERSION: 2.0 MIME-Version: 1.0 Content-Type: text/html X-Antivirus: avast! (VPS 091023-0, 23/10/2009), Outbound message X-Antivirus-Status: Clean Message-Id: <20100427144325.78DE128C125@core3.amsl.com> Date: Tue, 27 Apr 2010 07:43:24 -0700 (PDT)
Please click here if the e-mail below is not displayed correctly.
amazon.com
Free Two-Day Shipping with  › Amazon Prime
Your Amazon.com Today's Deals See All Departments
PharmTomTom XL 340S 4.3-Inch Portable GPS Navigator Bundle with Case
$199.95 $89.99 (55% off)
3.68398268398268
The TomTom XL 340S Bundle includes the TomTom XL 340S device plus a Soft Quilted Carry Case. Switch on and go right out of the box. Spoken turn-by-turn instructions including street names will guide you to any address in the US, Canada and Mexico--including more than 7 million preloaded points of interest.
Explore Other Great Gold Box Deals
Save on Hitachi's Most Popular 18-Guage Brad Nailer
Just $19.29: Behringer High-Def DJ Headphones
Save $10 on "Alice in Wonderland Combo Pack"
Great GPS to Make Mom's Life Easier
Save on Hitachi's Most Popular 18-Guage Brad Nailer
$148.05 $69.17 (53% off)
 
 
Just $19.29: Behringer High-Def DJ Headphones
 
 
Save $10 on "Alice in Wonderland Combo Pack"
 
 
Great GPS to Make Mom's Life Easier
 
Save up to 40% on Our Bestselling Fitness Products
100 Albums for $5 Each
Diamond Month: Save up to 40% on Diamond and Crystal-Accented Watches
Sony Laptops Clearance
Save up to 40% on Our Bestselling Fitness Products
 
 
100 Albums for $5 Each
 
 
Diamond Month: Save up to 40% on Diamond and Crystal-Accented Watches
 
 
Sony Laptops Clearance
 


This message was sent to the following e-mail address: dnsext-archive@ietf.org

You're receiving this e-mail because you subscribed to Gold Box Deals. If you do not want any more e-mails of this kind, it's easy to unsubscribe.

Please note that product prices and availability are subject to change. Prices and availability were accurate at the time this newsletter was sent; however, they may differ from those you see when you visit Amazon.com. The List Price represents the full retail price listed on the product itself, suggested by the manufacturer or supplier, or estimated in accordance with standard industry practice. For items offered as a set, List Price may represent open-stock prices.

© 2010 Amazon.com. All rights reserved.
Amazon.com is a registered trademark of Amazon.com, Inc.
Amazon.com, 1200 12th Ave. S., Suite 1200, Seattle, WA 98144-2734.
Reference: 15122060
From owner-namedroppers@ops.ietf.org Tue Apr 27 10:46:44 2010 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 B67C028C138; Tue, 27 Apr 2010 10:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.301 X-Spam-Level: ** X-Spam-Status: No, score=2.301 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_50=0.001, 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 midTlk1POU83; Tue, 27 Apr 2010 10:46:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8473D3A69E8; Tue, 27 Apr 2010 10:46:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6oiQ-000B7E-IT for namedroppers-data0@psg.com; Tue, 27 Apr 2010 17:36:58 +0000 Received: from [209.85.223.180] (helo=mail-iw0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6oiM-000B5F-Fe for namedroppers@ops.ietf.org; Tue, 27 Apr 2010 17:36:54 +0000 Received: by iwn10 with SMTP id 10so9661357iwn.13 for ; Tue, 27 Apr 2010 10:36:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.171.79 with SMTP id g15mr1960927ibz.75.1272389813232; Tue, 27 Apr 2010 10:36:53 -0700 (PDT) Received: by 10.231.214.209 with HTTP; Tue, 27 Apr 2010 10:36:53 -0700 (PDT) In-Reply-To: <4BD6E776.8020908@ogud.com> References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <20100422171521.GK1362@shinkuro.com> <201004230447.o3N4lsSv071899@drugs.dv.isc.org> <4BD21125.70307@ogud.com> <4BD6E776.8020908@ogud.com> Date: Tue, 27 Apr 2010 10:36:53 -0700 Message-ID: Subject: Re: [dnsext] Side effect of DNS control plane changes Re: BNAME, Synthesized CNAME, and DNSSEC From: Matthew Dempsky To: Olafur Gudmundsson 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 Tue, Apr 27, 2010 at 6:32 AM, Olafur Gudmundsson wrote: > DNAME and wild-card clarify became major forces during DNSSEC-bis in > advancing the community understanding of the DNS control-plane issues, > NSEC3 drove the point home. The most important point is to make sure that > validating resolvers do not try to validate answers from zones the > validator where "unknown" DNS "controls" are in use, thus we blind them with > new algorithm numbers. Agreed, but I don't see how this ruled out the possibility of an NSEC3 pseudo-algorithm. > So the long winded answer to your question is: "Yes if we decided to do that > in 2001-2002, but the train has left the station". > We still have the option of starting to take advantage of the "protocol > number" IFF we know that current validators check the value and barf at > unknown protocol versions, AND we replace the DS with one that includes the > protocol number (another big control plane change). To be clear, I'm not talking about updating the protocol number. I was sloppy with my previous DNSKEY example, so let me try again with concrete examples. Right now, isc.org has this as one of its DNSKEY records: isc.org. 7200 IN DNSKEY 256 3 5 ( BEAAAAPFYUryQxBgg/QaG6iBM52jIsyn8m5o3CmIsLwzKIHEAGYGyq8M h9dFkwHe0ACYHV/m3PK9jYflBsMJutqCFVH532Mg08qzTByO1VbErKKR 6mdKRTswErMuz7FXaFT2RZIKxdMtFesmP2LTLaW8drasPgR1rB+cMZmY RkC1IWkHwQ== ) Algorithm 5 is RSASHA1. If we want to deploy BNAME and follow the same way that NSEC3 was done, then we'll allocate a new algorithm id for RSASHA1-BNAME, which has an equivalent key layout to RSASHA1 but indicates the zone uses new features. Also, for RSASHA1-NSEC3-BNAME, ECC-GOST-BNAME, etc. Then when people want to start using BNAME, they would simply change the 5 in the above record to the new number. What I'm asking is why isn't a *single* new algorithm id allocated for a pseudo-algorithm "BNAME". Suppose it's given the id 42, then you could change the above record to: isc.org. 7200 IN DNSKEY 256 3 42 ( BQRAAAADxWFK8kMQYIP0GhuogTOdoyLMp/JuaNwpiLC8MyiBxABmBsqvDIfXRZMB 3tAAmB1f5tzyvY2H5QbDCbraghVR+d9jINPKs0wcjtVWxKyikepnSkU7MBKzLs+x V2hU9kWSCsXTLRXrJj9i0y2lvHa2rD4EdawfnDGZmEZAtSFpB8E= ) (The base64 blob here decodes to the same byte string as the original base64 blob, except prepended with the byte "5".) A BNAME aware validator can then recognize the BNAME pseudo-algorithm identifier 42, look at the BNAME "key data" and see from the first byte 5 that it also understands RSASHA1, and know how to validate the zone. Similarly, the same BNAME pseudo-algorithm id can be used to avoid having to allocate extra algorithm ids for RSASHA1-NSEC3-BNAME, ECC-GOST-BNAME, etc. The only issue I can potentially see is that a validator might know how to validate some BNAME keys (e.g., ones with embedded RSASHA1 keys but not ECC-GOST), but I don't see a reason this would actually be a problem. From owner-namedroppers@ops.ietf.org Tue Apr 27 17:26:30 2010 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 C89E63A67D6; Tue, 27 Apr 2010 17:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_50=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 Bwefjb1Zyqzd; Tue, 27 Apr 2010 17:26:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3F7413A6818; Tue, 27 Apr 2010 17:26:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6uxm-000IML-T5 for namedroppers-data0@psg.com; Wed, 28 Apr 2010 00:17:14 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6uxg-000ILr-3w for namedroppers@ops.ietf.org; Wed, 28 Apr 2010 00:17:08 +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 79CC8E9C8D; Wed, 28 Apr 2010 00:17: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 o3S0Gquu032595; Wed, 28 Apr 2010 10:16:54 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004280016.o3S0Gquu032595@drugs.dv.isc.org> To: Matthew Dempsky Cc: Olafur Gudmundsson , namedroppers From: Mark Andrews References: <20100409145117.GH3595@shinkuro.com> <4BC24639.7000202@ucd.ie> <2A18C28A42314CF4822ECCDD8E34B7D4@ics.forth.gr> <4BCF39D9.9090905@mail-abuse.org> <201004212314.o3LNEQKl069128@drugs.dv.isc.org> <20100422171521.GK1362@shinkuro.com> <201004230447.o3N4lsSv071899@drugs.dv.isc.org> <4BD21125.70307@ogud.com> <4BD6E776.8020908@ogud.com> Subject: Re: [dnsext] Side effect of DNS control plane changes Re: BNAME, Synthesized CNAME, and DNSSEC In-reply-to: Your message of "Tue, 27 Apr 2010 10:36:53 MST." Date: Wed, 28 Apr 2010 10:16:52 +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 , Matthew Dempsky writes: > On Tue, Apr 27, 2010 at 6:32 AM, Olafur Gudmundsson wrote: > > DNAME and wild-card clarify became major forces during DNSSEC-bis in > > advancing the community understanding of the DNS control-plane issues, > > NSEC3 drove the point home. The most important point is to make sure that > > validating resolvers do not try to validate answers from zones the > > validator where "unknown" DNS "controls" are in use, thus we blind them with > > new algorithm numbers. > > Agreed, but I don't see how this ruled out the possibility of an NSEC3 > pseudo-algorithm. > > > So the long winded answer to your question is: "Yes if we decided to do that > > in 2001-2002, but the train has left the station". > > We still have the option of starting to take advantage of the "protocol > > number" IFF we know that current validators check the value and barf at > > unknown protocol versions, AND we replace the DS with one that includes the > > protocol number (another big control plane change). > > To be clear, I'm not talking about updating the protocol number. I > was sloppy with my previous DNSKEY example, so let me try again with > concrete examples. > > Right now, isc.org has this as one of its DNSKEY records: > > isc.org. 7200 IN DNSKEY 256 3 5 ( > BEAAAAPFYUryQxBgg/QaG6iBM52jIsyn8m5o3CmIsLwzKIHEAGYGyq8M > h9dFkwHe0ACYHV/m3PK9jYflBsMJutqCFVH532Mg08qzTByO1VbErKKR > 6mdKRTswErMuz7FXaFT2RZIKxdMtFesmP2LTLaW8drasPgR1rB+cMZmY > RkC1IWkHwQ== > ) > > Algorithm 5 is RSASHA1. > > If we want to deploy BNAME and follow the same way that NSEC3 was > done, then we'll allocate a new algorithm id for RSASHA1-BNAME, which > has an equivalent key layout to RSASHA1 but indicates the zone uses > new features. Also, for RSASHA1-NSEC3-BNAME, ECC-GOST-BNAME, etc. > Then when people want to start using BNAME, they would simply change > the 5 in the above record to the new number. > > What I'm asking is why isn't a *single* new algorithm id allocated for > a pseudo-algorithm "BNAME". Suppose it's given the id 42, then you > could change the above record to: > > isc.org. 7200 IN DNSKEY 256 3 42 ( > BQRAAAADxWFK8kMQYIP0GhuogTOdoyLMp/JuaNwpiLC8MyiBxABmBsqvDIfXRZMB > 3tAAmB1f5tzyvY2H5QbDCbraghVR+d9jINPKs0wcjtVWxKyikepnSkU7MBKzLs+x > V2hU9kWSCsXTLRXrJj9i0y2lvHa2rD4EdawfnDGZmEZAtSFpB8E= > ) > > (The base64 blob here decodes to the same byte string as the original > base64 blob, except prepended with the byte "5".) > > A BNAME aware validator can then recognize the BNAME pseudo-algorithm > identifier 42, look at the BNAME "key data" and see from the first > byte 5 that it also understands RSASHA1, and know how to validate the > zone. > > Similarly, the same BNAME pseudo-algorithm id can be used to avoid > having to allocate extra algorithm ids for RSASHA1-NSEC3-BNAME, > ECC-GOST-BNAME, etc. > The only issue I can potentially see is that a validator might know > how to validate some BNAME keys (e.g., ones with embedded RSASHA1 keys > but not ECC-GOST), but I don't see a reason this would actually be a > problem. While it is do able (the oid and private id space demonstates that) you still have all the combinations of extensions to deal with. Note when I described this every id that supported BNAME also supported NSEC3 and plain DNSSEC. You don't get BNAME support without NSEC3 support. Going forward I would not expect new algorithms to not support both BNAME and NSEC3. So it is the cost of implementing this vs 3 extra algorithm numbers. Note we will NEVER run out of algorithm numbers even if we add a new one every day. We will just switch move the algorithm number into the start of the public key. more than likely signaled by algorithm 255. This is why 255 is currently reserved so we can design this escape path when we need to. 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 Apr 28 09:02:01 2010 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 0D3593A6B13; Wed, 28 Apr 2010 09:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.843 X-Spam-Level: X-Spam-Status: No, score=0.843 tagged_above=-999 required=5 tests=[AWL=-1.262, BAYES_50=0.001, 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 7mhqlZX24dj6; Wed, 28 Apr 2010 09:02:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A11E83A6B49; Wed, 28 Apr 2010 09:01:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O79W9-00047B-BR for namedroppers-data0@psg.com; Wed, 28 Apr 2010 15:49:41 +0000 Received: from [209.85.211.174] (helo=mail-yw0-f174.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O79W5-00045q-OZ for namedroppers@ops.ietf.org; Wed, 28 Apr 2010 15:49:38 +0000 Received: by ywh4 with SMTP id 4so3111323ywh.5 for ; Wed, 28 Apr 2010 08:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=mpzHLgCCd78JGlFaFPDZXSUftDiZexOxjSyrIGzXbPo=; b=RlvENjQLJNjTlVqBLI8zWu65TkSzZ3iudXvBOYz3WkQajbsWKvWAuQ/zB996PkFxcu 8nbnoawcdmjgKug6E5qVGnNFg8tdPlQgGEwAIGs7BullixW65YEm3T3mqEQuQ2iBGUVK 06O3S8JJvtEGnK656NyxNN3Qa3Aw5yiMLbYr4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=ktxYHsj2YbaTzNd5IKuWQFJ6H2PLGFS+5xn4JCFOisrDKR8iNPTyZV9RzNDq11R68d ofOhvsELUoCPK/DRdA5ESozCWEDqu5f47rwkog506GJCGHT9PzycgtlOB8sBPLB5rm3z cuyo4WtkPUQ10O83mAIAwyA27AB10KubQdM8U= MIME-Version: 1.0 Received: by 10.101.127.1 with SMTP id e1mr3343639ann.243.1272469776346; Wed, 28 Apr 2010 08:49:36 -0700 (PDT) Received: by 10.100.178.1 with HTTP; Wed, 28 Apr 2010 08:49:36 -0700 (PDT) Date: Wed, 28 Apr 2010 12:49:36 -0300 Message-ID: Subject: Multiple methods for aliasing (Was Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work) From: Brian Dickson To: Andrew Sullivan Cc: Vaggelis Segredakis , "Niall O'Reilly" , namedroppers@ops.ietf.org, Sotiris Panaretou 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: There are some issues that I think might be being overlooked a bit, in that we're mixing discussions of specific proposals, and requirements... (More below...) > Given the three types of redirection that I previously outlined, which > of them (and to what extent) do you think the BNAME proposal solves? > To remind, I offered these three candidates (see > http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00890.html). One thing to consider is, that at each label in the FQDN of a name being resolved, it is possible that *different* kinds of aliasing could be implemented. The reasons for using different alias methods might in fact be derived from the characteristics of each method. And, as such, we should be careful to consider the benefits of supporting more than one such method, in our analysis, recommendations, IDs, etc., especially as concerns what new WG work to consider. Here's a not-necessarily complete list of method-types and implications to deployed code and/or DNS zones: (a) client-side (resolver-side) alias methods. These are things similar to CNAME, DNAME, and BNAME (as proposed). They require the resolver to do additional work, and to understand new types. The main characteristic is, they are effectively "restrictive", and occur on the parent side of aliasing only. Some changes are needed to both recursive resolvers, and validating resolvers for DNSSEC, in addition to having authoritative servers serve up the new type. They are "transparent" to the child side of the alias target, in that the child does not need to know about the alias(es), and that the child basically can't prevent the alias from happening. (b) server-side (authority-side) alias methods. These are things which involve changes to meta-data and authority servers only. They do not require the resolver to do anything new, and are effectively backward-compatible completely, except as concerns DNSSEC. For DNSSEC, there may or may not be additional work in changing validation logic, in order to make the combinatorial issues for signatures go away. In the absence of changes to DNSSEC validation, however, the implementation via having DNSSEC signatures on all combinations of aliases, would make these methods *completely* backward compatible. The main characteristic is, they are effectively "permissive", and occur on the child side of aliasing only. The parent side of aliases simply use delegations (NS with optional DS) to the alias-implementing server(s). They are "transparent" to the parent side of the alias target, in that the parent does not need to know about the alias(es), and the parent can't enforce aliasing. My observations on these methods are the following: Server-side methods can be implemented *now*, without protocol changes. These would provide an evolutionary path to achieving scalable, widely deployed aliasing. Additional server-side incremental changes to DNSSEC validation have an easier deployment path, with fewer protocol changes, and a shorter "tail" (since they only require changes to existing validating resolvers deployed). Sever-side methods are likely to be popular at the SLD level and below, simply because there is less work involved (on making changes upstream) and more backward compatibility. Client-side methods are likely to be popular, or even mandated eventually, at the root and TLD levels, specifically because of the "restrictive" characteristic. Enforceability and least-surprise goals inform this conclusion. Thus, even though the tail is longer, there is more intrinsic impetus to deploy client-side changes (i.e. upgrading resolvers). Server-side -> client-side as an evolutionary path makes *both* attractive as WG items, especially given possible deployment long-tail issues. And finally, I believe these are mix-and-match, with no topological restrictions per se. I don't see anything that would make client-side beneath server-side impossible, or vice versa. Brian P.S. server-side would look something like this, to give a concrete example: On authority server ns.example.com: foo.example.com NS ns.foobar.example.com (and glue) bar.example.com NS ns.foobar.example.com (and glue) On authority server ns.foobar.example.com: foo.example.com SOA .... (link internally to zone data for foo.example.com) bar.example.com SOA ... (link internally to zone data for ===> foo.example.com <===) Additional meta-data is needed controlling things like "notify", "secondary", reload-signaling, etc.: A linked zone which is primary, would need to notify any secondaries of any aliases. A linked zone which is secondary, would need to track only one primary alias, and reload all aliases when a zone transfer happens, and also notify further secondaries (tertiaries). Signing of zone data would need to know about all aliases which require signatures. It is theoretically possible that aliases are topologically sparse on the master->[alias->]secondary->alias [...] tree, with some aliases not being present on the master, but which still require signatures. Again, the server-side method has the two important characteristics: fully backward compatible, and hard-linked (within any given server and associated with a specific SOA SN) aliasing of zone data (name -> rdata). Brian From tsar3@hotelhabita.com Wed Apr 28 11:55:52 2010 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 6347728C114; Wed, 28 Apr 2010 11:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.384 X-Spam-Level: X-Spam-Status: No, score=-17.384 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_XBL=3.033, SARE_SPEC_ROLEX_NOV5F=0.666, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_SBL=20, URIBL_SC_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 Mh+2JBCHZtS3; Wed, 28 Apr 2010 11:55:51 -0700 (PDT) Received: from adsl.eb2-perocovilha.edu.pt (adsl.eb2-perocovilha.edu.pt [194.210.84.73]) by core3.amsl.com (Postfix) with ESMTP id 40A283A69D0; Wed, 28 Apr 2010 11:55:49 -0700 (PDT) Received: from 194.210.84.73 by mx.hotelhabita.com; Wed, 28 Apr 2010 19:55:13 +0000 Date: Wed, 28 Apr 2010 19:55:13 +0000 From: dnsext-archive@ietf.org Subject: Brand name designer watches for less To: Message-ID: <000d01cae704$558addd0$6400a8c0@tsar3> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Tiffany keychains and rings for cheap http://watchperfect.ru From hepatitisbct@smartbroadband.net Wed Apr 28 11:58:18 2010 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 AC5213A6A70; Wed, 28 Apr 2010 11:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.73 X-Spam-Level: X-Spam-Status: No, score=-8.73 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_ALMOST_IP=5.417, FH_HOST_ALMOST_IP=1.889, HELO_DYNAMIC_SPLIT_IP=3.493, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_SBL=20, URIBL_SC_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 fM0brOIqO+P5; Wed, 28 Apr 2010 11:58:18 -0700 (PDT) Received: from 89.Red-80-38-191.staticIP.rima-tde.net (89.Red-80-38-191.staticIP.rima-tde.net [80.38.191.89]) by core3.amsl.com (Postfix) with ESMTP id 25BF83A67B6; Wed, 28 Apr 2010 11:58:16 -0700 (PDT) Received: from 80.38.191.89 by mx1.123-reg.co.uk; Wed, 28 Apr 2010 20:57:59 +0100 Date: Wed, 28 Apr 2010 20:57:59 +0100 From: dnsext-archive@ietf.org Subject: Prestige products for less To: Message-ID: <000d01cae704$b896daa0$6400a8c0@hepatitisbct> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Susan wanted me to buy her present from here http://watchperfect.ru From kmayo@amcat.co.uk Wed Apr 28 13:32:36 2010 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 CC37228C1C8 for ; Wed, 28 Apr 2010 13:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.192 X-Spam-Level: X-Spam-Status: No, score=-15.192 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_DSL=1.129, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FORGED_AMAZON=3, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, 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 89ISZiP8Xy5w for ; Wed, 28 Apr 2010 13:32:34 -0700 (PDT) Received: from 80-184-14-93.adsl.kems.net (80-184-14-133.adsl.kems.net [80.184.14.133]) by core3.amsl.com (Postfix) with SMTP id 0E5183A6A5C for ; Wed, 28 Apr 2010 13:30:46 -0700 (PDT) From: "Amazon.com Email Subscriptions" To: "dnsext-archive@ietf.org" Subject: Amazon.com Deal of the Day X-AMAZON-MAIL-RELAY-TYPE: subscription X-AMAZON-RTE-VERSION: 2.0 MIME-Version: 1.0 Content-Type: text/html Message-Id: <20100428203050.0E5183A6A5C@core3.amsl.com> Date: Wed, 28 Apr 2010 13:30:46 -0700 (PDT)
Please click here if the e-mail below is not displayed correctly.
amazon.com
Free Two-Day Shipping with  › Amazon Prime
Your Amazon.com Today's Deals See All Departments
PharmTomTom XL 340S 4.3-Inch Portable GPS Navigator Bundle with Case
$199.95 $89.99 (55% off)
3.68398268398268
The TomTom XL 340S Bundle includes the TomTom XL 340S device plus a Soft Quilted Carry Case. Switch on and go right out of the box. Spoken turn-by-turn instructions including street names will guide you to any address in the US, Canada and Mexico--including more than 7 million preloaded points of interest.
Explore Other Great Gold Box Deals
Save on Hitachi's Most Popular 18-Guage Brad Nailer
Just $19.29: Behringer High-Def DJ Headphones
Save $10 on "Alice in Wonderland Combo Pack"
Great GPS to Make Mom's Life Easier
Save on Hitachi's Most Popular 18-Guage Brad Nailer
$148.05 $69.17 (53% off)
 
 
Just $19.29: Behringer High-Def DJ Headphones
 
 
Save $10 on "Alice in Wonderland Combo Pack"
 
 
Great GPS to Make Mom's Life Easier
 
Save up to 40% on Our Bestselling Fitness Products
100 Albums for $5 Each
Diamond Month: Save up to 40% on Diamond and Crystal-Accented Watches
Sony Laptops Clearance
Save up to 40% on Our Bestselling Fitness Products
 
 
100 Albums for $5 Each
 
 
Diamond Month: Save up to 40% on Diamond and Crystal-Accented Watches
 
 
Sony Laptops Clearance
 


This message was sent to the following e-mail address: dnsext-archive@ietf.org

You're receiving this e-mail because you subscribed to Gold Box Deals. If you do not want any more e-mails of this kind, it's easy to unsubscribe.

Please note that product prices and availability are subject to change. Prices and availability were accurate at the time this newsletter was sent; however, they may differ from those you see when you visit Amazon.com. The List Price represents the full retail price listed on the product itself, suggested by the manufacturer or supplier, or estimated in accordance with standard industry practice. For items offered as a set, List Price may represent open-stock prices.

© 2010 Amazon.com. All rights reserved.
Amazon.com is a registered trademark of Amazon.com, Inc.
Amazon.com, 1200 12th Ave. S., Suite 1200, Seattle, WA 98144-2734.
Reference: 15122060
From owner-namedroppers@ops.ietf.org Wed Apr 28 13:55:24 2010 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 273243A6903; Wed, 28 Apr 2010 13:55:24 -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 elo2CukaaZHj; Wed, 28 Apr 2010 13:55:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 32ABA3A68AA; Wed, 28 Apr 2010 13:55:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O7E8L-000KT4-4Y for namedroppers-data0@psg.com; Wed, 28 Apr 2010 20:45:25 +0000 Received: from [131.111.8.132] (helo=ppsw-32.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O7E8I-000KSh-Qe for namedroppers@ops.ietf.org; Wed, 28 Apr 2010 20:45:22 +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-2.csi.cam.ac.uk ([131.111.8.54]:38202) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:cet1) id 1O7E8H-0008Q9-9p (Exim 4.70) for namedroppers@ops.ietf.org (return-path ); Wed, 28 Apr 2010 21:45:21 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1O7E8H-0008P7-14 (Exim 4.67) for namedroppers@ops.ietf.org (return-path ); Wed, 28 Apr 2010 21:45:21 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.2); 28 Apr 2010 21:45:20 +0100 Date: 28 Apr 2010 21:45:20 +0100 From: Chris Thompson To: namedroppers@ops.ietf.org Reply-To: cet1@cam.ac.uk Subject: [dnsext] Indicating BNAME support via DNSKEY algorithm values 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 am having a great deal of difficulty in seeing how this can possibly work in practice. Presumably the *-BNAME versions of the algorithms would only be enabling - "there *may* be BNAMEs" - so if a zone is signed with (say) both RSASHA256 and RSASHA256-BNAME, it can't actually have any BNAMEs. So in order to put a BNAME into your zone, you have to sign it *only* with algorithms which a substantial proportion of the validating community do not yet support. Why would anyone do that, when there are other methods (if less graceful) of achieving the same effect? Consider the root zone, post 2010-07-01. Would the relevant authorities really switch algorithms, and promulgate a new root trust anchor, just in order to have BNAMEs in the root zone? It seems extraordinarily unlikely! They would take the easier line of having duplicate delegations instead (i.e. offload the problem onto someone else). The *-NSEC3 algorithm values really only worked because DNSSEC was so little deployed at that stage, and those insisting on NSEC3 were such significant players in the deployment effort. -- 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 Apr 28 14:38:22 2010 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 189F83A6911; Wed, 28 Apr 2010 14:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.814 X-Spam-Level: X-Spam-Status: No, score=-0.814 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_50=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 it-wMlsAqvQR; Wed, 28 Apr 2010 14:38:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 16CFE3A68E9; Wed, 28 Apr 2010 14:38:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O7ErV-0003bF-Tr for namedroppers-data0@psg.com; Wed, 28 Apr 2010 21:32:05 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O7ErS-0003ar-7l for namedroppers@ops.ietf.org; Wed, 28 Apr 2010 21:32:02 +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 25209E9E3F; Wed, 28 Apr 2010 21:31:59 +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 o3SLVqpT057790; Thu, 29 Apr 2010 07:31:52 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201004282131.o3SLVqpT057790@drugs.dv.isc.org> To: cet1@cam.ac.uk Cc: namedroppers@ops.ietf.org From: Mark Andrews References: Subject: Re: [dnsext] Indicating BNAME support via DNSKEY algorithm values In-reply-to: Your message of "28 Apr 2010 21:45:20 +0100." Date: Thu, 29 Apr 2010 07:31:52 +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 , Chris Tho mpson writes: > I am having a great deal of difficulty in seeing how this can possibly > work in practice. > > Presumably the *-BNAME versions of the algorithms would only be enabling - > "there *may* be BNAMEs" - so if a zone is signed with (say) both RSASHA256 > and RSASHA256-BNAME, it can't actually have any BNAMEs. > > So in order to put a BNAME into your zone, you have to sign it *only* > with algorithms which a substantial proportion of the validating > community do not yet support. Why would anyone do that, when there > are other methods (if less graceful) of achieving the same effect? > > Consider the root zone, post 2010-07-01. Would the relevant authorities > really switch algorithms, and promulgate a new root trust anchor, just > in order to have BNAMEs in the root zone? It seems extraordinarily > unlikely! They would take the easier line of having duplicate delegations > instead (i.e. offload the problem onto someone else). > > The *-NSEC3 algorithm values really only worked because DNSSEC was so > little deployed at that stage, and those insisting on NSEC3 were such > significant players in the deployment effort. DNSSEC is still so little deployed and unfortunately will be for quite a while yet. Even if there was near ubiquitious deployment that is still not a reason to not develop and deploy BNAME capable server and validators. Some zones would not switch fast others would. The functionality is needed and not all use cases have alternate solutions. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From circumstancinglj46@bilbao.ru Thu Apr 29 19:19:53 2010 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 AF7FD3A699A; Thu, 29 Apr 2010 19:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.187 X-Spam-Level: X-Spam-Status: No, score=-13.187 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_BR=0.955, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, 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 9plmVYJXIq0M; Thu, 29 Apr 2010 19:19:52 -0700 (PDT) Received: from 20151004123.user.veloxzone.com.br (20151004123.user.veloxzone.com.br [201.51.4.123]) by core3.amsl.com (Postfix) with ESMTP id D40243A698F; Thu, 29 Apr 2010 19:19:50 -0700 (PDT) Received: from 201.51.4.123 by mx.monahoff.ru; Thu, 29 Apr 2010 23:19:34 -0300 Date: Thu, 29 Apr 2010 23:19:34 -0300 From: dnsext-archive@lists.ietf.org Subject: Click now for your surprise gift To: Message-ID: <000d01cae80b$936451b0$6400a8c0@circumstancinglj46> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Timepiece should last as long as ours http://summercollection.ru From dnsop-bounces@ietf.org Thu Apr 29 19:19:56 2010 Return-Path: X-Original-To: dnsext-archive@lists.ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4A623A698F for ; Thu, 29 Apr 2010 19:19:56 -0700 (PDT) Subject: The results of your email commands From: dnsop-bounces@ietf.org To: dnsext-archive@lists.ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1598532215==" Message-ID: Date: Thu, 29 Apr 2010 19:19:54 -0700 Precedence: bulk X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 List-Id: IETF DNSOP WG mailing list X-List-Administrivia: yes Sender: dnsop-bounces@ietf.org Errors-To: dnsop-bounces@ietf.org --===============1598532215== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. No commands were found in this message. To obtain instructions, send a message containing just the word "help". - Done. --===============1598532215== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: dnsop-request@core3.amsl.com Delivered-To: dnsop-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7FD3A699A; Thu, 29 Apr 2010 19:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.187 X-Spam-Level: X-Spam-Status: No, score=-13.187 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_BR=0.955, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, 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 9plmVYJXIq0M; Thu, 29 Apr 2010 19:19:52 -0700 (PDT) Received: from 20151004123.user.veloxzone.com.br (20151004123.user.veloxzone.com.br [201.51.4.123]) by core3.amsl.com (Postfix) with ESMTP id D40243A698F; Thu, 29 Apr 2010 19:19:50 -0700 (PDT) Received: from 201.51.4.123 by mx.monahoff.ru; Thu, 29 Apr 2010 23:19:34 -0300 Date: Thu, 29 Apr 2010 23:19:34 -0300 From: dnsext-archive@lists.ietf.org Subject: Click now for your surprise gift To: Message-ID: <000d01cae80b$936451b0$6400a8c0@circumstancinglj46> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Timepiece should last as long as ours http://summercollection.ru --===============1598532215==-- From circumstancinglj46@bilbao.ru Thu Apr 29 19:19:53 2010 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 AF7FD3A699A; Thu, 29 Apr 2010 19:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.187 X-Spam-Level: X-Spam-Status: No, score=-13.187 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_BR=0.955, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_PH_SURBL=1.787, 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 9plmVYJXIq0M; Thu, 29 Apr 2010 19:19:52 -0700 (PDT) Received: from 20151004123.user.veloxzone.com.br (20151004123.user.veloxzone.com.br [201.51.4.123]) by core3.amsl.com (Postfix) with ESMTP id D40243A698F; Thu, 29 Apr 2010 19:19:50 -0700 (PDT) Received: from 201.51.4.123 by mx.monahoff.ru; Thu, 29 Apr 2010 23:19:34 -0300 Date: Thu, 29 Apr 2010 23:19:34 -0300 From: dnsext-archive@lists.ietf.org Subject: Click now for your surprise gift To: Message-ID: <000d01cae80b$936451b0$6400a8c0@circumstancinglj46> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Timepiece should last as long as ours http://summercollection.ru From owner-namedroppers@ops.ietf.org Fri Apr 30 08:18:11 2010 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 A8FDF3A69A8; Fri, 30 Apr 2010 08:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.98 X-Spam-Level: X-Spam-Status: No, score=0.98 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_50=0.001, 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 3gNyUrvDxjlN; Fri, 30 Apr 2010 08:18:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 150983A69B9; Fri, 30 Apr 2010 08:17:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O7rmZ-000HMy-Aq for namedroppers-data0@psg.com; Fri, 30 Apr 2010 15:05:35 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O7rmV-000HMG-NB for namedroppers@ops.ietf.org; Fri, 30 Apr 2010 15:05:31 +0000 Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3UF5UBN011336 for ; Fri, 30 Apr 2010 11:05:30 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4BDAF1B8.5090207@ogud.com> Date: Fri, 30 Apr 2010 11:05:28 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: namedroppers Subject: [dnsext] WGLC-Summary: TCP-requirements Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 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 Working Group Last call has concluded. There was intense discussion by the WG about the document. The discussion on the mailing list indicates that the document has been thoroughly reviewed(20+), and among reviewers only one person voiced opposition to publication. Based on this the chairs declare a strong consensus to advance the document. The Editor has issued an updated version. If you sent in edits please take a look and comment if your concerns are not reflected in a satisfactory manner. If there are no comments on version 03 by May 7'th, we will declare it finished. http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dns-tcp-requirements/ While reviewing the many comments, the Chairs noticed certain asymmetry: the document talks about server connection management, but there is no text on how/when the client should close its TCP connections. Thus the Chairs want to ask the Working group, "Should the document be amended with a recommendation on client TCP connection termination?" If the answer is YES, then what should the recommendation be? The client MUST/SHOULD close TCP connection: - once the last outstanding question has been answered - a few seconds after the last answer arrived - never Pick one option, or rank the options. Note the value for "few seconds" is probably outside the scope of this document. Olafur & Andrew From owner-namedroppers@ops.ietf.org Fri Apr 30 10:26:46 2010 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 D212C3A69E1; Fri, 30 Apr 2010 10:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_05=-1.11] 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 TFBnsKydDeoO; Fri, 30 Apr 2010 10:26:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C006528C0CE; Fri, 30 Apr 2010 10:26:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O7tr3-000CCc-CN for namedroppers-data0@psg.com; Fri, 30 Apr 2010 17:18: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.71 (FreeBSD)) (envelope-from ) id 1O7tr0-000CCH-4x for namedroppers@ops.ietf.org; Fri, 30 Apr 2010 17:18:18 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 57067A3D56; Fri, 30 Apr 2010 17:18:16 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Olafur Gudmundsson cc: namedroppers Subject: Re: [dnsext] WGLC-Summary: TCP-requirements In-Reply-To: Your message of "Fri, 30 Apr 2010 11:05:28 -0400." <4BDAF1B8.5090207@ogud.com> References: <4BDAF1B8.5090207@ogud.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Fri, 30 Apr 2010 17:18:16 +0000 Message-ID: <98804.1272647896@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: Fri, 30 Apr 2010 11:05:28 -0400 > From: Olafur Gudmundsson > ... > Thus the Chairs want to ask the Working group, "Should the document be > amended with a recommendation on client TCP connection termination?" no. that would be new work, not a clarification. but... > If the answer is YES, then what should the recommendation be? > The client MUST/SHOULD close TCP connection: > - once the last outstanding question has been answered > - a few seconds after the last answer arrived > - never > > Pick one option, or rank the options. > Note the value for "few seconds" is probably outside the scope of this > document. since the server can close based on connection congestion or other need, the client should leave the connection open unless it has a reason to close it, such as exiting an application or context, or for reasons similar to the server's possible reasons (congestion). if streams of queries from a client to a server are able to reuse a tcp session it'll be great for everybody. i'd go further: if you have to open a tcp/53 session you should make all possible attempts to reuse it for as long as practical.