From dnsext-archive@ietf.org Sun Aug 1 03:29: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 5FAAB3A6984 for ; Sun, 1 Aug 2010 03:29:36 -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: 626 VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -6.069 X-Spam-Level: X-Spam-Status: No, score=-6.069 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, 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_DYNAMIC=1.144, 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_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_RECV_SPAM_DOMN0b=1.666, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1iMoEyCBoa9 for ; Sun, 1 Aug 2010 03:29:29 -0700 (PDT) Received: from 114-46-201-202.dynamic.hinet.net (114-46-201-202.dynamic.hinet.net [114.46.201.202]) by core3.amsl.com (Postfix) with SMTP id AEE343A6947 for ; Sun, 1 Aug 2010 03:29:28 -0700 (PDT) From: 626 VIAGRA ® Official Site To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org VIAGRA ® Official Site 20% 0FF MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100801102928.AEE343A6947@core3.amsl.com> Date: Sun, 1 Aug 2010 03:29:28 -0700 (PDT)
Click here.

Dear dnsext-archive@ietf.org
From dnsext-archive@ietf.org Sun Aug 1 06:35: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 C5A623A68C8 for ; Sun, 1 Aug 2010 06:35:29 -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: 454 VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -75.766 X-Spam-Level: X-Spam-Status: No, score=-75.766 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, HELO_EQ_MODEMCABLE=0.768, HELO_EQ_SHAWCABLE_2=1.45, HOST_EQ_MODEMCABLE=1.368, HOST_EQ_SHAWCAB=1.8, HS_INDEX_PARAM=0.001, HTML_IMAGE_ONLY_08=1.787, 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, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, SARE_UNSUB38D=0.642, SUBJECT_NEEDS_ENCODING=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 VgNJ5q5oMS6C for ; Sun, 1 Aug 2010 06:35:23 -0700 (PDT) Received: from S0106000874ec58b3.cg.shawcable.net (S0106000874ec58b3.cg.shawcable.net [174.0.113.132]) by core3.amsl.com (Postfix) with ESMTP id DB30D3A6895 for ; Sun, 1 Aug 2010 06:35:22 -0700 (PDT) From: 454 VIAGRA ® Official Site To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org VIAGRA ® Official Site 14% 0FF MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100801133522.DB30D3A6895@core3.amsl.com> Date: Sun, 1 Aug 2010 06:35:22 -0700 (PDT)
Please Click here!

For dnsext-archive!
From owner-namedroppers@ops.ietf.org Sun Aug 1 20:43: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 D8A283A67CF; Sun, 1 Aug 2010 20:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id um2HiD6xQnmJ; Sun, 1 Aug 2010 20:43:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC2133A6868; Sun, 1 Aug 2010 20:43:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oflno-000I1J-63 for namedroppers-data0@psg.com; Mon, 02 Aug 2010 03:35:00 +0000 Received: from [2001:4f8:fff7:1::5] (helo=mail1.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oflnj-000I11-VW for namedroppers@ops.ietf.org; Mon, 02 Aug 2010 03:34:55 +0000 Received: from cust-63-209-227-45.bos-dynamic.gis.net ([63.209.227.45] helo=[10.10.10.101]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OflnY-000Fnk-5J; Mon, 02 Aug 2010 03:34:54 +0000 Message-ID: <4C563D28.3060004@gis.net> Date: Sun, 01 Aug 2010 23:36:08 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org References: <20100731005454.GE26174@shinkuro.com> In-Reply-To: <20100731005454.GE26174@shinkuro.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 63.209.227.45 X-SA-Exim-Rcpt-To: ajs@shinkuro.com, namedroppers@ops.ietf.org X-SA-Exim-Mail-From: mayer@ntp.org Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 7/30/2010 8:54 PM, Andrew Sullivan wrote: > On Fri, Jul 30, 2010 at 12:16:48PM -0400, Phillip Hallam-Baker wrote: >> One issue missing from the charter is the question of use of DNSSEC in >> applications. > > It certainly is not missing from the charter in the sense that it is > our problem, and we need to tackle it. > > We are narrowly focussed on issues of the DNS protocol. Nothing about > how applications get to DNS results, &c, are our problem. Indeed, > they're not even the problem of the _area_ we are in: they're more > likely to be APP than INT. > I agree that it's not a protocol issue. I am however concerned that functions like getaddrinfo() provide no way to require that the resolve use DNSSEC to validate the answers returned or for that matter when the answers are returned the TTL for each answer is not given. You might not care about validating google.com but you definitely would about your bank's website. Danny > All of that said, I encourage people who think there are > application-level issues here to submit individual drafts. If there > were three or four such drafts that talked about application-level > interaction with DNSSEC, it might strike people who are inclined to > try to organize IETF work (i.e. all of us, right?!) that we could take > steps to co-ordinate that work (i.e. form a working group). Of > course, we already have some efforts in that direction. But the key > thing, under the current process rules, is to have a manifest > community of interested parties. Let's see those internet drafts! I > am sure that, though this sort of work be out of our charter, your > chairs will not object to the occasional announcement about such > drafts. When it gets heavy, we'll ask for a separate IETF mail list. > Alternatively, ask for one (perhaps M. Sury wull suggest that you > should use the one he is setting up.) > > Best, > > A > From owner-namedroppers@ops.ietf.org Mon Aug 2 01: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 94D1F3A6B01; Mon, 2 Aug 2010 01:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRhFLBRR9IBH; Mon, 2 Aug 2010 01:41:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C0A943A6B19; Mon, 2 Aug 2010 01:41:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OfqSt-000Ojj-LE for namedroppers-data0@psg.com; Mon, 02 Aug 2010 08:33:43 +0000 Received: from [74.125.82.48] (helo=mail-ww0-f48.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OfqSq-000Oiz-NL for namedroppers@ops.ietf.org; Mon, 02 Aug 2010 08:33:40 +0000 Received: by wwb18 with SMTP id 18so3995729wwb.17 for ; Mon, 02 Aug 2010 01:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:subject :to:cc:reply-to:mime-version:x-priority:content-type :content-transfer-encoding; bh=xaqQHV5KdhOS5uzORRVyg1kanCipsSj2wHdLqQcyDX8=; b=PZs7QmaVFpconPYPBBaeGUFZC7Zuh/Q8XPn2A0N5vORl7ld+0UZnApSzTk3ga+cY4C hQFpfpE3YhoiDBgpdB3EXHZpWmgO4vcZGrg1wLBfqK37jArgp2T5bUnFslwqqr3YTuUC UBuBVCAZ1LPwbIj9t+Cp1n02wqvnFIuE2P/D8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:subject:to:cc:reply-to:mime-version:x-priority :content-type:content-transfer-encoding; b=Qdwz2PvH/mLdvSD3b2i3XSNe2OFnvVRwbVD/hyjKC6v+GSdolCRgL0jz7L51RU3sHW 2USs0q7zfXNoT2WmQBp6LQCVE1ZpCqbXF3Zv9h4pqAlltz4AQauHXqmt/62Dqh3OCIoy IRxeeMEDfnCD4KikEEoC7yQDMtlYYvbx7Z/AM= Received: by 10.216.44.208 with SMTP id n58mr2403562web.73.1280738018334; Mon, 02 Aug 2010 01:33:38 -0700 (PDT) Received: from lhrnms-0122-fe.pr.nmsg.s.nokia.com (em1x-74.lhr.messaging.nokia.com [131.228.18.74]) by mx.google.com with ESMTPS id n17sm2618182weq.6.2010.08.02.01.33.36 (version=SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 01:33:37 -0700 (PDT) Message-ID: <4c5682e1.91e8d80a.4951.ffff808e@mx.google.com> Date: Mon, 02 Aug 2010 08:33:26 +0000 From: "taurus.wf@gmail.com" Subject: RE: [dnsext] Charter discussion - Use of DNSSEC in applications To: "Phillip Hallam-Baker" CC: "namedroppers" Reply-To: taurus.wf@gmail.com MIME-Version: 1.0 X-Priority: 3 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: Hi Baker, Personally agree with you much, there should be relevant discussion in = IETF about using DNSSEC in applications from end users, OS service enab= ler, and service providers perspectives. Even possible interaction from= DNS operator side. Because DNS/DNSSEC works as a backend application, so end users possibl= y has no idea to differentiate when or where DNSSEC is used. And support one new DNSAPP WG to do this, a bar BoF on IETF#79 is welco= me :) Regards, Wang Feng. Shawn =20 -----Original Message----- From: Phillip Hallam-Baker Sent: 31/07/2010 00:16:48 Subject: [dnsext] Charter discussion - Use of DNSSEC in applications One issue missing from the charter is the question of use of DNSSEC in applications. I think that this is an area that has to be looked at very carefully, even if the result is an RFC that says 'bad idea'. In particular, now that we can start to assume that there is going to be a DNSSEC capability we can think about moving network configuration data out into the DNS as a matter of course. I would like to see documents of the type 'how to easily and securely hook up a mail client to a server by means of DNSSEC secured RRs'. Part of that effort may be something that the application concerned has to deal with, but I see a need for additional DNS RRs and I would like the approach taken by email and the web and jabber to be relatively consistent. --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Mon Aug 2 10:54: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 906203A6BAA; Mon, 2 Aug 2010 10:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[AWL=-2.177, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_23=0.6, 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 84IqzEwkTWAQ; Mon, 2 Aug 2010 10:54:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 635DF3A6B9D; Mon, 2 Aug 2010 10:54:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ofz8U-0001E8-L4 for namedroppers-data0@psg.com; Mon, 02 Aug 2010 17:49:14 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ofz8R-0001Dc-NB for namedroppers@ops.ietf.org; Mon, 02 Aug 2010 17:49:11 +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 0F8E01ECB408; Mon, 2 Aug 2010 17:49:09 +0000 (UTC) Date: Mon, 2 Aug 2010 13:49:07 -0400 From: Andrew Sullivan To: "Jeffrey A. Williams" , namedroppers@ops.ietf.org Cc: dnsext-ads@tools.ietf.org Subject: [dnsext] Posting warning (was: ISC Offers Response Policy Zones For DNS, Really?) Message-ID: <20100802174906.GE30051@shinkuro.com> References: <4256467.1280611469698.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4256467.1280611469698.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.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: Dear Mr Williams: You copied a very long list of people when you posted your message to the namedroppers list. That is not allowed. We have repeatedly warned you in private about your behaviour on list. Specifically, there are three issues we have warned you about: 1. Widespread cross-posting or cc:ing of addresses other than the list. We discourage this because it causes the discussion to be unfocussed and to fragment into different threads in different contexts. If you cannot reach your audience on namedroppers alone, you should reconsider whether posting on namedroppers is the right thing to do. In your case, it seems that it rarely is. Don't do this any more. 2. Irrelevant discussions. Your remarks often seem to drag in peripheral issues unrelated to protocol issues. Specific discussion of particular zones is by and large not allowed on the list, and yet you seem to refer to such things regularly, often in the course of some sort of _ad hominem_ attack (which is a fallacy of relevance). Don't do this any more. 3. Frivolous or unnecessary posting. You sometimes add little more than "me too" to a discussion. The IETF does not work by voting, so unless you have substantive points to make, we've asked you to restrict your posting. In accordance with the procedures in RFC 3934, Section 2, we are hereby warning you publicly about your behaviour. If you repeat any of these behaviours, we will revoke your mailing list posting privileges for 30 days. Note that this message is copied to the relevant Area Directors. Best regards, Andrew & Olafur (WG co-chairs) On Sat, Jul 31, 2010 at 04:24:29PM -0500, Jeffrey A. Williams wrote: > All, > > Really?!! Seems to me that there has been on a on and off > again a basis this technology for 'cooperating good guys' to > do this for some time. [&c.] see for instance http://www.dnsstuff.com/ > and http://www.dnsstuff.com/domaindoctor as just one such example. > Unfortunately one of Paul Vixies > Domain Names doesn't seem to come up to snuff, see: > http://www.dnsstuff.com/tools/dnsreport?domain=vix.com&format=raw&loadresults=true&token=25e1e96ae86088a90d270c040ed18014 > Nor does another ISC.ORG entirely but is better, see: > http://www.dnsstuff.com/tools/dnsreport?domain=isc.org&format=raw&loadresults=true&token=25c1af6afc93828d0f876c0511ea901a > > The article > See:https://tech.slashdot.org/story/10/07/30/2031254/ISC-Offers-Response-Policy-Zones-For-DNS > > ISC has made the announcement that they have developed a technology > that will allow 'cooperating good guys' to http://www.circleid.com/posts/20100728_taking_back_the_dns/ > provide and consume reputation information about domains names. > The release of the technology, called Response Policy Zones > (DNS RPZ), was announced at DEFCON. Paul Vixie explains: 'Every > day lots of new names are added to the global DNS, and most of > them belong to scammers, spammers, e-criminals, and speculators. > The DNS industry has a lot of highly capable and competitive > registrars and registries who have made it possible to reserve > or create a new name in just seconds, and to create millions of > them per day. ... If your recursive DNS server has a policy > rule which forbids certain domain names from being resolvable, then they > will not resolve. And, it's possible to either create and maintain these > rules locally, or, import them from a reputation provider. ISC is not in > the business of identifying good domains or bad domains. We will not be > publishing any reputation data. But, we do publish technical information > about protocols and formats, and we do publish source code. So our role > in DNS RPZ will be to ftp://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt > define 'the spec' whereby cooperating producers and consumers can > exchange reputation data, and to publish a version of BIND that can > subscribe to such reputation data feeds. This means we will create a > market for DNS reputation but we will not participate directly > in that market. > > Regards, > > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 294k members/stakeholders and growing, strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln > > "Credit should go with the performance of duty and not with what is very > often the accident of glory" - Theodore Roosevelt > > "If the probability be called P; the injury, L; and the burden, B; liability > depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of > Information Network Eng. INEG. INC. > ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com > Phone: 214-244-4827 > -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From happy@sky.com Mon Aug 2 17:28: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 B09A03A67F4; Mon, 2 Aug 2010 17:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.96 X-Spam-Level: **** X-Spam-Status: No, score=4.96 tagged_above=-999 required=5 tests=[BAYES_60=1, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, MPART_ALT_DIFF_COUNT=1.11, MSGID_FROM_MTA_HEADER=0.803, RELAY_IS_203=0.994, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2chRMlm7KTg; Mon, 2 Aug 2010 17:28:36 -0700 (PDT) Received: from host75.truemail.co.th (host75.truemail.co.th [203.144.173.75]) by core3.amsl.com (Postfix) with ESMTP id 4300F3A679C; Mon, 2 Aug 2010 17:28:32 -0700 (PDT) Message-Id: <8qgu2t$3ep2os@irp3.truemail.co.th> X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvFqACIAV0w6CWzy/2dsb2JhbACBQ4FRkBYBiQCCdQwBBlJysnGWY3MEhBQ X-IronPort-AV: E=Sophos;i="4.55,306,1278262800"; d="scan'208,217";a="116165404" Received: from ppp-58-9-108-242.revip2.asianet.co.th (HELO PC-201007031654) ([58.9.108.242]) by irp3.truemail.co.th with ESMTP; 03 Aug 2010 07:28:53 +0700 MIME-Version: 1.0 From: =?utf-8?B?4Liq4Liz4Lir4Lij4Lix4Lia4LiE4Li44LiT?= Date: 3 Aug 2010 08:28:51 +0800 Subject: =?utf-8?B?4LiY4Li44Lij4LiB4Li04LiI4LiX4Li14LmI4LiW4Li54LiB4LiX4Li14LmI4LiW4Li54LiB4LmA4Lin4Lil4LiyLi4uLi4uLi4=?= Content-Type: multipart/alternative; boundary=--boundary_21_963d2cb7-5eb4-4b3d-9a2e-5ec78005128e To: undisclosed-recipients:; ----boundary_21_963d2cb7-5eb4-4b3d-9a2e-5ec78005128e Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zOm8gPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv ZmZpY2U6b2ZmaWNlIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNi4wMC42MDAwLjE3MDYzIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSBzdHls ZT0iQkFDS0dST1VORC1DT0xPUjogdHJhbnNwYXJlbnQiPg0KPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCI+PEI+PFNQQU4gbGFuZz1USCANCnN0eWxl PSJGT05ULVNJWkU6IDEycHQ7IENPTE9SOiBibGFjazsgTElORS1IRUlHSFQ6IDExNSU7IEZP TlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IG1zby10aGVtZWNvbG9yOiB0ZXh0 MSI+4Lit4Lii4LmI4Liy4LmD4LiK4LmJ4LmA4Lin4Lil4Liy4LiX4Lix4LmJ4LiH4LiK4Li1 4Lin4Li04LiV4LmA4Lie4Li34LmI4Lit4LiX4Liz4LiH4Liy4LiZ4Lir4Liy4LmA4LiH4Li0 4LiZPC9TUEFOPjwvQj48Qj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IENPTE9S OiBibGFjazsgTElORS1IRUlHSFQ6IDExNSU7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fu cy1zZXJpZic7IG1zby10aGVtZWNvbG9yOiB0ZXh0MSI+PEJSPjxTUEFOIA0KbGFuZz1USD7g uYHguJXguYjguIjguIfguYPguIrguYnguYDguKfguKXguLLguK3guLHguJnguJnguYnguK3g uKLguJnguLTguJTguJfguLPguIfguLLguJnguYDguJ7guLfguYjguK3guIjguLDguYPguIrg uYnguYDguIfguLTguJnguJfguLHguYnguIfguIrguLXguKfguLTguJU8L1NQQU4+PEJSPjxT UEFOIA0KbGFuZz1USD7guIHguLLguKPguKrguLnguI3guYDguKrguLXguKLguYDguIfguLTg uJnguYDguJvguYfguJnguIHguLLguKPguKrguLnguI3guYDguKrguLXguKLguYDguJ7guLXg uKLguIfguJrguLLguIfguKrguLTguYjguIfguJrguLLguIfguK3guKLguYjguLLguIfguILg uK3guIfguIrguLXguKfguLTguJU8L1NQQU4+PEJSPjxTUEFOIA0KbGFuZz1USD7guYHguJXg uYjguIHguLLguKPguKrguLnguI3guYDguKrguLXguKLguYLguK3guIHguLLguKrguYDguJvg uYfguJnguIHguLLguKPguKrguLnguI3guYDguKrguLXguKLguJfguLjguIHguKrguLTguYjg uIfguJfguLjguIHguK3guKLguYjguLLguIfguILguK3guIfguIrguLXguKfguLTguJU8L1NQ QU4+PEJSPjxTUEFOIA0KbGFuZz1USD7guYLguK3guIHguLLguKrguYHguKvguYjguIfguIHg uLLguKPguKrguKPguYnguLLguIfguKPguLLguKLguYTguJTguYkgPC9TUEFOPjUtNiA8U1BB TiBsYW5nPVRIPuC4q+C4peC4seC4gSDguJXguYjguK3guYDguJTguLfguK3guJkg4Lih4Liy 4LiW4Li24LiHIA0K4LmB4Lil4LmJ4Lin4LiE4LmI4LiwPC9TUEFOPjxCUj48U1BBTiBsYW5n PVRIPuC4reC4ouC5iOC4suC4oeC4reC4h+C4guC5ieC4suC4oeC5guC4reC4geC4suC4quC4 meC4teC5iSANCuC5geC4peC4sOC4reC4ouC5iOC4suC4m+C4peC5iOC4reC4ouC5g+C4q+C5 ieC4q+C4peC4uOC4lOC4peC4reC4ouC5hOC4myEhITwvU1BBTj48bzpwPjwvbzpwPjwvU1BB Tj48L0I+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20g MTBwdCI+PEI+PFNQQU4gbGFuZz1USCANCnN0eWxlPSJGT05ULVNJWkU6IDE4cHQ7IEJBQ0tH Uk9VTkQ6IGxpbWU7IENPTE9SOiBibGFjazsgTElORS1IRUlHSFQ6IDExNSU7IEZPTlQtRkFN SUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IG1zby10aGVtZWNvbG9yOiB0ZXh0MTsgbXNv LWhpZ2hsaWdodDogbGltZSI+4Liq4LiZ4LmD4LiIIA0KPC9TUEFOPjwvQj48Qj48U1BBTiBs YW5nPVRIIA0Kc3R5bGU9IkZPTlQtU0laRTogMThwdDsgQkFDS0dST1VORDogbGltZTsgTElO RS1IRUlHSFQ6IDExNSU7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IG1z by1oaWdobGlnaHQ6IGxpbWUiPjxBIA0KaHJlZj0iaHR0cDovL3d3dy4yNG9rZ3JvdXAuY29t L2dvb2RyaWNoIj7guITguKXguLTguIHguJfguLXguYjguJnguLXguYg8L0E+PC9TUEFOPjwv Qj48U1BBTiBsYW5nPVRIIA0Kc3R5bGU9IkZPTlQtU0laRTogMThwdDsgTElORS1IRUlHSFQ6 IDExNSU7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPjxvOnA+PC9vOnA+ PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDEwcHQiPjxCPjxTUEFOIGxhbmc9VEggDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBDT0xP UjogcmVkOyBMSU5FLUhFSUdIVDogMTE1JTsgRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5z LXNlcmlmJyI+4Lia4Lij4Li04Lip4Lix4LiX4Lih4Li14LiE4Lin4Liy4Lih4Lih4Lix4LmI 4LiZ4LiE4LiHPC9TUEFOPjwvQj48Qj48U1BBTiANCmxhbmc9VEggDQpzdHlsZT0iRk9OVC1T SVpFOiAxMnB0OyBMSU5FLUhFSUdIVDogMTE1JTsgRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdz YW5zLXNlcmlmJyI+IA0K4Lih4Li14Liq4LiE4LiaLuC4luC4ueC4geC4leC5ieC4reC4hyDg uYDguJvguYfguJnguYLguKPguIfguIfguLLguJnguJzguKXguLTguJXguYDguK3guIfguKHg uLXguJvguKPguLDguKrguJrguIHguLLguKPguJPguYw8L1NQQU4+PC9CPjxTUEFOIGxhbmc9 VEggDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBDT0xPUjogYmx1ZTsgTElORS1IRUlHSFQ6 IDExNSU7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPiANCjxTVFJPTkc+ PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPuC4nOC4 ueC5ieC4muC4o+C4tOC4q+C4suC4oyDguITguLjguJPguKPguLjguYjguIfguYLguKPguIjg uJnguYwgDQombmJzcDvguIjguLHguIHguKPguIrguLHguKLguKPguLjguYjguIfguYDguKPg uLfguK3guIcg4LmA4Lib4LmH4LiZ4Lic4Li54LmJ4LiX4Li14LmI4Lih4Li14Lib4Lij4Liw 4Liq4Lia4LiB4Liy4Lij4LiT4LmM4LmD4LiZ4LiB4Liy4Lij4Lia4Lij4Li04Lir4Liy4Lij 4LiY4Li44Lij4LiB4Li04LiI4Lih4Liy4Lir4Lil4Liy4Lii4Liq4Li04Lia4Lib4Li1IA0K 4LmA4Lib4LmH4LiZ4LiX4Li14LmI4Lib4Lij4Li24LiB4Lip4Liy4Lij4Lix4LiQ4Lih4LiZ 4LiV4Lij4Li14LmD4LiZ4Lij4Lix4LiQ4Lia4Liy4Lil4Lib4Lix4LiI4LiI4Li44Lia4Lix 4LiZ4LiW4Li24LiHIDwvU1BBTj48L1NUUk9ORz48L1NQQU4+PFNUUk9ORz48U1BBTiANCnN0 eWxlPSJGT05ULVNJWkU6IDEycHQ7IENPTE9SOiBibHVlOyBMSU5FLUhFSUdIVDogMTE1JTsg Rk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+MyANCjxTUEFOIGxhbmc9VEg+ 4LiB4Lij4Liw4LiX4Lij4Lin4LiHIOC4geC4o+C4sOC4l+C4o+C4p+C4h+C4hOC4oeC4meC4 suC4hOC4oSDguIHguKPguLDguJfguKPguKfguIfguYDguIHguKnguJXguKPguYHguKXguLDg uKrguKvguIHguKPguJPguYwgDQrguYHguKXguLDguIHguKPguLDguJfguKPguKfguIfguKrg uLLguJjguLLguKPguJPguKrguLjguII8L1NQQU4+PC9TUEFOPjwvU1RST05HPjxTUEFOIA0K c3R5bGU9IkZPTlQtU0laRTogMTJwdDsgTElORS1IRUlHSFQ6IDExNSU7IEZPTlQtRkFNSUxZ OiAnVGFob21hJywnc2Fucy1zZXJpZiciPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiPjxTVFJPTkc+PFNQ QU4gbGFuZz1USCANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IENPTE9SOiByZWQ7IExJTkUt SEVJR0hUOiAxMTUlOyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnIj7guKrg uLTguJnguITguYnguLLguJfguLXguYjguJbguLnguIHguITguLHguJTguKrguKPguKM8L1NQ QU4+PC9TVFJPTkc+PEI+PFNQQU4gDQpsYW5nPVRIIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJw dDsgTElORS1IRUlHSFQ6IDExNSU7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJp ZiciPiANCuC4quC4tOC4meC4hOC5ieC4suC4oeC4teC4hOC4uOC4k+C4oOC4suC4nuC5hOC4 lOC5ieC4o+C4seC4muC4reC4oi7guJfguLjguIHguJXguLHguKfguIHguYjguK3guJnguIjg uLPguKvguJnguYjguLLguKI8L1NQQU4+PC9CPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTog MTJwdDsgTElORS1IRUlHSFQ6IDExNSU7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1z ZXJpZiciPjxCUj48U1RST05HPjxTUEFOIA0KbGFuZz1USCANCnN0eWxlPSJDT0xPUjogYmx1 ZTsgRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+4LmB4Lil4Liw4LiX4Liz 4LiB4Liy4Lij4Lin4Li04LiI4Lix4Lii4Lih4Liy4LmB4Lil4LmJ4Lin4Lin4LmI4Liy4LmA 4Lib4LmH4LiZ4Liq4Li04LiZ4LiE4LmJ4Liy4LiX4Li14LmI4Liq4LiZ4LmD4LiI4LiC4Lit 4LiH4Lic4Li54LmJ4Lia4Lij4Li04LmC4Lig4LiEIA0K4LiI4Li24LiH4LiX4Liz4LmD4Lir 4LmJ4Liq4Lih4Liy4LiK4Li04LiB4Liq4Liy4Lih4Liy4Lij4LiW4LiX4Liz4LiB4Liy4Lij 4LiV4Lil4Liy4LiU4LmE4LiU4LmJ4LiH4LmI4Liy4LiiIOC5gOC4m+C5h+C4meC4quC4tOC4 meC4hOC5ieC4suC4l+C4teC5iOC4oeC4teC4q+C4peC4suC4geC4q+C4peC4suC4ouC4geC4 peC4uOC5iOC4oSANCuC4o+C4suC4hOC4suC5hOC4oeC5iOC4quC4ueC4h+C5gOC4geC4tOC4 meC5hOC4myDguKXguLnguIHguITguYnguLLguKrguLLguKHguLLguKPguJbguIvguLfguYng uK3guIvguYnguLPguYTguJTguYnguK3guKLguYjguLLguIfguJXguYjguK3guYDguJnguLfg uYjguK3guIfguYHguKXguLDguJfguLLguIfguJrguKPguLTguKnguLHguJfguK8gDQrguKHg uLXguYLguKPguIfguIfguLLguJnguKrguLLguKHguLLguKPguJbguJzguKXguLTguJXguKrg uLTguJnguITguYnguLLguYTguJTguYnguYDguK3guIcgDQrguIjguLbguIfguJfguLPguYPg uKvguYnguKrguLLguKHguLLguKPguJbguJzguKXguLTguJXguKDguLHguJPguJHguYzguYTg uJTguYnguK3guKLguYjguLLguIfguYDguJ7guLXguKLguIfguJ7guK3guIHguLHguJrguITg uKfguLLguKHguJXguYnguK3guIfguIHguLLguKPguILguK3guIfguJfguLXguKHguIfguLLg uJnguKrguKHguLLguIrguLTguIE8L1NQQU4+PC9TVFJPTkc+PG86cD48L286cD48L1NQQU4+ PC9QPg0KPFAgc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnkiPjxTVFJPTkc+PFNQQU4gbGFu Zz1USCANCnN0eWxlPSJDT0xPUjogcmVkOyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMt c2VyaWYnIj7guYHguJzguJnguIHguLLguKPguJXguKXguLLguJTguILguK3guIfguJrguKPg uLTguKnguLHguJc8L1NQQU4+PC9TVFJPTkc+PFNUUk9ORz48U1BBTiANCmxhbmc9VEggc3R5 bGU9IkNPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnIj4g DQo8L1NQQU4+PC9TVFJPTkc+PFNUUk9ORz48U1BBTiBsYW5nPVRIIA0Kc3R5bGU9IkZPTlQt RkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPuC5gOC4m+C5h+C4meC5geC4nOC4meC4 l+C4teC5iOC4oeC4teC4hOC4p+C4suC4oeC4ouC4uOC4leC4tOC4mOC4o+C4o+C4oTxTUEFO IA0Kc3R5bGU9IkNPTE9SOiBibHVlIj4g4LmA4LiZ4LmJ4LiZ4LiB4Liy4Lij4Liq4Lij4LmJ 4Liy4LiH4LmA4LiE4Lij4Li34Lit4LiC4LmI4Liy4Lii4Lic4Li54LmJ4Lia4Lij4Li04LmC 4Lig4LiE4Lit4Lii4LmI4Liy4LiH4LmB4LiX4LmJ4LiI4Lij4Li04LiHIOC4oeC4teC4geC4 suC4o+C4o+C4seC4muC4o+C4suC4ouC5hOC4lOC5iSANCjwvU1BBTj48L1NQQU4+PC9TVFJP Tkc+PFNUUk9ORz48U1BBTiANCnN0eWxlPSJDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6ICdU YWhvbWEnLCdzYW5zLXNlcmlmJyI+NiA8U1BBTiANCmxhbmc9VEg+4LiK4LmI4Lit4LiH4LiX 4Liy4LiHPC9TUEFOPjwvU1BBTj48L1NUUk9ORz48U1RST05HPjxTUEFOIGxhbmc9VEggDQpz dHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+4Lij4Lix4Lia4LiE 4LmI4Liy4LmB4LiZ4Liw4LiZ4Liz4Liq4Li54LiH4Liq4Li44LiUIA0KPC9TUEFOPjwvU1RS T05HPjxTVFJPTkc+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5z LXNlcmlmJyI+MTEwJTxTUEFOIHN0eWxlPSJDT0xPUjogYmx1ZSI+IDxTUEFOIA0KbGFuZz1U SD7guIjguLLguIEgPC9TUEFOPjUgPFNQQU4gbGFuZz1USD7guIrguLHguYnguJnguKXguLbg uIEg4Lij4Lix4Lia4LiE4LmI4Liy4Lia4Lij4Li04Lir4Liy4Lij4Liq4Li54LiH4Liq4Li4 4LiU4LiW4Li24LiH4LmA4LiB4Li34Lit4LiaIDwvU1BBTj44IA0KPFNQQU4gbGFuZz1USD7g uYHguKrguJnguJrguLLguJcg4LmB4Lil4Liw4Lij4Lix4Lia4LmC4Lia4LiZ4Lix4Liq4LmB 4Lih4LiX4LiK4Li04LmI4LiH4Lih4Liy4LiB4LiW4Li24LiHIDwvU1BBTj4yNDAlIDxTUEFO IGxhbmc9VEg+4LiI4Liy4LiBIA0KPC9TUEFOPjQgPFNQQU4gbGFuZz1USD7guIrguLHguYng uJnguKXguLbguIEgDQrguIfguYjguLLguKLguJXguYjguK3guIHguLLguKPguJvguKPguLDg uKrguJrguITguKfguLLguKHguKrguLPguYDguKPguYfguIjguYDguJvguYfguJnguK3guKLg uYjguLLguIfguKLguLTguYjguIc8L1NQQU4+PC9TUEFOPjwvU1BBTj48L1NUUk9ORz48L1A+ DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0Ij48Qj48 U1BBTiBsYW5nPVRIIA0Kc3R5bGU9IkZPTlQtU0laRTogMThwdDsgQkFDS0dST1VORDogbGlt ZTsgQ09MT1I6IGJsYWNrOyBMSU5FLUhFSUdIVDogMTE1JTsgRk9OVC1GQU1JTFk6ICdUYWhv bWEnLCdzYW5zLXNlcmlmJzsgbXNvLXRoZW1lY29sb3I6IHRleHQxOyBtc28taGlnaGxpZ2h0 OiBsaW1lIj7guKrguJnguYPguIggDQo8L1NQQU4+PC9CPjxCPjxTUEFOIGxhbmc9VEggDQpz dHlsZT0iRk9OVC1TSVpFOiAxOHB0OyBCQUNLR1JPVU5EOiBsaW1lOyBMSU5FLUhFSUdIVDog MTE1JTsgRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgbXNvLWhpZ2hsaWdo dDogbGltZSI+PEEgDQpocmVmPSJodHRwOi8vd3d3LjI0b2tncm91cC5jb20vZ29vZHJpY2gi PuC4hOC4peC4tOC4geC4l+C4teC5iOC4meC4teC5iDwvQT48L1NQQU4+PC9CPjxTUEFOIGxh bmc9VEggDQpzdHlsZT0iRk9OVC1TSVpFOiAxOHB0OyBMSU5FLUhFSUdIVDogMTE1JTsgRk9O VC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+PG86cD48L286cD48L1NQQU4+PC9Q Pg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCI+PFNQ QU4gbGFuZz1USCANCnN0eWxlPSJGT05ULVNJWkU6IDE0cHQ7IExJTkUtSEVJR0hUOiAxMTUl OyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnIj7guYDguKPguLLguJ7guKPg uYnguK3guKHguJfguLXguYjguIjguLDguJXguYnguK3guJnguKPguLHguJrguYHguKXguLDg uIrguYjguKfguKLguYDguKvguKXguLfguK3guJzguLnguYnguJfguLXguYjguK3guKLguLLg uIHguYDguJvguKXguLXguYjguKLguJnguYHguJvguKXguIfguIrguLXguKfguLTguJXguJXg uLHguKfguYDguK3guIfguYPguKvguYnguJTguLXguILguLbguYnguJk8L1NQQU4+PFNQQU4g DQpzdHlsZT0iRk9OVC1TSVpFOiAxNHB0OyBMSU5FLUhFSUdIVDogMTE1JTsgRk9OVC1GQU1J TFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+PEJSPjxTUEFOIA0KbGFuZz1USD7guIjguIfg uYPguIrguYnguYDguKPguLLguYDguJvguYfguJnguYDguITguKPguLfguYjguK3guIfguKHg uLfguK3guYHguKXguLDguYDguILguYfguKHguJfguLTguKjguJnguLPguJfguLLguIfguITg uLjguJMgDQrguYTguJvguKrguLnguYjguIjguLjguJTguKHguLjguYjguIfguKvguKHguLLg uKLguILguK3guIfguITguLjguJM8L1NQQU4+PEJSPjxTUEFOIGxhbmc9VEg+4LiZ4Lix4LmI 4LiZ4LiE4Li34Lit4LiE4Lin4Liy4Lih4Liq4Liz4LmA4Lij4LmH4LiIPC9TUEFOPjxCUiAN CnN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPjxCUiANCnN0eWxl PSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPjxvOnA+PC9vOnA+PC9TUEFO PjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQi PjxCPjxTUEFOIGxhbmc9VEggDQpzdHlsZT0iRk9OVC1TSVpFOiAxOHB0OyBCQUNLR1JPVU5E OiBsaW1lOyBDT0xPUjogYmxhY2s7IExJTkUtSEVJR0hUOiAxMTUlOyBGT05ULUZBTUlMWTog J1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBtc28tdGhlbWVjb2xvcjogdGV4dDE7IG1zby1oaWdo bGlnaHQ6IGxpbWUiPuC4quC4meC5g+C4iCANCjwvU1BBTj48L0I+PEI+PFNQQU4gbGFuZz1U SCANCnN0eWxlPSJGT05ULVNJWkU6IDE4cHQ7IEJBQ0tHUk9VTkQ6IGxpbWU7IExJTkUtSEVJ R0hUOiAxMTUlOyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBtc28taGln aGxpZ2h0OiBsaW1lIj48QSANCmhyZWY9Imh0dHA6Ly93d3cuMjRva2dyb3VwLmNvbS9nb29k cmljaCI+4LiE4Lil4Li04LiB4LiX4Li14LmI4LiZ4Li14LmIPC9BPjwvU1BBTj48L0I+PFNQ QU4gbGFuZz1USCANCnN0eWxlPSJGT05ULVNJWkU6IDE4cHQ7IExJTkUtSEVJR0hUOiAxMTUl OyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnIj48bzpwPjwvbzpwPjwvU1BB Tj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0 Ij48Qj48U1BBTiBsYW5nPVRIIA0Kc3R5bGU9IkZPTlQtU0laRTogMTRwdDsgQ09MT1I6IHJl ZDsgTElORS1IRUlHSFQ6IDExNSU7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJp ZiciPi4uLi4uLi4uLi4uLi4uLuC4guC4reC4reC4oOC4seC4ouC4reC4ouC5iOC4suC4h+C4 quC4ueC4h+C4q+C4suC4geC5gOC4oeC4peC4peC5jOC4meC4teC5ieC4o+C4muC4geC4p+C4 meC4l+C5iOC4suC4mTwvU1BBTj48L0I+PEI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAx NHB0OyBDT0xPUjogcmVkOyBMSU5FLUhFSUdIVDogMTE1JTsgRk9OVC1GQU1JTFk6ICdUYWhv bWEnLCdzYW5zLXNlcmlmJyI+4oCm4oCm4oCm4oCm4oCm4oCmPG86cD48L286cD48L1NQQU4+ PC9CPjwvUD4NCjxQPiZuYnNwOzwvUD4NClR1ZSwgMDMgQXVnIDIwMTAgMDg6MjU6MTMgR01U DQo8L0JPRFk+PC9IVE1MPg0K ----boundary_21_963d2cb7-5eb4-4b3d-9a2e-5ec78005128e Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zOm8gPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv ZmZpY2U6b2ZmaWNlIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNi4wMC42MDAwLjE3MDYzIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSBzdHls ZT0iQkFDS0dST1VORC1DT0xPUjogdHJhbnNwYXJlbnQiPg0KPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCI+PEI+PFNQQU4gbGFuZz1USCANCnN0eWxl PSJGT05ULVNJWkU6IDEycHQ7IENPTE9SOiBibGFjazsgTElORS1IRUlHSFQ6IDExNSU7IEZP TlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IG1zby10aGVtZWNvbG9yOiB0ZXh0 MSI+4Lit4Lii4LmI4Liy4LmD4LiK4LmJ4LmA4Lin4Lil4Liy4LiX4Lix4LmJ4LiH4LiK4Li1 4Lin4Li04LiV4LmA4Lie4Li34LmI4Lit4LiX4Liz4LiH4Liy4LiZ4Lir4Liy4LmA4LiH4Li0 4LiZPC9TUEFOPjwvQj48Qj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IENPTE9S OiBibGFjazsgTElORS1IRUlHSFQ6IDExNSU7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fu cy1zZXJpZic7IG1zby10aGVtZWNvbG9yOiB0ZXh0MSI+PEJSPjxTUEFOIA0KbGFuZz1USD7g uYHguJXguYjguIjguIfguYPguIrguYnguYDguKfguKXguLLguK3guLHguJnguJnguYnguK3g uKLguJnguLTguJTguJfguLPguIfguLLguJnguYDguJ7guLfguYjguK3guIjguLDguYPguIrg uYnguYDguIfguLTguJnguJfguLHguYnguIfguIrguLXguKfguLTguJU8L1NQQU4+PEJSPjxT UEFOIA0KbGFuZz1USD7guIHguLLguKPguKrguLnguI3guYDguKrguLXguKLguYDguIfguLTg uJnguYDguJvguYfguJnguIHguLLguKPguKrguLnguI3guYDguKrguLXguKLguYDguJ7guLXg uKLguIfguJrguLLguIfguKrguLTguYjguIfguJrguLLguIfguK3guKLguYjguLLguIfguILg uK3guIfguIrguLXguKfguLTguJU8L1NQQU4+PEJSPjxTUEFOIA0KbGFuZz1USD7guYHguJXg uYjguIHguLLguKPguKrguLnguI3guYDguKrguLXguKLguYLguK3guIHguLLguKrguYDguJvg uYfguJnguIHguLLguKPguKrguLnguI3guYDguKrguLXguKLguJfguLjguIHguKrguLTguYjg uIfguJfguLjguIHguK3guKLguYjguLLguIfguILguK3guIfguIrguLXguKfguLTguJU8L1NQ QU4+PEJSPjxTUEFOIA0KbGFuZz1USD7guYLguK3guIHguLLguKrguYHguKvguYjguIfguIHg uLLguKPguKrguKPguYnguLLguIfguKPguLLguKLguYTguJTguYkgPC9TUEFOPjUtNiA8U1BB TiBsYW5nPVRIPuC4q+C4peC4seC4gSDguJXguYjguK3guYDguJTguLfguK3guJkg4Lih4Liy 4LiW4Li24LiHIA0K4LmB4Lil4LmJ4Lin4LiE4LmI4LiwPC9TUEFOPjxCUj48U1BBTiBsYW5n PVRIPuC4reC4ouC5iOC4suC4oeC4reC4h+C4guC5ieC4suC4oeC5guC4reC4geC4suC4quC4 meC4teC5iSANCuC5geC4peC4sOC4reC4ouC5iOC4suC4m+C4peC5iOC4reC4ouC5g+C4q+C5 ieC4q+C4peC4uOC4lOC4peC4reC4ouC5hOC4myEhITwvU1BBTj48bzpwPjwvbzpwPjwvU1BB Tj48L0I+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20g MTBwdCI+PEI+PFNQQU4gbGFuZz1USCANCnN0eWxlPSJGT05ULVNJWkU6IDE4cHQ7IEJBQ0tH Uk9VTkQ6IGxpbWU7IENPTE9SOiBibGFjazsgTElORS1IRUlHSFQ6IDExNSU7IEZPTlQtRkFN SUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IG1zby10aGVtZWNvbG9yOiB0ZXh0MTsgbXNv LWhpZ2hsaWdodDogbGltZSI+4Liq4LiZ4LmD4LiIIA0KPC9TUEFOPjwvQj48Qj48U1BBTiBs YW5nPVRIIA0Kc3R5bGU9IkZPTlQtU0laRTogMThwdDsgQkFDS0dST1VORDogbGltZTsgTElO RS1IRUlHSFQ6IDExNSU7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IG1z by1oaWdobGlnaHQ6IGxpbWUiPjxBIA0KaHJlZj0iaHR0cDovL3d3dy4yNG9rZ3JvdXAuY29t L2dvb2RyaWNoIj7guITguKXguLTguIHguJfguLXguYjguJnguLXguYg8L0E+PC9TUEFOPjwv Qj48U1BBTiBsYW5nPVRIIA0Kc3R5bGU9IkZPTlQtU0laRTogMThwdDsgTElORS1IRUlHSFQ6 IDExNSU7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPjxvOnA+PC9vOnA+ PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDEwcHQiPjxCPjxTUEFOIGxhbmc9VEggDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBDT0xP UjogcmVkOyBMSU5FLUhFSUdIVDogMTE1JTsgRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5z LXNlcmlmJyI+4Lia4Lij4Li04Lip4Lix4LiX4Lih4Li14LiE4Lin4Liy4Lih4Lih4Lix4LmI 4LiZ4LiE4LiHPC9TUEFOPjwvQj48Qj48U1BBTiANCmxhbmc9VEggDQpzdHlsZT0iRk9OVC1T SVpFOiAxMnB0OyBMSU5FLUhFSUdIVDogMTE1JTsgRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdz YW5zLXNlcmlmJyI+IA0K4Lih4Li14Liq4LiE4LiaLuC4luC4ueC4geC4leC5ieC4reC4hyDg uYDguJvguYfguJnguYLguKPguIfguIfguLLguJnguJzguKXguLTguJXguYDguK3guIfguKHg uLXguJvguKPguLDguKrguJrguIHguLLguKPguJPguYw8L1NQQU4+PC9CPjxTUEFOIGxhbmc9 VEggDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBDT0xPUjogYmx1ZTsgTElORS1IRUlHSFQ6 IDExNSU7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPiANCjxTVFJPTkc+ PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPuC4nOC4 ueC5ieC4muC4o+C4tOC4q+C4suC4oyDguITguLjguJPguKPguLjguYjguIfguYLguKPguIjg uJnguYwgDQombmJzcDvguIjguLHguIHguKPguIrguLHguKLguKPguLjguYjguIfguYDguKPg uLfguK3guIcg4LmA4Lib4LmH4LiZ4Lic4Li54LmJ4LiX4Li14LmI4Lih4Li14Lib4Lij4Liw 4Liq4Lia4LiB4Liy4Lij4LiT4LmM4LmD4LiZ4LiB4Liy4Lij4Lia4Lij4Li04Lir4Liy4Lij 4LiY4Li44Lij4LiB4Li04LiI4Lih4Liy4Lir4Lil4Liy4Lii4Liq4Li04Lia4Lib4Li1IA0K 4LmA4Lib4LmH4LiZ4LiX4Li14LmI4Lib4Lij4Li24LiB4Lip4Liy4Lij4Lix4LiQ4Lih4LiZ 4LiV4Lij4Li14LmD4LiZ4Lij4Lix4LiQ4Lia4Liy4Lil4Lib4Lix4LiI4LiI4Li44Lia4Lix 4LiZ4LiW4Li24LiHIDwvU1BBTj48L1NUUk9ORz48L1NQQU4+PFNUUk9ORz48U1BBTiANCnN0 eWxlPSJGT05ULVNJWkU6IDEycHQ7IENPTE9SOiBibHVlOyBMSU5FLUhFSUdIVDogMTE1JTsg Rk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+MyANCjxTUEFOIGxhbmc9VEg+ 4LiB4Lij4Liw4LiX4Lij4Lin4LiHIOC4geC4o+C4sOC4l+C4o+C4p+C4h+C4hOC4oeC4meC4 suC4hOC4oSDguIHguKPguLDguJfguKPguKfguIfguYDguIHguKnguJXguKPguYHguKXguLDg uKrguKvguIHguKPguJPguYwgDQrguYHguKXguLDguIHguKPguLDguJfguKPguKfguIfguKrg uLLguJjguLLguKPguJPguKrguLjguII8L1NQQU4+PC9TUEFOPjwvU1RST05HPjxTUEFOIA0K c3R5bGU9IkZPTlQtU0laRTogMTJwdDsgTElORS1IRUlHSFQ6IDExNSU7IEZPTlQtRkFNSUxZ OiAnVGFob21hJywnc2Fucy1zZXJpZiciPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQiPjxTVFJPTkc+PFNQ QU4gbGFuZz1USCANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IENPTE9SOiByZWQ7IExJTkUt SEVJR0hUOiAxMTUlOyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnIj7guKrg uLTguJnguITguYnguLLguJfguLXguYjguJbguLnguIHguITguLHguJTguKrguKPguKM8L1NQ QU4+PC9TVFJPTkc+PEI+PFNQQU4gDQpsYW5nPVRIIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJw dDsgTElORS1IRUlHSFQ6IDExNSU7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJp ZiciPiANCuC4quC4tOC4meC4hOC5ieC4suC4oeC4teC4hOC4uOC4k+C4oOC4suC4nuC5hOC4 lOC5ieC4o+C4seC4muC4reC4oi7guJfguLjguIHguJXguLHguKfguIHguYjguK3guJnguIjg uLPguKvguJnguYjguLLguKI8L1NQQU4+PC9CPjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTog MTJwdDsgTElORS1IRUlHSFQ6IDExNSU7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1z ZXJpZiciPjxCUj48U1RST05HPjxTUEFOIA0KbGFuZz1USCANCnN0eWxlPSJDT0xPUjogYmx1 ZTsgRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+4LmB4Lil4Liw4LiX4Liz 4LiB4Liy4Lij4Lin4Li04LiI4Lix4Lii4Lih4Liy4LmB4Lil4LmJ4Lin4Lin4LmI4Liy4LmA 4Lib4LmH4LiZ4Liq4Li04LiZ4LiE4LmJ4Liy4LiX4Li14LmI4Liq4LiZ4LmD4LiI4LiC4Lit 4LiH4Lic4Li54LmJ4Lia4Lij4Li04LmC4Lig4LiEIA0K4LiI4Li24LiH4LiX4Liz4LmD4Lir 4LmJ4Liq4Lih4Liy4LiK4Li04LiB4Liq4Liy4Lih4Liy4Lij4LiW4LiX4Liz4LiB4Liy4Lij 4LiV4Lil4Liy4LiU4LmE4LiU4LmJ4LiH4LmI4Liy4LiiIOC5gOC4m+C5h+C4meC4quC4tOC4 meC4hOC5ieC4suC4l+C4teC5iOC4oeC4teC4q+C4peC4suC4geC4q+C4peC4suC4ouC4geC4 peC4uOC5iOC4oSANCuC4o+C4suC4hOC4suC5hOC4oeC5iOC4quC4ueC4h+C5gOC4geC4tOC4 meC5hOC4myDguKXguLnguIHguITguYnguLLguKrguLLguKHguLLguKPguJbguIvguLfguYng uK3guIvguYnguLPguYTguJTguYnguK3guKLguYjguLLguIfguJXguYjguK3guYDguJnguLfg uYjguK3guIfguYHguKXguLDguJfguLLguIfguJrguKPguLTguKnguLHguJfguK8gDQrguKHg uLXguYLguKPguIfguIfguLLguJnguKrguLLguKHguLLguKPguJbguJzguKXguLTguJXguKrg uLTguJnguITguYnguLLguYTguJTguYnguYDguK3guIcgDQrguIjguLbguIfguJfguLPguYPg uKvguYnguKrguLLguKHguLLguKPguJbguJzguKXguLTguJXguKDguLHguJPguJHguYzguYTg uJTguYnguK3guKLguYjguLLguIfguYDguJ7guLXguKLguIfguJ7guK3guIHguLHguJrguITg uKfguLLguKHguJXguYnguK3guIfguIHguLLguKPguILguK3guIfguJfguLXguKHguIfguLLg uJnguKrguKHguLLguIrguLTguIE8L1NQQU4+PC9TVFJPTkc+PG86cD48L286cD48L1NQQU4+ PC9QPg0KPFAgc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnkiPjxTVFJPTkc+PFNQQU4gbGFu Zz1USCANCnN0eWxlPSJDT0xPUjogcmVkOyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMt c2VyaWYnIj7guYHguJzguJnguIHguLLguKPguJXguKXguLLguJTguILguK3guIfguJrguKPg uLTguKnguLHguJc8L1NQQU4+PC9TVFJPTkc+PFNUUk9ORz48U1BBTiANCmxhbmc9VEggc3R5 bGU9IkNPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnIj4g DQo8L1NQQU4+PC9TVFJPTkc+PFNUUk9ORz48U1BBTiBsYW5nPVRIIA0Kc3R5bGU9IkZPTlQt RkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZiciPuC5gOC4m+C5h+C4meC5geC4nOC4meC4 l+C4teC5iOC4oeC4teC4hOC4p+C4suC4oeC4ouC4uOC4leC4tOC4mOC4o+C4o+C4oTxTUEFO IA0Kc3R5bGU9IkNPTE9SOiBibHVlIj4g4LmA4LiZ4LmJ4LiZ4LiB4Liy4Lij4Liq4Lij4LmJ 4Liy4LiH4LmA4LiE4Lij4Li34Lit4LiC4LmI4Liy4Lii4Lic4Li54LmJ4Lia4Lij4Li04LmC 4Lig4LiE4Lit4Lii4LmI4Liy4LiH4LmB4LiX4LmJ4LiI4Lij4Li04LiHIOC4oeC4teC4geC4 suC4o+C4o+C4seC4muC4o+C4suC4ouC5hOC4lOC5iSANCjwvU1BBTj48L1NQQU4+PC9TVFJP Tkc+PFNUUk9ORz48U1BBTiANCnN0eWxlPSJDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6ICdU YWhvbWEnLCdzYW5zLXNlcmlmJyI+NiA8U1BBTiANCmxhbmc9VEg+4LiK4LmI4Lit4LiH4LiX 4Liy4LiHPC9TUEFOPjwvU1BBTj48L1NUUk9ORz48U1RST05HPjxTUEFOIGxhbmc9VEggDQpz dHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+4Lij4Lix4Lia4LiE 4LmI4Liy4LmB4LiZ4Liw4LiZ4Liz4Liq4Li54LiH4Liq4Li44LiUIA0KPC9TUEFOPjwvU1RS T05HPjxTVFJPTkc+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5z LXNlcmlmJyI+MTEwJTxTUEFOIHN0eWxlPSJDT0xPUjogYmx1ZSI+IDxTUEFOIA0KbGFuZz1U SD7guIjguLLguIEgPC9TUEFOPjUgPFNQQU4gbGFuZz1USD7guIrguLHguYnguJnguKXguLbg uIEg4Lij4Lix4Lia4LiE4LmI4Liy4Lia4Lij4Li04Lir4Liy4Lij4Liq4Li54LiH4Liq4Li4 4LiU4LiW4Li24LiH4LmA4LiB4Li34Lit4LiaIDwvU1BBTj44IA0KPFNQQU4gbGFuZz1USD7g uYHguKrguJnguJrguLLguJcg4LmB4Lil4Liw4Lij4Lix4Lia4LmC4Lia4LiZ4Lix4Liq4LmB 4Lih4LiX4LiK4Li04LmI4LiH4Lih4Liy4LiB4LiW4Li24LiHIDwvU1BBTj4yNDAlIDxTUEFO IGxhbmc9VEg+4LiI4Liy4LiBIA0KPC9TUEFOPjQgPFNQQU4gbGFuZz1USD7guIrguLHguYng uJnguKXguLbguIEgDQrguIfguYjguLLguKLguJXguYjguK3guIHguLLguKPguJvguKPguLDg uKrguJrguITguKfguLLguKHguKrguLPguYDguKPguYfguIjguYDguJvguYfguJnguK3guKLg uYjguLLguIfguKLguLTguYjguIc8L1NQQU4+PC9TUEFOPjwvU1BBTj48L1NUUk9ORz48L1A+ DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0Ij48Qj48 U1BBTiBsYW5nPVRIIA0Kc3R5bGU9IkZPTlQtU0laRTogMThwdDsgQkFDS0dST1VORDogbGlt ZTsgQ09MT1I6IGJsYWNrOyBMSU5FLUhFSUdIVDogMTE1JTsgRk9OVC1GQU1JTFk6ICdUYWhv bWEnLCdzYW5zLXNlcmlmJzsgbXNvLXRoZW1lY29sb3I6IHRleHQxOyBtc28taGlnaGxpZ2h0 OiBsaW1lIj7guKrguJnguYPguIggDQo8L1NQQU4+PC9CPjxCPjxTUEFOIGxhbmc9VEggDQpz dHlsZT0iRk9OVC1TSVpFOiAxOHB0OyBCQUNLR1JPVU5EOiBsaW1lOyBMSU5FLUhFSUdIVDog MTE1JTsgRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgbXNvLWhpZ2hsaWdo dDogbGltZSI+PEEgDQpocmVmPSJodHRwOi8vd3d3LjI0b2tncm91cC5jb20vZ29vZHJpY2gi PuC4hOC4peC4tOC4geC4l+C4teC5iOC4meC4teC5iDwvQT48L1NQQU4+PC9CPjxTUEFOIGxh bmc9VEggDQpzdHlsZT0iRk9OVC1TSVpFOiAxOHB0OyBMSU5FLUhFSUdIVDogMTE1JTsgRk9O VC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+PG86cD48L286cD48L1NQQU4+PC9Q Pg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMTBwdCI+PFNQ QU4gbGFuZz1USCANCnN0eWxlPSJGT05ULVNJWkU6IDE0cHQ7IExJTkUtSEVJR0hUOiAxMTUl OyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnIj7guYDguKPguLLguJ7guKPg uYnguK3guKHguJfguLXguYjguIjguLDguJXguYnguK3guJnguKPguLHguJrguYHguKXguLDg uIrguYjguKfguKLguYDguKvguKXguLfguK3guJzguLnguYnguJfguLXguYjguK3guKLguLLg uIHguYDguJvguKXguLXguYjguKLguJnguYHguJvguKXguIfguIrguLXguKfguLTguJXguJXg uLHguKfguYDguK3guIfguYPguKvguYnguJTguLXguILguLbguYnguJk8L1NQQU4+PFNQQU4g DQpzdHlsZT0iRk9OVC1TSVpFOiAxNHB0OyBMSU5FLUhFSUdIVDogMTE1JTsgRk9OVC1GQU1J TFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+PEJSPjxTUEFOIA0KbGFuZz1USD7guIjguIfg uYPguIrguYnguYDguKPguLLguYDguJvguYfguJnguYDguITguKPguLfguYjguK3guIfguKHg uLfguK3guYHguKXguLDguYDguILguYfguKHguJfguLTguKjguJnguLPguJfguLLguIfguITg uLjguJMgDQrguYTguJvguKrguLnguYjguIjguLjguJTguKHguLjguYjguIfguKvguKHguLLg uKLguILguK3guIfguITguLjguJM8L1NQQU4+PEJSPjxTUEFOIGxhbmc9VEg+4LiZ4Lix4LmI 4LiZ4LiE4Li34Lit4LiE4Lin4Liy4Lih4Liq4Liz4LmA4Lij4LmH4LiIPC9TUEFOPjxCUiAN CnN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPjxCUiANCnN0eWxl PSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6IGxpbmUtYnJlYWsiPjxvOnA+PC9vOnA+PC9TUEFO PjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDEwcHQi PjxCPjxTUEFOIGxhbmc9VEggDQpzdHlsZT0iRk9OVC1TSVpFOiAxOHB0OyBCQUNLR1JPVU5E OiBsaW1lOyBDT0xPUjogYmxhY2s7IExJTkUtSEVJR0hUOiAxMTUlOyBGT05ULUZBTUlMWTog J1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBtc28tdGhlbWVjb2xvcjogdGV4dDE7IG1zby1oaWdo bGlnaHQ6IGxpbWUiPuC4quC4meC5g+C4iCANCjwvU1BBTj48L0I+PEI+PFNQQU4gbGFuZz1U SCANCnN0eWxlPSJGT05ULVNJWkU6IDE4cHQ7IEJBQ0tHUk9VTkQ6IGxpbWU7IExJTkUtSEVJ R0hUOiAxMTUlOyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBtc28taGln aGxpZ2h0OiBsaW1lIj48QSANCmhyZWY9Imh0dHA6Ly93d3cuMjRva2dyb3VwLmNvbS9nb29k cmljaCI+4LiE4Lil4Li04LiB4LiX4Li14LmI4LiZ4Li14LmIPC9BPjwvU1BBTj48L0I+PFNQ QU4gbGFuZz1USCANCnN0eWxlPSJGT05ULVNJWkU6IDE4cHQ7IExJTkUtSEVJR0hUOiAxMTUl OyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnIj48bzpwPjwvbzpwPjwvU1BB Tj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAxMHB0 Ij48Qj48U1BBTiBsYW5nPVRIIA0Kc3R5bGU9IkZPTlQtU0laRTogMTRwdDsgQ09MT1I6IHJl ZDsgTElORS1IRUlHSFQ6IDExNSU7IEZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJp ZiciPi4uLi4uLi4uLi4uLi4uLuC4guC4reC4reC4oOC4seC4ouC4reC4ouC5iOC4suC4h+C4 quC4ueC4h+C4q+C4suC4geC5gOC4oeC4peC4peC5jOC4meC4teC5ieC4o+C4muC4geC4p+C4 meC4l+C5iOC4suC4mTwvU1BBTj48L0I+PEI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAx NHB0OyBDT0xPUjogcmVkOyBMSU5FLUhFSUdIVDogMTE1JTsgRk9OVC1GQU1JTFk6ICdUYWhv bWEnLCdzYW5zLXNlcmlmJyI+4oCm4oCm4oCm4oCm4oCm4oCmPG86cD48L286cD48L1NQQU4+ PC9CPjwvUD4NCjxQPiZuYnNwOzwvUD4NClR1ZSwgMDMgQXVnIDIwMTAgMDg6MjU6MTMgR01U DQo8L0JPRFk+PC9IVE1MPg0K ----boundary_21_963d2cb7-5eb4-4b3d-9a2e-5ec78005128e-- From owner-namedroppers@ops.ietf.org Mon Aug 2 21:07: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 C97A73A6783; Mon, 2 Aug 2010 21:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.569 X-Spam-Level: ** X-Spam-Status: No, score=2.569 tagged_above=-999 required=5 tests=[AWL=-2.153, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, MISSING_HEADERS=1.292, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0FydvUlsY1D; Mon, 2 Aug 2010 21:07:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DBFEE3A6781; Mon, 2 Aug 2010 21:06:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Og8fX-000OSj-Ig for namedroppers-data0@psg.com; Tue, 03 Aug 2010 03:59:59 +0000 Received: from [2001:500:60::65] (helo=mx.ams1.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Og8fV-000OSQ-9g for namedroppers@ops.ietf.org; Tue, 03 Aug 2010 03:59:57 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id B2F035F985D for ; Tue, 3 Aug 2010 03:59:41 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 769D8E6030 for ; Tue, 3 Aug 2010 03:59:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o733xYMj020732 for ; Tue, 3 Aug 2010 13:59:36 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201008030359.o733xYMj020732@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <201007300944.o6U9iHnI036521@drugs.dv.isc.org> <4F591391-AE08-46C6-ACD5-B0FDBA53A43B@hopcount.ca> Subject: Re: [dnsext] draft-andrews-dnsext-multi-match-label-00 In-reply-to: Your message of "Sat, 31 Jul 2010 18:07:22 +0200." <4F591391-AE08-46C6-ACD5-B0FDBA53A43B@hopcount.ca> Date: Tue, 03 Aug 2010 13:59:34 +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 <4F591391-AE08-46C6-ACD5-B0FDBA53A43B@hopcount.ca>, Joe Abley writes : > Mark, > > On 2010-07-30, at 11:44, Mark Andrews wrote: > > > FYI > > Am I reading this correctly: your idea requires clients to support EDNS1? > > > Joe It requires signaling between the client and server. Bumping the EDNS version is a reasonable way to do that. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Aug 2 21:09: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 244EE3A6783; Mon, 2 Aug 2010 21:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.587 X-Spam-Level: *** X-Spam-Status: No, score=3.587 tagged_above=-999 required=5 tests=[AWL=-1.736, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, J_CHICKENPOX_55=0.6, MISSING_HEADERS=1.292, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWUK+2bU1ZaJ; Mon, 2 Aug 2010 21:09:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C7173A6781; Mon, 2 Aug 2010 21:09:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Og8lJ-000P7m-7F for namedroppers-data0@psg.com; Tue, 03 Aug 2010 04:05:57 +0000 Received: from [2001:4f8:0:2::2b] (helo=mx.pao1.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Og8lH-000P7X-4O for namedroppers@ops.ietf.org; Tue, 03 Aug 2010 04:05:55 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 813CDC941A for ; Tue, 3 Aug 2010 04:05:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 06D1DE6030 for ; Tue, 3 Aug 2010 04:05:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o7345gEP020781 for ; Tue, 3 Aug 2010 14:05:42 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201008030405.o7345gEP020781@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <201007300944.o6U9iHnI036521@drugs.dv.isc.org> Subject: Re: [dnsext] draft-andrews-dnsext-multi-match-label-00 In-reply-to: Your message of "Sun, 01 Aug 2010 19:11:08 +0100." Date: Tue, 03 Aug 2010 14:05:42 +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: > I have quickly read the draft ( http://tools.ietf.org/id/draft-andrews-dnsext-multi-match-label-00.txt ). > > It's certainly an ingenious and interesting idea, and may have some > advantages, such as minimising the total number of zones and signatures. > > However I dislike the redundancy and potential inconsistencies that can > occur. > > With multi-match labels (if I have understood correctly), every child zone > would have to be updated in order that cn and xn--fiqs8s ( or whatever ) > are equivalent everywhere, which seems bad to me. The child servers would support this or would manually replicate the zones. > With the BNAME or CNAME+DNAME approach, once the desired redirection has > been specified, names below are guarunteed to "work", and no further action > is required. BNAME or CNAME+DNAME also turn one "zone" into a zone of cnames which has its own set of issues. > So I'm not convinced this is a good idea. > > George -- 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 Aug 3 03:54: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 323583A68DA; Tue, 3 Aug 2010 03:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.759 X-Spam-Level: X-Spam-Status: No, score=0.759 tagged_above=-999 required=5 tests=[AWL=-1.888, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Jo8gojRC1oz; Tue, 3 Aug 2010 03:54:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E6D3F3A682E; Tue, 3 Aug 2010 03:54:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgF2d-0000y9-KX for namedroppers-data0@psg.com; Tue, 03 Aug 2010 10:48:15 +0000 Received: from [89.188.97.107] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgF2b-0000wi-3l for namedroppers@ops.ietf.org; Tue, 03 Aug 2010 10:48:13 +0000 Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id A96B246792; Tue, 3 Aug 2010 14:48:04 +0400 (MSD) Message-ID: <4C57F3E4.9060207@cryptocom.ru> Date: Tue, 03 Aug 2010 14:48:04 +0400 From: Basil Dolmatov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Jeffrey A. Williams" CC: bmanning@vacation.karoshi.com, Nicholas Weaver , Phillip Hallam-Baker , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> In-Reply-To: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> 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: 01.08.2010 01:01, Jeffrey A. Williams пишет: > Bill and all, > > Your last point is a good one and I for one agree > that such is, or may be a problem in some if not many > instances. > In most of the instances... In current world DNS-admin in _most_ cases have no connection with the domain owner, who is _really_ the target of seeking the trust. Not going far apart from obvious (implied) scheme of https:// it can be stated that the client with the browser at hand want to approach to the given legal entity in order to exchange some information (credit card number) that requires at least one-way trust... I wonder how the any kind of trust can be built through the set of of people which are not bound by any legal means... Going to the much more simpler question of establishing SSL/TLS connection, as it has been said already here, it does not require _any_ level of trust so can be established using _any kind of certs (even expired ones). This could be the situation when placing something in DNS will help, just to supply the interested party with _any_ cert of the given server. dol@ > > -----Original Message----- >> From: bmanning@vacation.karoshi.com >> Sent: Jul 30, 2010 9:21 PM >> To: Nicholas Weaver >> Cc: Phillip Hallam-Baker, namedroppers >> Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications >> >> the one thing that worries me is that trust is not transitive, the DNS admin >> is generally not the sysadmin of the node in question and so syncronization >> between the sysadmin and the DNS admin(s) is an exploitable channel. >> >> --bill >> > From dnsext-archive@ietf.org Tue Aug 3 07:37: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 8669C3A684F for ; Tue, 3 Aug 2010 07:37: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 AE hex): Subject: dnsext-archive@ietf.org New \256 Valium 58% 0FF\n X-Spam-Flag: NO X-Spam-Score: -24.794 X-Spam-Level: X-Spam-Status: No, score=-24.794 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_99=3.5, DRUGS_ANXIETY=0.01, 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, J_CHICKENPOX_22=0.6, MANGLED_OFF=2.3, 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_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_DRUG_GAP_VA=1.014, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS--Rt1SCBM0 for ; Tue, 3 Aug 2010 07:37:20 -0700 (PDT) Received: from 171-123-94-178.pool.ukrtel.net (171-123-94-178.pool.ukrtel.net [178.94.123.171]) by core3.amsl.com (Postfix) with SMTP id 0E4663A67E1 for ; Tue, 3 Aug 2010 07:37:19 -0700 (PDT) Message-ID: <20100803173702.2652.qmail@171-123-94-178.pool.ukrtel.net> From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org New ® Valium 58% 0FF MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Date: Tue, 3 Aug 2010 07:37:19 -0700 (PDT) http://ftfoz.rxtrusts.com?name=dnsext-archive@ietf.org verheerend. Schon um die Durchfuhrung eines wirklich ernsten Kampfes uberhaupt zu ermoglichen, mu.te die alldeutsche Bewegung sich vor allem der Gewinnun From owner-namedroppers@ops.ietf.org Tue Aug 3 08:28: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 F1E0C3A6918; Tue, 3 Aug 2010 08:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.957 X-Spam-Level: * X-Spam-Status: No, score=1.957 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 7cFnPz4RcXKx; Tue, 3 Aug 2010 08:28:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A795B3A68D9; Tue, 3 Aug 2010 08:28:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgJJl-000F8u-W0 for namedroppers-data0@psg.com; Tue, 03 Aug 2010 15:22:13 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgJJj-000F7u-3S for namedroppers@ops.ietf.org; Tue, 03 Aug 2010 15:22:11 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1OgJJe-0003gU-Fx; Tue, 03 Aug 2010 15:22:06 +0000 Received: by bfk.de with local id 1OgJJa-0003OW-RZ; Tue, 03 Aug 2010 15:22:02 +0000 To: Phillip Hallam-Baker Cc: namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: From: Florian Weimer Date: Tue, 03 Aug 2010 15:22:02 +0000 In-Reply-To: (Phillip Hallam-Baker's message of "Fri\, 30 Jul 2010 12\:16\:48 -0400") Message-ID: <82y6cn202t.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Phillip Hallam-Baker: > One issue missing from the charter is the question of use of DNSSEC in > applications. The only way an application can "use" DNSSEC is to refuse to work with insecure (provably unsigned) responses. What would be the benefit of that? Putting data into DNS which can be used for cryptographic operations and policy decisions at other protocol layers looks rather useful to me, but this has nothing to do with DNSSEC at all. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Tue Aug 3 09:15: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 1BB883A6A8B; Tue, 3 Aug 2010 09:15: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScX-ELvYoyr9; Tue, 3 Aug 2010 09:15:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 258263A6A8C; Tue, 3 Aug 2010 09:15:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgK6t-000LuU-FJ for namedroppers-data0@psg.com; Tue, 03 Aug 2010 16:12:59 +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.72 (FreeBSD)) (envelope-from ) id 1OgK6r-000Lu4-7U for namedroppers@ops.ietf.org; Tue, 03 Aug 2010 16:12:57 +0000 Received: from [199.212.90.17] (helo=dh17.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OgK6l-0002VZ-SK; Tue, 03 Aug 2010 16:12:52 +0000 Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <82y6cn202t.fsf@mid.bfk.de> Date: Tue, 3 Aug 2010 12:12:50 -0400 Cc: Phillip Hallam-Baker , namedroppers Content-Transfer-Encoding: 7bit Message-Id: References: <82y6cn202t.fsf@mid.bfk.de> To: Florian Weimer X-Mailer: Apple Mail (2.1081) X-SA-Exim-Connect-IP: 199.212.90.17 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-08-03, at 11:22, Florian Weimer wrote: > * Phillip Hallam-Baker: > >> One issue missing from the charter is the question of use of DNSSEC in >> applications. > > The only way an application can "use" DNSSEC is to refuse to work with > insecure (provably unsigned) responses. Why is that the only way? Joe From owner-namedroppers@ops.ietf.org Tue Aug 3 09: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 5E4FE3A6A8C; Tue, 3 Aug 2010 09:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.082 X-Spam-Level: ** X-Spam-Status: No, score=2.082 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_20=-0.74, 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 Kbv2hpeKKtSj; Tue, 3 Aug 2010 09:15:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 495B53A6999; Tue, 3 Aug 2010 09:15:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgK6e-000LtT-8j for namedroppers-data0@psg.com; Tue, 03 Aug 2010 16:12:44 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgK6a-000Lsa-6Y for namedroppers@ops.ietf.org; Tue, 03 Aug 2010 16:12:40 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1OgK6T-0004fm-Fa; Tue, 03 Aug 2010 16:12:33 +0000 Received: by bfk.de with local id 1OgK6T-0003qQ-8t; Tue, 03 Aug 2010 16:12:33 +0000 To: Paul Wouters Cc: Phillip Hallam-Baker , Nicholas Weaver , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <34F2CFD6-EE08-4BEA-86B1-BCD12755CECE@icsi.berkeley.edu> From: Florian Weimer Date: Tue, 03 Aug 2010 16:12:33 +0000 In-Reply-To: (Paul Wouters's message of "Fri\, 30 Jul 2010 18\:23\:04 -0400 \(EDT\)") Message-ID: <82k4o71xqm.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Paul Wouters: > The federated DNS approach has a big advantadge. Trust moves from > larger to smaller groups, you can override it at any point for your > personal 1 trust anchor, [...] This only applies as long as your trust decision is somehow related to the name. I fear that this model only looks more attractive than established alternatives because we lack real-world experience and typical failure scenarios. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Tue Aug 3 09:19: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 8DCDD3A68E0; Tue, 3 Aug 2010 09:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_QP_LONG_LINE=1.396, 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 XKxg+nG5uper; Tue, 3 Aug 2010 09:19:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B29D3A6937; Tue, 3 Aug 2010 09:19:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgKA2-000MWa-DM for namedroppers-data0@psg.com; Tue, 03 Aug 2010 16:16:14 +0000 Message-Id: Received: from [76.96.62.80] (helo=qmta08.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgKA0-000MW7-6Q for namedroppers@ops.ietf.org; Tue, 03 Aug 2010 16:16:12 +0000 Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta08.westchester.pa.mail.comcast.net with comcast id pni21e0011vXlb858sGBcU; Tue, 03 Aug 2010 16:16:11 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta17.westchester.pa.mail.comcast.net with comcast id psGA1e00R1EtFYL3dsGBcf; Tue, 03 Aug 2010 16:16:11 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 03 Aug 2010 12:16:02 -0400 To: Florian Weimer ,Phillip Hallam-Baker From: Michael StJohns Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Cc: namedroppers In-Reply-To: <82y6cn202t.fsf@mid.bfk.de> References: <82y6cn202t.fsf@mid.bfk.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 11:22 AM 8/3/2010, Florian Weimer wrote: >* Phillip Hallam-Baker: > >> One issue missing from the charter is the question of use of DNSSEC in >> applications. > >The only way an application can "use" DNSSEC is to refuse to work with >insecure (provably unsigned) responses. What would be the benefit of >that? Consider for a moment the email system. It seems to me that it might be a= good idea for an MTA to refuse to deliver email to an MTA or mail store= for which the MX record is bogus. And I would consider that a benefit. Or= refusing to accept email from a site where the signed PTR record doesn't= point back to a signed and consistent A record. But mail is one of the few applications where the routing information is= stored in the DNS. Other automated (non-interactive) applications that= depend on NAPTR or SRV records may also be good candidates for this type of= automatic block.=20 >Putting data into DNS which can be used for cryptographic operations >and policy decisions at other protocol layers looks rather useful to >me, but this has nothing to do with DNSSEC at all. Putting data into the DNS which can be used for cryptographic operations= looks like a very bad idea to me for at least the reasons noted by Basil.= =20 >--=20 >Florian Weimer >BFK edv-consulting GmbH http://www.bfk.de/ >Kriegsstra=DFe 100 tel: +49-721-96201-1 >D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Tue Aug 3 09:20: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 026923A68E0; Tue, 3 Aug 2010 09:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.284 X-Spam-Level: * X-Spam-Status: No, score=1.284 tagged_above=-999 required=5 tests=[AWL=0.534, 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 o7a7HMZx8cm3; Tue, 3 Aug 2010 09:20:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EEE613A6879; Tue, 3 Aug 2010 09:20:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgKCX-000Ms0-Kp for namedroppers-data0@psg.com; Tue, 03 Aug 2010 16:18:49 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgKCU-000MrR-DK for namedroppers@ops.ietf.org; Tue, 03 Aug 2010 16:18:46 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1OgKCR-00077Q-Tf; Tue, 03 Aug 2010 16:18:43 +0000 Received: by bfk.de with local id 1OgKCR-0006BZ-Ol; Tue, 03 Aug 2010 16:18:43 +0000 To: Joe Abley Cc: Phillip Hallam-Baker , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <82y6cn202t.fsf@mid.bfk.de> From: Florian Weimer Date: Tue, 03 Aug 2010 16:18:43 +0000 In-Reply-To: (Joe Abley's message of "Tue\, 3 Aug 2010 12\:12\:50 -0400") Message-ID: <82eief1xgc.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Joe Abley: > On 2010-08-03, at 11:22, Florian Weimer wrote: > >> * Phillip Hallam-Baker: >>=20 >>> One issue missing from the charter is the question of use of DNSSEC in >>> applications. >>=20 >> The only way an application can "use" DNSSEC is to refuse to work with >> insecure (provably unsigned) responses. > > Why is that the only way? All data which is available with DNSSEC is also available without DNSSEC. Without such artifical rejections, any DNS-based protocol would work equally well with signed and unsigned zones. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From dnsext-archive@ietf.org Tue Aug 3 09:59: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 EFB813A6AAB for ; Tue, 3 Aug 2010 09:59: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 AE hex): Subject: dnsext-archive@ietf.org Top \256 Vicodin 71% 0FF\n X-Spam-Flag: NO X-Spam-Score: -19.429 X-Spam-Level: X-Spam-Status: No, score=-19.429 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_PAIN=0.01, 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_BR=0.955, HELO_EQ_DYNAMIC=1.144, HOST_EQ_BR=1.295, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_73=0.6, MANGLED_OFF=2.3, 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_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWwSK-QYBbHD for ; Tue, 3 Aug 2010 09:59:44 -0700 (PDT) Received: from 189-041-143-127.xd-dynamic.ctbcnetsuper.com.br (189-041-143-127.xd-dynamic.ctbcnetsuper.com.br [189.41.143.127]) by core3.amsl.com (Postfix) with SMTP id 2F7AB3A6988 for ; Tue, 3 Aug 2010 09:59:43 -0700 (PDT) Message-ID: <20100803202657.2404.qmail@189-041-143-127.xd-dynamic.ctbcnetsuper.com.br> From: Vicodin To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org Top ® Vicodin 71% 0FF MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Date: Tue, 3 Aug 2010 09:59:43 -0700 (PDT) http://wbyzf.rxstuffsite.com?name=dnsext-archive@ietf.org sind dann ihre Antwort!Der Mensch, der die Rassengesetze verkennt und mi.achtet, bringt sich wirklich um das Gluck, das ihm bestimmt erscheint. Er verhindert den Siegeszug der besten Rasse und damit aber auch die Vorbedingung zu allem menschlichen Fortschritt. Er begibt sich in der Folge, belastet mit der Empfindlichkeit des Menschen, ins Bereich des hilflosen Tieres. Es ist ein mu.iges Beginnen, daruber zu streiten, welche Rasse oder Rassen die ursprunglichen Trager der menschlichen Kultur waren und damit die wirklichen Begrunder dessen, was wir mit dem Worte Menschheit alles umfassen. Einfacher ist es, sich diese Frage fur die Gegenwart zu stellen, und hier ergibt sich auch die Antwort leicht und deutlich. Was wir heute an menschlicher Kultur, an Ergebnisse From owner-namedroppers@ops.ietf.org Tue Aug 3 10:01: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 CE4F93A6AA8; Tue, 3 Aug 2010 10:01:41 -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 4uwSxgJg0KSF; Tue, 3 Aug 2010 10:01:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F31D33A6998; Tue, 3 Aug 2010 10:01:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgKoK-0002J0-CG for namedroppers-data0@psg.com; Tue, 03 Aug 2010 16:57:52 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgKoE-0002Hy-0t for namedroppers@ops.ietf.org; Tue, 03 Aug 2010 16:57:46 +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 EE51EC5693F; Tue, 3 Aug 2010 17:57:42 +0100 (BST) Date: Tue, 03 Aug 2010 17:57:42 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Florian Weimer , Joe Abley cc: Phillip Hallam-Baker , namedroppers , Alex Bligh Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: <7143B370CED458C7B8AE6465@Ximines.local> In-Reply-To: <82eief1xgc.fsf@mid.bfk.de> References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 3 August 2010 16:18:43 +0000 Florian Weimer wrote: > All data which is available with DNSSEC is also available without > DNSSEC. Without such artifical rejections, any DNS-based protocol > would work equally well with signed and unsigned zones. In practical terms there is a distinction between the application, the library, the stub resolver, and the recursive nameserver. Consider a legacy application that calls gethostbyname(), and a library that supports DNSSEC that attempts a lookup on a name in a signed zone where the authoritative nameserver concerned has been compromised and is producing incorrect data (assume it's signed elsewhere so the key has not been compromised). My feeling is that it would be useful behaviour if gethostbyname() returned something other than the incorrect A record. The things one might choose to upgrade to support DNSSEC to achieve this allegedly useful result are: 1. Recursive nameserver 2. Stub resolver 3. Library 4. Application It would seem a pity if it were necessary to upgrade all four of these to get it. -- Alex Bligh From owner-namedroppers@ops.ietf.org Tue Aug 3 15:39: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 04A2E3A68AE; Tue, 3 Aug 2010 15:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=-0.380, 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 aHQbcIDXpRb0; Tue, 3 Aug 2010 15:39:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F29DF3A689E; Tue, 3 Aug 2010 15:39:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgQ4K-000LkM-E1 for namedroppers-data0@psg.com; Tue, 03 Aug 2010 22:34:44 +0000 Received: from [209.85.214.180] (helo=mail-iw0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgQ4F-000Ljj-KO for namedroppers@ops.ietf.org; Tue, 03 Aug 2010 22:34:40 +0000 Received: by iwn8 with SMTP id 8so7494315iwn.11 for ; Tue, 03 Aug 2010 15:34:39 -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=9DCUUS3lb/IC6Ij3hiz+mZrrnXTp6BIkT7tSpWAhCg0=; b=x8/N2T9PjZc4LpTLvrcdtelXNqgO7NIA4LLFHpz3sl3LtnF8Ztc15DkvBvNYV/6qXw x0+BVk/aONtzfKJtOit5ZZxjmZpnnELYnIuHyPjNm8nrVwqbC1e/iPRfxBnCFWYjL3uN jxfTL5np+KaJEuJEf2e4vQmu6VAzdPB5ZUtjc= 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=XX0LPRrzzb5JaNjQNpSRWam5P7IDoHF6xVXKdjtKHLcMzIjczTCneT0WUPEtkthYD2 BoywaTO6T3eYXlzdm+lI3ycsgstRJzfcwa6n4BHX8N2j1SodFHegH8D91zFLckGXShih 3HVEtyGpIK2niuNus/W4W/yJaNmnuJhBaP+Cc= MIME-Version: 1.0 Received: by 10.231.184.71 with SMTP id cj7mr9130661ibb.159.1280874878993; Tue, 03 Aug 2010 15:34:38 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Tue, 3 Aug 2010 15:34:38 -0700 (PDT) In-Reply-To: <82eief1xgc.fsf@mid.bfk.de> References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> Date: Tue, 3 Aug 2010 18:34:38 -0400 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Phillip Hallam-Baker To: Florian Weimer Cc: Joe Abley , namedroppers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: The reason that I have been so anxious to get DNSSEC deployed is that there are important security problems that can only be solved through DNSSEC. That is not one of them. On Tue, Aug 3, 2010 at 12:18 PM, Florian Weimer wrote: > * Joe Abley: > >> On 2010-08-03, at 11:22, Florian Weimer wrote: >> >>> * Phillip Hallam-Baker: >>> >>>> One issue missing from the charter is the question of use of DNSSEC in >>>> applications. >>> >>> The only way an application can "use" DNSSEC is to refuse to work with >>> insecure (provably unsigned) responses. >> >> Why is that the only way? > > All data which is available with DNSSEC is also available without > DNSSEC. =A0Without such artifical rejections, any DNS-based protocol > would work equally well with signed and unsigned zones. > > -- > Florian Weimer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > BFK edv-consulting GmbH =A0 =A0 =A0 http://www.bfk.de/ > Kriegsstra=DFe 100 =A0 =A0 =A0 =A0 =A0 =A0 =A0tel: +49-721-96201-1 > D-76133 Karlsruhe =A0 =A0 =A0 =A0 =A0 =A0 fax: +49-721-96201-99 > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Tue Aug 3 16:08: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 B2D843A6B47; Tue, 3 Aug 2010 16:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[AWL=-0.376, 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 4gVpsC2VHg0f; Tue, 3 Aug 2010 16:08:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C0BA73A6B41; Tue, 3 Aug 2010 16:08:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgQXs-000OmF-6O for namedroppers-data0@psg.com; Tue, 03 Aug 2010 23:05:16 +0000 Received: from [209.85.214.180] (helo=mail-iw0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgQXp-000Olz-PT for namedroppers@ops.ietf.org; Tue, 03 Aug 2010 23:05:13 +0000 Received: by iwn8 with SMTP id 8so7532862iwn.11 for ; Tue, 03 Aug 2010 16:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=G2Xtj4B5pNOcxU+b1Ev8aDZ2p+jPXAJwSbVq37vhuDo=; b=WneWBt30Agpji562ynkLjY8pVS6Ttykl5gVjgLohLHq3g4JdIB2AntyaSI26z2vvAG YM3BF/ZyF6cBmDrIysgZYlz4Sk0mkBzb06vjyTDs5peqnnRoP2QSgewqJ0EmQj9PG1cu RXTqFfTdQrzrsuyLq3NDFuvPjiBY1YyR2MpO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=g8XZaY7wOAyPVsNRHVzkujBVkb16tCMMeYjm8gDdil7phO2FXG81j+uaKPe0frMmAf mNwNuZyrpu9acsPxheR5jqNNs0SaYECes2XHXH5p7yggXkh1q4Yj55c8m5E04AfkLvuM mfQSkcwoG4V4wYytXtuibMGR+qAdC4HbH2WwE= Received: by 10.231.36.134 with SMTP id t6mr9442777ibd.128.1280876713196; Tue, 03 Aug 2010 16:05:13 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id g31sm7095227ibh.16.2010.08.03.16.05.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Aug 2010 16:05:11 -0700 (PDT) References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <25B407F7-BE9E-4FEB-8FAF-52F482422530@icsi.berkeley.edu> Content-Transfer-Encoding: 7bit Cc: Nicholas Weaver , Florian Weimer , Joe Abley , namedroppers From: Nicholas Weaver Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Date: Tue, 3 Aug 2010 16:05:09 -0700 To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 3, 2010, at 3:34 PM, Phillip Hallam-Baker wrote: > The reason that I have been so anxious to get DNSSEC deployed is that > there are important security problems that can only be solved through > DNSSEC. That is not one of them. What important security problems? From owner-namedroppers@ops.ietf.org Wed Aug 4 00:36: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 1E5B13A693D; Wed, 4 Aug 2010 00:36:04 -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 JjahhXJBld-V; Wed, 4 Aug 2010 00:36:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 846DE3A67A1; Wed, 4 Aug 2010 00:36:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgYPa-0004XE-QZ for namedroppers-data0@psg.com; Wed, 04 Aug 2010 07:29:14 +0000 Received: from [2a02:760:1002:15::14] (helo=mail.kirei.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgYPY-0004WX-Cb for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 07:29:12 +0000 Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kirei.se; s=wagaya20060620; t=1280906949; bh=BGkhJud/UUorVeQj3xPkvU/00yJxTaz7u5+LjDB4bcw=; h=Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Oo/qdIHKluMGbKNPUyWA1wmppjmPZW3YsEWAefrW3J/Trqfg9TySXz3V0vEc51/ii dqu6VoKd7LOcXtLwWoK46Dha/BUHWxXGcLPSkfkzPWwRAMzc2fvDIOVt3c194UauY4 0SNIVN6FfoUBf4MHjfCEBTHpPVnK0ymsyLcp9JZY= Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <4C57F3E4.9060207@cryptocom.ru> Date: Wed, 4 Aug 2010 09:29:01 +0200 Cc: "Jeffrey A. Williams" , bmanning@vacation.karoshi.com, Nicholas Weaver , Phillip Hallam-Baker , namedroppers Content-Transfer-Encoding: quoted-printable Message-Id: <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> To: Basil Dolmatov X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 3 aug 2010, at 12.48, Basil Dolmatov wrote: > In current world DNS-admin in _most_ cases have no connection with the = domain owner, who is _really_ the target of seeking the trust. That might be true today, but it does not have to be true tomorrow. When = the use of DNS and DNSSEC change, how we administer it needs to change = as well. jakob From owner-namedroppers@ops.ietf.org Wed Aug 4 01:03: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 ECFD83A6A1E; Wed, 4 Aug 2010 01:03:50 -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.733 X-Spam-Level: * X-Spam-Status: No, score=1.733 tagged_above=-999 required=5 tests=[AWL=0.184, 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 QUWXw+G5PmLL; Wed, 4 Aug 2010 01:03:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD9ED3A6A0A; Wed, 4 Aug 2010 01:03:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgYu1-0008Sx-9b for namedroppers-data0@psg.com; Wed, 04 Aug 2010 08:00:41 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgYty-0008Rk-Iu for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 08:00:39 +0000 Received: (eyou send program); Wed, 04 Aug 2010 16:00:37 +0800 Message-ID: <480908837.21845@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, 04 Aug 2010 16:00:37 +0800 Message-ID: From: "Jiankang YAO" To: "Joe Abley" , "Florian Weimer" Cc: "Phillip Hallam-Baker" , "namedroppers" References: <82y6cn202t.fsf@mid.bfk.de> <480852715.25423@cnnic.cn> Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Date: Wed, 4 Aug 2010 16:00:44 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvZSBBYmxleSIgPGphYmxl eUBob3Bjb3VudC5jYT4NClRvOiAiRmxvcmlhbiBXZWltZXIiIDxmd2VpbWVyQGJmay5kZT4NCkNj OiAiUGhpbGxpcCBIYWxsYW0tQmFrZXIiIDxoYWxsYW1AZ21haWwuY29tPjsgIm5hbWVkcm9wcGVy cyIgPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAw NCwgMjAxMCAxMjoxMiBBTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIENoYXJ0ZXIgZGlzY3Vzc2lv biAtIFVzZSBvZiBETlNTRUMgaW4gYXBwbGljYXRpb25zDQoNCg0KPiANCj4gT24gMjAxMC0wOC0w MywgYXQgMTE6MjIsIEZsb3JpYW4gV2VpbWVyIHdyb3RlOg0KPiANCj4+ICogUGhpbGxpcCBIYWxs YW0tQmFrZXI6DQo+PiANCj4+PiBPbmUgaXNzdWUgbWlzc2luZyBmcm9tIHRoZSBjaGFydGVyIGlz IHRoZSBxdWVzdGlvbiBvZiB1c2Ugb2YgRE5TU0VDIGluDQo+Pj4gYXBwbGljYXRpb25zLg0KPj4g DQo+PiBUaGUgb25seSB3YXkgYW4gYXBwbGljYXRpb24gY2FuICJ1c2UiIEROU1NFQyBpcyB0byBy ZWZ1c2UgdG8gd29yayB3aXRoDQo+PiBpbnNlY3VyZSAocHJvdmFibHkgdW5zaWduZWQpIHJlc3Bv bnNlcy4NCj4+DQoNCnlvdSBzaG91bGQgZ2l2ZSB0aGUgY3VzdG9tZXJzIG9yIHRoZSBhcHBsaWNh dGlvbnMgYSBjaG9pY2UsIGRuc3NlYyBvciBub3QuDQoNCmlmIHlvdSBmb3JjZSB0aGUgY3VzdG9t ZXJzIHRvIHVzZSBkbnNzZWMsIHRoZXkgbWF5IGJlIHVuaGFwcHkuDQoNCmZvciBpbnRlcm5ldCBi YW5raW5nIG9yIGJ1c2luZXNzLCBkbnNzZWMgaXMgYSBnb29kIGNob2ljZSwgYnV0IGZvciBvdGhl cnMsIG1heSBiZSBub3QuDQoNCj4gDQo+IFdoeSBpcyB0aGF0IHRoZSBvbmx5IHdheT8NCj4gDQoN CisxDQoNCmlmIHdlIGZvcmNlIGRuc3NlYyB0b2RheSwgbWFueSBhcHBsaWNhdGlvbnMgbWF5IG5v dCB3b3JrIGR1ZSB0byBhIGxvdCBvZiB1bi1lbmFibGVkIGRuc3NlYyBkb21haW4gbmFtZXMuDQoN Cg0KPiANCj4gSm9lDQo+ From owner-namedroppers@ops.ietf.org Wed Aug 4 01: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 D5FFD3A68BF; Wed, 4 Aug 2010 01:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHJwxRHKlOcP; Wed, 4 Aug 2010 01:40:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ABCB73A67E7; Wed, 4 Aug 2010 01:40:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgZT3-000DZe-Rh for namedroppers-data0@psg.com; Wed, 04 Aug 2010 08:36:53 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgZSx-000DYG-SA for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 08:36:48 +0000 Received: (qmail 41293 invoked from network); 4 Aug 2010 08:42:17 -0000 Received: from bmdk1212.bmobile.ne.jp (HELO ?202.232.243.212?) (202.232.243.212) by necom830.hpcl.titech.ac.jp with SMTP; 4 Aug 2010 08:42:17 -0000 Message-ID: <4C59265F.10402@necom830.hpcl.titech.ac.jp> Date: Wed, 04 Aug 2010 17:35:43 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Phillip Hallam-Baker CC: Florian Weimer , Joe Abley , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP 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: Phillip Hallam-Baker wrote: > The reason that I have been so anxious to get DNSSEC deployed is that > there are important security problems that can only be solved through > DNSSEC. That is not one of them. There is no important security problem solvable by DNSSEC. Masataka Ohta From owner-namedroppers@ops.ietf.org Wed Aug 4 05:05: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 133583A682E; Wed, 4 Aug 2010 05:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.281 X-Spam-Level: X-Spam-Status: No, score=-102.281 tagged_above=-999 required=5 tests=[AWL=0.319, 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 JOjxMPSqklJn; Wed, 4 Aug 2010 05:05:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A0C3F3A6872; Wed, 4 Aug 2010 05:05:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgcdQ-000Izj-0q for namedroppers-data0@psg.com; Wed, 04 Aug 2010 11:59:48 +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.72 (FreeBSD)) (envelope-from ) id 1OgcdK-000Il2-6t for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 11:59:45 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o74Bw2jq016828; Wed, 4 Aug 2010 11:58:02 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o74Bvxc8016827; Wed, 4 Aug 2010 11:57:59 GMT Date: Wed, 4 Aug 2010 11:57:59 +0000 From: bmanning@vacation.karoshi.com To: Jakob Schlyter Cc: Basil Dolmatov , "Jeffrey A. Williams" , bmanning@vacation.karoshi.com, Nicholas Weaver , Phillip Hallam-Baker , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: <20100804115759.GA16458@vacation.karoshi.com.> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> 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, Aug 04, 2010 at 09:29:01AM +0200, Jakob Schlyter wrote: > On 3 aug 2010, at 12.48, Basil Dolmatov wrote: > > > In current world DNS-admin in _most_ cases have no connection with the domain owner, who is _really_ the target of seeking the trust. > > That might be true today, but it does not have to be true tomorrow. When the use of DNS and DNSSEC change, how we administer it needs to change as well. > > jakob > well - that seems to lead to a fork. one path would lead toward DNS admins taking over control of the end system admin function (Since we control the DNS, we have sysadmin from your hosts); and the second path leads toward sysadmins of the nodes holding the domain name taking over the operation of their own DNS. That second path is actually very much in line with one of the DNS design principles, that heirarchy is fundamentally a good thing. However that path also leads to a much broader diversity in DNS admin expertise - and market trends over the past 15 year seem to indicate may are willing/eager to outsource their DNS to others. As long as you are also willing to outsource your sysadmin tasks (e.g. cloud computing) then I think the first fork is viable. IMHO, I do not beleive we will ever get rid of either fork, some will want the "ease" of completely outsourcing their services, others want to keep them in-house. And there will be the odd lot who split the two. Its not going to be easy to socially engineer a fundamental change in human nature. -- bill From owner-namedroppers@ops.ietf.org Wed Aug 4 05:18: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 A898A3A6B04; Wed, 4 Aug 2010 05:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.249 X-Spam-Level: X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLKhAYXOmRbI; Wed, 4 Aug 2010 05:17:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8C2EE3A6AE9; Wed, 4 Aug 2010 05:16:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogcqb-000L7c-GO for namedroppers-data0@psg.com; Wed, 04 Aug 2010 12:13:25 +0000 Received: from [74.125.83.180] (helo=mail-pv0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgcqY-000L79-Aq for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 12:13:23 +0000 Received: by pvg12 with SMTP id 12so3100016pvg.11 for ; Wed, 04 Aug 2010 05:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=r/jp5K/OCwZ7QzNWKhTGb5DIVFeD5NR0E7DaEmS9gmc=; b=uQNAhBGAyW95dehkkdx5VvyRjoz6zsk37a2OLljqCMTqwBUf+3otvyz4ouwQCyfypa uuNOB2FfXRqVOnOJXKnx0IJsRTxBXurHPw8/BParGAb1ZCwOdEtkEPGuMzpMP1eAB1CF +eL452F4kmd0SAPAv9DtjUHGwcUogv/iKUfDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=MJxbSJ+1fnN7lkOWgbqJyEtEYF7txcVtYGJQDgav9Z98A8VTtlSySYS7ZBI6C59o6H oL1lNhdd5Ls5m7gn9KI9gKw+jLai6sB/yFhVmcP/UPivitAdes8b5qIYN2PMa2ga96e4 hkdjoB8Me8fmhwgmgOUKQXQiZRhNlvavlLVZs= Received: by 10.142.141.8 with SMTP id o8mr7720327wfd.298.1280924001670; Wed, 04 Aug 2010 05:13:21 -0700 (PDT) Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) by mx.google.com with ESMTPS id t11sm10511302wfc.4.2010.08.04.05.13.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 05:13:18 -0700 (PDT) Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Wed, 4 Aug 2010 05:13:15 -0700 Cc: Nicholas Weaver , Florian Weimer , Joe Abley , namedroppers Content-Transfer-Encoding: quoted-printable Message-Id: <1C736AB3-B168-4423-9D4F-1BC2F60540B4@ICSI.Berkeley.EDU> References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <25B407F7-BE9E-4FEB-8FAF-52F482422530@icsi.berkeley.edu> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 4, 2010, at 5:07 AM, Phillip Hallam-Baker wrote: > Preventing a downgrade attack. >=20 > At the moment the biggest hole in SSL is that it is optional and the > client does not have any in-band method of finding out if it is > supported. DNSSEC doesn't help because it suffers from the exact same downgrade = attacks. Thus unless you have UNIVERSAL signing of DNS data, the = in-path attacker just downgrades DNSSEC first. From owner-namedroppers@ops.ietf.org Wed Aug 4 05:18: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 D9FC43A6A71; Wed, 4 Aug 2010 05:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[AWL=-0.371, 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 yU6sT3PL0y7T; Wed, 4 Aug 2010 05:17:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6EBE63A6A67; Wed, 4 Aug 2010 05:16:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogcqf-000L8L-Kf for namedroppers-data0@psg.com; Wed, 04 Aug 2010 12:13:29 +0000 Received: from [209.85.213.52] (helo=mail-yw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogcqd-000L7q-CY for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 12:13:27 +0000 Received: by ywa6 with SMTP id 6so2742898ywa.11 for ; Wed, 04 Aug 2010 05:13:26 -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; bh=5ZeccUCwnyby2oPcDWYPzLba6HcxqDOsVO06AKTu2Oo=; b=lch5Vh5gJzX6HJ3PKVJOHAbmui752K5wL5Jctou8Id4lGoYuamD2pbpp8H1D5SEshL pUdphsRcqV9I6RGJFwLYFn8vHot3WnE2nHtWwLWNqnQIdRkpLWviyvDEwcbJtrSBuulZ OOS38X3G7RFd8g1nw2cFzTSJdHu7XIXDimuaE= 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=C4/n1ZdpY0mCGx6kxRrCF+sk0+GFjLppjR1fvXJnQf/trfBCyUae57+WaNTLBY8+Pi VzfnaBC8llyrC9a2XS2D6ChE1BqLBjC9FWTJIexPJZ6i1aCD5U8PjWTquse71V3F1/Pl nW2M9MECTeJto3vSoFYZyxpEQrEboYd+0bNGQ= MIME-Version: 1.0 Received: by 10.231.162.2 with SMTP id t2mr2264034ibx.57.1280923668660; Wed, 04 Aug 2010 05:07:48 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Wed, 4 Aug 2010 05:07:48 -0700 (PDT) In-Reply-To: <25B407F7-BE9E-4FEB-8FAF-52F482422530@icsi.berkeley.edu> References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <25B407F7-BE9E-4FEB-8FAF-52F482422530@icsi.berkeley.edu> Date: Wed, 4 Aug 2010 08:07:48 -0400 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Phillip Hallam-Baker To: Nicholas Weaver Cc: Florian Weimer , Joe Abley , 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: Preventing a downgrade attack. At the moment the biggest hole in SSL is that it is optional and the client does not have any in-band method of finding out if it is supported. On Tue, Aug 3, 2010 at 7:05 PM, Nicholas Weaver wrote: > > On Aug 3, 2010, at 3:34 PM, Phillip Hallam-Baker wrote: > >> The reason that I have been so anxious to get DNSSEC deployed is that >> there are important security problems that can only be solved through >> DNSSEC. That is not one of them. > > What important security problems? > > -- Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Wed Aug 4 05: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 E44F53A67E2; Wed, 4 Aug 2010 05:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.177 X-Spam-Level: * X-Spam-Status: No, score=1.177 tagged_above=-999 required=5 tests=[AWL=0.427, 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 xwRxm9aJoTO5; Wed, 4 Aug 2010 05:18:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0BB9E3A6B7A; Wed, 4 Aug 2010 05:16:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogcqr-000LAN-T9 for namedroppers-data0@psg.com; Wed, 04 Aug 2010 12:13:41 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogcqp-000L9U-Ot for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 12:13:39 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Ogcqi-0006vd-OY; Wed, 04 Aug 2010 12:13:32 +0000 Received: by bfk.de with local id 1OgcqW-0000AA-E2; Wed, 04 Aug 2010 12:13:20 +0000 To: Phillip Hallam-Baker Cc: Nicholas Weaver , Joe Abley , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <25B407F7-BE9E-4FEB-8FAF-52F482422530@icsi.berkeley.edu> From: Florian Weimer Date: Wed, 04 Aug 2010 12:13:20 +0000 In-Reply-To: (Phillip Hallam-Baker's message of "Wed\, 4 Aug 2010 08\:07\:48 -0400") Message-ID: <82sk2u1spr.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Phillip Hallam-Baker: > Preventing a downgrade attack. > > At the moment the biggest hole in SSL is that it is optional and the > client does not have any in-band method of finding out if it is > supported. Again, this is totally unrelated to DNSSEC. An application which prevented downgrade attacks only if it knows that the indicating DNS resource record was secure (that is, DNSSEC-signed) would be a foolish thing to implement. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Wed Aug 4 05:23: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 399653A67F9; Wed, 4 Aug 2010 05:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.106 X-Spam-Level: * X-Spam-Status: No, score=1.106 tagged_above=-999 required=5 tests=[AWL=0.356, 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 cV1yEDpQtzrA; Wed, 4 Aug 2010 05:23:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B01D3A67B3; Wed, 4 Aug 2010 05:23:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogcwp-000M4V-Gi for namedroppers-data0@psg.com; Wed, 04 Aug 2010 12:19:51 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogcwn-000M47-4F for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 12:19:49 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Ogcwi-0007iY-M7; Wed, 04 Aug 2010 12:19:44 +0000 Received: by bfk.de with local id 1Ogcwi-0006xS-FL; Wed, 04 Aug 2010 12:19:44 +0000 To: Michael StJohns Cc: Phillip Hallam-Baker , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <82y6cn202t.fsf@mid.bfk.de> From: Florian Weimer Date: Wed, 04 Aug 2010 12:19:44 +0000 In-Reply-To: (Michael StJohns's message of "Tue\, 03 Aug 2010 12\:16\:02 -0400") Message-ID: <82ocdi1sf3.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Michael StJohns: > Consider for a moment the email system. It seems to me that it > might be a good idea for an MTA to refuse to deliver email to an MTA > or mail store for which the MX record is bogus. "bogus" in what sense? The DNSSEC sense? This already happens automatically in vendor-default DNSSEC configurations. No protocol or application changes are required. > Or refusing to accept email from a site where the signed PTR record > doesn't point back to a signed and consistent A record. Seems like a bad idea to me because that would reject tons of legitimate mail. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Wed Aug 4 05:31: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 4844F3A6B0A; Wed, 4 Aug 2010 05:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.857 X-Spam-Level: X-Spam-Status: No, score=-0.857 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqI5XXG4Ywxp; Wed, 4 Aug 2010 05:31:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 86C713A69CE; Wed, 4 Aug 2010 05:31:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogd5N-000NRt-Vu for namedroppers-data0@psg.com; Wed, 04 Aug 2010 12:28:42 +0000 Received: from [209.85.213.52] (helo=mail-yw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogd5L-000NRU-CD for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 12:28:39 +0000 Received: by ywa6 with SMTP id 6so2752225ywa.11 for ; Wed, 04 Aug 2010 05:28:38 -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=YBdMP2Vtg8n1QhX5tFR7uOpHYR2zeAzc96COMj4vFCk=; b=O18GdEfX5g65HQncEoMu5GSXQs4cF6otpHgavACqYduP5XkBmxgmRByHyoND2opCkd vuE4dIm0HrRU21sUG9IqFLG0FTdwbKC2xOZRCVKIuVNPKJ+/HHpR++ms1zdhmFlnpFnr iDBYfgUiywSu8CzAujgcy9Tarw2NZziNCeRd0= 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=fNWQDVHsmidyxvTXF13d7QA+AkumincVYtfFispNUDpjRJCuV43JAGjIM2cGkoIr3k EMe+c1kd3urxiRvJKRaL0gLh0I+BSRmCnnHwtwehcgJxmP6K2AC2npHRF377u3Xb0VIJ EOivF9I3Xc9vFztpiPd4sWqW848jz+p9b+R0Y= MIME-Version: 1.0 Received: by 10.150.253.13 with SMTP id a13mr10295076ybi.177.1280924918696; Wed, 04 Aug 2010 05:28:38 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Wed, 4 Aug 2010 05:28:38 -0700 (PDT) In-Reply-To: <1C736AB3-B168-4423-9D4F-1BC2F60540B4@ICSI.Berkeley.EDU> References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <25B407F7-BE9E-4FEB-8FAF-52F482422530@icsi.berkeley.edu> <1C736AB3-B168-4423-9D4F-1BC2F60540B4@ICSI.Berkeley.EDU> Date: Wed, 4 Aug 2010 08:28:38 -0400 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Phillip Hallam-Baker To: Nicholas Weaver Cc: Florian Weimer , Joe Abley , namedroppers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Again, you are assuming that I am going to only limit my design to the fragile ICANN infrastructure. That is not going to be my proposal. On Wed, Aug 4, 2010 at 8:13 AM, Nicholas Weaver wrote: > > On Aug 4, 2010, at 5:07 AM, Phillip Hallam-Baker wrote: > >> Preventing a downgrade attack. >> >> At the moment the biggest hole in SSL is that it is optional and the >> client does not have any in-band method of finding out if it is >> supported. > > > > DNSSEC doesn't help because it suffers from the exact same downgrade atta= cks. =A0Thus unless you have UNIVERSAL signing of DNS data, the in-path att= acker just downgrades DNSSEC first. > > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Wed Aug 4 05:31: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 D8AE53A67E2; Wed, 4 Aug 2010 05:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.355 X-Spam-Level: ** X-Spam-Status: No, score=2.355 tagged_above=-999 required=5 tests=[AWL=-0.995, 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 0ncslmAZ0TSr; Wed, 4 Aug 2010 05:31:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 85A3D3A6B76; Wed, 4 Aug 2010 05:31:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogd62-000NaF-DN for namedroppers-data0@psg.com; Wed, 04 Aug 2010 12:29:22 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogd5z-000NZZ-Pv for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 12:29:20 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Ogd5s-0000WZ-Le; Wed, 04 Aug 2010 12:29:12 +0000 Received: by bfk.de with local id 1Ogd5s-0008S0-HF; Wed, 04 Aug 2010 12:29:12 +0000 To: Alex Bligh Cc: Joe Abley , Phillip Hallam-Baker , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> From: Florian Weimer Date: Wed, 04 Aug 2010 12:29:12 +0000 In-Reply-To: <7143B370CED458C7B8AE6465@Ximines.local> (Alex Bligh's message of "Tue\, 03 Aug 2010 17\:57\:42 +0100") Message-ID: <82k4o61rzb.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Alex Bligh: > Consider a legacy application that calls gethostbyname(), and a > library that supports DNSSEC that attempts a lookup on a name > in a signed zone where the authoritative nameserver concerned > has been compromised and is producing incorrect data (assume > it's signed elsewhere so the key has not been compromised). > My feeling is that it would be useful behaviour if gethostbyname() > returned something other than the incorrect A record. When the zone is secure (in the DNSSEC sense) from the point of view of the resolver, then the legacy application will not receive that A record. > The things one might choose to upgrade to support DNSSEC to achieve > this allegedly useful result are: > 1. Recursive nameserver > 2. Stub resolver > 3. Library > 4. Application > > It would seem a pity if it were necessary to upgrade all four of > these to get it. Updating the recursor is sufficient if you can secure the last mile. And who wants to use a compromised Internet connection, anyway? For many sites, upgrading the resolver cannot be avoided because you typically need NSEC3 support which has become available from vendors only relatively recently (in addition to basic DNSSECbis support). Given that the DNSSEC protocol does not actually prevent cache poisoning, you really, really want to install a superset of your customers' trust anchors (even if that set is not empty) because someone might find a bypass for source port randomization which allows to trivially poison a cache which isn't married to a validator. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Wed Aug 4 06:42: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 D3A643A6978; Wed, 4 Aug 2010 06:42:33 -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 w3u2dzGITabF; Wed, 4 Aug 2010 06:42:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 050183A6836; Wed, 4 Aug 2010 06:42:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgeAB-0008ae-W8 for namedroppers-data0@psg.com; Wed, 04 Aug 2010 13:37:44 +0000 Received: from [2001:a18:1::62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgeA9-0008aI-Pv for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 13:37:42 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 0165B10598 for ; Wed, 4 Aug 2010 15:37:41 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:230:5ff:fefe:537e] (unknown [IPv6:2001:a18:1:8:230:5ff:fefe:537e]) by smtprelay.restena.lu (Postfix) with ESMTP id DB25310594 for ; Wed, 4 Aug 2010 15:37:40 +0200 (CEST) Message-ID: <4C596D24.3060701@restena.lu> Date: Wed, 04 Aug 2010 15:37:40 +0200 From: Gilles Massen Organization: Fondation RESTENA User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> In-Reply-To: <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Jakob Schlyter wrote: > On 3 aug 2010, at 12.48, Basil Dolmatov wrote: > >> In current world DNS-admin in _most_ cases have no connection with >> the domain owner, who is _really_ the target of seeking the trust. >> > > That might be true today, but it does not have to be true tomorrow. I think it's not even true today: there is always a relationship between the DNS admin and the domain name owner, but it can range from loose (e.g. registrar provided DNS) to very strong (same company, same person). It's not that different to the hosting of a website, where the content provider and the webserver operator can have any kind of relationship. Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From owner-namedroppers@ops.ietf.org Wed Aug 4 07:12: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 635753A67D1; Wed, 4 Aug 2010 07:12:55 -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=-0.464, 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 gpCLe7ae651P; Wed, 4 Aug 2010 07:12:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F84D3A6848; Wed, 4 Aug 2010 07:12:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgeeP-000Dqp-1J for namedroppers-data0@psg.com; Wed, 04 Aug 2010 14:08:57 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgeeM-000DqG-Qy for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 14:08:55 +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 o74E8qZT070350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Aug 2010 07:08:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> Date: Wed, 4 Aug 2010 07:08:50 -0700 To: namedroppers From: Paul Hoffman Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications 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:29 AM +0200 8/4/10, Jakob Schlyter wrote: >On 3 aug 2010, at 12.48, Basil Dolmatov wrote: > >> In current world DNS-admin in _most_ cases have no connection with the domain owner, who is _really_ the target of seeking the trust. > >That might be true today, but it does not have to be true tomorrow. When the use of DNS and DNSSEC change, how we administer it needs to change as well. It is not even true today. How could it be? The DNS admin makes the config that tells the world the data associated with the domain name. If the admin can tell the world data such as the A record associated with a domain name, he/she can tell the world the other data as well. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Wed Aug 4 07:17: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 62D503A6B16; Wed, 4 Aug 2010 07:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=-0.301, 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 tmKe5mXoMGdi; Wed, 4 Aug 2010 07:17:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5F95B3A6B05; Wed, 4 Aug 2010 07:17:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgejI-000Ejk-V4 for namedroppers-data0@psg.com; Wed, 04 Aug 2010 14:14:00 +0000 Received: from [74.125.83.180] (helo=mail-pv0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgejG-000EjO-FN for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 14:13:59 +0000 Received: by pvg12 with SMTP id 12so3159317pvg.11 for ; Wed, 04 Aug 2010 07:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=t1ZtOcS9z4vwv+smmyNyuZecERtfqEebt8PclJycSwQ=; b=YOQbsSqYH0mp16zpwMJpQBG0nVYjzaxGKO5ZdR6eWdtlUNZUC8m+zuizjZKWf45xzO o7kaWJw3RvTQ6CmVmDmwfRj5EhuVimddBWHt6pjoYCK3eqdpVOSInI6ltCKdxNTD+QEJ AtJe0Tcg5CuD4giOGdzXF8YU8otzvH7NfOsnM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=C7AwFmtk2I/zX6rHigsCau1IQmaWQs9hoNRz5nVv/J+ykDLAdzqEf7Xlxx6l2mqals 7zYJXBDk/svcZVs72e7LpSMq17a/kzBzHB/MtXs26vA+SYoALPcpf9JRmxKXFJ+awsTS ADEgvxKD2JvbyUnhuD6aSDz7xrRTsupGeniKk= Received: by 10.142.231.14 with SMTP id d14mr7912938wfh.108.1280931238014; Wed, 04 Aug 2010 07:13:58 -0700 (PDT) Received: from [10.0.1.2] (nweaver-airport.icir.org [192.150.187.57]) by mx.google.com with ESMTPS id y16sm10629946wff.14.2010.08.04.07.13.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 07:13:56 -0700 (PDT) Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <1C736AB3-B168-4423-9D4F-1BC2F60540B4@ICSI.Berkeley.EDU> Date: Wed, 4 Aug 2010 07:13:55 -0700 Cc: Phillip Hallam-Baker , Florian Weimer , Joe Abley , namedroppers Content-Transfer-Encoding: quoted-printable Message-Id: References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <25B407F7-BE9E-4FEB-8FAF-52F482422530@icsi.berkeley.edu> <1C736AB3-B168-4423-9D4F-1BC2F60540B4@ICSI.Berkeley.EDU> To: Nicholas Weaver X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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, stupid me, this actually WOULD help prevent downgrades. On Aug 4, 2010, at 5:13 AM, Nicholas Weaver wrote: >=20 > On Aug 4, 2010, at 5:07 AM, Phillip Hallam-Baker wrote: >=20 >> Preventing a downgrade attack. >>=20 >> At the moment the biggest hole in SSL is that it is optional and the >> client does not have any in-band method of finding out if it is >> supported. >=20 >=20 >=20 > DNSSEC doesn't help because it suffers from the exact same downgrade = attacks. Thus unless you have UNIVERSAL signing of DNS data, the = in-path attacker just downgrades DNSSEC first. >=20 >=20 >=20 From owner-namedroppers@ops.ietf.org Wed Aug 4 07:46: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 9D0593A6800; Wed, 4 Aug 2010 07:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[AWL=-1.551, 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 aA7bd+81nbic; Wed, 4 Aug 2010 07:46:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 405DB3A6AE9; Wed, 4 Aug 2010 07:46:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgfAK-000Jcl-ED for namedroppers-data0@psg.com; Wed, 04 Aug 2010 14:41:56 +0000 Received: from [209.85.210.52] (helo=mail-pz0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgfAH-000Jbq-PP for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 14:41:53 +0000 Received: by pzk27 with SMTP id 27so3176320pzk.11 for ; Wed, 04 Aug 2010 07:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Yq8QYFKmbfw/SOp2z01XNrlZfhbj/73Hl//kPA1nRC4=; b=odt/2NDBXVsgnTqYM9tQpN+psUEvXYRPYuYvE3vwPDXdNuxV20+BazLe8ykchvB1bf BPJIQ8pYhfRiITMjTo2FgENpuLJrXfSjfG/hhLgBdHteAVesScq0lpIH+50q5Dpfmv68 YCPvmYymG7njHB2XUxE+sJ+ljOtqeQevxKAJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=hbyNYIa94hyfd99rZBYbinO7hxhDlNKg+KiWIyrqND5v2TvNKvfE+lfDJ6nvlmdyxe HR/pP2+Q4lDXV8iEwSW1IsJDPoz1aLzIjtyChlkouykvjjFFSyZOkAWiwkNyYXgbKo/R J+mM3ORqNbZm2ON0HJV7kHmP2SKwMyJ4BjHck= Received: by 10.142.234.11 with SMTP id g11mr8022267wfh.240.1280932913243; Wed, 04 Aug 2010 07:41:53 -0700 (PDT) Received: from [10.0.1.2] (nweaver-airport.icir.org [192.150.187.57]) by mx.google.com with ESMTPS id w27sm10657041wfd.5.2010.08.04.07.41.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 07:41:51 -0700 (PDT) Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <82k4o61rzb.fsf@mid.bfk.de> Date: Wed, 4 Aug 2010 07:41:49 -0700 Cc: Nicholas Weaver , Alex Bligh , Joe Abley , Phillip Hallam-Baker , namedroppers Content-Transfer-Encoding: quoted-printable Message-Id: References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> To: Florian Weimer X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 4, 2010, at 5:29 AM, Florian Weimer wrote: >> The things one might choose to upgrade to support DNSSEC to achieve >> this allegedly useful result are: >> 1. Recursive nameserver >> 2. Stub resolver >> 3. Library >> 4. Application >>=20 >> It would seem a pity if it were necessary to upgrade all four of >> these to get it. >=20 > Updating the recursor is sufficient if you can secure the last mile. > And who wants to use a compromised Internet connection, anyway? Dear god no! Validating on the recursive resolver ranges between useless and = dangerous. If the recursive resolver just simply reports the validation, its = useless: =20 Our experience with Netalyzr has shown that the recursive resolver can't = be trusted, and is in fact the adversary.=20 We've seen multiple DNS manipulations, ranging from "benign" policy to a = huge amount of NXDOMAIN wildcarding to ISPs which use DNS to = man-in-the-middle user's search requests (yes, MITM of google, yahoo, = and bing, by multiple ISPs, using DNS!) to malcode-set recursive = resolvers that return umm, interesting results for ad.doubleclick.net. I'd rather trust Bernie Madoff to balance his own books than the = recursive resolver to validate DNSSEC. If the recursive resolver acts on the validation, its dangerous: = 99.999% of the DNSSEC failures (if not 100%) will be benign, not = malicious (assuming, of course, that the resolver is properly resistant = to out-of-path adversaries.).=20 Thus any decision to return a SERVFAIL in response to a failure to = validate represents a denial-of-service attack, not a security feature. And the last mile is exactly the MOST insecure part of the network. It = is the last mile (on either end) that you have low volume. That you = have wireless networks. That you have unauthenticated broadcast domains = (ethernet, wireless) where hostile machines are present. In path = adversaries, OTHER than nation-state adversaries or rogue ISPs = advertising bad routes, operate almost exclusively in that last mile on = one side or the other. =20 So its not like you can trust the results returned by the recursive = resolver aren't manipulated during that last hop. Rather, validation must be the exclusive domain of the stub resolver, = libaries, and application if you want DNSSEC to have any meaning at all = beyond an Internet-scale denial of service attack and full employment = act for consultants. =20 If the application is "DNSSEC unaware" (using current APIs), it is only = the stub resolver that needs to do anything: on any failure of DNSSEC = (no trust anchor, bad signature, no DNSSEC information at all), the stub = should conduct its own independent request, bypassing the recursive = resolver, and ACCEPT THE RESULTS of this independent request, = regardless. (This can be optimized by trusting everything from the = recursive resolver that DOES validate, so a cached path, except for the = failure and beyond, could be fetched from the recursive resolver). Now all DNSSEC "failures" become a performance degrader and a load on = the failing authorities, not a DOS. (And this is safe to do!) If the application is "DNSSEC aware" (using APIs which convey DNSSEC = results), then the stub just reports the results of the validation and = leaves it to the application to figure out what to do. >=20 > For many sites, upgrading the resolver cannot be avoided because you > typically need NSEC3 support which has become available from vendors > only relatively recently (in addition to basic DNSSECbis support). > Given that the DNSSEC protocol does not actually prevent cache > poisoning, you really, really want to install a superset of your > customers' trust anchors (even if that set is not empty) because > someone might find a bypass for source port randomization which allows > to trivially poison a cache which isn't married to a validator. As an out of path adversary, you can't "bypass" randomization: with = sufficient entropy, it is the same type of protection you get from = cryptography: mathematical bounds and calculateable amounts of work. If = you are not comfortable with 2^32-2^40th level work for the attacker = (port randomization, randomization + 0x20), the group should adopt = Barwood's EDNS0 ping, which converts it to 2^128th level work. =20 Between good randomization and good glue policy (eliminate all = race-until-win attacks), out of path adversaries are a non-issue for a = well constructed resolver. As an in-path adversary, yes, you can trivially pillage DNS because the = randomization becomes meaningless. But this only matters if the in-path = adversary is NOT on the packet-path for the final traffic, because = applications are either a) Trivially pillaged by the same in-path adversary or b) Not actually trusting DNS, because a DNS manipulation is just = another in-path adversary. From owner-namedroppers@ops.ietf.org Wed Aug 4 07:55: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 269BA3A6B76; Wed, 4 Aug 2010 07:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.32 X-Spam-Level: X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 h-44UDeS+0Vq; Wed, 4 Aug 2010 07:55:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 321963A6B67; Wed, 4 Aug 2010 07:55:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgfLm-000Lzz-1l for namedroppers-data0@psg.com; Wed, 04 Aug 2010 14:53:46 +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.72 (FreeBSD)) (envelope-from ) id 1OgfLi-000LmU-Rb for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 14:53:43 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o74EqMjq018157; Wed, 4 Aug 2010 14:52:22 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o74EqLbh018156; Wed, 4 Aug 2010 14:52:21 GMT Date: Wed, 4 Aug 2010 14:52:21 +0000 From: bmanning@vacation.karoshi.com To: Paul Hoffman Cc: namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: <20100804145221.GA17773@vacation.karoshi.com.> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> 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 Wed, Aug 04, 2010 at 07:08:50AM -0700, Paul Hoffman wrote: > At 9:29 AM +0200 8/4/10, Jakob Schlyter wrote: > >On 3 aug 2010, at 12.48, Basil Dolmatov wrote: > > > >> In current world DNS-admin in _most_ cases have no connection with the domain owner, who is _really_ the target of seeking the trust. > > > >That might be true today, but it does not have to be true tomorrow. When the use of DNS and DNSSEC change, how we administer it needs to change as well. > > It is not even true today. How could it be? The DNS admin makes the config that tells the world the data associated with the domain name. If the admin can tell the world data such as the A record associated with a domain name, he/she can tell the world the other data as well. > > --Paul Hoffman, Director > --VPN Consortium so the DNS admin can tell the world what SSL certs are installed on the target node, what x509 certs are installed, what applications are running on the target node, etc? and why would the world beleive that the DNS admin has any clue as to the configuration and application profile of the target node? --bill From owner-namedroppers@ops.ietf.org Wed Aug 4 08:11: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 7BD573A6B9E; Wed, 4 Aug 2010 08:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.435 X-Spam-Level: X-Spam-Status: No, score=0.435 tagged_above=-999 required=5 tests=[AWL=-0.929, 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 1fnsf73t5MtJ; Wed, 4 Aug 2010 08:11:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 47F8D3A6894; Wed, 4 Aug 2010 08:11:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgfZ1-000OZT-Pm for namedroppers-data0@psg.com; Wed, 04 Aug 2010 15:07:27 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgfYz-000OZ7-1e for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 15:07:25 +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 C6DDCC56938; Wed, 4 Aug 2010 16:07:22 +0100 (BST) Date: Wed, 04 Aug 2010 16:07:22 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Nicholas Weaver , Florian Weimer cc: Nicholas Weaver , Joe Abley , Phillip Hallam-Baker , namedroppers , Alex Bligh Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: <5348CBEC5D77DD4D61E8F3C1@Ximines.local> In-Reply-To: References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 4 August 2010 07:41:49 -0700 Nicholas Weaver wrote: > I'd rather trust Bernie Madoff to balance his own books than the > recursive resolver to validate DNSSEC. +1. This is like hanging your door keys on your gate post. > Rather, validation must be the exclusive domain of the stub resolver, > libaries, [and] application if you want DNSSEC to have any meaning at all > beyond an Internet-scale denial of service attack and full employment act > for consultants. I think the 'and' I put in []s can be "and/or". > If the application is "DNSSEC unaware" (using current APIs), it is only > the stub resolver that needs to do anything: [*] on any failure of DNSSEC (no > trust anchor, bad signature, no DNSSEC information at all), the stub > should conduct its own independent request, bypassing the recursive > resolver, and ACCEPT THE RESULTS of this independent request, regardless. > (This can be optimized by trusting everything from the recursive resolver > that DOES validate, so a cached path, except for the failure and beyond, > could be fetched from the recursive resolver). The stub resolver needs to do something else different before you get to [*], which is issue queries with DO set in response to "DNSSEC unaware" calls (gethostbyname etc.). Inspection suggests this does not happen. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Aug 4 08:39: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 6BEDD3A682F; Wed, 4 Aug 2010 08:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.72 X-Spam-Level: X-Spam-Status: No, score=0.72 tagged_above=-999 required=5 tests=[AWL=-1.830, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAbXpsoL5gF5; Wed, 4 Aug 2010 08:36:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D58D3A65A6; Wed, 4 Aug 2010 08:30:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogfsj-0001TB-JN for namedroppers-data0@psg.com; Wed, 04 Aug 2010 15:27:49 +0000 Received: from [85.17.178.138] (helo=rotring.dds.nl) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogfsh-0001Sk-1f for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 15:27:47 +0000 Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id AF39D580B0 for ; Wed, 4 Aug 2010 17:27:45 +0200 (CEST) Received: from vylkir.localdomain (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 7CE13580AE for ; Wed, 4 Aug 2010 17:27:36 +0200 (CEST) Message-ID: <4C5986E7.4020400@nlnetlabs.nl> Date: Wed, 04 Aug 2010 17:27:35 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Thunderbird/3.1.1 MIME-Version: 1.0 To: Namedroppers Subject: [dnsext] algorithm rollover X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.1 at rotring X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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, Key algorithm rollover needs to be described better. In 4641-bis, on introducing a new algorithm, removing an algorithm, and removing an algorithm with Revoke. In dnssecbis-updates, that revoked keys can sign not only the DNSKEY set they are in, but are also allowed to sign the entire zone contents for backwards compatibility with non-5011 validators when removing an algorithm [or some other specific delineation what revoked keys can and can not sign]. And text that RRSIGs MUST exist for a key that is not in the DNSKEY rrset during such algorithm changes: a zone MAY contain RRSIG's for an DNSKEY that does not exist in the DNSKEY RRset. * introducing a new algorithm. 1) add signatures on entire zone with algorithm 2) publish ZSK for the algorithm 3) publish KSK for the algorithm 4) publish DS for the algorithm. With TTL waits between steps. * removing an algorithm 1) remove DS for the algorithm 2) remove KSK for the algorithm 3) remove ZSK for the algorithm 4) remove signatures on the entire zone for the algorithm With TTL waits between steps. * removing an algorithm with 5011-REVOKE for KSK. 1) remove DS for the algorithm 2) publish KSK with REVOKE flag. 3) remove KSK for the algorithm 4) remove ZSK for the algorithm 5) remove signatures on the entire zone for the algorithm With TTL waits between steps. Other options for removal of an algorithm are * Go MISSING. use the steps for removal without the REVOKE publish step. The key goes into 5011-MISSING state. And is removed after a time (180 or 366 days or so). This may be an alternative for non ZSK-KSK split zones, since they want things easy, and this is easy. * Sign the entire zone with the removed KSK while it is REVOKED as well. Some find this distasteful, but really, it is only a DNSKEY flag, just like the SEP flag and carries meaning only to operators. If you have a ZSK/KSK split you do not have to do this. Alternatively, for this a spec-change can be made that such 5011 revocations should be looked for by validators for any zone (not just for trust-anchors), and revocations handled somehow. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxZhucACgkQkDLqNwOhpPi4EgCfYDFKcSRQ/PZ4eMBsAuaYvK64 uAIAoJ6GEaOgEFw5IMQtNmzRLdpTyw5r =/HG5 -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Wed Aug 4 08:39: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 886AF3A6990; Wed, 4 Aug 2010 08:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.206 X-Spam-Level: X-Spam-Status: No, score=-0.206 tagged_above=-999 required=5 tests=[AWL=0.289, 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 Gbct4vBCdNLP; Wed, 4 Aug 2010 08:39:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 37AD53A6BAC; Wed, 4 Aug 2010 08:36:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogfw6-0001xP-H1 for namedroppers-data0@psg.com; Wed, 04 Aug 2010 15:31:18 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogfw4-0001wx-8S for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 15:31:16 +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 o74FVDrI075697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Aug 2010 08:31:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100804145221.GA17773@vacation.karoshi.com.> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> Date: Wed, 4 Aug 2010 08:31:12 -0700 To: bmanning@vacation.karoshi.com From: Paul Hoffman Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Cc: namedroppers 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 2:52 PM +0000 8/4/10, bmanning@vacation.karoshi.com wrote: >On Wed, Aug 04, 2010 at 07:08:50AM -0700, Paul Hoffman wrote: >> At 9:29 AM +0200 8/4/10, Jakob Schlyter wrote: >> >On 3 aug 2010, at 12.48, Basil Dolmatov wrote: >> > >> >> In current world DNS-admin in _most_ cases have no connection with the domain owner, who is _really_ the target of seeking the trust. >> > >> >That might be true today, but it does not have to be true tomorrow. When the use of DNS and DNSSEC change, how we administer it needs to change as well. >> >> It is not even true today. How could it be? The DNS admin makes the config that tells the world the data associated with the domain name. If the admin can tell the world data such as the A record associated with a domain name, he/she can tell the world the other data as well. >> >> --Paul Hoffman, Director >> --VPN Consortium > > so the DNS admin can tell the world what SSL certs are installed on the target node, > what x509 certs are installed, what applications are running on the target node, etc? If there are standards for that, sure. Of course, there aren't, because you (I assume purposely) picked examples of things that discoverable through normal means. But if the IETF wants to define a DNS record that tells the world that, sure. > and why would the world beleive that the DNS admin has any clue as to the configuration > and application profile of the target node? In your currently-unsupported examples, they would believe it because there was a standard for it. But, of course, there are no such DNS records, so this is probably not a fruitful exercise. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Wed Aug 4 08:59: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 EB5D63A6BB9; Wed, 4 Aug 2010 08:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 Yg2kxwStcrUo; Wed, 4 Aug 2010 08:59:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E273828C0DB; Wed, 4 Aug 2010 08:59:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OggJB-0005sY-ID for namedroppers-data0@psg.com; Wed, 04 Aug 2010 15:55:09 +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.72 (FreeBSD)) (envelope-from ) id 1OggJ9-0005ge-AN for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 15:55:07 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o74Frkjq018673; Wed, 4 Aug 2010 15:53:46 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o74FrjQe018672; Wed, 4 Aug 2010 15:53:45 GMT Date: Wed, 4 Aug 2010 15:53:45 +0000 From: bmanning@vacation.karoshi.com To: Paul Hoffman Cc: bmanning@vacation.karoshi.com, namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: <20100804155345.GA18609@vacation.karoshi.com.> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.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 Wed, Aug 04, 2010 at 08:31:12AM -0700, Paul Hoffman wrote: > At 2:52 PM +0000 8/4/10, bmanning@vacation.karoshi.com wrote: > >On Wed, Aug 04, 2010 at 07:08:50AM -0700, Paul Hoffman wrote: > >> At 9:29 AM +0200 8/4/10, Jakob Schlyter wrote: > >> >On 3 aug 2010, at 12.48, Basil Dolmatov wrote: > >> > > >> >> In current world DNS-admin in _most_ cases have no connection with the domain owner, who is _really_ the target of seeking the trust. > >> > > >> >That might be true today, but it does not have to be true tomorrow. When the use of DNS and DNSSEC change, how we administer it needs to change as well. > >> > >> It is not even true today. How could it be? The DNS admin makes the config that tells the world the data associated with the domain name. If the admin can tell the world data such as the A record associated with a domain name, he/she can tell the world the other data as well. > >> > >> --Paul Hoffman, Director > >> --VPN Consortium > > > > so the DNS admin can tell the world what SSL certs are installed on the target node, > > what x509 certs are installed, what applications are running on the target node, etc? > > If there are standards for that, sure. Of course, there aren't, because you (I assume purposely) picked examples of things that discoverable through normal means. But if the IETF wants to define a DNS record that tells the world that, sure. > > > and why would the world beleive that the DNS admin has any clue as to the configuration > > and application profile of the target node? > > In your currently-unsupported examples, they would believe it because there was a standard for it. But, of course, there are no such DNS records, so this is probably not a fruitful exercise. ah, but there -were- IETF standards for such foolishness (granted, back before DNSSEC) that were deemed totally broken, since the DNS admin and the host admin were almost never the same person. Ref: HINFO RRs. i.e. what is the fundamental difference between a DNS RR that says: box.example.net in a 169.254.0.13 in hinfo httpd and box.example.net in a 169.254.0.13 in sslcert "hex-string" in neither case does the admin of the domain example.net really have any clue what is supposed to be running on node "box". Or does she? and if so, how? --bill > > --Paul Hoffman, Director > --VPN Consortium From owner-namedroppers@ops.ietf.org Wed Aug 4 09:10: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 67FD33A6A15; Wed, 4 Aug 2010 09:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.193 X-Spam-Level: X-Spam-Status: No, score=-101.193 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 kF4Zq4GEKuuh; Wed, 4 Aug 2010 09:10:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7441E28C0E6; Wed, 4 Aug 2010 09:10:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OggVJ-0007oy-Ij for namedroppers-data0@psg.com; Wed, 04 Aug 2010 16:07:41 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OggVH-0007oW-9Q for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 16:07:39 +0000 Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o74G7K0A090241; Wed, 4 Aug 2010 12:07:20 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4C599036.5030203@ogud.com> Date: Wed, 04 Aug 2010 12:07:18 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Mark Andrews CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-andrews-dnsext-multi-match-label-00 References: <201007300944.o6U9iHnI036521@drugs.dv.isc.org> <4F591391-AE08-46C6-ACD5-B0FDBA53A43B@hopcount.ca> <201008030359.o733xYMj020732@drugs.dv.isc.org> In-Reply-To: <201008030359.o733xYMj020732@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: This draft ignores the main lesson from bit labels fiasco: No new label type is useful until the whole installed base is updated to support it. EDNSx version change does not work as EDNS is only hop by hop and the problems are going to show up in the middle rather than at the edges. This is the main reason why edns0-bis is closing the label type registry. Olafur On 02/08/2010 11:59 PM, Mark Andrews wrote: > In message<4F591391-AE08-46C6-ACD5-B0FDBA53A43B@hopcount.ca>, Joe Abley writes > : >> Mark, >> >> On 2010-07-30, at 11:44, Mark Andrews wrote: >> >>> FYI >> >> Am I reading this correctly: your idea requires clients to support EDNS1? >> >> >> Joe > > It requires signaling between the client and server. Bumping the EDNS > version is a reasonable way to do that. > From owner-namedroppers@ops.ietf.org Wed Aug 4 09:16: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 908E73A6826; Wed, 4 Aug 2010 09:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.217 X-Spam-Level: X-Spam-Status: No, score=-105.217 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 gCQEkzL3JLkX; Wed, 4 Aug 2010 09:16:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C2E273A6A28; Wed, 4 Aug 2010 09:16:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OggbB-0008sx-CW for namedroppers-data0@psg.com; Wed, 04 Aug 2010 16:13:45 +0000 Received: from [64.18.2.22] (helo=exprod7og122.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oggb8-0008sL-QD for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 16:13:43 +0000 Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTFmRsvoZoMXbi/bh5fiqGUpQQscZ1ZtS@postini.com; Wed, 04 Aug 2010 09:13:42 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D2AF21B88C1; Wed, 4 Aug 2010 09:13:37 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 4 Aug 2010 09:13:37 -0700 Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <20100804155345.GA18609@vacation.karoshi.com.> Date: Wed, 4 Aug 2010 12:13:33 -0400 CC: namedroppers Content-Transfer-Encoding: quoted-printable Message-ID: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> To: X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 4, 2010, at 11:53 AM, = wrote: > i.e. what is the fundamental difference between a DNS RR that = says: >=20 > box.example.net in a 169.254.0.13 > in hinfo httpd >=20 > and >=20 > box.example.net in a 169.254.0.13 > in sslcert "hex-string" The difference is that in the first instance, we are clearly relying on = some mechanism other than DNSSEC to validate the cert for the http = server at box.example.net. In the latter case, we are relying solely = on DNSSEC. This makes DNSSEC a very juicy target for attack. In the = former case, attacking DNSSEC doesn't get you very much, but in the = latter case, it allows you to impersonate the http server. So to me the question you've raised leads to this: how much work are you = willing to do to keep your own DNS server secure, and how much cash = money are you willing to bet that the root is secure enough to make = monetary transactions safe? Because that's the bet you're making. = And while I applaud the folks running the root zone for their very well = thought-out security protocol, I think putting this kind of pressure on = the root key and all the keys down to your own domain is not something = we've budgeted for. If what you are proposing is that the SSL cert in the DNS be a = *confirmation* of the validity of an SSL cert that's also been signed by = a known CA, I think that's a different story, and if that is what you = were proposing, then I don't think my objection is important. I've = only just started following this conversation, so I may have missed = something. From owner-namedroppers@ops.ietf.org Wed Aug 4 09:27: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 AEE083A6966; Wed, 4 Aug 2010 09:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.211 X-Spam-Level: X-Spam-Status: No, score=-100.211 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 XKdru2BouhB9; Wed, 4 Aug 2010 09:27:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B40BE3A6961; Wed, 4 Aug 2010 09:27:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OggmK-000ARv-Tu for namedroppers-data0@psg.com; Wed, 04 Aug 2010 16:25:16 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OggmI-000ARR-Jd for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 16:25:14 +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 o74GPBUC079232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Aug 2010 09:25:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100804155345.GA18609@vacation.karoshi.com.> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> Date: Wed, 4 Aug 2010 09:25:10 -0700 To: bmanning@vacation.karoshi.com From: Paul Hoffman Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Cc: namedroppers Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 3:53 PM +0000 8/4/10, bmanning@vacation.karoshi.com wrote: >On Wed, Aug 04, 2010 at 08:31:12AM -0700, Paul Hoffman wrote: > > In your currently-unsupported examples, they would believe it because there was a standard for it. But, of course, there are no such DNS records, so this is probably not a fruitful exercise. > > > ah, but there -were- IETF standards for such foolishness (granted, back before > DNSSEC) that were deemed totally broken, since the DNS admin and the host admin > were almost never the same person. > > Ref: HINFO RRs. > > > i.e. what is the fundamental difference between a DNS RR that says: > > box.example.net in a 169.254.0.13 > in hinfo httpd Errr, that's not the lame usage that is standardized in RFC 1035. RFC 1035 says: HINFO records are used to acquire general information about a host. The main use is for protocols such as FTP that can use special procedures when talking between machines or operating systems of the same type. What RRTYPE were you thinking of when you wrote the above? > > and > > box.example.net in a 169.254.0.13 > in sslcert "hex-string" There is no fundamental difference. A host administrator tells the DNS administrator "I have a host I want called box.example.net. It is configured to respond at 169.254.0.13. Further, it has the following features that I believe there are DNS RRTYPES for: ...". > in neither case does the admin of the domain example.net really have any clue > what is supposed to be running on node "box". Or does she? and if so, how? OOB communication. To turn your question around: how did the DNS admin find out that box.example.net is configured to respond on 169.254.0.13? --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Wed Aug 4 09:32: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 47E173A69E3; Wed, 4 Aug 2010 09:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[AWL=-0.465, 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 FYtqcx0bIq+z; Wed, 4 Aug 2010 09:32:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 36B3D3A6948; Wed, 4 Aug 2010 09:32:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oggqn-000BC0-Tu for namedroppers-data0@psg.com; Wed, 04 Aug 2010 16:29:53 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oggql-000BBN-JC for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 16:29:51 +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 0AF03C56934; Wed, 4 Aug 2010 17:29:49 +0100 (BST) Date: Wed, 04 Aug 2010 17:29:49 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ted Lemon , bmanning@vacation.karoshi.com cc: namedroppers , Alex Bligh Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> In-Reply-To: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.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 4 August 2010 12:13:33 -0400 Ted Lemon wrote: > So to me the question you've raised leads to this: how much work are you > willing to do to keep your own DNS server secure, and how much cash money > are you willing to bet that the root is secure enough to make monetary > transactions safe? Because that's the bet you're making. And while I > applaud the folks running the root zone for their very well thought-out > security protocol, I think putting this kind of pressure on the root key > and all the keys down to your own domain is not something we've budgeted > for. As most SSL certificates are only domain validated, all an SSL certiticate does is tell you that at some point in the past few years, the person in possession of the certificate probably had control over the DNS for that name (actually being able to spoof DNS and/or intercept email to the domain is sometimes enough). I don't see why it's fundamentally more risky to go straight to the DNS. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Aug 4 09:45: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 450403A6990; Wed, 4 Aug 2010 09:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 X5Fs0rOq2KTy; Wed, 4 Aug 2010 09:45:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0EC103A69FB; Wed, 4 Aug 2010 09:45:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogh2B-000Cs8-OQ for namedroppers-data0@psg.com; Wed, 04 Aug 2010 16:41:39 +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.72 (FreeBSD)) (envelope-from ) id 1Ogh29-000Cg0-G0 for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 16:41: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 o74GeBjq019012; Wed, 4 Aug 2010 16:40:11 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o74GeBPe019011; Wed, 4 Aug 2010 16:40:11 GMT Date: Wed, 4 Aug 2010 16:40:11 +0000 From: bmanning@vacation.karoshi.com To: Paul Hoffman Cc: bmanning@vacation.karoshi.com, namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: <20100804164011.GB18609@vacation.karoshi.com.> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.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 Wed, Aug 04, 2010 at 09:25:10AM -0700, Paul Hoffman wrote: > > > > box.example.net in a 169.254.0.13 > > in sslcert "hex-string" > > There is no fundamental difference. A host administrator tells the DNS administrator "I have a host I want called box.example.net. It is configured to respond at 169.254.0.13. Further, it has the following features that I believe there are DNS RRTYPES for: ...". right. 'cept in my current home case, the DHCP server hands out the IP (IPv6) address and dynamically updates the DNS. :) Sounds like more DHCP options to me... the DNSSEC tools then sign the whole zone (per the DNSSEC spec). other, non-DNS data has to come in via an OOB method to the DNS admin. > > > in neither case does the admin of the domain example.net really have any clue > > what is supposed to be running on node "box". Or does she? and if so, how? > > OOB communication. To turn your question around: how did the DNS admin find out that box.example.net is configured to respond on 169.254.0.13? bingo! see above. DNS data, data about the DNS is passed into/through the DNS. non-DNS data has to come via OOB methods. WHEN oob communications break down, then there is a transitive trust problem. e.g. student body turnover on a college campus. campus IT will hand out DNS data and (via DHCP) things like NTP and DNS servers, default routers, etc. there is little to no method to collect (in the USC case) host specific information from the 17,000 undergrads each quarter. This is the primary problem with using the DNS to store non-DNS related data. > > --Paul Hoffman, Director > --VPN Consortium From owner-namedroppers@ops.ietf.org Wed Aug 4 09:51: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 A1B563A685B; Wed, 4 Aug 2010 09:51:25 -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 lIt-7ADdjsYI; Wed, 4 Aug 2010 09:51:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC4E63A6A66; Wed, 4 Aug 2010 09:51:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogh7o-000Dk2-Aa for namedroppers-data0@psg.com; Wed, 04 Aug 2010 16:47:28 +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.72 (FreeBSD)) (envelope-from ) id 1Ogh7l-000Dhw-U7 for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 16:47:26 +0000 Received: from [199.212.90.17] (helo=dh17.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ogh7N-000Pcy-1M; Wed, 04 Aug 2010 16:47:01 +0000 Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <20100804155345.GA18609@vacation.karoshi.com.> Date: Wed, 4 Aug 2010 12:46:59 -0400 Cc: Paul Hoffman , namedroppers Content-Transfer-Encoding: quoted-printable Message-Id: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1081) X-SA-Exim-Connect-IP: 199.212.90.17 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-08-04, at 11:53, bmanning@vacation.karoshi.com wrote: > i.e. what is the fundamental difference between a DNS RR that = says: >=20 > box.example.net in a 169.254.0.13 > in hinfo httpd >=20 > and >=20 > box.example.net in a 169.254.0.13 > in sslcert "hex-string" >=20 >=20 > in neither case does the admin of the domain example.net really = have any clue > what is supposed to be running on node "box". Or does she? and = if so, how? I continue to be confused by this. If your argument is that you cannot rely upon DNS administrators to know = what information to publish in the DNS with respect to applications run = on infrastructure maintained by other people, then there's an obvious = counter-example which you even helpfully include in your own message, = above: the address (A/AAAA) record. Joe= From owner-namedroppers@ops.ietf.org Wed Aug 4 10:04: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 395F328C0D0; Wed, 4 Aug 2010 10:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.096 X-Spam-Level: X-Spam-Status: No, score=-101.096 tagged_above=-999 required=5 tests=[AWL=-1.097, 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 TkEwmgjYd2pG; Wed, 4 Aug 2010 10:04:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C718E3A6A7D; Wed, 4 Aug 2010 10:04:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OghJn-000Fnz-ER for namedroppers-data0@psg.com; Wed, 04 Aug 2010 16:59:51 +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.72 (FreeBSD)) (envelope-from ) id 1OghJk-000FaG-Pk for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 16:59:48 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o74Guujq019188; Wed, 4 Aug 2010 16:56:56 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o74Gutj4019186; Wed, 4 Aug 2010 16:56:55 GMT Date: Wed, 4 Aug 2010 16:56:55 +0000 From: bmanning@vacation.karoshi.com To: Nicholas Weaver Cc: Florian Weimer , Alex Bligh , Joe Abley , Phillip Hallam-Baker , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: <20100804165655.GC18609@vacation.karoshi.com.> References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> 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 Wed, Aug 04, 2010 at 07:41:49AM -0700, Nicholas Weaver wrote: > > On Aug 4, 2010, at 5:29 AM, Florian Weimer wrote: > >> The things one might choose to upgrade to support DNSSEC to achieve > >> this allegedly useful result are: > >> 1. Recursive nameserver > >> 2. Stub resolver > >> 3. Library > >> 4. Application > >> > >> It would seem a pity if it were necessary to upgrade all four of > >> these to get it. > > > > Updating the recursor is sufficient if you can secure the last mile. > > And who wants to use a compromised Internet connection, anyway? > > Dear god no! > > Validating on the recursive resolver ranges between useless and dangerous. > > If the recursive resolver just simply reports the validation, its useless: > > Our experience with Netalyzr has shown that the recursive resolver can't be trusted, and is in fact the adversary. > > We've seen multiple DNS manipulations, ranging from "benign" policy to a huge amount of NXDOMAIN wildcarding to ISPs which use DNS to man-in-the-middle user's search requests (yes, MITM of google, yahoo, and bing, by multiple ISPs, using DNS!) to malcode-set recursive resolvers that return umm, interesting results for ad.doubleclick.net. > > I'd rather trust Bernie Madoff to balance his own books than the recursive resolver to validate DNSSEC. > > > If the recursive resolver acts on the validation, its dangerous: 99.999% of the DNSSEC failures (if not 100%) will be benign, not malicious (assuming, of course, that the resolver is properly resistant to out-of-path adversaries.). > > Thus any decision to return a SERVFAIL in response to a failure to validate represents a denial-of-service attack, not a security feature. > > > > And the last mile is exactly the MOST insecure part of the network. It is the last mile (on either end) that you have low volume. That you have wireless networks. That you have unauthenticated broadcast domains (ethernet, wireless) where hostile machines are present. In path adversaries, OTHER than nation-state adversaries or rogue ISPs advertising bad routes, operate almost exclusively in that last mile on one side or the other. > > So its not like you can trust the results returned by the recursive resolver aren't manipulated during that last hop. > > > > Rather, validation must be the exclusive domain of the stub resolver, libaries, and application if you want DNSSEC to have any meaning at all beyond an Internet-scale denial of service attack and full employment act for consultants. > > > If the application is "DNSSEC unaware" (using current APIs), it is only the stub resolver that needs to do anything: on any failure of DNSSEC (no trust anchor, bad signature, no DNSSEC information at all), the stub should conduct its own independent request, bypassing the recursive resolver, and ACCEPT THE RESULTS of this independent request, regardless. (This can be optimized by trusting everything from the recursive resolver that DOES validate, so a cached path, except for the failure and beyond, could be fetched from the recursive resolver). > > > Now all DNSSEC "failures" become a performance degrader and a load on the failing authorities, not a DOS. (And this is safe to do!) > > > If the application is "DNSSEC aware" (using APIs which convey DNSSEC results), then the stub just reports the results of the validation and leaves it to the application to figure out what to do. > > > > > > For many sites, upgrading the resolver cannot be avoided because you > > typically need NSEC3 support which has become available from vendors > > only relatively recently (in addition to basic DNSSECbis support). > > Given that the DNSSEC protocol does not actually prevent cache > > poisoning, you really, really want to install a superset of your > > customers' trust anchors (even if that set is not empty) because > > someone might find a bypass for source port randomization which allows > > to trivially poison a cache which isn't married to a validator. > > As an out of path adversary, you can't "bypass" randomization: with sufficient entropy, it is the same type of protection you get from cryptography: mathematical bounds and calculateable amounts of work. If you are not comfortable with 2^32-2^40th level work for the attacker (port randomization, randomization + 0x20), the group should adopt Barwood's EDNS0 ping, which converts it to 2^128th level work. > > Between good randomization and good glue policy (eliminate all race-until-win attacks), out of path adversaries are a non-issue for a well constructed resolver. > > > As an in-path adversary, yes, you can trivially pillage DNS because the randomization becomes meaningless. But this only matters if the in-path adversary is NOT on the packet-path for the final traffic, because applications are either > > a) Trivially pillaged by the same in-path adversary > or > b) Not actually trusting DNS, because a DNS manipulation is just another in-path adversary. > > tell us how you really feel about intermediate validation :) there are some cases where I can see that there is not enough resource in the node to run its own validation, but there is enough to run a stub resolver... but those are not the norm. --bill From owner-namedroppers@ops.ietf.org Wed Aug 4 10:04: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 5C64F3A6A89; Wed, 4 Aug 2010 10:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[AWL=-1.621, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_32=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 aotdRajH3SP6; Wed, 4 Aug 2010 10:04:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C98573A68B8; Wed, 4 Aug 2010 10:04:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OghJF-000FiX-3p for namedroppers-data0@psg.com; Wed, 04 Aug 2010 16:59:17 +0000 Received: from [74.125.83.52] (helo=mail-gw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OghJC-000Fi2-7l for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 16:59:14 +0000 Received: by gwj20 with SMTP id 20so2977841gwj.11 for ; Wed, 04 Aug 2010 09:59:13 -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=ngucnlRvwZKctNYgZCY+5p/mC6PjVYfcG0RtG7ioTiQ=; b=fYPixJgWl8P6B60XRuj/H/DFdaCF+CIzNcaHRdi9hJIQidG/grqB1dfOUtPS/Pf2C5 FY4Hfrj5fbXqBbSbyteAeqzuG/SOZ8T4D53Uil2djHNHVfgJntqaPMVlhU8smojl6WE6 wvgr5M2ax0E94G0cx8bc0F11hurd9N+fzJ3pw= 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=ZH6/WJycoOtnNnSBPgd3lVVAfuiGdrwA0cFo/es8dJlyxwut/zp3axFt1u/XJsWYlR nAJQqyR2DWg43FjAa2mw9OrPEYtt1sg29zngmCxr25k+1RCvGPx+W2HD4KKSrDWo2Wbc 1Jhng7spx1Nc83pwVUVHQm9xL8ZFsN21YdDUg= MIME-Version: 1.0 Received: by 10.231.160.17 with SMTP id l17mr10696653ibx.102.1280941153422; Wed, 04 Aug 2010 09:59:13 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Wed, 4 Aug 2010 09:59:13 -0700 (PDT) In-Reply-To: <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> Date: Wed, 4 Aug 2010 12:59:13 -0400 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Phillip Hallam-Baker To: Alex Bligh Cc: Ted Lemon , bmanning@vacation.karoshi.com, namedroppers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: It depends on how you do it. 1) Straight DNSSEC giving you only a signed A record has absolutely no security value. All that is achieved is diverting attacks from the DNS to the BGP. 2) Augmented DNSSEC with a certificate that is accredited via a CERT or CERTHASH RR provides end to end cryptography with a very weak trust chain. 3) Augmented DNSSEC with a certificate accredited as above plus a DV trust chain accreditation for the DNSSEC Key Signing Key gives you end to end cryptographic security with an endpoint that is as trustworthy as their domain name. 4) Augmented DNSSEC with a certificate accredited as above plus an EV trust chain accreditation for the DNSSEC Key Signing Key allows greater security than is possible with either DNSSEC alone or SSL+EV alone. >From an apps point of view, #1 is really undesirable. #2 is desirable in that it allows us to make it possible to turn on strong encryption to a weakly trustworthy key at no cost. That in turn means that we can start using browsers, web servers and email where security is the default. This is what I think most people who complain about CAs really want. What you can't do with that level of security is to tell the user that it is safe to give the site your credit card because the other end of the connection is trustworthy. You have a secure tunnel to an untrustworthy endpoint. So please do not think about turning on the padlock icon. Looking at this as a CA (ob Disclosure, I am now VP & PS at Comodo Inc.), I am not at all concerned about this. Once someone is using strong crypto with weakly accredited keys, it is much easier to persuade them of the value of getting their key strongly accredited. The value that the CA brings to the table here is that we say 'that guy you are going to do business with is accountable'. And that is why I started EV certs with Comodo when I was working for another CA. Please try to understand the value proposition we bring to the table before you assume that DNSSEC is useless or will replace the need for us or whatever. The common ground here is that we all want to make #2 happen. But lets do that in a way that also enables #3 and #4. Because then instead of a stupid and unproductive standards war between PKI and DNSSEC (one that DNSSEC will lose), we can combine the strengths of both and go on to do what we should have done in the first place. On Wed, Aug 4, 2010 at 12:29 PM, Alex Bligh wrote: > > > --On 4 August 2010 12:13:33 -0400 Ted Lemon wrote= : > >> So to me the question you've raised leads to this: how much work are you >> willing to do to keep your own DNS server secure, and how much cash mone= y >> are you willing to bet that the root is secure enough to make monetary >> transactions safe? =A0 Because that's the bet you're making. =A0 And whi= le I >> applaud the folks running the root zone for their very well thought-out >> security protocol, I think putting this kind of pressure on the root key >> and all the keys down to your own domain is not something we've budgeted >> for. > > As most SSL certificates are only domain validated, all an SSL certiticat= e > does is tell you that at some point in the past few years, the person > in possession of the certificate probably had control over the DNS for > that name (actually being able to spoof DNS and/or intercept email > to the domain is sometimes enough). > > I don't see why it's fundamentally more risky to go straight to the > DNS. > > -- > Alex Bligh > > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Wed Aug 4 10:19: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 330003A6A00; Wed, 4 Aug 2010 10:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.216 X-Spam-Level: X-Spam-Status: No, score=-100.216 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 cnM+W+AEYWOx; Wed, 4 Aug 2010 10:19:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC4AA3A67E6; Wed, 4 Aug 2010 10:19:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogha3-000IYa-4S for namedroppers-data0@psg.com; Wed, 04 Aug 2010 17:16:39 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogha0-000IX5-Mi for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 17:16:36 +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 o74HGYIH082607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Aug 2010 10:16:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100804164011.GB18609@vacation.karoshi.com.> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <20100804164011.GB18609@vacation.karoshi.com.> Date: Wed, 4 Aug 2010 10:16:33 -0700 To: bmanning@vacation.karoshi.com From: Paul Hoffman Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Cc: bmanning@vacation.karoshi.com, namedroppers Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 4:40 PM +0000 8/4/10, bmanning@vacation.karoshi.com wrote: >On Wed, Aug 04, 2010 at 09:25:10AM -0700, Paul Hoffman wrote: >> > >> > box.example.net in a 169.254.0.13 >> > in sslcert "hex-string" >> >> There is no fundamental difference. A host administrator tells the DNS administrator "I have a host I want called box.example.net. It is configured to respond at 169.254.0.13. Further, it has the following features that I believe there are DNS RRTYPES for: ...". > > right. 'cept in my current home case, the DHCP server hands out the IP (IPv6) address > and dynamically updates the DNS. :) Sounds like more DHCP options to me... Could be, sure. However, in the real world, many servers that run TLS don't get their addresses from DHCP: they are manually configured. The server admins tell the DNS admin the relevant information about their box. > > OOB communication. To turn your question around: how did the DNS admin find out that box.example.net is configured to respond on 169.254.0.13? > > > bingo! see above. DNS data, data about the DNS is passed into/through the DNS. > non-DNS data has to come via OOB methods. WHEN oob communications break down, > then there is a transitive trust problem. The same is true when DHCP communication break down. > > e.g. student body turnover on a college campus. campus IT will hand out DNS data > and (via DHCP) things like NTP and DNS servers, default routers, etc. > > there is little to no method to collect (in the USC case) host specific information > from the 17,000 undergrads each quarter. > > This is the primary problem with using the DNS to store non-DNS related data. That last line is a non sequitur. It is not the type of information that seems to be your problem: it is the source of it. As you say above, there could be a DHCP option to fill in "non-DNS related data" at the same time as the A record is filled in. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Wed Aug 4 10:47: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 D15183A657C; Wed, 4 Aug 2010 10:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.305 X-Spam-Level: X-Spam-Status: No, score=-102.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 Plctdg1op-bv; Wed, 4 Aug 2010 10:47:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3CB903A67E6; Wed, 4 Aug 2010 10:47:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogi06-000Mys-Oh for namedroppers-data0@psg.com; Wed, 04 Aug 2010 17:43:34 +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.72 (FreeBSD)) (envelope-from ) id 1Ogi04-000MnG-F4 for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 17:43:32 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o74HgBjq019526; Wed, 4 Aug 2010 17:42:11 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o74Hg6W8019522; Wed, 4 Aug 2010 17:42:06 GMT Date: Wed, 4 Aug 2010 17:42:06 +0000 From: bmanning@vacation.karoshi.com To: Paul Hoffman Cc: bmanning@vacation.karoshi.com, namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: <20100804174206.GE18609@vacation.karoshi.com.> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <20100804164011.GB18609@vacation.karoshi.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 Wed, Aug 04, 2010 at 10:16:33AM -0700, Paul Hoffman wrote: > At 4:40 PM +0000 8/4/10, bmanning@vacation.karoshi.com wrote: > >On Wed, Aug 04, 2010 at 09:25:10AM -0700, Paul Hoffman wrote: > >> > > >> > box.example.net in a 169.254.0.13 > >> > in sslcert "hex-string" > >> > >> There is no fundamental difference. A host administrator tells the DNS administrator "I have a host I want called box.example.net. It is configured to respond at 169.254.0.13. Further, it has the following features that I believe there are DNS RRTYPES for: ...". > > > > right. 'cept in my current home case, the DHCP server hands out the IP (IPv6) address > > and dynamically updates the DNS. :) Sounds like more DHCP options to me... > > Could be, sure. However, in the real world, many servers that run TLS don't get their addresses from DHCP: they are manually configured. The server admins tell the DNS admin the relevant information about their box. apparently we inhabit differnet "real" worlds :) > > e.g. student body turnover on a college campus. campus IT will hand out DNS data > > and (via DHCP) things like NTP and DNS servers, default routers, etc. > > > > there is little to no method to collect (in the USC case) host specific information > > from the 17,000 undergrads each quarter. > > > > This is the primary problem with using the DNS to store non-DNS related data. > > That last line is a non sequitur. It is not the type of information that seems to be your problem: it is the source of it. As you say above, there could be a DHCP option to fill in "non-DNS related data" at the same time as the A record is filled in. Ok.. so I was making the distinction between data used by the DNS (as an application) and data used by non-DNS applications. The DNS protocol does pretty well moving/passing DNS related data around - esp given thatthe target of the data is the DNS. Using the DNS for NON-DNS applications seems a bit specious, since there will be constant debate about who has to talk to whom about coordinating what needs to happen when - OUTSIDE the DNS protocol. Argues for either: pushing DNS administration to the host admin or pushing system administration to the DNS admin > > --Paul Hoffman, Director > --VPN Consortium From owner-namedroppers@ops.ietf.org Wed Aug 4 11:07: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 A2DA43A63EC; Wed, 4 Aug 2010 11:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.125 X-Spam-Level: X-Spam-Status: No, score=0.125 tagged_above=-999 required=5 tests=[AWL=0.620, 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 EmCxN73tWTHK; Wed, 4 Aug 2010 11:07:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C78313A6A1C; Wed, 4 Aug 2010 11:07:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgiJI-0000Hq-PD for namedroppers-data0@psg.com; Wed, 04 Aug 2010 18:03:24 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgiJF-0000HC-Vs for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 18:03:22 +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 68C07C56938; Wed, 4 Aug 2010 19:03:19 +0100 (BST) Date: Wed, 04 Aug 2010 19:03:18 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Phillip Hallam-Baker cc: Ted Lemon , bmanning@vacation.karoshi.com, namedroppers , Alex Bligh Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: <091F7ED5CD0A9C9EE264D5E4@Ximines.local> In-Reply-To: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 4 August 2010 12:59:13 -0400 Phillip Hallam-Baker wrote: > The value that the CA brings to the table here is that we say 'that > guy you are going to do business with is accountable'. And that is why > I started EV certs with Comodo when I was working for another CA. But EV accounts for only a tiny % of total number of certs in issue, doesn't it? Obviously EV does more, but it seems to me properly implemented DNSSEC does little less than non-EV certs. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Aug 4 11:34: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 C34583A680A; Wed, 4 Aug 2010 11:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.187 X-Spam-Level: X-Spam-Status: No, score=-105.187 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 D4Kq4BCO7Pj7; Wed, 4 Aug 2010 11:34:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B0883A67E6; Wed, 4 Aug 2010 11:34:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgikD-0004IX-J0 for namedroppers-data0@psg.com; Wed, 04 Aug 2010 18:31:13 +0000 Received: from [64.18.2.210] (helo=exprod7og127.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgikA-0004I9-VY for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 18:31:11 +0000 Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTFmx6pQMVYn4uWdl5WQ3mEsL88bKsjb6@postini.com; Wed, 04 Aug 2010 11:31:10 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 748A11B88C8; Wed, 4 Aug 2010 11:31:06 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 4 Aug 2010 11:31:06 -0700 Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> Date: Wed, 4 Aug 2010 14:31:01 -0400 CC: "bmanning@vacation.karoshi.com" , namedroppers Content-Transfer-Encoding: quoted-printable Message-ID: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> To: Alex Bligh X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 4, 2010, at 12:29 PM, Alex Bligh wrote: > As most SSL certificates are only domain validated, all an SSL = certiticate > does is tell you that at some point in the past few years, the person > in possession of the certificate probably had control over the DNS for > that name (actually being able to spoof DNS and/or intercept email > to the domain is sometimes enough). >=20 > I don't see why it's fundamentally more risky to go straight to the > DNS. That's certainly something to consider, but in fact the validation = process is a *little* more stringent than that, ranging up to quite a = bit more stringent (although the mechanism whereby this distinction is = communicated to the end-user isn't particularly functional at the = moment). Also, risky or not, two separate confirmations done at separate times = using separate systems make it quite a bit harder for an attacker to = compromise the certification process. From owner-namedroppers@ops.ietf.org Wed Aug 4 11:36: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 4D5A43A6891; Wed, 4 Aug 2010 11:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.16 X-Spam-Level: X-Spam-Status: No, score=-105.16 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 anHro17by+Te; Wed, 4 Aug 2010 11:36:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2FCF73A6807; Wed, 4 Aug 2010 11:36:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogimj-0004f1-1o for namedroppers-data0@psg.com; Wed, 04 Aug 2010 18:33:49 +0000 Received: from [64.18.2.161] (helo=exprod7og104.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogimg-0004ed-Fx for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 18:33:46 +0000 Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTFmyhQ5ToXCRhcpHiLQ5HVAjBtJWdK8F@postini.com; Wed, 04 Aug 2010 11:33:46 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BA8051B88F8; Wed, 4 Aug 2010 11:33:37 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 4 Aug 2010 11:33:37 -0700 Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <091F7ED5CD0A9C9EE264D5E4@Ximines.local> Date: Wed, 4 Aug 2010 14:33:33 -0400 CC: Phillip Hallam-Baker , "bmanning@vacation.karoshi.com" , namedroppers Content-Transfer-Encoding: quoted-printable Message-ID: <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> To: Alex Bligh X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 4, 2010, at 2:03 PM, Alex Bligh wrote: > But EV accounts for only a tiny % of total number of certs > in issue, doesn't it? Obviously EV does more, but it seems to me > properly implemented DNSSEC does little less than non-EV certs. For the case where all I want is a secure connection between the browser = and the endpoint, and I have no trust for the endpoint, you are right, = and I think Phillip said that. The trick is to avoid creating a system = based solely on the DNS that gets used for e-commerce. From owner-namedroppers@ops.ietf.org Wed Aug 4 12:09: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 9F2D33A6831; Wed, 4 Aug 2010 12:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.27 X-Spam-Level: * X-Spam-Status: No, score=1.27 tagged_above=-999 required=5 tests=[AWL=-0.835, 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 nQ-mlFxH5DTT; Wed, 4 Aug 2010 12:09:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9FCBE3A680B; Wed, 4 Aug 2010 12:09:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgjIr-0009xg-Rh for namedroppers-data0@psg.com; Wed, 04 Aug 2010 19:07:01 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgjIp-0009xK-EU for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 19:06:59 +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 AF43FC5693F; Wed, 4 Aug 2010 20:06:57 +0100 (BST) Date: Wed, 04 Aug 2010 20:06:56 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ted Lemon cc: Phillip Hallam-Baker , bmanning@vacation.karoshi.com, namedroppers , Alex Bligh Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: In-Reply-To: <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.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 4 August 2010 14:33:33 -0400 Ted Lemon wrote: > On Aug 4, 2010, at 2:03 PM, Alex Bligh wrote: >> But EV accounts for only a tiny % of total number of certs >> in issue, doesn't it? Obviously EV does more, but it seems to me >> properly implemented DNSSEC does little less than non-EV certs. > > For the case where all I want is a secure connection between the browser > and the endpoint, and I have no trust for the endpoint, you are right, > and I think Phillip said that. The trick is to avoid creating a system > based solely on the DNS that gets used for e-commerce. Perhaps I am just cynical about EV. If you take a non-EV certificate, and add EV, the difference to the normal user is the colour of their browser bar. If they investigated further, they'd find that the EV certificate is categorically and without question registered to "Foo Trading Inc, of 1 Acacia Avenue [blah]". I'd argue that for the majority of certificate holders (by number), that gives the end user very little information of whether they will actually get what they ordered, and it will conform to expectation. If an EV type functionality was required for extended validation of a DNSSEC secured name (i.e. if the customer wanted to know who the name was registered to), a whois type function would be just as good a technical solution, provided the back end checks were the same. In some circumstances (e.g. where the TLD/SLD is restricted to e.g. government entities) that step is largely unnecessary. And if the customer merely wants to know "they are buying from amazon.com" then "amazon.com" DNSSEC validated is surely sufficient? -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Aug 4 12:09: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 A88DD3A680B; Wed, 4 Aug 2010 12:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.692 X-Spam-Level: X-Spam-Status: No, score=-3.692 tagged_above=-999 required=5 tests=[AWL=0.745, 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 bUnkU9HVqVPw; Wed, 4 Aug 2010 12:09:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A41463A6886; Wed, 4 Aug 2010 12:09:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgjHQ-0009j3-21 for namedroppers-data0@psg.com; Wed, 04 Aug 2010 19:05:32 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgjHM-0009iW-MN for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 19:05:28 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id AAF65D8C789; Wed, 4 Aug 2010 12:05:27 -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 yed-sFYT2tUR; Wed, 4 Aug 2010 12:05:25 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 03539D8C774; Wed, 4 Aug 2010 12:05:24 -0700 (PDT) Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Wed, 4 Aug 2010 12:05:24 -0700 Cc: namedroppers Content-Transfer-Encoding: quoted-printable Message-Id: References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> To: Nicholas Weaver X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 4, 2010, at 7:41 AM, Nicholas Weaver wrote: > I'd rather trust Bernie Madoff to balance his own books than the = recursive resolver to validate DNSSEC. (I suspect Bernie Madoff balanced his own books quite well. It was the = books he showed to others that were the problem.) I have a pretty high level of trust in the validating resolver I have on = my laptop. It also gives me the side benefit that I can look at the = logs when I get a SERVFAIL. It would be a SMOP to hack the resolver (or = watch the logs) to signal a validation failure to a process that pops up = a dialog box (or does other actions) to deal with why the validator = puked. > Thus any decision to return a SERVFAIL in response to a failure to = validate represents a denial-of-service attack, not a security feature. A rational policy decsion: "fail close" instead of "fail open". > So its not like you can trust the results returned by the recursive = resolver aren't manipulated during that last hop. It depends on your trust boundary. In many enterprises, the folks who = run the resovlers are trusted and that's why we have TSIG and/or SIG(0). = Of course, in such environments, you lose the ability of end users to = determine why a validation failed, but you gain site wide caching. In = other environments, e.g., residential ISP services, the trust boundary = currently incorporates demonstrably untrustworthy parties, so running a = validating resolver locally is warranted if you want to trust DNS = responses.=20 > Rather, validation must be the exclusive domain of the stub resolver, = libaries, and application if you want DNSSEC to have any meaning at all = beyond an Internet-scale denial of service attack and full employment = act for consultants. =20 Doesn't scale. You're proposing multiplying the load on the DNS = infrastructure by the number of applications executing on every machine = on the Internet and essentially defeating any real level of caching.=20 Running the resolver on the local host at least "only" increases load to = the number of machines on the Internet. Caching at the host level is a = bit better than caching at the application level. Regards, -drc From owner-namedroppers@ops.ietf.org Wed Aug 4 12:13: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 029943A6957; Wed, 4 Aug 2010 12:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[AWL=0.632, 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 nyGKp0Xx8mtE; Wed, 4 Aug 2010 12:13:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE44E3A6831; Wed, 4 Aug 2010 12:13:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgjMc-000ASf-6F for namedroppers-data0@psg.com; Wed, 04 Aug 2010 19:10:54 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgjMa-000ASE-24 for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 19:10:52 +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 D7BE5C56934; Wed, 4 Aug 2010 20:10:49 +0100 (BST) Date: Wed, 04 Aug 2010 20:10:49 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Alex Bligh , Ted Lemon cc: Phillip Hallam-Baker , bmanning@vacation.karoshi.com, namedroppers , Alex Bligh Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: In-Reply-To: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.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 4 August 2010 20:06:56 +0100 Alex Bligh wrote: > If an EV type functionality was required for extended validation > of a DNSSEC secured name (i.e. if the customer wanted to know > who the name was registered to), a whois type function > would be just as good a technical solution, provided the > back end checks were the same. I wrote that incredibly badly. I didn't mean a live whois connection, I mean the registry signing the whois data. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Aug 4 12:33: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 E17B13A67DB; Wed, 4 Aug 2010 12:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.134 X-Spam-Level: X-Spam-Status: No, score=-105.134 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 HZ5oqichHqGD; Wed, 4 Aug 2010 12:31:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D049D3A6886; Wed, 4 Aug 2010 12:30:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgjdQ-000D9E-F8 for namedroppers-data0@psg.com; Wed, 04 Aug 2010 19:28:16 +0000 Received: from [64.18.2.159] (helo=exprod7og103.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgjdO-000D8g-6y for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 19:28:14 +0000 Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTFm/SC+E7sXpCRIvxyGs3yXUr7bpnAkK@postini.com; Wed, 04 Aug 2010 12:28:14 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 40E0E1B890E; Wed, 4 Aug 2010 12:28:08 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 4 Aug 2010 12:28:07 -0700 Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Wed, 4 Aug 2010 15:28:03 -0400 CC: Phillip Hallam-Baker , "bmanning@vacation.karoshi.com" , namedroppers Content-Transfer-Encoding: quoted-printable Message-ID: <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> To: Alex Bligh X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 4, 2010, at 3:06 PM, Alex Bligh wrote: > If an EV type functionality was required for extended validation > of a DNSSEC secured name (i.e. if the customer wanted to know > who the name was registered to), a whois type function > would be just as good a technical solution, provided the > back end checks were the same. No, the point I was making is that they are very different. In the = case of EV validation, the company getting the validation is paying = quite a bit of money for what's at least advertised as a fairly secure = system. The CA is supposed to keep their keys secure, so that it would = be difficult to get an EV Cert without going through this process. = They charge a lot of money to pay for that security. If you don't need = that much security, you don't pay for it. Everybody wins. Contrast this with DNSSEC. With DNSSEC, the root seems to be fairly = secure. Maybe COM will be too, someday, but will the level of security = for COM be sufficient to trust for e-commerce applications, or the even = higher degree of security required for banking? What about the security = of the bank's DNS service, which right now is probably outsourced? If we were to entrust banking information to the ZSK for .COM, that = would make the ZSK for .COM extremely valuable. Keeping a key that's = that valuable really secure will cost a lot of money. I don't want to = have to pay $100/year for every .com domain I have. Most people don't. = Hence, .COM's ZSK is not going to be secure enough to be used for = banking. Even the potential pressure on .COM's ZSK is probably one reason why = .COM isn't signed yet. I haven't heard that said, but I suspect it's = true. If we make DNSSEC the basis for banking-level security, it will = be too expensive to use for its actual intended purpose, which is making = sure that the information in secure zones is not forged. From owner-namedroppers@ops.ietf.org Wed Aug 4 12:34: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 3D36F3A69B8; Wed, 4 Aug 2010 12:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.11 X-Spam-Level: X-Spam-Status: No, score=-105.11 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 6VyUya4TRaXi; Wed, 4 Aug 2010 12:34:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 674E93A6960; Wed, 4 Aug 2010 12:33:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgjhF-000Dho-Mw for namedroppers-data0@psg.com; Wed, 04 Aug 2010 19:32:13 +0000 Received: from [64.18.2.26] (helo=exprod7og124.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgjhD-000Dgu-5T for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 19:32:11 +0000 Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTFnAMuZPDSjgSeMv9En2k2UMY1b/C7Ww@postini.com; Wed, 04 Aug 2010 12:32:11 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AD9401B8911; Wed, 4 Aug 2010 12:32:01 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 4 Aug 2010 12:32:01 -0700 Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Wed, 4 Aug 2010 15:31:56 -0400 CC: Nicholas Weaver , namedroppers Content-Transfer-Encoding: quoted-printable Message-ID: <0F98AB72-BF5F-4034-9036-0BD3F6D493DA@nominum.com> References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> To: David Conrad X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 4, 2010, at 3:05 PM, David Conrad wrote: > Running the resolver on the local host at least "only" increases load = to the number of machines on the Internet. Caching at the host level is = a bit better than caching at the application level. There's no reason not to continue to use your ISP's DNS cache, as long = as you validate the answers it gives you, and have a heuristic for = learning if it lies, and bypass it if you detect that it does. The = only additional load a validating resolver in the application should = create is its own CPU load doing the validations. A local validating = cache would certainly help with that. From owner-namedroppers@ops.ietf.org Wed Aug 4 12:48: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 E7D043A68B2; Wed, 4 Aug 2010 12:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.689 X-Spam-Level: * X-Spam-Status: No, score=1.689 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGRyrOiVwBVo; Wed, 4 Aug 2010 12:48:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D75673A67D3; Wed, 4 Aug 2010 12:48:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgjuH-000Fny-Cx for namedroppers-data0@psg.com; Wed, 04 Aug 2010 19:45:41 +0000 Received: from [89.188.97.107] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgjuE-000Flm-7Q for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 19:45:39 +0000 Received: from [192.168.63.201] (ppp91-76-135-248.pppoe.mtu-net.ru [91.76.135.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 01D38467C5; Wed, 4 Aug 2010 23:45:25 +0400 (MSD) Message-ID: <4C59C34E.40802@cryptocom.ru> Date: Wed, 04 Aug 2010 23:45:18 +0400 From: Basil Dolmatov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: Joe Abley CC: bmanning@vacation.karoshi.com, namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> In-Reply-To: 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: 04.08.2010 20:46, Joe Abley пишет: > On 2010-08-04, at 11:53, bmanning@vacation.karoshi.com wrote: > > >> i.e. what is the fundamental difference between a DNS RR that says: >> >> box.example.net in a 169.254.0.13 >> in hinfo httpd >> >> and >> >> box.example.net in a 169.254.0.13 >> in sslcert "hex-string" >> >> >> in neither case does the admin of the domain example.net really have any clue >> what is supposed to be running on node "box". Or does she? and if so, how? >> > I continue to be confused by this. > > If your argument is that you cannot rely upon DNS administrators to know what information to publish in the DNS with respect to applications run on infrastructure maintained by other people, then there's an obvious counter-example which you even helpfully include in your own message, above: the address (A/AAAA) record. > Yes. A record information _could_be_ equally unreliable... And the proper certificate is the means _to_check_ whether A-record information returned from DNS is _in_this_very_case_ reliable. Putting cert information in the same DNS-zone implicitly states that _every_byte_ of information, which has come as a DNS-answer is totally reliable and could be trusted upon even financially. Who will guarantee (give an insurance) this assumption? Who will stand forward and be willing to pay expenses and losses when and if this information happened to be wrong? dol@ > > Joe > From owner-namedroppers@ops.ietf.org Wed Aug 4 12:49: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 485DF3A68B2; Wed, 4 Aug 2010 12:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.031 X-Spam-Level: X-Spam-Status: No, score=0.031 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 xWyu05Dt7y+H; Wed, 4 Aug 2010 12:49:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7706D3A6886; Wed, 4 Aug 2010 12:49:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgjwZ-000G5o-Ks for namedroppers-data0@psg.com; Wed, 04 Aug 2010 19:48:03 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgjwX-000G5V-7n for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 19:48:01 +0000 Received: from [10.122.55.50] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 5D313C56940; Wed, 4 Aug 2010 20:47:58 +0100 (BST) Date: Wed, 04 Aug 2010 20:48:01 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ted Lemon cc: Phillip Hallam-Baker , bmanning@vacation.karoshi.com, namedroppers , Alex Bligh Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: In-Reply-To: <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.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 4 August 2010 15:28:03 -0400 Ted Lemon wrote: > If we were to entrust banking information to the ZSK for .COM, that would > make the ZSK for .COM extremely valuable. Keeping a key that's that > valuable really secure will cost a lot of money. I don't want to have > to pay $100/year for every .com domain I have. Most people don't. > Hence, .COM's ZSK is not going to be secure enough to be used for banking. Who says it needs to cost $100 a year? There are 100 million domains (approx) in .com. $10bn a year would, I suspect, be overkill even for this security application. I suspect even $1 per domain ($100m / year) would be more than sufficient to keep such a valuable ZSK secure. That gives (at worst) comparable security to non-EV certs to 100% of registrants, at a far lower cost, which is all (I would argue) all but 0.001% of registrants actually need. Those 0.001% of registrant's requirements are not fixed by EV certs alone anyway and have larger holes in their security usage they don't choose to fix (look at the 3D-Secure mess for instance). I suspect we may be wandering out of charter though. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Aug 4 13:03: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 C0FEF3A6985; Wed, 4 Aug 2010 13:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.912 X-Spam-Level: ** X-Spam-Status: No, score=2.912 tagged_above=-999 required=5 tests=[AWL=-1.224, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cv7d+QS5jL+3; Wed, 4 Aug 2010 13:03:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B1CF3A687C; Wed, 4 Aug 2010 13:03:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogk8Z-000Hvl-E7 for namedroppers-data0@psg.com; Wed, 04 Aug 2010 20:00:27 +0000 Received: from [89.188.97.107] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ogk8W-000HvQ-R1 for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 20:00:25 +0000 Received: from [192.168.63.201] (ppp91-76-135-248.pppoe.mtu-net.ru [91.76.135.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 9537B467BC; Thu, 5 Aug 2010 00:00:22 +0400 (MSD) Message-ID: <4C59C6D5.9090604@cryptocom.ru> Date: Thu, 05 Aug 2010 00:00:21 +0400 From: Basil Dolmatov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: Ted Lemon CC: Alex Bligh , Phillip Hallam-Baker , "bmanning@vacation.karoshi.com" , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> In-Reply-To: <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.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: 04.08.2010 23:28, Ted Lemon пишет: > > If we were to entrust banking information to the ZSK for .COM, that would make the ZSK for .COM extremely valuable. Keeping a key that's that valuable really secure will cost a lot of money. I don't want to have to pay $100/year for every .com domain I have. Most people don't. Hence, .COM's ZSK is not going to be secure enough to be used for banking. > Please, keep in mind that all information that is coming into .COM zone from the registrars will be signed with ZSK of .COM zone nearly automatically. So, you have no need at all to compromise .COM ZSK, yu have to perform the much easier task of compromising either database of one small registrars or data channel between the registrar and .COM zone whichever is easier (I bet for the first one). Nearly all of TLDs have systems now which distributes "trust" to its registrars inherently. But this "trust" concerns only manipulation with direction of information flows (A-records for all protocols, MX-records for SMTP), and one have the means to _check_ the validity of this direction with totally independent means (cert validating) and if something goes wrong - simply refuse to communicate in the wrong direction to the wrong recipient. So, the level of failure of this "trust" is quite limited - real service become _available_ until problem is rectified, so there are no direct possible financial losses, only indirect ones (waist of time and possibility). Putting cert information in DNS will greatly raise the necessary level of trust (real, without the quotes), and this trust will demand either total restructuring of the current distributed domain and DNS registration system or ensuring the _equal_ security of all registrars involved. Neither of it I think is feasible now. dol@ > Even the potential pressure on .COM's ZSK is probably one reason why .COM isn't signed yet. I haven't heard that said, but I suspect it's true. If we make DNSSEC the basis for banking-level security, it will be too expensive to use for its actual intended purpose, which is making sure that the information in secure zones is not forged. > > > From owner-namedroppers@ops.ietf.org Wed Aug 4 13:15: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 0A8323A6993; Wed, 4 Aug 2010 13:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.088 X-Spam-Level: X-Spam-Status: No, score=-105.088 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 pwAKo13J2iAt; Wed, 4 Aug 2010 13:15:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A8D633A69C0; Wed, 4 Aug 2010 13:15:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgkJz-000JUg-Nu for namedroppers-data0@psg.com; Wed, 04 Aug 2010 20:12:15 +0000 Received: from [64.18.2.155] (helo=exprod7og101.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgkJw-000JUC-PX for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 20:12:12 +0000 Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTFnJlGm0Tz/R95aLixZ6bXwFf/r2L03e@postini.com; Wed, 04 Aug 2010 13:12:12 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6FEDC1B8922; Wed, 4 Aug 2010 13:12:04 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 4 Aug 2010 13:12:04 -0700 Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <4C59C6D5.9090604@cryptocom.ru> Date: Wed, 4 Aug 2010 16:11:59 -0400 CC: Alex Bligh , Phillip Hallam-Baker , "bmanning@vacation.karoshi.com" , namedroppers Content-Transfer-Encoding: 7bit Message-ID: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C59C6D5.9090604@cryptocom.ru> To: Basil Dolmatov X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 4, 2010, at 4:00 PM, Basil Dolmatov wrote: > So, you have no need at all to compromise .COM ZSK, yu have to perform > the much easier task of compromising either database of one small > registrars or data channel between the registrar and .COM zone whichever > is easier (I bet for the first one). A very good point. From owner-namedroppers@ops.ietf.org Wed Aug 4 13:57: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 2282D3A69A6; Wed, 4 Aug 2010 13:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[AWL=-0.353, 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 nTemMfPICCBK; Wed, 4 Aug 2010 13:57:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF1923A6861; Wed, 4 Aug 2010 13:57:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgkzV-00007k-E2 for namedroppers-data0@psg.com; Wed, 04 Aug 2010 20:55:09 +0000 Received: from [209.85.213.52] (helo=mail-yw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgkzS-000076-U2 for namedroppers@ops.ietf.org; Wed, 04 Aug 2010 20:55:07 +0000 Received: by ywa6 with SMTP id 6so3103769ywa.11 for ; Wed, 04 Aug 2010 13:55:06 -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; bh=uhujLnZdrtUy+4uCOBsfON2F3LQ743b/Ch+FBv3gxPo=; b=xsqE0ji7OxahqEgDJ4H6dvbMBt3gpR6tzO2drU4J4IPxN+0Aswv0RRwBfBlkTNl7wZ AlKNBtRaLzNc7BSLEt8P9Yrmxw+76OpPJFa6UmaWVMmUjZlER/dfqYEL0yZJhcrFuAov /g9IJi8M7MTYSxgk3l3YSLvR8Uyc40cOz5O+c= 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=tlvLjtRa0JgP7xRvdHP2a1WaX8JpZN6rnN8iV4N+5jURTWa8XPIOdrXFq4K7FMkLlb 5shrfyBDAZZbU07NXXyVPZiucvv3eeyNX7E7MEdrmK1mh1iQruwy2XRi59hvAW8lSUnW ecHjiGghUej70WY4WZNdztHqL1nt3zdCbN7bA= MIME-Version: 1.0 Received: by 10.231.167.196 with SMTP id r4mr11041465iby.29.1280955305859; Wed, 04 Aug 2010 13:55:05 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Wed, 4 Aug 2010 13:55:05 -0700 (PDT) In-Reply-To: <091F7ED5CD0A9C9EE264D5E4@Ximines.local> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> Date: Wed, 4 Aug 2010 16:55:05 -0400 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Phillip Hallam-Baker To: Alex Bligh Cc: Ted Lemon , bmanning@vacation.karoshi.com, 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 its own DNSSEC does less than DV certs do. The combination of DNSSEC plus certs is what is powerful. And there is going to be a range of needs. Only a small portion of Internet users are going to qualify for an EV certificate. But they all need encryption. Don't worry about the commercial side. Let the industry work that out. I want DNSSEC to be a part of the best no-cost security solution, the best low cost security solution and the best security solution. On Wed, Aug 4, 2010 at 2:03 PM, Alex Bligh wrote: > > > --On 4 August 2010 12:59:13 -0400 Phillip Hallam-Baker > wrote: > >> The value that the CA brings to the table here is that we say 'that >> guy you are going to do business with is accountable'. And that is why >> I started EV certs with Comodo when I was working for another CA. > > But EV accounts for only a tiny % of total number of certs > in issue, doesn't it? Obviously EV does more, but it seems to me > properly implemented DNSSEC does little less than non-EV certs. > > -- > Alex Bligh > -- Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Thu Aug 5 01: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 6831F3A6803; Thu, 5 Aug 2010 01:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.868 X-Spam-Level: X-Spam-Status: No, score=-97.868 tagged_above=-999 required=5 tests=[AWL=4.731, 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 ffmiyecOX+0V; Thu, 5 Aug 2010 01:39:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C4B363A6AE2; Thu, 5 Aug 2010 01:39:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgvsX-000EzW-KU for namedroppers-data0@psg.com; Thu, 05 Aug 2010 08:32:41 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgvsS-000EyO-KG for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 08:32:37 +0000 Received: from [192.168.1.8] (ip123-112-174-82.adsl2.static.versatel.nl [82.174.112.123]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.3) with ESMTP id o758WWBC006567; Thu, 5 Aug 2010 10:32:32 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4C5A7724.1020003@nlnetlabs.nl> Date: Thu, 05 Aug 2010 10:32:36 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: "W.C.A. Wijngaards" CC: Namedroppers Subject: Re: [dnsext] algorithm rollover References: <4C5986E7.4020400@nlnetlabs.nl> In-Reply-To: <4C5986E7.4020400@nlnetlabs.nl> 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.5 (open.nlnetlabs.nl [213.154.224.1]); Thu, 05 Aug 2010 10:32:33 +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, On 08/04/2010 05:27 PM, W.C.A. Wijngaards wrote: > Hi, > > Key algorithm rollover needs to be described better. > > In 4641-bis, on introducing a new algorithm, removing an algorithm, and > removing an algorithm with Revoke. I have proposed text in the dnsop list. > In dnssecbis-updates, that revoked keys can sign not only the DNSKEY set > they are in, but are also allowed to sign the entire zone contents for > backwards compatibility with non-5011 validators when removing an > algorithm [or some other specific delineation what revoked keys can and > can not sign]. And text that RRSIGs MUST exist for a key that is not in > the DNSKEY rrset during such algorithm changes: a zone MAY contain > RRSIG's for an DNSKEY that does not exist in the DNSKEY RRset. dnssecbis-updates does not talk about revoked keys, so there is no restriction, so why should it go in there? I think it would be better to make an errata or update on RFC 5011 in this case. When it comes to algorithm rollover and RFC 5011, the backwards compatibility can be solved by following the algorithm rollover described in 4641bis + the earlier mentioned proposed text. I would like to propose to change the text "a zone MAY contain RRSIG's for an DNSKEY that does not exist in the DNSKEY RRset." with "a zone MUST allow for RRSIG's for an DNSKEY that does not exist in the DNSKEY RRset." It's a subtle change, but it enforcer implementations to allow this, instead of giving them the choice to ignore/filter signatures that don't match one of the keys in the DNSKEY set. > > * introducing a new algorithm. > 1) add signatures on entire zone with algorithm > 2) publish ZSK for the algorithm > 3) publish KSK for the algorithm > 4) publish DS for the algorithm. > With TTL waits between steps. > > * removing an algorithm > 1) remove DS for the algorithm > 2) remove KSK for the algorithm > 3) remove ZSK for the algorithm > 4) remove signatures on the entire zone for the algorithm > With TTL waits between steps. > > * removing an algorithm with 5011-REVOKE for KSK. > 1) remove DS for the algorithm > 2) publish KSK with REVOKE flag. > 3) remove KSK for the algorithm > 4) remove ZSK for the algorithm > 5) remove signatures on the entire zone for the algorithm > With TTL waits between steps. Yes, but such text is already in the 4641bis right and the proposed text, right? Or do you prefer splitting it up in adding and removing algorithms, instead of describing a rollover? > Other options for removal of an algorithm are > * Go MISSING. > use the steps for removal without the REVOKE publish step. The key goes > into 5011-MISSING state. And is removed after a time (180 or 366 days > or so). This may be an alternative for non ZSK-KSK split zones, since > they want things easy, and this is easy. It is an option, though I argue if it is a good one. If you have a way to properly rollover algorithms, why would you abuse the abnormal state from 5011? It is true that it is more easy to implement than the proper algorithm rollover. > * Sign the entire zone with the removed KSK while it is REVOKED as well. > Some find this distasteful, but really, it is only a DNSKEY flag, just > like the SEP flag and carries meaning only to operators. If you have a > ZSK/KSK split you do not have to do this. The issue with REVOKED bit is that you cannot know if it was revoked because of a planned rollover, or if it was revoked because it is compromised. That's why it may be distasteful. Perhaps these two alternative options should also go into 4641bis. > Alternatively, for this a spec-change can be made that such 5011 > revocations should be looked for by validators for any zone (not just > for trust-anchors), and revocations handled somehow. This is too vague for me to understand what you mean... Best regards, Matthijs > > Best regards, > Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMWncjAAoJEA8yVCPsQCW5TwEH/RwlJ9H2qRw5Zqm3ZDprFrQW ApHQxpyMLRfPjVAHqokugad/Bxka+2iz3yUgHWJRLCRthgH+vW7MrlK7M6vIFEXm AICGK41YpO4Zl42tTZ9c0X83HKB1nv8kmcFmaaacxyjbDfJxkahnIgtHRQgKHzvf cpeBKJl5zEFDe7VjEqSNEBCjCR6ZxgQ/V3DPmCKTNjOEjDTh/xxaGSC8/aGG7ujt v6Sv4VTb6ggBpSbK8pWJolELNF5np0Wxp9UFTLp/z4mOMXS+lPcCAxMNfAikV1tL JTU77/PDxZQy/KryAMYyRaPOklJ2qi7MIEauAaEs4uB9nFx8wV+onw87OPVQFzo= =vc6L -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Thu Aug 5 02:12: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 DDD3A3A6AF6; Thu, 5 Aug 2010 02:12:34 -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 0AWVl+Iz80tX; Thu, 5 Aug 2010 02:12:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C485F3A69DA; Thu, 5 Aug 2010 02:12:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgwRi-000LQH-SA for namedroppers-data0@psg.com; Thu, 05 Aug 2010 09:09:02 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OgwRd-000LOJ-Sf for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 09:08:58 +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.4/8.14.3) with ESMTP id o7598rqT013750 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 5 Aug 2010 11:08:53 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4C5A7FA5.2030909@nlnetlabs.nl> Date: Thu, 05 Aug 2010 11:08:53 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Thunderbird/3.1.1 MIME-Version: 1.0 To: Matthijs Mekking CC: Namedroppers Subject: Re: [dnsext] algorithm rollover References: <4C5986E7.4020400@nlnetlabs.nl> <4C5A7724.1020003@nlnetlabs.nl> In-Reply-To: <4C5A7724.1020003@nlnetlabs.nl> X-Enigmail-Version: 1.1.2 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.5 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 05 Aug 2010 11:08:54 +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 Matthijs, On 08/05/2010 10:32 AM, Matthijs Mekking wrote: > I would like to propose to change the text "a zone MAY contain RRSIG's > for an DNSKEY that does not exist in the DNSKEY RRset." with > "a zone MUST allow for RRSIG's for an DNSKEY that does not exist in the > DNSKEY RRset." It's a subtle change, but it enforcer implementations to > allow this, instead of giving them the choice to ignore/filter > signatures that don't match one of the keys in the DNSKEY set. OK > Yes, but such text is already in the 4641bis right and the proposed > text, right? Or do you prefer splitting it up in adding and removing > algorithms, instead of describing a rollover? Since people want to do this, and removal of an algorithm hits corner cases, this may be a good thing to do. >> * Go MISSING. > It is an option, though I argue if it is a good one. If you have a way > to properly rollover algorithms, why would you abuse the abnormal state > from 5011? It is true that it is more easy to implement than the proper > algorithm rollover. Yes if you do the proper rollover that is nicer, with a ZSK of the algorithm to sign the zone with. > This is too vague for me to understand what you mean... The REVOKE flag, what does it mean when the validator is not configured for 5011 validation for a domain? Does it change the validation process? Since 5011 does not say that it does, it does not change the validation process at all, and is only a flag 'for indicating rollover'. Therefore a REVOKED key may be used by any zone, say as KSK. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxaf6UACgkQkDLqNwOhpPhkMQCgrMHPHFRXkImoo9vn1O5j1vbX caMAniyRByoBl+ZOOe3qWy47eii5zpKT =/kd5 -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Thu Aug 5 06:10: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 1E1FF3A6AF6; Thu, 5 Aug 2010 06:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.097 X-Spam-Level: X-Spam-Status: No, score=-101.097 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, J_CHICKENPOX_23=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 CQZmW484iymY; Thu, 5 Aug 2010 06:10:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B35FE3A6B15; Thu, 5 Aug 2010 06:10:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh07S-0008VC-OJ for namedroppers-data0@psg.com; Thu, 05 Aug 2010 13:04:22 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh07P-0008Ub-RV for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 13:04:20 +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 A2F05734425; Thu, 5 Aug 2010 15:04:17 +0200 (CEST) Message-ID: <4C5AB6D1.9090601@nic.cz> Date: Thu, 05 Aug 2010 15:04:17 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <20100731005454.GE26174@shinkuro.com> In-Reply-To: <20100731005454.GE26174@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 31.7.2010 02:54, Andrew Sullivan wrote: > On Fri, Jul 30, 2010 at 12:16:48PM -0400, Phillip Hallam-Baker wrote: >> One issue missing from the charter is the question of use of DNSSEC in >> applications. > > It certainly is not missing from the charter in the sense that it is > our problem, and we need to tackle it. > > We are narrowly focussed on issues of the DNS protocol. Nothing about > how applications get to DNS results,&c, are our problem. Indeed, > they're not even the problem of the _area_ we are in: they're more > likely to be APP than INT. I second that. dnsext is no place to solve this and it also doesn't have the full expertise for that. > All of that said, I encourage people who think there are > application-level issues here to submit individual drafts. If there > were three or four such drafts that talked about application-level > interaction with DNSSEC, it might strike people who are inclined to > try to organize IETF work (i.e. all of us, right?!) that we could take > steps to co-ordinate that work (i.e. form a working group). Of > course, we already have some efforts in that direction. But the key > thing, under the current process rules, is to have a manifest > community of interested parties. Let's see those internet drafts! I > am sure that, though this sort of work be out of our charter, your > chairs will not object to the occasional announcement about such > drafts. When it gets heavy, we'll ask for a separate IETF mail list. > Alternatively, ask for one (perhaps M. Sury wull suggest that you > should use the one he is setting up.) I have already asked for mailing list for Public Keys in DNS (or how we are going to call it). I'll let you know when it's created and we could move this discussion there. O. -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 5 06:16: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 D59BA3A6B22; Thu, 5 Aug 2010 06:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.034 X-Spam-Level: X-Spam-Status: No, score=-100.034 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_05=-1.11, 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 bDHwXyKS8HMt; Thu, 5 Aug 2010 06:16:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 060AD3A6B1F; Thu, 5 Aug 2010 06:16:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh0G9-000A5k-Ns for namedroppers-data0@psg.com; Thu, 05 Aug 2010 13:13:21 +0000 Received: from [2001:12ff:0:2::4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh0G7-000A5H-EI for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 13:13:19 +0000 Received: by clone.registro.br (Postfix, from userid 1000) id 35A7EE04D5; Thu, 5 Aug 2010 10:13:17 -0300 (BRT) Date: Thu, 5 Aug 2010 10:13:17 -0300 From: Frederico A C Neves To: namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: <20100805131317.GD72677@registro.br> References: <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C59C6D5.9090604@cryptocom.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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, Aug 04, 2010 at 04:11:59PM -0400, Ted Lemon wrote: > On Aug 4, 2010, at 4:00 PM, Basil Dolmatov wrote: > > So, you have no need at all to compromise .COM ZSK, yu have to perform > > the much easier task of compromising either database of one small > > registrars or data channel between the registrar and .COM zone whichever > > is easier (I bet for the first one). > > A very good point. Take in account that the current registration model gives you choices of registrars. You could select the one that provides you the adequate level of security for your domain needs. At the currently x509 environment you could compromise one of the 60+ CAs present at mainstream browsers or one of the thousands of certs resellers databases. From owner-namedroppers@ops.ietf.org Thu Aug 5 07: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 58B063A6B2C; Thu, 5 Aug 2010 07:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.553 X-Spam-Level: X-Spam-Status: No, score=-100.553 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_05=-1.11, J_CHICKENPOX_23=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 FL4WcsCpDa0o; Thu, 5 Aug 2010 07:24:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 36B743A6B11; Thu, 5 Aug 2010 07:24:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh1Iz-000N8W-Oz for namedroppers-data0@psg.com; Thu, 05 Aug 2010 14:20:21 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh1Iw-000N87-VV for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 14:20:19 +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 EE64E734486; Thu, 5 Aug 2010 16:20:17 +0200 (CEST) Message-ID: <4C5AC8A1.10309@nic.cz> Date: Thu, 05 Aug 2010 16:20:17 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: Phillip Hallam-Baker CC: namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> In-Reply-To: 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.8.2010 18:59, Phillip Hallam-Baker wrote: > 2) Augmented DNSSEC with a certificate that is accredited via a CERT > or CERTHASH RR provides end to end cryptography with a very weak trust > chain. > > 3) Augmented DNSSEC with a certificate accredited as above plus a DV > trust chain accreditation for the DNSSEC Key Signing Key gives you end > to end cryptographic security with an endpoint that is as trustworthy > as their domain name. This two points have in fact exactly the same strength as long as the DV cert is validated (and issued) by sending email to admin@ (or to whois data) which is common these days. Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 5 07:53: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 218F13A680D; Thu, 5 Aug 2010 07:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.073 X-Spam-Level: X-Spam-Status: No, score=0.073 tagged_above=-999 required=5 tests=[AWL=-1.291, 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 iTRWcdZjv5s0; Thu, 5 Aug 2010 07:53:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9CE4B3A67B1; Thu, 5 Aug 2010 07:53:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh1ma-0002Jt-8f for namedroppers-data0@psg.com; Thu, 05 Aug 2010 14:50:56 +0000 Received: from [209.85.213.52] (helo=mail-yw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh1mX-0002JF-N3 for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 14:50:53 +0000 Received: by ywa6 with SMTP id 6so3648491ywa.11 for ; Thu, 05 Aug 2010 07:50:52 -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; bh=tw5sEKIlfHA4DOm+Kk+BUzUmmbHFHVm2QKbaZiSBzOg=; b=Tl5rpoc1rj2AOXiw8h7XH1DQauihFNyQl+hQaQdwVjeuqHwOw907s4x/PJOgBKXiOG ubKmbZM0gTk9bQvztsZXAWvfdXzR/rUo1I2pZXcDRwhM8VeMe8C2/yoMhrwp5/AqRt59 fH0dhBnqqEpNbJCzrGyAYo3RCR2pXfw80mMCU= 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=KQjklk6MIqn9877d4np7rJgoweg5b0VNH9GR7DmimASbrDytmczcM8kqj177MS7o4I AuXtVqI46Qi8PnXwiOj1lHgAM0jmPo4zbuPTrmSRrj+BddnJkWxkvFGlBJydYm5mD/v0 6hA4/E4nMMGqh4stbJg2XH0u1NJ73XsaEj3Yg= MIME-Version: 1.0 Received: by 10.150.11.12 with SMTP id 12mr12459578ybk.309.1281019852642; Thu, 05 Aug 2010 07:50:52 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Thu, 5 Aug 2010 07:50:52 -0700 (PDT) In-Reply-To: <20100805131317.GD72677@registro.br> References: <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C59C6D5.9090604@cryptocom.ru> <20100805131317.GD72677@registro.br> Date: Thu, 5 Aug 2010 10:50:52 -0400 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Phillip Hallam-Baker To: Frederico A C Neves 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: The difference is that under DNSSEC there is (currently) no means of expressing the validation criteria in an authenticated form. Modern browsers do not treat the 60+ roots as being directly equivalent. They are only equivalent for the purpose of turning on encryption, they are expressly not equivalent from the point of view of the user experience. The DV user experience is pretty inconspicuous and is likely to become more so. The EV user experience is considerably more noticeable because the validation process is establishing accountability. Speaking as a CA, the idea of DNSSEC replacing DV validated certificates is not a concern. I want as many people to use crypto as possible as that gives me upsell opportunities from what we agree are relatively weak validation processes to stronger ones. Given that we have to impedance match the DNSSEC validated chains to the existing browser infrastructure, it makes sense to use certs (possibly self-signed, possibly CA-issued) to wrap the application keys in the DNS. In addition to the technical advantage of doing so (I do not want to have to wait to rev the TLS standard, I want as few new code paths being tested as possible), I can then drop in the business logic that allows for control of liability. Specifically, I do not say 'this is the key for example.com', I say, 'this is the key that I validated by sending an email to admin@example.com and disclaim all warranties with respect to that claim, asset a maximum liability of $50 per cert while undertaking to insure transactions with respect to that certificate in the amount of $50'. Essentially I have managed to insert a little clickwrap license which is likely to allow me to mitigate the risk of unlimited liability in the case of a tort action since anyone who comes along and decides to rely on this certificate to authenticate the digital signature on a $500,000 mortgage agreement has been thoroughly warned. Unlike some people who raise what they consider 'roadblock' objections, I am raising issues for which I know the solution. I have a proven track record in this industry that pre-dates the formation of VeriSign. I have written a book on the subject, I reviewed parts of Ford and Baum's book on the subject. I would have brought up these issues earlier, but I rather needed ICANN to sign the root and the less for them to worry about the better. Everyone was waiting for ICANN to sign the root before they acted. On Thu, Aug 5, 2010 at 9:13 AM, Frederico A C Neves wrote: > On Wed, Aug 04, 2010 at 04:11:59PM -0400, Ted Lemon wrote: >> On Aug 4, 2010, at 4:00 PM, Basil Dolmatov wrote: >> > So, you have no need at all to compromise .COM ZSK, yu have to perform >> > the much easier task of compromising either database of one small >> > registrars or data channel between the registrar and .COM zone whichever >> > is easier (I bet for the first one). >> >> A very good point. > > Take in account that the current registration model gives you choices > of registrars. You could select the one that provides you the > adequate level of security for your domain needs. > > At the currently x509 environment you could compromise one of the 60+ > CAs present at mainstream browsers or one of the thousands of certs > resellers databases. > > -- Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Thu Aug 5 07: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 E5AA53A6A9D; Thu, 5 Aug 2010 07:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.212 X-Spam-Level: X-Spam-Status: No, score=-101.212 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, J_CHICKENPOX_23=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 pnWwPyuyjQu5; Thu, 5 Aug 2010 07:53:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6198F3A67B1; Thu, 5 Aug 2010 07:53:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh1m7-0002G6-Pp for namedroppers-data0@psg.com; Thu, 05 Aug 2010 14:50:27 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh1m2-0002FB-Db for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 14:50:22 +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 F2641734496; Thu, 5 Aug 2010 16:50:20 +0200 (CEST) Message-ID: <4C5ACFAC.7060509@nic.cz> Date: Thu, 05 Aug 2010 16:50:20 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: Ted Lemon CC: Alex Bligh , Phillip Hallam-Baker , "bmanning@vacation.karoshi.com" , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> In-Reply-To: <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.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.8.2010 21:28, Ted Lemon wrote: > On Aug 4, 2010, at 3:06 PM, Alex Bligh wrote: >> If an EV type functionality was required for extended validation of >> a DNSSEC secured name (i.e. if the customer wanted to know who the >> name was registered to), a whois type function would be just as >> good a technical solution, provided the back end checks were the >> same. > > No, the point I was making is that they are very different. In the > case of EV validation, the company getting the validation is paying > quite a bit of money for what's at least advertised as a fairly > secure system. The CA is supposed to keep their keys secure, so > that it would be difficult to get an EV Cert without going through > this process. They charge a lot of money to pay for that security. > If you don't need that much security, you don't pay for it. > Everybody wins. > > Contrast this with DNSSEC. With DNSSEC, the root seems to be fairly > secure. Maybe COM will be too, someday, but will the level of > security for COM be sufficient to trust for e-commerce applications, > or the even higher degree of security required for banking? What > about the security of the bank's DNS service, which right now is > probably outsourced? I agree that EV and DNSSEC-validated certs provide different type of service (identity vs. security). But I don't agree with the security part on DNSSEC et al. The security requirement is _already_ there. As a proof I have just created FREE DV certificate for www.sury.org and it took me less than 10 minutes and it was validated by 2 (two) emails. I would even say that the DV certificates are as strong as access to whois - with first email I have validated my email address and the second email went to the data in the whois. And now tell me how the common internet user can distinguish from _real_ bank certificate and this one. Will he even notice that the "green" bar is missing? Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 5 07: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 D61D83A659B; Thu, 5 Aug 2010 07:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.31 X-Spam-Level: X-Spam-Status: No, score=-101.31 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, J_CHICKENPOX_23=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 JKNFI1-4fKJF; Thu, 5 Aug 2010 07:55:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B076E3A680D; Thu, 5 Aug 2010 07:55:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh1oV-0002km-F7 for namedroppers-data0@psg.com; Thu, 05 Aug 2010 14:52:55 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh1oS-0002kJ-Rr for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 14:52:53 +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 28C4F7343C8; Thu, 5 Aug 2010 16:52:52 +0200 (CEST) Message-ID: <4C5AD043.5010308@nic.cz> Date: Thu, 05 Aug 2010 16:52:51 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: Basil Dolmatov CC: namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C59C6D5.9090604@cryptocom.ru> In-Reply-To: <4C59C6D5.9090604@cryptocom.ru> 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.8.2010 22:00, Basil Dolmatov wrote: > Putting cert information in DNS will greatly raise the necessary level > of trust (real, without the quotes), and this trust will demand either > total restructuring of the current distributed domain and DNS > registration system or ensuring the _equal_ security of all registrars > involved. Nope. There is no increase in security. If you can mangle MX to receive emails for that domain name then you can issue DV cert in less than 10 minutes for free. Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 5 08:04: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 271933A680C; Thu, 5 Aug 2010 08:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.544 X-Spam-Level: X-Spam-Status: No, score=-98.544 tagged_above=-999 required=5 tests=[AWL=4.056, 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 Ocj+bsTZec-J; Thu, 5 Aug 2010 08:04:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E31343A68AC; Thu, 5 Aug 2010 08:04:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh1wD-0004HR-0s for namedroppers-data0@psg.com; Thu, 05 Aug 2010 15:00:53 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh1w8-0004GC-6h for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 15:00:48 +0000 Received: from [192.168.1.8] (ip123-112-174-82.adsl2.static.versatel.nl [82.174.112.123]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.3) with ESMTP id o75F0j8s059931 for ; Thu, 5 Aug 2010 17:00:45 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4C5AD220.9060907@nlnetlabs.nl> Date: Thu, 05 Aug 2010 17:00:48 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Namedroppers Subject: Re: [dnsext] algorithm rollover References: <4C5986E7.4020400@nlnetlabs.nl> <4C5A7724.1020003@nlnetlabs.nl> <4C5A7FA5.2030909@nlnetlabs.nl> In-Reply-To: <4C5A7FA5.2030909@nlnetlabs.nl> 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.5 (open.nlnetlabs.nl [213.154.224.1]); Thu, 05 Aug 2010 17:00:45 +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 Wouter, On 08/05/2010 11:08 AM, W.C.A. Wijngaards wrote: >> Yes, but such text is already in the 4641bis right and the proposed >> text, right? Or do you prefer splitting it up in adding and removing >> algorithms, instead of describing a rollover? > > Since people want to do this, and removal of an algorithm hits corner > cases, this may be a good thing to do. Ok, but that should go into 4641 then, and it is more suitable to discuss that on the dnsop mailing list. >>> * Go MISSING. > >> It is an option, though I argue if it is a good one. If you have a way >> to properly rollover algorithms, why would you abuse the abnormal state >> from 5011? It is true that it is more easy to implement than the proper >> algorithm rollover. > > Yes if you do the proper rollover that is nicer, with a ZSK of the > algorithm to sign the zone with. > >> This is too vague for me to understand what you mean... > > The REVOKE flag, what does it mean when the validator is not configured > for 5011 validation for a domain? Does it change the validation > process? Since 5011 does not say that it does, it does not change the > validation process at all, and is only a flag 'for indicating rollover'. > Therefore a REVOKED key may be used by any zone, say as KSK. I interpreted 5011 in such a way that: As a 5011-aware resolver, you should of course obey the REVOKED bit. As a 5011-unaware resolver, you should ignore the bit, thus you can use it for validation. As a zone operator, I would not sign my complete zone with a key that I publish as revoked. Better to sign the zone with the non-SEP key with the same algorithm, those keys don't need to be revoked (as they will not be picked up as trust anchors). Even with a single type key scheme you need to introduce a non-SEP key, because otherwise you break 5011-aware resolvers (or let the old key go MISSING). Best regards, Matthijs > > Best regards, > Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMWtIgAAoJEA8yVCPsQCW5GtgIAILgiJamGTDWZLLJOxFVjirN eEK7Mu1jYa4KNAUbQwUbm0GsOQ9lTt7UIK0qdm71gEPVfDubHQYVv21/cMTqFjU3 Wxi9bUO839RgP4oPoLGAzb8NkR6TzAsR5SefL0It0TWV3HLQnSd4Vgmphz6vJp4s mswguP9igW50w8U9KtvxKV036phTNYhM308dMllYxcPKwSdM10X46FPRzNPi6Fgv VF+/tSgfSglW7LvuBSS++CVjmk5eC7xyLGsv+Ljl8zLZ6eZMiMBrpTEM8X5067/y 7Vr1Hfj9Koo51vmlkMmko9p7I+Rx1RiLKtgSyIK1NkFWeqLGfDidPXH1tXh9xoQ= =XMKF -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Thu Aug 5 08:08: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 592F13A6848; Thu, 5 Aug 2010 08:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.898 X-Spam-Level: X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[AWL=-1.366, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, 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 qOIH5QigfPtc; Thu, 5 Aug 2010 08:08:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 936843A63D3; Thu, 5 Aug 2010 08:08:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh214-0005EM-Ls for namedroppers-data0@psg.com; Thu, 05 Aug 2010 15:05:54 +0000 Received: from [74.125.83.52] (helo=mail-gw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh210-0005Dq-Tl for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 15:05:51 +0000 Received: by gwj20 with SMTP id 20so3625073gwj.11 for ; Thu, 05 Aug 2010 08:05:50 -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=IYCbtvcmue8DlLUjYPptQlJuc2h/IbFs8gasGDqLIy4=; b=SVrW1vnucguy2u9nUiYDBulUQLRoXz5m/oBBuF3D1R83VPSN0kqRYpPEzWG9ErB77+ d7SmpgZorlkhDnQFUPkFY9H8RFfEa3FO/W5GmHxZqvsNXgaWkzVe84Nk8fm83hs0dord hSoYOhIF9VQdqmDAYYyX/7RI8XQxBbKbSwrxc= 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=iqXaTQuNEzyty+rviUtXBZv458p25siulF1mk8AOllEYLzwMdPR+PQo+AX83xuXEv6 1I/HkqB+8eypmKOQWb4X65eQPmyl+8xTVLPGWZcilfXJQxv4aTxRqfsgVYCl6ctA+/Rv lR4RpD2MosCnTa3J4VxPsMQAdIYyYoAXcrZUM= MIME-Version: 1.0 Received: by 10.151.78.6 with SMTP id f6mr11665755ybl.52.1281020749272; Thu, 05 Aug 2010 08:05:49 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Thu, 5 Aug 2010 08:05:48 -0700 (PDT) In-Reply-To: <4C5ACFAC.7060509@nic.cz> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C5ACFAC.7060509@nic.cz> Date: Thu, 5 Aug 2010 11:05:48 -0400 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Cc: Ted Lemon , Alex Bligh , "bmanning@vacation.karoshi.com" , namedroppers Content-Type: text/plain; charset=ISO-8859-2 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: What you are doing here is to compare the weakest DV with DNSSEC and concluding that DNSSEC is no worse. There are some differences, they come from the fact that in SSL you know the date the cert was issued, in DNSSEC you have no idea. We don't really need to argue about this. Do you think that either DV or DNSSEC certs merit telling the user that they are secure? Both are strong enough to turn on crypto (as is a self-signed cert). Neither merits a padlock icon. I can't build a DNSSEC business by trying to undercut the price of DV certs. If DNSSEC certs are free then CAs will be forced to make DV certs free. You can already have a 90 day cert for free: http://www.instantssl.com/ssl-certificate-products/free-ssl-certificate.htm= l Come on folks, you think you can disrupt an incumbent business with a 15 year head start by competing on price against their loss leader? There has to be another advantage. Which is what I believe I have found in preventing downgrade attack. In my book dotCrime Manifesto, I describe how to use DNS policy records to fill in the missing pieces on SSL and S/MIME. On Thu, Aug 5, 2010 at 10:50 AM, Ond=F8ej Sur=FD wrote= : > On 4.8.2010 21:28, Ted Lemon wrote: >> >> On Aug 4, 2010, at 3:06 PM, Alex Bligh wrote: >>> >>> If an EV type functionality was required for extended validation of >>> a DNSSEC secured name (i.e. if the customer wanted to know who the >>> name was registered to), a whois type function would be just as >>> good a technical solution, provided the back end checks were the >>> same. >> >> No, the point I was making is that they are very different. =A0 In the >> case of EV validation, the company getting the validation is paying >> quite a bit of money for what's at least advertised as a fairly >> secure system. =A0 The CA is supposed to keep their keys secure, so >> that it would be difficult to get an EV Cert without going through >> this process. =A0 They charge a lot of money to pay for that security. >> If you don't need that much security, you don't pay for it. >> Everybody wins. >> >> Contrast this with DNSSEC. =A0 With DNSSEC, the root seems to be fairly >> secure. =A0 Maybe COM will be too, someday, but will the level of >> security for COM be sufficient to trust for e-commerce applications, >> or the even higher degree of security required for banking? =A0What >> about the security of the bank's DNS service, which right now is >> probably outsourced? > > I agree that EV and DNSSEC-validated certs provide different type of serv= ice > (identity vs. security). > > But I don't agree with the security part on DNSSEC et al. =A0The security > requirement is _already_ there. =A0As a proof I have just created FREE DV > certificate for www.sury.org and it took me less than 10 minutes and it w= as > validated by 2 (two) emails. > > I would even say that the DV certificates are as strong as access to whoi= s - > with first email I have validated my email address and the second email w= ent > to the data in the whois. > > And now tell me how the common internet user can distinguish from _real_ > bank certificate and this one. =A0Will he even notice that the "green" ba= r is > missing? > > Ondrej > -- > =A0Ond=F8ej Sur=FD > =A0vedouc=ED v=FDzkumu/Head of R&D department > =A0------------------------------------------- > =A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC > =A0Americka 23, 120 00 Praha 2, Czech Republic > =A0mailto:ondrej.sury@nic.cz =A0 =A0http://nic.cz/ > =A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112 > =A0------------------------------------------- > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Thu Aug 5 08: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 E06613A67FA; Thu, 5 Aug 2010 08:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.145 X-Spam-Level: X-Spam-Status: No, score=-100.145 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_20=-0.74, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=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 s87d3PyZRwVf; Thu, 5 Aug 2010 08:20:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 20E383A6978; Thu, 5 Aug 2010 08:20:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh2Ci-0007cd-9J for namedroppers-data0@psg.com; Thu, 05 Aug 2010 15:17:56 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh2CZ-0007Zh-MV for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 15:17:48 +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 E1041734423; Thu, 5 Aug 2010 17:17:46 +0200 (CEST) Message-ID: <4C5AD61A.6050905@nic.cz> Date: Thu, 05 Aug 2010 17:17:46 +0200 From: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: Phillip Hallam-Baker CC: namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C5ACFAC.7060509@nic.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; 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 5.8.2010 17:05, Phillip Hallam-Baker wrote: > What you are doing here is to compare the weakest DV with DNSSEC and > concluding that DNSSEC is no worse. And is that wrong? How? > There are some differences, they come from the fact that in SSL you > know the date the cert was issued, in DNSSEC you have no idea. And what benefit this does have? Does anybody check the date of the cert? > We don't really need to argue about this. Do you think that either DV > or DNSSEC certs merit telling the user that they are secure? Both are > strong enough to turn on crypto (as is a self-signed cert). Neither > merits a padlock icon. I am arguing that either both need to have the padlock or none of them. So, yes no need to argue. > There has to be another advantage. Which is what I believe I have > found in preventing downgrade attack. True. The benefit from publishing "you should see this certificate" is also important piece of this DNSPKI (as I call it). And I like that this enables to have SelfSigned+DNSSEC and EV+DNSSEC, and both will improve the situation. O. > On Thu, Aug 5, 2010 at 10:50 AM, Ondøej Surý wrote: >> On 4.8.2010 21:28, Ted Lemon wrote: >>> >>> On Aug 4, 2010, at 3:06 PM, Alex Bligh wrote: >>>> >>>> If an EV type functionality was required for extended validation of >>>> a DNSSEC secured name (i.e. if the customer wanted to know who the >>>> name was registered to), a whois type function would be just as >>>> good a technical solution, provided the back end checks were the >>>> same. >>> >>> No, the point I was making is that they are very different. In the >>> case of EV validation, the company getting the validation is paying >>> quite a bit of money for what's at least advertised as a fairly >>> secure system. The CA is supposed to keep their keys secure, so >>> that it would be difficult to get an EV Cert without going through >>> this process. They charge a lot of money to pay for that security. >>> If you don't need that much security, you don't pay for it. >>> Everybody wins. >>> >>> Contrast this with DNSSEC. With DNSSEC, the root seems to be fairly >>> secure. Maybe COM will be too, someday, but will the level of >>> security for COM be sufficient to trust for e-commerce applications, >>> or the even higher degree of security required for banking? What >>> about the security of the bank's DNS service, which right now is >>> probably outsourced? >> >> I agree that EV and DNSSEC-validated certs provide different type of service >> (identity vs. security). >> >> But I don't agree with the security part on DNSSEC et al. The security >> requirement is _already_ there. As a proof I have just created FREE DV >> certificate for www.sury.org and it took me less than 10 minutes and it was >> validated by 2 (two) emails. >> >> I would even say that the DV certificates are as strong as access to whois - >> with first email I have validated my email address and the second email went >> to the data in the whois. >> >> And now tell me how the common internet user can distinguish from _real_ >> bank certificate and this one. Will he even notice that the "green" bar is >> missing? -- Ondøej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 5 08:26: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 D0F7E3A685E; Thu, 5 Aug 2010 08:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[AWL=0.301, 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 rhVctvSYOrZ1; Thu, 5 Aug 2010 08:26:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E70203A67D1; Thu, 5 Aug 2010 08:26:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh2Hd-0008aY-TW for namedroppers-data0@psg.com; Thu, 05 Aug 2010 15:23:01 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh2Hb-0008Zt-5s for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 15:22:59 +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 99846C5693F; Thu, 5 Aug 2010 16:22:56 +0100 (BST) Date: Thu, 05 Aug 2010 16:22:55 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Phillip Hallam-Baker , =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= cc: Ted Lemon , bmanning@vacation.karoshi.com, namedroppers , Alex Bligh Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: <41C9C21D0C51E345276EBDAB@Ximines.local> In-Reply-To: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C5ACFAC.7060509@nic.cz> 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 5 August 2010 11:05:48 -0400 Phillip Hallam-Baker wrote: > I can't build a DNSSEC business by trying to undercut the price of DV > certs. If DNSSEC certs are free then CAs will be forced to make DV > certs free. You say it like this is a bad thing. I suspect many registries will provide DNSSEC at no incremental costs. If this results in a drop in the price of DV certificates, great. -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Aug 5 09:22: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 552633A68B6; Thu, 5 Aug 2010 09:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 QdB0Q+v5QB0T; Thu, 5 Aug 2010 09:22:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 023143A695D; Thu, 5 Aug 2010 09:22:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh396-000JQv-9M for namedroppers-data0@psg.com; Thu, 05 Aug 2010 16:18:16 +0000 Received: from [209.85.213.180] (helo=mail-yx0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh392-000JQW-RP for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 16:18:12 +0000 Received: by yxm8 with SMTP id 8so3737992yxm.11 for ; Thu, 05 Aug 2010 09:18: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:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=G7iaXfyJScmUJj0OHRZ6xBsJTRWsGXBD6vN2dIXJDTw=; b=OYNns8MAjN1DubHVGokzmS6gFzDAFpkTCResNf4EppcVEjeExOcExLAZ869w0P1QPA 4Bzf8WnvRKrIjoClS1PwnTKerW0WHfm+aKjp1RIDCy1b8jefDjnnCN+7sE4Bk68pvwjF tv8Y073SML4DtDk7sw8nx3Mx9F/P42uawrWZU= 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=uh4/euj0mwo2Om61QjP8rYhWQGIEStFIDPiYLvFHNg69owouhUoNqbmGEpiSP/ik64 vIN0Of730Ft97kQZwmrLBERqW3+w0dA2deelBExhsGba11VV/tbVO0fffOqV0t25Ce0l F96ecK1PRO5GfYsKv5H5WE7qIPCZAad3E6Rzg= MIME-Version: 1.0 Received: by 10.100.128.15 with SMTP id a15mr12282138and.67.1281025091943; Thu, 05 Aug 2010 09:18:11 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Thu, 5 Aug 2010 09:18:11 -0700 (PDT) In-Reply-To: <41C9C21D0C51E345276EBDAB@Ximines.local> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C5ACFAC.7060509@nic.cz> <41C9C21D0C51E345276EBDAB@Ximines.local> Date: Thu, 5 Aug 2010 12:18:11 -0400 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Phillip Hallam-Baker To: Alex Bligh Cc: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , Ted Lemon , bmanning@vacation.karoshi.com, 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: That assumes that VeriSign as the monopoly registry of .com is prepared to incur substantial costs and liabilities with respect to DNSSEC without charging additional fees for the new product. Does this seem likely? On Thu, Aug 5, 2010 at 11:22 AM, Alex Bligh wrote: > > > --On 5 August 2010 11:05:48 -0400 Phillip Hallam-Baker > wrote: > >> I can't build a DNSSEC business by trying to undercut the price of DV >> certs. If DNSSEC certs are free then CAs will be forced to make DV >> certs free. > > You say it like this is a bad thing. I suspect many registries will > provide DNSSEC at no incremental costs. If this results in a drop in > the price of DV certificates, great. > > -- > Alex Bligh > -- Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Thu Aug 5 09:43: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 5608F3A6842; Thu, 5 Aug 2010 09:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.126 X-Spam-Level: * X-Spam-Status: No, score=1.126 tagged_above=-999 required=5 tests=[AWL=-0.793, 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 XQszJbrMx1Ul; Thu, 5 Aug 2010 09:43:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC91C3A6872; Thu, 5 Aug 2010 09:43:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh3T7-000Mvl-14 for namedroppers-data0@psg.com; Thu, 05 Aug 2010 16:38:57 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh3T3-000Mun-HX for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 16:38:54 +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 5D7B2C5693F; Thu, 5 Aug 2010 17:38:50 +0100 (BST) Date: Thu, 05 Aug 2010 17:38:49 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Phillip Hallam-Baker cc: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= , Ted Lemon , bmanning@vacation.karoshi.com, namedroppers , Alex Bligh Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: In-Reply-To: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C5ACFAC.7060509@nic.cz> <41C9C21D0C51E345276EBDAB@Ximines.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Philip, --On 5 August 2010 12:18:11 -0400 Phillip Hallam-Baker wrote: > That assumes that VeriSign as the monopoly registry of .com is > prepared to incur substantial costs and liabilities with respect to > DNSSEC without charging additional fees for the new product. > > Does this seem likely? I wasn't thinking about .com, I was thinking about CCTLDs who tend to have a different outlook in life and a different set of drivers. If the result is that a CCTLD effectively included the equivalent of a DV cert, and a .com didn't, I would expect Verisign to react, yes. Even if the largest CCTLD is currently "only" 10% of the size of .com. -- Alex Bligh From owner-namedroppers@ops.ietf.org Thu Aug 5 10:03: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 A0E013A6A2F; Thu, 5 Aug 2010 10:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 LeGK5o-ln+tp; Thu, 5 Aug 2010 10:03:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4ADBA3A68CC; Thu, 5 Aug 2010 10:03:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh3oM-0000uS-HV for namedroppers-data0@psg.com; Thu, 05 Aug 2010 17:00:54 +0000 Received: from [2001:4f8:3:bb::111] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh3oJ-0000tz-Fx for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 17:00:51 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 4E9FCA1021 for ; Thu, 5 Aug 2010 17:00:50 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications In-Reply-To: Your message of "Thu, 05 Aug 2010 10:13:17 -0300." <20100805131317.GD72677@registro.br> References: <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C59C6D5.9090604@cryptocom.ru> <20100805131317.GD72677@registro.br> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 05 Aug 2010 17:00:50 +0000 Message-ID: <58778.1281027650@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, 5 Aug 2010 10:13:17 -0300 > From: Frederico A C Neves > ... > At the currently x509 environment you could compromise one of the 60+ CAs > present at mainstream browsers or one of the thousands of certs resellers > databases. or, if you're a government, you could just demand from some in-country CA a wildcard cert, to facilitate interception and wiretapping. what a silly system X.509/TLS is turning out to be. From owner-namedroppers@ops.ietf.org Thu Aug 5 10:22: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 481393A6A42; Thu, 5 Aug 2010 10:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.714 X-Spam-Level: X-Spam-Status: No, score=-0.714 tagged_above=-999 required=5 tests=[AWL=-0.219, 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 jL8FLNDodweI; Thu, 5 Aug 2010 10:22:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AD1663A685B; Thu, 5 Aug 2010 10:22:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh45z-00042G-Rw for namedroppers-data0@psg.com; Thu, 05 Aug 2010 17:19:07 +0000 Received: from [209.85.215.52] (helo=mail-ew0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh45x-00041w-6W for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 17:19:05 +0000 Received: by ewy20 with SMTP id 20so3235382ewy.11 for ; Thu, 05 Aug 2010 10:19:03 -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=zkVhydsQKDo3E8t/9F2pIUPaktYoaHy7B5ooRH4DHaw=; b=ISxnq6wXmKJZf9M74MgGFQwUyZsyNM5VYiVCPIl2BRv4zI9BLGzSPf25OtUkom7KzS JhcJtRTB5L3jI186PQKW4bnKFRhKv0ImGCqhFrIifCV4+XIP0YAxs+j6fwDtF9X8usNj JILSBOcRe2kxRXtHT0Hg4Uewg985wetG7s4n4= 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=IvSVNRcUixRgCPb2eiBX7US3rAS9H5Bi0CxuS5BKce7sEgRrNL7+twZkQEwTjonEaq Z4fg6wz4oOZRdaTsDAWpyhh237i5kAS/SOQ7zw/izdZI1/6wuMey2/MS2KimL9nI4AE0 2Wos37MAnlVvpXW4GTESwkGhYOS9HFLwxj24A= MIME-Version: 1.0 Received: by 10.14.53.70 with SMTP id f46mr4170164eec.19.1281028743550; Thu, 05 Aug 2010 10:19:03 -0700 (PDT) Received: by 10.14.127.195 with HTTP; Thu, 5 Aug 2010 10:19:03 -0700 (PDT) In-Reply-To: <58778.1281027650@nsa.vix.com> References: <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C59C6D5.9090604@cryptocom.ru> <20100805131317.GD72677@registro.br> <58778.1281027650@nsa.vix.com> Date: Thu, 5 Aug 2010 10:19:03 -0700 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Ted Hardie To: Paul Vixie Cc: namedroppers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Aug 5, 2010 at 10:00 AM, Paul Vixie wrote: >> Date: Thu, 5 Aug 2010 10:13:17 -0300 >> From: Frederico A C Neves >> ... >> At the currently x509 environment you could compromise one of the 60+ CA= s >> present at mainstream browsers or one of the thousands of certs reseller= s >> databases. > > or, if you're a government, you could just demand from some in-country CA > a wildcard cert, to facilitate interception and wiretapping. =A0what a si= lly > system X.509/TLS is turning out to be. A while back I suggested creating an RR that indicated which CA was expecte= d to sign any certs presented at the relevant host/domain. A DNSSEC-protected RR of this type would allow the application to compare whether the cert presented in a TLS session came from the CA named in the RR. That at least forces the government to g= et a wildcard cert from each CA, and it would allow business and others to act b= ased on the reputation of the CA with regards to its willingness to issue wildca= rd or other problematic certs. You'd still have to use the normal PKI checking methods for the cert itself (has it been invalidated, is it too old etc.), but this still seems to me to get a reasonable balance between useful information and ease of administration. As long the CA doesn't change its issuer information and the host/domain doesn't change CAs, this is close to file it and forget it. When I last mentioned this, several pointed out that the functionality was subsumed by other more complex methods; this is true, but I still wonder whether something cheap and cheerful might not be valuable here. regards, Ted From owner-namedroppers@ops.ietf.org Thu Aug 5 10:31: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 D5A0C3A68D0; Thu, 5 Aug 2010 10:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 iRbjgFaH1inE; Thu, 5 Aug 2010 10:31:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F1BE03A69A8; Thu, 5 Aug 2010 10:31:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh4Et-0005XG-NR for namedroppers-data0@psg.com; Thu, 05 Aug 2010 17:28:19 +0000 Received: from [2001:4f8:3:bb::111] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh4Eq-0005Wh-CQ for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 17:28:16 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id ECF2EA101E for ; Thu, 5 Aug 2010 17:28:15 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications In-Reply-To: Your message of "Thu, 05 Aug 2010 16:22:55 +0100." <41C9C21D0C51E345276EBDAB@Ximines.local> References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C5ACFAC.7060509@nic.cz> <41C9C21D0C51E345276EBDAB@Ximines.local> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 05 Aug 2010 17:28:15 +0000 Message-ID: <60484.1281029295@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, 05 Aug 2010 16:22:55 +0100 > From: Alex Bligh > > > I can't build a DNSSEC business by trying to undercut the price of DV > > certs. If DNSSEC certs are free then CAs will be forced to make DV > > certs free. > > You say it like this is a bad thing. I suspect many registries will > provide DNSSEC at no incremental costs. If this results in a drop in the > price of DV certificates, great. ouch! right in the middle of Hart-Scott-Rodino on the verisign/symantec transaction, and with a quote from a former verisign employee, too. "that's gotta hurt." +1, though. From owner-namedroppers@ops.ietf.org Thu Aug 5 11: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 CF4D83A6B3A; Thu, 5 Aug 2010 11:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.448 X-Spam-Level: X-Spam-Status: No, score=-99.448 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 vcxcsZzbYSfZ; Thu, 5 Aug 2010 11:07:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D30093A6A98; Thu, 5 Aug 2010 11:07:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh4lI-000Br0-3c for namedroppers-data0@psg.com; Thu, 05 Aug 2010 18:01:48 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh4lE-000BpY-IJ for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 18:01:44 +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 049211ECB408 for ; Thu, 5 Aug 2010 18:01:42 +0000 (UTC) Date: Thu, 5 Aug 2010 14:01:41 -0400 From: Andrew Sullivan To: namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: <20100805180141.GG38874@shinkuro.com> References: <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C5ACFAC.7060509@nic.cz> <41C9C21D0C51E345276EBDAB@Ximines.local> 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: Colleagues, On Thu, Aug 05, 2010 at 05:38:49PM +0100, Alex Bligh wrote: > If the result is that a CCTLD effectively included the equivalent of > a DV cert, and a .com didn't, I would expect Verisign to react, yes. > Even if the largest CCTLD is currently "only" 10% of the size of > .com. This is not to pick on Alex, but a general observation. The discussion here seems to be drifting very far from the remit of dnsext. How X.509 works is pretty clearly not our problem. Moreover, Olafur and I already suggested that, whereas the topic of support for applications, and APIs generally, are interesting and acceptable topics for the list, we're not going to add work items in this general area: it's too far outside our remit. It'd be good if we cooled heads on this topic. Thanks, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Aug 5 11:50: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 7E7B03A6A74; Thu, 5 Aug 2010 11:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[AWL=-0.326, 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 TyATLTmKio1L; Thu, 5 Aug 2010 11:50:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 838143A6B3B; Thu, 5 Aug 2010 11:50:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh5T0-000K0G-6S for namedroppers-data0@psg.com; Thu, 05 Aug 2010 18:46:58 +0000 Received: from [209.85.214.180] (helo=mail-iw0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh5Sw-000Jzq-Qn for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 18:46:54 +0000 Received: by iwn4 with SMTP id 4so553114iwn.11 for ; Thu, 05 Aug 2010 11:46:54 -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=uGuFhFg8y1lxL8qQFsUUQQL6yA9Ele4ClKjKTOJJxnM=; b=H9DV3lspmxCXzw0uRsLBpVgyYYvNHR12WSmNjqWOF5Tr/Y0zO7QRT82OBjvPn/Q3pd H+b62MmqBrJKG3/D54GdZoo64Bg/4pwXCxfX/d8vogz9a9VJhouEchCWeV0TTp0QKAaC qSHhX0k2eVEIF/rLdbJffLbl3mXdNZrYiAVOg= 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=Pz4RxI4SNSoJYMAL1KUggXITQ1SQmr81SAd0GlkgCaThiP6Xtf2GpIn80UezwB9To5 AcJQXS8Uq7wc9muv3F+IzFdQy7KdeqFzKnqrbrL8FGGtUHYk+g8r/g9O5/BHVWBC8eas ncZ0iYYB6BoHABTmyUOG6mQi+mncJRz/5R5rw= MIME-Version: 1.0 Received: by 10.231.174.5 with SMTP id r5mr12311130ibz.132.1281034011123; Thu, 05 Aug 2010 11:46:51 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Thu, 5 Aug 2010 11:46:50 -0700 (PDT) In-Reply-To: <58778.1281027650@nsa.vix.com> References: <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C59C6D5.9090604@cryptocom.ru> <20100805131317.GD72677@registro.br> <58778.1281027650@nsa.vix.com> Date: Thu, 5 Aug 2010 14:46:50 -0400 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Phillip Hallam-Baker To: Paul Vixie Cc: namedroppers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: And you think that the .cc registries will be immune from such pressure? We already know that ICANN is not. Security issues are always easy to solve if you are allowed to pretend that you have one entirely trustworthy actor that can be trusted to do the right thing. If we are going to hypothesize about defection by the trusted parties then you have to show why your favored trusted parties which operate under monopoly government contract are more trustworthy than the ones you criticize. On Thu, Aug 5, 2010 at 1:00 PM, Paul Vixie wrote: >> Date: Thu, 5 Aug 2010 10:13:17 -0300 >> From: Frederico A C Neves >> ... >> At the currently x509 environment you could compromise one of the 60+ CA= s >> present at mainstream browsers or one of the thousands of certs reseller= s >> databases. > > or, if you're a government, you could just demand from some in-country CA > a wildcard cert, to facilitate interception and wiretapping. =A0what a si= lly > system X.509/TLS is turning out to be. > > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Thu Aug 5 11:51: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 36B383A68FD; Thu, 5 Aug 2010 11:51:48 -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.319, 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 LmriOPwyoVKN; Thu, 5 Aug 2010 11:51:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 880713A68AF; Thu, 5 Aug 2010 11:51:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh5Vc-000KiY-7f for namedroppers-data0@psg.com; Thu, 05 Aug 2010 18:49:40 +0000 Received: from [209.85.160.180] (helo=mail-gy0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh5VZ-000Ki7-J8 for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 18:49:37 +0000 Received: by gye5 with SMTP id 5so3819158gye.11 for ; Thu, 05 Aug 2010 11: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:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pW/972UzQ42uvXRTu2xWUlHsg776RctocmfExnjOX1Y=; b=afg1XBkPaZVn5clakJetltv2zmCpkflA2+LLlztcAX/bwSGX8Mhok3+mxWzLkMpmMG isGhoBymd7X+fluB2kMZKzupgB1HAtIkZHQ3lc64ttg2dpO4jF2uew1ElN1xlb3XYOWY X3E3Z3n1eA+KI8NSO/BDxyaeWMgeZv+wAYkwc= 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=YDeaTnezCV/a5Kz/g0QNBcBcNHSLSOkUxyzKi5FXm6zlVyiE8R5Fn68ZZ4NZ5VPoms nHkLfHEWfts2pfU6np6hClsiSfhAH3JjmsSTMFNInZYfH1dUKUdyP5+x5j8rj1XzNLvX NRurGvGQQfUvefMWRgsdJj9kJGR9tx3ISLUHY= MIME-Version: 1.0 Received: by 10.151.63.41 with SMTP id q41mr12962814ybk.248.1281034175972; Thu, 05 Aug 2010 11:49:35 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Thu, 5 Aug 2010 11:49:35 -0700 (PDT) In-Reply-To: References: <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C59C6D5.9090604@cryptocom.ru> <20100805131317.GD72677@registro.br> <58778.1281027650@nsa.vix.com> Date: Thu, 5 Aug 2010 14:49:35 -0400 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Phillip Hallam-Baker To: Ted Hardie Cc: Paul Vixie , namedroppers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: That is a very sensible and useful suggestion. I had not considered that precise configuration, but I have earlier proposed a similar one. There are some slight complications to be considered (not all applications can chain to the same root so there will be roots not a root). But I think the basic principle is sound. On Thu, Aug 5, 2010 at 1:19 PM, Ted Hardie wrote: > On Thu, Aug 5, 2010 at 10:00 AM, Paul Vixie wrote: >>> Date: Thu, 5 Aug 2010 10:13:17 -0300 >>> From: Frederico A C Neves >>> ... >>> At the currently x509 environment you could compromise one of the 60+ C= As >>> present at mainstream browsers or one of the thousands of certs reselle= rs >>> databases. >> >> or, if you're a government, you could just demand from some in-country C= A >> a wildcard cert, to facilitate interception and wiretapping. =A0what a s= illy >> system X.509/TLS is turning out to be. > > > A while back I suggested creating an RR that indicated which CA was expec= ted to > sign any certs presented at the relevant host/domain. =A0A > DNSSEC-protected RR of this > type would allow the application to compare whether the cert presented > in a TLS session > came from the CA named in the RR. =A0That at least forces the government = to get a > wildcard cert from each CA, and it would allow business and others to act= based > on the reputation of the CA with regards to its willingness to issue wild= card or > other problematic certs. =A0 You'd still have to use the normal PKI > checking methods > for the cert itself (has it been invalidated, is it too old etc.), but > this still seems to > me to get a reasonable balance between useful information and ease of > administration. =A0As long the CA doesn't change its issuer information a= nd > the host/domain doesn't change CAs, this is close to file it and forget i= t. > > When I last mentioned this, several pointed out that the functionality > was subsumed > by other more complex methods; this is true, but I still wonder > whether something > cheap and cheerful might not be valuable here. > > regards, > > Ted > > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Thu Aug 5 14:46: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 DCDDF3A6B56; Thu, 5 Aug 2010 14:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.204 X-Spam-Level: X-Spam-Status: No, score=-98.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, MIME_QP_LONG_LINE=1.396, 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 5wu2YHSvsR6F; Thu, 5 Aug 2010 14:46:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BFC003A68D5; Thu, 5 Aug 2010 14:46:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh8B8-000ME0-2a for namedroppers-data0@psg.com; Thu, 05 Aug 2010 21:40:42 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh8B5-000MDd-DN for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 21:40:39 +0000 Received: from [10.127.60.160] (unknown [24.114.234.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 30C041ECB408; Thu, 5 Aug 2010 21:40:36 +0000 (UTC) References: <20100804155345.GA18609@vacation.karoshi.com.> <3E3736EDFE1BF63BB0C7BF5A@Ximines.local> <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C59C6D5.9090604@cryptocom.ru> <20100805131317.GD72677@registro.br> <58778.1281027650@nsa.vix.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A306) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Paul Vixie , namedroppers X-Mailer: iPhone Mail (8A306) From: Andrew Sullivan Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Date: Thu, 5 Aug 2010 17:35:42 -0400 To: Phillip Hallam-Baker Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Ok, to repeat more strongly my earlier moderator-hat remark: please stop wit= h the strongly worded arguments about security models &c. Thanks.=20 --=20 Andrew Sullivan On 2010-08-05, at 14:46, Phillip Hallam-Baker wrote: > And you think that the .cc registries will be immune from such pressure? >=20 > We already know that ICANN is not. >=20 >=20 > Security issues are always easy to solve if you are allowed to pretend > that you have one entirely trustworthy actor that can be trusted to do > the right thing. If we are going to hypothesize about defection by the > trusted parties then you have to show why your favored trusted parties > which operate under monopoly government contract are more trustworthy > than the ones you criticize. >=20 >=20 > On Thu, Aug 5, 2010 at 1:00 PM, Paul Vixie wrote: >>> Date: Thu, 5 Aug 2010 10:13:17 -0300 >>> From: Frederico A C Neves >>> ... >>> At the currently x509 environment you could compromise one of the 60+ CA= s >>> present at mainstream browsers or one of the thousands of certs reseller= s >>> databases. >>=20 >> or, if you're a government, you could just demand from some in-country CA= >> a wildcard cert, to facilitate interception and wiretapping. what a sill= y >> system X.509/TLS is turning out to be. >>=20 >>=20 >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 From owner-namedroppers@ops.ietf.org Thu Aug 5 16:39: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 32F443A6A9A; Thu, 5 Aug 2010 16:39:01 -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.502, 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 8zhBBdNTmC7K; Thu, 5 Aug 2010 16:38:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9470F3A69C2; Thu, 5 Aug 2010 16:38:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh9wS-000BXq-QA for namedroppers-data0@psg.com; Thu, 05 Aug 2010 23:33:40 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oh9wQ-000BXT-74 for namedroppers@ops.ietf.org; Thu, 05 Aug 2010 23:33:38 +0000 Received: from [10.122.55.50] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id DA1A6C56941; Fri, 6 Aug 2010 00:33:34 +0100 (BST) Date: Fri, 06 Aug 2010 00:33:37 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Andrew Sullivan , namedroppers cc: Alex Bligh Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Message-ID: <4378FCBEBA4A69B1658D26BC@nimrod.local> In-Reply-To: <20100805180141.GG38874@shinkuro.com> References: <091F7ED5CD0A9C9EE264D5E4@Ximines.local> <31EE8DA2-F845-404B-A28E-A292EB5A7942@nominum.com> <40AC4CCC-2049-4F9D-B2D6-6D3ABC3E7979@nominum.com> <4C5ACFAC.7060509@nic.cz> <41C9C21D0C51E345276EBDAB@Ximines.local> <20100805180141.GG38874@shinkuro.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 5 August 2010 14:01:41 -0400 Andrew Sullivan wrote: > This is not to pick on Alex, but a general observation. The > discussion here seems to be drifting very far from the remit of > dnsext. How X.509 works is pretty clearly not our problem. Moreover, > Olafur and I already suggested that, whereas the topic of support for > applications, and APIs generally, are interesting and acceptable > topics for the list, we're not going to add work items in this general > area: it's too far outside our remit. Actually, picking in me would be fair enough, as I suspect most of this tangent is my fault. Sorry. xTLD operator business models are definitely not on charter. Question to chairs so I don't get myself further into trouble: is interface to DNSSEC (e.g. library calls where library may or may not include stub resolver) on charter? Is discussion of potential use of DNSSEC to replace/augment SSL certs (from a technical point of view) on charter? I suspect the answers are "yes" and "no" respectively. -- Alex Bligh From owner-namedroppers@ops.ietf.org Fri Aug 6 01: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 E04FF3A6A35; Fri, 6 Aug 2010 01:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.074 X-Spam-Level: *** X-Spam-Status: No, score=3.074 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO6Gac0TCr4m; Fri, 6 Aug 2010 01:01:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E8AF33A6A27; Fri, 6 Aug 2010 01:01:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhHmi-000PlD-J9 for namedroppers-data0@psg.com; Fri, 06 Aug 2010 07:56:08 +0000 Received: from [2001:4f8:0:2::2b] (helo=mx.pao1.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhHmg-000Pks-BI for namedroppers@ops.ietf.org; Fri, 06 Aug 2010 07:56:06 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 01D2EC9423; Fri, 6 Aug 2010 07:55:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 8116CE6030; Fri, 6 Aug 2010 07:55:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 8A84729E86B; Fri, 6 Aug 2010 17:55:54 +1000 (EST) To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <201007300944.o6U9iHnI036521@drugs.dv.isc.org> <4F591391-AE08-46C6-ACD5-B0FDBA53A43B@hopcount.ca> <201008030359.o733xYMj020732@drugs.dv.isc.org><4C599036.5030203@ogud.com> Subject: Re: [dnsext] draft-andrews-dnsext-multi-match-label-00 In-reply-to: Your message of "Wed, 04 Aug 2010 12:07:18 -0400." <4C599036.5030203@ogud.com> Date: Fri, 06 Aug 2010 17:55:54 +1000 Message-Id: <20100806075554.8A84729E86B@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4C599036.5030203@ogud.com>, Olafur Gudmundsson writes: > This draft ignores the main lesson from bit labels fiasco: > No new label type is useful until the whole installed base is updated to > support it. No. These labels are NOT used in questions (IXFR/AXFR excluded). They are only in replies and only when the client signals that they understand them otherwise you get RFC 1035 labels. > EDNSx version change does not work as EDNS is only hop by hop and > the problems are going to show up in the middle rather than at the edges. > This is the main reason why edns0-bis is closing the label type registry. Hop by hop signalling is fine for this. If a cache understands it will get MML's in the reply. It can still generate RFC 1035 labels for the non MML aware clients. If the cache doesn't understand MML's then it will get RFC 1035 labels and a MML aware validator won't be able to validate through it. This is similar to NSEC3 where the cache needs to be NSEC3 aware to validate through it. 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 Aug 6 10: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 0F9E03A6AE5; Fri, 6 Aug 2010 10:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-1.740, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGPkUZab9Du9; Fri, 6 Aug 2010 10:35:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7FAF53A6A75; Fri, 6 Aug 2010 10:33:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhQhk-000H2Y-CR for namedroppers-data0@psg.com; Fri, 06 Aug 2010 17:27:36 +0000 Received: from [131.111.8.130] (helo=ppsw-30.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhQhh-000H1j-AD for namedroppers@ops.ietf.org; Fri, 06 Aug 2010 17:27:33 +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]:33710) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1OhQhW-0005UQ-fK (Exim 4.72) (return-path ); Fri, 06 Aug 2010 18:27:22 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OhQhW-0003tP-PY (Exim 4.67) (return-path ); Fri, 06 Aug 2010 18:27:22 +0100 Date: Fri, 6 Aug 2010 18:27:22 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: bmanning@vacation.karoshi.com cc: Jakob Schlyter , Basil Dolmatov , "Jeffrey A. Williams" , Nicholas Weaver , Phillip Hallam-Baker , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications In-Reply-To: <20100804115759.GA16458@vacation.karoshi.com.> Message-ID: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804115759.GA16458@vacation.karoshi.com.> 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 Wed, 4 Aug 2010, bmanning@vacation.karoshi.com wrote: > > well - that seems to lead to a fork. one path would lead toward DNS > admins taking over control of the end system admin function (Since we > control the DNS, we have sysadmin from your hosts); and the second path > leads toward sysadmins of the nodes holding the domain name taking over > the operation of their own DNS. The second path is already happening, to support certain kinds of load balancing appliances. However even packaged solutions are not immune to your warning about bad DNS installations - see for example http://fanf.livejournal.com/107721.html There's a third possibility that applications could use dynamic updates to publish their metadata in the DNS. I'm not sure how this can be made easy enough to be deployable, though. Tony. -- f.anthony.n.finch http://dotat.at/ THAMES DOVER: SOUTH VEERING SOUTHWEST, 4 OR 5, OCCASIONALLY 6 AT FIRST. SLIGHT OR MODERATE. OCCASIONAL RAIN, THEN SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. From owner-namedroppers@ops.ietf.org Fri Aug 6 10: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 9680D3A682D; Fri, 6 Aug 2010 10:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.638 X-Spam-Level: X-Spam-Status: No, score=-3.638 tagged_above=-999 required=5 tests=[AWL=-0.339, 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 VoBtL2TDOSGX; Fri, 6 Aug 2010 10:40:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2EF3F3A6826; Fri, 6 Aug 2010 10:40:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhQq8-000IJq-Th for namedroppers-data0@psg.com; Fri, 06 Aug 2010 17:36:16 +0000 Received: from [131.111.8.133] (helo=ppsw-33.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhQq5-000IIP-Qt for namedroppers@ops.ietf.org; Fri, 06 Aug 2010 17:36:14 +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]:48713) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1OhQpx-0000Oo-ge (Exim 4.72) (return-path ); Fri, 06 Aug 2010 18:36:05 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OhQpx-0004ug-6Z (Exim 4.67) (return-path ); Fri, 06 Aug 2010 18:36:05 +0100 Date: Fri, 6 Aug 2010 18:36:05 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Nicholas Weaver cc: Florian Weimer , Alex Bligh , Joe Abley , Phillip Hallam-Baker , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications In-Reply-To: Message-ID: References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> 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 Wed, 4 Aug 2010, Nicholas Weaver wrote: > > Dear god no! Validating on the recursive resolver ranges between useless > and dangerous. Not if the resolver runs on the endpoint. > Rather, validation must be the exclusive domain of the stub resolver, > libaries, and application if you want DNSSEC to have any meaning at all > beyond an Internet-scale denial of service attack and full employment > act for consultants. Stub resolvers (at least in the unix style) don't retain enough state to perform well, so you need at least some kind of separate caceh on the endpoint. Something like the bind-9 lwresd seems sensible to me, though it needs a lot of adaptation to re-focus it on application dnssec support. Tony. -- f.anthony.n.finch http://dotat.at/ NORTH FITZROY SOLE LUNDY FASTNET IRISH SEA: SOUTHWESTERLY OR WESTERLY, VEERING NORTHWESTERLY 5 OR 6, DECREASING 4 OR 5. MODERATE OR ROUGH. OCCASIONAL RAIN, THEN SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR AT FIRST. From owner-namedroppers@ops.ietf.org Fri Aug 6 10:41: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 9CD163A67DA; Fri, 6 Aug 2010 10:41:20 -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=-0.029, 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 qeGkULpdkZ8r; Fri, 6 Aug 2010 10:41:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A49963A6823; Fri, 6 Aug 2010 10:41:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhQt5-000Iql-1k for namedroppers-data0@psg.com; Fri, 06 Aug 2010 17:39:19 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhQt1-000IqC-KH for namedroppers@ops.ietf.org; Fri, 06 Aug 2010 17:39:15 +0000 Received: by pwj8 with SMTP id 8so993882pwj.11 for ; Fri, 06 Aug 2010 10:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=8FM5A2G1XcPx6RwyqUQjWLfgvFeEz/CbH+aLn7EjhD8=; b=cMBFSuLpodFiyud3klLVOdosB1Aqe3+LKTAPcHX1+/R1kiFEk/n0tS2SeawSBbuAiw j1WEzX2FlyqgO4Bz+dePdc/waapMMXwsahzk3/4mLAhN7kFkwmg+QGfbEZ7CCNvISRr3 8Ks7kGsNpKi0ZyVX2EsXbUC50fBBrWgZsDgXc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Jfl6fAhXUuQdRhIYPaTM1kzLd+T+PRSNesv4D/W8cCaFQESEVEqPALsT3PAFWLxSCm wfbY7G9Lar+zEbXvkGuhKw3Mi/AXbCISSOukeNiPYqXG/QWo4GGXlgPr6D5EK0wEnq+g jbQkYgyYER2ymWYt6ru3CXZulkOGkhYBqxv+Q= Received: by 10.114.72.2 with SMTP id u2mr14340134waa.216.1281116353497; Fri, 06 Aug 2010 10:39:13 -0700 (PDT) Received: from [10.0.1.2] (nweaver-airport.icir.org [192.150.187.57]) by mx.google.com with ESMTPS id x9sm3222874waj.3.2010.08.06.10.39.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Aug 2010 10:39:11 -0700 (PDT) Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Fri, 6 Aug 2010 10:39:08 -0700 Cc: Nicholas Weaver , Florian Weimer , Alex Bligh , Joe Abley , Phillip Hallam-Baker , namedroppers Content-Transfer-Encoding: quoted-printable Message-Id: <5A136610-47AB-4187-BA9F-B50E829112EA@ICSI.Berkeley.EDU> References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> To: Tony Finch X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 6, 2010, at 10:36 AM, Tony Finch wrote: > On Wed, 4 Aug 2010, Nicholas Weaver wrote: >>=20 >> Dear god no! Validating on the recursive resolver ranges between = useless >> and dangerous. >=20 > Not if the resolver runs on the endpoint. You're right. When I think of recursive resolver, I think of "separate = system" A better way to have put it is "validating on ANY host other than the = endpoint itself ranges between useless and dangerous". From owner-namedroppers@ops.ietf.org Fri Aug 6 10:41: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 C26273A68B6; Fri, 6 Aug 2010 10:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.605 X-Spam-Level: X-Spam-Status: No, score=-3.605 tagged_above=-999 required=5 tests=[AWL=-0.306, 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 mYGZOfmj5ECg; Fri, 6 Aug 2010 10:41:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA2223A68B5; Fri, 6 Aug 2010 10:41:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhQtZ-000Iu5-2s for namedroppers-data0@psg.com; Fri, 06 Aug 2010 17:39:49 +0000 Received: from [131.111.8.131] (helo=ppsw-31.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhQtU-000Isq-Fw for namedroppers@ops.ietf.org; Fri, 06 Aug 2010 17:39:44 +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]:44519) by ppsw-31.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1OhQtQ-00010A-Jn (Exim 4.72) (return-path ); Fri, 06 Aug 2010 18:39:40 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OhQtQ-0005Jj-3t (Exim 4.67) (return-path ); Fri, 06 Aug 2010 18:39:40 +0100 Date: Fri, 6 Aug 2010 18:39:40 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: bmanning@vacation.karoshi.com cc: Paul Hoffman , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications In-Reply-To: <20100804155345.GA18609@vacation.karoshi.com.> Message-ID: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> 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 Wed, 4 Aug 2010, bmanning@vacation.karoshi.com wrote: > > ah, but there -were- IETF standards for such foolishness (granted, back > before DNSSEC) that were deemed totally broken, since the DNS admin and > the host admin were almost never the same person. > Ref: HINFO RRs. I think you mean "are" not "were" - see MX, SRV, SSHFP, NAPTR, CERT. Tony. -- f.anthony.n.finch http://dotat.at/ SHANNON ROCKALL MALIN HEBRIDES: CYCLONIC IN MALIN AT FIRST, OTHERWISE NORTHERLY OR NORTHWESTERLY 5 TO 7, DECREASING 4 OR 5. MODERATE OR ROUGH. SHOWERS THEN FAIR. MODERATE OR GOOD. From owner-namedroppers@ops.ietf.org Fri Aug 6 10:49: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 1D2883A6990; Fri, 6 Aug 2010 10:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=-0.278, 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 vLWTQc4r5yTN; Fri, 6 Aug 2010 10:49:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE1693A685B; Fri, 6 Aug 2010 10:49:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhR01-000K4t-Br for namedroppers-data0@psg.com; Fri, 06 Aug 2010 17:46:29 +0000 Received: from [131.111.8.132] (helo=ppsw-32.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhQzv-000K3D-Hk for namedroppers@ops.ietf.org; Fri, 06 Aug 2010 17:46:23 +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]:38634) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1OhQzr-0001Ug-1P (Exim 4.72) (return-path ); Fri, 06 Aug 2010 18:46:19 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OhQzr-00065E-Df (Exim 4.67) (return-path ); Fri, 06 Aug 2010 18:46:19 +0100 Date: Fri, 6 Aug 2010 18:46:19 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: bmanning@vacation.karoshi.com cc: Paul Hoffman , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications In-Reply-To: <20100804164011.GB18609@vacation.karoshi.com.> Message-ID: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <20100804164011.GB18609@vacation.karoshi.com.> 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 Wed, 4 Aug 2010, bmanning@vacation.karoshi.com wrote: > On Wed, Aug 04, 2010 at 09:25:10AM -0700, Paul Hoffman wrote: > > > > OOB communication. To turn your question around: how did the DNS admin > > find out that box.example.net is configured to respond on > > 169.254.0.13? > > bingo! see above. DNS data, data about the DNS is passed into/through the DNS. > non-DNS data has to come via OOB methods. WHEN oob communications break down, > then there is a transitive trust problem. Data about the DNS is configured out-of-band too - i.e. delegations are configured using non-dns protocols. I don't see any fundamental difference between a delegated zone and an application's configuration. Tony. -- f.anthony.n.finch http://dotat.at/ WIGHT PORTLAND PLYMOUTH NORTH BISCAY: SOUTHWESTERLY VEERING WESTERLY OR NORTHWESTERLY, 4 OR 5, OCCASIONALLY 6 AT FIRST. MODERATE, OCCASIONALLY ROUGH IN PLYMOUTH AND NORTH BISCAY. RAIN OR SHOWERS, FAIR LATER. MODERATE OR GOOD, OCCASIONALLY POOR. From owner-namedroppers@ops.ietf.org Fri Aug 6 14:34: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 B77B03A6A6B; Fri, 6 Aug 2010 14:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.808 X-Spam-Level: X-Spam-Status: No, score=-0.808 tagged_above=-999 required=5 tests=[AWL=-0.313, 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 ZRFCoI82n-Kp; Fri, 6 Aug 2010 14:34:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0FA6028C2B2; Fri, 6 Aug 2010 14:18:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhUDk-0003VR-Jd for namedroppers-data0@psg.com; Fri, 06 Aug 2010 21:12:52 +0000 Received: from [209.85.214.180] (helo=mail-iw0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhUDg-0003Uu-LL for namedroppers@ops.ietf.org; Fri, 06 Aug 2010 21:12:49 +0000 Received: by iwn4 with SMTP id 4so2325226iwn.11 for ; Fri, 06 Aug 2010 14:12:48 -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=s0bz2DXE/rDJD3xWGj2ABMrorg9KkM7alr/A+6Em2Y0=; b=QIvVknVHrafKgNai5UKOsc/MM5xw4Wha4k/5RiD872IPhYcxmyxXzqZKncHhVXUSdl EN/7Sfhi38yc8D1IpaXlXiShjpDSm/Re51fHln5CaWg4Aq1VIQ3H7l2gNz4u8bIyHeF3 urabgXYK928mtQVnrJpSFv7hGh+lmOBE2+Nlw= 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=jYYYYRCM+IxJ87OotlaLGM2oZdSPhpskR0a3A7eUZnMbKU5dztbWlZYV7Y4TWh27vP oj/P728OtFDXaUAnXJ/MoGxBhVZ93RJTgr7wDnCgBGs1RC9uqIBE1Po77kzYMW3YzDpk XjBAZ4nhbDCXIlbIx4z8qOcLwA6s8Xkmun8aw= MIME-Version: 1.0 Received: by 10.231.39.69 with SMTP id f5mr14406870ibe.53.1281129167962; Fri, 06 Aug 2010 14:12:47 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Fri, 6 Aug 2010 14:12:47 -0700 (PDT) In-Reply-To: <5A136610-47AB-4187-BA9F-B50E829112EA@ICSI.Berkeley.EDU> References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> <5A136610-47AB-4187-BA9F-B50E829112EA@ICSI.Berkeley.EDU> Date: Fri, 6 Aug 2010 17:12:47 -0400 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Phillip Hallam-Baker To: Nicholas Weaver Cc: Tony Finch , Florian Weimer , Alex Bligh , Joe Abley , namedroppers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: OK, you try validating on my end point. It has a $1 PIC controller that is not capable of performing RSA or ECDSA. Looking at having about a thousand of them in the system. It makes no sense to validate at any point you do not have a trusted channe= l to. On Fri, Aug 6, 2010 at 1:39 PM, Nicholas Weaver wrote: > > On Aug 6, 2010, at 10:36 AM, Tony Finch wrote: > >> On Wed, 4 Aug 2010, Nicholas Weaver wrote: >>> >>> Dear god no! Validating on the recursive resolver ranges between useles= s >>> and dangerous. >> >> Not if the resolver runs on the endpoint. > > You're right. =A0When I think of recursive resolver, I think of "separate= system" > > A better way to have put it is "validating on ANY host other than the end= point itself ranges between useless and dangerous". > > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Fri Aug 6 14:36: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 090E63A67D4; Fri, 6 Aug 2010 14:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=-0.255, 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 Acn6Ug2bKZP2; Fri, 6 Aug 2010 14:36:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A0A823A6767; Fri, 6 Aug 2010 14:36:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhUWI-0006Bf-Gl for namedroppers-data0@psg.com; Fri, 06 Aug 2010 21:32:02 +0000 Received: from [131.111.8.133] (helo=ppsw-33.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhUWE-0006A2-8N for namedroppers@ops.ietf.org; Fri, 06 Aug 2010 21:31:58 +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]:54790) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1OhUWA-00040r-hm (Exim 4.72) (return-path ); Fri, 06 Aug 2010 22:31:54 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OhUWA-00053s-Hx (Exim 4.67) (return-path ); Fri, 06 Aug 2010 22:31:54 +0100 Date: Fri, 6 Aug 2010 22:31:54 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker cc: Nicholas Weaver , Florian Weimer , Alex Bligh , Joe Abley , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications In-Reply-To: Message-ID: References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> <5A136610-47AB-4187-BA9F-B50E829112EA@ICSI.Berkeley.EDU> 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 Fri, 6 Aug 2010, Phillip Hallam-Baker wrote: > > It makes no sense to validate at any point you do not have a trusted channel to. The right way of statinthe requirementit, of course :-) Tony. -- f.anthony.n.finch http://dotat.at/ SOUTHEAST ICELAND: EASTERLY 3 OR 4, OCCASIONALLY 5 LATER. MODERATE. RAIN OR SHOWERS, FOG PATCHES. MODERATE OR GOOD, OCCASIONALLY VERY POOR. From owner-namedroppers@ops.ietf.org Fri Aug 6 18:34: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 F1A913A681F; Fri, 6 Aug 2010 18:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[AWL=-0.306, 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 mwre-GTi9WBL; Fri, 6 Aug 2010 18:34:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A4663A6861; Fri, 6 Aug 2010 18:34:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhYEF-000Cgy-3A for namedroppers-data0@psg.com; Sat, 07 Aug 2010 01:29:39 +0000 Received: from [209.85.214.180] (helo=mail-iw0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhYEB-000CgS-Ns for namedroppers@ops.ietf.org; Sat, 07 Aug 2010 01:29:36 +0000 Received: by iwn4 with SMTP id 4so2608573iwn.11 for ; Fri, 06 Aug 2010 18:29:33 -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=LN4beY7OXf29aUdPYiLtF41a4XtGkDSttVZtdtIyMKk=; b=AtZ6RY3JZKlRq481zTVC0RcjzLCzz99wxI3RzzenCeO2vLG7AVzWf4mWJ3no//2a5y cZf0JKtahtRq9uqD2uGBfYB/b4aFYvXDPahVFStYlgughe+V6r+Qbjyk4jiyjYUOwngi FKQlAygHWIVOFxRl+nFTV/VUj4bQ9qafNJZmM= 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=XXhRAcN7E/Zz3BUm3M5xlIFOeFPOK2hslHMF6dIekZaPCOvAa3t1weYyURG/5ArE3/ SyzuBJ7cwFLI3mj0Q0lh6AnHFMEuHeQFkxmPsUdJLQS6+XF+jE94d4M4Z6YbhsTYT42Z mqiMHcLAJijSAufqDfyWuXNneyd0XbyERuvho= MIME-Version: 1.0 Received: by 10.231.177.25 with SMTP id bg25mr14376039ibb.154.1281144573202; Fri, 06 Aug 2010 18:29:33 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Fri, 6 Aug 2010 18:29:33 -0700 (PDT) In-Reply-To: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <20100804164011.GB18609@vacation.karoshi.com.> Date: Fri, 6 Aug 2010 21:29:33 -0400 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Phillip Hallam-Baker To: Tony Finch Cc: bmanning@vacation.karoshi.com, Paul Hoffman , namedroppers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Yes we could beef up the protocols for dynamic update. But it is not possible to correctly configure the DNS by means of applications maintaining their own entries (I tried). The corner case that caused me to abandon this idea is the case where I have 4 mail servers (or SRV advertised Web Services) that I want to load balance between them. The load balancing data requires real-time update so that servers that are under load can tell the DNS to slacken off. The problem here is that there is no way to do this unless the servers know what their load is relative to the other servers. If you have two servers that are both at 100% load they will wind down their priorities to zero. OK, well maybe there is, but I can't get my mind round how to do it as pure peers and if I could the algorithm would have to assume a certain set of optimization objectives. This works even less well when there are dependencies and resource contentions. For example, the mail server is also the auth server. These are not issues that I think can be addressed except on a site policy basis. And any site policy is best concentrated in a service registration service accessed via SRV record, not mangled into the DNS publication system. On Fri, Aug 6, 2010 at 1:46 PM, Tony Finch wrote: > On Wed, 4 Aug 2010, bmanning@vacation.karoshi.com wrote: >> On Wed, Aug 04, 2010 at 09:25:10AM -0700, Paul Hoffman wrote: >> > >> > OOB communication. To turn your question around: how did the DNS admin >> > find out that box.example.net is configured to respond on >> > 169.254.0.13? >> >> bingo! see above. =A0DNS data, data about the DNS is passed into/through= the DNS. >> non-DNS data has to come via OOB methods. =A0WHEN oob communications bre= ak down, >> then there is a transitive trust problem. > > Data about the DNS is configured out-of-band too - i.e. delegations are > configured using non-dns protocols. I don't see any fundamental differenc= e > between a delegated zone and an application's configuration. > > Tony. > -- > f.anthony.n.finch =A0 =A0http://dotat.at/ > WIGHT PORTLAND PLYMOUTH NORTH BISCAY: SOUTHWESTERLY VEERING WESTERLY OR > NORTHWESTERLY, 4 OR 5, OCCASIONALLY 6 AT FIRST. MODERATE, OCCASIONALLY RO= UGH > IN PLYMOUTH AND NORTH BISCAY. RAIN OR SHOWERS, FAIR LATER. MODERATE OR GO= OD, > OCCASIONALLY POOR. > > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Fri Aug 6 22:23: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 C2B5F3A6964; Fri, 6 Aug 2010 22:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.123 X-Spam-Level: X-Spam-Status: No, score=-0.123 tagged_above=-999 required=5 tests=[AWL=0.372, 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 qf7zgxstABBB; Fri, 6 Aug 2010 22:23:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A8FE23A686E; Fri, 6 Aug 2010 22:23:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhbnQ-000Ew4-O1 for namedroppers-data0@psg.com; Sat, 07 Aug 2010 05:18:12 +0000 Received: from [209.85.212.180] (helo=mail-px0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhbnL-000Ev5-5I for namedroppers@ops.ietf.org; Sat, 07 Aug 2010 05:18:07 +0000 Received: by pxi3 with SMTP id 3so4985145pxi.11 for ; Fri, 06 Aug 2010 22:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Km8eNpkSumOBx3cX59d+h1v4cEUml0Iqd1o4bgBHyI8=; b=FjfO4vv5W/ILtZiy+5C9vSeyTrE+Ke6L1Ls7qSPYFyj0dMohEKM6xSL+naNk4JT0i8 q8dMjPnSNTb9y0RYdhO88tWBmcLIi4RwF6rTG9yzzi7uuHlVeMEkNeSJXofuJDggyrel EDX/b8OMOycwjye7jYhImF/SXlM+6d823m+x8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=FQZu34nqcWiRUWEsXbYV4bmns6VSYvpwelUuM8Hdu5GxMAP+msir5ymh/2D/mk3NFR bxwq1B3PH/s25HAcqFYsPaL9IvU56USXNouzAJxSCPV98kRaB0Ie9B18OgG9hju5bSaa WYbh6ZcDnaYsQwbgevGjAM6qK6sKO9Nao3YwY= Received: by 10.142.230.18 with SMTP id c18mr11080261wfh.188.1281158284991; Fri, 06 Aug 2010 22:18:04 -0700 (PDT) Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) by mx.google.com with ESMTPS id w8sm2465757wfd.7.2010.08.06.22.18.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Aug 2010 22:18:02 -0700 (PDT) Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Fri, 6 Aug 2010 22:18:02 -0700 Cc: Nicholas Weaver , Tony Finch , Florian Weimer , Alex Bligh , Joe Abley , namedroppers Content-Transfer-Encoding: quoted-printable Message-Id: References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> <5A136610-47AB-4187-BA9F-B50E829112EA@ICSI.Berkeley.EDU> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 6, 2010, at 2:12 PM, Phillip Hallam-Baker wrote: > OK, you try validating on my end point. >=20 > It has a $1 PIC controller that is not capable of performing RSA or > ECDSA. Looking at having about a thousand of them in the system. >=20 > It makes no sense to validate at any point you do not have a trusted = channel to. THen such a PIC is going to get royally fucked by a MitM: In such a case, DNSSEC only protects such applications when the MitM is = only on DNS and not on the final protocol. And THAT MitM is called the not-on-the-endpoint "recursive resolver". From ugobopu5971@comcast.net Sat Aug 7 06:04: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 F04223A6984 for ; Sat, 7 Aug 2010 06:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.407 X-Spam-Level: X-Spam-Status: No, score=-35.407 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, IP_NOT_FRIENDLY=0.334, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tK2VZu3l1Go for ; Sat, 7 Aug 2010 06:04:23 -0700 (PDT) Received: from comcast.net (c-67-182-63-119.hsd1.ca.comcast.net [67.182.63.119]) by core3.amsl.com (Postfix) with ESMTP id AA33B3A696E for ; Sat, 7 Aug 2010 06:04:22 -0700 (PDT) From: To: dnsext-archive@ietf.org Date: Sat, 7 Aug 2010 06:05:00 -0700 Subject: Herbal Science Revolutionary Breakthrough Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100807130422.AA33B3A696E@core3.amsl.com> Her nights of pleasure will never be the same again. http://www.softtray.ru/ From owner-namedroppers@ops.ietf.org Sat Aug 7 07:39: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 C10263A69AC; Sat, 7 Aug 2010 07:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.21 X-Spam-Level: X-Spam-Status: No, score=-100.21 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 tuF5oNpuS6AD; Sat, 7 Aug 2010 07:39:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A4C9A3A69DF; Sat, 7 Aug 2010 07:39:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhkTU-000FJb-E2 for namedroppers-data0@psg.com; Sat, 07 Aug 2010 14:34:12 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhkTS-000FIp-1J for namedroppers@ops.ietf.org; Sat, 07 Aug 2010 14:34:10 +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 o77EY5jZ010479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Aug 2010 07:34:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <20100804164011.GB18609@vacation.karoshi.com.> Date: Sat, 7 Aug 2010 07:34:04 -0700 To: Phillip Hallam-Baker From: Paul Hoffman Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Cc: namedroppers 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:29 PM -0400 8/6/10, Phillip Hallam-Baker wrote: >Yes we could beef up the protocols for dynamic update. But it is not >possible to correctly configure the DNS by means of applications >maintaining their own entries (I tried). The fact that one person tried and failed is not an indicator that it cannot work if many people try. >The corner case that caused me to abandon this idea is the case where >I have 4 mail servers (or SRV advertised Web Services) that I want to >load balance between them. The load balancing data requires real-time >update so that servers that are under load can tell the DNS to slacken >off. > >The problem here is that there is no way to do this unless the servers >know what their load is relative to the other servers. If you have two >servers that are both at 100% load they will wind down their >priorities to zero. OK, well maybe there is, but I can't get my mind >round how to do it as pure peers and if I could the algorithm would >have to assume a certain set of optimization objectives. The IPsec world has this exact problem, and initial attempts to solve it were clumsy, but there are now many vendors with robust solutions to the load-balancing problem based on solutions that map well to the SRV solution. I propose that we don't give up on "correctly configure the DNS by means of applications maintaining their own entries". It has huge benefits for making the DNS responsive to the end nodes for which it serves data. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Sat Aug 7 09:40: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 28DA13A67B3; Sat, 7 Aug 2010 09:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.795 X-Spam-Level: X-Spam-Status: No, score=-0.795 tagged_above=-999 required=5 tests=[AWL=-0.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 LQa5n8XsH828; Sat, 7 Aug 2010 09:40:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6933F3A679F; Sat, 7 Aug 2010 09:40:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhmNO-0006eu-MC for namedroppers-data0@psg.com; Sat, 07 Aug 2010 16:36:02 +0000 Received: from [209.85.214.180] (helo=mail-iw0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhmNL-0006ec-Rn for namedroppers@ops.ietf.org; Sat, 07 Aug 2010 16:36:00 +0000 Received: by iwn4 with SMTP id 4so3404150iwn.11 for ; Sat, 07 Aug 2010 09:35:59 -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; bh=3kzkdosRdU56JJlyGpcdJUWZ4ZQ6ex4hAIqhn13pvj4=; b=OukUbVGIqlU+Ca/UkrQ+xGYj7pD4/TGK/AC4wom608oYJv7husHaNroZ8BWN+Fju7K uLmbTOp+ULuCFv9CkDukjphhIjIx2jSjjx8njv0TW4u5ZhQgONAacq8DbZ/mZquBOm79 lEZFUB3f9bIQxbJVdp0+sPvW8ia8LFg4y8DRA= 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=SwheA1OWGym8dDJhhQoA1HAAyxv5+e0oJQLMsYIqv+NbO/NcRo36CgJ8pQthio93EX odCDfTbKDiFIoHgRWRPjBeUVMAT4/7LHgdLkQCI+lBAr3J86yRuA/72cSG0fmAfKlBhM S7cpobbLD1DU5Vu2oXqAFOQ9rEHWq6wmYZYOc= MIME-Version: 1.0 Received: by 10.231.191.138 with SMTP id dm10mr15950174ibb.126.1281198959194; Sat, 07 Aug 2010 09:35:59 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Sat, 7 Aug 2010 09:35:59 -0700 (PDT) In-Reply-To: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <20100804164011.GB18609@vacation.karoshi.com.> Date: Sat, 7 Aug 2010 12:35:59 -0400 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Phillip Hallam-Baker To: Paul Hoffman 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: What I am saying here is that while it may appear that configuring the DNS is simply a matter of the endpoints telling the DNS what records to advertise for it, the problem is more involved. While you can extend any protocol to serve any purpose, I think that there is a natural break here and this problem is best addressed in a separate protocol. Which is in fact the current situation since many people already have DHCP configured so that when a host requests an IP address in DHCP, the relevant entry is pushed out to the DNS. I don't think overloading DHCP is a good approach either, I think we need a new protocol. While it might be possible to address the problem I raise in the context of DNS, it would take considerable ingenuity to do so. If we have a decomposition of the problem where one approach requires research and another is straightforward, I suggest we go for straightforward. On Sat, Aug 7, 2010 at 10:34 AM, Paul Hoffman wrote: > At 9:29 PM -0400 8/6/10, Phillip Hallam-Baker wrote: >>Yes we could beef up the protocols for dynamic update. But it is not >>possible to correctly configure the DNS by means of applications >>maintaining their own entries (I tried). > > The fact that one person tried and failed is not an indicator that it cannot work if many people try. > >>The corner case that caused me to abandon this idea is the case where >>I have 4 mail servers (or SRV advertised Web Services) that I want to >>load balance between them. The load balancing data requires real-time >>update so that servers that are under load can tell the DNS to slacken >>off. >> >>The problem here is that there is no way to do this unless the servers >>know what their load is relative to the other servers. If you have two >>servers that are both at 100% load they will wind down their >>priorities to zero. OK, well maybe there is, but I can't get my mind >>round how to do it as pure peers and if I could the algorithm would >>have to assume a certain set of optimization objectives. > > The IPsec world has this exact problem, and initial attempts to solve it were clumsy, but there are now many vendors with robust solutions to the load-balancing problem based on solutions that map well to the SRV solution. > > I propose that we don't give up on "correctly configure the DNS by means of applications maintaining their own entries". It has huge benefits for making the DNS responsive to the end nodes for which it serves data. > > --Paul Hoffman, Director > --VPN Consortium > -- Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Sat Aug 7 10:22: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 1ADB53A6A17; Sat, 7 Aug 2010 10:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.006 X-Spam-Level: X-Spam-Status: No, score=-99.006 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, 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 3f2ahiUaH0QJ; Sat, 7 Aug 2010 10:22:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EBA963A65A6; Sat, 7 Aug 2010 10:22:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ohn3W-000CWP-QZ for namedroppers-data0@psg.com; Sat, 07 Aug 2010 17:19:34 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ohn3U-000CW9-Hb for namedroppers@ops.ietf.org; Sat, 07 Aug 2010 17:19:32 +0000 Received: from [172.31.138.150] ([64.168.229.50]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o77HJSDC019176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Aug 2010 10:19:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <20100804164011.GB18609@vacation.karoshi.com.> Date: Sat, 7 Aug 2010 10:19:26 -0700 To: Phillip Hallam-Baker From: Paul Hoffman Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Cc: namedroppers 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 12:35 PM -0400 8/7/10, Phillip Hallam-Baker wrote: >What I am saying here is that while it may appear that configuring the >DNS is simply a matter of the endpoints telling the DNS what records >to advertise for it, the problem is more involved. Thank you for the correction. "is more involved" is quite different than the "is not possible" that you claimed earlier. >While it might be possible to address the problem I raise in the >context of DNS, it would take considerable ingenuity to do so. And you are claiming that we don't have enough of that here? > If we >have a decomposition of the problem where one approach requires >research and another is straightforward, I suggest we go for >straightforward. I propose that we do both. Having different protocols for different deployment scenarios (that is, different hosts will have different levels of introspection and communication with peers) is appropriate. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Sat Aug 7 10:52: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 4ED033A67D1; Sat, 7 Aug 2010 10:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.79 X-Spam-Level: X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5 tests=[AWL=-0.295, 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 Le+6EDlciHkO; Sat, 7 Aug 2010 10:52:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 300683A65A6; Sat, 7 Aug 2010 10:52:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhnV4-000Fxj-2T for namedroppers-data0@psg.com; Sat, 07 Aug 2010 17:48:02 +0000 Received: from [209.85.214.180] (helo=mail-iw0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhnV1-000FxB-6E for namedroppers@ops.ietf.org; Sat, 07 Aug 2010 17:47:59 +0000 Received: by iwn4 with SMTP id 4so3471234iwn.11 for ; Sat, 07 Aug 2010 10:47:58 -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; bh=CoUyJroipVvYEoebQYsZTkB8rM/g0Xk/TebxYssf5Aw=; b=Tf2+er4C2bfthPpEG8ZKkhRLhulBc1iOY9NyQzuNrGDuXQdVxlVDrR4EAQcgFDleQ0 rASfOeX9mkbMbs/1kgya5HNcgJzOXT5L8r+6ggUP0NoIedUAUrCjN1vvgbdGpy+5b1PR EA/ALZvDzzHGe8+SOrvPfNTQ992sCLFRdv51Q= 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=pWHV3EEii2cteq7DYOhacLByb9AaeV0pWnGrLtm25n5y3e4T20/sPFKPhlIgQ+tI+7 B8XwwesRDJx9SDG5Rogk3pvt9tGFEK7NXCJDTB8SJaW5cQ7dk5hEPBX31GcjOpLfwQwD 5Yjy5z4ZK0yTnibFePIwypIyvmBIIIX7Kp0Js= MIME-Version: 1.0 Received: by 10.231.33.67 with SMTP id g3mr16122968ibd.31.1281203278563; Sat, 07 Aug 2010 10:47:58 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Sat, 7 Aug 2010 10:47:58 -0700 (PDT) In-Reply-To: References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> <20100804164011.GB18609@vacation.karoshi.com.> Date: Sat, 7 Aug 2010 13:47:58 -0400 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Phillip Hallam-Baker To: Paul Hoffman 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: Sure, but apropos the charter discussion, are you proposing to have DNSEXT look at the DNS way of doing this and another group look at how to do it with a dedicated protocol? I think it would be better to have one working group look at this whole issue and then specify whatever DNS records or whatever are required with advice from this WG. On Sat, Aug 7, 2010 at 1:19 PM, Paul Hoffman wrote: > At 12:35 PM -0400 8/7/10, Phillip Hallam-Baker wrote: >>What I am saying here is that while it may appear that configuring the >>DNS is simply a matter of the endpoints telling the DNS what records >>to advertise for it, the problem is more involved. > > Thank you for the correction. "is more involved" is quite different than the "is not possible" that you claimed earlier. > >>While it might be possible to address the problem I raise in the >>context of DNS, it would take considerable ingenuity to do so. > > And you are claiming that we don't have enough of that here? > >> If we >>have a decomposition of the problem where one approach requires >>research and another is straightforward, I suggest we go for >>straightforward. > > I propose that we do both. Having different protocols for different deployment scenarios (that is, different hosts will have different levels of introspection and communication with peers) is appropriate. > > --Paul Hoffman, Director > --VPN Consortium > -- Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Sat Aug 7 13:49: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 E2E943A680B; Sat, 7 Aug 2010 13:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.323 X-Spam-Level: X-Spam-Status: No, score=-102.323 tagged_above=-999 required=5 tests=[AWL=0.277, 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 5LyQR61kClwz; Sat, 7 Aug 2010 13:49:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C5F9D3A68CD; Sat, 7 Aug 2010 13:49:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhqFo-000D6O-9q for namedroppers-data0@psg.com; Sat, 07 Aug 2010 20:44:28 +0000 Received: from [2001:1890:1112:1::2f] (helo=rfc-editor.org) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OhqFl-000D69-OE for namedroppers@ops.ietf.org; Sat, 07 Aug 2010 20:44:25 +0000 Received: by rfc-editor.org (Postfix, from userid 30) id 80CD6E06B3; Sat, 7 Aug 2010 13:44:24 -0700 (PDT) To: simon@josefsson.org, rdroms.ietf@gmail.com, jari.arkko@piuha.net, ogud@ogud.com, ajs@shinkuro.com Subject: [dnsext] [Technical Errata Reported] RFC4398 (2460) From: RFC Errata System Cc: paul@noc4.net, namedroppers@ops.ietf.org, rfc-editor@rfc-editor.org Message-Id: <20100807204424.80CD6E06B3@rfc-editor.org> Date: Sat, 7 Aug 2010 13:44:24 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: The following errata report has been submitted for RFC4398, "Storing Certificates in the Domain Name System (DNS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4398&eid=2460 -------------------------------------- Type: Technical Reported by: Paul Freeman Section: 2 Original Text ------------- 2. The CERT Resource Record The CERT resource record (RR) has the structure given below. Its RR type code is 37. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | key tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | algorithm | / +---------------+ certificate or CRL / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Corrected Text -------------- 2. The CERT Resource Record The CERT resource record (RR) has the structure given below. Its RR type code is 37. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | key tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | algorithm | / +---------------+ certificate or CRL / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Notes ----- In Section 2 (The CERT Resource Record) the table describing the wire format of the CERT RR is misaligned in such a way that it could lead to technical ambiguity of field positions within the packet structure. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4398 (draft-ietf-dnsext-rfc2538bis-09) -------------------------------------- Title : Storing Certificates in the Domain Name System (DNS) Publication Date : March 2006 Author(s) : S. Josefsson Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From aqaxady3765@comcast.net Sat Aug 7 15:17: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 1766F3A6A56 for ; Sat, 7 Aug 2010 15:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.741 X-Spam-Level: X-Spam-Status: No, score=-45.741 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, 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 RYs8YXMn8L0l for ; Sat, 7 Aug 2010 15:17:15 -0700 (PDT) Received: from comcast.net (c-71-63-106-37.hsd1.nc.comcast.net [71.63.106.37]) by core3.amsl.com (Postfix) with ESMTP id 324013A690D for ; Sat, 7 Aug 2010 15:17:15 -0700 (PDT) From: To: dnsext-archive@ietf.org Date: Sat, 7 Aug 2010 15:17:41 -0700 Subject: Herbal Science Revolutionary Breakthrough Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100807221715.324013A690D@core3.amsl.com> Your secret to a new, more satisfying and incredible sexual life. http://www.curtainthick.ru/ From avefefomy8938@comcast.net Sun Aug 8 03:12: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 EC5BC3A6998 for ; Sun, 8 Aug 2010 03:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -79.964 X-Spam-Level: X-Spam-Status: No, score=-79.964 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, GB_H_VIAGRA=4, GB_I_LETTER=-2, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_MONEYTERMS=0.681, SARE_UNI=0.591, 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 5FuKn3fbRzB7 for ; Sun, 8 Aug 2010 03:12:38 -0700 (PDT) Received: from comcast.net (c-71-207-205-13.hsd1.al.comcast.net [71.207.205.13]) by core3.amsl.com (Postfix) with ESMTP id 32DCB3A6868 for ; Sun, 8 Aug 2010 03:12:37 -0700 (PDT) From: Web-dealer of Viagra To: dnsext-archive@ietf.org Subject: Mr. dnsext-archive. Discounts are up to 70%. b Of British Date: Sun, 8 Aug 2010 05:13:10 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100808101237.32DCB3A6868@core3.amsl.com> history member into Newsletter
If you are unable to see the message below, click here to view.

Press here to see our store online

The Senate rules and customs were reformed in the twentieth century, largely in the 1970s.For other uses, see Daily Herald
(disambiguation). Five matches

were featured on the card. The New York Daily

News

and The

New York Post, founded in 1801 by Alexander Hamilton. Psalm 1
in a form of the Sternhold and Hopkins version widespread in Anglican usage before the English Civil War (1628 printing). While there, McQuarrie was asked by Hal Barwood to produce some illustrations for a film project he and Matthew Robbins were starting. During the winter he toured the Peloponnese. With these successful measures, the Yugoslav economy achieved

relative self-sufficiency and traded

extensively with both the West and the East. Constitutional Charter and Code of the Sovereign Military
Hospitaller Order of St. Malacosoma californicum is a species of tent caterpillar, so named because they build conspicuous silk tents in the branches of host trees. Yu Shan (Jade Mountain), 3,952metres

(12,966ft), Taiwan. Since

2003, 230,000 Sudanese refugees have fled to eastern Chad from war-ridden Darfur. Geneva Series of Commentaries, first published 1653-1655, First Banner of Truth edition, 1959, Banner of Truth. The letters that are easily confused, like "b" and "d", are presented in separate groups. St District, obsolete
since 1970 census. American Civil War in
Alabama, Encyclopedia of Alabama. The king presided over the assembly, and submitted decrees to it for ratification. Online Encyclopedia of Roman Emperors.Baronetcies conferred on the recommendation of Canadian governments. Scouting and Guiding in the Northwest Territories. In Averil Cameron, Bryan Ward-Perkins and Michael Whitby.James Town, Regent Park, Moss Park, Alexandra Park and Parkdale. Sub-Arctic Leadership Training

College

is a Bible college affiliated with the Pentecostal Assemblies of Canada.French

colonial expansion led to the

creation of the Territoire Militaire des Pays et Protectorats du Tchad in 1900. Only Britain recognized this annexation and Jordan has since ceded its claim to the territory to the PLO. Giovanni Koetting (born March 10, 1962 in Ivrea, Piedmont) is a retired Italian professional football player. In the 1950s the Swiss director Benno Besson with the Deutsches Theater successfully toured Europe and Asia including Japan with The Dragon by Jewgenij Schwarz. Crown Dependency or Overseas Territory of the United Kingdom.Committee chairs are elected, but, in practice, seniority is rarely bypassed. The license has since been changed to a public domain one. William Smith writes in his 1863 "A Dictionary of the Bible" about the different Hebrew forms supported by these Greek forms. Key points of commonality amongst various ideas include the idea that there is one working class, even though it may be internally divided.Bankruptcy commenced soon after the collapse. Sovereignty over Socotra is disputed by Somalia. Sir Otto Beit, 1st Baronet, South Africa. The population density is only 20.

© 2009 area reconstruct a Inc. All rights reserved.

Unsubscribe

From edysocyqou7014@comcast.net Sun Aug 8 13:09: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 828193A687A for ; Sun, 8 Aug 2010 13:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.741 X-Spam-Level: X-Spam-Status: No, score=-15.741 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, 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 9Hu1Nr8kViyz for ; Sun, 8 Aug 2010 13:09:18 -0700 (PDT) Received: from comcast.net (c-71-60-196-168.hsd1.pa.comcast.net [71.60.196.168]) by core3.amsl.com (Postfix) with ESMTP id A063C3A6878 for ; Sun, 8 Aug 2010 13:09:18 -0700 (PDT) From: To: dnsext-archive@ietf.org Date: Sun, 8 Aug 2010 16:09:53 -0400 Subject: hitting intense highs Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100808200918.A063C3A6878@core3.amsl.com> Never left home without it. Just me and my perfect piece of craftsmanship. http://www.watchany.ru/ From owner-namedroppers@ops.ietf.org Mon Aug 9 02:37: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 F1C3E3A677C; Mon, 9 Aug 2010 02:37:23 -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.870, 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 f9wvf6SMg1UD; Mon, 9 Aug 2010 02:37:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B7D1A3A6849; Mon, 9 Aug 2010 02:37:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiOhw-000C4c-Fj for namedroppers-data0@psg.com; Mon, 09 Aug 2010 09:31:48 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiOht-000C3y-Ru for namedroppers@ops.ietf.org; Mon, 09 Aug 2010 09:31:46 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1OiOhk-0002d8-Hs; Mon, 09 Aug 2010 09:31:36 +0000 Received: by bfk.de with local id 1OiOhk-0006hZ-B3; Mon, 09 Aug 2010 09:31:36 +0000 To: Nicholas Weaver Cc: Alex Bligh , Joe Abley , Phillip Hallam-Baker , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> From: Florian Weimer Date: Mon, 09 Aug 2010 09:31:36 +0000 In-Reply-To: (Nicholas Weaver's message of "Wed\, 4 Aug 2010 07\:41\:49 -0700") Message-ID: <82r5i8p1xj.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Nicholas Weaver: > Validating on the recursive resolver ranges between useless and > dangerous. How do you prevent cache poisoning without adding a validator to the cache? Keep in mind that a validator behind a non-validating cache has no way to recover from bad data which has entered the cache. If you think that DNS cache poisoning attacks are likely (and why else would you deploy DNSSEC?), this should be a concern to you. It might only be a denial of service, but that could still be quite annoying and cause significant call center costs. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Mon Aug 9 03:12: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 B9B853A67FE; Mon, 9 Aug 2010 03:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.576 X-Spam-Level: ** X-Spam-Status: No, score=2.576 tagged_above=-999 required=5 tests=[AWL=-0.774, 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 IPK+DpgGJ1D9; Mon, 9 Aug 2010 03:12:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B82F3A68E1; Mon, 9 Aug 2010 03:12:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiPHp-000Hij-RX for namedroppers-data0@psg.com; Mon, 09 Aug 2010 10:08:53 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiPHl-000Hhu-PB for namedroppers@ops.ietf.org; Mon, 09 Aug 2010 10:08:49 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1OiPHd-0000km-UT; Mon, 09 Aug 2010 10:08:41 +0000 Received: by bfk.de with local id 1OiPHd-0007G3-Q4; Mon, 09 Aug 2010 10:08:41 +0000 To: bmanning@vacation.karoshi.com Cc: Paul Hoffman , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <26299077.1280610118146.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> <4C57F3E4.9060207@cryptocom.ru> <5D9CBE2E-291D-485F-98DE-5EBBE761CD00@kirei.se> <20100804145221.GA17773@vacation.karoshi.com.> <20100804155345.GA18609@vacation.karoshi.com.> From: Florian Weimer Date: Mon, 09 Aug 2010 10:08:41 +0000 In-Reply-To: <20100804155345.GA18609@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Wed\, 4 Aug 2010 15\:53\:45 +0000") Message-ID: <82d3tsp07q.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > ah, but there -were- IETF standards for such foolishness > (granted, back before DNSSEC) that were deemed totally broken, > since the DNS admin and the host admin were almost never the > same person. But that ship has already sailed. nowadays, DNS doesn't provide addresing for hosts (individual machines), but for a more abstract service. People do not access the host named "www" in the "example.com" zone, but a web server on "www.example.com", and chances are good that this isn't even the primary host name of the box. In such an environment, the DNS administrator already has to know quite a lot about the organization's infrastructure (which servers can handle what load etc.). Maybe the person actually making the changes to the zone does not know all the details, but the process around zone updates surely has to take them into account. I really don't see how putting public key material would constitute a fundamental change of the DNS model. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Mon Aug 9 08:21: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 4049F3A6884; Mon, 9 Aug 2010 08:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[AWL=-2.623, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MALE_ENHANCE=2.596, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVvv6HnISRmA; Mon, 9 Aug 2010 08:21:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A319C3A67AE; Mon, 9 Aug 2010 08:21:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiU4c-000Cs7-5t for namedroppers-data0@psg.com; Mon, 09 Aug 2010 15:15:34 +0000 Received: from [74.125.83.180] (helo=mail-pv0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiU4Z-000Cra-B2 for namedroppers@ops.ietf.org; Mon, 09 Aug 2010 15:15:31 +0000 Received: by pvc30 with SMTP id 30so1430774pvc.11 for ; Mon, 09 Aug 2010 08:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=MZ7xPzWINCS6k0+xGgJi16rX9xTpLMSFNL+j9UQ9RrU=; b=XbRXBASZ8Tdvuc8WjxqiNIyFKj/jpf2YLeevFN5vmfjpHqRPhLXz00jhftomy8eQp9 B3MOS5sk7tJ6Lck4nKqVH8JSM0gV/dIOVrCCU05X680P+Xl9iMXbSD8qDAwNSeUqBjxZ aiZzazHuBjrsDvR6LJ3G6iL4gBt7NBzUsJeow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=AZNEhCGlF4S2MhvDejoqib5LP6qqAdJwzymVHW4niCOp8JoA+xugGf6ip5Hg490DP+ qacxEOQEUd6tA7QZV9Skj0RvOCclDhHNUuain4jYUEjHvrtVE5pj5TP87fx8R99xTt9y 3XvdDMGTpe5VFDi8+vPJ/bxvQWdGiseZZl4Xw= Received: by 10.114.88.18 with SMTP id l18mr18653918wab.175.1281366930475; Mon, 09 Aug 2010 08:15:30 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id n32sm10596583wag.23.2010.08.09.08.15.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Aug 2010 08:15:20 -0700 (PDT) References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> <82r5i8p1xj.fsf@mid.bfk.de> In-Reply-To: <82r5i8p1xj.fsf@mid.bfk.de> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <3C27B9EE-D75B-483B-9D02-B660C539A477@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , Alex Bligh , Joe Abley , Phillip Hallam-Baker , namedroppers From: Nicholas Weaver Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Date: Mon, 9 Aug 2010 08:15:11 -0700 To: Florian Weimer X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 9, 2010, at 2:31 AM, Florian Weimer wrote: > * Nicholas Weaver: >=20 >> Validating on the recursive resolver ranges between useless and >> dangerous. >=20 > How do you prevent cache poisoning without adding a validator to the > cache? Out of path attacker cache poisoning is eliminated by a combination of = query entropy (if 40b is not sufficient from a combination of port = randomization and 0x20, adopt EDNS0 ping) and glue policy (eliminates = race-until-win attacks and all attacks using ancillatory data). Unbound has successfully implemented such policies since shortly after = details of the Kaminski attack went public. =20 See = http://tools.ietf.org/html/draft-weaver-dnsext-fr-comprehensive-00#section= -10 for a detailed discussion of such glue policies and the rather = negligible performance impact they have (almost no increase in response = latency, a ~20% or so increase in query traffic). That Bind has not implemented these policies I find well, evidence of = tragic neglect at best. There are less charitable explanations. In-path attacker cache poisoning (where the attacker can see the actual = packets) generally does not matter, because such attackers are ONLY = relevant in the very rare case where the DNS traffic is NOT on the same = path as the final application traffic. [1] This is why I say that validating on the independent recursive resolver = is, at best, useless. And I lied slightly: there is one attacker who's in path on DNS but not = in path on the final traffic: the independent recursive resolver itself, = which we have seen in practice is malicious [2]. This is why I say that I'd rather trust Bernie Madoff to audit his books = than the independent recursive resolver to validate DNSSEC. > Keep in mind that a validator behind a non-validating cache has no way > to recover from bad data which has entered the cache. If you think > that DNS cache poisoning attacks are likely (and why else would you > deploy DNSSEC?), this should be a concern to you. It might only be a > denial of service, but that could still be quite annoying and cause > significant call center costs. Actually, a validator behind a non-validating cache has a great way to = recover from bad data: just do an iterative query and bypass the = non-validating cache! =20 In fact, I argue strongly that a validator behind a cache should react = to ALL DNSSEC failure or even lack of DNSSEC altogether by performing = such a fetch, accepting the resulting data regardless of DNSSEC = validation, and just using its own (small) cache for efficiency. Thats = hardly hard code to write, and far easier than validating DNSSEC = signatures. [3] And if you want to talk Denial of Service, that IS validating on the = not-end-host cache: 99% of the DNSSEC failures at least (quite possibly = 99.9 to 100%) will be misconfigurations etc. Thus taking any action = that results in the name not resolving is NOT improving security, but = rather a DOS on DNS. This is why I say that validating on the independent recursive resolver = is most likely dangerous unless the results of validation are always = ignored (in which case, why validate?). [1] Remember, an application using a A/AAAA record from DNS falls into = one of two categories: trivially pillaged by the same MitM who could = have pillaged the DNS request, OR not trusting DNS because a bad A = record is just another MitM.=20 [2] Such malice, which we have directly observed with Netalyzr, ranges = from the relatively benign (NXDOMAIN wildcarding, site-local blocking = policy) to moderately damaging (SERFAIL wildcarding) to the outright = malicious (ISPs that MitM search (www.google.com, search.yahoo.com, = www.bing.com) using DNS, malicious DNS resolvers that cause = ad.doubleclick.net to serve up 'male enhancement' ads). [3] Yes, this will hammer the authorities for domains that don't do = DNSSEC or which have a DNSSEC problem. You want to have authorities = have a reason to deploy DNSSEC, no? =20 Because unless you are storing key material or the like in DNS, OR you = have some mandate-from-on-high to add useless "security" to say you are = secure, deploying DNSSEC on your domain is a Bad Thing (tm): reduces = reliability, adds tons of hastle, but doesn't do jack for actual = security. From owner-namedroppers@ops.ietf.org Mon Aug 9 08:39: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 E0D013A69CE; Mon, 9 Aug 2010 08:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.94 X-Spam-Level: X-Spam-Status: No, score=-99.94 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 zUdq0zJBvk-Q; Mon, 9 Aug 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 DB1D83A67AE; Mon, 9 Aug 2010 08:39:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiUOY-000GBN-BG for namedroppers-data0@psg.com; Mon, 09 Aug 2010 15:36:10 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiUOV-000GAp-Hn for namedroppers@ops.ietf.org; Mon, 09 Aug 2010 15:36: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 266081ECB41D; Mon, 9 Aug 2010 15:36:05 +0000 (UTC) Date: Mon, 9 Aug 2010 11:36:03 -0400 From: Andrew Sullivan To: Simon Josefsson Cc: RFC Errata System , rdroms.ietf@gmail.com, jari.arkko@piuha.net, ogud@ogud.com, paul@noc4.net, namedroppers@ops.ietf.org Subject: [dnsext] Re: [Technical Errata Reported] RFC4398 (2460) Message-ID: <20100809153603.GH47951@shinkuro.com> References: <20100807204424.80CD6E06B3@rfc-editor.org> <8739upo3zw.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8739upo3zw.fsf@mocca.josefsson.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: Thanks for checking this. The erratum is fine. On Sun, Aug 08, 2010 at 11:20:03AM +0200, Simon Josefsson wrote: > Thanks for the report. It appears correct to me. > > /Simon > > RFC Errata System writes: > > > The following errata report has been submitted for RFC4398, > > "Storing Certificates in the Domain Name System (DNS)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=4398&eid=2460 > > > > -------------------------------------- > > Type: Technical > > Reported by: Paul Freeman > > > > Section: 2 > > > > Original Text > > ------------- > > 2. The CERT Resource Record > > > > The CERT resource record (RR) has the structure given below. Its RR > > type code is 37. > > > > 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | type | key tag | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | algorithm | / > > +---------------+ certificate or CRL / > > / / > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > > > > Corrected Text > > -------------- > > 2. The CERT Resource Record > > > > The CERT resource record (RR) has the structure given below. Its RR > > type code is 37. > > > > 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | type | key tag | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | algorithm | / > > +---------------+ certificate or CRL / > > / / > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > > > > Notes > > ----- > > In Section 2 (The CERT Resource Record) the table describing the wire format of the CERT RR is misaligned in such a way that it could lead to technical ambiguity of field positions within the packet structure. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC4398 (draft-ietf-dnsext-rfc2538bis-09) > > -------------------------------------- > > Title : Storing Certificates in the Domain Name System (DNS) > > Publication Date : March 2006 > > Author(s) : S. Josefsson > > Category : PROPOSED STANDARD > > Source : DNS Extensions > > Area : Internet > > Stream : IETF > > Verifying Party : IESG -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Aug 9 08: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 8A5243A698B; Mon, 9 Aug 2010 08:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.654 X-Spam-Level: ** X-Spam-Status: No, score=2.654 tagged_above=-999 required=5 tests=[AWL=-0.696, 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 RGMcYN4yHQGp; Mon, 9 Aug 2010 08:52:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 555FB3A6981; Mon, 9 Aug 2010 08:52:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiUbW-000IGM-QY for namedroppers-data0@psg.com; Mon, 09 Aug 2010 15:49:34 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiUbU-000IFX-0v for namedroppers@ops.ietf.org; Mon, 09 Aug 2010 15:49:32 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1OiUbI-0002Kl-KU; Mon, 09 Aug 2010 15:49:20 +0000 Received: by bfk.de with local id 1OiUbI-0003j4-Du; Mon, 09 Aug 2010 15:49:20 +0000 To: Nicholas Weaver Cc: Alex Bligh , Joe Abley , Phillip Hallam-Baker , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> <82r5i8p1xj.fsf@mid.bfk.de> <3C27B9EE-D75B-483B-9D02-B660C539A477@ICSI.Berkeley.EDU> From: Florian Weimer Date: Mon, 09 Aug 2010 15:49:20 +0000 In-Reply-To: <3C27B9EE-D75B-483B-9D02-B660C539A477@ICSI.Berkeley.EDU> (Nicholas Weaver's message of "Mon\, 9 Aug 2010 08\:15\:11 -0700") Message-ID: <8239unokfz.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Nicholas Weaver: > Out of path attacker cache poisoning is eliminated by a combination > of query entropy (if 40b is not sufficient from a combination of > port randomization and 0x20, adopt EDNS0 ping) and glue policy > (eliminates race-until-win attacks and all attacks using ancillatory > data). My belief is that this is too tricky to get right. Until someone comes up with a formal model for DNS data correctness (that is, a formal model based on which it is possible to tell whether a resolver answer is consistent with data it has received from upstream servers) and at least semi-formally validates an implementation against it, this is not going to change. In addtion to that, on IPv4, it is also impossible to move beyond 20-something bits due to network layer characteristics (even EDNS0 does not help there), and you have to rely mostly on the TTL. > Unbound has successfully implemented such policies since shortly > after details of the Kaminski attack went public. > See > http://tools.ietf.org/html/draft-weaver-dnsext-fr-comprehensive-00#sectio= n-10 > for a detailed discussion of such glue policies and the rather > negligible performance impact they have (almost no increase in > response latency, a ~20% or so increase in query traffic). At least some of the advice in that section is incorrect. For instance, it is unsafe to return a CNAME even if it is the direct answer to a query because Kaminsky-style attacks are still possible if you do that. In order to plug this hole, you need to check if the CNAME you've received conflicts with an existing cache entry and return SERVFAIL if it does. This has the potential of breaking name resolution, unfortunately. I also wonder how your resolution algorithm learns that a new delegation exists, while still avoiding to cache an incorrect delegation at an empty non-terminal. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Mon Aug 9 09:37: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 E524B3A684B; Mon, 9 Aug 2010 09:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.071 X-Spam-Level: * X-Spam-Status: No, score=1.071 tagged_above=-999 required=5 tests=[AWL=-1.034, 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 5TgmapvCjkhw; Mon, 9 Aug 2010 09:37:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C71843A686A; Mon, 9 Aug 2010 09:37:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiVH7-000Oda-D2 for namedroppers-data0@psg.com; Mon, 09 Aug 2010 16:32:33 +0000 Received: from [209.85.210.52] (helo=mail-pz0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiVH4-000Od5-Ce for namedroppers@ops.ietf.org; Mon, 09 Aug 2010 16:32:30 +0000 Received: by pzk27 with SMTP id 27so6050486pzk.11 for ; Mon, 09 Aug 2010 09:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=qMp+3Uv2jdFmCvqqLZjP3HKOQFjqcNQ87YuM6C7bdjA=; b=MXhsiQ60Rz8CRN0SFfuewWMlaC8FZRA8zZezqKty6SLNj9fyt2t1M+y+xRozIL1HRK zfK4JuEC76F3Y2WtqxE5+/MBtnDiJ7DFtZpjqqZ5nGALTIfp41MrZ4XXbHeQoEFUUoh7 ezV1A/97rLXCUSVa7RK0pUThGAUTh+ph5X2qk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=VcLwdIflt0q1se978iv0kXnY6ZOf+Byv/FjHISdjn35IPlZDwwBpLolaud2Xi1HKFI OADNUKBfU9pOF6JeoBywCb/rMSXiMZcDtozgTjTpnonCONwdCWNoqR3FtlU6y/B7tV1s jPvqvtPDQDWCfe9L19/GF1hkpt76bkZCA8gpw= Received: by 10.142.107.8 with SMTP id f8mr3312700wfc.200.1281371549942; Mon, 09 Aug 2010 09:32:29 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id n2sm6742368wfl.13.2010.08.09.09.32.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 09 Aug 2010 09:32:27 -0700 (PDT) References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> <82r5i8p1xj.fsf@mid.bfk.de> <3C27B9EE-D75B-483B-9D02-B660C539A477@ICSI.Berkeley.EDU> <8239unokfz.fsf@mid.bfk.de> In-Reply-To: <8239unokfz.fsf@mid.bfk.de> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <2962C4A4-A359-4099-9212-15E849FD79D8@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , Alex Bligh , Joe Abley , Phillip Hallam-Baker , namedroppers From: Nicholas Weaver Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications Date: Mon, 9 Aug 2010 09:32:25 -0700 To: Florian Weimer X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 9, 2010, at 8:49 AM, Florian Weimer wrote: > * Nicholas Weaver: >=20 >> Out of path attacker cache poisoning is eliminated by a combination >> of query entropy (if 40b is not sufficient from a combination of >> port randomization and 0x20, adopt EDNS0 ping) and glue policy >> (eliminates race-until-win attacks and all attacks using ancillatory >> data). >=20 > My belief is that this is too tricky to get right. Until someone > comes up with a formal model for DNS data correctness (that is, a > formal model based on which it is possible to tell whether a resolver > answer is consistent with data it has received from upstream servers) > and at least semi-formally validates an implementation against it, > this is not going to change. What do you find missing in the notion of scoping and validation? Its actually far simpler and clearer than bailywick checking as its = currently done in Bind. > In addtion to that, on IPv4, it is also impossible to move beyond > 20-something bits due to network layer characteristics (even EDNS0 > does not help there), and you have to rely mostly on the TTL. Uh, actually, this is false: 16B for transaction ID 12B for port # 8+B for 0x20 [1] EDNS0 ping can add an arbitrary amount of additional entropy if adopted. That Bind does not even do 0x20! I find remarkable in its absence. [1] If you eliminate all ancillatory data attacks, the 1.123.com = kaminski variant doesn't matter, so it becomes the 0x20 entropy for the = actual name targeted, which makes it 8+B in real word practice. >=20 >> Unbound has successfully implemented such policies since shortly >> after details of the Kaminski attack went public. >=20 >> See >> = http://tools.ietf.org/html/draft-weaver-dnsext-fr-comprehensive-00#section= -10 >> for a detailed discussion of such glue policies and the rather >> negligible performance impact they have (almost no increase in >> response latency, a ~20% or so increase in query traffic). >=20 > At least some of the advice in that section is incorrect. For > instance, it is unsafe to return a CNAME even if it is the direct > answer to a query because Kaminsky-style attacks are still possible if > you do that. In order to plug this hole, you need to check if the > CNAME you've received conflicts with an existing cache entry and > return SERVFAIL if it does. This has the potential of breaking name > resolution, unfortunately. no, because if you have an existing cache entry you don't do a query at = all. This is safe: If X is not in the cache, query for X from the authority returns X CNAME Y Y A Z There are two options, BOTH of which are safe from a kaminski variant. A: Collapse the CNAME (Ota's suggestion from a long time ago) to be X A = Z and return it. B: Cache X CNAME Y, do a new fetch for Y if Y is not already cached. In both cases, an attacker can't trigger a race-until-win with an out of = path injected reply. Because Y A Z is not introduced into the cache in = either case without a separate fetch, so an attacker who wants to inject = Y A Z into the cache by querying for a series of X's, if the resolver = implements case A the attacker can't do anything for Y with this, and if = the resolver implements case B, a successful race only triggers another = race (to poison Y A Z) There are resolvers that don't blindly accept CNAME chains, instead = doing B. (We test for this in Netalyzr, see = cname.n1.netalyzr.icsi.berkeley.edu ). It doesn't break things to do = so. > I also wonder how your resolution algorithm learns that a new > delegation exists, while still avoiding to cache an incorrect > delegation at an empty non-terminal. This is the observation that the other use of ancillatory data is = voiding data. Doing a new independent fetch triggered on such = conflicting ancillatory is safe, because that requires a = double-race-until-win, which is exponentially harder for an attacker. From owner-namedroppers@ops.ietf.org Mon Aug 9 09:55: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 ACE803A6836; Mon, 9 Aug 2010 09:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.185 X-Spam-Level: X-Spam-Status: No, score=-99.185 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 AsRDxybcVhmC; Mon, 9 Aug 2010 09:55:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1716C3A6B0C; Mon, 9 Aug 2010 09:55:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiVac-0001es-Ag for namedroppers-data0@psg.com; Mon, 09 Aug 2010 16:52:42 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiVaa-0001eS-7f for namedroppers@ops.ietf.org; Mon, 09 Aug 2010 16:52:40 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E68061ECB41D for ; Mon, 9 Aug 2010 16:52:38 +0000 (UTC) Date: Mon, 9 Aug 2010 12:52:37 -0400 From: Andrew Sullivan To: namedroppers Subject: Moderation message (was: [dnsext] Charter discussion - Use of DNSSEC in applications) Message-ID: <20100809165236.GM47951@shinkuro.com> References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> <82r5i8p1xj.fsf@mid.bfk.de> <3C27B9EE-D75B-483B-9D02-B660C539A477@ICSI.Berkeley.EDU> <8239unokfz.fsf@mid.bfk.de> <2962C4A4-A359-4099-9212-15E849FD79D8@ICSI.Berkeley.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2962C4A4-A359-4099-9212-15E849FD79D8@ICSI.Berkeley.EDU> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, On Mon, Aug 09, 2010 at 09:32:25AM -0700, Nicholas Weaver wrote: > > What do you find missing in the notion of scoping and validation? > > Its actually far simpler and clearer than bailywick checking as its currently done in Bind. [&c.] I can find nothing in this message about using DNSSEC in applications nor about the DNSEXT charter. Moreover, Olafur and I have already made it clear that DNSSEC in applications, apart from any new RRTYPE, is just not going to be on-charter for this WG. To begin with, it needs to attract attention of applications types, and we have a recent example of the apparent indifference of applications area participants to what goes on in DNSEXT. So, if one wants to continue exploring this part of the maze, I urge you at least to change the subject line. Thanks, A (as moderator) -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Aug 9 10:02: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 63DCF3A6955; Mon, 9 Aug 2010 10:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.017 X-Spam-Level: *** X-Spam-Status: No, score=3.017 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_54=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 f7wUEI3Lm7zC; Mon, 9 Aug 2010 10:02:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C5DC3A679F; Mon, 9 Aug 2010 10:02:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiVhf-0002q1-Vp for namedroppers-data0@psg.com; Mon, 09 Aug 2010 17:00:00 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiVhc-0002pK-Sh for namedroppers@ops.ietf.org; Mon, 09 Aug 2010 16:59:57 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1OiVhV-0007wa-UD; Mon, 09 Aug 2010 16:59:49 +0000 Received: by bfk.de with local id 1OiVhV-0001V8-Np; Mon, 09 Aug 2010 16:59:49 +0000 To: Nicholas Weaver Cc: Alex Bligh , Joe Abley , Phillip Hallam-Baker , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> <82r5i8p1xj.fsf@mid.bfk.de> <3C27B9EE-D75B-483B-9D02-B660C539A477@ICSI.Berkeley.EDU> <8239unokfz.fsf@mid.bfk.de> <2962C4A4-A359-4099-9212-15E849FD79D8@ICSI.Berkeley.EDU> From: Florian Weimer Date: Mon, 09 Aug 2010 16:59:49 +0000 In-Reply-To: <2962C4A4-A359-4099-9212-15E849FD79D8@ICSI.Berkeley.EDU> (Nicholas Weaver's message of "Mon\, 9 Aug 2010 09\:32\:25 -0700") Message-ID: <8239unn2m2.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Nicholas Weaver: >> My belief is that this is too tricky to get right. Until someone >> comes up with a formal model for DNS data correctness (that is, a >> formal model based on which it is possible to tell whether a resolver >> answer is consistent with data it has received from upstream servers) >> and at least semi-formally validates an implementation against it, >> this is not going to change. > > What do you find missing in the notion of scoping and validation? > > Its actually far simpler and clearer than bailywick checking as its curre= ntly done in Bind. > > >> In addtion to that, on IPv4, it is also impossible to move beyond >> 20-something bits due to network layer characteristics (even EDNS0 >> does not help there), and you have to rely mostly on the TTL. > > Uh, actually, this is false: > > 16B for transaction ID > 12B for port # > 8+B for 0x20 [1] There is a hidden assumption there concerning atomic message delivery, which is just not provided by the network layer (at least for IPv4, IPv6 is much closer). >> At least some of the advice in that section is incorrect. For >> instance, it is unsafe to return a CNAME even if it is the direct >> answer to a query because Kaminsky-style attacks are still possible if >> you do that. In order to plug this hole, you need to check if the >> CNAME you've received conflicts with an existing cache entry and >> return SERVFAIL if it does. This has the potential of breaking name >> resolution, unfortunately. > > no, because if you have an existing cache entry you don't do a query > at all. What you do if you've got an A RR in cache, and receive a QTYPE=3DAAAA query? You send out a new upstream transaction, and you might receive a CNAME for that. What do you do with it? Problems like this are the reason why we need a formal model. Otherwise, we can't be sure that we've covered all corner cases. >> I also wonder how your resolution algorithm learns that a new >> delegation exists, while still avoiding to cache an incorrect >> delegation at an empty non-terminal. > > This is the observation that the other use of ancillatory data is > voiding data. Doing a new independent fetch triggered on such > conflicting ancillatory is safe, because that requires a > double-race-until-win, which is exponentially harder for an > attacker. So you propose to query the parent again at the newly found delegation point? Wouldn't that double the query load on delegation-centric zones? At that cost, it's better to get rid of the amplification effect of caches altogether and cache responses for delivery to clients only after they have stabilized. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Mon Aug 9 10:24: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 8FA643A6B1C; Mon, 9 Aug 2010 10:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.456 X-Spam-Level: * X-Spam-Status: No, score=1.456 tagged_above=-999 required=5 tests=[AWL=-0.650, 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 JRseWACMgJVj; Mon, 9 Aug 2010 10:24:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E7CC83A694A; Mon, 9 Aug 2010 10:24:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiW1l-00065E-Cq for namedroppers-data0@psg.com; Mon, 09 Aug 2010 17:20:45 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiW1h-00064k-GD for namedroppers@ops.ietf.org; Mon, 09 Aug 2010 17:20:41 +0000 Received: by fxm10 with SMTP id 10so207754fxm.11 for ; Mon, 09 Aug 2010 10:20:37 -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; bh=QjFmpWQpYY7FLIbnJ1alYQMUOTodyaDcib81J0YUHYs=; b=iDiB5TBFwh9NoeQibF1njgouVKCRxOKD7fAWfLzXLy/D02FO0NhGBflSAjtV1c9H27 ZZyOppAPYlg7FnKkx0MIyCT9WBw3uS6p0gFwfFaJntdyNtsUnOSCf12fVQ9oYzOzXzjU TUfR59g7iIGuM9WxU7SVDlrW0KhZc82FOwim4= 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=OjzxMIO+7/39XnV+Oby5aHGHUSVMLXVfxPewCy/KuIp+iLAhh1F4JjLuiTGKXesLQ9 fPjBvG7BcCqJPR5GWKTqgMmvruslKZy1zfJ5kBXri1B8b2I1xAvzk4eEf6AqaznMPLra j1qNU4RbuLQGEp6X2wzHL+QLAWyYJfjBwVrNk= MIME-Version: 1.0 Received: by 10.223.116.6 with SMTP id k6mr16909085faq.49.1281374437057; Mon, 09 Aug 2010 10:20:37 -0700 (PDT) Received: by 10.223.50.154 with HTTP; Mon, 9 Aug 2010 10:20:37 -0700 (PDT) In-Reply-To: <3C27B9EE-D75B-483B-9D02-B660C539A477@ICSI.Berkeley.EDU> References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> <82r5i8p1xj.fsf@mid.bfk.de> <3C27B9EE-D75B-483B-9D02-B660C539A477@ICSI.Berkeley.EDU> Date: Mon, 9 Aug 2010 14:20:37 -0300 Message-ID: Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications From: Brian Dickson To: Nicholas Weaver Cc: Florian Weimer , Alex Bligh , Joe Abley , Phillip Hallam-Baker , namedroppers Content-Type: multipart/alternative; boundary=001636eef06425250f048d673cc9 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001636eef06425250f048d673cc9 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 9, 2010 at 12:15 PM, Nicholas Weaver wrote: > > On Aug 9, 2010, at 2:31 AM, Florian Weimer wrote: > > > * Nicholas Weaver: > > > >> Validating on the recursive resolver ranges between useless and > >> dangerous. > > > > How do you prevent cache poisoning without adding a validator to the > > cache? > > [snip] > > And I lied slightly: there is one attacker who's in path on DNS but not in > path on the final traffic: the independent recursive resolver itself, which > we have seen in practice is malicious [2]. > s/is/can be/ - there are plenty of non-malicious third-party resolvers (where "plenty" needs only be "at least one"). > Actually, a validator behind a non-validating cache has a great way to > recover from bad data: just do an iterative query and bypass the > non-validating cache! > > In fact, I argue strongly that a validator behind a cache should react to > ALL DNSSEC failure or even lack of DNSSEC altogether by performing such a > fetch, accepting the resulting data regardless of DNSSEC validation, and > just using its own (small) cache for efficiency. Thats hardly hard code to > write, and far easier than validating DNSSEC signatures. [3] > > I expect that those end-user (hosts) who want validation, who don't have a resolver that validates, at this stage, to be sufficiently knowledgeable and/or resourceful enough, to install personal validating recursive resolvers, thus avoiding your suggested "clever" idea. I see no reason to suspect the possibility that non-validating caches are likely to remain a long-term issue - or even a short-term issue. > [3] Yes, this will hammer the authorities for domains that don't do DNSSEC > or which have a DNSSEC problem. You want to have authorities have a reason > to deploy DNSSEC, no? > > Because unless you are storing key material or the like in DNS, OR you have > some mandate-from-on-high to add useless "security" to say you are secure, > deploying DNSSEC on your domain is a Bad Thing (tm): reduces reliability, > adds tons of hastle, but doesn't do jack for actual security. > > Sorry, going to have to call BS on this one. (But Sir!) The Kaminsky style attack is only possible because the resolver _is_ a resolver, and scales well for the attacker because the multiplier effect (resolver -> stubs) yields significant numbers of victims. The quantity of victims is only relevant if the domain "target" can be spoofed/poisoned, and has intrinsic value (e.g. somewhere users would expect to enter sensitive information, like a bank or on-line purchase site.) Even if the stub resolvers do not validate, having recursive resolvers that validate and authority servers that serve DNSSEC answers, removes the Kaminsky vector entirely -- for _those_ domains and _those_ resolvers' clients. The effort/return on trying to attack individual users' stub connections to resolvers is several orders of magnitude harder than attacking recursive resolvers. There is no mechanism to trigger the client to make queries to domains of the attackers choosing. There is no way for the attacker to know apriori what the recursive resolver being used is, on a specific IP address basis. And the benefits of attacking a single user are extremely minor, relatively speaking. This means that there is intrinsically competitive pressure amongst content-side folks (like banks or online retailers) to implement DNSSEC, and competitive pressure among third-party resolver operators to deploy validation. Enterprise resolvers have intrinsic regulatory pressure and/or owner/shareholder pressure to deploy validation. Once those pressures are visible in the marketplace, the pattern of adoption rates will resemble those of an epidemic - slow start ramping up, starting exponentially and eventually tailing off after the 50% mark. There will always be tail-enders. Note that the benefits are seen even without end-node (stub resolver) implementation. Further benefits are seen once stubs implement too. And competitive pressure helps adoption of DNSSEC, rather than your theory of being an impediment. Brian --001636eef06425250f048d673cc9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 9, 2010 at 12:15 PM, Nichola= s Weaver <nweaver@icsi.berkeley.edu> wrote:

On Aug 9, 2010, at 2:31 AM, Florian Weimer wrote:

> * Nicholas Weaver:
>
>> Validating on the recursive resolver ranges between useless and >> dangerous.
>
> How do you prevent cache poisoning without adding a validator to the > cache?

[snip]

And I lied slightly: there is one attacker who's in path on DNS but not= in path on the final traffic: the independent recursive resolver itself, w= hich we have seen in practice is malicious [2].

s/is/can be/ - there are plenty of non-malicious third-party resolvers (whe= re "plenty" needs only be "at least one").=A0
=

=A0
Actually, a validator behind a non-validating cache has a great way to reco= ver from bad data: just do an iterative query and bypass the non-validating= cache!

In fact, I argue strongly that a validator behind a cache should react to A= LL DNSSEC failure or even lack of DNSSEC altogether by performing such a fe= tch, accepting the resulting data regardless of DNSSEC validation, and just= using its own (small) cache for efficiency. =A0 Thats hardly hard code to = write, and far easier than validating DNSSEC signatures. =A0[3]


I expect that those end-user (hosts) who want val= idation, who don't have a resolver that validates, at this stage, to be= sufficiently knowledgeable and/or resourceful enough, to install personal = validating recursive resolvers, thus avoiding your suggested "clever&q= uot; idea.

I see no reason to suspect the possibility that non-validating caches a= re likely to remain a long-term issue - or even a short-term issue.
=A0<= /div>
[3] Yes, this will hammer the authorities for domains that don't do DNS= SEC or which have a DNSSEC problem. =A0You want to have authorities have a = reason to deploy DNSSEC, no?

Because unless you are storing key material or the like in DNS, OR you have= some mandate-from-on-high to add useless "security" to say you a= re secure, deploying DNSSEC on your domain is a Bad Thing (tm): reduces rel= iability, adds tons of hastle, but doesn't do jack for actual security.=


Sorry, going to have to call BS on this one. (But= Sir!)

The Kaminsky style attack is only possible because the resolv= er _is_ a resolver, and scales well for the attacker because the multiplier= effect (resolver -> stubs) yields significant numbers of victims. The q= uantity of victims is only relevant if the domain "target" can be= spoofed/poisoned, and has intrinsic value (e.g. somewhere users would expe= ct to enter sensitive information, like a bank or on-line purchase site.)
Even if the stub resolvers do not validate, having recursive resolvers = that validate and authority servers that serve DNSSEC answers, removes the = Kaminsky vector entirely -- for _those_ domains and _those_ resolvers' = clients.

The effort/return on trying to attack individual users' stub connec= tions to resolvers is several orders of magnitude harder than attacking rec= ursive resolvers. There is no mechanism to trigger the client to make queri= es to domains of the attackers choosing. There is no way for the attacker t= o know apriori what the recursive resolver being used is, on a specific IP = address basis. And the benefits of attacking a single user are extremely mi= nor, relatively speaking.

This means that there is intrinsically competitive pressure amongst con= tent-side folks (like banks or online retailers) to implement DNSSEC, and c= ompetitive pressure among third-party resolver operators to deploy validati= on. Enterprise resolvers have intrinsic regulatory pressure and/or owner/sh= areholder pressure to deploy validation.

Once those pressures are visible in the marketplace, the pattern of ado= ption rates will resemble those of an epidemic - slow start ramping up, sta= rting exponentially and eventually tailing off after the 50% mark. There wi= ll always be tail-enders.

Note that the benefits are seen even without end-node (stub resolver) i= mplementation. Further benefits are seen once stubs implement too.

A= nd competitive pressure helps adoption of DNSSEC, rather than your theory o= f being an impediment.

Brian

--001636eef06425250f048d673cc9-- From dnsext-archive@ietf.org Mon Aug 9 12:00: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 040EE3A6B42 for ; Mon, 9 Aug 2010 12:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.81 X-Spam-Level: X-Spam-Status: No, score=-78.81 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, J_CHICKENPOX_41=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, 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 fapjfz6rFRTf for ; Mon, 9 Aug 2010 12:00:36 -0700 (PDT) Received: from 65-29-124-91.pool.ukrtel.net (65-29-124-91.pool.ukrtel.net [91.124.29.65]) by core3.amsl.com (Postfix) with SMTP id E6E973A6B39 for ; Mon, 9 Aug 2010 12:00:23 -0700 (PDT) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20100809220651.2665.qmail@65-29-124-91.pool.ukrtel.net> To: Subject: Best Sales 2010! From: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Mon, 9 Aug 2010 12:00:23 -0700 (PDT) http://groups.yahoo.com/group/cngsuruoh/message Eskimo. Nein, diese herrliche, schopferisch gestaltende Fahigkeit ist eben gerade dem Arier verliehen, ob er sie schlummernd noch in sich tragt oder sie dem erwachenden Leben schenkt, je nachdem gunstige Umstande dies gestatten oder eine unwirtliche Natur verhindert. Daraus ergibt sich folgende Erkenntnis: Der Staat ist ein Mittel zum Zweck. Sein Zweck liegt in der Erhaltung und Forderung einer Gemeinschaft physisch und seelisch gleichartiger Lebewesen. Diese Erhaltung selber umfa.t erstlich den rassenma.igen Bestand und gestattet dadurch die freie Entwicklung aller in dieser Rasse schlummernden Krafte. Von ihnen wird immer wieder ein Teil in erster Linie der {434 Nationalsozialistische Auffassung vom Staat} Erhaltung des p From xaeca7351@comcast.net Mon Aug 9 18:18: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 0C7673A691B for ; Mon, 9 Aug 2010 18:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.36 X-Spam-Level: X-Spam-Status: No, score=-46.36 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, 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, URIBL_BLACK=20, 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 YR4dWmRggGp7 for ; Mon, 9 Aug 2010 18:18:56 -0700 (PDT) Received: from comcast.net (c-68-33-244-203.hsd1.md.comcast.net [68.33.244.203]) by core3.amsl.com (Postfix) with ESMTP id CA3623A68CE for ; Mon, 9 Aug 2010 18:18:54 -0700 (PDT) From: To: dnsext-archive@ietf.org Date: Mon, 9 Aug 2010 21:19:29 -0400 Subject: Get set to grow and grow Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100810011854.CA3623A68CE@core3.amsl.com> Enlarging your organ is easy with this http://www.anglenoise.ru/ From owner-namedroppers@ops.ietf.org Tue Aug 10 06:22: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 7629C3A67C2; Tue, 10 Aug 2010 06:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=-1.535, 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 KCFHev8Xey-U; Tue, 10 Aug 2010 06:22:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D71AB3A68C7; Tue, 10 Aug 2010 06:22:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oiof1-000BJu-OV for namedroppers-data0@psg.com; Tue, 10 Aug 2010 13:14:31 +0000 Received: from [131.111.8.131] (helo=ppsw-31.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oioey-000BJZ-KN for namedroppers@ops.ietf.org; Tue, 10 Aug 2010 13:14:28 +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]:35107) by ppsw-31.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Oioet-0004gU-LS (Exim 4.72) (return-path ); Tue, 10 Aug 2010 14:14:23 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Oioet-0005lb-KR (Exim 4.67) (return-path ); Tue, 10 Aug 2010 14:14:23 +0100 Date: Tue, 10 Aug 2010 14:14:23 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Brian Dickson cc: Nicholas Weaver , Florian Weimer , Alex Bligh , Joe Abley , Phillip Hallam-Baker , namedroppers Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications In-Reply-To: Message-ID: References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> <82r5i8p1xj.fsf@mid.bfk.de> <3C27B9EE-D75B-483B-9D02-B660C539A477@ICSI.Berkeley.EDU> 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 Mon, 9 Aug 2010, Brian Dickson wrote: > On Mon, Aug 9, 2010 at 12:15 PM, Nicholas Weaver > wrote: > > > > Actually, a validator behind a non-validating cache has a great way to > > recover from bad data: just do an iterative query and bypass the > > non-validating cache! > > > > In fact, I argue strongly that a validator behind a cache should react to > > ALL DNSSEC failure or even lack of DNSSEC altogether by performing such a > > fetch, accepting the resulting data regardless of DNSSEC validation, and > > just using its own (small) cache for efficiency. Thats hardly hard code to > > write, and far easier than validating DNSSEC signatures. [3] > > I expect that those end-user (hosts) who want validation, who don't have a > resolver that validates, at this stage, to be sufficiently knowledgeable > and/or resourceful enough, to install personal validating recursive > resolvers, thus avoiding your suggested "clever" idea. You can implement something like this idea by configuring BIND to use a forwarder with the "forward first" option. (It probably doesn't have quite the right fail-over logic, though.) The main problem is likely to be with end hosts behind a firewall that blocks DNS queries which do not go via the network's recursor. Tony. -- f.anthony.n.finch http://dotat.at/ IRISH SEA: SOUTHWEST, VEERING NORTHWEST, 5 OR 6. SLIGHT OR MODERATE. SHOWERS, THUNDERY AT FIRST. MODERATE OR GOOD. From owner-namedroppers@ops.ietf.org Tue Aug 10 06:41: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 F03193A69F4; Tue, 10 Aug 2010 06:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.932 X-Spam-Level: X-Spam-Status: No, score=-99.932 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 iOHz5Dd8RUAJ; Tue, 10 Aug 2010 06:41:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F60A3A69E0; Tue, 10 Aug 2010 06:41:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oip0h-000EwE-MK for namedroppers-data0@psg.com; Tue, 10 Aug 2010 13:36:55 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oip0e-000Evg-Qj for namedroppers@ops.ietf.org; Tue, 10 Aug 2010 13:36:52 +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 41B2F1ECB41D for ; Tue, 10 Aug 2010 13:36:51 +0000 (UTC) Date: Tue, 10 Aug 2010 09:36:49 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] DNSEXT charter and treating DNS names as "the same" Message-ID: <20100810133649.GC52191@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, One of our primary goals for DNSEXT at IETF 78 was to get feedback from the user community (in particular, we aimed at application developers) who have the "aliasing" and "sameness" problem(s) with the DNS. Unfortunately, we were unable to attract many such participants. It is clear to us that none of the proposals now before DNSEXT addresses all the problems that people have. As far as we are able to tell, there are needs with respect to domain names, with respect to whole trees in the DNS, and perhaps with respect to individual labels no matter where they might appear in a domain name. None of the proposals handles all of these, and some of these needs are not addressed at all. We appear to be faced with a choice among three basic strategies: 1. Experiment: Since we don't know what the problems are, but we have people proposing solutions, we could adopt the proposed solutions experimentally, and evaluate in (say) five years whether the proposals solved the problems people have. 2. Limp along: We could accept that no proposal will solve everything, and "limp along" by standardizing properly the proposals we have: work towards clarity and precision in the problem statement and then proceed to work on the proposals themselves. 3. Kick it upstairs: A basic problem in all of this is that the DNS does not have a presentation layer. Domain names end up being used in presentation contexts, and that's what's broken. So, we could say that there is no problem here for the DNS, but that we are ready and willing to support building a presentation layer atop the DNS. Such a specification needs to come from elsewhere. The problem with (1) is that some of the proposals are simply impossible to do as experiments (if we change the rules for CNAME, they're effectively changed forever whether we like it or not). In addition, we think it would be a very bad idea to perform such an experiment in the root, but we expect that there would be operational pressures to do so. The problem with (2) is that we make the DNS more complicated without solving all or perhaps even most of the problems people really have. The complication will be greater than many people seem to think: for instance, the BNAME proposal as it is currently written is, as far as we can tell, simply incompatible with all the deployed validators in the world. That seems like a problem that needs addressing, and we can't see how to do so easily. The problem with (3) is that it was suggested before, and got no traction. Moreover, it's very complicated, such that the work might never complete; and in the meantime, people who have a problem have no help. We DNSEXT chairs are mostly convinced that there is no current proposal that is any simpler than just duplicating zone apex data and adding a DNAME to the "alias" zones. This suggests an option 4: 4. Provisioning only: document how to do what's needed by provisioning, and explain why the WG is not doing anything else. Before we propose another charter for the WG, we'd like to hear more arguments why any work is needed, and which of the options 1-4 seem like the best bet for that work. Best regards, Andrew and Olafur -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Aug 10 07:16: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 0B2B73A698C; Tue, 10 Aug 2010 07:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.623 X-Spam-Level: X-Spam-Status: No, score=-99.623 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_55=0.6, 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 NAMTpDAtFN4l; Tue, 10 Aug 2010 07:16:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B517D3A686B; Tue, 10 Aug 2010 07:16:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oipa5-000LHI-Sy for namedroppers-data0@psg.com; Tue, 10 Aug 2010 14:13:29 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oipa2-000LGi-Tg for namedroppers@ops.ietf.org; Tue, 10 Aug 2010 14:13:27 +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 24A351ECB41D for ; Tue, 10 Aug 2010 14:13:25 +0000 (UTC) Date: Tue, 10 Aug 2010 10:13:23 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Does DNSSEC mean BNAME is undeployable? Message-ID: <20100810141322.GD52191@shinkuro.com> References: <05B243F724B2284986522B6ACD0504D7D3442996C7@EXVPMBX100-1.exc.icann.org> <201008042142.o74LgRap031934@cichlid.raleigh.ibm.com> <05B243F724B2284986522B6ACD0504D7D3444A2AAF@EXVPMBX100-1.exc.icann.org> <20100804230904.GB4034@farside.isc.org> <05B243F724B2284986522B6ACD0504D7D3444A2CF6@EXVPMBX100-1.exc.icann.org> <20100805182146.GI38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D00@EXVPMBX100-1.exc.icann.org> <20100805183608.GJ38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D1B@EXVPMBX100-1.exc.icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05B243F724B2284986522B6ACD0504D7D3444A2D1B@EXVPMBX100-1.exc.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, When discussing the "aliasing" items for the DNSEXT charter, Olafur and I came to the conclusion that BNAME, as currently written, is simply incompatible with DNSSEC as currently deployed. That seems to me, speaking without hat, like a pretty big argument against adoption. Olafur hasn't seen this message, because he's on vacation, so whatever I get wrong here is all my fault and you shouldn't blame him. This is nevertheless my understanding of what emerged from a meeting he and I had last week. I'm posting it now in the interests of moving this work along. I'm posting as co-chair, but as a befuddled-more-than-usual (!) one. In re-reading some previous discussion, I think this actually rehashes some of those arguments. It's likely a testament to my own dimness that I didn't get this before; but in case this is helpful to others, I'm posting anyway. In summary, to implement BNAME and be compatible with all the existing validating resolvers already deployed, it will be necessary to have CNAME and DNAME records available at that same owner ("domain") name in the DNS. This is functionally equivalent to CNAME+DNAME, and therefore there is no practical reason to prefer the BNAME proposal. Remember that we have largely concluded that DNSSEC validators MUST understand DNAME (this is I think implicit in RFC 2672 and is stated baldly in draft-ietf-dnsext-rfc2672bis-dname). This means that all the validators in the world can handle DNAME, and that therefore if they get a synthetic CNAME that is unsigned, they can validate it by validating instead the DNAME. The BNAME draft as it stands attempts to place a similar requirement on validators: [. . .] In order to make BNAME valid in DNSSEC verification, the DNSSEC enabled resolvers and servers MUST support BNAME. The synthesized CNAME in the answer section for the BNAME will never be signed. DNSSEC validators MUST understand BNAME, verify the BNAME and then checking that the CNAME was properly synthesized in order to verify the synthesized CNAME. This is, of course, not going to work: there is no way to require, retroactively, that deployed code support an RRTYPE with specialized server-side rules and modified DNSSEC rules. Any existing validator will treat a BNAME-derived synthetic CNAME inside a signed zone as bogus. We may not know what all the problems are that need solving, but we have strong reason to suppose that BNAME is partly supposed to be a solution for problems in or near the root. This would mean either that validation from the very beginning of deployment would experience failures, or that we'd have a validator-upgrade flag day. Neither seems acceptable. A way around this is to solve the problem with a signalling bit (call it BA, for BNAME Aware) that allows a query originator to signal whether it can handle BNAME. If BA=1, then BNAME is handled as described in draft-yao-dnsext-bname-03. If BA=0, but DO=1, then the client gets a synthetic CNAME _and_ a synthetic DNAME. The synthetic DNAME needs to be signed as though it were a regular DNAME in the zone (which either means online signing or that the server supports having a DNAME and a BNAME at the same owner name, and has differential rules for which data it hands out). If BA=0, and DO=0, then the answer is a synthetic CNAME (and signatures don't matter). But notice that the approach effectively requires CNAME+DNAME, at least for existing resolvers that set DO=1. If that's right, then there's practically no benefit to BNAME. An alternative, of course, is to have no backward compatibility attempts (i.e. no CNAME synthesis &c). This requires a signalling bit still, but it does not require any synthesis of other RRs. The disadvantage is that no existing resolver can follow the BNAME, so the value of the effort is questionable. Also, if this argument is right, DNSSEC effectively means that future server-side processing rules are going to be very hard to justify -- even harder than they used to be. I'd appreciate comments on any of this, in light of our plan (i.e. Olafur's and mine, as chairs) to have a new version of the charter in time for our self-imposed deadline in September. Thanks, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Aug 10 08:00: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 0FDA83A694E; Tue, 10 Aug 2010 08:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.673 X-Spam-Level: * X-Spam-Status: No, score=1.673 tagged_above=-999 required=5 tests=[AWL=-0.433, 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 dDkx5jJZ8ix1; Tue, 10 Aug 2010 08:00:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3FF1B3A6864; Tue, 10 Aug 2010 08:00:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiqEj-0001St-0W for namedroppers-data0@psg.com; Tue, 10 Aug 2010 14:55:29 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiqEe-0001SL-LC for namedroppers@ops.ietf.org; Tue, 10 Aug 2010 14:55:25 +0000 Received: by fxm10 with SMTP id 10so964380fxm.11 for ; Tue, 10 Aug 2010 07:55:20 -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; bh=LIi2LwkiBzV65OTBPOKT1qVBg46HI6sMrECScoXvYNM=; b=oUwD0idSCrcfI63i37Z6iZQ8ujNe8I4aeaA+dektdp83+VpHMBqHr7SqhvDsFW188c Mm9vAjDigeWvQ3dbgB4Z06iXtTwHCYX3V9mNR7gvwGPdWEPKPQesYTvyLQhWD8240Dc/ TrTQoB/qtaR3TySuPjyjpluldJFsydpAAeJGc= 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=Z/ngDqGa82tbtQQwKcrhZ5lO+U2Lfuxd1gICTEVJ2nK677EECpItxIqHg6c54ffikB TKxunQyapWqvgOp0qOpjTa6grtqQWMAxYoBRZbGOeFQixaY1fwTZ7gtFLYTe0g8TLTB/ hi4hZu1CsMKOvxH3QYb+nqaRPIe9ibycWaLoA= MIME-Version: 1.0 Received: by 10.223.117.73 with SMTP id p9mr18295736faq.56.1281452119914; Tue, 10 Aug 2010 07:55:19 -0700 (PDT) Received: by 10.223.50.154 with HTTP; Tue, 10 Aug 2010 07:55:19 -0700 (PDT) In-Reply-To: <20100810133649.GC52191@shinkuro.com> References: <20100810133649.GC52191@shinkuro.com> Date: Tue, 10 Aug 2010 11:55:19 -0300 Message-ID: Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" From: Brian Dickson To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=001636c5b18b677875048d795221 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001636c5b18b677875048d795221 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 10, 2010 at 10:36 AM, Andrew Sullivan wrote: > Dear colleagues, > > One of our primary goals for DNSEXT at IETF 78 was to get feedback > from the user community (in particular, we aimed at application > developers) who have the "aliasing" and "sameness" problem(s) with the > DNS. Unfortunately, we were unable to attract many such participants. > > It is clear to us that none of the proposals now before DNSEXT > addresses all the problems that people have. As far as we are able to > tell, there are needs with respect to domain names, with respect to > whole trees in the DNS, and perhaps with respect to individual labels > no matter where they might appear in a domain name. None of the > proposals handles all of these, and some of these needs are not > addressed at all. > > We appear to be faced with a choice among three basic strategies: > > 1. Experiment: Since we don't know what the problems are, but we > have people proposing solutions, we could adopt the proposed > solutions experimentally, and evaluate in (say) five years whether > the proposals solved the problems people have. > > 2. Limp along: We could accept that no proposal will solve > everything, and "limp along" by standardizing properly the > proposals we have: work towards clarity and precision in the > problem statement and then proceed to work on the proposals > themselves. > > 3. Kick it upstairs: A basic problem in all of this is that the > DNS does not have a presentation layer. Domain names end up being > used in presentation contexts, and that's what's broken. So, we > could say that there is no problem here for the DNS, but that we > are ready and willing to support building a presentation layer > atop the DNS. Such a specification needs to come from elsewhere. > > The problem with (1) is that some of the proposals are simply > impossible to do as experiments (if we change the rules for CNAME, > they're effectively changed forever whether we like it or not). In > addition, we think it would be a very bad idea to perform such an > experiment in the root, but we expect that there would be operational > pressures to do so. > > I think it would be reasonable to allow experimentation, with the restriction that changes must be fully backward compatible for at least one "equivalent" name of any set of equivalent names. In other words, it can't break existing implementations for all instances of a set of equivalent names, where "break" is interpreted as widely as possible (such as "fails validation as insecure or bogus, for signed zones"). NB - I am proposing something which won't break existing implementations, and thus can be experimented with, even at the root. > The problem with (2) is that we make the DNS more complicated without > solving all or perhaps even most of the problems people really have. > The complication will be greater than many people seem to think: for > instance, the BNAME proposal as it is currently written is, as far as > we can tell, simply incompatible with all the deployed validators in > the world. That seems like a problem that needs addressing, and we > can't see how to do so easily. > > I think there is a need to address the sets of problems, and potential sets of solutions, in the mathematical sense of "spanning sets". Only if the set of problems can be covered by the set of solutions, can (2) proceed, and all of the necessary solutions to meet that conditions must be fully delivered. This, unfortunately, may require a slight divergence from standard IETF policy, in that in order to meet this condition, there may be individual proposals which don't meet the traditional general consensus, which need to be "fostered" or "sponsored" by either the chairs, the area director(s), or the IAB, and for which "abandon" is not an acceptable outcome. They have to be treated as a set, all-or-nothing, not as individual proposals. Otherwise not all cases will be covered, and thus what portions do progress are for naught. > The problem with (3) is that it was suggested before, and got no > traction. Moreover, it's very complicated, such that the work might > never complete; and in the meantime, people who have a problem have no > help. > > We DNSEXT chairs are mostly convinced that there is no current > proposal that is any simpler than just duplicating zone apex data and > adding a DNAME to the "alias" zones. This suggests an option 4: > > 4. Provisioning only: document how to do what's needed by > provisioning, and explain why the WG is not doing anything else. > > I'd like to add to 4, e.g. " (4.a.) Provisioning Enhancements: document per-implementation improvements to support provisioning-only solutions, which reduce or eliminate out-of-sync conditions for equivalent 'things'." (By per-implementation, I mean describe in general/abstract terms, what each implementation is encouraged to do, and _not_ describe in implementation-specific detail what each known existing implementation should change.) > Before we propose another charter for the WG, we'd like to hear more > arguments why any work is needed, and which of the options 1-4 seem > like the best bet for that work. > > One underlying problem specific to DNSSEC RRSIG issues (where "equivalent" things need to be signed by each of their "equivalent" parent zone owner names), is the tying of "identity" of a zone to the "owner" name of the apex data. If we want to be able have "equivalent" things and not have an arithmetic explosion of RRSIGs for those things, either the labeling needs to change, or the manner of assigning an "identity" for "signer" purposes (and thus the corresponding logic for validation) needs to change. (IMHO, the label equivalence needs to be of the first-class type, where all labels are created equal, to avoid increasing complexity and fragility.) Mark Andrews has proposed a "multi-match label" (new label type). My idea is to add a new RRset to the apex of the zone, which establishes the complete set of names by which the zone is known (and thus equivalent owners, and thus de-facto permitted signer names). Note that as the RR type would not be one of the "special few", it would be signed, just like any other RR. And for ensuring the security and sanity (and to avoid circular logic in signing), it (and it alone) would need to be signed by all the names contained in it. The additional validation logic is simple - if owner(zone) != signer(zone_entry) then { check_for_signed_zone_equivalents(owner(zone),signer(zone_entry)) } Other than that, the provisioning of zones (by copying) or linking of zones (as an enhancement) should be sufficient for most, if not all, cases. Note that the restriction of some kinds of equivalence only working for zones, can be worked around by turning anything which would otherwise be a non-apex entry in a zone, into a zone of its own. It is a clever and ugly hack, which has the benefit of being 100% backwards compatible, and can be experimented on today with no risk. Brian --001636c5b18b677875048d795221 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 10, 2010 at 10:36 AM, Andrew= Sullivan <ajs@shi= nkuro.com> wrote:
Dear colleagues,

One of our primary goals for DNSEXT at IETF 78 was to get feedback
from the user community (in particular, we aimed at application
developers) who have the "aliasing" and "sameness" prob= lem(s) with the
DNS. =A0Unfortunately, we were unable to attract many such participants.
It is clear to us that none of the proposals now before DNSEXT
addresses all the problems that people have. =A0As far as we are able to tell, there are needs with respect to domain names, with respect to
whole trees in the DNS, and perhaps with respect to individual labels
no matter where they might appear in a domain name. =A0None of the
proposals handles all of these, and some of these needs are not
addressed at all.

We appear to be faced with a choice among three basic strategies:

=A0 =A01. =A0Experiment: Since we don't know what the problems are, bu= t we
=A0 =A0have people proposing solutions, we could adopt the proposed
=A0 =A0solutions experimentally, and evaluate in (say) five years whether<= br> =A0 =A0the proposals solved the problems people have.

=A0 =A02. =A0Limp along: We could accept that no proposal will solve
=A0 =A0everything, and "limp along" by standardizing properly th= e
=A0 =A0proposals we have: work towards clarity and precision in the
=A0 =A0problem statement and then proceed to work on the proposals
=A0 =A0themselves.

=A0 =A03. =A0Kick it upstairs: A basic problem in all of this is that the<= br> =A0 =A0DNS does not have a presentation layer. =A0Domain names end up bein= g
=A0 =A0used in presentation contexts, and that's what's broken. = =A0So, we
=A0 =A0could say that there is no problem here for the DNS, but that we =A0 =A0are ready and willing to support building a presentation layer
=A0 =A0atop the DNS. =A0Such a specification needs to come from elsewhere.=

The problem with (1) is that some of the proposals are simply
impossible to do as experiments (if we change the rules for CNAME,
they're effectively changed forever whether we like it or not). =A0In addition, we think it would be a very bad idea to perform such an
experiment in the root, but we expect that there would be operational
pressures to do so.


I think it would be reasonable to allow experimen= tation, with the restriction that changes
must be fully backward compati= ble for at least one "equivalent" name of any set of equivalent n= ames.

In other words, it can't break existing implementations for all ins= tances of a set of equivalent names,
where "break" is interpre= ted as widely as possible (such as "fails validation as insecure or bo= gus, for signed zones").

NB - I am proposing something which won't break existing implementa= tions, and thus can be experimented with, even
at the root.

=A0
The problem with (2) is that we make the DNS more complicated without
solving all or perhaps even most of the problems people really have.
The complication will be greater than many people seem to think: for
instance, the BNAME proposal as it is currently written is, as far as
we can tell, simply incompatible with all the deployed validators in
the world. =A0That seems like a problem that needs addressing, and we
can't see how to do so easily.


I think there is a need to address the sets of pr= oblems, and potential sets of solutions, in the mathematical
sense of &q= uot;spanning sets".

Only if the set of problems can be covered = by the set of solutions, can (2) proceed,
and all of the necessary solutions to meet that conditions must be fully de= livered.

This, unfortunately, may require a slight divergence from s= tandard IETF policy, in that in order
to meet this condition, there may = be individual proposals which don't meet the traditional
general consensus, which need to be "fostered" or "sponsored= " by either the chairs,
the area director(s), or the IAB, and for w= hich "abandon" is not an acceptable outcome.

They have to = be treated as a set, all-or-nothing, not as individual proposals.
Otherwise not all cases will be covered, and thus what portions do progress= are for naught.
=A0
The problem with (3) is that it was suggested before, and got no
traction. =A0Moreover, it's very complicated, such that the work might<= br> never complete; and in the meantime, people who have a problem have no
help.

We DNSEXT chairs are mostly convinced that there is no current
proposal that is any simpler than just duplicating zone apex data and
adding a DNAME to the "alias" zones. =A0This suggests an option 4= :

=A0 =A04. =A0Provisioning only: document how to do what's needed by =A0 =A0provisioning, and explain why the WG is not doing anything else.

I'd like to add to 4, e.g. " (4.a.) Prov= isioning Enhancements: document per-implementation improvements to support = provisioning-only solutions, which reduce or eliminate out-of-sync conditio= ns for equivalent 'things'."
(By per-implementation, I mean describe in general/abstract terms, what eac= h implementation is encouraged to do, and _not_ describe in implementation-= specific detail what each known existing implementation should change.)
=A0
Before we propose another charter for the WG, we'd like to hear more arguments why any work is needed, and which of the options 1-4 seem
like the best bet for that work.


One underlying problem specific to DNSSEC RRSIG i= ssues (where "equivalent" things need to be signed by each of the= ir "equivalent" parent zone owner names), is the tying of "i= dentity" of a zone to the "owner" name of the apex data.

If we want to be able have "equivalent" things and not have a= n arithmetic explosion of RRSIGs for those things, either the labeling need= s to change, or the manner of assigning an "identity" for "s= igner" purposes (and thus the corresponding logic for validation) need= s to change. (IMHO, the label equivalence needs to be of the first-class ty= pe, where all labels are created equal, to avoid increasing complexity and = fragility.)

Mark Andrews has proposed a "multi-match label" (new label ty= pe).

My idea is to add a new RRset to the apex of the zone, which es= tablishes the complete set of names by which the zone is known (and thus eq= uivalent owners, and thus de-facto permitted signer names).

Note that as the RR type would not be one of the "special few"= ;, it would be signed, just like any other RR.
And for ensuring the secu= rity and sanity (and to avoid circular logic in signing), it (and it alone)= would need to be signed by all the names contained in it.
The additional validation logic is simple - if owner(zone) !=3D signer(zone= _entry) then { check_for_signed_zone_equivalents(owner(zone),signer(zone_en= try)) }

Other than that, the provisioning of zones (by copying) or l= inking of zones (as an enhancement) should be sufficient for most, if not a= ll, cases.

Note that the restriction of some kinds of equivalence only working for= zones, can be worked around by turning anything which would otherwise be a= non-apex entry in a zone, into a zone of its own. It is a clever and ugly = hack, which has the benefit of being 100% backwards compatible, and can be = experimented on today with no risk.

Brian
--001636c5b18b677875048d795221-- From owner-namedroppers@ops.ietf.org Tue Aug 10 08:32: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 6EAE93A6803; Tue, 10 Aug 2010 08:32:17 -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: -96.463 X-Spam-Level: X-Spam-Status: No, score=-96.463 tagged_above=-999 required=5 tests=[AWL=-1.812, BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 pxYjyAcBkFZR; Tue, 10 Aug 2010 08:32:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF2963A67A1; Tue, 10 Aug 2010 08:32:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OiqlA-0006O3-3u for namedroppers-data0@psg.com; Tue, 10 Aug 2010 15:29:00 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oiql6-0006NS-F6 for namedroppers@ops.ietf.org; Tue, 10 Aug 2010 15:28:57 +0000 Received: (eyou send program); Tue, 10 Aug 2010 23:28:55 +0800 Message-ID: <481454135.16637@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, 10 Aug 2010 23:28:55 +0800 Message-ID: <3F9D6BF0A3BA40D5BA4044B7DC347FAA@LENOVO47E041CF> From: "Jiankang YAO" To: "Andrew Sullivan" , References: <05B243F724B2284986522B6ACD0504D7D3442996C7@EXVPMBX100-1.exc.icann.org> <201008042142.o74LgRap031934@cichlid.raleigh.ibm.com> <05B243F724B2284986522B6ACD0504D7D3444A2AAF@EXVPMBX100-1.exc.icann.org> <20100804230904.GB4034@farside.isc.org> <05B243F724B2284986522B6ACD0504D7D3444A2CF6@EXVPMBX100-1.exc.icann.org> <20100805182146.GI38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D00@EXVPMBX100-1.exc.icann.org> <20100805183608.GJ38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D1B@EXVPMBX100-1.exc.icann.org> <20100810141322.GD52191@shinkuro.com> Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable? Date: Tue, 10 Aug 2010 23:29:13 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 OiBUdWVzZGF5LCBBdWd1c3QgMTAsIDIwMTAgMTA6MTMgUE0NClN1YmplY3Q6IFtkbnNleHRdIERv ZXMgRE5TU0VDIG1lYW4gQk5BTUUgaXMgdW5kZXBsb3lhYmxlPw0KDQoNCj4gRGVhciBjb2xsZWFn dWVzLA0KPiANCj4gV2hlbiBkaXNjdXNzaW5nIHRoZSAiYWxpYXNpbmciIGl0ZW1zIGZvciB0aGUg RE5TRVhUIGNoYXJ0ZXIsIE9sYWZ1cg0KPiBhbmQgSSBjYW1lIHRvIHRoZSBjb25jbHVzaW9uIHRo YXQgQk5BTUUsIGFzIGN1cnJlbnRseSB3cml0dGVuLCBpcw0KPiBzaW1wbHkgaW5jb21wYXRpYmxl IHdpdGggRE5TU0VDIGFzIGN1cnJlbnRseSBkZXBsb3llZC4gIFRoYXQgc2VlbXMgdG8NCj4gbWUs IHNwZWFraW5nIHdpdGhvdXQgaGF0LCBsaWtlIGEgcHJldHR5IGJpZyBhcmd1bWVudCBhZ2FpbnN0 IGFkb3B0aW9uLg0KPg0KDQp3ZSB3aWxsIHVwZGF0ZSBpdCBzb29uIGJhc2VkIG9uIHRoZSBkbnNl eHQgZGlzY3Vzc2lvbi4NCiANCj4NCj4gT2xhZnVyIGhhc24ndCBzZWVuIHRoaXMgbWVzc2FnZSwg YmVjYXVzZSBoZSdzIG9uIHZhY2F0aW9uLCBzbyB3aGF0ZXZlcg0KPiBJIGdldCB3cm9uZyBoZXJl IGlzIGFsbCBteSBmYXVsdCBhbmQgeW91IHNob3VsZG4ndCBibGFtZSBoaW0uICBUaGlzIGlzDQo+ IG5ldmVydGhlbGVzcyBteSB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgZW1lcmdlZCBmcm9tIGEgbWVl dGluZyBoZSBhbmQgSQ0KPiBoYWQgbGFzdCB3ZWVrLiAgSSdtIHBvc3RpbmcgaXQgbm93IGluIHRo ZSBpbnRlcmVzdHMgb2YgbW92aW5nIHRoaXMNCj4gd29yayBhbG9uZy4gIEknbSBwb3N0aW5nIGFz IGNvLWNoYWlyLCBidXQgYXMgYQ0KPiBiZWZ1ZGRsZWQtbW9yZS10aGFuLXVzdWFsICghKSBvbmUu ICBJbiByZS1yZWFkaW5nIHNvbWUgcHJldmlvdXMNCj4gZGlzY3Vzc2lvbiwgSSB0aGluayB0aGlz IGFjdHVhbGx5IHJlaGFzaGVzIHNvbWUgb2YgdGhvc2UgYXJndW1lbnRzLg0KPiBJdCdzIGxpa2Vs eSBhIHRlc3RhbWVudCB0byBteSBvd24gZGltbmVzcyB0aGF0IEkgZGlkbid0IGdldCB0aGlzDQo+ IGJlZm9yZTsgYnV0IGluIGNhc2UgdGhpcyBpcyBoZWxwZnVsIHRvIG90aGVycywgSSdtIHBvc3Rp bmcgYW55d2F5Lg0KPiANCj4gSW4gc3VtbWFyeSwgdG8gaW1wbGVtZW50IEJOQU1FIGFuZCBiZSBj b21wYXRpYmxlIHdpdGggYWxsIHRoZSBleGlzdGluZw0KPiB2YWxpZGF0aW5nIHJlc29sdmVycyBh bHJlYWR5IGRlcGxveWVkLCBpdCB3aWxsIGJlIG5lY2Vzc2FyeSB0byBoYXZlDQo+IENOQU1FIGFu ZCBETkFNRSByZWNvcmRzIGF2YWlsYWJsZSBhdCB0aGF0IHNhbWUgb3duZXIgKCJkb21haW4iKSBu YW1lDQo+IGluIHRoZSBETlMuICBUaGlzIGlzIGZ1bmN0aW9uYWxseSBlcXVpdmFsZW50IHRvIENO QU1FK0ROQU1FLCBhbmQNCj4gdGhlcmVmb3JlIHRoZXJlIGlzIG5vIHByYWN0aWNhbCByZWFzb24g dG8gcHJlZmVyIHRoZSBCTkFNRSBwcm9wb3NhbC4NCj4gDQoNCmJuYW1lIGlzIG11Y2ggY2xlYXJl ci4NCg0KaWYgeW91IGxvb3NlIGNuYW1lIHRvIGhhdmUgYSBkbmFtZSwgdGhlIHVzZXIgbWF5IG5v dCBrbm93IHdoeS4NCnRoZXkgbWF5IGNvbmZpZ3VyZSBjK2RuYW1lIHRvZ2V0aGVyIGF0IHRoZSBz b21lIG9sZCBzZXJ2ZXJzLCB3aGljaCBsZWFkcyB0byB1bnJlc29sYWJsZSBvZiBlaXRoZXIgY25h bWUgb3IgZG5hbWUuDQoNCg0KPg0KPiBSZW1lbWJlciB0aGF0IHdlIGhhdmUgbGFyZ2VseSBjb25j bHVkZWQgdGhhdCBETlNTRUMgdmFsaWRhdG9ycyBNVVNUDQo+IHVuZGVyc3RhbmQgRE5BTUUgKHRo aXMgaXMgSSB0aGluayBpbXBsaWNpdCBpbiBSRkMgMjY3MiBhbmQgaXMgc3RhdGVkDQo+IGJhbGRs eSBpbiBkcmFmdC1pZXRmLWRuc2V4dC1yZmMyNjcyYmlzLWRuYW1lKS4gIFRoaXMgbWVhbnMgdGhh dCBhbGwNCj4gdGhlIHZhbGlkYXRvcnMgaW4gdGhlIHdvcmxkIGNhbiBoYW5kbGUgRE5BTUUsIA0K Pg0KdGhlIGNoYWlycyBzYWlkIGluIHRoZSBtZWV0aW5nIHRoYXQgb25seSBoYWxmICg/KSBvZiB0 aGUgc2VydmVycyBzdXBwb3J0IGRuYW1lLg0KDQpkbmFtZSBpcyBub3QgdW5pdmVyc2lhbGx5IHN1 cHBvcnQuDQoNCj5hbmQgdGhhdCB0aGVyZWZvcmUgaWYNCj4gdGhleSBnZXQgYSBzeW50aGV0aWMg Q05BTUUgdGhhdCBpcyB1bnNpZ25lZCwgdGhleSBjYW4gdmFsaWRhdGUgaXQgYnkNCj4gdmFsaWRh dGluZyBpbnN0ZWFkIHRoZSBETkFNRS4gIA0KPiANCj4gVGhlIEJOQU1FIGRyYWZ0IGFzIGl0IHN0 YW5kcyBhdHRlbXB0cyB0byBwbGFjZSBhIHNpbWlsYXIgcmVxdWlyZW1lbnQNCj4gb24gdmFsaWRh dG9yczoNCj4gDQo+ICAgWy4gLiAuXSBJbiBvcmRlciB0byBtYWtlIEJOQU1FIHZhbGlkIGluIERO U1NFQyB2ZXJpZmljYXRpb24sIHRoZQ0KPiAgIEROU1NFQyBlbmFibGVkIHJlc29sdmVycyBhbmQg c2VydmVycyBNVVNUIHN1cHBvcnQgQk5BTUUuICBUaGUNCj4gICBzeW50aGVzaXplZCBDTkFNRSBp biB0aGUgYW5zd2VyIHNlY3Rpb24gZm9yIHRoZSBCTkFNRSB3aWxsIG5ldmVyIGJlDQo+ICAgc2ln bmVkLiAgRE5TU0VDIHZhbGlkYXRvcnMgTVVTVCB1bmRlcnN0YW5kIEJOQU1FLCB2ZXJpZnkgdGhl IEJOQU1FDQo+ICAgYW5kIHRoZW4gY2hlY2tpbmcgdGhhdCB0aGUgQ05BTUUgd2FzIHByb3Blcmx5 IHN5bnRoZXNpemVkIGluIG9yZGVyDQo+ICAgdG8gdmVyaWZ5IHRoZSBzeW50aGVzaXplZCBDTkFN RS4NCj4gDQo+IFRoaXMgaXMsIG9mIGNvdXJzZSwgbm90IGdvaW5nIHRvIHdvcms6IHRoZXJlIGlz IG5vIHdheSB0byByZXF1aXJlLA0KPiByZXRyb2FjdGl2ZWx5LCB0aGF0IGRlcGxveWVkIGNvZGUg c3VwcG9ydCBhbiBSUlRZUEUgd2l0aCBzcGVjaWFsaXplZA0KPiBzZXJ2ZXItc2lkZSBydWxlcyBh bmQgbW9kaWZpZWQgRE5TU0VDIHJ1bGVzLiAgQW55IGV4aXN0aW5nIHZhbGlkYXRvcg0KPiB3aWxs IHRyZWF0IGEgQk5BTUUtZGVyaXZlZCBzeW50aGV0aWMgQ05BTUUgaW5zaWRlIGEgc2lnbmVkIHpv bmUgYXMNCj4gYm9ndXMuICANCj4NCg0Kc2VjdGlvbiA1LjIgb2YgYm5hbWUgZHJhZnQgYWRkcmVz c2VzIHRoaXMgcHJvYmxlbS4NCg0KNS4yLiAgQk5BTUUgYWxpYXMgYWxnb3JpdGhtIGlkZW50aWZp ZXJzDQoNCg0KICAgSW4gb3JkZXIgdG8gcHJldmVudCBCTkFNRS11bmF3YXJlIHJlc29sdmVycyBm cm9tIGF0dGVtcHRpbmcgdG8NCiAgIHZhbGlkYXRlIHJlc3BvbnNlcyBmcm9tIEJOQU1FLXNpZ25l ZCB6b25lcywgdGhpcyBzcGVjaWZpY2F0aW9uDQogICBhbGxvY2F0ZXMgdHdvIG5ldyBETlNLRVkg YWxnb3JpdGhtIGlkZW50aWZpZXJzLiAgQWxnb3JpdGhtIFksIERTQS0NCiAgIEJOQU1FLVNIQTEg aXMgYW4gYWxpYXMgZm9yIGFsZ29yaXRobSAzLCBEU0EuICBBbGdvcml0aG0gWiwgUlNBU0hBMS0N CiAgIEJOQU1FLVNIQTEgaXMgYW4gYWxpYXMgZm9yIGFsZ29yaXRobSA1LCBSU0FTSEExLg0KDQpU aGUgQk5BTUUtDQogICB1bmF3YXJlIHJlc29sdmVycyB3aWxsIG5vdCBrbm93IHRoZXNlIG5ldyBp ZGVudGlmaWVycyBhbmQgdHJlYXQNCiAgIHJlc3BvbnNlcyBmcm9tIHRoZSBCTkFNRSBzaWduZWQg em9uZSBhcyBpbnNlY3VyZQ0KDQo+DQo+V2UgbWF5IG5vdCBrbm93IHdoYXQgYWxsIHRoZSBwcm9i bGVtcyBhcmUgdGhhdCBuZWVkIHNvbHZpbmcsDQo+IGJ1dCB3ZSBoYXZlIHN0cm9uZyByZWFzb24g dG8gc3VwcG9zZSB0aGF0IEJOQU1FIGlzIHBhcnRseSBzdXBwb3NlZCB0bw0KPiBiZSBhIHNvbHV0 aW9uIGZvciBwcm9ibGVtcyBpbiBvciBuZWFyIHRoZSByb290LiANCj4NCg0KYm5hbWUgaXMgc3Vp dGFibGUgZm9yIHJvb3QuDQoNCg0KPiBUaGlzIHdvdWxkIG1lYW4NCj4gZWl0aGVyIHRoYXQgdmFs aWRhdGlvbiBmcm9tIHRoZSB2ZXJ5IGJlZ2lubmluZyBvZiBkZXBsb3ltZW50IHdvdWxkDQo+IGV4 cGVyaWVuY2UgZmFpbHVyZXMsIG9yIHRoYXQgd2UnZCBoYXZlIGEgdmFsaWRhdG9yLXVwZ3JhZGUg ZmxhZyBkYXkuDQo+IE5laXRoZXIgc2VlbXMgYWNjZXB0YWJsZS4NCj4gDQo+IEEgd2F5IGFyb3Vu ZCB0aGlzIGlzIHRvIHNvbHZlIHRoZSBwcm9ibGVtIHdpdGggYSBzaWduYWxsaW5nIGJpdCAoY2Fs bA0KPiBpdCBCQSwgZm9yIEJOQU1FIEF3YXJlKSB0aGF0IGFsbG93cyBhIHF1ZXJ5IG9yaWdpbmF0 b3IgdG8gc2lnbmFsDQo+IHdoZXRoZXIgaXQgY2FuIGhhbmRsZSBCTkFNRS4gIElmIEJBPTEsIHRo ZW4gQk5BTUUgaXMgaGFuZGxlZCBhcw0KPiBkZXNjcmliZWQgaW4gZHJhZnQteWFvLWRuc2V4dC1i bmFtZS0wMy4gIElmIEJBPTAsIGJ1dCBETz0xLCB0aGVuIHRoZQ0KPiBjbGllbnQgZ2V0cyBhIHN5 bnRoZXRpYyBDTkFNRSBfYW5kXyBhIHN5bnRoZXRpYyBETkFNRS4gIFRoZSBzeW50aGV0aWMNCj4g RE5BTUUgbmVlZHMgdG8gYmUgc2lnbmVkIGFzIHRob3VnaCBpdCB3ZXJlIGEgcmVndWxhciBETkFN RSBpbiB0aGUgem9uZQ0KPiAod2hpY2ggZWl0aGVyIG1lYW5zIG9ubGluZSBzaWduaW5nIG9yIHRo YXQgdGhlIHNlcnZlciBzdXBwb3J0cyBoYXZpbmcNCj4gYSBETkFNRSBhbmQgYSBCTkFNRSBhdCB0 aGUgc2FtZSBvd25lciBuYW1lLCBhbmQgaGFzIGRpZmZlcmVudGlhbCBydWxlcw0KPiBmb3Igd2hp Y2ggZGF0YSBpdCBoYW5kcyBvdXQpLiAgSWYgQkE9MCwgYW5kIERPPTAsIHRoZW4gdGhlIGFuc3dl ciBpcyBhDQo+IHN5bnRoZXRpYyBDTkFNRSAoYW5kIHNpZ25hdHVyZXMgZG9uJ3QgbWF0dGVyKS4N Cj4gDQoNCndoeSBhIHN5bnRoZXRpYyBETkFNRSBpcyBuZWNlc3Nhcnk/IGJuYW1lIGRyYWZ0IGhh cyBuZXZlciBzYWlkIGEgc3ludGhldGljIEROQU1FLg0KDQphIHN5bnRoZXRpYyBDTkFNRSBpcyBl bm91Z2ggZm9yIHRoZSBibmFtZS11bndhcmUgY2xpZW50cy4NCg0KPg0KPiBCdXQgbm90aWNlIHRo YXQgdGhlIGFwcHJvYWNoIGVmZmVjdGl2ZWx5IHJlcXVpcmVzIENOQU1FK0ROQU1FLCBhdA0KPiBs ZWFzdCBmb3IgZXhpc3RpbmcgcmVzb2x2ZXJzIHRoYXQgc2V0IERPPTEuICBJZiB0aGF0J3Mgcmln aHQsIHRoZW4NCj4gdGhlcmUncyBwcmFjdGljYWxseSBubyBiZW5lZml0IHRvIEJOQU1FLg0KPiAN Cg0Kbm8sIGJuYW1lIGRvZXMgbm90IG5lZWQgZG5hbWUuDQoNCnlvdXIgYXNzdW1wdGlvbiBpcyB0 b3RhbGx5IHdyb25nLg0KDQoNCj4gQW4gYWx0ZXJuYXRpdmUsIG9mIGNvdXJzZSwgaXMgdG8gaGF2 ZSBubyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5DQo+IGF0dGVtcHRzIChpLmUuIG5vIENOQU1FIHN5 bnRoZXNpcyAmYykuICBUaGlzIHJlcXVpcmVzIGEgc2lnbmFsbGluZyBiaXQNCj4gc3RpbGwsIGJ1 dCBpdCBkb2VzIG5vdCByZXF1aXJlIGFueSBzeW50aGVzaXMgb2Ygb3RoZXIgUlJzLiAgVGhlDQo+ IGRpc2FkdmFudGFnZSBpcyB0aGF0IG5vIGV4aXN0aW5nIHJlc29sdmVyIGNhbiBmb2xsb3cgdGhl IEJOQU1FLCBzbyB0aGUNCj4gdmFsdWUgb2YgdGhlIGVmZm9ydCBpcyBxdWVzdGlvbmFibGUuDQo+ IA0KPiBBbHNvLCBpZiB0aGlzIGFyZ3VtZW50IGlzIHJpZ2h0LCBETlNTRUMgZWZmZWN0aXZlbHkg bWVhbnMgdGhhdCBmdXR1cmUNCj4gc2VydmVyLXNpZGUgcHJvY2Vzc2luZyBydWxlcyBhcmUgZ29p bmcgdG8gYmUgdmVyeSBoYXJkIHRvIGp1c3RpZnkgLS0NCj4gZXZlbiBoYXJkZXIgdGhhbiB0aGV5 IHVzZWQgdG8gYmUuDQo+IA0KPiBJJ2QgYXBwcmVjaWF0ZSBjb21tZW50cyBvbiBhbnkgb2YgdGhp cywgaW4gbGlnaHQgb2Ygb3VyIHBsYW4NCj4gKGkuZS4gT2xhZnVyJ3MgYW5kIG1pbmUsIGFzIGNo YWlycykgdG8gaGF2ZSBhIG5ldyB2ZXJzaW9uIG9mIHRoZQ0KPiBjaGFydGVyIGluIHRpbWUgZm9y IG91ciBzZWxmLWltcG9zZWQgZGVhZGxpbmUgaW4gU2VwdGVtYmVyLg0KPiANCj4gVGhhbmtzLA0K PiANCj4gQQ0KPiANCj4gLS0gDQo+IEFuZHJldyBTdWxsaXZhbg0KPiBhanNAc2hpbmt1cm8uY29t DQo+IFNoaW5rdXJvLCBJbmMuDQo+ From owner-namedroppers@ops.ietf.org Tue Aug 10 08:47: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 7163C3A68D4; Tue, 10 Aug 2010 08:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.606 X-Spam-Level: X-Spam-Status: No, score=-99.606 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_15=0.6, 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 lS-4oUgDMQp2; Tue, 10 Aug 2010 08:47:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2F7BB3A6884; Tue, 10 Aug 2010 08:47:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oir0V-00093Q-QS for namedroppers-data0@psg.com; Tue, 10 Aug 2010 15:44:51 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oir0T-000931-KF for namedroppers@ops.ietf.org; Tue, 10 Aug 2010 15:44:49 +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 464A71ECB41D for ; Tue, 10 Aug 2010 15:44:48 +0000 (UTC) Date: Tue, 10 Aug 2010 11:44:46 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable? Message-ID: <20100810154446.GG52191@shinkuro.com> References: <201008042142.o74LgRap031934@cichlid.raleigh.ibm.com> <05B243F724B2284986522B6ACD0504D7D3444A2AAF@EXVPMBX100-1.exc.icann.org> <20100804230904.GB4034@farside.isc.org> <05B243F724B2284986522B6ACD0504D7D3444A2CF6@EXVPMBX100-1.exc.icann.org> <20100805182146.GI38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D00@EXVPMBX100-1.exc.icann.org> <20100805183608.GJ38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D1B@EXVPMBX100-1.exc.icann.org> <20100810141322.GD52191@shinkuro.com> <3F9D6BF0A3BA40D5BA4044B7DC347FAA@LENOVO47E041CF> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F9D6BF0A3BA40D5BA4044B7DC347FAA@LENOVO47E041CF> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: No hat. On Tue, Aug 10, 2010 at 11:29:13PM +0800, Jiankang YAO wrote: > if you loose cname to have a dname, the user may not know why. > they may configure c+dname together at the some old servers, which leads to unresolable of either cname or dname. > The tests we have seen so far don't seem to support that conclusion. In favour of that conclusion are things like qmail & its interpretation of CNAME; that line of argument could be productive, if someone wanted to investigate it. > > > the chairs said in the meeting that only half (?) of the servers support dname. So, to clarify, this is an issue with recursive resolvers that do not support DNAME. I didn't participate in the investigation, so the details will have to wait until Olafur gets back (unles Ondrej wants to chime in -- I think he was also involved?). But the key thing is to note that this is code base, not % of deployed systems. Moreover, the systems in question can't support DNSSEC properly, either. > > section 5.2 of bname draft addresses this problem. > > 5.2. BNAME alias algorithm identifiers > > > In order to prevent BNAME-unaware resolvers from attempting to > validate responses from BNAME-signed zones, this specification > allocates two new DNSKEY algorithm identifiers. Algorithm Y, DSA- Right, you're quite correct for taking me to task for not pointing this out. But this answer is still pretty bad, because what we're doing in that case is promoting a barrier to DNSSEC validation: if you don't have a BNAME-supporting validator, you don't get validation. This issue is part of why I'm anxious to get guidance. Also, the aliases are inadequate. You actually need an alias for every existing algorithm identifier. That means you need aliases for all the SHA2 variants and GOST as well (I'm willing to disregard MD5 because we think it oughtn't to be used anyway). > why a synthetic DNAME is necessary? bname draft has never said a synthetic DNAME. The BNAME draft indeed does not say that. In case I wasn't clear, the suggestion is that this approach is needed _instead_ of the way the BNAME draft is currently written. The point is that this will allow validation just as well as it works today, so that everyone in the world needn't upgrade to BNAME support just to get validation of these resource records. Best regards, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Aug 10 09:14: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 4BC603A699C; Tue, 10 Aug 2010 09:14: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: -96.712 X-Spam-Level: X-Spam-Status: No, score=-96.712 tagged_above=-999 required=5 tests=[AWL=-1.461, BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_15=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 jLYxGDgZlW20; Tue, 10 Aug 2010 09:14:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DCD8E3A6A65; Tue, 10 Aug 2010 09:14:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OirPM-000DS5-TH for namedroppers-data0@psg.com; Tue, 10 Aug 2010 16:10:32 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OirPK-000DRf-2Z for namedroppers@ops.ietf.org; Tue, 10 Aug 2010 16:10:30 +0000 Received: (eyou send program); Wed, 11 Aug 2010 00:10:28 +0800 Message-ID: <481456628.16636@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, 11 Aug 2010 00:10:28 +0800 Message-ID: <42489A1B083D44EE953954C51D38BF66@LENOVO47E041CF> From: "Jiankang YAO" To: "Andrew Sullivan" , References: <201008042142.o74LgRap031934@cichlid.raleigh.ibm.com> <05B243F724B2284986522B6ACD0504D7D3444A2AAF@EXVPMBX100-1.exc.icann.org> <20100804230904.GB4034@farside.isc.org> <05B243F724B2284986522B6ACD0504D7D3444A2CF6@EXVPMBX100-1.exc.icann.org> <20100805182146.GI38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D00@EXVPMBX100-1.exc.icann.org> <20100805183608.GJ38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D1B@EXVPMBX100-1.exc.icann.org> <20100810141322.GD52191@shinkuro.com> <3F9D6BF0A3BA40D5BA4044B7DC347FAA@LENOVO47E041CF> <20100810154446.GG52191@shinkuro.com> Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable? Date: Wed, 11 Aug 2010 00:10:47 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 OiBUdWVzZGF5LCBBdWd1c3QgMTAsIDIwMTAgMTE6NDQgUE0NClN1YmplY3Q6IFJlOiBbZG5zZXh0 XSBEb2VzIEROU1NFQyBtZWFuIEJOQU1FIGlzIHVuZGVwbG95YWJsZT8NCg0KDQo+IE5vIGhhdC4N Cj4gDQo+IE9uIFR1ZSwgQXVnIDEwLCAyMDEwIGF0IDExOjI5OjEzUE0gKzA4MDAsIEppYW5rYW5n IFlBTyB3cm90ZToNCj4gDQo+PiBpZiB5b3UgbG9vc2UgY25hbWUgdG8gaGF2ZSBhIGRuYW1lLCB0 aGUgdXNlciBtYXkgbm90IGtub3cgd2h5Lg0KPj4gdGhleSBtYXkgY29uZmlndXJlIGMrZG5hbWUg dG9nZXRoZXIgYXQgdGhlIHNvbWUgb2xkIHNlcnZlcnMsIHdoaWNoIGxlYWRzIHRvIHVucmVzb2xh YmxlIG9mIGVpdGhlciBjbmFtZSBvciBkbmFtZS4NCj4+IA0KPiANCj4gVGhlIHRlc3RzIHdlIGhh dmUgc2VlbiBzbyBmYXIgZG9uJ3Qgc2VlbSB0byBzdXBwb3J0IHRoYXQgY29uY2x1c2lvbi4NCj4g SW4gZmF2b3VyIG9mIHRoYXQgY29uY2x1c2lvbiBhcmUgdGhpbmdzIGxpa2UgcW1haWwgJiBpdHMN Cj4gaW50ZXJwcmV0YXRpb24gb2YgQ05BTUU7IHRoYXQgbGluZSBvZiBhcmd1bWVudCBjb3VsZCBi ZSBwcm9kdWN0aXZlLCBpZg0KPiBzb21lb25lIHdhbnRlZCB0byBpbnZlc3RpZ2F0ZSBpdC4NCj4g DQoNCnRoZXJlIGFyZSBzbyBtYW55IGltcGxlbWVudGFpb25zIGFuZCB2ZXJzaW9ucy4NCg0KeW91 J2QgYmV0dGVyIHNheSB3aGljaCBzb2Z0d2FyZSBhbmQgd2hpY2ggdmVyc2lvbiB5b3UgdGVzdGVk Pw0KDQpvbiB0aGUgb3RoZXIgaGFuZCwNCnRlc3Rpbmcgb25lIGRvZXMgbm90IG1lYW4gdGhhdCB5 b3UgY2FuIHByb3ZlIGFsbC4NCg0KDQo+PiA+DQo+PiB0aGUgY2hhaXJzIHNhaWQgaW4gdGhlIG1l ZXRpbmcgdGhhdCBvbmx5IGhhbGYgKD8pIG9mIHRoZSBzZXJ2ZXJzIHN1cHBvcnQgZG5hbWUuDQo+ IA0KPiBTbywgdG8gY2xhcmlmeSwgdGhpcyBpcyBhbiBpc3N1ZSB3aXRoIHJlY3Vyc2l2ZSByZXNv bHZlcnMgdGhhdCBkbyBub3QNCj4gc3VwcG9ydCBETkFNRS4gIEkgZGlkbid0IHBhcnRpY2lwYXRl IGluIHRoZSBpbnZlc3RpZ2F0aW9uLCBzbyB0aGUNCj4gZGV0YWlscyB3aWxsIGhhdmUgdG8gd2Fp dCB1bnRpbCBPbGFmdXIgZ2V0cyBiYWNrICh1bmxlcyBPbmRyZWogd2FudHMNCj4gdG8gY2hpbWUg aW4gLS0gSSB0aGluayBoZSB3YXMgYWxzbyBpbnZvbHZlZD8pLiAgQnV0IHRoZSBrZXkgdGhpbmcg aXMNCj4gdG8gbm90ZSB0aGF0IHRoaXMgaXMgY29kZSBiYXNlLCBub3QgJSBvZiBkZXBsb3llZCBz eXN0ZW1zLiAgTW9yZW92ZXIsDQo+IHRoZSBzeXN0ZW1zIGluIHF1ZXN0aW9uIGNhbid0IHN1cHBv cnQgRE5TU0VDIHByb3Blcmx5LCBlaXRoZXIuDQo+IA0KPj4gDQo+PiBzZWN0aW9uIDUuMiBvZiBi bmFtZSBkcmFmdCBhZGRyZXNzZXMgdGhpcyBwcm9ibGVtLg0KPj4gDQo+PiA1LjIuICBCTkFNRSBh bGlhcyBhbGdvcml0aG0gaWRlbnRpZmllcnMNCj4+IA0KPj4gDQo+PiAgICBJbiBvcmRlciB0byBw cmV2ZW50IEJOQU1FLXVuYXdhcmUgcmVzb2x2ZXJzIGZyb20gYXR0ZW1wdGluZyB0bw0KPj4gICAg dmFsaWRhdGUgcmVzcG9uc2VzIGZyb20gQk5BTUUtc2lnbmVkIHpvbmVzLCB0aGlzIHNwZWNpZmlj YXRpb24NCj4+ICAgIGFsbG9jYXRlcyB0d28gbmV3IEROU0tFWSBhbGdvcml0aG0gaWRlbnRpZmll cnMuICBBbGdvcml0aG0gWSwgRFNBLQ0KPiANCj4gUmlnaHQsIHlvdSdyZSBxdWl0ZSBjb3JyZWN0 IGZvciB0YWtpbmcgbWUgdG8gdGFzayBmb3Igbm90IHBvaW50aW5nDQo+IHRoaXMgb3V0LiAgQnV0 IHRoaXMgYW5zd2VyIGlzIHN0aWxsIHByZXR0eSBiYWQsIGJlY2F1c2Ugd2hhdCB3ZSdyZQ0KPiBk b2luZyBpbiB0aGF0IGNhc2UgaXMgcHJvbW90aW5nIGEgYmFycmllciB0byBETlNTRUMgdmFsaWRh dGlvbjogaWYgeW91DQo+IGRvbid0IGhhdmUgYSBCTkFNRS1zdXBwb3J0aW5nIHZhbGlkYXRvciwg eW91IGRvbid0IGdldCB2YWxpZGF0aW9uLg0KPiBUaGlzIGlzc3VlIGlzIHBhcnQgb2Ygd2h5IEkn bSBhbnhpb3VzIHRvIGdldCBndWlkYW5jZS4NCj4gDQo+IEFsc28sIHRoZSBhbGlhc2VzIGFyZSBp bmFkZXF1YXRlLiAgWW91IGFjdHVhbGx5IG5lZWQgYW4gYWxpYXMgZm9yDQo+IGV2ZXJ5IGV4aXN0 aW5nIGFsZ29yaXRobSBpZGVudGlmaWVyLiAgVGhhdCBtZWFucyB5b3UgbmVlZCBhbGlhc2VzIGZv cg0KPiBhbGwgdGhlIFNIQTIgdmFyaWFudHMgYW5kIEdPU1QgYXMgd2VsbCAoSSdtIHdpbGxpbmcg dG8gZGlzcmVnYXJkIE1ENQ0KPiBiZWNhdXNlIHdlIHRoaW5rIGl0IG91Z2h0bid0IHRvIGJlIHVz ZWQgYW55d2F5KS4NCj4gDQoNCmZvbGxvd2luZyB5b3VyIGxvZ2ljLCBhZnRlciBkbnNzZWMsIHdl IHdvdWxkIG5vdCBpbnZlbnQgdGhlIG5ldyBycnR5cGUuDQoNCmRvZXMgZG5zc2VjIG1lYW4gdGhl IGRlYWQgb2YgYWxsIG5ldyBycnR5cGU/DQoNCg0KDQo+PiB3aHkgYSBzeW50aGV0aWMgRE5BTUUg aXMgbmVjZXNzYXJ5PyBibmFtZSBkcmFmdCBoYXMgbmV2ZXIgc2FpZCBhIHN5bnRoZXRpYyBETkFN RS4NCj4gDQo+IFRoZSBCTkFNRSBkcmFmdCBpbmRlZWQgZG9lcyBub3Qgc2F5IHRoYXQuICBJbiBj YXNlIEkgd2Fzbid0IGNsZWFyLCB0aGUNCj4gc3VnZ2VzdGlvbiBpcyB0aGF0IHRoaXMgYXBwcm9h Y2ggaXMgbmVlZGVkIF9pbnN0ZWFkXyBvZiB0aGUgd2F5IHRoZQ0KPiBCTkFNRSBkcmFmdCBpcyBj dXJyZW50bHkgd3JpdHRlbi4gIFRoZSBwb2ludCBpcyB0aGF0IHRoaXMgd2lsbCBhbGxvdw0KPiB2 YWxpZGF0aW9uIGp1c3QgYXMgd2VsbCBhcyBpdCB3b3JrcyB0b2RheSwgc28gdGhhdCBldmVyeW9u ZSBpbiB0aGUNCj4gd29ybGQgbmVlZG4ndCB1cGdyYWRlIHRvIEJOQU1FIHN1cHBvcnQganVzdCB0 byBnZXQgdmFsaWRhdGlvbiBvZiB0aGVzZQ0KPiByZXNvdXJjZSByZWNvcmRzLg0KPiANCj4gQmVz dCByZWdhcmRzLA0KPiANCj4gQQ0KPiANCj4gLS0gDQo+IEFuZHJldyBTdWxsaXZhbg0KPiBhanNA c2hpbmt1cm8uY29tDQo+IFNoaW5rdXJvLCBJbmMuDQo+ From owner-namedroppers@ops.ietf.org Tue Aug 10 10:15: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 00B903A699A; Tue, 10 Aug 2010 10:15:21 -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: -98.293 X-Spam-Level: X-Spam-Status: No, score=-98.293 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 OxaLC0t8ph2z; Tue, 10 Aug 2010 10:15:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 359033A67E2; Tue, 10 Aug 2010 10:15:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OisLL-000MUf-4C for namedroppers-data0@psg.com; Tue, 10 Aug 2010 17:10:27 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OisLI-000MU4-3L for namedroppers@ops.ietf.org; Tue, 10 Aug 2010 17:10:24 +0000 Received: (eyou send program); Wed, 11 Aug 2010 01:10:23 +0800 Message-ID: <481460223.02424@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, 11 Aug 2010 01:10:23 +0800 Message-ID: <0255840D00074A649AEB64709F5F3EC4@LENOVO47E041CF> From: "Jiankang YAO" To: Subject: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-04.txt Date: Wed, 11 Aug 2010 01:10:43 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00BE_01CB38F2.054F1120" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_00BE_01CB38F2.054F1120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 dXBkYXRpbmcgYWJvdXQgc3ludGhlc2lzZWQgY25hbWUgZGVzY3JpcHRpb24uDQpvdGhlciBtYXRl cmlhbCB1cGRhdGluZyBhbmQgc2lnbmFsbGluZyB3aWxsIGJlIHNvb24gYXZhaWxhYmxlIGluIHRo ZSBuZXh0IHZlcnNpb24uDQoNCklmIHRoZSBvd25lciBuYW1lIG9mIHRoZSBibmFtZSBpcyB0aGUg c3VmZml4IG9mIHRoZSBuYW1lIHF1ZXJ5ZWQgYnV0DQogICBkaWZmZXJlbnQsIHdoZW4gcHJlcGFy aW5nIGEgcmVzcG9uc2UsIGEgc2VydmVyIHBlcmZvcm1pbmcgYSBCTkFNRQ0KICAgc3Vic3RpdHV0 aW9uIHdpbGwgaW4gYWxsIGNhc2VzIGluY2x1ZGUgdGhlIHJlbGV2YW50IEJOQU1FIFJSIGluIHRo ZQ0KICAgYW5zd2VyIHNlY3Rpb24uICBBIENOQU1FIFJSIGlzIHN5bnRoZXNpemVkIGFuZCBpbmNs dWRlZCBpbiB0aGUgYW5zd2VyDQogICBzZWN0aW9uLiAgVGhpcyB3aWxsIGhlbHAgdGhlIGNsaWVu dCB0byByZWFjaCB0aGUgY29ycmVjdCBETlMgZGF0YS4NCg0KICAgSWYgdGhlIG93bmVyIG5hbWUg b2YgdGhlIGJuYW1lIGlzIHNhbWUgd2l0aCB0aGUgbmFtZSBxdWVyeWVkLCB3aGVuDQogICBwcmVw YXJpbmcgYSByZXNwb25zZSwgYSBzZXJ2ZXIgcGVyZm9ybWluZyBhIEJOQU1FIHN1YnN0aXR1dGlv biB3aWxsDQogICBub3QgaW5jbHVkZSB0aGUgcmVsZXZhbnQgQk5BTUUgUlIgaW4gdGhlIGFuc3dl ciBzZWN0aW9uIHVubGVzcyB0aGUNCiAgIHR5cGUgcXVlcnllZCBpcyBCTkFNRS4gIEEgQ05BTUUg UlIgd2lsbCBiZSBzeW50aGVzaXplZCBhbmQgaW5jbHVkZWQNCiAgIGluIHRoZSBhbnN3ZXIgc2Vj dGlvbiB1bmxlc3MgdGhlIHR5cGUgcXVlcnllZCBpcyBCTkFNRSBvciB0aGUgcXVlcnkNCiAgIGlz IHRoZSBETlNTRUMgcXVlcnkuDQoNCg0KDQogICBJZiB0aGUgb3duZXIgbmFtZSBvZiB0aGUgYm5h bWUgaXMgdGhlIHN1ZmZpeCBvZiB0aGUgbmFtZSBxdWVyeWVkIGJ1dA0KICAgZGlmZmVyZW50LCBE TlNTRUMgdmFsaWRhdG9ycyBNVVNUIHVuZGVyc3RhbmQgQk5BTUUsIHZlcmlmeSB0aGUgQk5BTUUN CiAgIGFuZCB0aGVuIGNoZWNraW5nIHRoYXQgdGhlIENOQU1FIHdhcyBwcm9wZXJseSBzeW50aGVz aXplZCBpbiBvcmRlciB0bw0KICAgdmVyaWZ5IHRoZSBzeW50aGVzaXplZCBDTkFNRS4NCg0KICAg SWYgdGhlIG93bmVyIG5hbWUgb2YgdGhlIGJuYW1lIGlzIHNhbWUgd2l0aCB0aGUgbmFtZSBxdWVy eWVkLCBETlNTRUMNCiAgIHZhbGlkYXRvcnMgTVVTVCB1bmRlcnN0YW5kIEJOQU1FIGFuZCB2ZXJp ZnkgdGhlIEJOQU1FLiAgVGhlIEJOQU1FDQogICBlbmFibGVkIHJlc29sdmVyICh2YWxpZGF0b3Ip IHNob3VsZCBkbyBzb21ld2hhdCBhbmFsb2dvdXMgdG8gYSBDTkFNRQ0KICAgZm9yIGZ1cnRoZXIg cXVlcnkuDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiA8SW50ZXJuZXQt RHJhZnRzQGlldGYub3JnPg0KVG86IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQpTZW50OiBXZWRu ZXNkYXksIEF1Z3VzdCAxMSwgMjAxMCAxOjAwIEFNDQpTdWJqZWN0OiBJLUQgQWN0aW9uOmRyYWZ0 LXlhby1kbnNleHQtYm5hbWUtMDQudHh0IA0KDQoNCj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ IA0KPiBUaXRsZSAgICAgICAgICAgOiBCdW5kbGUgRE5TIE5hbWUgUmVkaXJlY3Rpb24NCj4gQXV0 aG9yKHMpICAgICAgIDogSi4gWWFvLCBldCBhbC4NCj4gRmlsZW5hbWUgICAgICAgIDogZHJhZnQt eWFvLWRuc2V4dC1ibmFtZS0wNC50eHQNCj4gUGFnZXMgICAgICAgICAgIDogMTMNCj4gRGF0ZSAg ICAgICAgICAgIDogMjAxMC0wOC0xMA0KPiANCj4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3 IEROUyBSZXNvdXJjZSBSZWNvcmQgY2FsbGVkICJCTkFNRSIsIHdoaWNoDQo+IHByb3ZpZGVzIHRo ZSBjYXBhYmlsaXR5IHRvIG1hcCBpdHNlbGYgYW5kIGl0cyBzdWJ0cmVlIG9mIHRoZSBETlMgbmFt ZQ0KPiBzcGFjZSB0byBhbm90aGVyIGRvbWFpbi4gIEl0IGRpZmZlcnMgZnJvbSB0aGUgQ05BTUUg cmVjb3JkIHdoaWNoIG9ubHkNCj4gbWFwcyBhIHNpbmdsZSBub2RlIG9mIHRoZSBETlMgbmFtZSBz cGFjZSwgZnJvbSB0aGUgRE5BTUUgd2hpY2ggb25seQ0KPiBtYXBzIHRoZSBzdWJ0cmVlIG9mIHRo ZSBETlMgbmFtZSBzcGFjZSB0byBhbm90aGVyIGRvbWFpbi4NCj4gDQo+IEEgVVJMIGZvciB0aGlz IEludGVybmV0LURyYWZ0IGlzOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC15YW8tZG5zZXh0LWJuYW1lLTA0LnR4dA0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLw0KPiANCj4gQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBl bmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcg0KPiBpbXBsZW1lbnRhdGlvbiB0byBh dXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQ0KPiBJbnRlcm5l dC1EcmFmdC4NCj4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSS1ELUFubm91bmNlIG1h aWxpbmcgbGlzdA0KPiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0 b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4gb3IgZnRwOi8vZnRwLmll dGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4= ------=_NextPart_000_00BE_01CB38F2.054F1120 Content-Type: text/plain; name="draft-yao-dnsext-bname-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-yao-dnsext-bname-04.txt" Content-Type: text/plain Content-ID: <2010-08-10095241.I-D@ietf.org> ------=_NextPart_000_00BE_01CB38F2.054F1120-- From owner-namedroppers@ops.ietf.org Tue Aug 10 10:23: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 28E293A6A8C; Tue, 10 Aug 2010 10:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.589 X-Spam-Level: X-Spam-Status: No, score=-99.589 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_55=0.6, 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 SHsluCLgl9Es; Tue, 10 Aug 2010 10:23:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3CB663A6A8B; Tue, 10 Aug 2010 10:23:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OisTS-000Nth-2F for namedroppers-data0@psg.com; Tue, 10 Aug 2010 17:18:50 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OisTP-000Nt4-5N for namedroppers@ops.ietf.org; Tue, 10 Aug 2010 17:18:47 +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 037201ECB41D for ; Tue, 10 Aug 2010 17:18:43 +0000 (UTC) Date: Tue, 10 Aug 2010 13:18:42 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable? Message-ID: <20100810171841.GJ52191@shinkuro.com> References: <20100804230904.GB4034@farside.isc.org> <05B243F724B2284986522B6ACD0504D7D3444A2CF6@EXVPMBX100-1.exc.icann.org> <20100805182146.GI38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D00@EXVPMBX100-1.exc.icann.org> <20100805183608.GJ38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D1B@EXVPMBX100-1.exc.icann.org> <20100810141322.GD52191@shinkuro.com> <3F9D6BF0A3BA40D5BA4044B7DC347FAA@LENOVO47E041CF> <20100810154446.GG52191@shinkuro.com> <42489A1B083D44EE953954C51D38BF66@LENOVO47E041CF> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42489A1B083D44EE953954C51D38BF66@LENOVO47E041CF> 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, Aug 11, 2010 at 12:10:47AM +0800, Jiankang YAO wrote: > on the other hand, > testing one does not mean that you can prove all. This is certainly true, and it's one of the reasons I feel uncomfortable with CNAME+DNAME. > following your logic, after dnssec, we would not invent the new rrtype. > > does dnssec mean the dead of all new rrtype? You are failing to make an important distinction, which is between RRTYPEs that need server-side processing and those that don't. The former are a big deal, whereas the latter can be treated trivially as the unknown type in those systems that don't understand them. I actually pointed out this distinction in the first mail in this thread. If you don't think that distinction is an important one in this context, you're going to need an argument to support such a position. Speaking only personally (to emphasise), I think the interaction of BNAME and DNSSEC as it stands is simply an unacceptable trade-off: the plan is to support a new kinf of aliasing (which could just as easily be supported by the provisioning layer, IMO) by trading away the ability to use deployed validating resolvers to tell whether a given response is legitimate. I think -- again, speaking personally -- that we don't want to give up so easily a feature this community has worked so long and hard to get deployed. If you think that the problems BNAME is aimed at addressing cannot be solved just as well by good provisioning tools, you need to make an argument for why. I haven't heard such an argument beyond, "None of the tools we have make this practical." I haven't yet seen a complete argument why some apex records + DNAME aren't good enough in the alias zone. In my personal, no-hat view, that is a good reason to go sponsor additional work on tools to support such deployment rather than to modify the DNS protocol in such a way as to require widespread adoption before all of the functionality we have (already deployed! Root is signed!) today is again working. Speaking as a WG chair, however, I wish to emphasise that the above preference will not prevent me accepting adoption of some or all of this work if the WG plainly wants it and we have a clear and complete statement of what problems we think we are solving. But I take very seriously the objection raised by more than one person in Maastricht that we should not add more complications to the protocol to solve a small number of cases that can also be addressed in other ways. Best regards, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Aug 10 10:59: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 180203A6A9C; Tue, 10 Aug 2010 10:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[AWL=-0.303, 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 yvwIOCvOYRxP; Tue, 10 Aug 2010 10:59:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BAA173A6A95; Tue, 10 Aug 2010 10:59:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oit2r-0003I4-KA for namedroppers-data0@psg.com; Tue, 10 Aug 2010 17:55:25 +0000 Received: from [209.85.161.180] (helo=mail-gx0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oit2o-0003Hj-EJ for namedroppers@ops.ietf.org; Tue, 10 Aug 2010 17:55:22 +0000 Received: by gxk22 with SMTP id 22so5733309gxk.11 for ; Tue, 10 Aug 2010 10:55:21 -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=Lh2hfY71490YBJ29fpCPo/fl1F+JYOSnk4vs3EicH14=; b=nfqfgkwo0Paqc2TGtMdSjTcY8iTCKjQIwEz32cbZRMw7l5Rr63LFfGpiYaPnvyC/cj 4ZvMbNWt4+kbdnhGZNbhBg1JbVO5k/eROc1lq09cPyp8wAKP9Sqzl+EWJ2xQW3TjkH+z hE+5xEG+/24lb7bfhVpTGrIRyq8ykTTypXuEc= 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=Rp67SHetMdvNI7JeJp9kd/Qc1ztVL/xkahelavf39QLuUcqUq0cfpz1X61RO70wj9t eMjFFgOKtnR9hJv+xwUKKE6qOG24bxjKzFg2yOwMUYWZOu8UXESN63Snp2T6u2/v2nEr ZXlOApO6JGW49HOd1HsdFcFuga9HWWjsN++K0= MIME-Version: 1.0 Received: by 10.100.53.30 with SMTP id b30mr20140632ana.43.1281462921473; Tue, 10 Aug 2010 10:55:21 -0700 (PDT) Received: by 10.101.188.15 with HTTP; Tue, 10 Aug 2010 10:55:21 -0700 (PDT) In-Reply-To: <20100810133649.GC52191@shinkuro.com> References: <20100810133649.GC52191@shinkuro.com> Date: Tue, 10 Aug 2010 13:55:21 -0400 Message-ID: Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" From: Phillip Hallam-Baker 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 the provisioning approach makes sense. I do not see the justification for experimenting for issues that can be handled through provisioning. While I am currently working on a 'presentation' layer proposal to combine DNSSEC, SSL and SRV and some other stuff to provide an integrated discovery mechanism, I see getting a presentation mechanism defined as being an essential prerequisite to getting an I18N presentation layer to work. In other words, we have to get a decent story together for how to manage presentation-layer for the Web Services for google.com before we go on to work out the presentation layer for the I18N variations thereof. On Tue, Aug 10, 2010 at 9:36 AM, Andrew Sullivan wrote: > Dear colleagues, > > One of our primary goals for DNSEXT at IETF 78 was to get feedback > from the user community (in particular, we aimed at application > developers) who have the "aliasing" and "sameness" problem(s) with the > DNS. =A0Unfortunately, we were unable to attract many such participants. > > It is clear to us that none of the proposals now before DNSEXT > addresses all the problems that people have. =A0As far as we are able to > tell, there are needs with respect to domain names, with respect to > whole trees in the DNS, and perhaps with respect to individual labels > no matter where they might appear in a domain name. =A0None of the > proposals handles all of these, and some of these needs are not > addressed at all. > > We appear to be faced with a choice among three basic strategies: > > =A0 =A01. =A0Experiment: Since we don't know what the problems are, but w= e > =A0 =A0have people proposing solutions, we could adopt the proposed > =A0 =A0solutions experimentally, and evaluate in (say) five years whether > =A0 =A0the proposals solved the problems people have. > > =A0 =A02. =A0Limp along: We could accept that no proposal will solve > =A0 =A0everything, and "limp along" by standardizing properly the > =A0 =A0proposals we have: work towards clarity and precision in the > =A0 =A0problem statement and then proceed to work on the proposals > =A0 =A0themselves. > > =A0 =A03. =A0Kick it upstairs: A basic problem in all of this is that the > =A0 =A0DNS does not have a presentation layer. =A0Domain names end up bei= ng > =A0 =A0used in presentation contexts, and that's what's broken. =A0So, we > =A0 =A0could say that there is no problem here for the DNS, but that we > =A0 =A0are ready and willing to support building a presentation layer > =A0 =A0atop the DNS. =A0Such a specification needs to come from elsewhere= . > > The problem with (1) is that some of the proposals are simply > impossible to do as experiments (if we change the rules for CNAME, > they're effectively changed forever whether we like it or not). =A0In > addition, we think it would be a very bad idea to perform such an > experiment in the root, but we expect that there would be operational > pressures to do so. > > The problem with (2) is that we make the DNS more complicated without > solving all or perhaps even most of the problems people really have. > The complication will be greater than many people seem to think: for > instance, the BNAME proposal as it is currently written is, as far as > we can tell, simply incompatible with all the deployed validators in > the world. =A0That seems like a problem that needs addressing, and we > can't see how to do so easily. > > The problem with (3) is that it was suggested before, and got no > traction. =A0Moreover, it's very complicated, such that the work might > never complete; and in the meantime, people who have a problem have no > help. > > We DNSEXT chairs are mostly convinced that there is no current > proposal that is any simpler than just duplicating zone apex data and > adding a DNAME to the "alias" zones. =A0This suggests an option 4: > > =A0 =A04. =A0Provisioning only: document how to do what's needed by > =A0 =A0provisioning, and explain why the WG is not doing anything else. > > Before we propose another charter for the WG, we'd like to hear more > arguments why any work is needed, and which of the options 1-4 seem > like the best bet for that work. > > Best regards, > > Andrew and Olafur > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Tue Aug 10 14:00: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 5898F3A6A75; Tue, 10 Aug 2010 14:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.972 X-Spam-Level: X-Spam-Status: No, score=-97.972 tagged_above=-999 required=5 tests=[AWL=-2.172, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6, 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 GwH1FXmW4W4l; Tue, 10 Aug 2010 14:00:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 238083A67B1; Tue, 10 Aug 2010 14:00:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oivqf-00003Q-7A for namedroppers-data0@psg.com; Tue, 10 Aug 2010 20:55:01 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oivqb-00002t-4J for namedroppers@ops.ietf.org; Tue, 10 Aug 2010 20:54:57 +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 7C3401ECB41D for ; Tue, 10 Aug 2010 20:54:54 +0000 (UTC) Date: Tue, 10 Aug 2010 16:54:52 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] draft minutes for IETF 78 Message-ID: <20100810205452.GC54011@shinkuro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="TYecfFk8j8mZq+dy" 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: --TYecfFk8j8mZq+dy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear colleagues, Attached are minutes for the meetings of the WG at IETF 78, for comment. IF you wish to make corrections, please send mail to the list or directly to me. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. --TYecfFk8j8mZq+dy Content-Type: text/plain; charset=UTF-8 Content-Disposition: attachment; filename="minutes-complete-2010-08-10a.txt" Content-Transfer-Encoding: quoted-printable Minutes of the DNS Extensions Working Group meetings IETF 78: Maastricht, NL. Meeting dates:=20 2010-07-26. Minutes prepared by Mark Mcfadden 2010-07-28. Minutes prepared by Paul Hoffman. Chairs' note: These minutes are in radically different styles. The first covers action to come from the meeting and contains less of the discussion. The second covers the discussion and contains few actions to come. This is because the goals of the two meetings were different, so the styles are appropriate. =3D=3D=3D=3D Session I -- 2010-07-26 =3D=3D=3D=3D=3D =3D=3D=3D=3D The chairs thank Mark Mcfaddon =3D=3D=3D=3D Action Items for DNSEXT - 2010 07 26 Existing item: RFC 2671bis Existing item: RFC 2672bis-dname - needs more text and should go back to the list - intent for this to be last-called again. Existing item: dnssec-registry-fixes - a new document will show up soon and thus there is no discussion in the WG - process issue will be dealt with a discussion on the list when there is a= new version Existing item: draft-ietf-dnsext-dnssec-bis-updates - small number of hums for the "roll over and die" text is not okay and no = hums for the text is okay - observation: few seem to have read the draft - demonstration of the "roll over and die" behaviour was given - CD-bit handling: nobody objected to having a default - unlike the two peo= ple on the mailing list - CD-bit handling: propose "Always set" as the default - nobody objected to= this proposal - CD-bit handling: this proposal will be taken to the list - CD-bit handling: the intent is to last call this document in short order Proposed new major work item: "aliasing", "synonymy", &c. - BNAME, C+DNAME, other ideas. - discussion: should we do one of these regardless of the situation with ID= N? - discussion: is this a solution for an existing problem, or a general appr= oach that might be of use for many problem=20 definitions. - discussion: it is possible to do this through provisioning rather than th= rough protocol changes. - discussion: C+DNAME testing by Ondrej Sury - fundamentally works properly= in a test zone; with some known problems - observation: are there are problems that cannot be solved by either of th= ese solutions? There appears to be a list that=20 will be provided to the mailing list - Observation: some resolvers do not support DNAME - Sense of the room: 2/3 of the room had read BNAME, C+DNAME, and Shadow Dr= afts - Sense of the room: 1/3 of the room had read the Problem Statement draft - Shadow zones =20 o draft-vixie-dnsext-dnsshadow-00 - agreement: shadow does have utility outside of BNAME and C+DNAME - discussion: seems to be some disagreement over whether or not to do this = work - action: whether or not to proceed on Shadow Zones will go to the mailing = list - Rationale/applicability. =20 o draft-yao-dnsext-identical-resolution-01 - discussion: Suzanne Wolff presented an overview of the probglem statement= draft and its goals Proposed new charter. - The proposed charter was posted to the mailing list: =20 http://www.psg.com/lists/namedroppers/namedroppers.2010/msg01836.html - Sense of the room: Could the work be moved earlier? two hands only Could= not? two hands only - Discussion: implementation is separate from making decisions about what w= ork to do in the WG - Rough consensus: move the dates up compared to the original draft prepare= d with the charter - Action Item: chairs will prpoduce another draft and send that to the IESG Returning work items. draft-crocker-dnssec-algo-signal-06 - In Stockholm last year, Patrik Faltstrom determined that this document wo= uld be needed if and only if something like=20 draft-ietf-dnsext-dnssec-alg-allocation were published. Since that is abou= t to happen, this document appears to be up for=20 adoption. =20 - Patrik has agreed to be shepherd. - Rough consensus: No objection to the arrangements for moving this documen= t forward Additional work items. IXFR-only: draft-kerr-ixfr-only-01 - Rough consensus: not proceed with this work, replace it with a larger doc= ument with more material (15 September or=20 proceed witht the current draft) DNSCURVE draft: draft-dempsky-dnscurve-01 - Supporters of the document need to come up with timelines - Consensus needs to be reached on the objections to adopting the document - Consensus by the 15 of Sepatember or this will default to a WG document URI DNSRR: draft-faltstrom-uri-05 - Don't need to adopt this in the Working Group because it is going through= the expert review process =3D=3D=3D=3D Session II -- 2010-07-28 =3D=3D=3D=3D =3D=3D=3D=3D The chairs thank Paul Hoffman =3D=3D=3D=3D DNSEXT Wednesday morning, 2010-07-28 Andrew Sullivan and Olafur Gudmundsson Minutes taken by Paul Hoffman Things from the slides not copied here You must read the slides to get more details Goal of this meeting: see if we are on the right track with the aliasing wo= rk we might add to the charter Andrew's introduction to the meeting What we have today CNAME and DNAME Second-class citizens Cannot be the target of an MX record Some people think (wrongly) that we already have aliasing finished Proposals so far CNAME+DNAME Many recursive servers don't do DNAME today BNAME SHADOW Provisioning Currently has deployment and usability issues Many people have said that "just provision" is not viable May not have the same folks administering the two sides Lots of things are out of scope All solutions will have some problems "First class citizen" issues for all of current proposals Purpose: to collect use cases Olaf Kolkman: does the "don't do anything" come under that header John Klensin: user community thinks that it has names that are equivalent Based on Unicode rules that say two spellings are equivalent One needs a pair of names (equal and symmetric) Real aliases Can be at any level Some people wants to ask about both names CNAMEs pointing in both directions: heads explode Andrew: is this about a character-to-character maps? John: that's only part of it: it is really label-to-label Related: changing the matching rules You made these ASCII labels match, make my language match the same way Antoin Verschuren: design of the DNS it self Worried if we are going to design something with aliases for nodes in the = system Becomes a web, not a tree: bad Only work if the aliases are for outside the DNS Ond=1Aej Sur=1A: which solutions need signalling? BNAME needs signalling, CNAME+DNAME doesn't Andrew: maybe both do Harald Alvestrand: most common use case for "we want these two be the same"= is the web If everything is friendly, we don't need the DNS There are lots of ifs Someone owning a higher-level zone want to tell people in lower zones how = to do things Maybe easier for the top to do things correctly underneath than having all= the bottom pieces do it right Aliases can be helpful, but is neither necessary nor sufficient; makes thi= ngs a good bit simpler Towards John: I don't have any idea what "equal" means John: if we optimize for the web, we are making a bad decision EAI means we will see a whole new domain of use cases =46rom Phill Hallam-Baker on Jabber: We need to do the shadow approach Same fixes needed for shadow will be needed for the other solutions as well John: making lots of assumptions of what applications need I thought that we were not cutting things off here Doug Barton on Jabber: What is the use cases for equivalence? John: Unicode is a mixture of legacy scripts that made a strange mixture People type on keyboards (input method editors) Easy to get different characters from similar users Can type things the same that look the same on the screen, they might not= match Spelling cases of different sorts: color vs. colour Lots of divergence even in one spoken language When normal people look at them, they see the same things Expectation that computers will fix this Suzanne Woolf: we need more examples on the mailing list in order to fully = develop the problem statement Ond=1Aej: equivalence of two labels doesn't need to be equivalence in the D= NS Can make a framework that will work elsewhere, not in the DNS Andrew: can have the underlying DNS layer and a different layer where they= are looked up Ond=1Aej: you already have that in other layers: Apache handles this Andrew: mail server has this problem Ond=1Aej: can relax the rule for mail servers Andrew: the mail specifications are outside our scope Paul Hoffman: you can choose them to be Andrew: there is tension between working groups Ond=1Aej: you just need to be careful what your target is pointing to Andrew: see what Harald said earlier: the entire tree issue People down the tree won't know that they are in an alias Suppose we have two input methods: can't know you are inside an aliase tr= ee Ond=1Aej: If you are there, you can't change anything anyway This is just one more place where things go wrong if you do them wrong John: when we first looked at IDNs, one conclusion was that we couldn't do = this fully in DNS This is a descendent from before Some decided either DNSNG or something else that did mapping Design systems princidple is where you draw the line Instead of keep kludging in the DNS, consider doing one of those options Could have different deployment options between them Maybe say "at this level of DNS abuse, we must stop" Paul: we tried to work on some of these, but there was no user interest John: if we have something that almost works, we can't start work on somet= hing that might be better But we might be approaching "the current stuff doesn't work" Andrew: what are the weird effect John: if the user hears "x is equivalent to y", they think "everyplace I u= se x I can use y" Also "I can find y if I look up x" Pure trees are lousy for human knowledge and queries Have to careful with cross-tree pointers Andrew: send this to Suzanne Olaf: what is the timescales in which we need solutions Different time scales might allow kludges or might force real solutions Adding kludges to a point where you making a promised that it will be a wo= rkable solution: You wasted time and energy Yao Jiankang: the problem is that the user says domain a and domain b are e= qual Thus they want same resolution Harald: domains will be declared equal whether we like it or not Question is: will doing standards work in the IETF make life better or wor= se Alfred H?nes: the DNS is tree structured You can't have true equivalence in a tree Some points will be first class Only solution is the have replication All examples from Unicode show only the registrant can decide what is equi= valent to what they registered We might be able to capture what the registrant wants equivalent We need a canonical form for correctness: DNSSEC We need a canonical form to avoid combinational explosion at multiple leve= ls of the tree Pointers to the canonical form Olafur asks questions: Apps folks: do the proposals help here: not enough information, no one sai= d yes, some said no Timeline: this is in the next few weeks Get your examples to us soon that --TYecfFk8j8mZq+dy-- From owner-namedroppers@ops.ietf.org Tue Aug 10 21:27: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 C80DB3A699E; Tue, 10 Aug 2010 21:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.546 X-Spam-Level: X-Spam-Status: No, score=-108.546 tagged_above=-999 required=5 tests=[AWL=0.549, 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, 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 fB8iBiVneYp7; Tue, 10 Aug 2010 21:27:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 885773A68D7; Tue, 10 Aug 2010 21:27:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj2mN-000Ljh-J9 for namedroppers-data0@psg.com; Wed, 11 Aug 2010 04:19:03 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj2mK-000LjH-G1 for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 04:19:01 +0000 Received: (qmail 77673 invoked from network); 11 Aug 2010 04:18:54 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 11 Aug 2010 04:18:54 -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=k1008; olt=johnl@user.iecc.com; bh=mfCObmepdqP2pXYHkbvNwknECCKGSl7rV4u6KFYqKIU=; b=Eb7Mre1pODl02ri08elb+D/OAIf3fy3IIdj53ktXbmMpRhk6bYqckJ/dknzkMyWLsxhO9y1236n6sBXux2r4J+IhrYFIIclWusVfHqgZEazCCrgZbNrUEoWY9JOxcBOLQ+/dS+GBPREt3vZluj8oPhfuGJJeHKJ1e4NIt6TROGI= Date: 11 Aug 2010 04:18:53 -0000 Message-ID: <20100811041853.46585.qmail@joyce.lan> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" In-Reply-To: <20100810133649.GC52191@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: > 4. Provisioning only: document how to do what's needed by > provisioning, and explain why the WG is not doing anything else. Yeah. Anyone been following the progress of the recent ICANN IDN TLDs? They're as good a live experiment in cloning trees via provisioning as we're likely to find. R's, John From owner-namedroppers@ops.ietf.org Tue Aug 10 22:06: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 BFD693A699E; Tue, 10 Aug 2010 22:06: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: -97.534 X-Spam-Level: X-Spam-Status: No, score=-97.534 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_05=-1.11, 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, 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 e-gKYnTV8I3n; Tue, 10 Aug 2010 22:06:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C6D3D3A69EF; Tue, 10 Aug 2010 22:06:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj3T2-00013l-SH for namedroppers-data0@psg.com; Wed, 11 Aug 2010 05:03:08 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj3T0-00013L-9C for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 05:03:06 +0000 Received: (eyou send program); Wed, 11 Aug 2010 13:03:04 +0800 Message-ID: <481502984.03751@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, 11 Aug 2010 13:03:04 +0800 Message-ID: From: "Jiankang YAO" To: "John Levine" , Cc: References: <481501584.15255@cnnic.cn> Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" Date: Wed, 11 Aug 2010 13:03:24 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: SSBoYXZlIGJlZW4gaW52b2x2aW5nIGluIHRoZSBpY2FubiBpZG4gcHJvY2VzcyBmb3IgbWFueSB5 ZWFycy4NCg0KaWYgcHJvdmlzaW9uaW5nIHdvcmtzLCBpY2FubiB3b3VsZCBoYXZlIHVzZWQgcHJv dmlzaW5nLg0KDQpJY2FubiBpZG4gdGxkcyBuZWVkIHRoZSBzb2x1dGlvbiBzdWNoIGFzIGJuYW1l Lg0KDQoNCiANCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSm9obiBMZXZp bmUiIDxqb2hubEBpZWNjLmNvbT4NClRvOiA8bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZz4NCkNj OiA8YWpzQHNoaW5rdXJvLmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDExLCAyMDEwIDEy OjE4IFBNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gRE5TRVhUIGNoYXJ0ZXIgYW5kIHRyZWF0aW5n IEROUyBuYW1lcyBhcyAidGhlIHNhbWUiDQoNCg0KPj4gICAgNC4gIFByb3Zpc2lvbmluZyBvbmx5 OiBkb2N1bWVudCBob3cgdG8gZG8gd2hhdCdzIG5lZWRlZCBieQ0KPj4gICAgcHJvdmlzaW9uaW5n LCBhbmQgZXhwbGFpbiB3aHkgdGhlIFdHIGlzIG5vdCBkb2luZyBhbnl0aGluZyBlbHNlLg0KPiAN Cj4gWWVhaC4NCj4gDQo+IEFueW9uZSBiZWVuIGZvbGxvd2luZyB0aGUgcHJvZ3Jlc3Mgb2YgdGhl IHJlY2VudCBJQ0FOTiBJRE4gVExEcz8NCj4gVGhleSdyZSBhcyBnb29kIGEgbGl2ZSBleHBlcmlt ZW50IGluIGNsb25pbmcgdHJlZXMgdmlhIHByb3Zpc2lvbmluZyBhcw0KPiB3ZSdyZSBsaWtlbHkg dG8gZmluZC4NCj4gDQo+IFIncywNCj4gSm9obg0KPg== From owner-namedroppers@ops.ietf.org Tue Aug 10 22:24: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 9CA153A69FE; Tue, 10 Aug 2010 22:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.624 X-Spam-Level: X-Spam-Status: No, score=-108.624 tagged_above=-999 required=5 tests=[AWL=0.471, 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, 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 gYO29RonSZNW; Tue, 10 Aug 2010 22:24:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 90AE23A69EF; Tue, 10 Aug 2010 22:24:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj3kO-0003Dx-CL for namedroppers-data0@psg.com; Wed, 11 Aug 2010 05:21:04 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj3kL-0003Dh-KR for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 05:21:02 +0000 Received: (qmail 4107 invoked from network); 11 Aug 2010 05:21:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=6FNKurTiMjtOJ0Hn5ADk3WuoXsQYan+VTMG6z8Ylx4A=; b=le8Ahhu9h94S2OnDKKRyUZNq65xwWZV+uG7uPjmQIW5c3VQm+M+1MK9ZbpNBfHo6Nl5n4p7ZT2pT3tD9W1lCmGYBHlKwyRLsqFZoq/oDFpmPUsMGwJxYdQhLO3JZIKvvHAuGlj0Mk5mlwvgfPwBDj0nE5ysDI5VgLEjlZ2I8FeI= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Aug 2010 05:20:38 -0000 Date: 11 Aug 2010 01:20:59 -0400 Message-ID: From: "John R. Levine" To: "Jiankang YAO" Cc: namedroppers@ops.ietf.org, ajs@shinkuro.com Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" In-Reply-To: References: <481501584.15255@cnnic.cn> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > I have been involving in the icann idn process for many years. > > if provisioning works, icann would have used provising. Hmmn. I see that CNNIC says in section 5 of their implementation plan for the IDN ccTLDs that they're making traditional and simplified Chinese domain names equivalent. If they're not doing that by provisioning, what are they're doing instead? http://www.cnnic.cn/html/Dir/2010/06/12/5852.htm R's, John From owner-namedroppers@ops.ietf.org Tue Aug 10 22: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 AE7E83A69FA; Tue, 10 Aug 2010 22:44:12 -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: -98.263 X-Spam-Level: X-Spam-Status: No, score=-98.263 tagged_above=-999 required=5 tests=[AWL=0.188, 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, 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 j5LGrw4kQ6zO; Tue, 10 Aug 2010 22:44:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7E3DD3A68C0; Tue, 10 Aug 2010 22:44:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj430-0005Qk-1n for namedroppers-data0@psg.com; Wed, 11 Aug 2010 05:40:18 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj42x-0005QP-F5 for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 05:40:15 +0000 Received: (eyou send program); Wed, 11 Aug 2010 13:40:14 +0800 Message-ID: <481505214.29344@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, 11 Aug 2010 13:40:14 +0800 Message-ID: From: "Jiankang YAO" To: "John R. Levine" Cc: , References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" Date: Wed, 11 Aug 2010 13:40:34 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: cHJvdmlzaW9uIGlzIHRoZSBwb2xpY3kgYmFzZWQsIG5vdCB0aGUgdGVjaG5vbG9neSBiYXNlZC4N Cg0KaXQgaXMgbm90IGEgbG9uZyB0ZXJtIHNvbHV0aW9uOyBpdCBpcyBhIHNob3J0IHNvbHV0aW9u Lg0KDQpsb25nIHRlcm0gc29sdXRpb24gbmVlZHMgdGhlIHRlY2hub2xvZ3kgc29sdXRpb24gIHN1 Y2ggYXMgYm5hbWUuDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJK b2huIFIuIExldmluZSIgPGpvaG5sQGllY2MuY29tPg0KVG86ICJKaWFua2FuZyBZQU8iIDx5YW9q a0Bjbm5pYy5jbj4NCkNjOiA8bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZz47IDxhanNAc2hpbmt1 cm8uY29tPg0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTEsIDIwMTAgMToyMCBQTQ0KU3ViamVj dDogUmU6IFtkbnNleHRdIEROU0VYVCBjaGFydGVyIGFuZCB0cmVhdGluZyBETlMgbmFtZXMgYXMg InRoZSBzYW1lIg0KDQoNCj4+IEkgaGF2ZSBiZWVuIGludm9sdmluZyBpbiB0aGUgaWNhbm4gaWRu IHByb2Nlc3MgZm9yIG1hbnkgeWVhcnMuDQo+Pg0KPj4gaWYgcHJvdmlzaW9uaW5nIHdvcmtzLCBp Y2FubiB3b3VsZCBoYXZlIHVzZWQgcHJvdmlzaW5nLg0KPiANCj4gSG1tbi4gIEkgc2VlIHRoYXQg Q05OSUMgc2F5cyBpbiBzZWN0aW9uIDUgb2YgdGhlaXIgaW1wbGVtZW50YXRpb24gcGxhbiBmb3Ig DQo+IHRoZSBJRE4gY2NUTERzIHRoYXQgdGhleSdyZSBtYWtpbmcgdHJhZGl0aW9uYWwgYW5kIHNp bXBsaWZpZWQgQ2hpbmVzZSANCj4gZG9tYWluIG5hbWVzIGVxdWl2YWxlbnQuICBJZiB0aGV5J3Jl IG5vdCBkb2luZyB0aGF0IGJ5IHByb3Zpc2lvbmluZywgd2hhdCANCj4gYXJlIHRoZXkncmUgZG9p bmcgaW5zdGVhZD8NCj4gDQo+IGh0dHA6Ly93d3cuY25uaWMuY24vaHRtbC9EaXIvMjAxMC8wNi8x Mi81ODUyLmh0bQ0KPiANCj4gUidzLA0KPiBKb2hu From owner-namedroppers@ops.ietf.org Tue Aug 10 23:08: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 6262E28C0E0; Tue, 10 Aug 2010 23:08: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: -97.262 X-Spam-Level: X-Spam-Status: No, score=-97.262 tagged_above=-999 required=5 tests=[AWL=-0.823, BAYES_00=-2.599, FAKE_REPLY_C=2.012, 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, 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 sW9Aca3JN+zs; Tue, 10 Aug 2010 23:08:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A32393A68DE; Tue, 10 Aug 2010 23:08:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj4RS-0008lz-38 for namedroppers-data0@psg.com; Wed, 11 Aug 2010 06:05:34 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj4RP-0008lP-7Z for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 06:05:31 +0000 Received: (eyou send program); Wed, 11 Aug 2010 14:05:30 +0800 Message-ID: <481506730.11282@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, 11 Aug 2010 14:05:30 +0800 Message-ID: <38861D0BF73F4076A9E981F2CC688A7A@LENOVO47E041CF> From: "Jiankang YAO" To: "John R. Levine" Cc: , Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" Date: Wed, 11 Aug 2010 13:57:09 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Y3VycmVudCBwcm9jZXNzIGlzIHRoZSBpY2FubiBpZG4gZmFzdCB0cmFjay4NCg0Kb3RoZXIgaWNh bm4gaWRuIHByb2Nlc3NlcyBzdWNoIGFzIGd0bGQgaWRuIHRsZCBhcmUgd2FpdGluZyBmb3IgZG5z c2V4dCdzIHRlY2hub2xvZ3kgc29sdXRpb24uICANCg0KaWYgY2hhaXJzIG9yIHdnIHNhaWQgdGhh dCB3ZSBjYW4gZG8gcHJvdmlzaW9uIGFuZCB3ZSBkbyBub3QgbmVlZCBhIHRlY2hub2xvZ3ksIERv bid0IHNodW4gYXdheSBmcm9tIG91ciByZXNwb25zaWJpbGl0eSwgcGxlYXNlLg0KDQoNCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSmlhbmthbmcgWUFPIiA8eWFvamtAY25u aWMuY24+DQpUbzogIkpvaG4gUi4gTGV2aW5lIiA8am9obmxAaWVjYy5jb20+DQpDYzogPG5hbWVk cm9wcGVyc0BvcHMuaWV0Zi5vcmc+OyA8YWpzQHNoaW5rdXJvLmNvbT4NClNlbnQ6IFdlZG5lc2Rh eSwgQXVndXN0IDExLCAyMDEwIDE6NDAgUE0NClN1YmplY3Q6IFJlOiBbZG5zZXh0XSBETlNFWFQg Y2hhcnRlciBhbmQgdHJlYXRpbmcgRE5TIG5hbWVzIGFzICJ0aGUgc2FtZSINCg0KDQo+IHByb3Zp c2lvbiBpcyB0aGUgcG9saWN5IGJhc2VkLCBub3QgdGhlIHRlY2hub2xvZ3kgYmFzZWQuDQo+IA0K PiBpdCBpcyBub3QgYSBsb25nIHRlcm0gc29sdXRpb247IGl0IGlzIGEgc2hvcnQgc29sdXRpb24u DQo+IA0KPiBsb25nIHRlcm0gc29sdXRpb24gbmVlZHMgdGhlIHRlY2hub2xvZ3kgc29sdXRpb24g IHN1Y2ggYXMgYm5hbWUuDQo+IA0KPiANCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAN Cj4gRnJvbTogIkpvaG4gUi4gTGV2aW5lIiA8am9obmxAaWVjYy5jb20+DQo+IFRvOiAiSmlhbmth bmcgWUFPIiA8eWFvamtAY25uaWMuY24+DQo+IENjOiA8bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9y Zz47IDxhanNAc2hpbmt1cm8uY29tPg0KPiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAxMSwgMjAx MCAxOjIwIFBNDQo+IFN1YmplY3Q6IFJlOiBbZG5zZXh0XSBETlNFWFQgY2hhcnRlciBhbmQgdHJl YXRpbmcgRE5TIG5hbWVzIGFzICJ0aGUgc2FtZSINCj4gDQo+IA0KPj4+IEkgaGF2ZSBiZWVuIGlu dm9sdmluZyBpbiB0aGUgaWNhbm4gaWRuIHByb2Nlc3MgZm9yIG1hbnkgeWVhcnMuDQo+Pj4NCj4+ PiBpZiBwcm92aXNpb25pbmcgd29ya3MsIGljYW5uIHdvdWxkIGhhdmUgdXNlZCBwcm92aXNpbmcu DQo+PiANCj4+IEhtbW4uICBJIHNlZSB0aGF0IENOTklDIHNheXMgaW4gc2VjdGlvbiA1IG9mIHRo ZWlyIGltcGxlbWVudGF0aW9uIHBsYW4gZm9yIA0KPj4gdGhlIElETiBjY1RMRHMgdGhhdCB0aGV5 J3JlIG1ha2luZyB0cmFkaXRpb25hbCBhbmQgc2ltcGxpZmllZCBDaGluZXNlIA0KPj4gZG9tYWlu IG5hbWVzIGVxdWl2YWxlbnQuICBJZiB0aGV5J3JlIG5vdCBkb2luZyB0aGF0IGJ5IHByb3Zpc2lv bmluZywgd2hhdCANCj4+IGFyZSB0aGV5J3JlIGRvaW5nIGluc3RlYWQ/DQo+PiANCj4+IGh0dHA6 Ly93d3cuY25uaWMuY24vaHRtbC9EaXIvMjAxMC8wNi8xMi81ODUyLmh0bQ0KPj4gDQo+PiBSJ3Ms DQo+PiBKb2hu From owner-namedroppers@ops.ietf.org Tue Aug 10 23:08: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 1B43228C0E0; Tue, 10 Aug 2010 23:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.664 X-Spam-Level: X-Spam-Status: No, score=-108.664 tagged_above=-999 required=5 tests=[AWL=0.431, 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, 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 aIYy7Hu36xK7; Tue, 10 Aug 2010 23:08:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 25B1D3A68DE; Tue, 10 Aug 2010 23:08:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj4Ra-0008n9-Cw for namedroppers-data0@psg.com; Wed, 11 Aug 2010 06:05:42 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj4RY-0008mm-5J for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 06:05:40 +0000 Received: (qmail 22619 invoked from network); 11 Aug 2010 06:05:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=RKA0vDA4qrIyU+kZBgN1k0PYkFUgq2T1bE8DqAw1tzk=; b=olTTcGWyF7ZEIC6+YxA8KecStS7HDWbv+zAsxPP81/BNU8hX4mgRueqIxJO8s6KNUEL8PiqQpWyy75JUB6F1IXTmuYQADSA5eO6cqipu39jdOXdt3uj3kcwbvHdi1t0jurE//im9/Tv/8UXFwn7Pv+eqgGQ8xAlG0ruE8YkVrFI= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Aug 2010 06:05:16 -0000 Date: 11 Aug 2010 02:05:38 -0400 Message-ID: From: "John R. Levine" To: "Jiankang YAO" Cc: namedroppers@ops.ietf.org, ajs@shinkuro.com Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" In-Reply-To: References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > provision is the policy based, not the technology based. > it is not a long term solution; it is a short solution. > long term solution needs the technology solution such as bname. Not to refight old battles here, but provisioning the DNS, whether manually or automatically, is only a small part of making two domains "the same". If the domains have web servers, the web servers need to be configured to accept names in both domains. If the domains accept mail, the mail servers have to be configured to accept names in both domains, possibly including the MX records if the mail server is in a domain different from the two "the same" ones. And so on and so forth for instant messaging, and every other protocol and subsystem that uses domain names. Something like BNAME might make the provisioning of the DNS somewhat easier, but I would argue that wouldn't solve enough of the overall problem to be worth doing. R's, John From owner-namedroppers@ops.ietf.org Tue Aug 10 23:17: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 25A3A3A69FC; Tue, 10 Aug 2010 23:17:17 -0700 (PDT) X-Quarantine-ID: <6ouqUEnig91j> 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: -97.204 X-Spam-Level: X-Spam-Status: No, score=-97.204 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, J_CHICKENPOX_55=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 6ouqUEnig91j; Tue, 10 Aug 2010 23:17:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 38DF13A69FA; Tue, 10 Aug 2010 23:17:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj4aN-000AGb-Rd for namedroppers-data0@psg.com; Wed, 11 Aug 2010 06:14:47 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj4aL-000AFx-9V for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 06:14:45 +0000 Received: (eyou send program); Wed, 11 Aug 2010 14:14:44 +0800 Message-ID: <481507284.31113@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, 11 Aug 2010 14:14:44 +0800 Message-ID: From: "Jiankang YAO" To: "Andrew Sullivan" , References: <20100804230904.GB4034@farside.isc.org> <05B243F724B2284986522B6ACD0504D7D3444A2CF6@EXVPMBX100-1.exc.icann.org> <20100805182146.GI38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D00@EXVPMBX100-1.exc.icann.org> <20100805183608.GJ38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D1B@EXVPMBX100-1.exc.icann.org> <20100810141322.GD52191@shinkuro.com> <3F9D6BF0A3BA40D5BA4044B7DC347FAA@LENOVO47E041CF> <20100810154446.GG52191@shinkuro.com> <42489A1B083D44EE953954C51D38BF66@LENOVO47E041CF> <481461720.01321@cnnic.cn> Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable? Date: Wed, 11 Aug 2010 14:12:49 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 OiBXZWRuZXNkYXksIEF1Z3VzdCAxMSwgMjAxMCAxOjE4IEFNDQpTdWJqZWN0OiBSZTogW2Ruc2V4 dF0gRG9lcyBETlNTRUMgbWVhbiBCTkFNRSBpcyB1bmRlcGxveWFibGU/DQoNCg0KPiBObyBoYXQu DQo+IA0KPiBPbiBXZWQsIEF1ZyAxMSwgMjAxMCBhdCAxMjoxMDo0N0FNICswODAwLCBKaWFua2Fu ZyBZQU8gd3JvdGU6DQo+IA0KPj4gb24gdGhlIG90aGVyIGhhbmQsDQo+PiB0ZXN0aW5nIG9uZSBk b2VzIG5vdCBtZWFuIHRoYXQgeW91IGNhbiBwcm92ZSBhbGwuDQo+IA0KPiBUaGlzIGlzIGNlcnRh aW5seSB0cnVlLCBhbmQgaXQncyBvbmUgb2YgdGhlIHJlYXNvbnMgSSBmZWVsDQo+IHVuY29tZm9y dGFibGUgd2l0aCBDTkFNRStETkFNRS4NCj4gDQo+PiBmb2xsb3dpbmcgeW91ciBsb2dpYywgYWZ0 ZXIgZG5zc2VjLCB3ZSB3b3VsZCBub3QgaW52ZW50IHRoZSBuZXcgcnJ0eXBlLg0KPj4gDQo+PiBk b2VzIGRuc3NlYyBtZWFuIHRoZSBkZWFkIG9mIGFsbCBuZXcgcnJ0eXBlPw0KPiANCj4gWW91IGFy ZSBmYWlsaW5nIHRvIG1ha2UgYW4gaW1wb3J0YW50IGRpc3RpbmN0aW9uLCB3aGljaCBpcyBiZXR3 ZWVuDQo+IFJSVFlQRXMgdGhhdCBuZWVkIHNlcnZlci1zaWRlIHByb2Nlc3NpbmcgYW5kIHRob3Nl IHRoYXQgZG9uJ3QuICBUaGUNCj4gZm9ybWVyIGFyZSBhIGJpZyBkZWFsLCB3aGVyZWFzIHRoZSBs YXR0ZXIgY2FuIGJlIHRyZWF0ZWQgdHJpdmlhbGx5IGFzDQo+IHRoZSB1bmtub3duIHR5cGUgaW4g dGhvc2Ugc3lzdGVtcyB0aGF0IGRvbid0IHVuZGVyc3RhbmQgdGhlbS4gIEkNCj4gYWN0dWFsbHkg cG9pbnRlZCBvdXQgdGhpcyBkaXN0aW5jdGlvbiBpbiB0aGUgZmlyc3QgbWFpbCBpbiB0aGlzDQo+ IHRocmVhZC4gIElmIHlvdSBkb24ndCB0aGluayB0aGF0IGRpc3RpbmN0aW9uIGlzIGFuIGltcG9y dGFudCBvbmUgaW4NCj4gdGhpcyBjb250ZXh0LCB5b3UncmUgZ29pbmcgdG8gbmVlZCBhbiBhcmd1 bWVudCB0byBzdXBwb3J0IHN1Y2ggYQ0KPiBwb3NpdGlvbi4NCj4gDQoNCg0Kd2hldGhlciB0aGUg cnJ0eXBlIG5lZWRzIHRoZSBzZXJ2ZXItc2lkZSBwcm9jZXNzaW5nIG9yIG5vdCwNCg0KdGhlIGZp bmFsIHJlc3VsdCBpcyB0aGF0IHRoZSBjdXJyZW50IGRuc3NlYyByZXNvbHZlciBkb2VzIG5vdCBy ZWNvZ25pemUgb3Igc3VwcG9ydCB0aGUgbmV3IHJydHlwZS4NCg0KZG9lcyB0aGUgY3VycmVudCBk bnNzZWMgcmVzb2xvdmVycyBhdXRvbWF0aWNhbGx5IHJlY29nbml6ZSB0aGUgbmV3IHJydHlwZSB3 aGljaCBkb2VzIG5vdCBuZWVkIHRoZSBzZXJ2ZXItc2lkZSBwcm9jZXNzaW5nPw0KDQo= From owner-namedroppers@ops.ietf.org Tue Aug 10 23:34: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 E31293A6A07; Tue, 10 Aug 2010 23:34:09 -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: -98.228 X-Spam-Level: X-Spam-Status: No, score=-98.228 tagged_above=-999 required=5 tests=[AWL=0.223, 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, 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 JNsdKPZElBFJ; Tue, 10 Aug 2010 23:34:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D4F2F3A68B9; Tue, 10 Aug 2010 23:34:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj4pg-000CT2-3E for namedroppers-data0@psg.com; Wed, 11 Aug 2010 06:30:36 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj4pd-000CSR-7E for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 06:30:33 +0000 Received: (eyou send program); Wed, 11 Aug 2010 14:30:32 +0800 Message-ID: <481508232.31113@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, 11 Aug 2010 14:30:32 +0800 Message-ID: <26363F2859DD43A986B234970885B286@LENOVO47E041CF> From: "Jiankang YAO" To: "John R. Levine" Cc: , References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <481507397.12476@cnnic.cn> Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" Date: Wed, 11 Aug 2010 14:30:41 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gUi4gTGV2aW5lIiA8 am9obmxAaWVjYy5jb20+DQpUbzogIkppYW5rYW5nIFlBTyIgPHlhb2prQGNubmljLmNuPg0KQ2M6 IDxuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnPjsgPGFqc0BzaGlua3Vyby5jb20+DQpTZW50OiBX ZWRuZXNkYXksIEF1Z3VzdCAxMSwgMjAxMCAyOjA1IFBNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0g RE5TRVhUIGNoYXJ0ZXIgYW5kIHRyZWF0aW5nIEROUyBuYW1lcyBhcyAidGhlIHNhbWUiDQoNCg0K Pj4gcHJvdmlzaW9uIGlzIHRoZSBwb2xpY3kgYmFzZWQsIG5vdCB0aGUgdGVjaG5vbG9neSBiYXNl ZC4NCj4+IGl0IGlzIG5vdCBhIGxvbmcgdGVybSBzb2x1dGlvbjsgaXQgaXMgYSBzaG9ydCBzb2x1 dGlvbi4NCj4+IGxvbmcgdGVybSBzb2x1dGlvbiBuZWVkcyB0aGUgdGVjaG5vbG9neSBzb2x1dGlv biAgc3VjaCBhcyBibmFtZS4NCj4gDQo+IE5vdCB0byByZWZpZ2h0IG9sZCBiYXR0bGVzIGhlcmUs IGJ1dCBwcm92aXNpb25pbmcgdGhlIEROUywgd2hldGhlciANCj4gbWFudWFsbHkgb3IgYXV0b21h dGljYWxseSwgaXMgb25seSBhIHNtYWxsIHBhcnQgb2YgbWFraW5nIHR3byBkb21haW5zICJ0aGUg DQo+IHNhbWUiLg0KPiANCj4gSWYgdGhlIGRvbWFpbnMgaGF2ZSB3ZWIgc2VydmVycywgdGhlIHdl YiBzZXJ2ZXJzIG5lZWQgdG8gYmUgY29uZmlndXJlZCB0byANCj4gYWNjZXB0IG5hbWVzIGluIGJv dGggZG9tYWlucy4gIElmIHRoZSBkb21haW5zIGFjY2VwdCBtYWlsLCB0aGUgbWFpbCANCj4gc2Vy dmVycyBoYXZlIHRvIGJlIGNvbmZpZ3VyZWQgdG8gYWNjZXB0IG5hbWVzIGluIGJvdGggZG9tYWlu cywgcG9zc2libHkgDQo+IGluY2x1ZGluZyB0aGUgTVggcmVjb3JkcyBpZiB0aGUgbWFpbCBzZXJ2 ZXIgaXMgaW4gYSBkb21haW4gZGlmZmVyZW50IGZyb20gDQo+IHRoZSB0d28gInRoZSBzYW1lIiBv bmVzLiAgQW5kIHNvIG9uIGFuZCBzbyBmb3J0aCBmb3IgaW5zdGFudCBtZXNzYWdpbmcsIA0KPiBh bmQgZXZlcnkgb3RoZXIgcHJvdG9jb2wgYW5kIHN1YnN5c3RlbSB0aGF0IHVzZXMgZG9tYWluIG5h bWVzLg0KPiANCj4gU29tZXRoaW5nIGxpa2UgQk5BTUUgbWlnaHQgbWFrZSB0aGUgcHJvdmlzaW9u aW5nIG9mIHRoZSBETlMgc29tZXdoYXQgDQo+IGVhc2llciwgYnV0IEkgd291bGQgYXJndWUgdGhh dCB3b3VsZG4ndCBzb2x2ZSBlbm91Z2ggb2YgdGhlIG92ZXJhbGwgDQo+IHByb2JsZW0gdG8gYmUg d29ydGggZG9pbmcuDQo+IA0KDQpmb3IgZG9tYWluIG5hbWUgZGVsZWdhdGlvbnMsICB0aGUgYm5h bWUgaXMgcGVyZmVjdCBmb3IgZG9tYWluIG5hbWUgcmVnaXN0cnkgc3VjaCBhcyBpY2FubiwgdGxk IG9wZXJhdG9ycy4NCg0KDQoNCj4gUidzLA0KPiBKb2huDQo+ From owner-namedroppers@ops.ietf.org Wed Aug 11 01:31: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 92FE43A68D3; Wed, 11 Aug 2010 01:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEGzi3ypaL52; Wed, 11 Aug 2010 01:31:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A38D3A6A44; Wed, 11 Aug 2010 01:31:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj6dU-0001m8-8p for namedroppers-data0@psg.com; Wed, 11 Aug 2010 08:26:08 +0000 Received: from [85.17.178.138] (helo=rotring.dds.nl) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj6dR-0001le-JX for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 08:26:05 +0000 Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id A60225822F; Wed, 11 Aug 2010 10:26:01 +0200 (CEST) Received: from vylkir.localdomain (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 12B3B5821D; Wed, 11 Aug 2010 10:25:47 +0200 (CEST) Message-ID: <4C625E89.7070705@nlnetlabs.nl> Date: Wed, 11 Aug 2010 10:25:45 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1 MIME-Version: 1.0 To: Jiankang YAO CC: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable? References: <20100804230904.GB4034@farside.isc.org> <05B243F724B2284986522B6ACD0504D7D3444A2CF6@EXVPMBX100-1.exc.icann.org> <20100805182146.GI38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D00@EXVPMBX100-1.exc.icann.org> <20100805183608.GJ38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D1B@EXVPMBX100-1.exc.icann.org> <20100810141322.GD52191@shinkuro.com> <3F9D6BF0A3BA40D5BA4044B7DC347FAA@LENOVO47E041CF> <20100810154446.GG52191@shinkuro.com> <42489A1B083D44EE953954C51D38BF66@LENOVO47E041CF> <481461720.01321@cnnic.cn> <481507284.31113@cnnic.cn> In-Reply-To: <481507284.31113@cnnic.cn> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.1 at rotring X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Jiankang, On 08/11/2010 08:12 AM, Jiankang YAO wrote: > does the current dnssec resolovers automatically recognize the new rrtype which does not need the server-side processing? > Yes. Also the dnssec signers and authority servers can. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxiXokACgkQkDLqNwOhpPhMUACfb/mZxfbjRysMD85oVEu3H7+G +U8An0JjaqwPceVAD1lp/Ip1TmoGwcpm =Hy+g -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Wed Aug 11 04:43: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 3A7A33A682A; Wed, 11 Aug 2010 04:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.839 X-Spam-Level: X-Spam-Status: No, score=-99.839 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 T1vZ1BbAZGaK; Wed, 11 Aug 2010 04:43:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 263B13A693E; Wed, 11 Aug 2010 04:43:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj9cp-0003M6-Qp for namedroppers-data0@psg.com; Wed, 11 Aug 2010 11:37:39 +0000 Received: from [2001:df0:8:6::72] (helo=send12.jprs.co.jp) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oj9cn-0003Ji-2Z for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 11:37:37 +0000 Received: from sendsms12.jprs.co.jp (sendsms12.jprs.co.jp [202.11.17.114]) by send12.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id o7BBaaRN017550; Wed, 11 Aug 2010 20:36:36 +0900 (JST) Received: from sendsms12.jprs.co.jp (unknown [127.0.0.1]) by sendsms12.jprs.co.jp (Symantec Mail Security) with ESMTP id 17F8F336A; Wed, 11 Aug 2010 20:36:36 +0900 (JST) X-AuditID: ca0b1172-0000000800000914-d3-4c628b435b14 Date: Wed, 11 Aug 2010 20:36:35 +0900 (JST) Message-Id: <20100811.203635.43020306.fujiwara@jprs.co.jp> To: yaojk@cnnic.cn Cc: johnl@iecc.com, namedroppers@ops.ietf.org, ajs@shinkuro.com Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" From: fujiwara@jprs.co.jp In-Reply-To: <481508232.31113@cnnic.cn> References: <481507397.12476@cnnic.cn> <481508232.31113@cnnic.cn> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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: "Jiankang YAO" > ----- Original Message ----- > From: "John R. Levine" > To: "Jiankang YAO" > Cc: ; > Sent: Wednesday, August 11, 2010 2:05 PM > Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" > > >>> provision is the policy based, not the technology based. >>> it is not a long term solution; it is a short solution. >>> long term solution needs the technology solution such as bname. >> >> Not to refight old battles here, but provisioning the DNS, whether >> manually or automatically, is only a small part of making two domains "the >> same". >> >> If the domains have web servers, the web servers need to be configured to >> accept names in both domains. If the domains accept mail, the mail >> servers have to be configured to accept names in both domains, possibly >> including the MX records if the mail server is in a domain different from >> the two "the same" ones. And so on and so forth for instant messaging, >> and every other protocol and subsystem that uses domain names. >> >> Something like BNAME might make the provisioning of the DNS somewhat >> easier, but I would argue that wouldn't solve enough of the overall >> problem to be worth doing. >> > > for domain name delegations, the bname is perfect for domain name registry such as icann, tld operators. There are many solutions. 1. BNAME + Server configuration change for all servers. -> TLD's work is limited, but all registrants need to configure their servers. 2. New DNS software which generates synthesized CNAME with online signing for each query. + Server configuration change for all servers. -> Same as BNAME, but no DNS protocol change is required. Special DNS software solves BNAME problem. May I write prototype implemetation ? 3. Update IDNA. Implement TLD specific preprocess in the application. -> It does not need changes for TLDs, DNS protocols, servers. # I think it is a perfect solution, but too late to say. -- Kazunori Fujiwara, JPRS From info@webmaster.org Wed Aug 11 04: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 4CF2D3A686E for ; Wed, 11 Aug 2010 04:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.536 X-Spam-Level: X-Spam-Status: No, score=0.536 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_MX=0.535] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6buHRKuAqCw for ; Wed, 11 Aug 2010 04:46:24 -0700 (PDT) Received: from server.cecac.edu.mx (server.cecac.edu.mx [96.31.77.129]) by core3.amsl.com (Postfix) with ESMTP id 5FB673A6844 for ; Wed, 11 Aug 2010 04:46:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=webmail.cecac.edu.mx) by server.cecac.edu.mx with esmtpa (Exim 4.69) (envelope-from ) id 1Oj8B5-0001NA-FU; Wed, 11 Aug 2010 14:04:55 +0400 Received: from 203.92.211.166 ([203.92.211.166]) (proxying for 203.92.211.166) (SquirrelMail authenticated user mcalvarez@cecac.edu.mx) by webmail.cecac.edu.mx with HTTP; Wed, 11 Aug 2010 14:04:55 +0400 Message-ID: Date: Wed, 11 Aug 2010 14:04:55 +0400 Subject: Confirma tu cuenta de correo web From: "info_webmaster" Reply-To: customercarewebdept20@9.cn User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.cecac.edu.mx X-AntiAbuse: Original Domain - lists.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - webmaster.org To: undisclosed-recipients:; Estimado usuario de correo web, Lamentamos anunciarles que vamos a hacer algo de mantenimiento vital en nuestro webmail base de datos. Durante este proceso es posible que tenga problemas de entrada en la firma en su cuenta en línea, pero para evitar esto tienes que confirmar tu cuenta inmediatamente después de recibir este notificación. Para confirmar y mantener su cuenta activa durante y después de este proceso, por favor Responder a este mensaje con la siguiente información de la cuenta. De no hacerlo, podría causar la desactivación permanente de su cuenta de usuario de la base de datos que nos permita crear más espacios para los nuevos usuarios. Confirmar sus datos de cuenta a continuación: =================================== Nombre: E-mail ID: E-mail Contraseña: Fecha de nacimiento: =================================== Esta actualización es obligatoria, como resultado de nuestro servidor de cambios recientes. Si usted no actualizar su dirección de correo electrónico que pronto será incapaz de recibir / enviar su mails.Also correo electrónico no será equipado con el último sistema anti-virus en nuestros nuevos servidores. Esto hará que su correo electrónico y el PC vulnerable a ataques de virus desde Internet. Su cuenta permanecerá activa después de haber confirmado exitosamente su cuenta detalles. Código de confirmación: -/93-1A388-480 Webmail Soporte Técnico del equipo. Gracias por su paciencia, Webmail Mesa de Ayuda. WEB MAIL BETA ================================================== ==== Este mensaje electrónico está dirigido sólo a su destinatario indicado anteriormente y puede contienen información confidencial, privilegiada o privada, legalmente, que no es para uso general o de la divulgación. Si no es el destinatario, se le notifica que cualquier divulgación, copia, distribución o la toma de cualquier acción basada en el contenido de este mensaje está estrictamente prohibido. Si recibe este mensaje por error, por favor indíquenos por mensaje de respuesta y luego borre este mensaje de su sistema. Su cooperación es apreciada. ================================================== ==== Gracias por su colaboración From owner-namedroppers@ops.ietf.org Wed Aug 11 07: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 67FA73A6862; Wed, 11 Aug 2010 07:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.818 X-Spam-Level: X-Spam-Status: No, score=-99.818 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 oTkpuQuvxjdf; Wed, 11 Aug 2010 07:01:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D51463A6835; Wed, 11 Aug 2010 07:01:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjBnp-000POS-1B for namedroppers-data0@psg.com; Wed, 11 Aug 2010 13:57:09 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjBnm-000PLW-GL for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 13:57: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 D43931ECB41D for ; Wed, 11 Aug 2010 13:57:02 +0000 (UTC) Date: Wed, 11 Aug 2010 09:56:58 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") Message-ID: <20100811135657.GA57645@shinkuro.com> References: <481501584.15255@cnnic.cn> <481504066.03751@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: Colleagues, I'm writing this as co-chair, as an attempt to make the arguments on both sides as clear as possible. I know some of you have expressed weariness at this topic, and would like less traffic on it. I too would like that, so I'm hopeful that we can come to speedy conclusions about this topic and meet our aimed-for charter deadline in September. On Wed, Aug 11, 2010 at 01:40:34PM +0800, Jiankang YAO wrote: > provision is the policy based, not the technology based. > > it is not a long term solution; it is a short solution. > > long term solution needs the technology solution such as bname. This claim keeps getting repeated, but without any supporting argument. Without a supporting argument, I don't believe it. Here is the only argument I can think of. Please tell me whether it is the one (and only one) you would use. For those who think that we should not add more things to the DNS in order to solve some small percentage of cases, please tell me whether you think the case in question is big enough to meet the threshold where we might want to add something to the protocol, or whether you can think of ways other than BNAME (or something like it) to accomplish the same thing. Here's the supporting argument: Suppose we have two domain names, N1 and N2. These are to be delegated by parent P, such that there would be two zones N1.P and N2.P. Now, P's policy is that the zones N1 and N2 are to be maintained such that a user arriving at any name X.N1.P and a similar user arriving at any name X.N2.P will have an experience as though they were "the same name". (So, for instance, in a web environment these would be "the same" web site; mail destined to user@X.N1.P and to user@X.N2.P always reaches the same mailbox "user", and so on. This might need formal tightening, but for now this ostensive definition will do.) Under a provisioning-only regime, the requirement that N1.P and N2.P be "the same name" cannot be guaranteed. That is because under provisioning, it would be necessary to duplicate all the zones all the way down the tree, and there is no easy way in the DNS to check that two zones are equivalent without walking the zone. Is that the argument? Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Aug 11 07:21: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 39DAE3A6853; Wed, 11 Aug 2010 07:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_65=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 SZstL+lU-4WB; Wed, 11 Aug 2010 07:21:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB1A63A67B5; Wed, 11 Aug 2010 07:21:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjC7g-0002Y0-VB for namedroppers-data0@psg.com; Wed, 11 Aug 2010 14:17:40 +0000 Received: from [209.85.160.180] (helo=mail-gy0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjC7e-0002XV-7Z for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 14:17:38 +0000 Received: by gye5 with SMTP id 5so58395gye.11 for ; Wed, 11 Aug 2010 07:17: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:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MCkKZ/0vwvEzqZL57hVpybqQw/2qFn5RImdaO/1+2Rg=; b=kmH6zmhGa2HDjHBL1MbyV1QV8R0CFteznAby6xvYM7LAR+VaYX3Atykl4ohVkjII/g NSSjuHSEvLtS8xu6gs7BGJPkDpC94+bgRNrbkMMkiyZ1t1evOfljixvRDOG4OUdCcBvP rvH83Kw9H8W5AHlSqtwge5uvs+twvw2diiuMc= 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=ZxdsvUDHWarGRTsU7AoHh7qUAYOGx7jaNghL1H3KOqvcK+17WalD78COa61hmeHlvA PaONwWKnRF8p7rBjgmoW5BJgJaazyOJIqCwmh8q7PfnYJTX9Q4iLb7epbSFV2Mm8m7WP mkf/UODHMaPqlgLEx0sq3+vNjwWoBk8/xIgcQ= MIME-Version: 1.0 Received: by 10.100.127.15 with SMTP id z15mr21654853anc.213.1281536256561; Wed, 11 Aug 2010 07:17:36 -0700 (PDT) Received: by 10.101.188.15 with HTTP; Wed, 11 Aug 2010 07:17:36 -0700 (PDT) In-Reply-To: References: <481501584.15255@cnnic.cn> Date: Wed, 11 Aug 2010 10:17:36 -0400 Message-ID: Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" From: Phillip Hallam-Baker To: "John R. Levine" Cc: Jiankang YAO , namedroppers@ops.ietf.org, ajs@shinkuro.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: The difference is seen at the zone delegation points. And when I look at the issues there, the objective of making one tree look like another looks to raise security issues as far as I am concerned. Lets take the example where .china is introduced with the idea that it it is going to be a clone of .cn. This objective is not objectionable in itself, but it is not free of provisioning issues. Consider what happens when someone attempts to access google.china. Their Web browser finds the record that asserts *.china -> *.cn and attempts to access google.cn. What Host header does the browser use? Now before people start to say that this is an application issue. It is certainly an issue that the proponents of any scheme have to consider and provide an answer for. If someone wants to lay a rail line over an existing road, they have to build the bridge. Any proposals that fail to explain what the application level considerations are should be rejected as incomplete. It is certainly going to be a waste of time pitting them to IETF last call. The DNSEXT WG cannot make a DNS proposal that breaks HTTP. There are two options here. Either the host header is google.china, in which case the Web server has no idea what to do with the request as it does not serve that site. I really don't think we want Web servers being required to work out what the browser meant when presented an unknown host header Or the host header is google.cn in which case the Web server is unaware that the user requested a different URL. Probably the best approach would be to make the host header be the mapper URL and create a new header to tell the Web server what the original host was. But whatever way you try to slice up the back end, you cannot make this work without browsers being totally engaged in the DNS name translation process. Today they simply call gethostbyname. If you try to do transparent fixup in the DNS so that the client asks for google.china and gets back the A records for google.cn from the resolver, we now have a facility that can be used to establish transparent redirects without browsers ever being aware that they were redirected. The only point where the browser is going to find out is when SSL stops working because the site certificate is for a different domain. So now the user is going to be told that the cert does not match. On Wed, Aug 11, 2010 at 1:20 AM, John R. Levine wrote: >> I have been involving in the icann idn process for many years. >> >> if provisioning works, icann would have used provising. > > Hmmn. =A0I see that CNNIC says in section 5 of their implementation plan = for > the IDN ccTLDs that they're making traditional and simplified Chinese dom= ain > names equivalent. =A0If they're not doing that by provisioning, what are > they're doing instead? > > http://www.cnnic.cn/html/Dir/2010/06/12/5852.htm > > R's, > John > > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Wed Aug 11 07:24: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 B46123A695F; Wed, 11 Aug 2010 07:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.148 X-Spam-Level: X-Spam-Status: No, score=-9.148 tagged_above=-999 required=5 tests=[AWL=-0.953, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 Vl77cvUXmi4g; Wed, 11 Aug 2010 07:24:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9DD713A690D; Wed, 11 Aug 2010 07:24:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjCCZ-0003Ef-Jj for namedroppers-data0@psg.com; Wed, 11 Aug 2010 14:22:43 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjCCX-0003EP-9W for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 14:22:41 +0000 Authentication-Results: rtp-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: AvsEAF9PYkxAZnwM/2dsb2JhbACgJXGgPZtPhToEiVA X-IronPort-AV: E=Sophos;i="4.55,353,1278288000"; d="sig'?scan'208";a="146447860" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2010 14:22:40 +0000 Received: from dhcp-10-55-82-7.cisco.com (dhcp-10-55-82-7.cisco.com [10.55.82.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7BEMdNg029843; Wed, 11 Aug 2010 14:22:39 GMT Subject: Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-120-434164612" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100811135657.GA57645@shinkuro.com> Date: Wed, 11 Aug 2010 16:22:38 +0200 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <51AF9E88-C237-4435-990D-31FF06B1880E@cisco.com> References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <20100811135657.GA57645@shinkuro.com> To: Andrew Sullivan X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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-120-434164612 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 aug 2010, at 15.56, Andrew Sullivan wrote: > Under a provisioning-only regime, the requirement that N1.P and N2.P > be "the same name" cannot be guaranteed. That is because under > provisioning, it would be necessary to duplicate all the zones all the > way down the tree, and there is no easy way in the DNS to check that > two zones are equivalent without walking the zone. >=20 > Is that the argument? For me, yes, with the addition that it is not to me perfectly clear if = the risk is zero that competition rules in various legislations might = force the two zones N1.P and N2.P be delegated to entities according to = some RFP process that MIGHT result in the two domains be run by two = different registries. Specifically if N1.P exists, and N2.P is to be allocated. A competitor = to the registry for N1.P might very well ask to become the registry for = N2.P, if N2.P was in reality delegated. If instead N1.P is delegated, and N2.P was some pointer to N1.P, then = that competition argument would not exist. Patrik --Apple-Mail-120-434164612 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) iD8DBQFMYrIuvHlR2X0luNwRAteCAKDPfUehGzYlcEwxkw0wJC88cx6CkgCfeYSU y9f9Z7mHmN9V0rBDpSTLCoc= =4Aza -----END PGP SIGNATURE----- --Apple-Mail-120-434164612-- From owner-namedroppers@ops.ietf.org Wed Aug 11 07:33: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 1EFEE3A6405; Wed, 11 Aug 2010 07:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, 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 dlGyyfNVrmWa; Wed, 11 Aug 2010 07:33:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27FAB3A6979; Wed, 11 Aug 2010 07:33:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjCKJ-0004Wl-FJ for namedroppers-data0@psg.com; Wed, 11 Aug 2010 14:30:43 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjCKG-0004WI-7N for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 14:30:40 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id A87F33A6853; Wed, 11 Aug 2010 07:30: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-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100811143002.A87F33A6853@core3.amsl.com> Date: Wed, 11 Aug 2010 07:30: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 : Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Author(s) : S. Rose Filename : draft-ietf-dnsext-dnssec-registry-fixes-06.txt Pages : 8 Date : 2010-08-11 The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms that is incomplete in that it lacks the implementation status of each algorithm. This document provides an applicability statement on algorithm status for DNSSEC implementations. This document replaces that registry table with a new IANA registry table for Domain Name System Security (DNSSEC) Algorithm Numbers which lists each algorithm's status based on the current reference. If that status is not defined in the original specification, this document assigns a status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-fixes-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-11071624.I-D@ietf.org> --NextPart-- From owner-namedroppers@ops.ietf.org Wed Aug 11 08:05: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 E10F13A69F1; Wed, 11 Aug 2010 08:05:19 -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 AgPGMdSxqX33; Wed, 11 Aug 2010 08:05:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 696BF3A69A2; Wed, 11 Aug 2010 08:05:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjCmz-000995-9Z for namedroppers-data0@psg.com; Wed, 11 Aug 2010 15:00:21 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjCmw-00098a-Ai for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 15:00:18 +0000 Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o7BF03go031220 for ; Wed, 11 Aug 2010 11:00:03 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 11 Aug 2010 11:00:02 -0400 From: "Rose, Scott W." To: IETF DNSEXT WG Date: Wed, 11 Aug 2010 11:00:02 -0400 Subject: Re: {Blocked Content} [dnsext] I-D Action:draft-ietf-dnsext-dnssec-registry-fixes-06.txt Thread-Topic: {Blocked Content} [dnsext] I-D Action:draft-ietf-dnsext-dnssec-registry-fixes-06.txt Thread-Index: Acs5ZdSezkGyP4KpSgqrxlr7c8n0cw== Message-ID: <2A87990D-7BA6-4AE6-9FB4-C80A5102F38F@nist.gov> References: <20100811143002.A87F33A6853@core3.amsl.com> In-Reply-To: <20100811143002.A87F33A6853@core3.amsl.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" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: As you may be able to tell by the title, this updated version changes the tone of the draft. The draft now replaces the DNSSEC Security DNSKEY Algorithm entirely, and is authoritative for that registry and current status of all algorithms. This draft updates several RFC's (listed), and cannot be updated - only replaced with a new registry table. Comments welcome. I think I got all the language changed, but might have missed a bit here or there. Scott On Aug 11, 2010, at 10:30 AM, wrote: > Warning: This message has had one or more attachments removed > Warning: (not named). > Warning: Please read the following for more information. > > 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 : Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry > Author(s) : S. Rose > Filename : draft-ietf-dnsext-dnssec-registry-fixes-06.txt > Pages : 8 > Date : 2010-08-11 > > The DNS Security Extensions (DNSSEC) requires the use of > cryptographic algorithm suites for generating digital signatures over > DNS data. There is currently an IANA registry for these algorithms > that is incomplete in that it lacks the implementation status of each > algorithm. This document provides an applicability statement on > algorithm status for DNSSEC implementations. This document replaces > that registry table with a new IANA registry table for Domain Name > System Security (DNSSEC) Algorithm Numbers which lists each > algorithm's status based on the current reference. If that status is > not defined in the original specification, this document assigns a > status. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-fixes-06.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. > =================================== Scott Rose NIST scottr@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =================================== From owner-namedroppers@ops.ietf.org Wed Aug 11 08:26: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 76A073A6864; Wed, 11 Aug 2010 08:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.632 X-Spam-Level: X-Spam-Status: No, score=-0.632 tagged_above=-999 required=5 tests=[AWL=-0.437, 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 LjhC5S8AcaFx; Wed, 11 Aug 2010 08:26:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F13BC3A67D0; Wed, 11 Aug 2010 08:26:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjD7p-000CN1-Cr for namedroppers-data0@psg.com; Wed, 11 Aug 2010 15:21:53 +0000 Received: from [209.85.161.180] (helo=mail-gx0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjD7m-000CMZ-Dd for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 15:21:50 +0000 Received: by gxk22 with SMTP id 22so115398gxk.11 for ; Wed, 11 Aug 2010 08:21:49 -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=6VJRHVZiucefE2rMmpXCCJl+nf8/yOnXba5B9r0mN4Y=; b=AOk9WaDbVBfjMvAOOR931qoed1PGs7YdHGerAVZpjYFkRjGAIGfP06IqgOJmb0C1Gb Sxhk8zBy0bPyMkONeQuuptJJPa/GIOw8314VKaQwhpDb/ma+BZDSoB/IZ9XOpvOF3yd1 DHcRUgESorjyIhsDSt3u8UZVz3elzW2ZZYqlk= 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=XQ3Iih88Fz8Sg4eg/2T6fjlF6qBvCqMk09zC8A3kvmfycsWK2hZWelMTNqhXiJj9P0 Ao6XBqCVBor6Zr2I6xhFGro2XsAFeOwjWL41L9EFR8+cM9aBcjXXlBH3plotgcFX3r7y gKIQjmK+t0KM/8gQ1NRO2SQKz4jAhQqmBG7x0= MIME-Version: 1.0 Received: by 10.101.193.5 with SMTP id v5mr21670290anp.201.1281540106978; Wed, 11 Aug 2010 08:21:46 -0700 (PDT) Received: by 10.101.188.15 with HTTP; Wed, 11 Aug 2010 08:21:46 -0700 (PDT) In-Reply-To: <51AF9E88-C237-4435-990D-31FF06B1880E@cisco.com> References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <20100811135657.GA57645@shinkuro.com> <51AF9E88-C237-4435-990D-31FF06B1880E@cisco.com> Date: Wed, 11 Aug 2010 11:21:46 -0400 Message-ID: Subject: Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Andrew Sullivan , 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: This is what I believe the argument is. My point is that while provisioning is complex, introducing the pointer does not eliminate the complexity. All that is achieved is that the complexity is moved from the DNS provisioning process to the application configuration process. The provisioning problem also looks much worse if we look at the abstract capabilities of DNS as opposed to how it is being used in practice. In particular, DNS in theory allows for an almost infinite hierarchy of delegations, each of which may involve a change of authority. But in practice there are almost only ever two authorities which are significant, There is the TLD registry and there is the domain name holder. At the domain holder level, I am very skeptical of the need for hierarchy as we move from considering the DNS as being an infrastructure for configuring machines and towards considering it as a means for configuring services. With the exception of telnet/SSH and their ilk, there is no Internet application where the machine name is really relevant any more. I do not see any reason why the issues driving this proposal would be relevant to SSH, FTP, NNTP or any other. If we move to using SRV records to advertise Web Services, much of the pressure to use hierarchy at the domain holder level disappears. If HTTP had used SRV from the start there would be no www.google.com, there would be only google.com. One way in which we might perhaps square this circle is if we instead introduced a 'Did You Mean' Resource Record that is merely a variation of 'NXDOMAIN'. Such a record would have no processing semantics applied. If applications chose to use such records in their I18N processing, they are taking the full responsibility for working out what the interpretation is and how to fix it. One major difference is going to be in how applications treat hyperlinks. A browser might well and sensibly work out how to be liberal with user input. But being liberal with interpretation of URIs is a very, very bad plan. If there is no sand in the shoe when the job is done wrong, the Web soon becomes filled with unenumerated variations of wrongness and instead of a specification we end up with a set of heuristics. The result in this case would be links that only work sometimes. I am quite happy for a DYM record that can be used to facilitate user interaction in anyboxes. That seems sensible enough. But going beyond that gives me very bad feelings. I think it is at best a rat hole and a time sink. 2010/8/11 Patrik F=E4ltstr=F6m : > On 11 aug 2010, at 15.56, Andrew Sullivan wrote: > >> Under a provisioning-only regime, the requirement that N1.P and N2.P >> be "the same name" cannot be guaranteed. =A0That is because under >> provisioning, it would be necessary to duplicate all the zones all the >> way down the tree, and there is no easy way in the DNS to check that >> two zones are equivalent without walking the zone. >> >> Is that the argument? > > For me, yes, with the addition that it is not to me perfectly clear if th= e risk is zero that competition rules in various legislations might force t= he two zones N1.P and N2.P be delegated to entities according to some RFP p= rocess that MIGHT result in the two domains be run by two different registr= ies. > > Specifically if N1.P exists, and N2.P is to be allocated. A competitor to= the registry for N1.P might very well ask to become the registry for N2.P,= if N2.P was in reality delegated. > > If instead N1.P is delegated, and N2.P was some pointer to N1.P, then tha= t competition argument would not exist. > > =A0 Patrik > > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Wed Aug 11 08:26: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 E3ECB3A6864; Wed, 11 Aug 2010 08:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.624 X-Spam-Level: X-Spam-Status: No, score=-0.624 tagged_above=-999 required=5 tests=[AWL=-0.429, 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 rnH8NVAnXDE7; Wed, 11 Aug 2010 08:26:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B69E3A67D0; Wed, 11 Aug 2010 08:26:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjD97-000CZ1-HG for namedroppers-data0@psg.com; Wed, 11 Aug 2010 15:23:13 +0000 Received: from [209.85.161.180] (helo=mail-gx0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjD92-000CWs-RE for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 15:23:09 +0000 Received: by gxk22 with SMTP id 22so116133gxk.11 for ; Wed, 11 Aug 2010 08:23:08 -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=cG1/jSuZyvX51tAtLnqvKBy4MWaCHxA84NOIcclEA10=; b=D27TKMECXce5gHSKXhLRLpuGluSbSM6NxzgzVEr50SdU3kjkZAbfxZ/n6i1SRYDcFO /blbnEy1hLRSan2pZAAIr7MKLpzrKb7VJ6K7a6ZZqk5DuBuikYE7UvzDnPvuJ7dJECvg jY9lcvXaKpFjqRc9XVHOaDHUvIEFd7K4E38/A= 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=KeRiTkRYnmIO478WdUmw9SMl2320rQ/Ik3a1xaUCag+7NbI4AA0b6+6i41af3cjWyr yBbqwt/d+ueM2lfRsP9ctdcmQiI4CcmX/WV6nH4f7e/qUIqmktlOUSDVWLzNDK25T5/c kI+EfWzU6oulzBgGmdAkE0ZORIlsrY21GvGOw= MIME-Version: 1.0 Received: by 10.100.43.2 with SMTP id q2mr21927564anq.152.1281540188117; Wed, 11 Aug 2010 08:23:08 -0700 (PDT) Received: by 10.101.188.15 with HTTP; Wed, 11 Aug 2010 08:23:08 -0700 (PDT) In-Reply-To: References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <20100811135657.GA57645@shinkuro.com> <51AF9E88-C237-4435-990D-31FF06B1880E@cisco.com> Date: Wed, 11 Aug 2010 11:23:08 -0400 Message-ID: Subject: Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Andrew Sullivan , 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: Another consequence of the DYM approach is that there would be zero impact on DNSSEC. Which is another reason I prefer it. 2010/8/11 Phillip Hallam-Baker : > This is what I believe the argument is. > > My point is that while provisioning is complex, introducing the > pointer does not eliminate the complexity. All that is achieved is > that the complexity is moved from the DNS provisioning process to the > application configuration process. > > > The provisioning problem also looks much worse if we look at the > abstract capabilities of DNS as opposed to how it is being used in > practice. In particular, DNS in theory allows for an almost infinite > hierarchy of delegations, each of which may involve a change of > authority. But in practice there are almost only ever two authorities > which are significant, There is the TLD registry and there is the > domain name holder. > > At the domain holder level, I am very skeptical of the need for > hierarchy as we move from considering the DNS as being an > infrastructure for configuring machines and towards considering it as > a means for configuring services. With the exception of telnet/SSH and > their ilk, there is no Internet application where the machine name is > really relevant any more. I do not see any reason why the issues > driving this proposal would be relevant to SSH, FTP, NNTP or any > other. > > If we move to using SRV records to advertise Web Services, much of the > pressure to use hierarchy at the domain holder level disappears. If > HTTP had used SRV from the start there would be no www.google.com, > there would be only google.com. > > > One way in which we might perhaps square this circle is if we instead > introduced a 'Did You Mean' Resource Record that is merely a variation > of 'NXDOMAIN'. > > Such a record would have no processing semantics applied. If > applications chose to use such records in their I18N processing, they > are taking the full responsibility for working out what the > interpretation is and how to fix it. > > > One major difference is going to be in how applications treat > hyperlinks. A browser might well and sensibly work out how to be > liberal with user input. But being liberal with interpretation of URIs > is a very, very bad plan. If there is no sand in the shoe when the job > is done wrong, the Web soon becomes filled with unenumerated > variations of wrongness and instead of a specification we end up with > a set of heuristics. The result in this case would be links that only > work sometimes. > > I am quite happy for a DYM record that can be used to facilitate user > interaction in anyboxes. That seems sensible enough. But going beyond > that gives me very bad feelings. I think it is at best a rat hole and > a time sink. > > > 2010/8/11 Patrik F=E4ltstr=F6m : >> On 11 aug 2010, at 15.56, Andrew Sullivan wrote: >> >>> Under a provisioning-only regime, the requirement that N1.P and N2.P >>> be "the same name" cannot be guaranteed. =A0That is because under >>> provisioning, it would be necessary to duplicate all the zones all the >>> way down the tree, and there is no easy way in the DNS to check that >>> two zones are equivalent without walking the zone. >>> >>> Is that the argument? >> >> For me, yes, with the addition that it is not to me perfectly clear if t= he risk is zero that competition rules in various legislations might force = the two zones N1.P and N2.P be delegated to entities according to some RFP = process that MIGHT result in the two domains be run by two different regist= ries. >> >> Specifically if N1.P exists, and N2.P is to be allocated. A competitor t= o the registry for N1.P might very well ask to become the registry for N2.P= , if N2.P was in reality delegated. >> >> If instead N1.P is delegated, and N2.P was some pointer to N1.P, then th= at competition argument would not exist. >> >> =A0 Patrik >> >> > > > > -- > Website: http://hallambaker.com/ > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Wed Aug 11 08: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 A2C8B3A6864; Wed, 11 Aug 2010 08:27:17 -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: -98.254 X-Spam-Level: X-Spam-Status: No, score=-98.254 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 rhcQj1n4N80S; Wed, 11 Aug 2010 08:27:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 744B13A67D0; Wed, 11 Aug 2010 08:27:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjDAm-000Cnk-8g for namedroppers-data0@psg.com; Wed, 11 Aug 2010 15:24:56 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjDAj-000Cn9-I7 for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 15:24:54 +0000 Received: (eyou send program); Wed, 11 Aug 2010 23:24:51 +0800 Message-ID: <481540291.31022@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, 11 Aug 2010 23:24:51 +0800 Message-ID: <0E6D0A8F153741BDB7F27A94F79F8D7A@LENOVO47E041CF> From: "Jiankang YAO" To: Subject: [dnsext] alias algorithm for bname and other new rrtype Fw: I-D Action:draft-yao-dnsext-alias-algorithm-00.txt Date: Wed, 11 Aug 2010 23:25:08 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_03B2_01CB39AC.6FE11050" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_03B2_01CB39AC.6FE11050 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 bnNlYzMgb3IgYm5hbWUgYW5kIG1vcmUgZnV0dXJlIHJydHlwZSBoYXZlIHRvIGRlYWwgd2l0aCB0 aGUgZG5zc2VjIHByb2JsZW1zLg0KYWxpYXMgYWxnb3JpdGhtIGlkZW50aWZpZXIgaXMgbmVjZXNz YXJ5Lg0KdGhpcyBkb2N1bWVudCBkZXNpZ24gYSB1bml2ZXJpc2lhbCBtZXRob2QgZm9yIGFsbCBu ZXcgcnJ0eXBlcyBpbiBkbnNzZWMuDQoNCndlIHdpbGwgbm90IG5lZWQgdG8gbmFtZSBhIGluZGl2 aWR1YWwgYWxpYXMgYWxnb3JpdGhtIGlkZW50aWZpZXJzIHRvIGluZGl2aWR1YWwgcnJ0eXBlLg0K DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiA8SW50ZXJuZXQtRHJhZnRz QGlldGYub3JnPg0KVG86IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNkYXks IEF1Z3VzdCAxMSwgMjAxMCA5OjQ1IFBNDQpTdWJqZWN0OiBJLUQgQWN0aW9uOmRyYWZ0LXlhby1k bnNleHQtYWxpYXMtYWxnb3JpdGhtLTAwLnR4dCANCg0KDQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVz Lg0KPiANCj4gVGl0bGUgICAgICAgICAgIDogQWxpYXMgYWxnb3JpdGhtIGlkZW50aWZpZXIgYXNz aWdubWVudCBtZWNoYW5pc20gZm9yIEROU1NFQw0KPiBBdXRob3IocykgICAgICAgOiBKLiBZYW8s IGV0IGFsLg0KPiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC15YW8tZG5zZXh0LWFsaWFzLWFsZ29y aXRobS0wMC50eHQNCj4gUGFnZXMgICAgICAgICAgIDogNw0KPiBEYXRlICAgICAgICAgICAgOiAy MDEwLTA4LTExDQo+IA0KPiBETlMgU2VjdXJpdHkgRXh0ZW5zaW9ucyAoRE5TU0VDKSBoYXMgYmVl biBkZXZlbG9wZWQgdG8gcHJvdmlkZSBvcmlnaW4NCj4gYXV0aGVudGljYXRpb24gYW5kIGludGVn cml0eSBwcm90ZWN0aW9uIGZvciBETlMgZGF0YSBieSB1c2luZyBkaWdpdGFsDQo+IHNpZ25hdHVy ZXMuICBUaGUgRE5TS0VZLCBSUlNJRywgYW5kIERTIFJScyB1c2UgYW4gOC1iaXQgbnVtYmVyIHRv DQo+IGlkZW50aWZ5IHRoZSBzZWN1cml0eSBhbGdvcml0aG0gYmVpbmcgdXNlZC4gIE1vcmUgYW5k IG1vcmUgbmV3DQo+IFJSVFlQRXMgd2lsbCBhcHBlYXIgaW4gZnV0dXJlLiAgVGhpcyBkb2N1bWVu dCBkZWZpbmVzIGFuIGFsaWFzDQo+IGFsZ29yaXRobSBpZGVudGlmaWVyIGFzc2lnbm1lbnQgbWV0 aG9kIGZvciBETlNTRUMgOC1iaXQgYWxnb3JpdGhtDQo+IG51bWJlcnMuDQo+IA0KPiBBIFVSTCBm b3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQteWFvLWRuc2V4dC1hbGlhcy1hbGdvcml0aG0tMDAudHh0DQo+IA0KPiBJ bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiBCZWxvdyBpcyB0aGUg ZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyDQo+IGlt cGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24g b2YgdGhlDQo+IEludGVybmV0LURyYWZ0Lg0KPg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPiBJbnRl cm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0K PiBvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPg== ------=_NextPart_000_03B2_01CB39AC.6FE11050 Content-Type: text/plain; name="draft-yao-dnsext-alias-algorithm-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-yao-dnsext-alias-algorithm-00.txt" Content-Type: text/plain Content-ID: <2010-08-11063619.I-D@ietf.org> ------=_NextPart_000_03B2_01CB39AC.6FE11050-- From owner-namedroppers@ops.ietf.org Wed Aug 11 08: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 546113A69A2; Wed, 11 Aug 2010 08:36:19 -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: -98.089 X-Spam-Level: X-Spam-Status: No, score=-98.089 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 rm+EutTMfzsB; Wed, 11 Aug 2010 08:36:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 630A73A693D; Wed, 11 Aug 2010 08:36:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjDJn-000EKW-Ds for namedroppers-data0@psg.com; Wed, 11 Aug 2010 15:34:15 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjDJk-000EID-I7 for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 15:34:12 +0000 Received: (eyou send program); Wed, 11 Aug 2010 23:34:12 +0800 Message-ID: <481540852.30643@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, 11 Aug 2010 23:34:12 +0800 Message-ID: From: "Jiankang YAO" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Andrew Sullivan" Cc: References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <20100811135657.GA57645@shinkuro.com> <481537251.30643@cnnic.cn> Subject: Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") Date: Wed, 11 Aug 2010 23:34:34 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBhdHJpayBG5Gx0c3Ry9m0i IDxwYWZAY2lzY28uY29tPg0KVG86ICJBbmRyZXcgU3VsbGl2YW4iIDxhanNAc2hpbmt1cm8uY29t Pg0KQ2M6IDxuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnPg0KU2VudDogV2VkbmVzZGF5LCBBdWd1 c3QgMTEsIDIwMTAgMTA6MjIgUE0NClN1YmplY3Q6IFJlOiBBbiBhcmd1bWVudCB3aHkgYm5hbWUt c3R5bGUgZGVsZWdhdGlvbiBpcyBuZWVkZWQgKHdhczogW2Ruc2V4dF0gRE5TRVhUIGNoYXJ0ZXIg YW5kIHRyZWF0aW5nIEROUyBuYW1lcyBhcyAidGhlIHNhbWUiKQ0KDQo+DQo+DQoNCiAgT24gMTEg YXVnIDIwMTAsIGF0IDE1LjU2LCBBbmRyZXcgU3VsbGl2YW4gd3JvdGU6DQoNCiAgPiBVbmRlciBh IHByb3Zpc2lvbmluZy1vbmx5IHJlZ2ltZSwgdGhlIHJlcXVpcmVtZW50IHRoYXQgTjEuUCBhbmQg TjIuUA0KICA+IGJlICJ0aGUgc2FtZSBuYW1lIiBjYW5ub3QgYmUgZ3VhcmFudGVlZC4gIFRoYXQg aXMgYmVjYXVzZSB1bmRlcg0KICA+IHByb3Zpc2lvbmluZywgaXQgd291bGQgYmUgbmVjZXNzYXJ5 IHRvIGR1cGxpY2F0ZSBhbGwgdGhlIHpvbmVzIGFsbCB0aGUNCiAgPiB3YXkgZG93biB0aGUgdHJl ZSwgYW5kIHRoZXJlIGlzIG5vIGVhc3kgd2F5IGluIHRoZSBETlMgdG8gY2hlY2sgdGhhdA0KICA+ IHR3byB6b25lcyBhcmUgZXF1aXZhbGVudCB3aXRob3V0IHdhbGtpbmcgdGhlIHpvbmUuDQogID4g DQogID4gSXMgdGhhdCB0aGUgYXJndW1lbnQ/DQoNCiAgRm9yIG1lLCB5ZXMsIHdpdGggdGhlIGFk ZGl0aW9uIHRoYXQgaXQgaXMgbm90IHRvIG1lIHBlcmZlY3RseSBjbGVhciBpZiB0aGUgcmlzayBp cyB6ZXJvIHRoYXQgY29tcGV0aXRpb24gcnVsZXMgaW4gdmFyaW91cyBsZWdpc2xhdGlvbnMgbWln aHQgZm9yY2UgdGhlIHR3byB6b25lcyBOMS5QIGFuZCBOMi5QIGJlIGRlbGVnYXRlZCB0byBlbnRp dGllcyBhY2NvcmRpbmcgdG8gc29tZSBSRlAgcHJvY2VzcyB0aGF0IE1JR0hUIHJlc3VsdCBpbiB0 aGUgdHdvIGRvbWFpbnMgYmUgcnVuIGJ5IHR3byBkaWZmZXJlbnQgcmVnaXN0cmllcy4NCg0KICBT cGVjaWZpY2FsbHkgaWYgTjEuUCBleGlzdHMsIGFuZCBOMi5QIGlzIHRvIGJlIGFsbG9jYXRlZC4g QSBjb21wZXRpdG9yIHRvIHRoZSByZWdpc3RyeSBmb3IgTjEuUCBtaWdodCB2ZXJ5IHdlbGwgYXNr IHRvIGJlY29tZSB0aGUgcmVnaXN0cnkgZm9yIE4yLlAsIGlmIE4yLlAgd2FzIGluIHJlYWxpdHkg ZGVsZWdhdGVkLg0KDQogIElmIGluc3RlYWQgTjEuUCBpcyBkZWxlZ2F0ZWQsIGFuZCBOMi5QIHdh cyBzb21lIHBvaW50ZXIgdG8gTjEuUCwgdGhlbiB0aGF0IGNvbXBldGl0aW9uIGFyZ3VtZW50IHdv dWxkIG5vdCBleGlzdC4NCg0KICAgICBQYXRyaWsNCg0KPg0KPg0KDQorMQ== From owner-namedroppers@ops.ietf.org Wed Aug 11 08:36: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 24DD93A67E7; Wed, 11 Aug 2010 08:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.481 X-Spam-Level: X-Spam-Status: No, score=0.481 tagged_above=-999 required=5 tests=[AWL=0.975, 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 MsdkfFSlfKgi; Wed, 11 Aug 2010 08:36:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B5AB53A6999; Wed, 11 Aug 2010 08:36:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjDJ3-000EDR-7e for namedroppers-data0@psg.com; Wed, 11 Aug 2010 15:33:29 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjDIy-000ECn-NW for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 15:33:25 +0000 Received: by fxm10 with SMTP id 10so249256fxm.11 for ; Wed, 11 Aug 2010 08:33:22 -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; bh=ivHQhwBLH15EmoyhXBwTWBmv0izpz8xgRrRjEV5lnQY=; b=sI5Xz3QZ6oOoe806oLvkWgVEbp6QlIERUgopThwFMOX5i9n/cl7kXgBsgb/MT2X9j7 8Gqm497gs0Gi4mU5dVTQRYMTuB83MBERMQB8eU/zCN3PdMOwMYC5FCGV7EeBqAkaQYqd o7InIiSoc7xpGqfeP3wFxx1sFeIS1DN5u8qYU= 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=VNYR0UhS57nRIgN8BMevy/GK+ygo6uvT5hb6xgNx2wSujdYz7ZiTpQJdpPf5+gSlor DGLwrE2H8/E/g0Lm7BD1pJAS2/Q/gLjlogbLY2bd0roTbH9bkC5r6WOAyQccxqyPwKAj JpGY5EcqljPQo43bpdYkorEyY+vOESADFfGi8= MIME-Version: 1.0 Received: by 10.103.39.1 with SMTP id r1mr1474837muj.131.1281540801941; Wed, 11 Aug 2010 08:33:21 -0700 (PDT) Received: by 10.223.50.154 with HTTP; Wed, 11 Aug 2010 08:33:21 -0700 (PDT) In-Reply-To: <20100811135657.GA57645@shinkuro.com> References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <20100811135657.GA57645@shinkuro.com> Date: Wed, 11 Aug 2010 12:33:21 -0300 Message-ID: Subject: Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") From: Brian Dickson To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=0016364c74d543d358048d8df899 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016364c74d543d358048d8df899 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 11, 2010 at 10:56 AM, Andrew Sullivan wrote: > Colleagues, > > I'm writing this as co-chair, as an attempt to make the arguments on > both sides as clear as possible. I know some of you have expressed > weariness at this topic, and would like less traffic on it. I too > would like that, so I'm hopeful that we can come to speedy conclusions > about this topic and meet our aimed-for charter deadline in September. > > On Wed, Aug 11, 2010 at 01:40:34PM +0800, Jiankang YAO wrote: > > provision is the policy based, not the technology based. > > > > it is not a long term solution; it is a short solution. > > > > long term solution needs the technology solution such as bname. > > This claim keeps getting repeated, but without any supporting > argument. Without a supporting argument, I don't believe it. > > Here is the only argument I can think of. Please tell me whether it > is the one (and only one) you would use. For those who think that we > should not add more things to the DNS in order to solve some small > percentage of cases, please tell me whether you think the case in > question is big enough to meet the threshold where we might want to > add something to the protocol, or whether you can think of ways other > than BNAME (or something like it) to accomplish the same thing. > > Here's the supporting argument: Suppose we have two domain names, N1 > and N2. These are to be delegated by parent P, such that there would > be two zones N1.P and N2.P. Now, P's policy is that the zones N1 and > N2 are to be maintained such that a user arriving at any name X.N1.P > and a similar user arriving at any name X.N2.P will have an experience > as though they were "the same name". (So, for instance, in a web > environment these would be "the same" web site; mail destined to > user@X.N1.P and to user@X.N2.P always reaches the same mailbox "user", > and so on. This might need formal tightening, but for now this > ostensive definition will do.) > > Under a provisioning-only regime, the requirement that N1.P and N2.P > be "the same name" cannot be guaranteed. That is because under > provisioning, it would be necessary to duplicate all the zones all the > way down the tree, and there is no easy way in the DNS to check that > two zones are equivalent without walking the zone. > > Is that the argument? > > I think that is the argument. And now I'll use another argument for *non*-Xname changes to DNS, as an augmentation of what exists now, to facilitate both provisioning-only mechanisms, and to facilitate better-scaling DNSSEC signing. What is missing, is a *server*-side (below-the-zone-cut) apex record, which asserts all the names by which the zone is known. This avoids client-side processing (chasing Xnames around), makes the assertions authoritative, and permits cross-signing of the zone owner names (note the plural!). (It does not, of course, prevent operator error, e.g. duplicated, non-linked zones which diverge content-wise, but which both assert multiple names. That kind of error can occur today for a single zone, so this is not a new problem at all.) Above the zone cuts, all that is needed is delegations. The bundling, as it were, is handled on the server _to which_ the delegations occur. And, the bundling is further asserted via the new record type (whatever it is called - zone alias, AKA, hello_my_name_is, etc.). P would delegate N1 to servers N1_NS_i (for i in 1..N), and N2 to servers N2_NS_i. (Those two sets could be identical, overlapping, or completely independent, for policy reasons.) However, the operator of P would expect that for a given SOA SN, N1.P and N2.P would have identical content, and specifically that the new RR type (e.g. AKA) at the apex of both zones (N1.P and N2.P) would contain both N1.P and N2.P. (NB - This validation would be trivial to automate, for enforcement purposes, once such AKA records are supported by implementations.) Example: say the new RRtype is AKA. We would expect to see, when looking at the respective zones: N1.P. SOA (stuff); NS whatever; AKA N1.P; AKA N2.P; and N2.P. SOA (stuff); NS whatever; AKA N1.P; AKA N2.P; RRSIG records for the normal zone rdata records, could be signed by N1.P, N2.P, or both. The AKA RRset would need to be signed by all members of the AKA RRset (i.e. one RRSIG whose signer is the RDATA, for all members of the AKA RRset). Provisioning systems (on the child side) for specific implementations might in fact use (new feature alert) hard-linking of zone data to multiple names, thus guaranteeing synchronous zones and reducing space and signing requirements. And note that this would support zones with many names, such as N1.P, N2.P, N1.Q, N2.Q, N1.X.Y, N1.A.B.C, and even N1 (i.e. its own TLD). P (by policy) might insist on N1.P and N2.P, but that would *not* preclude additional AKA records. Having only portions of a tree have many more names, could be handled (trivially) by delegating those portions, even to/on the same server(s). E.g. smtp (under the identical N1.P and N2.P AKA zone) delegated to some NS set, and on those servers, zone smtp.N1.P having apex AKA records smtp.N1.P, smtp.N2.P, smtp.BIG-CO.example.com, smtp.N3.Q, smtp.N4.R, and smtp.BIG-CO.co.CCtld. Querying by any name "just" returns the right data, which is identical independent of name. It works for all existing resolvers, modulo DNSSEC validators having to have new logic to support AKA signing. The AKA signing is basically just a way of validating independent paths for SEP (secure entry points) to the same zone data, and ensuring that the use of "sister" signatures is in fact authorized and valid. At worst, the lack of AKA support will result in some variants of zones being seen as insecure, and that can be resolved (pun not intended) by adding appropriate RRSIG data until AKA support is sufficiently widespread. This differs from the xNAME proposals in that the parent side is never doing anything other than NS (and possibly DS), which supports pretty much any model for delegation, including parallel registries operated by different parties for IDN TLD variants. It also means that provisioning can begin now, without changes required later, since the extra "goodness" is added below the zone cut. The most important features are: No special server-side processing No flag bits No signaling required No client-side query re-writing (xNAME) Fully backwards compatible for non-DNSSEC Mostly backwards compatible for DNSSEC validation Deployment of AKA-supporting code encourages both DNSSEC and IDN deployment Does not represent a significant barrier to DNSSEC deployment (no flag day) Provisioning-only for IDN delegations One-time-only new RRtype at a zone apex Good scaling on RRSIGs for IDNs Brian --0016364c74d543d358048d8df899 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Aug 11, 2010 at 10:56 AM, Andrew= Sullivan <ajs@shi= nkuro.com> wrote:
Colleagues,

I'm writing this as co-chair, as an attempt to make the arguments on both sides as clear as possible. =A0I know some of you have expressed
weariness at this topic, and would like less traffic on it. =A0I too
would like that, so I'm hopeful that we can come to speedy conclusions<= br> about this topic and meet our aimed-for charter deadline in September.

On Wed, Aug 11, 2010 at 01:40:34PM +0800, Jiankang YAO wrote:
> provision is the policy based, not the technology based.
>
> it is not a long term solution; it is a short solution.
>
> long term solution needs the technology solution =A0such as bname.

This claim keeps getting repeated, but without any supporting
argument. =A0Without a supporting argument, I don't believe it.

Here is the only argument I can think of. =A0Please tell me whether it
is the one (and only one) you would use. =A0For those who think that we
should not add more things to the DNS in order to solve some small
percentage of cases, please tell me whether you think the case in
question is big enough to meet the threshold where we might want to
add something to the protocol, or whether you can think of ways other
than BNAME (or something like it) to accomplish the same thing.

Here's the supporting argument: Suppose we have two domain names, N1 and N2. =A0These are to be delegated by parent P, such that there would
be two zones N1.P and N2.P. =A0Now, P's policy is that the zones N1 and=
N2 are to be maintained such that a user arriving at any name X.N1.P
and a similar user arriving at any name X.N2.P will have an experience
as though they were "the same name". =A0(So, for instance, in a w= eb
environment these would be "the same" web site; mail destined to<= br> user@X.N1.P and to user@X.N2.P always reaches the same mailbox "user&q= uot;,
and so on. =A0This might need formal tightening, but for now this
ostensive definition will do.)

Under a provisioning-only regime, the requirement that N1.P and N2.P
be "the same name" cannot be guaranteed. =A0That is because under=
provisioning, it would be necessary to duplicate all the zones all the
way down the tree, and there is no easy way in the DNS to check that
two zones are equivalent without walking the zone.

Is that the argument?



I think that is the argument.

And now = I'll use another argument for *non*-Xname changes to DNS,
as an augm= entation of what exists now, to facilitate both provisioning-only mechanism= s,
and to facilitate better-scaling DNSSEC signing.

What is missing, is= a *server*-side (below-the-zone-cut) apex record, which asserts all the na= mes by which the zone is known.

This avoids client-side processing (= chasing Xnames around), makes the assertions authoritative, and permits cro= ss-signing of the zone owner names (note the plural!).

(It does not, of course, prevent operator error, e.g. duplicated, non-l= inked zones which diverge content-wise, but which both assert multiple name= s. That kind of error can occur today for a single zone, so this is not a n= ew problem at all.)

Above the zone cuts, all that is needed is delegations. The bundling, a= s it were, is handled on the server _to which_ the delegations occur. And, = the bundling is further asserted via the new record type (whatever it is ca= lled - zone alias, AKA, hello_my_name_is, etc.).

P would delegate N1 to servers N1_NS_i (for i in 1..N), and N2 to serve= rs N2_NS_i. (Those two sets could be identical, overlapping, or completely = independent, for policy reasons.)
However, the operator of P would expec= t that for a given SOA SN, N1.P and N2.P would have identical content, and = specifically that the new RR type (e.g. AKA) at the apex of both zones (N1.= P and N2.P) would contain both N1.P and N2.P.
(NB - This validation would be trivial to automate, for enforcement purpose= s, once such AKA records are supported by implementations.)

Example:= say the new RRtype is AKA. We would expect to see, when looking at the res= pective zones:

N1.P.=A0=A0 SOA=A0 (stuff);
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 NS whatev= er;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 AKA N1.P;
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 AKA N2.P;

and

N2.P.=A0=A0 SOA=A0 (stuff);
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 NS whatever;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 AKA N1.P;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 AKA N2.P;

RRSIG records for the norma= l zone rdata records, could be signed by N1.P, N2.P, or both.
The AKA RR= set would need to be signed by all members of the AKA RRset (i.e. one RRSIG= whose signer is the RDATA, for all members of the AKA RRset).

Provisioning systems (on the child side) for specific implementations m= ight in fact use (new feature alert) hard-linking of zone data to multiple = names, thus guaranteeing synchronous zones and reducing space and signing r= equirements.

And note that this would support zones with many names, such as N1.P, N= 2.P, N1.Q, N2.Q, N1.X.Y, N1.A.B.C, and even N1 (i.e. its own TLD). P (by po= licy) might insist on N1.P and N2.P, but that would *not* preclude addition= al AKA records.

Having only portions of a tree have many more names, could be handled (= trivially) by delegating those portions, even to/on the same server(s).
= E.g. smtp (under the identical N1.P and N2.P AKA zone) delegated to some NS= set, and on those servers, zone smtp.N1.P having apex AKA records smtp.N1.= P, smtp.N2.P, smtp.BIG-CO.exampl= e.com, smtp.N3.Q, smtp.N4.R, and smtp.BIG-CO.co.CCtld.

Querying by any name "just" returns the right data, which is = identical independent of name. It works for all existing resolvers, modulo = DNSSEC validators having to have new logic to support AKA signing.
The A= KA signing is basically just a way of validating independent paths for SEP = (secure entry points) to the same zone data, and ensuring that the use of &= quot;sister" signatures is in fact authorized and valid.
At worst, the lack of AKA support will result in some variants of zones bei= ng seen as insecure, and that can be resolved (pun not intended) by adding = appropriate RRSIG data until AKA support is sufficiently widespread.

This differs from the xNAME proposals in that the parent side is never = doing anything other than NS (and possibly DS), which supports pretty much = any model for delegation, including parallel registries operated by differe= nt parties for IDN TLD variants. It also means that provisioning can begin = now, without changes required later, since the extra "goodness" i= s added below the zone cut.

The most important features are:
No special server-side processingNo flag bits
No signaling required
No client-side query re-writing = (xNAME)
Fully backwards compatible for non-DNSSEC
Mostly backwards co= mpatible for DNSSEC validation
Deployment of AKA-supporting code encourages both DNSSEC and IDN deployment=
Does not represent a significant barrier to DNSSEC deployment (no flag = day)
Provisioning-only for IDN delegations
One-time-only new RRtype a= t a zone apex
Good scaling on RRSIGs for IDNs

Brian
--0016364c74d543d358048d8df899-- From owner-namedroppers@ops.ietf.org Wed Aug 11 08:48: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 6398228C0EC; Wed, 11 Aug 2010 08:48:01 -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 e8Mvu3tJvCK3; Wed, 11 Aug 2010 08:48:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B1CD3A67EE; Wed, 11 Aug 2010 08:48:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjDU4-000GF2-Cn for namedroppers-data0@psg.com; Wed, 11 Aug 2010 15:44:52 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjDU1-000GEa-A5 for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 15:44:49 +0000 Received: from [192.168.1.68] (cpc2-livi1-0-0-cust276.sgyl.cable.virginmedia.com [82.41.185.21]) by mail.avalus.com (Postfix) with ESMTPSA id 4D117C5692E; Wed, 11 Aug 2010 16:44:48 +0100 (BST) Date: Wed, 11 Aug 2010 16:44:47 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Andrew Sullivan , namedroppers@ops.ietf.org cc: Alex Bligh Subject: [dnsext] Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") Message-ID: <88B2242191A75578846B5E0B@nimrod.local> In-Reply-To: <20100811135657.GA57645@shinkuro.com> References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <20100811135657.GA57645@shinkuro.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 11 August 2010 09:56:58 -0400 Andrew Sullivan wrote: > On Wed, Aug 11, 2010 at 01:40:34PM +0800, Jiankang YAO wrote: >> provision is the policy based, not the technology based. >> >> it is not a long term solution; it is a short solution. >> >> long term solution needs the technology solution such as bname. > > This claim keeps getting repeated, but without any supporting > argument. Without a supporting argument, I don't believe it. I'm not putting this to support the need for a protocol change, but I had thought the argument was this: Let us suppose that A1 needs to be equivalent to A2, B1 to B2 etc. Provisioning type solutions work if one wishes to ensure x.A1 is equivalent to x.A2 for any X. However, the servers to which they are delegated then need to run zones for x.A1 and x.A2. That's not so bad (two zones). Now suppose the problem is mapping x.Ai.Bj.Ck.Dl to x.A1.B1.C1.D1 for any i, j, k, l. You have an O(a^n) problem in terms of the number of zones that have to be supported at the left hand end. That's why you 'have' to make whole sections of tree map to whole other sections of tree. So the provisioning problem is /smallest/ at the TLD level, but largest at the end user level (or whoever provides DNS for the end user). I am guessing there is also an issue that if the number of equivalences in one label is large, (say at the C label in the above), then the end DNS config needs to know all equivalences of C, which is error prone and might change over time. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Aug 11 08:58: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 B24B83A694E; Wed, 11 Aug 2010 08:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.843 X-Spam-Level: X-Spam-Status: No, score=-99.843 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 NZn6T2JYpq32; Wed, 11 Aug 2010 08:58:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D265E3A693D; Wed, 11 Aug 2010 08:58:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjDep-000I71-9X for namedroppers-data0@psg.com; Wed, 11 Aug 2010 15:55:59 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjDen-000I6S-1N for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 15:55:57 +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 9FCD91ECB41D for ; Wed, 11 Aug 2010 15:55:55 +0000 (UTC) Date: Wed, 11 Aug 2010 11:55:53 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") Message-ID: <20100811155552.GM57645@shinkuro.com> References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <20100811135657.GA57645@shinkuro.com> <88B2242191A75578846B5E0B@nimrod.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <88B2242191A75578846B5E0B@nimrod.local> 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, Aug 11, 2010 at 04:44:47PM +0100, Alex Bligh wrote: > Now suppose the problem is mapping > x.Ai.Bj.Ck.Dl > to > x.A1.B1.C1.D1 > for any i, j, k, l. You have an O(a^n) problem in terms of the number of > zones that have to be supported at the left hand end. That's why you > 'have' to make whole sections of tree map to whole other sections of > tree. There have been arguments in favour of that position, yes. I haven't seen an argument why BNAME would solve it, however. BNAME occludes things beneath it just as DNAME does. So if (say) we had Dl BNAME D1, we'd still need to do all the provisioning of Ck/C1, Bj/B1, and so on. No? > I am guessing there is also an issue that if the number of equivalences > in one label is large, (say at the C label in the above), then the > end DNS config needs to know all equivalences of C, which is error > prone and might change over time. Also true, but it also still needs someone to provision the BNAMEs as opposed to (say) the DNAMEs + apex records if needed. I think, anyway. If someone has an argument why I'm wrong (and I'm fully prepared to be. I am, for better or worse, unafraid of being made a fool of in public), please educate me. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Aug 11 09:40: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 E9C903A6A03; Wed, 11 Aug 2010 09:40:33 -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 NgMd1AFWHI6C; Wed, 11 Aug 2010 09:40:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F253D3A69B9; Wed, 11 Aug 2010 09:40:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjEGw-000OKx-2H for namedroppers-data0@psg.com; Wed, 11 Aug 2010 16:35:22 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjEGt-000OKS-G7 for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 16:35:19 +0000 Received: from [192.168.1.68] (cpc2-livi1-0-0-cust276.sgyl.cable.virginmedia.com [82.41.185.21]) by mail.avalus.com (Postfix) with ESMTPSA id 6A2BBC5692E; Wed, 11 Aug 2010 17:35:16 +0100 (BST) Date: Wed, 11 Aug 2010 17:35:16 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Andrew Sullivan , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") Message-ID: <8741ED5CB121AE652BED9997@nimrod.local> In-Reply-To: <20100811155552.GM57645@shinkuro.com> References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <20100811135657.GA57645@shinkuro.com> <88B2242191A75578846B5E0B@nimrod.local> <20100811155552.GM57645@shinkuro.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 11 August 2010 11:55:53 -0400 Andrew Sullivan wrote: >> Now suppose the problem is mapping >> x.Ai.Bj.Ck.Dl >> to >> x.A1.B1.C1.D1 >> for any i, j, k, l. You have an O(a^n) problem in terms of the number of >> zones that have to be supported at the left hand end. That's why you >> 'have' to make whole sections of tree map to whole other sections of >> tree. > > There have been arguments in favour of that position, yes. I haven't > seen an argument why BNAME would solve it, however. > > BNAME occludes things beneath it just as DNAME does. So if (say) we > had Dl BNAME D1, we'd still need to do all the provisioning of Ck/C1, > Bj/B1, and so on. No? I think a desirable xNAME quality would reduce this to a O(n) problem, so you could just do D2. IN xNAME D1. D3. IN xNAME D1. D4. IN xNAME D1. ... C2.D1. IN xNAME C1.D1. C3.D1. IN xNAME C1.D1. C4.D1. IN xNAME C1.D1. ... B2.C1.D1. IN xNAME B1.C1.D1. B3.C1.D1. IN xNAME B1.C1.D1. B4.C1.D1. IN xNAME B1.C1.D1. ... A2.B1.C1.D1. IN xNAME A1.B1.C1.D1. A3.B1.C1.D1. IN xNAME A1.B1.C1.D1. A4.B1.C1.D1. IN xNAME A1.B1.C1.D1. ... x.A1.B1.C1.D1. IN (whatever) IE you never need to consider records for (e.g. Bj.Ck.Dl. for j!=1 or k!=1). I can't see how a provisioning based system has that quality. Doesn't that mean at the Ai level, you'd need 4*4^3 entries. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Aug 11 09:42: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 6F5563A6914; Wed, 11 Aug 2010 09:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.837 X-Spam-Level: X-Spam-Status: No, score=-99.837 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 C3br2jYR+eLF; Wed, 11 Aug 2010 09:42:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8EB023A67F3; Wed, 11 Aug 2010 09:42:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjELH-000P6L-7m for namedroppers-data0@psg.com; Wed, 11 Aug 2010 16:39:51 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjELF-000P5P-0A for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 16:39:49 +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 D01D81ECB41D for ; Wed, 11 Aug 2010 16:39:46 +0000 (UTC) Date: Wed, 11 Aug 2010 12:39:45 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") Message-ID: <20100811163944.GP57645@shinkuro.com> References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <20100811135657.GA57645@shinkuro.com> <88B2242191A75578846B5E0B@nimrod.local> <20100811155552.GM57645@shinkuro.com> <8741ED5CB121AE652BED9997@nimrod.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8741ED5CB121AE652BED9997@nimrod.local> 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, Aug 11, 2010 at 05:35:16PM +0100, Alex Bligh wrote: >> BNAME occludes things beneath it just as DNAME does. So if (say) we >> had Dl BNAME D1, we'd still need to do all the provisioning of Ck/C1, >> Bj/B1, and so on. No? > > I think a desirable xNAME quality would reduce this to a O(n) problem, > so you could just do > > D2. IN xNAME D1. > D3. IN xNAME D1. > D4. IN xNAME D1. > > ... > > C2.D1. IN xNAME C1.D1. > C3.D1. IN xNAME C1.D1. > C4.D1. IN xNAME C1.D1. Excellent! We have another concisely-worded requirement. Suzanne, can you add this to the list? Thanks A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Aug 11 10:28: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 679DE28C0F6; Wed, 11 Aug 2010 10:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.673 X-Spam-Level: X-Spam-Status: No, score=-108.673 tagged_above=-999 required=5 tests=[AWL=0.422, 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, 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 htFR3rYClpXU; Wed, 11 Aug 2010 10:28:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B76928C0EC; Wed, 11 Aug 2010 10:28:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjF1f-0006VJ-Nz for namedroppers-data0@psg.com; Wed, 11 Aug 2010 17:23:39 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjF1b-0006UA-VJ for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 17:23:37 +0000 Received: (qmail 93021 invoked from network); 11 Aug 2010 17:23:31 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 11 Aug 2010 17:23:31 -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=k1008; olt=johnl@user.iecc.com; bh=GoK8GNsf2NLeZFbZKrtY3oPJHB2X/fjPnAMzKVNThnU=; b=ZVbxM849+3BmDac90xVdsNhc+0ROTYo39k04XmXu+djHVzbHLK7U7pXrcZpGYQLwMRG9l2tNTZ0IGyMFQpz1gtl7t6v59Ap0yQJSNt0xIKd54HPNQ1v2qNii+dZVrnEOCXhOIa8aDMvW+G1fyvOfjHMWMdk1CCaIlUnHA+c+hVY= Date: 11 Aug 2010 17:23:31 -0000 Message-ID: <20100811172331.37497.qmail@joyce.lan> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: how would an xNAME work? In-Reply-To: <8741ED5CB121AE652BED9997@nimrod.local> Organization: Cc: alex@alex.org.uk 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: >D2. IN xNAME D1. >D3. IN xNAME D1. >D4. IN xNAME D1. >... > >C2.D1. IN xNAME C1.D1. >C3.D1. IN xNAME C1.D1. >C4.D1. IN xNAME C1.D1. >... > >B2.C1.D1. IN xNAME B1.C1.D1. >B3.C1.D1. IN xNAME B1.C1.D1. >B4.C1.D1. IN xNAME B1.C1.D1. >... > >A2.B1.C1.D1. IN xNAME A1.B1.C1.D1. >A3.B1.C1.D1. IN xNAME A1.B1.C1.D1. >A4.B1.C1.D1. IN xNAME A1.B1.C1.D1. I must be missing something. Let's assume that C1.D1 is delegated to someone other than the operator of D1. Who publishes the third and fourth groups of xNAME records? If it's the operator of D1, how does he find out what xNAMEs he needs to publish? If it's the operator of C1.D1, how does the TLD ensure that the delegated operators are publishing all of the xNAME records they're supposed to? And of course, if they're serious about equivalence, who verifies that all of the mail, web, etc. applications are properly aliasing all of the An.Bn.Cn.Dn names? Here's the one-senence version of why I think provisioning is the way to go (with a hat tip to Phill): To make two domains usefully equivalent, the amount of application provisioning necessary down at the leaves will be so large that any savings from an xNAME hack up in the DNS tree are lost in the noise. R's, John From owner-namedroppers@ops.ietf.org Wed Aug 11 10:37: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 9E1773A6A7B; Wed, 11 Aug 2010 10:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 EuRpaHM98gcG; Wed, 11 Aug 2010 10:37:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 628E23A6A90; Wed, 11 Aug 2010 10:37:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjFCp-0008K5-8g for namedroppers-data0@psg.com; Wed, 11 Aug 2010 17:35:11 +0000 Received: from [131.111.8.130] (helo=ppsw-30.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjFCn-0008IQ-23 for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 17:35:09 +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]:52566) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1OjFCc-00084I-fH (Exim 4.72) (return-path ); Wed, 11 Aug 2010 18:34:58 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OjFCc-0000sa-PD (Exim 4.67) (return-path ); Wed, 11 Aug 2010 18:34:58 +0100 Date: Wed, 11 Aug 2010 18:34:58 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker cc: =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= , Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") In-Reply-To: Message-ID: References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <20100811135657.GA57645@shinkuro.com> <51AF9E88-C237-4435-990D-31FF06B1880E@cisco.com> 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 Wed, 11 Aug 2010, Phillip Hallam-Baker wrote: > > My point is that while provisioning is complex, introducing the > pointer does not eliminate the complexity. All that is achieved is > that the complexity is moved from the DNS provisioning process to the > application configuration process. That isn't quite correct: the application configuration requirements are the same in both cases. BNAME moves complexity from domain provisioning to client resolvers. > One way in which we might perhaps square this circle is if we instead > introduced a 'Did You Mean' Resource Record that is merely a variation > of 'NXDOMAIN'. This moves complexity from the provisioning process to the client application, and requires application code changes not just configuration. (It reminds me of the old SMTP canonicalization requirement, i.e. CNAME-based mail domain rewrites.) To me this all looks like various efforts to offload costs from the people who want multiple parallel domains to their users. Tony. -- f.anthony.n.finch http://dotat.at/ SOUTHEAST FAIR ISLE: VARIABLE, BECOMING NORTHEASTERLY, 3 OR 4. SLIGHT OR MODERATE. RAIN OR SHOWERS. MODERATE OR GOOD. From owner-namedroppers@ops.ietf.org Wed Aug 11 10: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 D28DA3A6957; Wed, 11 Aug 2010 10:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.767 X-Spam-Level: X-Spam-Status: No, score=-0.767 tagged_above=-999 required=5 tests=[AWL=-0.272, 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 EvyO+wUo8cBR; Wed, 11 Aug 2010 10:51:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5CA843A684B; Wed, 11 Aug 2010 10:51:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjFQ3-000ATk-Il for namedroppers-data0@psg.com; Wed, 11 Aug 2010 17:48:51 +0000 Received: from [209.85.161.180] (helo=mail-gx0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjFQ1-000ATD-2i for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 17:48:49 +0000 Received: by gxk22 with SMTP id 22so192213gxk.11 for ; Wed, 11 Aug 2010 10:48:48 -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=3dcV5lcWaQKQtyeqiS50xGbliOH/WmAVrzRQf4g3i7Q=; b=hf0WkV9pwvxRVTeJc4EcLDNDXFFv4rihHm454b2Y/LeX/MpXHNinKNTrCjuWp0naz2 qKoVX91FOecc01Jj1JxI2dkEgUxtVZww2yjz7AYP0QsqDZjB0KWNompsPVrxUiy+Bw3H sq7X72qMIf8De4DBxB0kEnBkswRJh8SzRevu0= 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=O8wg140HMWJiUF8eqV+ND4g70dyD2n5RIuxEYmlehS5AoxLEY57+GJl7cspo6d9aZp s+i1iUvJEaWD3O/WlddTS1AF9sX6X8iXxo8/YujbilJzmUZqh5BVKTcWpMhYq+t06T0T yPigTdMy4YT+GiFDKmfKQpA96HA6yslgKHfb4= MIME-Version: 1.0 Received: by 10.100.106.6 with SMTP id e6mr22152322anc.111.1281548927918; Wed, 11 Aug 2010 10:48:47 -0700 (PDT) Received: by 10.101.188.15 with HTTP; Wed, 11 Aug 2010 10:48:47 -0700 (PDT) In-Reply-To: References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <20100811135657.GA57645@shinkuro.com> <51AF9E88-C237-4435-990D-31FF06B1880E@cisco.com> Date: Wed, 11 Aug 2010 13:48:47 -0400 Message-ID: Subject: Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") From: Phillip Hallam-Baker To: Tony Finch Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Andrew Sullivan , 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: Yes, we cannot eliminate the complexity, we can only move it around. Looking at the impact that this proposal has on SSL, there is no way that we can make this work without the application layer being aware that it is taking place. If *.china is created as an alias for *.cn, then as a CA, I am going to have to know to tell all my customers that they need to replace their existing SSL certificates with new ones with an additional alias for the *.china version of their name. This is not an issue that can be addressed in the DNS alone. I think that the proper place to compartmentalize this complexity is in the multibox where user input is dealt with. On Wed, Aug 11, 2010 at 1:34 PM, Tony Finch wrote: > On Wed, 11 Aug 2010, Phillip Hallam-Baker wrote: >> >> My point is that while provisioning is complex, introducing the >> pointer does not eliminate the complexity. All that is achieved is >> that the complexity is moved from the DNS provisioning process to the >> application configuration process. > > That isn't quite correct: the application configuration requirements are > the same in both cases. BNAME moves complexity from domain provisioning > to client resolvers. > >> One way in which we might perhaps square this circle is if we instead >> introduced a 'Did You Mean' Resource Record that is merely a variation >> of 'NXDOMAIN'. > > This moves complexity from the provisioning process to the client > application, and requires application code changes not just configuration= . > (It reminds me of the old SMTP canonicalization requirement, i.e. > CNAME-based mail domain rewrites.) > > To me this all looks like various efforts to offload costs from the peopl= e > who want multiple parallel domains to their users. > > Tony. > -- > f.anthony.n.finch =A0 =A0http://dotat.at/ > SOUTHEAST FAIR ISLE: VARIABLE, BECOMING NORTHEASTERLY, 3 OR 4. SLIGHT OR > MODERATE. RAIN OR SHOWERS. MODERATE OR GOOD. > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Wed Aug 11 10:57: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 160803A67EC; Wed, 11 Aug 2010 10:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.116 X-Spam-Level: X-Spam-Status: No, score=-3.116 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, J_CHICKENPOX_65=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 BiJ7JA5-rUf4; Wed, 11 Aug 2010 10:57:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D86F43A6919; Wed, 11 Aug 2010 10:57:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjFWC-000Beh-Oc for namedroppers-data0@psg.com; Wed, 11 Aug 2010 17:55:12 +0000 Received: from [131.111.8.130] (helo=ppsw-30.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjFWA-000Bc4-DC for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 17:55:10 +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]:35475) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1OjFW5-0005vh-dj (Exim 4.72) (return-path ); Wed, 11 Aug 2010 18:55:05 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OjFW3-0003H8-OF (Exim 4.67) (return-path ); Wed, 11 Aug 2010 18:55:03 +0100 Date: Wed, 11 Aug 2010 18:55:03 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker cc: "John R. Levine" , Jiankang YAO , namedroppers@ops.ietf.org, ajs@shinkuro.com Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" In-Reply-To: Message-ID: References: <481501584.15255@cnnic.cn> 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 Wed, 11 Aug 2010, Phillip Hallam-Baker wrote: > > If you try to do transparent fixup in the DNS so that the client asks > for google.china and gets back the A records for google.cn from the > resolver, we now have a facility that can be used to establish > transparent redirects without browsers ever being aware that they were > redirected. CNAME and DNAME already do that. Tony. -- f.anthony.n.finch http://dotat.at/ SHANNON ROCKALL: NORTHWEST 4 OR 5. MODERATE. SHOWERS. GOOD. From owner-namedroppers@ops.ietf.org Wed Aug 11 11:23: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 16A9E3A69B1; Wed, 11 Aug 2010 11:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=0.302, 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 ljetyjUnlwU4; Wed, 11 Aug 2010 11:23:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EAFBF3A67EF; Wed, 11 Aug 2010 11:23:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjFu0-000FzI-Nx for namedroppers-data0@psg.com; Wed, 11 Aug 2010 18:19:48 +0000 Received: from [2001:500:60::65] (helo=mx.ams1.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjFts-000FwM-Vo for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 18:19:41 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id CAE745F9861 for ; Wed, 11 Aug 2010 18:19:11 +0000 (UTC) (envelope-from woolf@isc.org) Received: by farside.isc.org (Postfix, from userid 10265) id 0233BE60DE; Wed, 11 Aug 2010 18:19:09 +0000 (UTC) Date: Wed, 11 Aug 2010 18:19:09 +0000 From: Suzanne Woolf To: namedroppers@ops.ietf.org Subject: new use case? was Re: [dnsext] Re: An argument why bname-style delegation is needed Message-ID: <20100811181909.GA49913@farside.isc.org> References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <20100811135657.GA57645@shinkuro.com> <88B2242191A75578846B5E0B@nimrod.local> <20100811155552.GM57645@shinkuro.com> <8741ED5CB121AE652BED9997@nimrod.local> <20100811163944.GP57645@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100811163944.GP57645@shinkuro.com> 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: Andrew, Alex, et. al., Sure, happy to add this to the problem statement doc, with the following questions: 1. Does any solution currently proposed handle this case? At a glance I don't think so. 2. Does anyone reading this want to speak up and say Alex's formulation corresponds to a use case they've seen and they would use this capability if they had it? I'm well aware that's a weaker constraint than Andrew has been trying to encourage (as I read it, he's been trying to get us to "you couldn't do what you need to do without it" rather than "you'd use it if you had it"), but I'm willing to lower the bar for purposes of discussion. thx, Suzanne On Wed, Aug 11, 2010 at 12:39:45PM -0400, Andrew Sullivan wrote: > On Wed, Aug 11, 2010 at 05:35:16PM +0100, Alex Bligh wrote: > >> BNAME occludes things beneath it just as DNAME does. So if (say) we > >> had Dl BNAME D1, we'd still need to do all the provisioning of Ck/C1, > >> Bj/B1, and so on. No? > > > > I think a desirable xNAME quality would reduce this to a O(n) problem, > > so you could just do > > > > D2. IN xNAME D1. > > D3. IN xNAME D1. > > D4. IN xNAME D1. > > > > ... > > > > C2.D1. IN xNAME C1.D1. > > C3.D1. IN xNAME C1.D1. > > C4.D1. IN xNAME C1.D1. > > Excellent! We have another concisely-worded requirement. Suzanne, > can you add this to the list? Thanks > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > From owner-namedroppers@ops.ietf.org Wed Aug 11 11:23: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 814173A68A2; Wed, 11 Aug 2010 11:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=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 u9ws8xYsW0xX; Wed, 11 Aug 2010 11:23:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF9453A67EF; Wed, 11 Aug 2010 11:23:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjFvu-000GJ4-CD for namedroppers-data0@psg.com; Wed, 11 Aug 2010 18:21:46 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjFvq-000GIg-Uj for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 18:21:43 +0000 Received: from [192.168.1.68] (unknown [83.105.105.210]) by mail.avalus.com (Postfix) with ESMTPSA id 407E2C56947; Wed, 11 Aug 2010 19:21:40 +0100 (BST) Date: Wed, 11 Aug 2010 19:21:39 +0100 From: Alex Bligh Reply-To: Alex Bligh To: John Levine , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] Re: how would an xNAME work? Message-ID: <2D9E6CEEC890027E5015CA26@nimrod.local> In-Reply-To: <20100811172331.37497.qmail@joyce.lan> References: <20100811172331.37497.qmail@joyce.lan> 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 11 August 2010 17:23:31 +0000 John Levine wrote: >> D2. IN xNAME D1. >> D3. IN xNAME D1. >> D4. IN xNAME D1. >> ... >> >> C2.D1. IN xNAME C1.D1. >> C3.D1. IN xNAME C1.D1. >> C4.D1. IN xNAME C1.D1. >> ... >> >> B2.C1.D1. IN xNAME B1.C1.D1. >> B3.C1.D1. IN xNAME B1.C1.D1. >> B4.C1.D1. IN xNAME B1.C1.D1. >> ... >> >> A2.B1.C1.D1. IN xNAME A1.B1.C1.D1. >> A3.B1.C1.D1. IN xNAME A1.B1.C1.D1. >> A4.B1.C1.D1. IN xNAME A1.B1.C1.D1. > > I must be missing something. Let's assume that C1.D1 is delegated to > someone other than the operator of D1. Who publishes the third and > fourth groups of xNAME records? So, lets assume D1's zone file contains: C1.D1. IN NS ns.example.com. as would be the normal registry case. I would presume these records also live in D1's zonefile. C2.D1. IN xNAME C1.D1. C3.D1. IN xNAME C1.D1. C4.D1. IN xNAME C1.D1. in each case served by the nameservers for D1. Similarly, C1.D1's zone file contains: B1.C1.D1. IN NS.example2.com. as is the normal registry case, and I would presume that these records also live in C1.D1's zone file: B2.C1.D1. IN xNAME B1.C1.D1. B3.C1.D1. IN xNAME B1.C1.D1. B4.C1.D1. IN xNAME B1.C1.D1. in each case served by the nameservers for C1.D1. (here ns.example.com) Further, B1.C1.D1's zone file contains A1.B1.C1.D1. IN NS.example3.com. as is the normal registry case, and I would presume that these records also live in B1.C1.D1's zone file: A2.B1.C1.D1. IN xNAME A1.B1.C1.D1. A3.B1.C1.D1. IN xNAME A1.B1.C1.D1. A4.B1.C1.D1. IN xNAME A1.B1.C1.D1. in each case served by the nameservers for B1.C1.D1. (here ns2.example.com) > If it's the operator of D1, how does > he find out what xNAMEs he needs to publish? If it's the operator of > C1.D1, how does the TLD ensure that the delegated operators are > publishing all of the xNAME records they're supposed to? The xNAME records are transferred to the delegating registry in the same way NS records are now. > And of course, if they're serious about equivalence, who verifies that > all of the mail, web, etc. applications are properly aliasing all of > the An.Bn.Cn.Dn names? The registry could, for instance, only accepts an xNAME record if it matches the appropriate policy equivalence test for an existing NS record. D1 will only accept C2.D1. as an xNAME if C2 is equivalent to C1; how it does that equivalence is a policy matter not a technical matter (it might be 'chinese characters with equivalent meaning'). Because C2.D1. is never delegated *at all*, it any children of C2.D1. will always be equivalent at a DNS level to the same child of C1.D1. because the lookup process would be performing that lookup within the C1.D1. tree. The C2.D1. tree does not itself exist; C2.D1. is just an alias to C1.D1. > Here's the one-senence version of why I think provisioning is the way > to go (with a hat tip to Phill): To make two domains usefully > equivalent, the amount of application provisioning necessary down at > the leaves will be so large that any savings from an xNAME hack up in > the DNS tree are lost in the noise. Well, that may be the case, and note the prefix to my post to Andrew, that I wasn't suggesting this requirement makes the whole thing useful, I was suggesting it may be a reason why people wouldn't argue for provision. As you say, making names "equivalent automatically in DNS" does not necessarily fix the issue. Two case spring to mind. In either a "dumb DNS provisioning hack", or my thing above, an http request for http://www.A2.B3.C4.D2/ would correctly be made to the server with IP address given by the A record for www.A1.B1.C1.D1. However, the GET line will be: GET http://www.A2.B3.C4.D2/index.html or whatever. This means, *irrespective* of the DNS method used, that the server operator will have to know to configure that server to respond to every Ai,Bj,Ck,Dl, even though they may only know the policy for equivalence at the Ai level (and indeed it may change "under their feet"). Arguably, this could fixed by browsers canonicalising the URL in the same way as DNS, but if you are doing that, why put the hack in at the DNS layer at all? Secondly, if you make the above case an https: request, the server has now lost any way to disambiguate between a request to www.A1.B1.C1.D1. and any other www.Ai.Bj.Ck.Dl request, which means it has no way of knowing which certificate to serve. That either requires a TLS/cert/browser hack, or worse. Hopefully the hack does not require having O(n^2) certificates. And this is fundamentally my problem with the whole BNAME idea. I see how it might be useful as a fun DNS tool, but not how it would actually work in practice as I can't see how the upper layers would work. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Aug 11 12:31: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 E84273A69D0; Wed, 11 Aug 2010 12:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=-0.325, 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 HoVgP8iLZyT5; Wed, 11 Aug 2010 12:31:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EA5083A6998; Wed, 11 Aug 2010 12:31:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjGy1-0000oR-3V for namedroppers-data0@psg.com; Wed, 11 Aug 2010 19:28:01 +0000 Received: from [209.85.215.180] (helo=mail-ey0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjGxy-0000nK-On for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 19:27:58 +0000 Received: by eyz10 with SMTP id 10so396109eyz.11 for ; Wed, 11 Aug 2010 12:27:57 -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=ReGn4hHMdhowUfWqJXoPmYugGNYq0PoYbwCEN1jcdm4=; b=Klm65DdZSidjLTpEYLLATjzSNp0yA3pzqLhlayy6nDGzQs0OcbXm/vQsQjNDpTJHXP fT/KB32UD47sSxG4YwXH7rQ8XVNUafLumuNQ5kYmDVkvItR5NISaqLvX5Twd+hfzoPME 7t6aCMRXGc4X658cpD8/eSN7x+KGaCYoSjhAs= 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=hW62T9hHsDpp/xfuCMAqmCQS8uecLfSXwB15u24ypTjWWBM+tXh7w0SpplGWKAICAK gm+ZdRgWZC3JukCYZhi2H4Bd9XRrhg/3IauR7a5kxqdLOdbN00GaSqg9KW3zZl2pccE2 PphkGGZDGXkklDnF25S0LBJTSKR7/A8djND4U= MIME-Version: 1.0 Received: by 10.213.27.201 with SMTP id j9mr15671287ebc.54.1281554877443; Wed, 11 Aug 2010 12:27:57 -0700 (PDT) Received: by 10.14.127.195 with HTTP; Wed, 11 Aug 2010 12:27:57 -0700 (PDT) Date: Wed, 11 Aug 2010 12:27:57 -0700 Message-ID: Subject: [dnsext] Whose ox is gored? was (Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same")) From: Ted Hardie To: Phillip Hallam-Baker , Tony Finch , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , 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: I am not sure I buy the argument that we cannot eliminate the complexity, only move it around. We can fail to create the complexity and limit the choices instead. That may, in fact, be a good thing. As an APPs guy, I'm pretty sure that handing applications something with the semantics of "also known as" or "did you mean" is not going to result in anything useful. The semantics aren't clear enough to get consistent results, at least in my opinion. If we lose interoperabilty at the level we won't be doing anybody any favors. regards, Ted From owner-namedroppers@ops.ietf.org Wed Aug 11 12:44: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 633DA28C0E7; Wed, 11 Aug 2010 12:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.122 X-Spam-Level: X-Spam-Status: No, score=-9.122 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 ogWGSk8GZn6i; Wed, 11 Aug 2010 12:44:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 80D393A65A5; Wed, 11 Aug 2010 12:44:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjHBG-00040I-Qd for namedroppers-data0@psg.com; Wed, 11 Aug 2010 19:41:42 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjHBC-0003zA-OX for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 19:41:38 +0000 Authentication-Results: rtp-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: AvsEADOZYkxAZnwM/2dsb2JhbACgL3GhU5s9hToEiVA X-IronPort-AV: E=Sophos;i="4.55,354,1278288000"; d="sig'?scan'208";a="146570872" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2010 19:41:35 +0000 Received: from dhcp-10-55-82-7.cisco.com (dhcp-10-55-82-7.cisco.com [10.55.82.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7BJfZ1i028316; Wed, 11 Aug 2010 19:41:35 GMT Subject: Re: [dnsext] Re: how would an xNAME work? Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-129-453299739" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100811172331.37497.qmail@joyce.lan> Date: Wed, 11 Aug 2010 21:41:33 +0200 Cc: namedroppers@ops.ietf.org, alex@alex.org.uk Content-Transfer-Encoding: 7bit Message-Id: References: <20100811172331.37497.qmail@joyce.lan> To: John Levine X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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-129-453299739 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 11 aug 2010, at 19.23, John Levine wrote: >> D2. IN xNAME D1. >> D3. IN xNAME D1. >> D4. IN xNAME D1. >> ... >>=20 >> C2.D1. IN xNAME C1.D1. >> C3.D1. IN xNAME C1.D1. >> C4.D1. IN xNAME C1.D1. >> ... >>=20 >> B2.C1.D1. IN xNAME B1.C1.D1. >> B3.C1.D1. IN xNAME B1.C1.D1. >> B4.C1.D1. IN xNAME B1.C1.D1. >> ... >>=20 >> A2.B1.C1.D1. IN xNAME A1.B1.C1.D1. >> A3.B1.C1.D1. IN xNAME A1.B1.C1.D1. >> A4.B1.C1.D1. IN xNAME A1.B1.C1.D1. >=20 > I must be missing something. Let's assume that C1.D1 is delegated to > someone other than the operator of D1. Who publishes the third and > fourth groups of xNAME records? If it's the operator of D1, how does > he find out what xNAMEs he needs to publish? If it's the operator of > C1.D1, how does the TLD ensure that the delegated operators are > publishing all of the xNAME records they're supposed to? The various managers of the various zones handle the records. We have to remember one thing here, and that is that there is absolutely = no ability to get any agreement on "what is equal". That implies = everyone will have their own view of what is equal. A scheme like the one above make it possible for each registry for each = one of the zones to make up their mind what xNAME RR they want to = publish. And finally, it is the application manager that makes up their = mind on what they want to support. Just like today when people might choose to (or not to) handle both = www.example.com and example.com as aliases in their HTTP server. I.e. we must separate the question of "what is equal, and who makes that = decision" from "given someone decide A and B should result in the same = data when being resolved, how to make that in an as practical way as = possible". In the scheme above, if the final end user that want the email addresses = me@A4.B3.C2.A1 and me@A4.B1.C2.A1 "should work", that user will request = that from some application hosting provider (maybe he will run the = server themselves). The email hosting provider will configure both = strings, and then ensure both domains will resolve. I am not worried. Yes, the number of permutations might be large. But for example here in = Sweden we already have this "problem" where some people have chosen = themselves to support bot (for example) faltstrom.se and f=E4ltstr=F6m.se.= But I do not want to support f=E4ltstrom.se (i.e. mixed a/=E4 and o/=F6).= So even if we had: faltstrom.se. IN NS ... f=E4ltstr=F6m.se. IN xNAME faltstrom.se. f=E4ltstrom.se. IN xNAME faltstrom.se. faltstr=F6m.se. IN xNAME faltstrom.se. ...I would never configure my application to support all four...and that = is fine, as *I* make the decision. As the domain holder. Other people might make other decisions. So I actually think this scheme makes sense for that reason as well. = That the decision is where the decision should be. If a "parent" zone = does not have "enough" xNAME in there, you talk with your parent. Patrik --Apple-Mail-129-453299739 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) iD8DBQFMYvztvHlR2X0luNwRAsacAJ9SvW8mOJ7bKRQ20dDysfhywLVQNACg10Jo JN6b2vgC4gq61G4gAZnyV50= =Jtvf -----END PGP SIGNATURE----- --Apple-Mail-129-453299739-- From owner-namedroppers@ops.ietf.org Wed Aug 11 13:13: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 873CD3A6A83; Wed, 11 Aug 2010 13:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.531 X-Spam-Level: X-Spam-Status: No, score=-108.531 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HABEAS_ACCREDITED_SOI=-4.3, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_BSP_TRUSTED=-4.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 bEarmXt8XN45; Wed, 11 Aug 2010 13:12:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE94D28C0F6; Wed, 11 Aug 2010 13:12:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjHcS-000Af1-Ie for namedroppers-data0@psg.com; Wed, 11 Aug 2010 20:09:48 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjHcQ-000AeT-9P for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 20:09:46 +0000 Received: (qmail 79446 invoked from network); 11 Aug 2010 20:09:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=2VD+QWbDShtgIlVajtB+Y9KQSasw+gZS+tRTnVYt8DM=; b=08UfRZxUtEmoyyRUPa7K18/sXWJkoW3NN7/CYbI4WguV6Fpg6CWcCeauSpW6SbiZ5HvnsWdF5cdoIIVyPwl1IKp3hicZ/Phom7I6hFAkevaA8aSKi7frSOolm7A61XRFAP2kPWfq5aABxSz/z35GMozPQbZQ/vVBHioTBEx0Ywc= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Aug 2010 20:09:21 -0000 Date: 11 Aug 2010 16:09:43 -0400 Message-ID: From: "John R. Levine" To: "=?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?=" Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: how would an xNAME work? In-Reply-To: References: <20100811172331.37497.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > We have to remember one thing here, and that is that there is absolutely no ability to get any agreement on "what is equal". That implies everyone will have their own view of what is equal. Quite right. That's why I don't see the point in inventing new DNS hacks that enshrine one defnition or another in code. R's, John From owner-namedroppers@ops.ietf.org Wed Aug 11 13:17: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 8719A3A6A99; Wed, 11 Aug 2010 13:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.097 X-Spam-Level: X-Spam-Status: No, score=-9.097 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 hxButbSvZs-R; Wed, 11 Aug 2010 13:17:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 05B203A683A; Wed, 11 Aug 2010 13:17:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjHgM-000Bb9-8g for namedroppers-data0@psg.com; Wed, 11 Aug 2010 20:13:50 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjHgK-000BaV-4G for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 20:13:48 +0000 Authentication-Results: rtp-iport-1.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: AvsEAPmgYkxAZnwN/2dsb2JhbACgMnGhS5tFhToEiVA X-IronPort-AV: E=Sophos;i="4.55,354,1278288000"; d="sig'?scan'208";a="146404398" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 11 Aug 2010 20:13:46 +0000 Received: from dhcp-10-55-82-7.cisco.com (dhcp-10-55-82-7.cisco.com [10.55.82.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7BKDkMT013706; Wed, 11 Aug 2010 20:13:46 GMT Subject: Re: [dnsext] Re: how would an xNAME work? Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-134-455230875" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Wed, 11 Aug 2010 22:13:45 +0200 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <7443EFEC-73E7-4635-B11D-2E59DF16480F@cisco.com> References: <20100811172331.37497.qmail@joyce.lan> To: "John R. Levine" X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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-134-455230875 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 aug 2010, at 22.09, John R. Levine wrote: >> We have to remember one thing here, and that is that there is = absolutely no ability to get any agreement on "what is equal". That = implies everyone will have their own view of what is equal. >=20 > Quite right. That's why I don't see the point in inventing new DNS = hacks that enshrine one defnition or another in code. Ok, then I misunderstood your posting. If I am admin for the zone B.C., then I want to make a decision to have = for example: A1.B.C. IN NS ... A2.B.C. IN xNAME A1.B.C. A3.B.C. IN xNAME A1.B.C. This decision can be based on a number of things: 1. My own preferences 2. Some policy admin for B.C. has, which implies I have promised to have = it 3. The domain holder of A1.B.C. has requested it Maybe other reasons as well. What I think would be a good thing is some xNAME "thing" that makes it = possible for me to implement this. In the small piece of Internet that I = am responsible for. The B.C. zone. Patrik --Apple-Mail-134-455230875 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) iD8DBQFMYwR5vHlR2X0luNwRAmdsAJ9GcSLWAGj8HdTaSnwneN1N1RqkAACfamu0 9sbCkvsQMhDdDa4vfLf9cjg= =smHO -----END PGP SIGNATURE----- --Apple-Mail-134-455230875-- From owner-namedroppers@ops.ietf.org Wed Aug 11 14:14: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 F2EAE3A67D1; Wed, 11 Aug 2010 14:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.536 X-Spam-Level: X-Spam-Status: No, score=-108.536 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HABEAS_ACCREDITED_SOI=-4.3, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_BSP_TRUSTED=-4.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 isb8jqiDQ6sI; Wed, 11 Aug 2010 14:14:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 42C963A6823; Wed, 11 Aug 2010 14:14:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjIYI-000Mvc-4G for namedroppers-data0@psg.com; Wed, 11 Aug 2010 21:09:34 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjIYF-000MvF-D6 for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 21:09:31 +0000 Received: (qmail 8979 invoked from network); 11 Aug 2010 21:09:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=uDvWcKPvDZHfkIlH/RocQTFagJ0YSCtnN/YHxubl0II=; b=xDpCQkuvpNfO8ZINqUl4FQwoxnNyfD0/TVzdAJFfTgs4/4CQZzejaT1IUmwQQoXfmpKAA2VfZrimeCZeGdfatHxRA99c11d6WGapcMzdN5By4GdkfMqv9Azo7k5xPJmA2QxKJgwYZ4V62cP5UEHewrNPHyXAsCNwdO4xc4xF1Uw= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Aug 2010 21:09:08 -0000 Date: 11 Aug 2010 17:09:29 -0400 Message-ID: From: "John R. Levine" To: "=?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?=" Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: how would an xNAME work? In-Reply-To: <7443EFEC-73E7-4635-B11D-2E59DF16480F@cisco.com> References: <20100811172331.37497.qmail@joyce.lan> <7443EFEC-73E7-4635-B11D-2E59DF16480F@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > If I am admin for the zone B.C., then I want to make a decision to have for example: > > A1.B.C. IN NS ... > A2.B.C. IN xNAME A1.B.C. > A3.B.C. IN xNAME A1.B.C. > > This decision can be based on a number of things: > > 1. My own preferences > > 2. Some policy admin for B.C. has, which implies I have promised to have it > > 3. The domain holder of A1.B.C. has requested it Maybe I'm spoiled, but the DNS records in my zones are all generated by perl scripts out of a database, so the extra programming to clone a zone is no big deal. I keep hearing people (not you particularly) saying "well, this hack does MY job serving DNS, and the other 90% is someone else's problem so I don't care." R's, John From owner-namedroppers@ops.ietf.org Wed Aug 11 14:27: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 7381728C0DB; Wed, 11 Aug 2010 14:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.436 X-Spam-Level: X-Spam-Status: No, score=0.436 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 oAjzSdWI3h7I; Wed, 11 Aug 2010 14:27:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 91E9C28C0CE; Wed, 11 Aug 2010 14:27:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjIlz-000OvE-Dl for namedroppers-data0@psg.com; Wed, 11 Aug 2010 21:23:43 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjIls-000Orj-BX for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 21:23:36 +0000 Received: by fxm10 with SMTP id 10so582155fxm.11 for ; Wed, 11 Aug 2010 14:23:34 -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; bh=f0ZuI6avVhiT+vzdPEw7i+BdEsXZP7YtFxkWvPpZaWs=; b=l/EECAjbGpjtt607h4iMw7ewEc4EaGf9iqs8Fx9qzqDbHFka9Cyo4dQ75En9s05HKG st7/LH3wLzfdnMpczAU84resJdjKyLRCwaVc+/O/uSyg28h2hoEik9jcUCrIkTs3vBdh BQPcH2Yin4jlNqm+PmG6D4QJdO+bTu2f2Ka7w= 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=rNXb1PQM5PfhILj7DDYAb93S/47ibNn/LH2df00YNhrY+fhlWyMLbvF7OSaA6ynj1x T4NHXErtMMlM5dTXITbmUzEqXUoRl6B7t1h9gWeq1Jhwqe0jn/AMk88L9Rdk82ZOLRqH adyayH97jN8TfPqSKpZ5tl7N2Fxm5s9zVH8FA= MIME-Version: 1.0 Received: by 10.223.105.76 with SMTP id s12mr9176235fao.107.1281561814607; Wed, 11 Aug 2010 14:23:34 -0700 (PDT) Received: by 10.223.50.154 with HTTP; Wed, 11 Aug 2010 14:23:34 -0700 (PDT) In-Reply-To: <7443EFEC-73E7-4635-B11D-2E59DF16480F@cisco.com> References: <20100811172331.37497.qmail@joyce.lan> <7443EFEC-73E7-4635-B11D-2E59DF16480F@cisco.com> Date: Wed, 11 Aug 2010 18:23:34 -0300 Message-ID: Subject: Re: [dnsext] Re: how would an xNAME work? From: Brian Dickson To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: "John R. Levine" , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=0016e6d32a1fb7ab5a048d92dcba Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016e6d32a1fb7ab5a048d92dcba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Let's consider two very similar notions, which have entirely different semantics under the hood, and differing sets of required changes to the DNS ecosystem. First, the xNAME approach: In the zone B.C, we establish the equivalence directly, and need new kinds of records (xNAME). A1.B.C NS ... A2.B.C xNAME A1.B.C Note also, that all other (xNAME) labels are "second class" citizens; the labels won't be usable until resolvers or clients understand xNAME; the other labels are entirely dependent upon the first label, making the system somewhat brittle. In a sequence of delegations, any single delegation which loses its X1 entry, breaks the whole chain for all W[1-N].X[1-N].Y[1-N].Z permutations. Second, an alternative approach, where the equivalence is established indirectly, in the child zone(s) below the zone cut(s): A1.B.C NS ... A2.B.C NS ... A3.B.C NS ... And on the authority server(s) pointed to by the NS records: A1 =3D=3D A2 =3D=3D A3 (under B.C) =3D> zone contents for the equivalent zo= nes The same number of entries is required in the B.C zone. There is the requirement that the target of the delegation "understand" tha= t queries, regardless of which A[1234] they show up under. And likewise that server would need to understand all the permutations Ai.Bj.Ck.Dl. However, and this is important... Generally speaking, the server will only be authoritative for stuff at or below Ai. This means that the tree of labels can be folded via hard-links at each level of the tree, on the child tree (or hash table) used for deciding how to answer queries. So, on the leaf authority server, that server can have D1 =3D=3D D2 =3D=3D = D3 =3D=3D D4 (TLD), and under that, (C1 =3D=3D C2 =3D=3D C3 =3D=3D C4).D1, etc., preserv= ing the O(n) behavior. Each label Dl points to the same node, which has children Ck all pointing t= o the same child node, which has children of its own Bj pointing to the same node, and finally Ai great-grand-children. This is less brittle, in that a single error above the authority server for the equivalent zones, will only break one possible path among the very many paths -- they are all NS records. The equivalence is done by the zone admin of the authority server, rather than the zone admin of the parent zone, and thus it removes the parent zone admin from having that administrative burden. And, most important, the DNS protocol does not need to change to support this, only the implementations of authority servers to provide this equivalence hard-coding capability. The ability itself does not require any interoperability, as it is local, and thus creates a potentially more reliable resulting set of systems through the delegation and authority chai= n - since multiple vendors' code can be used independently once the feature i= s available. Brian 2010/8/11 Patrik F=E4ltstr=F6m > > On 11 aug 2010, at 22.09, John R. Levine wrote: > > >> We have to remember one thing here, and that is that there is absolute= ly > no ability to get any agreement on "what is equal". That implies everyone > will have their own view of what is equal. > > > > Quite right. That's why I don't see the point in inventing new DNS hac= ks > that enshrine one defnition or another in code. > > Ok, then I misunderstood your posting. > > If I am admin for the zone B.C., then I want to make a decision to have f= or > example: > > A1.B.C. IN NS ... > A2.B.C. IN xNAME A1.B.C. > A3.B.C. IN xNAME A1.B.C. > > This decision can be based on a number of things: > > 1. My own preferences > > 2. Some policy admin for B.C. has, which implies I have promised to have = it > > 3. The domain holder of A1.B.C. has requested it > > Maybe other reasons as well. > > What I think would be a good thing is some xNAME "thing" that makes it > possible for me to implement this. In the small piece of Internet that I = am > responsible for. The B.C. zone. > > Patrik > > --0016e6d32a1fb7ab5a048d92dcba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Let's consider two very similar notions, which have entirely different = semantics under the hood, and differing sets of required changes to the DNS= ecosystem.

First, the xNAME approach:

In the zone B.C, we es= tablish the equivalence directly, and need new kinds of records (xNAME).
A1.B.C NS ...
A2.B.C xNAME A1.B.C

Note also, that all other (= xNAME) labels are "second class" citizens; the labels won't b= e usable until resolvers or clients understand xNAME; the other labels are = entirely dependent upon the first label, making the system somewhat brittle= .
In a sequence of delegations, any single delegation which loses its X1 entr= y, breaks the whole chain for all W[1-N].X[1-N].Y[1-N].Z permutations.
<= br>Second, an alternative approach, where the equivalence is established in= directly, in the child zone(s) below the zone cut(s):

A1.B.C NS ...
A2.B.C NS ...
A3.B.C NS ...

And on the autho= rity server(s) pointed to by the NS records:
A1 =3D=3D A2 =3D=3D A3 (und= er B.C) =3D> zone contents for the equivalent zones

The same numb= er of entries is required in the B.C zone.
There is the requirement that the target of the delegation "understand= " that queries, regardless of which A[1234] they show up under.
And= likewise that server would need to understand all the permutations Ai.Bj.C= k.Dl.

However, and this is important... Generally speaking, the server will o= nly be authoritative for stuff at or below Ai.

This means that the t= ree of labels can be folded via hard-links at each level of the tree, on th= e child tree (or hash table) used for deciding how to answer queries.

So, on the leaf authority server, that server can have D1 =3D=3D D2 =3D= =3D D3 =3D=3D D4 (TLD), and under that, (C1 =3D=3D C2 =3D=3D C3 =3D=3D C4).= D1, etc., preserving the O(n) behavior.

Each label Dl points to the = same node, which has children Ck all pointing to the same child node, which= has children of its own Bj pointing to the same node, and finally Ai great= -grand-children.

This is less brittle, in that a single error above the authority server= for the equivalent zones, will only break one possible path among the very= many paths -- they are all NS records.

The equivalence is done by t= he zone admin of the authority server, rather than the zone admin of the pa= rent zone, and thus it removes the parent zone admin from having that admin= istrative burden.

And, most important, the DNS protocol does not need to change to suppor= t this, only the implementations of authority servers to provide this equiv= alence hard-coding capability. The ability itself does not require any inte= roperability, as it is local, and thus creates a potentially more reliable = resulting set of systems through the delegation and authority chain - since= multiple vendors' code can be used independently once the feature is a= vailable.

Brian

2010/8/11 Patrik F=E4ltstr=F6m = <paf@cisco.com>= ;

On 11 aug 2010, at 22.09, John R. Levine wrote:

>> We have to remember one thing here, and that is that there is abso= lutely no ability to get any agreement on "what is equal". That i= mplies everyone will have their own view of what is equal.
>
> Quite right. =A0That's why I don't see the point in inventing = new DNS hacks that enshrine one defnition or another in code.

Ok, then I misunderstood your posting.

If I am admin for the zone B.C., then I want to make a decision to have for= example:

A1.B.C. IN NS ...
A2.B.C. IN xNAME A1.B.C.
A3.B.C. IN xNAME A1.B.C.

This decision can be based on a number of things:

1. My own preferences

2. Some policy admin for B.C. has, which implies I have promised to have it=

3. The domain holder of A1.B.C. has requested it

Maybe other reasons as well.

What I think would be a good thing is some xNAME "thing" that mak= es it possible for me to implement this. In the small piece of Internet tha= t I am responsible for. The B.C. zone.

=A0 Patrik


--0016e6d32a1fb7ab5a048d92dcba-- From owner-namedroppers@ops.ietf.org Wed Aug 11 15:17: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 BB6043A67B7; Wed, 11 Aug 2010 15:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.273 X-Spam-Level: X-Spam-Status: No, score=-105.273 tagged_above=-999 required=5 tests=[AWL=-0.836, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 J3E1mlqnjYb1; Wed, 11 Aug 2010 15:17:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 929F33A6918; Wed, 11 Aug 2010 15:17:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjJa3-0006cJ-DG for namedroppers-data0@psg.com; Wed, 11 Aug 2010 22:15:27 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjJa1-0006c5-DY for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 22:15:25 +0000 Received: from sjc-office-nat-210.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 98E09A94482; Wed, 11 Aug 2010 22:15:24 +0000 (UTC) Message-ID: <4C6320FC.7040402@mail-abuse.org> Date: Wed, 11 Aug 2010 15:15:24 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "John R. Levine" CC: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: how would an xNAME work? References: <20100811172331.37497.qmail@joyce.lan> 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 8/11/10 1:09 PM, John R. Levine wrote: >> We have to remember one thing here, and that is that there is >> absolutely no ability to get any agreement on "what is equal". That >> implies everyone will have their own view of what is equal. > Quite right. That's why I don't see the point in inventing new DNS > hacks that enshrine one defnition or another in code. John, Why get bogged down with semantics? IDN creates difficult to resolve issues in DNS. For example, when dealing with ideograms, verbally communicating a domain can be problematic. For cases where users might not know which variant to use, cloning different domains seems to share similar issues with bnames. For TLS certificates to show the correct target, http 302 redirects might be a solution. This approach could also be used in conjunction with a tactic needed to preclude use of aliased names as targets within the resource record. It seems this represents a configuration issue that will need to be handled, but there does not appear to be a better solution when nothing is changed with respect to the DNS protocol. How do you envision these issues being resolved? -Doug From owner-namedroppers@ops.ietf.org Wed Aug 11 15:17: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 DD37C3A680C; Wed, 11 Aug 2010 15:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.317 X-Spam-Level: X-Spam-Status: No, score=-101.317 tagged_above=-999 required=5 tests=[AWL=1.283, 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 vfy+SuqCEOmh; Wed, 11 Aug 2010 15:17:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 929C73A68B5; Wed, 11 Aug 2010 15:17:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjJY0-0006O5-Pj for namedroppers-data0@psg.com; Wed, 11 Aug 2010 22:13:20 +0000 Received: from [2001:12ff:0:2::4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjJXy-0006Nl-Ip for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 22:13:18 +0000 Received: by clone.registro.br (Postfix, from userid 1000) id 9D4C0E0497; Wed, 11 Aug 2010 19:13:17 -0300 (BRT) Date: Wed, 11 Aug 2010 19:13:17 -0300 From: Frederico A C Neves To: Brian Dickson Cc: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , "John R. Levine" , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: how would an xNAME work? Message-ID: <20100811221317.GC132@registro.br> References: <20100811172331.37497.qmail@joyce.lan> <7443EFEC-73E7-4635-B11D-2E59DF16480F@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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, Aug 11, 2010 at 06:23:34PM -0300, Brian Dickson wrote: ... > The equivalence is done by the zone admin of the authority server, rather > than the zone admin of the parent zone, and thus it removes the parent zone > admin from having that administrative burden. > > And, most important, the DNS protocol does not need to change to support > this, only the implementations of authority servers to provide this > equivalence hard-coding capability. The ability itself does not require any > interoperability, as it is local, and thus creates a potentially more > reliable resulting set of systems through the delegation and authority chain > - since multiple vendors' code can be used independently once the feature is > available. For non DNSSEC zones this is straight forward to implement. For Signed zones this is much harder to accommodate, but probably the only and most sane workable solution. > Brian Fred From owner-namedroppers@ops.ietf.org Wed Aug 11 15:34: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 98D203A67B7; Wed, 11 Aug 2010 15:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_65=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 Acy0Vqb2OKYk; Wed, 11 Aug 2010 15:34:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F61E3A63EC; Wed, 11 Aug 2010 15:34:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjJpJ-0008ah-3T for namedroppers-data0@psg.com; Wed, 11 Aug 2010 22:31:13 +0000 Received: from [209.85.160.180] (helo=mail-gy0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjJpG-0008aA-7j for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 22:31:10 +0000 Received: by gye5 with SMTP id 5so292153gye.11 for ; Wed, 11 Aug 2010 15:31:09 -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=nVuIIyqWO4BbyP4Ebt6c+oeuBwBuM6iXqwTptE5x41A=; b=YwTPVWtYJZBrEXp8NZSliOFMV3kNuUk3Wnw3aeGxx2MYuaqMmeKOsVbw6FFvmBbexe 7dzymksn8VB8Gb/Yq/D+rYrj1VO2mJ9FBhMPqUD34WKDxPsSC+rtSmvSxJOLonE26Mbf 7Xgs1BBRbBcMw9fT8YMKf5f116IuskBCJorAg= 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=ofQsWfQOsjIjqgfVTB3hA48OvFOHpK4iPSdHDxfCfo3hPFRNVossWMFiEy6iVG3EXg y93WLVjQPayaNYPkuGbgx40/H93kKG7kOaqk+xtLiczOd5qdLOqt8/MysTW09zKMEgIY DORVWwx680QnUjxs9ceTqgIijpYbhFBsxQEYY= MIME-Version: 1.0 Received: by 10.100.174.16 with SMTP id w16mr22400490ane.266.1281565869340; Wed, 11 Aug 2010 15:31:09 -0700 (PDT) Received: by 10.101.188.15 with HTTP; Wed, 11 Aug 2010 15:31:09 -0700 (PDT) In-Reply-To: References: <481501584.15255@cnnic.cn> Date: Wed, 11 Aug 2010 18:31:09 -0400 Message-ID: Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" From: Phillip Hallam-Baker To: Tony Finch Cc: "John R. Levine" , Jiankang YAO , namedroppers@ops.ietf.org, ajs@shinkuro.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: Not from the parent authority domain, they don't. Within an authority area, this problem can be solved with provisioning and CNames etc. Its the parent authority name issue that is tricky. On Wed, Aug 11, 2010 at 1:55 PM, Tony Finch wrote: > On Wed, 11 Aug 2010, Phillip Hallam-Baker wrote: >> >> If you try to do transparent fixup in the DNS so that the client asks >> for google.china and gets back the A records for google.cn from the >> resolver, we now have a facility that can be used to establish >> transparent redirects without browsers ever being aware that they were >> redirected. > > CNAME and DNAME already do that. > > Tony. > -- > f.anthony.n.finch =A0 =A0http://dotat.at/ > SHANNON ROCKALL: NORTHWEST 4 OR 5. MODERATE. SHOWERS. GOOD. > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Wed Aug 11 15:39: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 D431E3A67B7; Wed, 11 Aug 2010 15:39:27 -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, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MU0kHkGEOhKC; Wed, 11 Aug 2010 15:39:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C320A3A680B; Wed, 11 Aug 2010 15:39:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjJvI-0009MH-EM for namedroppers-data0@psg.com; Wed, 11 Aug 2010 22:37:24 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjJvF-0009Lh-H9 for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 22:37:22 +0000 Received: from [192.168.1.68] (unknown [83.105.105.210]) by mail.avalus.com (Postfix) with ESMTPSA id 94BBCC56947; Wed, 11 Aug 2010 23:37:19 +0100 (BST) Date: Wed, 11 Aug 2010 23:37:18 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Suzanne Woolf , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: new use case? was Re: [dnsext] Re: An argument why bname-style delegation is needed Message-ID: <3F869153919545C74600DFAE@nimrod.local> In-Reply-To: <20100811181909.GA49913@farside.isc.org> References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <20100811135657.GA57645@shinkuro.com> <88B2242191A75578846B5E0B@nimrod.local> <20100811155552.GM57645@shinkuro.com> <8741ED5CB121AE652BED9997@nimrod.local> <20100811163944.GP57645@shinkuro.com> <20100811181909.GA49913@farside.isc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Suzanne, --On 11 August 2010 18:19:09 +0000 Suzanne Woolf wrote: > Sure, happy to add this to the problem statement doc, with the > following questions: > > 1. Does any solution currently proposed handle this case? At a glance > I don't think so. > > 2. Does anyone reading this want to speak up and say Alex's > formulation corresponds to a use case they've seen and they would use > this capability if they had it? I'm well aware that's a weaker > constraint than Andrew has been trying to encourage (as I read it, > he's been trying to get us to "you couldn't do what you need to do > without it" rather than "you'd use it if you had it"), but I'm willing > to lower the bar for purposes of discussion. I'm not sure what I am suggesting is a new criterion; I think it's just a reformulation (and perhaps a useful one, that's for others) of an existing one. I'll attempt to explain why: Any system conforming to the criterion I specified has the property that in x.Ai.Bj.Ck.Dl, the zone containing x is only stored once, in x.Ai.Bj.Ck.Dl, because equivalence is performed rightward of x, and any formulation only storing the zone once must necessarily have this property (i.e. it's an if-and-only-if). If the zone is stored more than once (i.e. this criteria does not apply), that implies the data could differ, which implies there is no way of an operator further up the tree ensuring that labels downstream remain equivalent. For instance, if C can ensure through the D zone file that C1.D1 is equivalent to C2.D1, then if and only if C can ensure that Ax.By.C1.D1 == Ax.By.C2.D1 for all x and y, this is equivalent to there being only one copy of everything below C1 (or at least of every copy being forced to be identical). So I don't think my criterion is much more than a restatement of the proposed criterion which states that a property of xNAME should be that that the xNAME owner can ensure that not only the immediate sublevel but anything below it shares the same equivalence. I can't see how you could satisfy that /without/ solving the O(a^n) problem. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Aug 11 15:57: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 EB8C43A680B; Wed, 11 Aug 2010 15:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.09 X-Spam-Level: X-Spam-Status: No, score=-3.09 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, J_CHICKENPOX_65=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 Fj6nojEDHuny; Wed, 11 Aug 2010 15:57:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F0F13A63EC; Wed, 11 Aug 2010 15:57:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjKCe-000Bvf-Fg for namedroppers-data0@psg.com; Wed, 11 Aug 2010 22:55:20 +0000 Received: from [131.111.8.132] (helo=ppsw-32.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjKCc-000BvO-2u for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 22:55:18 +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]:41357) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1OjKCX-0005Gp-2d (Exim 4.72) (return-path ); Wed, 11 Aug 2010 23:55:14 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OjKCX-0003RF-Py (Exim 4.67) (return-path ); Wed, 11 Aug 2010 23:55:13 +0100 Date: Wed, 11 Aug 2010 23:55:13 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker cc: "John R. Levine" , Jiankang YAO , namedroppers@ops.ietf.org, ajs@shinkuro.com Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" In-Reply-To: Message-ID: References: <481501584.15255@cnnic.cn> 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 Wed, 11 Aug 2010, Phillip Hallam-Baker wrote: > On Wed, Aug 11, 2010 at 1:55 PM, Tony Finch wrote: > > On Wed, 11 Aug 2010, Phillip Hallam-Baker wrote: > >> > >> If you try to do transparent fixup in the DNS so that the client asks > >> for google.china and gets back the A records for google.cn from the > >> resolver, we now have a facility that can be used to establish > >> transparent redirects without browsers ever being aware that they were > >> redirected. > > > > CNAME and DNAME already do that. > > Not from the parent authority domain, they don't. Sorry, I was being too terse. The context was that the app would be confused because it was unaware of the redirection, and I thought you were saying that this is a new thing. However I could create google.dotat.at CNAME www.l.google.com which doesn't work for just the same reason. Tony. -- f.anthony.n.finch http://dotat.at/ MALIN HEBRIDES: NORTHWEST 5 OR 6, DECREASING 4 LATER IN HEBRIDES. MODERATE, OCCASIONALLY ROUGH. SHOWERS. MODERATE OR GOOD. From owner-namedroppers@ops.ietf.org Wed Aug 11 17:01: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 E720D3A69F6; Wed, 11 Aug 2010 17:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 RPH5thsiy4Vi; Wed, 11 Aug 2010 17:01:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F1AFE3A68B8; Wed, 11 Aug 2010 17:01:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjLAK-000KHs-QC for namedroppers-data0@psg.com; Wed, 11 Aug 2010 23:57:00 +0000 Received: from [2001:4f8:3:bb::111] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjLAI-000KHU-NN for namedroppers@ops.ietf.org; Wed, 11 Aug 2010 23:56:58 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 65E58A1054 for ; Wed, 11 Aug 2010 23:56:58 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: how would an xNAME work? In-Reply-To: Your message of "11 Aug 2010 17:09:29 -0400." References: <20100811172331.37497.qmail@joyce.lan> <7443EFEC-73E7-4635-B11D-2E59DF16480F@cisco.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Wed, 11 Aug 2010 23:56:58 +0000 Message-ID: <81131.1281571018@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: 11 Aug 2010 17:09:29 -0400 > From: "John R. Levine" > > Maybe I'm spoiled, but the DNS records in my zones are all generated by > perl scripts out of a database, so the extra programming to clone a zone > is no big deal. you're not spoiled. but you're not running a large delegation-mostly with high churn, where the registrants are constantly updating their NS RRsets as they add and drop slave servers. and you're probably not running slave service for tens of thousand domains, either. so, your needs are smallish. > I keep hearing people (not you particularly) saying "well, this hack does > MY job serving DNS, and the other 90% is someone else's problem so I > don't care." in my own work on this topic (SHADOW), i noted that a great share of the burden of sameness falls on third parties, and that to scale, an approach would have to automate/synchronize the cooperation of these other parties. in other words, not everything that the protocol can somehow already do if every domain owner can write the local software they need, is enough. From owner-namedroppers@ops.ietf.org Wed Aug 11 20:43: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 D7F923A68A7; Wed, 11 Aug 2010 20:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.073 X-Spam-Level: X-Spam-Status: No, score=-9.073 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 1jQ0hiHTc5-1; Wed, 11 Aug 2010 20:43:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F85C3A68CE; Wed, 11 Aug 2010 20:43:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjOai-000PFJ-Pm for namedroppers-data0@psg.com; Thu, 12 Aug 2010 03:36:28 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjOaf-000PF0-S4 for namedroppers@ops.ietf.org; Thu, 12 Aug 2010 03:36:26 +0000 Authentication-Results: rtp-iport-1.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: AvsEADoJY0xAZnwN/2dsb2JhbACgOXGgSJs/hToEiVA X-IronPort-AV: E=Sophos;i="4.55,356,1278288000"; d="sig'?scan'208";a="146546167" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Aug 2010 03:36:24 +0000 Received: from dhcp-10-55-82-7.cisco.com (dhcp-10-55-82-7.cisco.com [10.55.82.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7C3aN1Z027655; Thu, 12 Aug 2010 03:36:24 GMT Subject: Re: [dnsext] Re: how would an xNAME work? Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-137-481788690" From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Thu, 12 Aug 2010 05:36:22 +0200 Cc: "John R. Levine" , namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <79F5FF91-642F-45CE-8135-AD12A2DA7781@cisco.com> References: <20100811172331.37497.qmail@joyce.lan> <7443EFEC-73E7-4635-B11D-2E59DF16480F@cisco.com> To: Brian Dickson X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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-137-481788690 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 aug 2010, at 23.23, Brian Dickson wrote: > Second, an alternative approach, where the equivalence is established > indirectly, in the child zone(s) below the zone cut(s): >=20 > A1.B.C NS ... > A2.B.C NS ... > A3.B.C NS ... >=20 > And on the authority server(s) pointed to by the NS records: > A1 =3D=3D A2 =3D=3D A3 (under B.C) =3D> zone contents for the = equivalent zones >=20 > The same number of entries is required in the B.C zone. > There is the requirement that the target of the delegation = "understand" that > queries, regardless of which A[1234] they show up under. > And likewise that server would need to understand all the permutations > Ai.Bj.Ck.Dl. I think this in reality only works as long as you believe you can keep = the NS records synchronised, and possibly all referring to the same set = of authority servers. Including the configuration of the servers = themselves in the form of configuration of the secondary servers, zone = transfer etc. Think specifically of the point in time when things are = not paid for any longer, or transferred from holder Foo to Bar. And = maybe A2.B.C. is changing holder... I.e. "bundling" of domain names in = the registry will be an absolute requirement, instead of as with xNAME = A1.B.C might go away, be re-registered by someone else, and then that = party will automatically get also the A[234].B.C. names as the xNAME = stayed in the parent zone as before during the transfer of the A1.B.C. = domain from holder Foo to holder Bar. So, I still think we with xNAME get easier administration as only one = parent/child relationship is to be managed, instead of many. Yes, two = new problems: support for xNAME and management of the xNAME itself (so = it does not refer to a "dead" name). The second of these I claim is = relatively easy though as that is in the B.C. zone in the example above. = There are no cross zone management issues as you would have in the child = zones with zone transfer management. We of course also have to think about the following (instead of only the = delegation): A1.B.C. IN A ... A1.B.C. IN AAAA ... A1.B.C. IN MX ... _foo._bar.A1.B.C. IN SRV ... www.A1.B.C. IN A ... www.A1.B.C. IN AAAA ... A2.B.C. IN xNAME A1.B.C. A3.B.C. IN xNAME A1.B.C. A4.B.C. IN xNAME A1.B.C. That way, the management of "similarities" is managed by the xNAME = records, while all data is tied to the A1-related records. Yes, someone = said A1 then become a first class citizen, while others are secondary, = but in some cases that can be viewed as a positive thing. Patrik --Apple-Mail-137-481788690 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) iD8DBQFMY2w2vHlR2X0luNwRAieWAJ99hqHamjuhJPf8EaaEOqNiqNAyzQCg+muY FKhmHJzduDEclHYE09G/TzQ= =WyL8 -----END PGP SIGNATURE----- --Apple-Mail-137-481788690-- From owner-namedroppers@ops.ietf.org Thu Aug 12 00: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 7B2883A6830; Thu, 12 Aug 2010 00:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.245 X-Spam-Level: X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 wUIiyBQppMiH; Thu, 12 Aug 2010 00:01:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 618C53A6893; Thu, 12 Aug 2010 00:01:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjRhI-0001x9-IF for namedroppers-data0@psg.com; Thu, 12 Aug 2010 06:55:28 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjRhE-0001wO-UZ for namedroppers@ops.ietf.org; Thu, 12 Aug 2010 06:55:25 +0000 Received: from [192.168.1.68] (unknown [83.105.105.210]) by mail.avalus.com (Postfix) with ESMTPSA id 37B21C56943; Thu, 12 Aug 2010 07:55:21 +0100 (BST) Date: Thu, 12 Aug 2010 07:55:22 +0100 From: Alex Bligh Reply-To: Alex Bligh To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , Brian Dickson cc: "John R. Levine" , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Re: how would an xNAME work? Message-ID: <17894F8A9869BC9AD5BE000A@nimrod.local> In-Reply-To: <79F5FF91-642F-45CE-8135-AD12A2DA7781@cisco.com> References: <20100811172331.37497.qmail@joyce.lan> <7443EFEC-73E7-4635-B11D-2E59DF16480F@cisco.com> <79F5FF91-642F-45CE-8135-AD12A2DA7781@cisco.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 12 August 2010 05:36:22 +0200 Patrik F=C3=A4ltstr=C3=B6m = wrote: > We of course also have to think about the following (instead of only the > delegation): > > A1.B.C. IN A ... > A1.B.C. IN AAAA ... > A1.B.C. IN MX ... > _foo._bar.A1.B.C. IN SRV ... > www.A1.B.C. IN A ... > www.A1.B.C. IN AAAA ... > > A2.B.C. IN xNAME A1.B.C. > A3.B.C. IN xNAME A1.B.C. > A4.B.C. IN xNAME A1.B.C. That would be desirable, but an (inferior) alternative would be to say xNAME only works for the delegations, and (e.g.) www.A2.B.C. was handled by a second entry in the above zone file. Obviously handling cases other than delegation is far better, but I mention this for completeness. --=20 Alex Bligh From owner-namedroppers@ops.ietf.org Thu Aug 12 06:34: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 863FC3A68B2; Thu, 12 Aug 2010 06:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.705 X-Spam-Level: X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6, J_CHICKENPOX_64=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 PUGMjcUwi3iV; Thu, 12 Aug 2010 06:34:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5ED7D3A684C; Thu, 12 Aug 2010 06:34:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjXpv-000HlQ-GB for namedroppers-data0@psg.com; Thu, 12 Aug 2010 13:28:47 +0000 Received: from [209.85.212.180] (helo=mail-px0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjXpp-000Hkc-Jk for namedroppers@ops.ietf.org; Thu, 12 Aug 2010 13:28:41 +0000 Received: by pxi7 with SMTP id 7so739604pxi.11 for ; Thu, 12 Aug 2010 06:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=CiCYSRZuM4f7Ovgl/ga7kTFyj+2qtGCkXXtaoVITII8=; b=Jt1B112s0PPg8Qxb8QYZ/xJBU5vI3VdRzzVmeBjoIlcwxPZBFfXFRpm+xZGx7qYYRr QfA7Gnj6hOPClAxYk1UDg8SM5NrHETHR5wq83TIuGrQqEwFBCUflzxjUmKjGSLI6hO3q t1ypqtbDWemf7pWR+lLxE+YwOwFwrFwKyuwv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; b=XgEmOQ/Mwje4F3fBoeW/vDlutiAVmZi9VZETpOWjWxi9vBSQQSqx6tY/Q+h/tewMNv Cu3ijGZu9MSwm5T/vIAxCtGoB7c13vp0YWuFMFeVcdhikzXfMHY9Y/vQXgLRQV6lUe5w 9VwMD4++YzdUozH80Yi7VCQrBEC+lvNQy9wKM= Received: by 10.142.207.5 with SMTP id e5mr39853wfg.229.1281619719242; Thu, 12 Aug 2010 06:28:39 -0700 (PDT) Received: from zhanglikun ([218.241.109.24]) by mx.google.com with ESMTPS id 23sm1583140wfa.10.2010.08.12.06.28.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 12 Aug 2010 06:28:38 -0700 (PDT) From: "zhanglikun" To: Subject: Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") Date: Thu, 12 Aug 2010 21:28:37 +0800 Message-ID: <00aa01cb3a22$4754a5e0$d5fdf1a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs6HimaKNkUk/8RQly7BAuIEUtxIQAA/y2g Content-Language: zh-cn Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I don't plan to add more arguments for the provision way, since the complexity it brings when comes to multiple-labels domain equivalence, which has been mentioned by former emails, it's o(a^n), instead xName is o(n) . Now let me go back to c+dname VS bname. If one zone has records: a.net. cname a.cn. a.net. dname b.com. user do the query with the following sequence: dig a.net. cname dig a.net. dname if the cache isn't aware of the new c+dname rules, will the second query will chase down to b.com.? it will try to chase down a dname record belonging to a.cn. rather than b.com. Except the c+dname has one rule: the rdata part of should be same. anther, when doing update, you have to be very careful to decide whether to remove/add c+dname or just one of them. Last, c+dname will double zone size, compared with bname. My point is +1 for bname. Anyway, this topic recall me to the added voice saying no to DNAME long before(five years ago or more), somebody said he had a complete dislike for the DNAME, not just the document but also the idea, even though the DNAME had born. :) Thanks Likun Zhang From owner-namedroppers@ops.ietf.org Thu Aug 12 06:44: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 3126F3A6838; Thu, 12 Aug 2010 06:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.246 X-Spam-Level: X-Spam-Status: No, score=-101.246 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, J_CHICKENPOX_23=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 pOVDhdCcca7N; Thu, 12 Aug 2010 06:44:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A72853A6A28; Thu, 12 Aug 2010 06:44:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjY1c-000K74-8f for namedroppers-data0@psg.com; Thu, 12 Aug 2010 13:40:52 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjY1Z-000K5w-6W for namedroppers@ops.ietf.org; Thu, 12 Aug 2010 13:40:49 +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 6FE9D734376; Thu, 12 Aug 2010 15:40:47 +0200 (CEST) Message-ID: <4C63F9DF.4010104@nic.cz> Date: Thu, 12 Aug 2010 15:40:47 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable? References: <201008042142.o74LgRap031934@cichlid.raleigh.ibm.com> <05B243F724B2284986522B6ACD0504D7D3444A2AAF@EXVPMBX100-1.exc.icann.org> <20100804230904.GB4034@farside.isc.org> <05B243F724B2284986522B6ACD0504D7D3444A2CF6@EXVPMBX100-1.exc.icann.org> <20100805182146.GI38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D00@EXVPMBX100-1.exc.icann.org> <20100805183608.GJ38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D1B@EXVPMBX100-1.exc.icann.org> <20100810141322.GD52191@shinkuro.com> <3F9D6BF0A3BA40D5BA4044B7DC347FAA@LENOVO47E041CF> <20100810154446.GG52191@shinkuro.com> In-Reply-To: <20100810154446.GG52191@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 10.8.2010 17:44, Andrew Sullivan wrote: > In favour of that conclusion are things like qmail& its > interpretation of CNAME; that line of argument could be productive, if > someone wanted to investigate it. qmail delivered email to nic.dname.cz just fine. (Had to go thru all the hoops and loops when building netqmail in chrooted environment. Don't make me do that again...) >> the chairs said in the meeting that only half (?) of the servers support dname. > > So, to clarify, this is an issue with recursive resolvers that do not > support DNAME. I didn't participate in the investigation, so the > details will have to wait until Olafur gets back (unles Ondrej wants > to chime in -- I think he was also involved?). But the key thing is > to note that this is code base, not % of deployed systems. We tested some, but they all were fine using synthetized CNAMEs since they don't support DNSSEC. > Moreover, the systems in question can't support DNSSEC properly, either. Yes, and the argument here is same for BNAME. If those servers didn't get support for DNAME, they will not get support for BNAME either. And if they get proper DNSSEC support (soon) they will likely get a DNAME support. >> section 5.2 of bname draft addresses this problem. >> >> 5.2. BNAME alias algorithm identifiers >> >> >> In order to prevent BNAME-unaware resolvers from attempting to >> validate responses from BNAME-signed zones, this specification >> allocates two new DNSKEY algorithm identifiers. Algorithm Y, DSA- > > Right, you're quite correct for taking me to task for not pointing > this out. But this answer is still pretty bad, because what we're > doing in that case is promoting a barrier to DNSSEC validation: if you > don't have a BNAME-supporting validator, you don't get validation. > This issue is part of why I'm anxious to get guidance. > > Also, the aliases are inadequate. You actually need an alias for > every existing algorithm identifier. That means you need aliases for > all the SHA2 variants and GOST as well (I'm willing to disregard MD5 > because we think it oughtn't to be used anyway). And you need normal and BNAME for every future algorithm. Or do you plan to make BNAME support mandatory for every new algorithm? >> why a synthetic DNAME is necessary? bname draft has never said a synthetic DNAME. > > The BNAME draft indeed does not say that. In case I wasn't clear, the > suggestion is that this approach is needed _instead_ of the way the > BNAME draft is currently written. The point is that this will allow > validation just as well as it works today, so that everyone in the > world needn't upgrade to BNAME support just to get validation of these > resource records. True and I understood that. But do you need BNAME at all, if you make this sort of backward compatibility? Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 12 07:56: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 A2F0728C0ED; Thu, 12 Aug 2010 07:56:41 -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 icUdLERQy9Mu; Thu, 12 Aug 2010 07:56:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 792C33A67B5; Thu, 12 Aug 2010 07:56:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjZ89-0007V6-7V for namedroppers-data0@psg.com; Thu, 12 Aug 2010 14:51:41 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjZ86-0007Ue-Oi for namedroppers@ops.ietf.org; Thu, 12 Aug 2010 14:51:39 +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.4/8.14.3) with ESMTP id o7CEpaKO091984 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 12 Aug 2010 16:51:36 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4C640A78.50008@nlnetlabs.nl> Date: Thu, 12 Aug 2010 16:51:36 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1 MIME-Version: 1.0 To: Namedroppers Subject: [dnsext] rfc2672-dname-bis: NXDOMAIN rcode question X-Enigmail-Version: 1.1.2 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.5 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 12 Aug 2010 16:51:36 +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, The wg wanted the following taken to the mailing list at IETF78. The question is about the (NXDOMAIN) rcode after chasing a CNAME (or DNAME). The spec, rfc1034, currently indicates that recursors return NXDOMAIN in such a case, and that authority servers return NOERROR. Is there a change to dname-bis to be made for this? The discussion does not seem to be very adamant (there were comments heard from the audience that only protocol purists would care about this). Once resolved, the WG chairs intend to resume WGLC. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxkCngACgkQkDLqNwOhpPhiMwCgnNPRnJIMcFP9CeZgoxmla+s+ hEcAnRVRrMzKuDC/9iAhBsLDSvfCsnKA =8UE8 -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Thu Aug 12 08:09: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 0411D3A6972; Thu, 12 Aug 2010 08:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.961 X-Spam-Level: X-Spam-Status: No, score=-99.961 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 LYsgazkvtBVv; Thu, 12 Aug 2010 08:09:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 356D43A6937; Thu, 12 Aug 2010 08:09:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjZMq-000Aeh-9z for namedroppers-data0@psg.com; Thu, 12 Aug 2010 15:06:52 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjZMn-000Ad8-Na for namedroppers@ops.ietf.org; Thu, 12 Aug 2010 15:06:49 +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 942961ECB41D for ; Thu, 12 Aug 2010 15:06:48 +0000 (UTC) Date: Thu, 12 Aug 2010 11:06:46 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] rfc2672-dname-bis: NXDOMAIN rcode question Message-ID: <20100812150646.GE63338@shinkuro.com> References: <4C640A78.50008@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C640A78.50008@nlnetlabs.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Aug 12, 2010 at 04:51:36PM +0200, W.C.A. Wijngaards wrote: > The discussion does not seem to be very adamant (there were comments > heard from the audience that only protocol purists would care about > this). Once resolved, the WG chairs intend to resume WGLC. Speaking as chair, I'll note that if this WG isn't going to be the source of protocol purists, we maybe ought to think about giving up the claim that we're where DNS protocol review happens. There's nothing wrong with being precise about the protocol. Also, if we think that this is a place that the protocol is simply undefined, we can state that. (No hat, however, I'll say that I think it would be a bad idea to say that.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Aug 12 08:41: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 6C7943A67FB; Thu, 12 Aug 2010 08:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 txJZaFx3bCiM; Thu, 12 Aug 2010 08:41:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7F96C3A6407; Thu, 12 Aug 2010 08:41:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjZrI-000GEa-Sp for namedroppers-data0@psg.com; Thu, 12 Aug 2010 15:38:20 +0000 Received: from [2001:4f8:3:bb::111] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjZrG-000GDr-FI for namedroppers@ops.ietf.org; Thu, 12 Aug 2010 15:38:18 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 14057A1031 for ; Thu, 12 Aug 2010 15:38:18 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: [dnsext] rfc2672-dname-bis: NXDOMAIN rcode question In-Reply-To: Your message of "Thu, 12 Aug 2010 16:51:36 +0200." <4C640A78.50008@nlnetlabs.nl> References: <4C640A78.50008@nlnetlabs.nl> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 12 Aug 2010 15:38:18 +0000 Message-ID: <34062.1281627498@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, 12 Aug 2010 16:51:36 +0200 > From: "W.C.A. Wijngaards" > > The spec, rfc1034, currently indicates that recursors return NXDOMAIN in > such a case, and that authority servers return NOERROR. > > Is there a change to dname-bis to be made for this? i think "no change". not just "no change is needed" but "any change would be bad". From owner-namedroppers@ops.ietf.org Thu Aug 12 09:20: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 4E2F53A67FC; Thu, 12 Aug 2010 09:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.355 X-Spam-Level: X-Spam-Status: No, score=-101.355 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 RsmSQnDzmlEd; Thu, 12 Aug 2010 09:20:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 38AF73A67E7; Thu, 12 Aug 2010 09:20:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjaSF-000N4a-Vi for namedroppers-data0@psg.com; Thu, 12 Aug 2010 16:16:31 +0000 Received: from [209.85.214.52] (helo=mail-bw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjaSD-000N36-1j for namedroppers@ops.ietf.org; Thu, 12 Aug 2010 16:16:29 +0000 Received: by bwz17 with SMTP id 17so1460284bwz.11 for ; Thu, 12 Aug 2010 09:16:27 -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:content-type; bh=Wc7ctxbseZOC92+Kqo/1gTubRd/CcR1uKJE8Qq3MJgU=; b=d3Pv4/4ervmaAMRwZiybhTyBeGAUsufbri2Jpvc+e9SJ7sZAfdCoJpo3Xf2+LhhjKf 5UHli00NbHQonrBMEu9c2VEJoGc4lAXFIZNSOyvV6GonPhsNvLEdn8+zpTWmC9qG8cA/ wxtYzgjYeYIHeVJPLBz1EGrs697PxL5nJmJRY= 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=VRSh3GokyldXbju+zjX77BIaRvJGUJVL6/NQtKpVTqJrTZkIyFA9qcAJpVOQ2oM5oh mdeZ6Z7Fb9Zltf9jEXqvhvkEwvX61LBuV6Zjf6DZHq3PtrzGdJ2+fb5QVElx/ZfB4IPU u6JVdHu8+4JzTpGsAnnj1MfFl3zWhpMLcBl0Q= MIME-Version: 1.0 Received: by 10.204.46.23 with SMTP id h23mr224135bkf.75.1281629787459; Thu, 12 Aug 2010 09:16:27 -0700 (PDT) Received: by 10.204.122.7 with HTTP; Thu, 12 Aug 2010 09:16:27 -0700 (PDT) In-Reply-To: <34062.1281627498@nsa.vix.com> References: <4C640A78.50008@nlnetlabs.nl> <34062.1281627498@nsa.vix.com> Date: Thu, 12 Aug 2010 12:16:27 -0400 Message-ID: Subject: Re: [dnsext] rfc2672-dname-bis: NXDOMAIN rcode question From: Donald Eastlake To: Namedroppers Content-Type: multipart/alternative; boundary=0016e6daa86a370f50048da2b0bc Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016e6daa86a370f50048da2b0bc Content-Type: text/plain; charset=ISO-8859-1 So why don't we just adopt https://datatracker.ietf.org/doc/draft-eastlake-dnsext-xnamercode/ with option B selected in Section 3. I wrote this so we could nail this down. Thanks, Donald On Thu, Aug 12, 2010 at 11:38 AM, Paul Vixie wrote: > > Date: Thu, 12 Aug 2010 16:51:36 +0200 > > From: "W.C.A. Wijngaards" > > > > The spec, rfc1034, currently indicates that recursors return NXDOMAIN in > > such a case, and that authority servers return NOERROR. > > > > Is there a change to dname-bis to be made for this? > > i think "no change". not just "no change is needed" but "any change would > be bad". > > --0016e6daa86a370f50048da2b0bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So why don't we just adopt
with option B selected in Sect= ion 3. I wrote this so we could nail this down.

Thanks,
--0016e6daa86a370f50048da2b0bc-- From owner-namedroppers@ops.ietf.org Thu Aug 12 09:44: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 A07E93A6884; Thu, 12 Aug 2010 09:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 eU4VlM96-N3H; Thu, 12 Aug 2010 09:44:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A58E83A6805; Thu, 12 Aug 2010 09:44:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojaps-00019n-S6 for namedroppers-data0@psg.com; Thu, 12 Aug 2010 16:40:56 +0000 Received: from [2001:4f8:3:bb::111] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojapq-00018W-Jy for namedroppers@ops.ietf.org; Thu, 12 Aug 2010 16:40:54 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 47DAFA1019 for ; Thu, 12 Aug 2010 16:40:54 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Namedroppers Subject: Re: [dnsext] rfc2672-dname-bis: NXDOMAIN rcode question In-Reply-To: Your message of "Thu, 12 Aug 2010 12:16:27 -0400." References: <4C640A78.50008@nlnetlabs.nl> <34062.1281627498@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 12 Aug 2010 16:40:54 +0000 Message-ID: <38094.1281631254@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, 12 Aug 2010 12:16:27 -0400 > From: Donald Eastlake > > So why don't we just adopt > https://datatracker.ietf.org/doc/draft-eastlake-dnsext-xnamercode/ > with option B selected in Section 3. I wrote this so we could nail this > down. that doesn't (yet?) describe the difference between RD=1 (where the rcode is final and definitive) vs. RD=0,AA=1 where the rcode is only definitive if ANCOUNT<>0 and the final name is in-bailiwick. From owner-namedroppers@ops.ietf.org Thu Aug 12 10: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 DD4C93A68D4; Thu, 12 Aug 2010 10: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: -96.96 X-Spam-Level: X-Spam-Status: No, score=-96.96 tagged_above=-999 required=5 tests=[AWL=-1.069, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 OWPGNv-rGG+G; Thu, 12 Aug 2010 10:14:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0DDB03A6979; Thu, 12 Aug 2010 10:14:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjbJu-0006j6-6D for namedroppers-data0@psg.com; Thu, 12 Aug 2010 17:11:58 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjbJp-0006hx-Dx for namedroppers@ops.ietf.org; Thu, 12 Aug 2010 17:11:54 +0000 Received: (eyou send program); Fri, 13 Aug 2010 01:11:51 +0800 Message-ID: <481633111.17609@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, 13 Aug 2010 01:11:51 +0800 Message-ID: From: "Jiankang YAO" To: Subject: [dnsext] the method of avoiding signal in bname Date: Fri, 13 Aug 2010 01:12:08 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0070_01CB3A84.8CC07BB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0070_01CB3A84.8CC07BB0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCg0KSSBwcm9wb3NlZCB0aGUgZm9sbG93aW5nIG1ldGhvZCBmb3IgYm5hbWUg dG8gYXZvaWQgdGhlIHNpZ25hbGluZzoNCg0KaWYgdGhlIHF1ZXJ5IGlzIG5vdCBkbnNzZWMgcXVl cnk6DQoNCiAgIElmIHRoZSBvd25lciBuYW1lIG9mIHRoZSBibmFtZSBpcyB0aGUgc3VmZml4IG9m IHRoZSBuYW1lIHF1ZXJ5ZWQgYnV0DQogICBkaWZmZXJlbnQsIHdoZW4gcHJlcGFyaW5nIGEgcmVz cG9uc2UsIGEgc2VydmVyIHBlcmZvcm1pbmcgYSBCTkFNRQ0KICAgc3Vic3RpdHV0aW9uIHdpbGwg aW4gYWxsIGNhc2VzIGluY2x1ZGUgdGhlIHJlbGV2YW50IEJOQU1FIFJSIGluIHRoZQ0KICAgYW5z d2VyIHNlY3Rpb24uICBBIENOQU1FIFJSIGlzIHN5bnRoZXNpemVkIGFuZCBpbmNsdWRlZCBpbiB0 aGUgYW5zd2VyDQogICBzZWN0aW9uLiAgVGhpcyB3aWxsIGhlbHAgdGhlIGNsaWVudCB0byByZWFj aCB0aGUgY29ycmVjdCBETlMgZGF0YS4NCg0KICAgSWYgdGhlIG93bmVyIG5hbWUgb2YgdGhlIGJu YW1lIGlzIHNhbWUgd2l0aCB0aGUgbmFtZSBxdWVyeWVkLCB3aGVuDQogICBwcmVwYXJpbmcgYSBy ZXNwb25zZSwgYSBzZXJ2ZXIgcGVyZm9ybWluZyBhIEJOQU1FIHN1YnN0aXR1dGlvbiB3aWxsDQog ICBub3QgaW5jbHVkZSB0aGUgcmVsZXZhbnQgQk5BTUUgUlIgaW4gdGhlIGFuc3dlciBzZWN0aW9u IHVubGVzcyB0aGUNCiAgIHR5cGUgcXVlcnllZCBpcyBCTkFNRS4gIEEgQ05BTUUgUlIgd2lsbCBi ZSBzeW50aGVzaXplZCBhbmQgaW5jbHVkZWQNCiAgIGluIHRoZSBhbnN3ZXIgc2VjdGlvbiB1bmxl c3MgdGhlIHR5cGUgcXVlcnllZCBpcyBCTkFNRSBvciB0aGUgcXVlcnkNCiAgIGlzIHRoZSBETlNT RUMgcXVlcnkuDQoNCg0KDQppZiB0aGUgcXVlcnkgaXMgdGhlIGRuc3NlYyBxdWVyeToNCg0Kb25s eSB0aGUgYm5hbWUgaXMgcmV0dXJuZWQgdG8gdGhlIHJlc29sdmVycyBmcm9tIHRoZSBzZXJ2ZXJz Lg0KDQp0aGlzIGFzc3VtZXMgdGhhdDogaWYgdGhlIHJlc29sdmVycyBkb2VzIG5vdCByZWNvZ25p emUgdGhlIGJuYW1lIGJ1dCB3YW50IGRuc3NlYywgdGhlIHN5bnRoZXNpemVkDQpjbmFtZSBpcyBu b3QgdXNlZnVsIGZvciB0aGVtLg0KaWYgdGhlIHJlc29sdmVycyBkb2VzICByZWNvZ25pemUgdGhl IGJuYW1lIGFuZCB3YW50IGRuc3NlYywgdGhlIHJlc29sdmVycyBjYW4gZG8gdGhlIA0KbmV4dCBx dWVyeSB3aXRob3V0IHRoZSBzeW50aGVzaXplZA0KY25hbWUuDQoNCg0KdGhyb3VnaCB0aGUgbWV0 aG9kIGFib3ZlLCB0aGVyZSB3aWxsIG5ldmVyIGlzc3VlIGNuYW1lIGFuZCBibmFtZSB0b2dldGhl ciB3aXRoIHRoZSBzYW1lIG93bmVyIG5hbWUuDQoNCg0KDQppZiAgYm5hbWUgc3RpbGwgbmVlZHMg dGhlIGFsaWFzIGFsZ29yaXRobSwgaXQgd2lsbCBmb2xsb3cgdGhlIGRpZmluaXRvbiBvZiBkcmFm dC15YW8tZG5zZXh0LWFsaWFzLWFsZ29yaXRobS0wMC50eHQgdG8gYXZvaWQgYWRkaW5nDQp0b28g bWFueSBhbGlhcyBhbGdvcml0aG1zIGZvciB0aGUgbmV3IHJydHlwZXMuDQoNCmFueSBjb21tZW50 cyBhcmUgd2VsY29tZS4NCg0KdGhhbmtzIGEgbG90Lg0KDQoNCkppYW5rYW5nIFlhbw0K ------=_NextPart_000_0070_01CB3A84.8CC07BB0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE4OTI4Ij4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jY2NlOGNmPg0KPERJVj48Rk9OVCBzaXplPTI+RGVhciBhbGwsPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSBwcm9wb3Nl ZCB0aGUgZm9sbG93aW5nIG1ldGhvZCBmb3IgYm5hbWUgdG8gYXZvaWQgdGhlIA0Kc2lnbmFsaW5n OjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPmlmIHRoZSBxdWVyeSBpcyBub3QgZG5zc2VjIHF1ZXJ5OjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7 Jm5ic3A7IElmIHRoZSBvd25lciBuYW1lIG9mIHRoZSBibmFtZSBpcyB0aGUgc3VmZml4IG9mIHRo ZSBuYW1lIA0KcXVlcnllZCBidXQ8QlI+Jm5ic3A7Jm5ic3A7IGRpZmZlcmVudCwgd2hlbiBwcmVw YXJpbmcgYSByZXNwb25zZSwgYSBzZXJ2ZXIgDQpwZXJmb3JtaW5nIGEgQk5BTUU8QlI+Jm5ic3A7 Jm5ic3A7IHN1YnN0aXR1dGlvbiB3aWxsIGluIGFsbCBjYXNlcyBpbmNsdWRlIHRoZSANCnJlbGV2 YW50IEJOQU1FIFJSIGluIHRoZTxCUj4mbmJzcDsmbmJzcDsgYW5zd2VyIHNlY3Rpb24uJm5ic3A7 IEEgQ05BTUUgUlIgaXMgDQpzeW50aGVzaXplZCBhbmQgaW5jbHVkZWQgaW4gdGhlIGFuc3dlcjxC Uj4mbmJzcDsmbmJzcDsgc2VjdGlvbi4mbmJzcDsgVGhpcyB3aWxsIA0KaGVscCB0aGUgY2xpZW50 IHRvIHJlYWNoIHRoZSBjb3JyZWN0IEROUyBkYXRhLjxCUj48QlI+Jm5ic3A7Jm5ic3A7IElmIHRo ZSBvd25lciANCm5hbWUgb2YgdGhlIGJuYW1lIGlzIHNhbWUgd2l0aCB0aGUgbmFtZSBxdWVyeWVk LCB3aGVuPEJSPiZuYnNwOyZuYnNwOyBwcmVwYXJpbmcgDQphIHJlc3BvbnNlLCBhIHNlcnZlciBw ZXJmb3JtaW5nIGEgQk5BTUUgc3Vic3RpdHV0aW9uIHdpbGw8QlI+Jm5ic3A7Jm5ic3A7IG5vdCAN CmluY2x1ZGUgdGhlIHJlbGV2YW50IEJOQU1FIFJSIGluIHRoZSBhbnN3ZXIgc2VjdGlvbiB1bmxl c3MgdGhlPEJSPiZuYnNwOyZuYnNwOyANCnR5cGUgcXVlcnllZCBpcyBCTkFNRS4mbmJzcDsgQSBD TkFNRSBSUiB3aWxsIGJlIHN5bnRoZXNpemVkIGFuZCANCmluY2x1ZGVkPEJSPiZuYnNwOyZuYnNw OyBpbiB0aGUgYW5zd2VyIHNlY3Rpb24gdW5sZXNzIHRoZSB0eXBlIHF1ZXJ5ZWQgaXMgQk5BTUUg DQpvciB0aGUgcXVlcnk8QlI+Jm5ic3A7Jm5ic3A7IGlzIHRoZSBETlNTRUMgcXVlcnkuPC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5pZiB0aGUgcXVlcnkgaXMgdGhlIGRuc3NlYyBxdWVyeTo8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj5vbmx5IHRoZSBibmFtZSBpcyByZXR1cm5lZCB0byB0aGUgcmVzb2x2ZXJz IGZyb20gdGhlIA0Kc2VydmVycy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj50aGlzIGFzc3VtZXMgdGhhdDogaWYg dGhlIHJlc29sdmVycyBkb2VzIG5vdCByZWNvZ25pemUgdGhlIA0KYm5hbWUgYnV0IHdhbnQgZG5z c2VjLCB0aGUgPC9GT05UPjxGT05UIHNpemU9Mz5zeW50aGVzaXplZDwvRk9OVD48L0RJVj4NCjxE SVY+Y25hbWUgaXMgbm90IHVzZWZ1bCBmb3IgdGhlbS48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PmlmIHRoZSByZXNvbHZlcnMgZG9lcyZuYnNwOyByZWNvZ25pemUgdGhlIGJuYW1lJm5ic3A7YW5k IHdhbnQgDQpkbnNzZWMsIHRoZSByZXNvbHZlcnMgY2FuIGRvIHRoZSA8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj5uZXh0IHF1ZXJ5IHdpdGhvdXQgdGhlIDwvRk9OVD48Rk9OVCANCnNp emU9Mz5zeW50aGVzaXplZDwvRk9OVD48L0RJVj4NCjxESVY+Y25hbWUuPC9ESVY+DQo8RElWPjxG T05UIHNpemU9Mj48L0ZPTlQ+PEZPTlQgc2l6ZT0yPjwvRk9OVD48Rk9OVCBzaXplPTI+PC9GT05U PjxGT05UIA0Kc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPnRocm91Z2ggdGhlIG1ldGhvZCBh Ym92ZSwgdGhlcmUgd2lsbCBuZXZlciBpc3N1ZSBjbmFtZSBhbmQgDQpibmFtZSB0b2dldGhlciB3 aXRoIHRoZSBzYW1lIG93bmVyIG5hbWUuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmlmJm5ic3A7IGJuYW1lIHN0 aWxsIG5lZWRzIHRoZSBhbGlhcyBhbGdvcml0aG0sIGl0IHdpbGwgZm9sbG93IA0KdGhlIGRpZmlu aXRvbiBvZiA8Rk9OVCBzaXplPTM+ZHJhZnQteWFvLWRuc2V4dC1hbGlhcy1hbGdvcml0aG0tMDAu dHh0IHRvIGF2b2lkIA0KYWRkaW5nPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+dG9vIG1hbnkg YWxpYXMgYWxnb3JpdGhtcyBmb3IgdGhlIG5ldyBycnR5cGVzLjwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmFueSBjb21tZW50cyBhcmUgd2VsY29tZS48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj50aGFua3MgYSBsb3QuPC9ESVY+DQo8RElWPjxCUj48L0RJVj48L0ZPTlQ+DQo8RElW PjxGT05UIHNpemU9Mj5KaWFua2FuZyBZYW88L0ZPTlQ+PEJSPjwvRElWPjwvQk9EWT48L0hUTUw+ DQo= ------=_NextPart_000_0070_01CB3A84.8CC07BB0-- From webmailteam96@4u.com.gh Thu Aug 12 19:11: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 72C283A6A85 for ; Thu, 12 Aug 2010 19:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.483 X-Spam-Level: * X-Spam-Status: No, score=1.483 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQ8jswSkEMRt for ; Thu, 12 Aug 2010 19:11:04 -0700 (PDT) Received: from isp6.4u.com.gh (isp6.4u.com.gh [80.87.72.6]) by core3.amsl.com (Postfix) with SMTP id EDAB53A6A81 for ; Thu, 12 Aug 2010 19:11:02 -0700 (PDT) Received: from webmail.4u.com.gh (isp6.4u.com.gh [80.87.72.6]) by isp6.4u.com.gh (Postfix) with ESMTP id 81A89C7E7B5; Fri, 13 Aug 2010 02:05:57 +0000 (GMT) Received: from 41.210.7.92 (SquirrelMail authenticated user prisonmin) by webmail.4u.com.gh with HTTP; Thu, 12 Aug 2010 22:05:57 -0400 (EDT) Message-ID: Date: Thu, 12 Aug 2010 22:05:57 -0400 (EDT) Subject: Attn: Webmail Users, YOUR ACCOUNT WILL BE BLOCKED. From: "Webmail Team" Reply-To: webmailteam96@yahoo.com.hk User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; Content-Transfer-Encoding: quoted-printable Attn: Webmail Users, We regret to announce to you that we will be making some vital maintenance on our website. During this process you might have login problems in signing into your Online account, but to prevent this you have to confirm your account immediately after you receive this notification. To confirm and to keep your account active during and after this process, please reply to this message with the below account informations to webmailteam96@yahoo.com.hk Failure to do this might cause a permanent deactivation of your user account from our database to enable us create more spaces for new users. YOUR ACCOUNT CONFIRMATION Name: E-mail ID: E-mail Password: Date of birth: Your account shall remain active after you have successfully confirmed your account details to the email address below. Thanks for bearing with us. Webmail Team webmailteam96@yahoo.com.hk Warning Code: 002671 NOTE: ALL RESPONSES SHOULD BE FORWARDED TO: webmailteam96@yahoo.com.hk From webmailteam96@4u.com.gh Thu Aug 12 19:11: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 5AEA83A6A84 for ; Thu, 12 Aug 2010 19:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.483 X-Spam-Level: * X-Spam-Status: No, score=1.483 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmNBsc+5EmPK for ; Thu, 12 Aug 2010 19:11:09 -0700 (PDT) Received: from isp6.4u.com.gh (isp6.4u.com.gh [80.87.72.6]) by core3.amsl.com (Postfix) with SMTP id C6D563A6A83 for ; Thu, 12 Aug 2010 19:11:05 -0700 (PDT) Received: from webmail.4u.com.gh (isp6.4u.com.gh [80.87.72.6]) by isp6.4u.com.gh (Postfix) with ESMTP id 81A89C7E7B5; Fri, 13 Aug 2010 02:05:57 +0000 (GMT) Received: from 41.210.7.92 (SquirrelMail authenticated user prisonmin) by webmail.4u.com.gh with HTTP; Thu, 12 Aug 2010 22:05:57 -0400 (EDT) Message-ID: Date: Thu, 12 Aug 2010 22:05:57 -0400 (EDT) Subject: Attn: Webmail Users, YOUR ACCOUNT WILL BE BLOCKED. From: "Webmail Team" Reply-To: webmailteam96@yahoo.com.hk User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; Content-Transfer-Encoding: quoted-printable Attn: Webmail Users, We regret to announce to you that we will be making some vital maintenance on our website. During this process you might have login problems in signing into your Online account, but to prevent this you have to confirm your account immediately after you receive this notification. To confirm and to keep your account active during and after this process, please reply to this message with the below account informations to webmailteam96@yahoo.com.hk Failure to do this might cause a permanent deactivation of your user account from our database to enable us create more spaces for new users. YOUR ACCOUNT CONFIRMATION Name: E-mail ID: E-mail Password: Date of birth: Your account shall remain active after you have successfully confirmed your account details to the email address below. Thanks for bearing with us. Webmail Team webmailteam96@yahoo.com.hk Warning Code: 002671 NOTE: ALL RESPONSES SHOULD BE FORWARDED TO: webmailteam96@yahoo.com.hk From owner-namedroppers@ops.ietf.org Thu Aug 12 19:17: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 5CCD43A6A83; Thu, 12 Aug 2010 19:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.803 X-Spam-Level: **** X-Spam-Status: No, score=4.803 tagged_above=-999 required=5 tests=[AWL=-1.942, BAYES_40=-0.185, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iyMjMJFAi6A; Thu, 12 Aug 2010 19:17:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D2A843A6A89; Thu, 12 Aug 2010 19:17:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjjjX-000NnX-P1 for namedroppers-data0@psg.com; Fri, 13 Aug 2010 02:10:59 +0000 Received: from [2001:500:60::65] (helo=mx.ams1.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjjjU-000NnC-Ni for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 02:10:57 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 5BBF05F98F2; Fri, 13 Aug 2010 02:10:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 16750E6030; Fri, 13 Aug 2010 02:10:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 75ACE2D5113; Fri, 13 Aug 2010 12:10:34 +1000 (EST) To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Cc: Andrew Sullivan , namedroppers@ops.ietf.org From: Mark Andrews References: <201008042142.o74LgRap031934@cichlid.raleigh.ibm.com> <05B243F724B2284986522B6ACD0504D7D3444A2AAF@EXVPMBX100-1.exc.icann.org> <20100804230904.GB4034@farside.isc.org> <05B243F724B2284986522B6ACD0504D7D3444A2CF6@EXVPMBX100-1.exc.icann.org> <20100805182146.GI38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D00@EXVPMBX100-1.exc.icann.org> <20100805183608.GJ38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D1B@EXVPMBX100-1.exc.icann.org> <20100810141322.GD52191@shinkuro.com> <3F9D6BF0A3BA40D5BA4044B7DC347FAA@LENOVO47E041CF> <20100810154446.GG52191@shinkuro.com> <4C63F9DF.4010104@nic.cz> Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable? In-reply-to: Your message of "Thu, 12 Aug 2010 15:40:47 +0200." <4C63F9DF.4010104@nic.cz> Date: Fri, 13 Aug 2010 12:10:34 +1000 Message-Id: <20100813021034.75ACE2D5113@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4C63F9DF.4010104@nic.cz>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= writes: > On 10.8.2010 17:44, Andrew Sullivan wrote: > > In favour of that conclusion are things like qmail& its > > interpretation of CNAME; that line of argument could be productive, if > > someone wanted to investigate it. > > qmail delivered email to nic.dname.cz just fine. (Had to go thru all > the hoops and loops when building netqmail in chrooted environment. > Don't make me do that again...) > > >> the chairs said in the meeting that only half (?) of the servers support d > name. > > > > So, to clarify, this is an issue with recursive resolvers that do not > > support DNAME. I didn't participate in the investigation, so the > > details will have to wait until Olafur gets back (unles Ondrej wants > > to chime in -- I think he was also involved?). But the key thing is > > to note that this is code base, not % of deployed systems. > > We tested some, but they all were fine using synthetized CNAMEs since > they don't support DNSSEC. > > > Moreover, the systems in question can't support DNSSEC properly, either. > > Yes, and the argument here is same for BNAME. If those servers didn't > get support for DNAME, they will not get support for BNAME either. And > if they get proper DNSSEC support (soon) they will likely get a DNAME > support. > > >> section 5.2 of bname draft addresses this problem. > >> > >> 5.2. BNAME alias algorithm identifiers > >> > >> > >> In order to prevent BNAME-unaware resolvers from attempting to > >> validate responses from BNAME-signed zones, this specification > >> allocates two new DNSKEY algorithm identifiers. Algorithm Y, DSA- > > > > Right, you're quite correct for taking me to task for not pointing > > this out. But this answer is still pretty bad, because what we're > > doing in that case is promoting a barrier to DNSSEC validation: if you > > don't have a BNAME-supporting validator, you don't get validation. > > This issue is part of why I'm anxious to get guidance. > > > > Also, the aliases are inadequate. You actually need an alias for > > every existing algorithm identifier. That means you need aliases for > > all the SHA2 variants and GOST as well (I'm willing to disregard MD5 > > because we think it oughtn't to be used anyway). > > And you need normal and BNAME for every future algorithm. Or do you > plan to make BNAME support mandatory for every new algorithm? I would expect it to be like NSEC3, new algorithms would also indicate BNAME support. If we had had known enough about DNSSEC DNAME's original introduction would have added algorithm aliases. The type code roll allowed us to do that a slightly different way. > >> why a synthetic DNAME is necessary? bname draft has never said a synthetic > DNAME. > > > > The BNAME draft indeed does not say that. In case I wasn't clear, the > > suggestion is that this approach is needed _instead_ of the way the > > BNAME draft is currently written. The point is that this will allow > > validation just as well as it works today, so that everyone in the > > world needn't upgrade to BNAME support just to get validation of these > > resource records. > > True and I understood that. But do you need BNAME at all, if you make > this sort of backward compatibility? > > Ondrej > -- > OndÅ™ej Surý > vedoucí výzkumu/Head of R&D department > ------------------------------------------- > 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 > ------------------------------------------- > -- 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 Aug 12 21:55: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 8C4723A688B; Thu, 12 Aug 2010 21:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 AIPlftCEB9oA; Thu, 12 Aug 2010 21:55:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 377353A6918; Thu, 12 Aug 2010 21:55:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjmF6-000Dq1-Ds for namedroppers-data0@psg.com; Fri, 13 Aug 2010 04:51:44 +0000 Received: from [209.85.160.180] (helo=mail-gy0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjmF3-000Dpk-HU for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 04:51:41 +0000 Received: by gye5 with SMTP id 5so1163862gye.11 for ; Thu, 12 Aug 2010 21:51:38 -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=2q/fYQas47ssBWQ5mlhufCtHWHdLQ1U6XvNjCVLYQYo=; b=Echw6lJly+fMoOOK260mPNWUWlo0Divf9RumBlpDVghSOWXuN3AmwZJycstMOPP65t UooIvvP1RcmGX3gnBse2ZmCcLpm5avMjUGdTW7TURGqUklMBAK61CinAMAV9OvLduzfO zk0usy3hVuu6+VFzooQj5EKLywx3hdYY3VbKs= 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=GAvf8RWT/BR+VIJ5Ynee8zQdQ1CTo3ens/nIGkmCsSVDABsQ6kiJuC3XVuBF60X7Jy iWSArnyolJiMBflmIokHieIHp4HzDI5sbUjKvJ2mIVI4LdIzgJacbxHjbOrF7ldhcCk6 GhXRNDjssuzNjHmyXwJdE02OzlEeNEKSLsKoM= MIME-Version: 1.0 Received: by 10.231.59.15 with SMTP id j15mr939488ibh.172.1281675096146; Thu, 12 Aug 2010 21:51:36 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Thu, 12 Aug 2010 21:51:36 -0700 (PDT) In-Reply-To: <20100813021034.75ACE2D5113@drugs.dv.isc.org> References: <201008042142.o74LgRap031934@cichlid.raleigh.ibm.com> <05B243F724B2284986522B6ACD0504D7D3444A2AAF@EXVPMBX100-1.exc.icann.org> <20100804230904.GB4034@farside.isc.org> <05B243F724B2284986522B6ACD0504D7D3444A2CF6@EXVPMBX100-1.exc.icann.org> <20100805182146.GI38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D00@EXVPMBX100-1.exc.icann.org> <20100805183608.GJ38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D1B@EXVPMBX100-1.exc.icann.org> <20100810141322.GD52191@shinkuro.com> <3F9D6BF0A3BA40D5BA4044B7DC347FAA@LENOVO47E041CF> <20100810154446.GG52191@shinkuro.com> <4C63F9DF.4010104@nic.cz> <20100813021034.75ACE2D5113@drugs.dv.isc.org> Date: Fri, 13 Aug 2010 00:51:36 -0400 Message-ID: Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable? From: Phillip Hallam-Baker To: Mark Andrews Cc: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , Andrew Sullivan , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-2 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: So if a zone contains a DNAME, a resolver that does not understand it simply has to treat the zone as unsigned? That might work. But only if any change is made before validation is pushed out to the edge and before there are applications that rely on DNSSEC being there. On Thu, Aug 12, 2010 at 10:10 PM, Mark Andrews wrote: > > In message <4C63F9DF.4010104@nic.cz>, =3D?UTF-8?B?T25kxZllaiBTdXLDvQ=3D= =3D?=3D writes: >> On 10.8.2010 17:44, Andrew Sullivan wrote: >> > In favour of that conclusion are things like qmail& =A0its >> > interpretation of CNAME; that line of argument could be productive, if >> > someone wanted to investigate it. >> >> qmail delivered email to nic.dname.cz just fine. =A0(Had to go thru all >> the hoops and loops when building netqmail in chrooted environment. >> Don't make me do that again...) >> >> >> the chairs said in the meeting that only half (?) of the servers supp= ort d >> name. >> > >> > So, to clarify, this is an issue with recursive resolvers that do not >> > support DNAME. =A0I didn't participate in the investigation, so the >> > details will have to wait until Olafur gets back (unles Ondrej wants >> > to chime in -- I think he was also involved?). =A0But the key thing is >> > to note that this is code base, not % of deployed systems. >> >> We tested some, but they all were fine using synthetized CNAMEs since >> they don't support DNSSEC. >> >> > Moreover, the systems in question can't support DNSSEC properly, eithe= r. >> >> Yes, and the argument here is same for BNAME. =A0If those servers didn't >> get support for DNAME, they will not get support for BNAME either. =A0An= d >> if they get proper DNSSEC support (soon) they will likely get a DNAME >> support. >> >> >> section 5.2 of bname draft addresses this problem. >> >> >> >> 5.2. =A0BNAME alias algorithm identifiers >> >> >> >> >> >> =A0 =A0 In order to prevent BNAME-unaware resolvers from attempting t= o >> >> =A0 =A0 validate responses from BNAME-signed zones, this specificatio= n >> >> =A0 =A0 allocates two new DNSKEY algorithm identifiers. =A0Algorithm = Y, DSA- >> > >> > Right, you're quite correct for taking me to task for not pointing >> > this out. =A0But this answer is still pretty bad, because what we're >> > doing in that case is promoting a barrier to DNSSEC validation: if you >> > don't have a BNAME-supporting validator, you don't get validation. >> > This issue is part of why I'm anxious to get guidance. >> > >> > Also, the aliases are inadequate. =A0You actually need an alias for >> > every existing algorithm identifier. =A0That means you need aliases fo= r >> > all the SHA2 variants and GOST as well (I'm willing to disregard MD5 >> > because we think it oughtn't to be used anyway). >> >> And you need normal and BNAME for every future algorithm. =A0Or do you >> plan to make BNAME support mandatory for every new algorithm? > > I would expect it to be like NSEC3, new algorithms would also indicate > BNAME support. =A0If we had had known enough about DNSSEC DNAME's origina= l > introduction would have added algorithm aliases. =A0The type code roll > allowed us to do that a slightly different way. > >> >> why a synthetic DNAME is necessary? bname draft has never said a synt= hetic >> =A0DNAME. >> > >> > The BNAME draft indeed does not say that. =A0In case I wasn't clear, t= he >> > suggestion is that this approach is needed _instead_ of the way the >> > BNAME draft is currently written. =A0The point is that this will allow >> > validation just as well as it works today, so that everyone in the >> > world needn't upgrade to BNAME support just to get validation of these >> > resource records. >> >> True and I understood that. =A0But do you need BNAME at all, if you make >> this sort of backward compatibility? >> >> Ondrej >> -- >> =A0 Ond=F8ej Sur=FD >> =A0 vedouc=ED v=FDzkumu/Head of R&D department >> =A0 ------------------------------------------- >> =A0 CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC >> =A0 Americka 23, 120 00 Praha 2, Czech Republic >> =A0 mailto:ondrej.sury@nic.cz =A0 =A0http://nic.cz/ >> =A0 tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112 >> =A0 ------------------------------------------- >> > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org > > --=20 Website: http://hallambaker.com/ From dnsext-archive@ietf.org Thu Aug 12 22:54: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 54C333A691B for ; Thu, 12 Aug 2010 22:54:25 -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): Subject: ...-archive@ietf.org VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -18.319 X-Spam-Level: X-Spam-Status: No, score=-18.319 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FB_GET_MEDS=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_STATIC=1.172, 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_XBL=3.033, SUBJECT_NEEDS_ENCODING=0.001, TVD_QUAL_MEDS=3.568, TVD_RCVD_IP=1.931, 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 hQ11AZUSL3po for ; Thu, 12 Aug 2010 22:54:19 -0700 (PDT) Received: from 195-248-168-240.static.vega-ua.net (195-248-168-240.static.vega-ua.net [195.248.168.240]) by core3.amsl.com (Postfix) with ESMTP id 0418C3A68E6 for ; Thu, 12 Aug 2010 22:54:18 -0700 (PDT) Message-Id: <20100813055506.2183.qmail@195-248-168-240.static.vega-ua.net> To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org VIAGRA ® Official Seller -36% From: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 12 Aug 2010 22:54:18 -0700 (PDT) Dear dnsext-archive@ietf.org Get ready to make her happy. Discount price store: ID05301 http://turnrope.ru We do guarantee high-quality medications, instant worldwide delivery and friendly support. © 2001-2010 Pfizer Inc. All rights reserved. From dnsext-archive@lists.ietf.org Thu Aug 12 22:54: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 8B2F83A68E6 for ; Thu, 12 Aug 2010 22:54:25 -0700 (PDT) X-Quarantine-ID: <2+UTWr+7V-eF> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...ve@lists.ietf.org VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -18.319 X-Spam-Level: X-Spam-Status: No, score=-18.319 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FB_GET_MEDS=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_STATIC=1.172, 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_XBL=3.033, SUBJECT_NEEDS_ENCODING=0.001, TVD_QUAL_MEDS=3.568, TVD_RCVD_IP=1.931, 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 2+UTWr+7V-eF for ; Thu, 12 Aug 2010 22:54:19 -0700 (PDT) Received: from 195-248-168-240.static.vega-ua.net (195-248-168-240.static.vega-ua.net [195.248.168.240]) by core3.amsl.com (Postfix) with ESMTP id 031BD3A6892 for ; Thu, 12 Aug 2010 22:54:18 -0700 (PDT) Message-Id: <20100813055506.2466.qmail@195-248-168-240.static.vega-ua.net> To: dnsext-archive@lists.ietf.org Subject: dnsext-archive@lists.ietf.org VIAGRA ® Official Seller -36% From: dnsext-archive@lists.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 12 Aug 2010 22:54:18 -0700 (PDT) Dear dnsext-archive@lists.ietf.org Get ready to make her happy. Discount price store: ID05301 http://turnrope.ru We do guarantee high-quality medications, instant worldwide delivery and friendly support. © 2001-2010 Pfizer Inc. All rights reserved. From owner-namedroppers@ops.ietf.org Fri Aug 13 00:37: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 5796D3A694D; Fri, 13 Aug 2010 00:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.302 X-Spam-Level: X-Spam-Status: No, score=-101.302 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, J_CHICKENPOX_23=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 aeC1-Yowjlr8; Fri, 13 Aug 2010 00:37:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA7983A681B; Fri, 13 Aug 2010 00:37:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjojO-0005Rx-MK for namedroppers-data0@psg.com; Fri, 13 Aug 2010 07:31:10 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjojL-0005Rf-OC for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 07:31:07 +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 27461734429; Fri, 13 Aug 2010 09:31:05 +0200 (CEST) Message-ID: <4C64F4B8.6040104@nic.cz> Date: Fri, 13 Aug 2010 09:31:04 +0200 From: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Phillip Hallam-Baker CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable? References: <201008042142.o74LgRap031934@cichlid.raleigh.ibm.com> <05B243F724B2284986522B6ACD0504D7D3444A2AAF@EXVPMBX100-1.exc.icann.org> <20100804230904.GB4034@farside.isc.org> <05B243F724B2284986522B6ACD0504D7D3444A2CF6@EXVPMBX100-1.exc.icann.org> <20100805182146.GI38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D00@EXVPMBX100-1.exc.icann.org> <20100805183608.GJ38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D1B@EXVPMBX100-1.exc.icann.org> <20100810141322.GD52191@shinkuro.com> <3F9D6BF0A3BA40D5BA4044B7DC347FAA@LENOVO47E041CF> <20100810154446.GG52191@shinkuro.com> <4C63F9DF.4010104@nic.cz> <20100813021034.75ACE2D5113@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; 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 13.8.2010 06:51, Phillip Hallam-Baker wrote: > So if a zone contains a DNAME, a resolver that does not understand it > simply has to treat the zone as unsigned? No. Currently the requirement is - if you do DNSSEC, you have to do DNAME. > That might work. No, that wouldn't work. That would mean that you can just spoof DNAME and you can spoof whole zone. O. -- Ondøej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 13 00:47: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 93A5E3A6964; Fri, 13 Aug 2010 00:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.602 X-Spam-Level: X-Spam-Status: No, score=-100.602 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_05=-1.11, J_CHICKENPOX_23=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 s6vHE6apuvTD; Fri, 13 Aug 2010 00:46:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9A4E33A694D; Fri, 13 Aug 2010 00:46:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjovG-0006ip-Nl for namedroppers-data0@psg.com; Fri, 13 Aug 2010 07:43:26 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjovD-0006iZ-R7 for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 07:43:24 +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 D9819734429; Fri, 13 Aug 2010 09:43:22 +0200 (CEST) Message-ID: <4C64F799.4050500@nic.cz> Date: Fri, 13 Aug 2010 09:43:21 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Mark Andrews CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable? References: <201008042142.o74LgRap031934@cichlid.raleigh.ibm.com> <05B243F724B2284986522B6ACD0504D7D3444A2AAF@EXVPMBX100-1.exc.icann.org> <20100804230904.GB4034@farside.isc.org> <05B243F724B2284986522B6ACD0504D7D3444A2CF6@EXVPMBX100-1.exc.icann.org> <20100805182146.GI38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D00@EXVPMBX100-1.exc.icann.org> <20100805183608.GJ38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D1B@EXVPMBX100-1.exc.icann.org> <20100810141322.GD52191@shinkuro.com> <3F9D6BF0A3BA40D5BA4044B7DC347FAA@LENOVO47E041CF> <20100810154446.GG52191@shinkuro.com> <4C63F9DF.4010104@nic.cz> <20100813021034.75ACE2D5113@drugs.dv.isc.org> In-Reply-To: <20100813021034.75ACE2D5113@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 13.8.2010 04:10, Mark Andrews wrote: > In message<4C63F9DF.4010104@nic.cz>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= writes: >> On 10.8.2010 17:44, Andrew Sullivan wrote: >>> In favour of that conclusion are things like qmail& its >>> interpretation of CNAME; that line of argument could be productive, if >>> someone wanted to investigate it. >> >> qmail delivered email to nic.dname.cz just fine. (Had to go thru all >> the hoops and loops when building netqmail in chrooted environment. >> Don't make me do that again...) >> >>>> the chairs said in the meeting that only half (?) of the servers support d >> name. >>> >>> So, to clarify, this is an issue with recursive resolvers that do not >>> support DNAME. I didn't participate in the investigation, so the >>> details will have to wait until Olafur gets back (unles Ondrej wants >>> to chime in -- I think he was also involved?). But the key thing is >>> to note that this is code base, not % of deployed systems. >> >> We tested some, but they all were fine using synthetized CNAMEs since >> they don't support DNSSEC. >> >>> Moreover, the systems in question can't support DNSSEC properly, either. >> >> Yes, and the argument here is same for BNAME. If those servers didn't >> get support for DNAME, they will not get support for BNAME either. And >> if they get proper DNSSEC support (soon) they will likely get a DNAME >> support. >> >>>> section 5.2 of bname draft addresses this problem. >>>> >>>> 5.2. BNAME alias algorithm identifiers >>>> >>>> >>>> In order to prevent BNAME-unaware resolvers from attempting to >>>> validate responses from BNAME-signed zones, this specification >>>> allocates two new DNSKEY algorithm identifiers. Algorithm Y, DSA- >>> >>> Right, you're quite correct for taking me to task for not pointing >>> this out. But this answer is still pretty bad, because what we're >>> doing in that case is promoting a barrier to DNSSEC validation: if you >>> don't have a BNAME-supporting validator, you don't get validation. >>> This issue is part of why I'm anxious to get guidance. >>> >>> Also, the aliases are inadequate. You actually need an alias for >>> every existing algorithm identifier. That means you need aliases for >>> all the SHA2 variants and GOST as well (I'm willing to disregard MD5 >>> because we think it oughtn't to be used anyway). >> >> And you need normal and BNAME for every future algorithm. Or do you >> plan to make BNAME support mandatory for every new algorithm? > > I would expect it to be like NSEC3, new algorithms would also indicate > BNAME support. If we had had known enough about DNSSEC DNAME's original > introduction would have added algorithm aliases. The type code roll > allowed us to do that a slightly different way. That might work now. But I see it as a bad precedent. If we setup this as a usual way how to cope, we would have to create algorithm dupes for every (non deprecated) algorithm to the date. This might grow huge. Fortunately you don't have to do Cartesian product for all signaling, but you can say that new signal also includes all preceding ones (ie. support for BNAME includes support for DNAME and NSEC3). If this gets ever created we need something like a table with algorithm numbers as lines and standards included in columns with fields indicating support. It's already mess that you have some algorithms named -NSEC3- and some not (SHA-2 family, GOST) and they all include NSEC3 support. Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 13 01:26: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 90D523A6966; Fri, 13 Aug 2010 01:26:17 -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: -97.343 X-Spam-Level: X-Spam-Status: No, score=-97.343 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.041, MSGID_FROM_MTA_HEADER=0.803, 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 bvlolajZaKwF; Fri, 13 Aug 2010 01:26:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 121F83A6976; Fri, 13 Aug 2010 01:26:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjpXl-000BNt-KA for namedroppers-data0@psg.com; Fri, 13 Aug 2010 08:23:13 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjpXi-000BNH-6S for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 08:23:10 +0000 Received: (eyou send program); Fri, 13 Aug 2010 16:23:08 +0800 Message-ID: <481687788.26943@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, 13 Aug 2010 16:23:08 +0800 Message-ID: <1977A2EDDA384FB38D49077900DECDE4@LENOVO47E041CF> From: "Jiankang YAO" To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , "Mark Andrews" Cc: References: <201008042142.o74LgRap031934@cichlid.raleigh.ibm.com> <05B243F724B2284986522B6ACD0504D7D3444A2AAF@EXVPMBX100-1.exc.icann.org> <20100804230904.GB4034@farside.isc.org> <05B243F724B2284986522B6ACD0504D7D3444A2CF6@EXVPMBX100-1.exc.icann.org> <20100805182146.GI38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D00@EXVPMBX100-1.exc.icann.org> <20100805183608.GJ38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D1B@EXVPMBX100-1.exc.icann.org> <20100810141322.GD52191@shinkuro.com> <3F9D6BF0A3BA40D5BA4044B7DC347FAA@LENOVO47E041CF> <20100810154446.GG52191@shinkuro.com> <4C63F9DF.4010104@nic.cz> <20100813021034.75ACE2D5113@drugs.dv.isc.org> <481686271.26970@cnnic.cn> Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable? Date: Fri, 13 Aug 2010 16:23:27 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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+DQpTZW50OiBGcmlkYXksIEF1Z3VzdCAxMywg MjAxMCAzOjQzIFBNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gRG9lcyBETlNTRUMgbWVhbiBCTkFN RSBpcyB1bmRlcGxveWFibGU/DQoNCg0KPiBPbiAxMy44LjIwMTAgMDQ6MTAsIE1hcmsgQW5kcmV3 cyB3cm90ZToNCj4+IEluIG1lc3NhZ2U8NEM2M0Y5REYuNDAxMDEwNEBuaWMuY3o+LCA9P1VURi04 P0I/VDI1a3habGxhaUJUZFhMRHZRPT0/PSB3cml0ZXM6DQo+Pj4gT24gMTAuOC4yMDEwIDE3OjQ0 LCBBbmRyZXcgU3VsbGl2YW4gd3JvdGU6DQo+Pj4+IEluIGZhdm91ciBvZiB0aGF0IGNvbmNsdXNp b24gYXJlIHRoaW5ncyBsaWtlIHFtYWlsJiAgIGl0cw0KPj4+PiBpbnRlcnByZXRhdGlvbiBvZiBD TkFNRTsgdGhhdCBsaW5lIG9mIGFyZ3VtZW50IGNvdWxkIGJlIHByb2R1Y3RpdmUsIGlmDQo+Pj4+ IHNvbWVvbmUgd2FudGVkIHRvIGludmVzdGlnYXRlIGl0Lg0KPj4+DQo+Pj4gcW1haWwgZGVsaXZl cmVkIGVtYWlsIHRvIG5pYy5kbmFtZS5jeiBqdXN0IGZpbmUuICAoSGFkIHRvIGdvIHRocnUgYWxs DQo+Pj4gdGhlIGhvb3BzIGFuZCBsb29wcyB3aGVuIGJ1aWxkaW5nIG5ldHFtYWlsIGluIGNocm9v dGVkIGVudmlyb25tZW50Lg0KPj4+IERvbid0IG1ha2UgbWUgZG8gdGhhdCBhZ2Fpbi4uLikNCj4+ Pg0KPj4+Pj4gdGhlIGNoYWlycyBzYWlkIGluIHRoZSBtZWV0aW5nIHRoYXQgb25seSBoYWxmICg/ KSBvZiB0aGUgc2VydmVycyBzdXBwb3J0IGQNCj4+PiBuYW1lLg0KPj4+Pg0KPj4+PiBTbywgdG8g Y2xhcmlmeSwgdGhpcyBpcyBhbiBpc3N1ZSB3aXRoIHJlY3Vyc2l2ZSByZXNvbHZlcnMgdGhhdCBk byBub3QNCj4+Pj4gc3VwcG9ydCBETkFNRS4gIEkgZGlkbid0IHBhcnRpY2lwYXRlIGluIHRoZSBp bnZlc3RpZ2F0aW9uLCBzbyB0aGUNCj4+Pj4gZGV0YWlscyB3aWxsIGhhdmUgdG8gd2FpdCB1bnRp bCBPbGFmdXIgZ2V0cyBiYWNrICh1bmxlcyBPbmRyZWogd2FudHMNCj4+Pj4gdG8gY2hpbWUgaW4g LS0gSSB0aGluayBoZSB3YXMgYWxzbyBpbnZvbHZlZD8pLiAgQnV0IHRoZSBrZXkgdGhpbmcgaXMN Cj4+Pj4gdG8gbm90ZSB0aGF0IHRoaXMgaXMgY29kZSBiYXNlLCBub3QgJSBvZiBkZXBsb3llZCBz eXN0ZW1zLg0KPj4+DQo+Pj4gV2UgdGVzdGVkIHNvbWUsIGJ1dCB0aGV5IGFsbCB3ZXJlIGZpbmUg dXNpbmcgc3ludGhldGl6ZWQgQ05BTUVzIHNpbmNlDQo+Pj4gdGhleSBkb24ndCBzdXBwb3J0IERO U1NFQy4NCj4+Pg0KPj4+PiBNb3Jlb3ZlciwgdGhlIHN5c3RlbXMgaW4gcXVlc3Rpb24gY2FuJ3Qg c3VwcG9ydCBETlNTRUMgcHJvcGVybHksIGVpdGhlci4NCj4+Pg0KPj4+IFllcywgYW5kIHRoZSBh cmd1bWVudCBoZXJlIGlzIHNhbWUgZm9yIEJOQU1FLiAgSWYgdGhvc2Ugc2VydmVycyBkaWRuJ3QN Cj4+PiBnZXQgc3VwcG9ydCBmb3IgRE5BTUUsIHRoZXkgd2lsbCBub3QgZ2V0IHN1cHBvcnQgZm9y IEJOQU1FIGVpdGhlci4gIEFuZA0KPj4+IGlmIHRoZXkgZ2V0IHByb3BlciBETlNTRUMgc3VwcG9y dCAoc29vbikgdGhleSB3aWxsIGxpa2VseSBnZXQgYSBETkFNRQ0KPj4+IHN1cHBvcnQuDQo+Pj4N Cj4+Pj4+IHNlY3Rpb24gNS4yIG9mIGJuYW1lIGRyYWZ0IGFkZHJlc3NlcyB0aGlzIHByb2JsZW0u DQo+Pj4+Pg0KPj4+Pj4gNS4yLiAgQk5BTUUgYWxpYXMgYWxnb3JpdGhtIGlkZW50aWZpZXJzDQo+ Pj4+Pg0KPj4+Pj4NCj4+Pj4+ICAgICAgSW4gb3JkZXIgdG8gcHJldmVudCBCTkFNRS11bmF3YXJl IHJlc29sdmVycyBmcm9tIGF0dGVtcHRpbmcgdG8NCj4+Pj4+ICAgICAgdmFsaWRhdGUgcmVzcG9u c2VzIGZyb20gQk5BTUUtc2lnbmVkIHpvbmVzLCB0aGlzIHNwZWNpZmljYXRpb24NCj4+Pj4+ICAg ICAgYWxsb2NhdGVzIHR3byBuZXcgRE5TS0VZIGFsZ29yaXRobSBpZGVudGlmaWVycy4gIEFsZ29y aXRobSBZLCBEU0EtDQo+Pj4+DQo+Pj4+IFJpZ2h0LCB5b3UncmUgcXVpdGUgY29ycmVjdCBmb3Ig dGFraW5nIG1lIHRvIHRhc2sgZm9yIG5vdCBwb2ludGluZw0KPj4+PiB0aGlzIG91dC4gIEJ1dCB0 aGlzIGFuc3dlciBpcyBzdGlsbCBwcmV0dHkgYmFkLCBiZWNhdXNlIHdoYXQgd2UncmUNCj4+Pj4g ZG9pbmcgaW4gdGhhdCBjYXNlIGlzIHByb21vdGluZyBhIGJhcnJpZXIgdG8gRE5TU0VDIHZhbGlk YXRpb246IGlmIHlvdQ0KPj4+PiBkb24ndCBoYXZlIGEgQk5BTUUtc3VwcG9ydGluZyB2YWxpZGF0 b3IsIHlvdSBkb24ndCBnZXQgdmFsaWRhdGlvbi4NCj4+Pj4gVGhpcyBpc3N1ZSBpcyBwYXJ0IG9m IHdoeSBJJ20gYW54aW91cyB0byBnZXQgZ3VpZGFuY2UuDQo+Pj4+DQo+Pj4+IEFsc28sIHRoZSBh bGlhc2VzIGFyZSBpbmFkZXF1YXRlLiAgWW91IGFjdHVhbGx5IG5lZWQgYW4gYWxpYXMgZm9yDQo+ Pj4+IGV2ZXJ5IGV4aXN0aW5nIGFsZ29yaXRobSBpZGVudGlmaWVyLiAgVGhhdCBtZWFucyB5b3Ug bmVlZCBhbGlhc2VzIGZvcg0KPj4+PiBhbGwgdGhlIFNIQTIgdmFyaWFudHMgYW5kIEdPU1QgYXMg d2VsbCAoSSdtIHdpbGxpbmcgdG8gZGlzcmVnYXJkIE1ENQ0KPj4+PiBiZWNhdXNlIHdlIHRoaW5r IGl0IG91Z2h0bid0IHRvIGJlIHVzZWQgYW55d2F5KS4NCj4+Pg0KPj4+IEFuZCB5b3UgbmVlZCBu b3JtYWwgYW5kIEJOQU1FIGZvciBldmVyeSBmdXR1cmUgYWxnb3JpdGhtLiAgT3IgZG8geW91DQo+ Pj4gcGxhbiB0byBtYWtlIEJOQU1FIHN1cHBvcnQgbWFuZGF0b3J5IGZvciBldmVyeSBuZXcgYWxn b3JpdGhtPw0KPj4NCj4+IEkgd291bGQgZXhwZWN0IGl0IHRvIGJlIGxpa2UgTlNFQzMsIG5ldyBh bGdvcml0aG1zIHdvdWxkIGFsc28gaW5kaWNhdGUNCj4+IEJOQU1FIHN1cHBvcnQuICBJZiB3ZSBo YWQgaGFkIGtub3duIGVub3VnaCBhYm91dCBETlNTRUMgRE5BTUUncyBvcmlnaW5hbA0KPj4gaW50 cm9kdWN0aW9uIHdvdWxkIGhhdmUgYWRkZWQgYWxnb3JpdGhtIGFsaWFzZXMuICBUaGUgdHlwZSBj b2RlIHJvbGwNCj4+IGFsbG93ZWQgdXMgdG8gZG8gdGhhdCBhIHNsaWdodGx5IGRpZmZlcmVudCB3 YXkuDQo+IA0KPiBUaGF0IG1pZ2h0IHdvcmsgbm93LiAgQnV0IEkgc2VlIGl0IGFzIGEgYmFkIHBy ZWNlZGVudC4gIElmIHdlIHNldHVwIHRoaXMgDQo+IGFzIGEgdXN1YWwgd2F5IGhvdyB0byBjb3Bl LCB3ZSB3b3VsZCBoYXZlIHRvIGNyZWF0ZSBhbGdvcml0aG0gZHVwZXMgZm9yIA0KPiBldmVyeSAo bm9uIGRlcHJlY2F0ZWQpIGFsZ29yaXRobSB0byB0aGUgZGF0ZS4gIFRoaXMgbWlnaHQgZ3JvdyBo dWdlLiANCj4gRm9ydHVuYXRlbHkgeW91IGRvbid0IGhhdmUgdG8gZG8gQ2FydGVzaWFuIHByb2R1 Y3QgZm9yIGFsbCBzaWduYWxpbmcsIA0KPiBidXQgeW91IGNhbiBzYXkgdGhhdCBuZXcgc2lnbmFs IGFsc28gaW5jbHVkZXMgYWxsIHByZWNlZGluZyBvbmVzIChpZS4gDQo+IHN1cHBvcnQgZm9yIEJO QU1FIGluY2x1ZGVzIHN1cHBvcnQgZm9yIEROQU1FIGFuZCBOU0VDMykuDQo+IA0KDQpibmFtZSBm b2xsb3cgdGhlIGRpZmluaXRvbiBvZiBkcmFmdC15YW8tZG5zZXh0LWFsaWFzLWFsZ29yaXRobS0w MC50eHQgdG8gYXZvaWQgYWRkaW5nDQp0b28gbWFueSBhbGlhcyBhbGdvcml0aG1zIGZvciB0aGUg bmV3IHJydHlwZXMuDQoNCj4NCj4gSWYgdGhpcyBnZXRzIGV2ZXIgY3JlYXRlZCB3ZSBuZWVkIHNv bWV0aGluZyBsaWtlIGEgdGFibGUgd2l0aCBhbGdvcml0aG0gDQo+IG51bWJlcnMgYXMgbGluZXMg YW5kIHN0YW5kYXJkcyBpbmNsdWRlZCBpbiBjb2x1bW5zIHdpdGggZmllbGRzIA0KPiBpbmRpY2F0 aW5nIHN1cHBvcnQuICBJdCdzIGFscmVhZHkgbWVzcyB0aGF0IHlvdSBoYXZlIHNvbWUgYWxnb3Jp dGhtcyANCj4gbmFtZWQgPHNvbWV0aGluZz4tTlNFQzMtPHNvbWV0aGluZz4gYW5kIHNvbWUgbm90 IChTSEEtMiBmYW1pbHksIEdPU1QpIA0KPiBhbmQgdGhleSBhbGwgaW5jbHVkZSBOU0VDMyBzdXBw b3J0Lg0KPiANCj4gT25kcmVqDQo+IC0tIA0KPiAgT25kxZllaiBTdXLDvQ0KPiAgdmVkb3Vjw60g dsO9emt1bXUvSGVhZCBvZiBSJkQgZGVwYXJ0bWVudA0KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgQ1ouTklDLCB6LnMucC5vLiAgICAtLSAgICBMYWJv cmF0b8WZZSBDWi5OSUMNCj4gIEFtZXJpY2thIDIzLCAxMjAgMDAgUHJhaGEgMiwgQ3plY2ggUmVw dWJsaWMNCj4gIG1haWx0bzpvbmRyZWouc3VyeUBuaWMuY3ogICAgaHR0cDovL25pYy5jei8NCj4g IHRlbDorNDIwLjIyMjc0NTExMCAgICAgICBmYXg6KzQyMC4yMjI3NDUxMTINCj4gIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4= From owner-namedroppers@ops.ietf.org Fri Aug 13 01:52: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 A2F133A687E; Fri, 13 Aug 2010 01:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.307 X-Spam-Level: X-Spam-Status: No, score=-101.307 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, J_CHICKENPOX_23=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 vWC8c1BaWKr8; Fri, 13 Aug 2010 01:52:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 962443A6830; Fri, 13 Aug 2010 01:52:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjpwC-000EQz-Ur for namedroppers-data0@psg.com; Fri, 13 Aug 2010 08:48:28 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjpwA-000EQk-55 for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 08:48:26 +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 22FBF734295; Fri, 13 Aug 2010 10:48:25 +0200 (CEST) Message-ID: <4C6506D7.6060701@nic.cz> Date: Fri, 13 Aug 2010 10:48:23 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jiankang YAO CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] alias algorithm for bname and other new rrtype Fw: I-D Action:draft-yao-dnsext-alias-algorithm-00.txt References: <481540291.31022@cnnic.cn> In-Reply-To: <481540291.31022@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 11.8.2010 17:25, Jiankang YAO wrote: > nsec3 or bname and more future rrtype have to deal with the dnssec > problems. alias algorithm identifier is necessary. this document > design a univerisial method for all new rrtypes in dnssec. > > we will not need to name a individual alias algorithm identifiers to > individual rrtype. Sorry, but that I-D doesn't make any sense at all. You write: > Based on the rule of first come first served, the 8-bit algorithm > allocation pool would soon be exhausted if more and more new RRTYPEs > and algorithms had appeared in the DNS protocols. And then you define new "aliases". But you don't say anything about the coding the "alias" to the RRSIG/DNSKEY RR types. The field in those records are still 8-bit and you cannot create alias-labels from the thin air. You need to code it into the wire format - e.g. into the algorithm field of DNSKEY/RRSIG record. So the problem you are trying to solve is still there. Or am I missing something? How will you code the "alias" to the wire format. > The validating resolver following this specification MUST check the > type covered of the RRSIG before the verification. Only when the > validating resolver knows the RRTYPE, it can begin to verify the > signature of the RRSIG. Otherwise, the validating resolver MUST > regard the RRSIG in which the type covered is unknown to the > resolver as insecure instead of bogus. Also I am very afraid of this. I could imagine all sort of "upgrade" attacks when attacker will spoof RRTYPE not know to the resolver, but known to the client. Hence I consider this proposal very dangerous to the DNSSEC security. O. -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 13 02:08: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 AEEAA3A6893; Fri, 13 Aug 2010 02:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.343 X-Spam-Level: X-Spam-Status: No, score=-101.343 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, J_CHICKENPOX_23=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 dLTnyNIsYGig; Fri, 13 Aug 2010 02:08:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5CF133A68A2; Fri, 13 Aug 2010 02:08:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjqD0-000Gh2-0B for namedroppers-data0@psg.com; Fri, 13 Aug 2010 09:05:50 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjqCx-000Ggm-6R for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 09:05:47 +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 C1939734434; Fri, 13 Aug 2010 11:05:45 +0200 (CEST) Message-ID: <4C650AE9.2030301@nic.cz> Date: Fri, 13 Aug 2010 11:05:45 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jiankang YAO CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] the method of avoiding signal in bname References: <481633111.17609@cnnic.cn> In-Reply-To: <481633111.17609@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 12.8.2010 19:12, Jiankang YAO wrote: > Dear all, > I proposed the following method for bname to avoid the signaling: > if the query is not dnssec query: > If the owner name of the bname is the suffix of the name queryed but > different, when preparing a response, a server performing a BNAME > substitution will in all cases include the relevant BNAME RR in the > answer section. A CNAME RR is synthesized and included in the answer > section. This will help the client to reach the correct DNS data. > > If the owner name of the bname is same with the name queryed, when > preparing a response, a server performing a BNAME substitution will > not include the relevant BNAME RR in the answer section unless the > type queryed is BNAME. A CNAME RR will be synthesized and included > in the answer section unless the type queryed is BNAME or the query > is the DNSSEC query. > if the query is the dnssec query: > only the bname is returned to the resolvers from the servers. > this assumes that: if the resolvers does not recognize the bname but > want dnssec, the synthesized > cname is not useful for them. > if the resolvers does recognize the bname and want dnssec, the resolvers > can do the > next query without the synthesized > cname. > through the method above, there will never issue cname and bname > together with the same owner name. > if bname still needs the alias algorithm, it will follow the difiniton > of draft-yao-dnsext-alias-algorithm-00.txt to avoid adding > too many alias algorithms for the new rrtypes. You cannot avoid the signaling for the BNAME. You still need the signaling for the BNAME support in the DNSSEC-validating resolver. You need to treat the non-BNAME aware DNSSEC validating resolver as your case number #1. And then you have a unsolvable problem with chained resolvers. Because downstream BNAME-aware resolver will not be able to see BNAME record after the upstream resolver has a synthesized CNAME in the cache. I think this won't fly [RFC1925]. Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 13 02:17: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 55BA33A6893; Fri, 13 Aug 2010 02:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.443 X-Spam-Level: X-Spam-Status: No, score=-100.443 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_20=-0.74, J_CHICKENPOX_23=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 t7I5GG9YoZMM; Fri, 13 Aug 2010 02:17:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8DD603A68DA; Fri, 13 Aug 2010 02:17:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjqLt-000Hud-Sx for namedroppers-data0@psg.com; Fri, 13 Aug 2010 09:15:01 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjqLp-000Hu0-PW for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 09:14: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 DFDF3734439; Fri, 13 Aug 2010 11:14:56 +0200 (CEST) Message-ID: <4C650D10.8070809@nic.cz> Date: Fri, 13 Aug 2010 11:14:56 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" References: <20100810133649.GC52191@shinkuro.com> In-Reply-To: <20100810133649.GC52191@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 10.8.2010 15:36, Andrew Sullivan wrote: > Dear colleagues, > > One of our primary goals for DNSEXT at IETF 78 was to get feedback > from the user community (in particular, we aimed at application > developers) who have the "aliasing" and "sameness" problem(s) with the > DNS. Unfortunately, we were unable to attract many such participants. Andrew, I would like to point out that application developers are not the only target audience of the "sameness" problem. From my (obvious) point of view I see that more close to the registry/registrar audience. Like what Greeks are doing: https://grweb.ics.forth.gr/english/faq.html#f49 As I see it they would benefit greatly if they could insert xNAME (where x is C+D or B) which would alias owner of the xNAME as well. Domain owners are the second audience which has some opinions on the "sameness" (mostly in form of IDN). I hear many voices which either say "don't do IDN at all because you create mess" or they say "if you do IDN, do it as an aliases only". Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 13 02:36: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 616203A68F1; Fri, 13 Aug 2010 02:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.314 X-Spam-Level: * X-Spam-Status: No, score=1.314 tagged_above=-999 required=5 tests=[AWL=-0.905, BAYES_40=-0.185, 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 Ne7+pzlybezx; Fri, 13 Aug 2010 02:36:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 39F323A6804; Fri, 13 Aug 2010 02:36:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojqe7-000KbW-DM for namedroppers-data0@psg.com; Fri, 13 Aug 2010 09:33:51 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojqe4-000Kb0-Ff for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 09:33:48 +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 30543C56949; Fri, 13 Aug 2010 10:33:45 +0100 (BST) Date: Fri, 13 Aug 2010 10:33:45 +0100 From: Alex Bligh Reply-To: Alex Bligh To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= , Andrew Sullivan cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" Message-ID: In-Reply-To: <4C650D10.8070809@nic.cz> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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: Ondrej, --On 13 August 2010 11:14:56 +0200 Ond=C5=99ej Sur=C3=BD = wrote: > I would like to point out that application developers are not the only > target audience of the "sameness" problem. From my (obvious) point of > view I see that more close to the registry/registrar audience. Like what > Greeks are doing: https://grweb.ics.forth.gr/english/faq.html#f49 > As I see it they would benefit greatly if they could insert xNAME (where > x is C+D or B) which would alias owner of the xNAME as well. I agree that this is being driven partly (mostly?) by the = registry/registrar community. However, what I don't understand is that even if we come up with a magic DNS aliasing solution so that Ai.Bj always gives the same result as A1.B1, what is the use of it if it doesn't work at the application layer too? number of users of web browsers and email exceed number of users of dig by many orders of magnitude. I have yet to find one application the "magic xNAME" proposal would work with out the box. --=20 Alex Bligh From owner-namedroppers@ops.ietf.org Fri Aug 13 06:11: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 863C23A6782; Fri, 13 Aug 2010 06:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.582 X-Spam-Level: X-Spam-Status: No, score=-100.582 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_05=-1.11, J_CHICKENPOX_23=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 wRuG9pOXzBWl; Fri, 13 Aug 2010 06:11:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 80BB83A6869; Fri, 13 Aug 2010 06:11:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjtwJ-000Mnn-2M for namedroppers-data0@psg.com; Fri, 13 Aug 2010 13:04:51 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjtwG-000MnB-19 for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 13:04:48 +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 7FB91734352; Fri, 13 Aug 2010 15:04:45 +0200 (CEST) Message-ID: <4C6542ED.1000700@nic.cz> Date: Fri, 13 Aug 2010 15:04:45 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alex Bligh CC: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> In-Reply-To: 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 13.8.2010 11:33, Alex Bligh wrote: > Ondrej, > > --On 13 August 2010 11:14:56 +0200 OndÅ™ej Surý > wrote: > >> I would like to point out that application developers are not the >> only target audience of the "sameness" problem. From my (obvious) >> point of view I see that more close to the registry/registrar >> audience. Like what Greeks are doing: >> https://grweb.ics.forth.gr/english/faq.html#f49 As I see it they >> would benefit greatly if they could insert xNAME (where x is C+D >> or B) which would alias owner of the xNAME as well. > > I agree that this is being driven partly (mostly?) by the > registry/registrar community. However, what I don't understand is > that even if we come up with a magic DNS aliasing solution so that > Ai.Bj always gives the same result as A1.B1, what is the use of it > if it doesn't work at the application layer too? number of users of > web browsers and email exceed number of users of dig by many orders > of magnitude. > I have yet to find one application the "magic xNAME" proposal would > work with out the box. Why is it so important that it works out of the box? The usage in R-R-R model doesn't include magnitude of domain names. It just gives people an option to simplify the one place where they do most errors and which has those strange things which people don't understand like TTL. From my viewpoint (of a person who worked for hosting company longer than for registry) the rest is up to the provisioning and it's very easy to do compared to provisioning of the DNS. OndÅ™ej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 13 06:30: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 B14B63A68CC; Fri, 13 Aug 2010 06:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.118 X-Spam-Level: * X-Spam-Status: No, score=1.118 tagged_above=-999 required=5 tests=[AWL=-0.546, 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 ck5nHbwBrSS0; Fri, 13 Aug 2010 06:30:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2DAF83A68F8; Fri, 13 Aug 2010 06:30:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjuHm-000PmI-4x for namedroppers-data0@psg.com; Fri, 13 Aug 2010 13:27:02 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjuHj-000Plk-Ac for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 13:26:59 +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 64DDDC5694A; Fri, 13 Aug 2010 14:26:57 +0100 (BST) Date: Fri, 13 Aug 2010 14:26:56 +0100 From: Alex Bligh Reply-To: Alex Bligh To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= cc: Andrew Sullivan , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" Message-ID: <25187E64AF3BDAA68165A923@Ximines.local> In-Reply-To: <4C6542ED.1000700@nic.cz> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <4C6542ED.1000700@nic.cz> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 13 August 2010 15:04:45 +0200 Ond=C5=99ej Sur=C3=BD = wrote: > Why is it so important that it works out of the box? The usage in R-R-R > model doesn't include magnitude of domain names. It just gives people an > option to simplify the one place where they do most errors and which has > those strange things which people don't understand like TTL. From my > viewpoint (of a person who worked for hosting company longer than for > registry) the rest is up to the provisioning and it's very easy to do > compared to provisioning of the DNS. My suspicion is that it is all but impossible to solve at the application layer, and that means there is little point causing protocol entropy at the DNS layer. I'd quite like to be proved wrong on this. To give you an example of provisioning impossibility or impracticality take www.Ai.Bj.Ck.Dl, where each of i,j,k,l are more than one (and range from 1 to I,J,K,L). How do you provide an SSL certificate for that? As far as I can see, the only current way is to have I*J*K*L certificates, on I*J*K*L different IP addresses, which necessarily means you CANNOT have mirroring between zones because you want a different A record. Even if one of the various proposed solutions to the one-SSL-cert per IP record problem was adopted, you would STILL need I*J*K*L SSL certs as far as I can see. This problem exists at various different magnitudes for http, smtp, sip, etc. etc. I am not saying we should ignore this until the application layer is fixed. I am saying the protocol entropy this induces means we shouldn't progress this until we know the application layer is fixable at least for common protocols (and as I say, I'd like my cynicism to be proved wrong here). If there's one common protocol that requires x.Ai.Bj.Ck.Dl has a different A record to x.A1.B1.C1.D1, then people aren't going to use an xNAME type proposal because it will prevent support of that protocol (and presumably they'll use a "dumb provisioning hack" instead). --=20 Alex Bligh From owner-namedroppers@ops.ietf.org Fri Aug 13 06:55: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 6EDF43A6912; Fri, 13 Aug 2010 06:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.071 X-Spam-Level: X-Spam-Status: No, score=-100.071 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_20=-0.74, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=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 Jvv7ppN8T0dM; Fri, 13 Aug 2010 06:55:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DDE0D3A6994; Fri, 13 Aug 2010 06:55:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojugh-0003Gb-6d for namedroppers-data0@psg.com; Fri, 13 Aug 2010 13:52:47 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojugd-0003GA-QT for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 13:52:44 +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 A3B85734352; Fri, 13 Aug 2010 15:52:42 +0200 (CEST) Message-ID: <4C654E29.2070905@nic.cz> Date: Fri, 13 Aug 2010 15:52:41 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: zhanglikun CC: namedroppers@ops.ietf.org Subject: Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") References: <00aa01cb3a22$4754a5e0$d5fdf1a0$@com> In-Reply-To: <00aa01cb3a22$4754a5e0$d5fdf1a0$@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 12.8.2010 15:28, zhanglikun wrote: > Now let me go back to c+dname VS bname. > > If one zone has records: a.net. cname a.cn. a.net. dname b.com. > > user do the query with the following sequence: dig a.net. cname > dig a.net. dname > > if the cache isn't aware of the new c+dname rules, will the second > query will chase down to b.com.? > It will try to chase down a dname record belonging to a.cn. rather > than b.com. Yes, but Wouter and I have already mentioned that the workaround is to query for anything below the owner. (Sorry for using your email user part for testing purposes, I was out of ideas how to name it.) $ dig +noall +answer IN CNAME zhanglikun.dname.cz @127.0.0.2 zhanglikun.dname.cz. 60 IN CNAME target1.dname.cz. $ dig +noall +answer IN DNAME zhanglikun.dname.cz @127.0.0.2 zhanglikun.dname.cz. 55 IN CNAME target1.dname.cz. target1.dname.cz. 60 IN DNAME ccccc.dname.cz. So yes, you are right here. However the important is what happens if you resolver .: $ dig +noall +answer IN DNAME www.zhanglikun.dname.cz @127.0.0.2 zhanglikun.dname.cz. 60 IN DNAME target2.dname.cz. www.zhanglikun.dname.cz. 0 IN CNAME www.target2.dname.cz. target2.dname.cz. 60 IN DNAME ddddd.dname.cz. www.target2.dname.cz. 0 IN CNAME www.ddddd.dname.cz. This works even when you have chained caches (tested unbound and bind9 as downstream, bind9 as upstream). > Except the c+dname has one rule: the rdata part of should be same. There is no such rule. > another, when doing update, you have to be very careful to decide > whether to remove/add c+dname or just one of them. Yes, you have to be careful when you edit your zone. What's the new thing here? > Last, c+dname will double zone size, compared with bname. Common... right now the registry put at least 2 or more NS records (and glue). O. -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 13 07:07: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 B51A93A67AC; Fri, 13 Aug 2010 07:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.315 X-Spam-Level: X-Spam-Status: No, score=-100.315 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_20=-0.74, J_CHICKENPOX_23=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 eawHNP7cNYhG; Fri, 13 Aug 2010 07:07:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 29EA63A6846; Fri, 13 Aug 2010 07:07:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjusJ-0005CE-7M for namedroppers-data0@psg.com; Fri, 13 Aug 2010 14:04:47 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjusG-0005Bj-9R for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 14:04:44 +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 6F1DC734378; Fri, 13 Aug 2010 16:04:43 +0200 (CEST) Message-ID: <4C6550FB.4040905@nic.cz> Date: Fri, 13 Aug 2010 16:04:43 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alex Bligh CC: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <4C6542ED.1000700@nic.cz> <25187E64AF3BDAA68165A923@Ximines.local> In-Reply-To: <25187E64AF3BDAA68165A923@Ximines.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 13.8.2010 15:26, Alex Bligh wrote: > To give you an example of provisioning impossibility or impracticality > take www.Ai.Bj.Ck.Dl, where each of i,j,k,l are more than one (and > range from 1 to I,J,K,L). How do you provide an SSL certificate for > that? As far as I can see, the only current way is to have > I*J*K*L certificates, on I*J*K*L different IP addresses, which necessarily > means you CANNOT have mirroring between zones because you want a different > A record. Even if one of the various proposed solutions to the one-SSL-cert > per IP record problem was adopted, you would STILL need I*J*K*L SSL > certs as far as I can see. This problem exists at various different > magnitudes for http, smtp, sip, etc. etc. For HTTPS you either: - don't use ssl for aliased domain names - dont' use aliases for domains where you need SSL - use SNI (Server Name Indication) the support is already there - use this: X509v3 Subject Alternative Name: DNS:www.sury.org, DNS:sury.org SMTP, SIP, etc. have either requirement for using canonical name (SMTP) or they have SRV records (SIP). Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 13 07:22: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 949163A69F7; Fri, 13 Aug 2010 07:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.181 X-Spam-Level: X-Spam-Status: No, score=0.181 tagged_above=-999 required=5 tests=[AWL=0.675, 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 0YmHvjxCyVqr; Fri, 13 Aug 2010 07:22:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 44BEF3A68F2; Fri, 13 Aug 2010 07:22:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojv6L-0007pZ-Jm for namedroppers-data0@psg.com; Fri, 13 Aug 2010 14:19:17 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojv6H-0007nh-VP for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 14:19:14 +0000 Received: by fxm10 with SMTP id 10so2330374fxm.11 for ; Fri, 13 Aug 2010 07:19: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:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=cB+9PXzv8l7u/PED4MD6JsP/zUI+wgQaVnDW5Z7Yh+M=; b=VwadBBc859ER5c7OCDEe71Kupr8sZRAQ49NMn+RPv8K2oWXgYEbcs4HTXhmInX6tay m4xBZjyfy/dRm8WUohuOZzL6iRq+1DQF60vCC0BHSMhLbulKOmEyUMS6NBWqlIFnJ8xk ErMmbdL3Zs4OulWWkxYVIXQpcGaleS3XslCA4= 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=M10Hz7Fes0EmU+/fOH1bCuhyaVvtp164CHLX+8oS96JFuvEYILAzgFwyWhNp10xDet WC6I3QiThWxvHbCNHCLsKvRGZZNimrj9oPt3/SUcTym28GepBa7JXVc88qtDmJZtbMY5 0DfBbTXzKuO9+AzvZ1jHLvS6ZNMoZyGkN6sOY= MIME-Version: 1.0 Received: by 10.223.103.148 with SMTP id k20mr2046228fao.101.1281709152540; Fri, 13 Aug 2010 07:19:12 -0700 (PDT) Received: by 10.223.50.154 with HTTP; Fri, 13 Aug 2010 07:19:12 -0700 (PDT) In-Reply-To: <25187E64AF3BDAA68165A923@Ximines.local> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <4C6542ED.1000700@nic.cz> <25187E64AF3BDAA68165A923@Ximines.local> Date: Fri, 13 Aug 2010 11:19:12 -0300 Message-ID: Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" From: Brian Dickson To: Alex Bligh Cc: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , Andrew Sullivan , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=001636c5a8a1be18bb048db52a93 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001636c5a8a1be18bb048db52a93 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 13, 2010 at 10:26 AM, Alex Bligh wrote: > > > --On 13 August 2010 15:04:45 +0200 Ond=C5=99ej Sur=C3=BD wrote: > > Why is it so important that it works out of the box? The usage in R-R-R >> model doesn't include magnitude of domain names. It just gives people a= n >> option to simplify the one place where they do most errors and which has >> those strange things which people don't understand like TTL. From my >> viewpoint (of a person who worked for hosting company longer than for >> registry) the rest is up to the provisioning and it's very easy to do >> compared to provisioning of the DNS. >> > > My suspicion is that it is all but impossible to solve at the > application layer, and that means there is little point causing > protocol entropy at the DNS layer. I'd quite like to be proved > wrong on this. > > To give you an example of provisioning impossibility or impracticality > take www.Ai.Bj.Ck.Dl, where each of i,j,k,l are more than one (and > range from 1 to I,J,K,L). How do you provide an SSL certificate for > that? As far as I can see, the only current way is to have > I*J*K*L certificates, on I*J*K*L different IP addresses, which necessaril= y > means you CANNOT have mirroring between zones because you want a differen= t > A record. Even if one of the various proposed solutions to the one-SSL-ce= rt > per IP record problem was adopted, you would STILL need I*J*K*L SSL > certs as far as I can see. This problem exists at various different > magnitudes for http, smtp, sip, etc. etc. > I believe the one-SSL-per-IP is well-solved. http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI (All current versions of all browsers support SNI, AFAIK.) The Subject Alternative Name in SSL certificates allows a single cert to function for all combinations. Costs vary by SSL CA/reseller, of course. Combine these together, and I think the problem, at least for HTTPS, is solved. Brian > > I am not saying we should ignore this until the application layer is > fixed. I am saying the protocol entropy this induces means we shouldn't > progress this until we know the application layer is fixable at > least for common protocols (and as I say, I'd like my cynicism to be > proved wrong here). If there's one common protocol that requires > x.Ai.Bj.Ck.Dl has a different A record to x.A1.B1.C1.D1, then people > aren't going to use an xNAME type proposal because it will prevent > support of that protocol (and presumably they'll use a "dumb > provisioning hack" instead). > > -- > Alex Bligh > > --001636c5a8a1be18bb048db52a93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Aug 13, 2010 at 10:26 AM, Alex B= ligh <alex@alex.or= g.uk> wrote:


--On 13 August 2010 15:04:45 +0200 Ond=C5=99ej Sur=C3=BD <ondrej.sury@nic.cz> wrote:=

Why is it so important that it works out of the box? =C2=A0The usage in R-R= -R
model doesn't include magnitude of domain names. =C2=A0It just gives pe= ople an
option to simplify the one place where they do most errors and which has those strange things which people don't understand like TTL. =C2=A0From= my
viewpoint (of a person who worked for hosting company longer than for
registry) the rest is up to the provisioning and it's very easy to do compared to provisioning of the DNS.

My suspicion is that it is all but impossible to solve at the
application layer, and that means there is little point causing
protocol entropy at the DNS layer. I'd quite like to be proved
wrong on this.

To give you an example of provisioning impossibility or impracticality
take www.Ai.Bj.Ck.Dl, where each of i,j,k,l are more than one (and
range from 1 to I,J,K,L). How do you provide an SSL certificate for
that? As far as I can see, the only current way is to have
I*J*K*L certificates, on I*J*K*L different IP addresses, which necessarily<= br> means you CANNOT have mirroring between zones because you want a different<= br> A record. Even if one of the various proposed solutions to the one-SSL-cert=
per IP record problem was adopted, you would STILL need I*J*K*L SSL
certs as far as I can see. This problem exists at various different
magnitudes for http, smtp, sip, etc. etc.


I be= lieve the one-SSL-per-IP is well-solved.

http://wiki.apache.org/httpd/NameBa= sedSSLVHostsWithSNI

(All current versions of all browsers support SNI, AFAIK.)

The S= ubject Alternative Name in SSL certificates allows a single cert to functio= n for all combinations.
Costs vary by SSL CA/reseller, of course.

Combine these together, and I think the problem, at least for HTTPS, is= solved.

Brian

=C2=A0

I am not saying we should ignore this until the application layer is
fixed. I am saying the protocol entropy this induces means we shouldn't=
progress this until we know the application layer is fixable at
least for common protocols (and as I say, I'd like my cynicism to be proved wrong here). If there's one common protocol that requires
x.Ai.Bj.Ck.Dl has a different A record to x.A1.B1.C1.D1, then people
aren't going to use an xNAME type proposal because it will prevent
support of that protocol (and presumably they'll use a "dumb
provisioning hack" instead).

--
Alex Bligh


--001636c5a8a1be18bb048db52a93-- From owner-namedroppers@ops.ietf.org Fri Aug 13 07:22: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 B11F23A67AC; Fri, 13 Aug 2010 07:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.62 X-Spam-Level: X-Spam-Status: No, score=-101.62 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 fwSF5W+lis9d; Fri, 13 Aug 2010 07:22:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B1333A6403; Fri, 13 Aug 2010 07:22:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojv7o-000818-O8 for namedroppers-data0@psg.com; Fri, 13 Aug 2010 14:20:48 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojv7j-00080c-Kj for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 14:20:46 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7DEKdKh006973 for ; Fri, 13 Aug 2010 10:20:39 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o7DEKdgY006972 for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 10:20:39 -0400 (EDT) (envelope-from namedroppers) Received: from [83.241.177.39] (helo=yxa-v.extundo.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oi23i-000JsC-OX for namedroppers@ops.ietf.org; Sun, 08 Aug 2010 09:20:48 +0000 Received: from mocca (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o789K4Vw026713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 8 Aug 2010 11:20:07 +0200 From: Simon Josefsson To: RFC Errata System Cc: rdroms.ietf@gmail.com, jari.arkko@piuha.net, ogud@ogud.com, ajs@shinkuro.com, paul@noc4.net, namedroppers@ops.ietf.org Subject: [dnsext] Re: [Technical Errata Reported] RFC4398 (2460) References: <20100807204424.80CD6E06B3@rfc-editor.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100808:ajs@shinkuro.com::5MApHhVj7tRZWiOV:33QE X-Hashcash: 1:22:100808:jari.arkko@piuha.net::lrJv8FH7KsHrWUyq:2DS0 X-Hashcash: 1:22:100808:rfc-editor@rfc-editor.org::SyvM2vJ+fUkxnv9n:3cVi X-Hashcash: 1:22:100808:namedroppers@ops.ietf.org::YEwBvUicA4X97BcM:7uoj X-Hashcash: 1:22:100808:ogud@ogud.com::mw5zT0ZNVdBMBp03:JzAo X-Hashcash: 1:22:100808:paul@noc4.net::u3LxR+757EanmO12:lFSl X-Hashcash: 1:22:100808:rdroms.ietf@gmail.com::y83AQ2QRD2a5uVmg:bmzu Date: Sun, 08 Aug 2010 11:20:03 +0200 In-Reply-To: <20100807204424.80CD6E06B3@rfc-editor.org> (RFC Errata System's message of "Sat, 7 Aug 2010 13:44:24 -0700 (PDT)") Message-ID: <8739upo3zw.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean 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. ] Thanks for the report. It appears correct to me. /Simon RFC Errata System writes: > The following errata report has been submitted for RFC4398, > "Storing Certificates in the Domain Name System (DNS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4398&eid=2460 > > -------------------------------------- > Type: Technical > Reported by: Paul Freeman > > Section: 2 > > Original Text > ------------- > 2. The CERT Resource Record > > The CERT resource record (RR) has the structure given below. Its RR > type code is 37. > > 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | type | key tag | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | algorithm | / > +---------------+ certificate or CRL / > / / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > > Corrected Text > -------------- > 2. The CERT Resource Record > > The CERT resource record (RR) has the structure given below. Its RR > type code is 37. > > 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | type | key tag | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | algorithm | / > +---------------+ certificate or CRL / > / / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > > Notes > ----- > In Section 2 (The CERT Resource Record) the table describing the wire format of the CERT RR is misaligned in such a way that it could lead to technical ambiguity of field positions within the packet structure. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4398 (draft-ietf-dnsext-rfc2538bis-09) > -------------------------------------- > Title : Storing Certificates in the Domain Name System (DNS) > Publication Date : March 2006 > Author(s) : S. Josefsson > Category : PROPOSED STANDARD > Source : DNS Extensions > Area : Internet > Stream : IETF > Verifying Party : IESG From owner-namedroppers@ops.ietf.org Fri Aug 13 07:24: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 559F93A69F7; Fri, 13 Aug 2010 07:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.705 X-Spam-Level: X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6, J_CHICKENPOX_64=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 e2smtmTlAutJ; Fri, 13 Aug 2010 07:24:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 569463A67AC; Fri, 13 Aug 2010 07:24:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojv9N-0008Ei-Qe for namedroppers-data0@psg.com; Fri, 13 Aug 2010 14:22:25 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojv9K-0008EB-OQ for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 14:22:23 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7DEMLDk006998 for ; Fri, 13 Aug 2010 10:22:21 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o7DEMLs3006997 for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 10:22:21 -0400 (EDT) (envelope-from namedroppers) Received: from [209.85.210.52] (helo=mail-pz0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjXNM-000ByH-Gc for namedroppers@ops.ietf.org; Thu, 12 Aug 2010 12:59:16 +0000 Received: by pzk27 with SMTP id 27so721790pzk.11 for ; Thu, 12 Aug 2010 05:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=CiCYSRZuM4f7Ovgl/ga7kTFyj+2qtGCkXXtaoVITII8=; b=EdNdW6mcdifOY1mgfbW8fluSnjAy2cQ0n+Y8VYHMdxmDNxWsIn4xenLTINthrzsSvn bhcq6yODrwwphhDJdVvfEZ+ZytSItnhVnl61IDltwSTg9rqBbjoDA1/rmQEmrb25jmvq i5f2W/cffBDn5OyX+sIxG9kR62e4+d+ZLYzC0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; b=dzIaaSY5eMHukGfhd9aFsNbVuX8nfyp5U6++Sfa7E+hIUgCnM0/W17nJRndh4UUKHZ 0w1a357l41d37cO2fmIzLPKO1xmDw0aFnildm6MMqiUs6T3Zd8fanm4qsxViapJ5bu1f wfdf6mO88dVfSEVpTsS0dObtycfmfAy3ilNVQ= Received: by 10.142.232.13 with SMTP id e13mr50797wfh.87.1281617955635; Thu, 12 Aug 2010 05:59:15 -0700 (PDT) Received: from zhanglikun ([218.241.109.24]) by mx.google.com with ESMTPS id g5sm1551928wfd.7.2010.08.12.05.59.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 12 Aug 2010 05:59:14 -0700 (PDT) From: "zhanglikun" To: Subject: Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") Date: Thu, 12 Aug 2010 20:59:13 +0800 Message-ID: <006001cb3a1e$2bd6fa10$8384ee30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs6HimaKNkUk/8RQly7BAuIEUtxIQ== Content-Language: zh-cn 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. ] I don't plan to add more arguments for the provision way, since the complexity it brings when comes to multiple-labels domain equivalence, which has been mentioned by former emails, it's o(a^n), instead xName is o(n) . Now let me go back to c+dname VS bname. If one zone has records: a.net. cname a.cn. a.net. dname b.com. user do the query with the following sequence: dig a.net. cname dig a.net. dname if the cache isn't aware of the new c+dname rules, will the second query will chase down to b.com.? it will try to chase down a dname record belonging to a.cn. rather than b.com. Except the c+dname has one rule: the rdata part of should be same. anther, when doing update, you have to be very careful to decide whether to remove/add c+dname or just one of them. Last, c+dname will double zone size, compared with bname. My point is +1 for bname. Anyway, this topic recall me to the added voice saying no to DNAME long before(five years ago or more), somebody said he had a complete dislike for the DNAME, not just the document but also the idea, even though the DNAME had born. :) Thanks Likun Zhang From owner-namedroppers@ops.ietf.org Fri Aug 13 07:46: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 A4FFA3A689B; Fri, 13 Aug 2010 07:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.826 X-Spam-Level: **** X-Spam-Status: No, score=4.826 tagged_above=-999 required=5 tests=[AWL=-1.318, BAYES_40=-0.185, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnvieuH+Vlao; Fri, 13 Aug 2010 07:46:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A9E23A68F8; Fri, 13 Aug 2010 07:46:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjvTI-000BL6-IO for namedroppers-data0@psg.com; Fri, 13 Aug 2010 14:43:00 +0000 Received: from [2001:500:60::65] (helo=mx.ams1.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjvTF-000BKY-Gm for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 14:42:57 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 6FC3C5F9891; Fri, 13 Aug 2010 14:42:41 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 5C243E6030; Fri, 13 Aug 2010 14:42:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C732D2E957F; Sat, 14 Aug 2010 00:42:35 +1000 (EST) To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <201008042142.o74LgRap031934@cichlid.raleigh.ibm.com> <05B243F724B2284986522B6ACD0504D7D3444A2AAF@EXVPMBX100-1.exc.icann.org> <20100804230904.GB4034@farside.isc.org> <05B243F724B2284986522B6ACD0504D7D3444A2CF6@EXVPMBX100-1.exc.icann.org> <20100805182146.GI38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D00@EXVPMBX100-1.exc.icann.org> <20100805183608.GJ38874@shinkuro.com> <05B243F724B2284986522B6ACD0504D7D3444A2D1B@EXVPMBX100-1.exc.icann.org> <20100810141322.GD52191@shinkuro.com> <3F9D6BF0A3BA40D5BA4044B7DC347FAA@LENOVO47E041CF> <20100810154446.GG52191@shinkuro.com> <4C63F9DF.4010104@nic.cz> <20100813021034.75ACE2D5113@drugs.dv.isc.org> <4C64F799.4050500@nic.cz> Subject: Re: [dnsext] Does DNSSEC mean BNAME is undeployable? In-reply-to: Your message of "Fri, 13 Aug 2010 09:43:21 +0200." <4C64F799.4050500@nic.cz> Date: Sat, 14 Aug 2010 00:42:35 +1000 Message-Id: <20100813144235.C732D2E957F@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4C64F799.4050500@nic.cz>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= writes: > On 13.8.2010 04:10, Mark Andrews wrote: > > In message<4C63F9DF.4010104@nic.cz>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= write > s: > >> On 10.8.2010 17:44, Andrew Sullivan wrote: > >>> In favour of that conclusion are things like qmail& its > >>> interpretation of CNAME; that line of argument could be productive, if > >>> someone wanted to investigate it. > >> > >> qmail delivered email to nic.dname.cz just fine. (Had to go thru all > >> the hoops and loops when building netqmail in chrooted environment. > >> Don't make me do that again...) > >> > >>>> the chairs said in the meeting that only half (?) of the servers support > d > >> name. > >>> > >>> So, to clarify, this is an issue with recursive resolvers that do not > >>> support DNAME. I didn't participate in the investigation, so the > >>> details will have to wait until Olafur gets back (unles Ondrej wants > >>> to chime in -- I think he was also involved?). But the key thing is > >>> to note that this is code base, not % of deployed systems. > >> > >> We tested some, but they all were fine using synthetized CNAMEs since > >> they don't support DNSSEC. > >> > >>> Moreover, the systems in question can't support DNSSEC properly, either. > >> > >> Yes, and the argument here is same for BNAME. If those servers didn't > >> get support for DNAME, they will not get support for BNAME either. And > >> if they get proper DNSSEC support (soon) they will likely get a DNAME > >> support. > >> > >>>> section 5.2 of bname draft addresses this problem. > >>>> > >>>> 5.2. BNAME alias algorithm identifiers > >>>> > >>>> > >>>> In order to prevent BNAME-unaware resolvers from attempting to > >>>> validate responses from BNAME-signed zones, this specification > >>>> allocates two new DNSKEY algorithm identifiers. Algorithm Y, DSA- > >>> > >>> Right, you're quite correct for taking me to task for not pointing > >>> this out. But this answer is still pretty bad, because what we're > >>> doing in that case is promoting a barrier to DNSSEC validation: if you > >>> don't have a BNAME-supporting validator, you don't get validation. > >>> This issue is part of why I'm anxious to get guidance. > >>> > >>> Also, the aliases are inadequate. You actually need an alias for > >>> every existing algorithm identifier. That means you need aliases for > >>> all the SHA2 variants and GOST as well (I'm willing to disregard MD5 > >>> because we think it oughtn't to be used anyway). > >> > >> And you need normal and BNAME for every future algorithm. Or do you > >> plan to make BNAME support mandatory for every new algorithm? > > > > I would expect it to be like NSEC3, new algorithms would also indicate > > BNAME support. If we had had known enough about DNSSEC DNAME's original > > introduction would have added algorithm aliases. The type code roll > > allowed us to do that a slightly different way. > > That might work now. But I see it as a bad precedent. If we setup this > as a usual way how to cope, we would have to create algorithm dupes for > every (non deprecated) algorithm to the date. This might grow huge. > Fortunately you don't have to do Cartesian product for all signaling, > but you can say that new signal also includes all preceding ones (ie. > support for BNAME includes support for DNAME and NSEC3). And how often do we make this sort of change to the DNS? DNAME was 10 years ago and we have no shortage of algorithm numbers. No we are not limited to 256. We just haven't defined how to encode algorithm numbers bigger than 254 we know that it is possible as we currently support a effectively infinite number of algorithms. > If this gets ever created we need something like a table with algorithm > numbers as lines and standards included in columns with fields > indicating support. It's already mess that you have some algorithms > named -NSEC3- and some not (SHA-2 family, GOST) > and they all include NSEC3 support. And you would have a set that indicate BNAME support along with NSEC3 and them some that don't, so what. BRSASHA1, BRSASHA256, BRSASHA512, BDSA, BGOST 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 Aug 13 08:05: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 27A813A68B2; Fri, 13 Aug 2010 08:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.441 X-Spam-Level: * X-Spam-Status: No, score=1.441 tagged_above=-999 required=5 tests=[AWL=-0.778, BAYES_40=-0.185, 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 Rm2jQusN4mIH; Fri, 13 Aug 2010 08:05:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5051B3A684A; Fri, 13 Aug 2010 08:05:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjvnX-000EK9-VS for namedroppers-data0@psg.com; Fri, 13 Aug 2010 15:03:55 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjvnV-000EJA-Ds for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 15:03:53 +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 939EEC56949; Fri, 13 Aug 2010 16:03:47 +0100 (BST) Date: Fri, 13 Aug 2010 16:03:47 +0100 From: Alex Bligh Reply-To: Alex Bligh To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= cc: Andrew Sullivan , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" Message-ID: <6569D35235547038CB2C4FED@Ximines.local> In-Reply-To: <4C6550FB.4040905@nic.cz> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <4C6542ED.1000700@nic.cz> <25187E64AF3BDAA68165A923@Ximines.local> <4C6550FB.4040905@nic.cz> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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: Ondrej, --On 13 August 2010 16:04:43 +0200 Ond=C5=99ej Sur=C3=BD = wrote: > For HTTPS you either: > > - don't use ssl for aliased domain names Not really an option if the idea is to make aliasing work > - dont' use aliases for domains where you need SSL You can't avoid that if your registry uses aliasing, can you? > - use SNI (Server Name Indication) the support is already there Does SNI have widescale deployment support? I thought it still required I*J*K*L different certificates (not that I am an https guru by any means). > - use this: > X509v3 Subject Alternative Name: > DNS:www.sury.org, DNS:sury.org Something like this is the only practical way to make all aliases behave in an equivalent manner (which was, as I understand it) the idea. > SMTP, SIP, etc. have either requirement for using canonical name (SMTP)=20 or > they have SRV records (SIP). SIP with SRV is less of a problem. HTTP (not S) still requires handling of the GET line, which will have to be written according to equivalence rules which may only be known to the registry (paf suggested this isn't an issue). --=20 Alex Bligh From owner-namedroppers@ops.ietf.org Fri Aug 13 08:34: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 340393A6A07; Fri, 13 Aug 2010 08:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 Ldyo4adbBRlb; Fri, 13 Aug 2010 08:34:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 405333A69F7; Fri, 13 Aug 2010 08:34:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjwDc-000IOX-5B for namedroppers-data0@psg.com; Fri, 13 Aug 2010 15:30:52 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjwDY-000IO1-Qa for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 15:30:48 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 77165A1021 for ; Fri, 13 Aug 2010 15:30:48 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] the method of avoiding signal in bname In-Reply-To: Your message of "Fri\, 13 Aug 2010 11\:05\:45 +0200." <4C650AE9.2030301@nic.cz> References: <481633111.17609@cnnic.cn> <4C650AE9.2030301@nic.cz> 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: Fri, 13 Aug 2010 15:30:48 +0000 Message-ID: <17956.1281713448@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, 13 Aug 2010 11:05:45 +0200 > From: Ond=C5=99ej Sur=C3=BD >=20 > You cannot avoid the signaling for the BNAME. You still need the > signaling for the BNAME support in the DNSSEC-validating resolver. i agree with this. BNAME-awareness would have to be signalled or else the initiator would only see synthesized CNAME. in this we'd be "like DNAME". > You need to treat the non-BNAME aware DNSSEC validating resolver as your > case number #1. And then you have a unsolvable problem with chained > resolvers. Because downstream BNAME-aware resolver will not be able to > see BNAME record after the upstream resolver has a synthesized CNAME in > the cache. I think this won't fly [RFC1925]. i don't know that it won't fly, but it's a deeper problem than DNAME had and may help us all understand why DNAME only affects its children not its owner. in any case, what you're saying would apply equally to C+D, for reasons i've stated about correct current assumptions in the installed base. From owner-namedroppers@ops.ietf.org Fri Aug 13 08:42: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 F41BE3A68CE; Fri, 13 Aug 2010 08:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 gCbnUSh18UEq; Fri, 13 Aug 2010 08:42:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D3C863A67EB; Fri, 13 Aug 2010 08:42:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjwMw-000JkQ-G4 for namedroppers-data0@psg.com; Fri, 13 Aug 2010 15:40: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.72 (FreeBSD)) (envelope-from ) id 1OjwMu-000Jjb-6A for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 15:40:28 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id E70A5A1043 for ; Fri, 13 Aug 2010 15:40:27 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" In-Reply-To: Your message of "Fri, 13 Aug 2010 10:33:45 +0100." References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Fri, 13 Aug 2010 15:40:27 +0000 Message-ID: <18374.1281714027@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, 13 Aug 2010 10:33:45 +0100 > From: Alex Bligh > > I agree that this is being driven partly (mostly?) by the > registry/registrar community. However, what I don't understand is that > even if we come up with a magic DNS aliasing solution so that Ai.Bj > always gives the same result as A1.B1, what is the use of it if it > doesn't work at the application layer too? number of users of web > browsers and email exceed number of users of dig by many orders of > magnitude. I have yet to find one application the "magic xNAME" proposal > would work with out the box. there's no way to get total sameness without application changes. consider an application who looks for the A and AAAA for an MX target, and then looks for PTR's for the resulting addresses, and insists that the one be found within the other. if the original name is Ai.Bj then there's not enough state in DNS itself to ensure that the final name is also Ai.Bj, it's going to be A1.B1. this example is not contrived. this yields a hard choice: add a constraint. require that Ai.Bj be normalized to A1.B1 before it is used either for DNS lookups or any host identity (like SMTP HELO). this means we wouldn't have true "sameness" across the names {A1.B1, Ai.Bj}, one would be a first class name, the other would be a second class name. both BNAME and SHADOW would create second class names in this sense, though only BNAME uses CNAME or CNAME-like technology to do it. the other hard choice would be to say, only new-style-alias-aware apps can see them. this is unthinkable due to the size of the installed base. From owner-namedroppers@ops.ietf.org Fri Aug 13 08:59: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 81D0A3A6971; Fri, 13 Aug 2010 08:59:52 -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: -97.33 X-Spam-Level: X-Spam-Status: No, score=-97.33 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.041, MSGID_FROM_MTA_HEADER=0.803, 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 kVAScM7iNydH; Fri, 13 Aug 2010 08:59:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7AC203A6803; Fri, 13 Aug 2010 08:59:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjwdM-000MHR-T2 for namedroppers-data0@psg.com; Fri, 13 Aug 2010 15:57:28 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjwdJ-000MGt-Eb for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 15:57:26 +0000 Received: (eyou send program); Fri, 13 Aug 2010 23:57:22 +0800 Message-ID: <481715042.08043@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, 13 Aug 2010 23:57:22 +0800 Message-ID: <208E0AC85B0343B3AA15E745B1FC7DA0@LENOVO47E041CF> From: "Jiankang YAO" To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Cc: References: <481540291.31022@cnnic.cn> <481690866.12897@cnnic.cn> Subject: Re: [dnsext] alias algorithm for bname and other new rrtype Fw: I-D Action:draft-yao-dnsext-alias-algorithm-00.txt Date: Fri, 13 Aug 2010 23:57:10 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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+DQpUbzogIkppYW5rYW5nIFlBTyIgPHlhb2prQGNubmljLmNuPg0K Q2M6IDxuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnPg0KU2VudDogRnJpZGF5LCBBdWd1c3QgMTMs IDIwMTAgNDo0OCBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIGFsaWFzIGFsZ29yaXRobSBmb3Ig Ym5hbWUgYW5kIG90aGVyIG5ldyBycnR5cGUgRnc6IEktRCBBY3Rpb246ZHJhZnQteWFvLWRuc2V4 dC1hbGlhcy1hbGdvcml0aG0tMDAudHh0DQoNCg0KPiBPbiAxMS44LjIwMTAgMTc6MjUsIEppYW5r YW5nIFlBTyB3cm90ZToNCj4+IG5zZWMzIG9yIGJuYW1lIGFuZCBtb3JlIGZ1dHVyZSBycnR5cGUg aGF2ZSB0byBkZWFsIHdpdGggdGhlIGRuc3NlYw0KPj4gcHJvYmxlbXMuIGFsaWFzIGFsZ29yaXRo bSBpZGVudGlmaWVyIGlzIG5lY2Vzc2FyeS4gdGhpcyBkb2N1bWVudA0KPj4gZGVzaWduIGEgdW5p dmVyaXNpYWwgbWV0aG9kIGZvciBhbGwgbmV3IHJydHlwZXMgaW4gZG5zc2VjLg0KPj4NCj4+IHdl IHdpbGwgbm90IG5lZWQgdG8gbmFtZSBhIGluZGl2aWR1YWwgYWxpYXMgYWxnb3JpdGhtIGlkZW50 aWZpZXJzIHRvDQo+PiBpbmRpdmlkdWFsIHJydHlwZS4NCj4gDQo+IFNvcnJ5LCBidXQgdGhhdCBJ LUQgZG9lc24ndCBtYWtlIGFueSBzZW5zZSBhdCBhbGwuDQo+IA0KPiBZb3Ugd3JpdGU6DQo+IA0K Pj4gQmFzZWQgb24gdGhlIHJ1bGUgb2YgZmlyc3QgY29tZSBmaXJzdCBzZXJ2ZWQsIHRoZSA4LWJp dCBhbGdvcml0aG0NCj4+IGFsbG9jYXRpb24gcG9vbCB3b3VsZCBzb29uIGJlIGV4aGF1c3RlZCBp ZiBtb3JlIGFuZCBtb3JlIG5ldyBSUlRZUEVzDQo+PiBhbmQgYWxnb3JpdGhtcyBoYWQgYXBwZWFy ZWQgaW4gdGhlIEROUyBwcm90b2NvbHMuDQo+IA0KPiBBbmQgdGhlbiB5b3UgZGVmaW5lIG5ldyAi YWxpYXNlcyIuICBCdXQgeW91IGRvbid0IHNheSBhbnl0aGluZyBhYm91dCB0aGUNCj4gY29kaW5n IHRoZSAiYWxpYXMiIHRvIHRoZSBSUlNJRy9ETlNLRVkgUlIgdHlwZXMuICBUaGUgZmllbGQgaW4g dGhvc2UNCj4gcmVjb3JkcyBhcmUgc3RpbGwgOC1iaXQgYW5kIHlvdSBjYW5ub3QgY3JlYXRlIGFs aWFzLWxhYmVscyBmcm9tIHRoZSB0aGluDQo+IGFpci4gIFlvdSBuZWVkIHRvIGNvZGUgaXQgaW50 byB0aGUgd2lyZSBmb3JtYXQgLSBlLmcuIGludG8gdGhlIGFsZ29yaXRobQ0KPiBmaWVsZCBvZiBE TlNLRVkvUlJTSUcgcmVjb3JkLiAgU28gdGhlIHByb2JsZW0geW91IGFyZSB0cnlpbmcgdG8gc29s dmUgaXMgDQo+IHN0aWxsIHRoZXJlLiAgT3IgYW0gSSBtaXNzaW5nIHNvbWV0aGluZz8gIEhvdyB3 aWxsIHlvdSBjb2RlIHRoZSAiYWxpYXMiIA0KPiB0byB0aGUgd2lyZSBmb3JtYXQuDQo+IA0KDQoN CnRoZSBjdXJyZW50IHJlc29sdmVycyB3aWxsIG5vdCBrbm93IHRoZSBhbGlhcy1hbGdvcml0aG0u DQp0aGUgbmV3IHJlc29sdmVycyBmb2xsb3cgdGhpcy4gdGhpcyBhbGlhcy1hbGcgbWF5IGJlIHVz ZWQgZm9yIGFueSBuZXcgcnJ0eXBlcy4NCm15IHVuZGVyc3RhbmRpbmcgaXMgdGhlIHByb2JsZW0g ZGlzYXBwZWFyLg0KDQpldmVyeSBhbGlhcy1hbGcgaGFzIHRoZSBuZXcgbnVtYmVyIGZyb20gaWFu YS4NCg0KDQo+DQo+PiBUaGUgdmFsaWRhdGluZyByZXNvbHZlciBmb2xsb3dpbmcgdGhpcyBzcGVj aWZpY2F0aW9uIE1VU1QgY2hlY2sgdGhlDQo+PiB0eXBlIGNvdmVyZWQgb2YgdGhlIFJSU0lHIGJl Zm9yZSB0aGUgdmVyaWZpY2F0aW9uLiAgT25seSB3aGVuIHRoZQ0KPj4gdmFsaWRhdGluZyByZXNv bHZlciBrbm93cyB0aGUgUlJUWVBFLCBpdCBjYW4gYmVnaW4gdG8gdmVyaWZ5IHRoZQ0KPj4gc2ln bmF0dXJlIG9mIHRoZSBSUlNJRy4gIE90aGVyd2lzZSwgdGhlIHZhbGlkYXRpbmcgcmVzb2x2ZXIg TVVTVA0KPj4gcmVnYXJkIHRoZSBSUlNJRyBpbiB3aGljaCB0aGUgdHlwZSBjb3ZlcmVkIGlzIHVu a25vd24gdG8gdGhlDQo+PiByZXNvbHZlciBhcyBpbnNlY3VyZSBpbnN0ZWFkIG9mIGJvZ3VzLg0K PiANCj4gQWxzbyBJIGFtIHZlcnkgYWZyYWlkIG9mIHRoaXMuICBJIGNvdWxkIGltYWdpbmUgYWxs IHNvcnQgb2YgInVwZ3JhZGUiIA0KPiBhdHRhY2tzIHdoZW4gYXR0YWNrZXIgd2lsbCBzcG9vZiBS UlRZUEUgbm90IGtub3cgdG8gdGhlIHJlc29sdmVyLCBidXQgDQo+IGtub3duIHRvIHRoZSBjbGll bnQuICBIZW5jZSBJIGNvbnNpZGVyIHRoaXMgcHJvcG9zYWwgdmVyeSBkYW5nZXJvdXMgdG8gDQo+ IHRoZSBETlNTRUMgc2VjdXJpdHkuDQo+IA0KDQp0aGlzIHdpbGwgbm90IGluY3JlYXNlIHRoZSBw b3NzaWJsZSBhdHRhY2sgeW91IG1ldGlvbmVkLg0KDQpmb3IgZXhhbXBsZSwgbWFueSBjdXJyZW50 IHJlc29sdmVycyBkbyBub3Qgc3VwcG9ydCBuc2VjMyBhbmQgRFNBLU5TRUMzLVNIQTEsDQoNCnRo ZSBhdHRhY2tlcnMgY2FuIHN0aWxsIHNwb29mIGFzIHRoZSBOU0VDMyB0eXBlIGFuZCAgRFNBLU5T RUMzLVNIQTEsDQp0aGUgICJ1cGdyYWRlIiAgYXR0YWNrcyB5b3UgbWVudGlvbmVkIHdpbGwgYXBw ZWFyLg0KDQoNCiANCj4gTy4NCj4gLS0gDQo+ICBPbmTFmWVqIFN1csO9DQo+ICB2ZWRvdWPDrSB2 w716a3VtdS9IZWFkIG9mIFImRCBkZXBhcnRtZW50DQo+ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICBDWi5OSUMsIHoucy5wLm8uICAgIC0tICAgIExhYm9y YXRvxZllIENaLk5JQw0KPiAgQW1lcmlja2EgMjMsIDEyMCAwMCBQcmFoYSAyLCBDemVjaCBSZXB1 YmxpYw0KPiAgbWFpbHRvOm9uZHJlai5zdXJ5QG5pYy5jeiAgICBodHRwOi8vbmljLmN6Lw0KPiAg dGVsOis0MjAuMjIyNzQ1MTEwICAgICAgIGZheDorNDIwLjIyMjc0NTExMg0KPiAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg== From owner-namedroppers@ops.ietf.org Fri Aug 13 09:00: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 A14D53A6A15; Fri, 13 Aug 2010 09:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.215 X-Spam-Level: X-Spam-Status: No, score=-101.215 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, J_CHICKENPOX_23=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 wBMQzQAARn7T; Fri, 13 Aug 2010 09:00:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 93C393A6A0E; Fri, 13 Aug 2010 09:00:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojwes-000MTD-UC for namedroppers-data0@psg.com; Fri, 13 Aug 2010 15:59:02 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojweq-000MSl-3l for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 15:59:00 +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 208AC734383; Fri, 13 Aug 2010 17:58:59 +0200 (CEST) Message-ID: <4C656BC2.1060006@nic.cz> Date: Fri, 13 Aug 2010 17:58:58 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Mark Andrews CC: Jiankang YAO , namedroppers@ops.ietf.org Subject: Re: [dnsext] the method of avoiding signal in bname References: <481633111.17609@cnnic.cn><4C650AE9.2030301@nic.cz> <20100813150009.7E0652E9804@drugs.dv.isc.org> In-Reply-To: <20100813150009.7E0652E9804@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 13.8.2010 17:00, Mark Andrews wrote: > In message<4C650AE9.2030301@nic.cz>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= writes: >> On 12.8.2010 19:12, Jiankang YAO wrote: >>> Dear all, >>> I proposed the following method for bname to avoid the signaling: >>> if the query is not dnssec query: >>> If the owner name of the bname is the suffix of the name queryed but >>> different, when preparing a response, a server performing a BNAME >>> substitution will in all cases include the relevant BNAME RR in the >>> answer section. A CNAME RR is synthesized and included in the answer >>> section. This will help the client to reach the correct DNS data. >>> >>> If the owner name of the bname is same with the name queryed, when >>> preparing a response, a server performing a BNAME substitution will >>> not include the relevant BNAME RR in the answer section unless the >>> type queryed is BNAME. A CNAME RR will be synthesized and included >>> in the answer section unless the type queryed is BNAME or the query >>> is the DNSSEC query. >>> if the query is the dnssec query: >>> only the bname is returned to the resolvers from the servers. >>> this assumes that: if the resolvers does not recognize the bname but >>> want dnssec, the synthesized >>> cname is not useful for them. >>> if the resolvers does recognize the bname and want dnssec, the resolvers >>> can do the >>> next query without the synthesized >>> cname. >>> through the method above, there will never issue cname and bname >>> together with the same owner name. >> >> >> >>> if bname still needs the alias algorithm, it will follow the difiniton >>> of draft-yao-dnsext-alias-algorithm-00.txt to avoid adding >>> too many alias algorithms for the new rrtypes. >> >> You cannot avoid the signaling for the BNAME. You still need the >> signaling for the BNAME support in the DNSSEC-validating resolver. >> >> You need to treat the non-BNAME aware DNSSEC validating resolver as your >> case number #1. And then you have a unsolvable problem with chained >> resolvers. Because downstream BNAME-aware resolver will not be able to >> see BNAME record after the upstream resolver has a synthesized CNAME in >> the cache. I think this won't fly [RFC1925]. > > NSEC3 doesn't work through chained nameservers that don't support NSEC3 > but we still deployed NSEC3. > > DNSSEC doesn't work through chained nameserves that don't support DNSSEC > but we still deployed DNSSEC. > > Now you are saying that we can't deploy BNAME because it won't work through > chained nameservers that don't support BNAME. Sorry that just doesn't pass > the laugh test as a reason to block it. Way too many counter examples here. Mark, please read the original Yao's proposal to know what "this" means before you turn your mean-mode on next time. I am not arguing against BNAME in general, I am merely saying that "the method of avoiding signal in bname" as proposed in this email is flawed and you probably want to send BNAME along with synthesized CNAME. Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 13 09:02: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 B7E183A684A; Fri, 13 Aug 2010 09:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.144 X-Spam-Level: X-Spam-Status: No, score=0.144 tagged_above=-999 required=5 tests=[AWL=0.639, 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 Q5SJ2v+Ok3e6; Fri, 13 Aug 2010 09:02:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B08D3A6407; Fri, 13 Aug 2010 09:02:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjwgU-000Mo6-6o for namedroppers-data0@psg.com; Fri, 13 Aug 2010 16:00:42 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjwgR-000Mnd-QK for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 16:00:40 +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 2073BC56949; Fri, 13 Aug 2010 17:00:37 +0100 (BST) Date: Fri, 13 Aug 2010 17:00:37 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" Message-ID: <1003B23DCEFA6491EC639CB6@Ximines.local> In-Reply-To: <18374.1281714027@nsa.vix.com> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <18374.1281714027@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 13 August 2010 15:40:27 +0000 Paul Vixie wrote: > there's no way to get total sameness without application changes. I agree. So: 1. we can't get total sameness without application changes 2. many of those applications are going to require "manual provisioning hacks" which are dependent upon knowing how aliasing further up the tree works, which removes at least some of the benefits of xNAME My question is: Do these together mean the advantage of xNAME over doing the "manual provisioning hack" for DNS as well as for the applications is outweighed by protocol entropy caused? If the answer is "no, it is not outweighed", xNAME needs to be a LOT better than manual provisioning (hence the criterion of O(n) provisioning I suggested). -- Alex Bligh From owner-namedroppers@ops.ietf.org Fri Aug 13 09:21: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 A02F63A6A18; Fri, 13 Aug 2010 09:21:28 -0700 (PDT) X-Quarantine-ID: <51zxCTW6SsI9> 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: -97.41 X-Spam-Level: X-Spam-Status: No, score=-97.41 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.041, MSGID_FROM_MTA_HEADER=0.803, 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 51zxCTW6SsI9; Fri, 13 Aug 2010 09:21:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 376693A6A0E; Fri, 13 Aug 2010 09:21:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjwxN-000PSd-MC for namedroppers-data0@psg.com; Fri, 13 Aug 2010 16:18:09 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjwxK-000PRy-5o for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 16:18:06 +0000 Received: (eyou send program); Sat, 14 Aug 2010 00:17:57 +0800 Message-ID: <481716277.31535@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 14 Aug 2010 00:17:57 +0800 Message-ID: <4F09F62F6DB1427C8C5FBEA61069CC8E@LENOVO47E041CF> From: "Jiankang YAO" To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , "Mark Andrews" Cc: References: <481633111.17609@cnnic.cn><4C650AE9.2030301@nic.cz> <20100813150009.7E0652E9804@drugs.dv.isc.org> <4C656BC2.1060006@nic.cz> Subject: Re: [dnsext] the method of avoiding signal in bname Date: Sat, 14 Aug 2010 00:18:16 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 YzogIkppYW5rYW5nIFlBTyIgPHlhb2prQGNubmljLmNuPjsgPG5hbWVkcm9wcGVyc0BvcHMuaWV0 Zi5vcmc+DQpTZW50OiBGcmlkYXksIEF1Z3VzdCAxMywgMjAxMCAxMTo1OCBQTQ0KU3ViamVjdDog UmU6IFtkbnNleHRdIHRoZSBtZXRob2Qgb2YgYXZvaWRpbmcgc2lnbmFsIGluIGJuYW1lDQoNCg0K PiBPbiAxMy44LjIwMTAgMTc6MDAsIE1hcmsgQW5kcmV3cyB3cm90ZToNCj4+IEluIG1lc3NhZ2U8 NEM2NTBBRTkuMjAzMDMwMUBuaWMuY3o+LCA9P1VURi04P0I/VDI1a3habGxhaUJUZFhMRHZRPT0/ PSB3cml0ZXM6DQo+Pj4gT24gMTIuOC4yMDEwIDE5OjEyLCBKaWFua2FuZyBZQU8gd3JvdGU6DQo+ Pj4+IERlYXIgYWxsLA0KPj4+PiBJIHByb3Bvc2VkIHRoZSBmb2xsb3dpbmcgbWV0aG9kIGZvciBi bmFtZSB0byBhdm9pZCB0aGUgc2lnbmFsaW5nOg0KPj4+PiBpZiB0aGUgcXVlcnkgaXMgbm90IGRu c3NlYyBxdWVyeToNCj4+Pj4gSWYgdGhlIG93bmVyIG5hbWUgb2YgdGhlIGJuYW1lIGlzIHRoZSBz dWZmaXggb2YgdGhlIG5hbWUgcXVlcnllZCBidXQNCj4+Pj4gZGlmZmVyZW50LCB3aGVuIHByZXBh cmluZyBhIHJlc3BvbnNlLCBhIHNlcnZlciBwZXJmb3JtaW5nIGEgQk5BTUUNCj4+Pj4gc3Vic3Rp dHV0aW9uIHdpbGwgaW4gYWxsIGNhc2VzIGluY2x1ZGUgdGhlIHJlbGV2YW50IEJOQU1FIFJSIGlu IHRoZQ0KPj4+PiBhbnN3ZXIgc2VjdGlvbi4gQSBDTkFNRSBSUiBpcyBzeW50aGVzaXplZCBhbmQg aW5jbHVkZWQgaW4gdGhlIGFuc3dlcg0KPj4+PiBzZWN0aW9uLiBUaGlzIHdpbGwgaGVscCB0aGUg Y2xpZW50IHRvIHJlYWNoIHRoZSBjb3JyZWN0IEROUyBkYXRhLg0KPj4+Pg0KPj4+PiBJZiB0aGUg b3duZXIgbmFtZSBvZiB0aGUgYm5hbWUgaXMgc2FtZSB3aXRoIHRoZSBuYW1lIHF1ZXJ5ZWQsIHdo ZW4NCj4+Pj4gcHJlcGFyaW5nIGEgcmVzcG9uc2UsIGEgc2VydmVyIHBlcmZvcm1pbmcgYSBCTkFN RSBzdWJzdGl0dXRpb24gd2lsbA0KPj4+PiBub3QgaW5jbHVkZSB0aGUgcmVsZXZhbnQgQk5BTUUg UlIgaW4gdGhlIGFuc3dlciBzZWN0aW9uIHVubGVzcyB0aGUNCj4+Pj4gdHlwZSBxdWVyeWVkIGlz IEJOQU1FLiBBIENOQU1FIFJSIHdpbGwgYmUgc3ludGhlc2l6ZWQgYW5kIGluY2x1ZGVkDQo+Pj4+ IGluIHRoZSBhbnN3ZXIgc2VjdGlvbiB1bmxlc3MgdGhlIHR5cGUgcXVlcnllZCBpcyBCTkFNRSBv ciB0aGUgcXVlcnkNCj4+Pj4gaXMgdGhlIEROU1NFQyBxdWVyeS4NCj4+Pj4gaWYgdGhlIHF1ZXJ5 IGlzIHRoZSBkbnNzZWMgcXVlcnk6DQo+Pj4+IG9ubHkgdGhlIGJuYW1lIGlzIHJldHVybmVkIHRv IHRoZSByZXNvbHZlcnMgZnJvbSB0aGUgc2VydmVycy4NCj4+Pj4gdGhpcyBhc3N1bWVzIHRoYXQ6 IGlmIHRoZSByZXNvbHZlcnMgZG9lcyBub3QgcmVjb2duaXplIHRoZSBibmFtZSBidXQNCj4+Pj4g d2FudCBkbnNzZWMsIHRoZSBzeW50aGVzaXplZA0KPj4+PiBjbmFtZSBpcyBub3QgdXNlZnVsIGZv ciB0aGVtLg0KPj4+PiBpZiB0aGUgcmVzb2x2ZXJzIGRvZXMgcmVjb2duaXplIHRoZSBibmFtZSBh bmQgd2FudCBkbnNzZWMsIHRoZSByZXNvbHZlcnMNCj4+Pj4gY2FuIGRvIHRoZQ0KPj4+PiBuZXh0 IHF1ZXJ5IHdpdGhvdXQgdGhlIHN5bnRoZXNpemVkDQo+Pj4+IGNuYW1lLg0KPj4+PiB0aHJvdWdo IHRoZSBtZXRob2QgYWJvdmUsIHRoZXJlIHdpbGwgbmV2ZXIgaXNzdWUgY25hbWUgYW5kIGJuYW1l DQo+Pj4+IHRvZ2V0aGVyIHdpdGggdGhlIHNhbWUgb3duZXIgbmFtZS4NCj4+Pg0KPj4+DQo+Pj4N Cj4+Pj4gaWYgYm5hbWUgc3RpbGwgbmVlZHMgdGhlIGFsaWFzIGFsZ29yaXRobSwgaXQgd2lsbCBm b2xsb3cgdGhlIGRpZmluaXRvbg0KPj4+PiBvZiBkcmFmdC15YW8tZG5zZXh0LWFsaWFzLWFsZ29y aXRobS0wMC50eHQgdG8gYXZvaWQgYWRkaW5nDQo+Pj4+IHRvbyBtYW55IGFsaWFzIGFsZ29yaXRo bXMgZm9yIHRoZSBuZXcgcnJ0eXBlcy4NCj4+Pg0KPj4+IFlvdSBjYW5ub3QgYXZvaWQgdGhlIHNp Z25hbGluZyBmb3IgdGhlIEJOQU1FLiAgWW91IHN0aWxsIG5lZWQgdGhlDQo+Pj4gc2lnbmFsaW5n IGZvciB0aGUgQk5BTUUgc3VwcG9ydCBpbiB0aGUgRE5TU0VDLXZhbGlkYXRpbmcgcmVzb2x2ZXIu DQo+Pj4NCj4+PiBZb3UgbmVlZCB0byB0cmVhdCB0aGUgbm9uLUJOQU1FIGF3YXJlIEROU1NFQyB2 YWxpZGF0aW5nIHJlc29sdmVyIGFzIHlvdXINCj4+PiBjYXNlIG51bWJlciAjMS4gIEFuZCB0aGVu IHlvdSBoYXZlIGEgdW5zb2x2YWJsZSBwcm9ibGVtIHdpdGggY2hhaW5lZA0KPj4+IHJlc29sdmVy cy4gIEJlY2F1c2UgZG93bnN0cmVhbSBCTkFNRS1hd2FyZSByZXNvbHZlciB3aWxsIG5vdCBiZSBh YmxlIHRvDQo+Pj4gc2VlIEJOQU1FIHJlY29yZCBhZnRlciB0aGUgdXBzdHJlYW0gcmVzb2x2ZXIg aGFzIGEgc3ludGhlc2l6ZWQgQ05BTUUgaW4NCj4+PiB0aGUgY2FjaGUuICBJIHRoaW5rIHRoaXMg d29uJ3QgZmx5IFtSRkMxOTI1XS4NCj4+DQo+PiBOU0VDMyBkb2Vzbid0IHdvcmsgdGhyb3VnaCBj aGFpbmVkIG5hbWVzZXJ2ZXJzIHRoYXQgZG9uJ3Qgc3VwcG9ydCBOU0VDMw0KPj4gYnV0IHdlIHN0 aWxsIGRlcGxveWVkIE5TRUMzLg0KPj4NCj4+IEROU1NFQyBkb2Vzbid0IHdvcmsgdGhyb3VnaCBj aGFpbmVkIG5hbWVzZXJ2ZXMgdGhhdCBkb24ndCBzdXBwb3J0IEROU1NFQw0KPj4gYnV0IHdlIHN0 aWxsIGRlcGxveWVkIEROU1NFQy4NCj4+DQo+PiBOb3cgeW91IGFyZSBzYXlpbmcgdGhhdCB3ZSBj YW4ndCBkZXBsb3kgQk5BTUUgYmVjYXVzZSBpdCB3b24ndCB3b3JrIHRocm91Z2gNCj4+IGNoYWlu ZWQgbmFtZXNlcnZlcnMgdGhhdCBkb24ndCBzdXBwb3J0IEJOQU1FLiAgU29ycnkgdGhhdCBqdXN0 IGRvZXNuJ3QgcGFzcw0KPj4gdGhlIGxhdWdoIHRlc3QgYXMgYSByZWFzb24gdG8gYmxvY2sgaXQu ICBXYXkgdG9vIG1hbnkgY291bnRlciBleGFtcGxlcyBoZXJlLg0KPiANCj4gTWFyaywgcGxlYXNl IHJlYWQgdGhlIG9yaWdpbmFsIFlhbydzIHByb3Bvc2FsIHRvIGtub3cgd2hhdCAidGhpcyIgbWVh bnMgDQo+IGJlZm9yZSB5b3UgdHVybiB5b3VyIG1lYW4tbW9kZSBvbiBuZXh0IHRpbWUuICBJIGFt IG5vdCBhcmd1aW5nIGFnYWluc3QgDQo+IEJOQU1FIGluIGdlbmVyYWwsIEkgYW0gbWVyZWx5IHNh eWluZyB0aGF0ICJ0aGUgbWV0aG9kIG9mIGF2b2lkaW5nIHNpZ25hbCANCj4gaW4gYm5hbWUiIGFz IHByb3Bvc2VkIGluIHRoaXMgZW1haWwgaXMgZmxhd2VkIGFuZCB5b3UgcHJvYmFibHkgd2FudCB0 byANCj4gc2VuZCBCTkFNRSBhbG9uZyB3aXRoIHN5bnRoZXNpemVkIENOQU1FLg0KPiANCg0KV2Ug YXBwcmVjaWF0ZSB0aGUgQ29uc3RydWN0aXZlIFByb3Bvc2FsIG9yIHN1Z2dlc3Rpb24gb3IgY29t bWVudHMgdG8gaW1wcm92ZSB0aGUgYm5hbWUuDQoNCg0KPiBPbmRyZWoNCj4gLS0gDQo+ICBPbmTF mWVqIFN1csO9DQo+ICB2ZWRvdWPDrSB2w716a3VtdS9IZWFkIG9mIFImRCBkZXBhcnRtZW50DQo+ ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICBDWi5OSUMs IHoucy5wLm8uICAgIC0tICAgIExhYm9yYXRvxZllIENaLk5JQw0KPiAgQW1lcmlja2EgMjMsIDEy MCAwMCBQcmFoYSAyLCBDemVjaCBSZXB1YmxpYw0KPiAgbWFpbHRvOm9uZHJlai5zdXJ5QG5pYy5j eiAgICBodHRwOi8vbmljLmN6Lw0KPiAgdGVsOis0MjAuMjIyNzQ1MTEwICAgICAgIGZheDorNDIw LjIyMjc0NTExMg0KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPg== From owner-namedroppers@ops.ietf.org Fri Aug 13 09:24: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 E15AB3A6A18; Fri, 13 Aug 2010 09:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.244 X-Spam-Level: X-Spam-Status: No, score=-101.244 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, J_CHICKENPOX_23=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 YTtHS-rn2gMG; Fri, 13 Aug 2010 09:24:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 903563A6407; Fri, 13 Aug 2010 09:24:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojx2F-00008D-M2 for namedroppers-data0@psg.com; Fri, 13 Aug 2010 16:23:11 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojx2C-00007Z-Fq for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 16:23:08 +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 A044E7343E2; Fri, 13 Aug 2010 18:23:07 +0200 (CEST) Message-ID: <4C65716B.6010306@nic.cz> Date: Fri, 13 Aug 2010 18:23:07 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jiankang YAO CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] alias algorithm for bname and other new rrtype Fw: I-D Action:draft-yao-dnsext-alias-algorithm-00.txt References: <481540291.31022@cnnic.cn> <481690866.12897@cnnic.cn> <481715042.08043@cnnic.cn> In-Reply-To: <481715042.08043@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 13.8.2010 17:57, Jiankang YAO wrote: > > ----- Original Message ----- > From: "Ondřej Surý" > To: "Jiankang YAO" > Cc: > Sent: Friday, August 13, 2010 4:48 PM > Subject: Re: [dnsext] alias algorithm for bname and other new rrtype Fw: I-D Action:draft-yao-dnsext-alias-algorithm-00.txt > > >> On 11.8.2010 17:25, Jiankang YAO wrote: >>> nsec3 or bname and more future rrtype have to deal with the dnssec >>> problems. alias algorithm identifier is necessary. this document >>> design a univerisial method for all new rrtypes in dnssec. >>> >>> we will not need to name a individual alias algorithm identifiers to >>> individual rrtype. >> >> Sorry, but that I-D doesn't make any sense at all. >> >> You write: >> >>> Based on the rule of first come first served, the 8-bit algorithm >>> allocation pool would soon be exhausted if more and more new RRTYPEs >>> and algorithms had appeared in the DNS protocols. >> >> And then you define new "aliases". But you don't say anything about the >> coding the "alias" to the RRSIG/DNSKEY RR types. The field in those >> records are still 8-bit and you cannot create alias-labels from the thin >> air. You need to code it into the wire format - e.g. into the algorithm >> field of DNSKEY/RRSIG record. So the problem you are trying to solve is >> still there. Or am I missing something? How will you code the "alias" >> to the wire format. >> > > the current resolvers will not know the alias-algorithm. > the new resolvers follow this. this alias-alg may be used for any new rrtypes. > my understanding is the problem disappear. Sorry, but I still don't get it. Maybe give me an example of adding two consecutive RRTYPEs following the rules you propose: 1. BNAME 2. YNAME How many new algorithms numbers (and names) will you have and what happens if: 1. you introduce BNAME 2. you introduce new algorithm called f.e. DEXTER 3. you introduce YNAME > every alias-alg has the new number from iana. So it doesn't solve the 8-bit problem. >>> The validating resolver following this specification MUST check the >>> type covered of the RRSIG before the verification. Only when the >>> validating resolver knows the RRTYPE, it can begin to verify the >>> signature of the RRSIG. Otherwise, the validating resolver MUST >>> regard the RRSIG in which the type covered is unknown to the >>> resolver as insecure instead of bogus. >> >> Also I am very afraid of this. I could imagine all sort of "upgrade" >> attacks when attacker will spoof RRTYPE not know to the resolver, but >> known to the client. Hence I consider this proposal very dangerous to >> the DNSSEC security. >> > > this will not increase the possible attack you metioned. > > for example, many current resolvers do not support nsec3 and DSA-NSEC3-SHA1, > > the attackers can still spoof as the NSEC3 type and DSA-NSEC3-SHA1, > the "upgrade" attacks you mentioned will appear. No it won't because it's secured by DS record in the parent zone. So you are either secure (because the resolver support the algorithm) or you are insecure (because your resolver doesn't support the algorithm). But the attacker cannot change that for individual RRTYPEs. O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 13 10:10: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 D3BA23A682A; Fri, 13 Aug 2010 10:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.077 X-Spam-Level: X-Spam-Status: No, score=-100.077 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 hwdBQUbM-JCI; Fri, 13 Aug 2010 10:10:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B4993A6805; Fri, 13 Aug 2010 10:10:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjxiF-0005XW-De for namedroppers-data0@psg.com; Fri, 13 Aug 2010 17:06:35 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjxiD-0005X1-1S for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 17:06: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 690CE1ECB41D for ; Fri, 13 Aug 2010 17:06:31 +0000 (UTC) Date: Fri, 13 Aug 2010 13:06:29 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] The succinct version of the argument for "do nothing" (was: [dnsext] DNSEXT charter and treating DNS names as "the same") Message-ID: <20100813170629.GB68767@shinkuro.com> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <4C6542ED.1000700@nic.cz> <25187E64AF3BDAA68165A923@Ximines.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25187E64AF3BDAA68165A923@Ximines.local> 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, Aug 13, 2010 at 02:26:56PM +0100, Alex Bligh wrote: > My suspicion is that it is all but impossible to solve at the > application layer, and that means there is little point causing > protocol entropy at the DNS layer. I'd quite like to be proved > wrong on this. I want to highlight that paragraph, because it is a concise version of an objection we've heard a few times in this debate. This WG is responsible for the DNS protocol, and we have to make a trade-off: is the additional complexity we propose to add going to be worth it? The "worth it" question was the reason I was aiming at applications area people in particular in Maastricht. I agree that the pressure to add these aliasing features is coming from the registry/registrar (and other zone operators, if you make that distinction) community. But as keepers of the protocol, we need not just to respond to direct users of the DNS but also to the question, "Will this be usable? Is the additional complexity going to benefit us overall?" Some are arguing (as Alex does nicely above) that the answer seems to be no. For my part, my answer is, "I don't know." But speaking personally, I am reluctant to make a change to any protocol in order to get a benefit I have reason to doubt will be attainable. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Aug 13 10:30: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 B44DF3A67E7; Fri, 13 Aug 2010 10:30:37 -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 NqvAZ+1K2RpW; Fri, 13 Aug 2010 10:30:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B05E3A6A51; Fri, 13 Aug 2010 10:30:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojy2I-0008rz-Lw for namedroppers-data0@psg.com; Fri, 13 Aug 2010 17:27:18 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojy2G-0008ra-2C for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 17:27:16 +0000 Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o7DHQxHQ028069 for ; Fri, 13 Aug 2010 13:26:59 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 13 Aug 2010 13:26:59 -0400 From: "Rose, Scott W." To: Namedroppers Date: Fri, 13 Aug 2010 13:26:58 -0400 Subject: Re: [dnsext] rfc2672-dname-bis: NXDOMAIN rcode question Thread-Topic: [dnsext] rfc2672-dname-bis: NXDOMAIN rcode question Thread-Index: Acs7DLAZVQdW6cGITJGwpHTwRtnavA== Message-ID: <7F2F70D3-34B1-4C69-ABB1-42B0DA970064@nist.gov> References: <4C640A78.50008@nlnetlabs.nl> <34062.1281627498@nsa.vix.com> <38094.1281631254@nsa.vix.com> In-Reply-To: <38094.1281631254@nsa.vix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: How about the following: When an xNAME chain is followed, all but the last query cycle necessarily had no error. The RCODE in the ultimate DNS response MUST BE set based on the final query cycle leading to that response as long as the following holds: * The RD bit is set in the original query OR * The RD bit is not set in the original query AND * The AA bit is set in the response AND * The final target name terminating the xNAME chain is in-bailiwick or in another zone for which the zone is authoritative. AND * The Answer section is not empty. In other words, if the xNAME chain was terminated by an error, it will be that error code. If the xNAME chain terminated without error, it will be zero. If the above conditions do not hold, the error code MUST be zero. /end Very rough text, but trying to nail down a solution so we can move forward. Of course, there is still the option of doing nothing, and letting DNAME-bis advance as is (on this point). Scott On Aug 12, 2010, at 12:40 PM, Paul Vixie wrote: >> Date: Thu, 12 Aug 2010 12:16:27 -0400 >> From: Donald Eastlake >> >> So why don't we just adopt >> https://datatracker.ietf.org/doc/draft-eastlake-dnsext-xnamercode/ >> with option B selected in Section 3. I wrote this so we could nail this >> down. > > that doesn't (yet?) describe the difference between RD=1 (where the rcode > is final and definitive) vs. RD=0,AA=1 where the rcode is only definitive > if ANCOUNT<>0 and the final name is in-bailiwick. > =================================== Scott Rose NIST scottr@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =================================== From owner-namedroppers@ops.ietf.org Fri Aug 13 10:51: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 B1C5B3A6A83; Fri, 13 Aug 2010 10:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.384 X-Spam-Level: X-Spam-Status: No, score=0.384 tagged_above=-999 required=5 tests=[AWL=-1.221, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_65=0.6, 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 XB1k67STR5nF; Fri, 13 Aug 2010 10:50:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B3593A635F; Fri, 13 Aug 2010 10:50:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjyL6-000BRa-7Z for namedroppers-data0@psg.com; Fri, 13 Aug 2010 17:46:44 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjyL3-000BR9-8i for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 17:46:42 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7DHkdFq008734 for ; Fri, 13 Aug 2010 13:46:39 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o7DHkdcY008733 for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 13:46:39 -0400 (EDT) (envelope-from namedroppers) Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ojwvy-000PHE-Tm for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 16:16:43 +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 AC46273438D; Fri, 13 Aug 2010 18:16:41 +0200 (CEST) Message-ID: <4C656FE8.3090003@nic.cz> Date: Fri, 13 Aug 2010 18:16:40 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] the method of avoiding signal in bname References: <481633111.17609@cnnic.cn> <4C650AE9.2030301@nic.cz> <17956.1281713448@nsa.vix.com> In-Reply-To: <17956.1281713448@nsa.vix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: On 13.8.2010 17:30, Paul Vixie wrote: >> You need to treat the non-BNAME aware DNSSEC validating resolver as >> your case number #1. And then you have a unsolvable problem with >> chained resolvers. Because downstream BNAME-aware resolver will >> not be able to see BNAME record after the upstream resolver has a >> synthesized CNAME in the cache. I think this won't fly [RFC1925]. > > i don't know that it won't fly, but it's a deeper problem than DNAME > had and may help us all understand why DNAME only affects its > children not its owner. I agree it's a deeper problem. > in any case, what you're saying would apply equally to C+D, for > reasons i've stated about correct current assumptions in the > installed base. Yes. And I think you cannot avoid a situation where you will see a CNAME and xNAME together in the same cache (or answer section). Maybe (and really maybe as I haven't put much thought into it) this could be somehow combined with RD=1 bit. Ie. RD=1 DO=0 will see only synthesized CNAMEs. Applies both to C+D and B. So for: -=-=-=-=- C+DNAME -=-=-=-=- Q= IN A RD=* DO=* CNAME Q=www. IN A RD=1 DO=0 www. sCNAME RD=0 DO=0 www. sCNAME RD=1 DO=1 www. sCNAME+ DNAME RD=0 DO=1 DNAME (That would mean that the RD=0 DO=1 must do DNAME processing, so the other option is keep status quo and for DO=1 send sCNAME along with DNAME.) -=-=-=-=- BNAME -=-=-=-=- Q= IN A RD=1 DO=0 BO=0 sCNAME RD=* DO=* BO=0 sCNAME+BNAME RD=0 DO=* BO=1 BNAME RD=1 DO=* BO=1 sCNAME+BNAME Q=www. IN A RD=1 DO=0 BO=0 www. sCNAME RD=* DO=* BO=0 www. sCNAME + BNAME RD=0 DO=* BO=1 BNAME RD=1 DO=* BO=1 www. CNAME + BNAME (Again the RD=0 BO=1 needs resolver side processing...) O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Aug 13 10:56: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 EAD123A6805; Fri, 13 Aug 2010 10:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 IbbN9Gl+zwr1; Fri, 13 Aug 2010 10:56:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A1EC03A635F; Fri, 13 Aug 2010 10:56:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjyRT-000CKs-3Y for namedroppers-data0@psg.com; Fri, 13 Aug 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.72 (FreeBSD)) (envelope-from ) id 1OjyRQ-000CKU-Vk for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 17:53:17 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id AD649A1031 for ; Fri, 13 Aug 2010 17:53:16 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" In-Reply-To: Your message of "Fri, 13 Aug 2010 17:00:37 +0100." <1003B23DCEFA6491EC639CB6@Ximines.local> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <18374.1281714027@nsa.vix.com> <1003B23DCEFA6491EC639CB6@Ximines.local> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Fri, 13 Aug 2010 17:53:16 +0000 Message-ID: <26141.1281721996@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, 13 Aug 2010 17:00:37 +0100 > From: Alex Bligh > > > there's no way to get total sameness without application changes. > > I agree. So: > 1. we can't get total sameness without application changes > 2. many of those applications are going to require "manual > provisioning hacks" which are dependent upon knowing how > aliasing further up the tree works, which removes at least > some of the benefits of xNAME i don't think the changes needed in apps should be called "manual provisioning hacks". that would misconstrue them as "similar to what ICANN is telling IDN TLD operators to do today" and they are not (similar): both in what's being changed (software) and in who is doing the changing (developers) and in the scalability (future proofing vs. unending manual labour). > My question is: > Do these together mean the advantage of xNAME over doing the > "manual provisioning hack" for DNS as well as for the > applications is outweighed by protocol entropy caused? i think that question is nonsequitur, given the lack of similarity between the thing IDN TLD operators do today, vs. what developers of DNS apps would have to do. (see above.) > If the answer is "no, it is not outweighed", xNAME needs to be > a LOT better than manual provisioning (hence the criterion > of O(n) provisioning I suggested). paul From owner-namedroppers@ops.ietf.org Fri Aug 13 11:00: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 EE8483A67F3; Fri, 13 Aug 2010 11:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.546 X-Spam-Level: X-Spam-Status: No, score=-99.546 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, 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 QVC1xQEkG4dN; Fri, 13 Aug 2010 11:00:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 07ED73A635F; Fri, 13 Aug 2010 11:00:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjyVe-000CzJ-NR for namedroppers-data0@psg.com; Fri, 13 Aug 2010 17:57:38 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjyVc-000CyX-80 for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 17:57:36 +0000 Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7DHvY3o097552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 10:57:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100813170629.GB68767@shinkuro.com> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <4C6542ED.1000700@nic.cz> <25187E64AF3BDAA68165A923@Ximines.local> <20100813170629.GB68767@shinkuro.com> Date: Fri, 13 Aug 2010 10:57:31 -0700 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] The succinct version of the argument for "do nothing" (was: [dnsext] DNSEXT charter and treating DNS names as "the same") 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 1:06 PM -0400 8/13/10, Andrew Sullivan wrote: >On Fri, Aug 13, 2010 at 02:26:56PM +0100, Alex Bligh wrote: >> My suspicion is that it is all but impossible to solve at the >> application layer, and that means there is little point causing >> protocol entropy at the DNS layer. I'd quite like to be proved >> wrong on this. > >I want to highlight that paragraph, because it is a concise version of >an objection we've heard a few times in this debate. > >This WG is responsible for the DNS protocol, and we have to make a >trade-off: is the additional complexity we propose to add going to be >worth it? > >The "worth it" question was the reason I was aiming at applications >area people in particular in Maastricht. I agree that the pressure to >add these aliasing features is coming from the registry/registrar (and >other zone operators, if you make that distinction) community. But as >keepers of the protocol, we need not just to respond to direct users >of the DNS but also to the question, "Will this be usable? Is the >additional complexity going to benefit us overall?" > >Some are arguing (as Alex does nicely above) that the answer seems to >be no. For my part, my answer is, "I don't know." But speaking >personally, I am reluctant to make a change to any protocol in order >to get a benefit I have reason to doubt will be attainable. Another way to look at this is that, unless the users of the change we are going to make agree to it, don't do it. We didn't get any significant application area input[*] in Maastricht, even after asking for it, so we truly don't know. Given that, I propose we don't start working on any line of solutions that will be useless without effort from the users. --Paul Hoffman [*] I don't consider the app input from John Klensin and I to be enough to be considered "significant", particularly because we mostly discussed a previous effort that died due to lack of input. From owner-namedroppers@ops.ietf.org Fri Aug 13 11:12: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 EFFD63A6884; Fri, 13 Aug 2010 11:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, J_CHICKENPOX_18=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 VSsdp3uN1jtK; Fri, 13 Aug 2010 11:11:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 043823A6805; Fri, 13 Aug 2010 11:11:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OjyfX-000Eo5-GE for namedroppers-data0@psg.com; Fri, 13 Aug 2010 18:07:51 +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.72 (FreeBSD)) (envelope-from ) id 1OjyfV-000Ens-6e for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 18:07:49 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id EA707A101E for ; Fri, 13 Aug 2010 18:07:48 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: [dnsext] C+D vs. B X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Fri, 13 Aug 2010 18:07:48 +0000 Message-ID: <26902.1281722868@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: the following code exists in a deployed (commercial, closed-source) recursive dns server. (which i wrote during a sabbatical in 2003.) ... /* Cache error means there can't be a CNAME. This happens * when we have no root hints at all. */ if (dom == NULL) break; /* If QTYPE is CNAME then return it rather than following it. */ if (qtype == ns_t_cname) break; /* If there's no CNAME in cache but there's any other type * (unexpired), then there cannot be a CNAME and we're done. * Note: this is an optimization to avoid dns_cache_findtype. */ anytype = (dns_cache_anytype(dom, now.tv_sec) != NULL); if ((dns_dom_getflags(dom) & DNS_DOM_ISALIAS) == 0 && anytype) break; /* Handle CNAME (if it exists) chaining. */ switch (dns_cache_findtype(dc, dom, qclass, ns_t_cname, FALSE, &rrset, now.tv_sec)) { ... i've mentioned this a couple times here, but i thought a real code example would help illustrate why C+D would need signalling. the above code is correct, and must never be exposed to the C+D data pattern, because that data pattern would violate this code's assumptions, making it incorrect. one of our duties as protocol stewards is to not invalidate existing correct implementations. (sometimes we also have to avoid invalidating existing incorrect implementations, but this is not one of those times.) on my drive to work today i realized there's an even deeper problem, which is that DNAME can coexist with lots of other types. DNAME-at-apex is for example how we handled the IP6.INT problem: http://ftp.isc.org/isc/pubs/tn/isc-tn-2002-1.txt when we talk about C+D we're really talking about C+D+other, where "other" is all the things that DNAME can presently coexist with. which means, when we talk about C+D we're really talking about C+anything. i'd like C+anything. it should have been there from day 1. it's what a lot of people think (incorrectly, until they try it and it doesn't work) that wildcards mean. but C+anything will require signalling, to protect existing (correct) implementations from a data pattern that they reasonably assumed could never exist. if we're voting, i'd like C+anything because it would be useful for many things, but as an implementor and operator, i'd find B easier and cleaner. (both approaches mean the same thing and both need signalling, but B is a new code point whereas C+D adds meaning to existing code points.) From owner-namedroppers@ops.ietf.org Fri Aug 13 16:09: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 AB8D93A69D1; Fri, 13 Aug 2010 16:09:14 -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.579, 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 vVIDzP4j1l3W; Fri, 13 Aug 2010 16:09:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 826C23A6A08; Fri, 13 Aug 2010 16:09:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ok3Ha-000Lig-Nk for namedroppers-data0@psg.com; Fri, 13 Aug 2010 23:03:26 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ok3HW-000Lfh-CA for namedroppers@ops.ietf.org; Fri, 13 Aug 2010 23:03:22 +0000 Received: by fxm10 with SMTP id 10so2772405fxm.11 for ; Fri, 13 Aug 2010 16:03:21 -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=b82rEgV5TKDN/FqaUiRdh2NR74CWrRhyyUW0Dulh4mU=; b=VKWyt5H/OWfK7c59m4Rk3+MVDALAQSHMftSIssxVpI0ZH4V3gIW9zyJOTokujNweTN mxh3UTkR4mUUMJFo28ak4EjX0cVusxzwYr+o+NMeC0xmsYyOJ87hIbDFoaBLqqivV0q+ Xt+IQgL9ZLS7ekDafATzMrEBmlcjvtR36/jvE= 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=Im2VX94A2XyRPfsPwgme2+Juyt0NNe2C8WxPv6LnR/2MMVrIdMq71w4cBBspLQaemJ Mm2Cn+4JkS4xJJpeJMmDa+B69kPv92b1JoxZTcPrX+qZwR9mJp+mehHz3aX24GlBBSRx 7Q9d1HI12/OtB3BlFFL7P//cw6yQaGejAywZc= MIME-Version: 1.0 Received: by 10.223.117.194 with SMTP id s2mr2670016faq.57.1281740600967; Fri, 13 Aug 2010 16:03:20 -0700 (PDT) Received: by 10.223.126.138 with HTTP; Fri, 13 Aug 2010 16:03:20 -0700 (PDT) Date: Fri, 13 Aug 2010 20:03:20 -0300 Message-ID: Subject: [dnsext] The missing link (was Re: An argument why bname-style delegation is needed) From: Brian Dickson To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=001636c5b47e370409048dbc7dc2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001636c5b47e370409048dbc7dc2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 11, 2010 at 12:33 PM, Brian Dickson < brian.peter.dickson@gmail.com> wrote: > > > On Wed, Aug 11, 2010 at 10:56 AM, Andrew Sullivan wrote: > >> Colleagues, >> >> Under a provisioning-only regime, the requirement that N1.P and N2.P >> be "the same name" cannot be guaranteed. That is because under >> provisioning, it would be necessary to duplicate all the zones all the >> way down the tree, and there is no easy way in the DNS to check that >> two zones are equivalent without walking the zone. >> >> > > And now I'll use another argument for *non*-Xname changes to DNS, > as an augmentation of what exists now, to facilitate both provisioning-only > mechanisms, > and to facilitate better-scaling DNSSEC signing. > > What is missing, is a *server*-side (below-the-zone-cut) apex record, which > asserts all the names by which the zone is known. > > Actually, I was wrong. Here's a brief synopsis of what follows: RFC 4034 and its predecessors, was written with a strict-tree-model of DNS, modulo CNAME and DNAME. In a strict tree, there is one path from the root to a leaf, and one path from any leaf to the root. It shows up in the logic and wording, whenever the text includes "_the_ name". In an acyclic graph model, each link is unidirectional (delegation), the root is by definition the only node to which no delegations are made, and a leaf is a node from which no delegations are made. There may be more than one path from the root to a leaf, and more than one path from any leaf to the root. The IDN problem (and the general "equivalent zones" problem) *can* be solved rather neatly, by anchoring the procedures for validation and resolution at the "last delegation apex", adopting a very slightly modified validation methodology (which is provably equivalent security-wise), and revising the appropriate RFCs to say "_a_ name" instead of "_the_ name", wherever that language exists. Or so I claim. :-) The long version follows... The basic problem here is that, even if there were some way to duplicate or hard-link zone contents at multiple places in the DNS tree, with unique forward linkages (NS zone cuts + DS) at unique places (i.e. labels or FQDNs) in the DNS tree, the DNSSEC validation for RRSIGs presumes a uniqueness to the back-link of the "signer", i.e. the owner name of the zone. If zones are to be signed once, even when they are known by multiple names, this creates a conundrum. DNSSEC wants to authenticate the DNSKEY used to sign RDATA, and to do so by name. If we start the forward/backward label-matching at the RR owner whose RRSIG we want to check, this can't be solved. However, if we start the forward/backward label-matching and validation at the apex of the zone in which the RR exists, the uniqueness problem can be resolved, as well as preserving the rest of the security validation model. Here is what we presume to already exist: The zone Z is known by two names, K and L, where K is Ki.Ki-1...K3.K2.K1, and L is similarly Lj.Lj-1....L3.L2.L1. We make no assumptions regarding i and j. We are interested in node in Z whose owner is x.y.K (and incidentally also x.y.L, and possibly other names too.) K and L are both DNSSEC secure entry points into Z. This means there are apex DNSKEYs signed respectively with owner == K, and owner == L. The validator may not have all of this information yet, i.e. the full validation chain of K and L. It *should* have the full validation chain of K, but may not yet have the full validation chain of L. If x.y.K is signed only by L, we can still authenticate x.y, if the logic used goes like this: We need to find the DNSKEY at L, used to sign x.y.K. For now, we ignore K != L (lexigraphically at least). We look for the the DNSKEY at the apex of L (which is one of the names of Z, although not the name we used to get here), which matches the keytag of the RRSIG of x.y.K. Before we can do anything with any of them, we need to validate them, via their name "L". This may mean chasing down the authentication chain all the way back to the root, but presumably results in a validated SEP to L. There may be more than one matching DNSKEY; if so, we need to try each of them. If we find a match, we have succeeded in validating x.y.L. However, we were trying to validate x.y.K. IFF we have a DNSKEY which validates x.y.L, which is found on the RRSIG of x.y.L, AND the DNSKEY itself is signed by both K and L, and K and L are SEPs, AND x.y.K == x.y.L AND RRSIG(x.y.K) == RRSIG(x.y.L) , THEN we can claim the key that signed the RR is in the same zone as the RR, and is valid, and validates the RR, and thus the RR is authenticated, for both names x.y.K and x.y.L. The crypto purists should note that the DS uses the owner name, but the DNSKEY RDATA does not include anything dependent upon its owner name. The DS values for K and L will be different, even if they are DS's for the same DNSKEY. Ideally, having a signed "nonce" at the apex of the zone, of sufficient number of bits, would establish zone identity (and identity sharing). However, nothing in the current DNS specs requires zones to be distinct or unique, per se - and I don't think we want it to. Ideally, the RRSIG of the ZSK should have enough entropy to satisfy the crypto crowd -- which is what the SEP incorporates. Q.E.D. NB - we always have to prove the chain of delegations and signatures, so the only change is the order in which certain checks are done, and then only in the final zone. NB2 - doing this trick at each layer of the delegation chain for IDNs, turns O(n^k) to O(n), without using xNAME. Di.P and D1.P have authenticated SEPs into their child zone, which means the DS Ci.Di is signed by D1 and still authenticates, and so on. This suggests that a modest change to the validation rules, can achieve the desired results without *requiring* xNAME or protocol changes. Brian --001636c5b47e370409048dbc7dc2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 11, 2010 at 12:33 PM, Brian Dick= son <= brian.peter.dickson@gmail.com> wrote:


On Wed= , Aug 11, 2010 at 10:56 AM, Andrew Sullivan <ajs@shinkuro.com> wrote:
Colleagues,

Under a provisioning-only regime, the requirement that N1.P and N2.P
be "the same name" cannot be guaranteed. =A0That is because under=
provisioning, it would be necessary to duplicate all the zones all the
way down the tree, and there is no easy way in the DNS to check that
two zones are equivalent without walking the zone.



And now I'll use another argument= for *non*-Xname changes to DNS,
as an augmentation of what exists now, = to facilitate both provisioning-only mechanisms,
and to facilitate better-scaling DNSSEC signing.

What is missing, is= a *server*-side (below-the-zone-cut) apex record, which asserts all the na= mes by which the zone is known.


Actually, I was wrong.

Here's a brief synopsis of what follows:=

RFC 4034 and its predecessors, was written with a strict-tree-model= of DNS, modulo CNAME and DNAME.
In a strict tree, there is one path fro= m the root to a leaf, and one path from any leaf to the root.

It shows up in the logic and wording, whenever the text includes "= _the_ name".

In an acyclic graph model, each link is unidirecti= onal (delegation), the root is by definition the only node to which no dele= gations are made, and a leaf is a node from which no delegations are made. = There may be more than one path from the root to a leaf, and more than one = path from any leaf to the root.

The IDN problem (and the general "equivalent zones" problem) = *can* be solved rather neatly, by anchoring the procedures for validation a= nd resolution at the "last delegation apex", adopting a very slig= htly modified validation methodology (which is provably equivalent security= -wise), and revising the appropriate RFCs to say "_a_ name" inste= ad of "_the_ name", wherever that language exists.

Or so I claim. :-)

The long version follows...

The basic = problem here is that, even if there were some way to duplicate or hard-link= zone contents at multiple places in the DNS tree, with unique forward link= ages (NS zone cuts + DS) at unique places (i.e. labels or FQDNs) in the DNS= tree, the DNSSEC validation for RRSIGs presumes a uniqueness to the back-l= ink of the "signer", i.e. the owner name of the zone.

If zones are to be signed once, even when they are known by multiple na= mes, this creates a conundrum.

DNSSEC wants to authenticate the DNSK= EY used to sign RDATA, and to do so by name.

If we start the forward= /backward label-matching at the RR owner whose RRSIG we want to check, this= can't be solved.

However, if we start the forward/backward label-matching and validation= at the apex of the zone in which the RR exists, the uniqueness problem can= be resolved, as well as preserving the rest of the security validation mod= el.

Here is what we presume to already exist:
The zone Z is known by two= names, K and L, where K is Ki.Ki-1...K3.K2.K1, and L is similarly Lj.Lj-1.= ...L3.L2.L1.
We make no assumptions regarding i and j.
We are interes= ted in node in Z whose owner is x.y.K (and incidentally also x.y.L, and pos= sibly other names too.)
K and L are both DNSSEC secure entry points into Z. This means there are ap= ex DNSKEYs signed respectively with owner =3D=3D K, and owner =3D=3D L.
= The validator may not have all of this information yet, i.e. the full valid= ation chain of K and L. It *should* have the full validation chain of K, bu= t may not yet have the full validation chain of L.

If x.y.K is signed only by L, we can still authenticate x.y, if the log= ic used goes like this:

We need to find the DNSKEY at L, used to sig= n x.y.K.
For now, we ignore K !=3D L (lexigraphically at least).
We l= ook for the the DNSKEY at the apex of L (which is one of the names of Z, al= though not the name we used to get here),
which matches the keytag of the RRSIG of x.y.K.
Before we can do anythin= g with any of them, we need to validate them, via their name "L".=
This may mean chasing down the authentication chain all the way back to= the root, but presumably results in a validated SEP to L.
There may be more than one matching DNSKEY; if so, we need to try each of t= hem.
If we find a match, we have succeeded in validating x.y.L.
Howev= er, we were trying to validate x.y.K.

IFF we have a DNSKEY which val= idates x.y.L, which is found on the RRSIG of x.y.L, AND the DNSKEY itself i= s signed by both K and L, and K and L are SEPs, AND x.y.K =3D=3D x.y.L AND = RRSIG(x.y.K) =3D=3D RRSIG(x.y.L) , THEN we can claim the key that signed th= e RR is in the same zone as the RR, and is valid, and validates the RR, and= thus the RR is authenticated, for both names x.y.K and x.y.L.

The crypto purists should note that the DS uses the owner name, but the= DNSKEY RDATA does not include anything dependent upon its owner name. The = DS values for K and L will be different, even if they are DS's for the = same DNSKEY.

Ideally, having a signed "nonce" at the apex of the zone, of = sufficient number of bits, would establish zone identity (and identity shar= ing).

However, nothing in the current DNS specs requires zones to be= distinct or unique, per se - and I don't think we want it to.
Ideally, the RRSIG of the ZSK should have enough entropy to satisfy the cry= pto crowd -- which is what the SEP incorporates.
Q.E.D.

NB - we a= lways have to prove the chain of delegations and signatures, so the only ch= ange is the order in which certain checks are done, and then only in the fi= nal zone.

NB2 - doing this trick at each layer of the delegation chain for IDNs, = turns O(n^k) to O(n), without using xNAME. Di.P and D1.P have authenticated= SEPs into their child zone, which means the DS Ci.Di is signed by D1 and s= till authenticates, and so on.

This suggests that a modest change to the validation rules, can achieve= the desired results without *requiring* xNAME or protocol changes.

= Brian
--001636c5b47e370409048dbc7dc2-- From owner-namedroppers@ops.ietf.org Sat Aug 14 00: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 113843A68A0; Sat, 14 Aug 2010 00:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[AWL=0.594, 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 exsaKJh2jJJU; Sat, 14 Aug 2010 00:02:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 167033A6872; Sat, 14 Aug 2010 00:02:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkAdA-00063E-0B for namedroppers-data0@psg.com; Sat, 14 Aug 2010 06:54:12 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkAd6-00062Z-Th for namedroppers@ops.ietf.org; Sat, 14 Aug 2010 06:54:09 +0000 Received: from [192.168.1.68] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 20442C56949; Sat, 14 Aug 2010 07:54:05 +0100 (BST) Date: Sat, 14 Aug 2010 07:54:04 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Hoffman , Andrew Sullivan , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] The succinct version of the argument for "do nothing" (was: [dnsext] DNSEXT charter and treating DNS names as "the same") Message-ID: In-Reply-To: References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <4C6542ED.1000700@nic.cz> <25187E64AF3BDAA68165A923@Ximines.local> <20100813170629.GB68767@shinkuro.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 13 August 2010 10:57:31 -0700 Paul Hoffman wrote: > Another way to look at this is that, unless the users of the change we > are going to make agree to it, don't do it. I think it may be worse than that. If the end requirement is to make Ai.Bj.Ck.Dl work like A1.B1.C1.D1, DNS equivalence may hinder this. How? Well, take the example of an application like https. The intention is that the end user typing the https://Ai.Bj.Ck.Dl into her browser gets the same thing as typing https://A1.B1.C1.D1. It may be (due to incomplete deployment of SNI, e.g. support of IE prior to 7.0) that the only effective way to do this is multiple IP addresses. Having a mirror will PREVENT that. Moreover if the server admin doesn't want to buy I*J*K*L certs, the end user will be presented with an invalid security cert rather than a simple 'not found'. https is just one example of why one might want an exception from equivalence. But so for no xNAME proposal allows for this. A provisioning hack does. So, if there are existing apps where DNS equivalence is problematic, xNAME may do more harm than good because it /breaks/ the application layer. Here, to make Ai.Bj.Ck.Dl work like A1.B1.C1.D1, you need DIFFERENT DNS reponses, which xNAME PREVENTS. -- Alex Bligh From owner-namedroppers@ops.ietf.org Sat Aug 14 00:05: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 C55203A68A0; Sat, 14 Aug 2010 00:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.949 X-Spam-Level: *** X-Spam-Status: No, score=3.949 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YR9yPQLJ87L1; Sat, 14 Aug 2010 00:05:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B3AE83A6872; Sat, 14 Aug 2010 00:05:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkAlB-0006m5-80 for namedroppers-data0@psg.com; Sat, 14 Aug 2010 07:02:29 +0000 Received: from [2001:4f8:0:2::2b] (helo=mx.pao1.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkAl8-0006kp-JC for namedroppers@ops.ietf.org; Sat, 14 Aug 2010 07:02:26 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 7330CC9424; Sat, 14 Aug 2010 07:02:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id E8D60E6030; Sat, 14 Aug 2010 07:02:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D2D102EB71A; Sat, 14 Aug 2010 17:02:10 +1000 (EST) To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Cc: Jiankang YAO , namedroppers@ops.ietf.org From: Mark Andrews References: <481633111.17609@cnnic.cn><4C650AE9.2030301@nic.cz> <20100813150009.7E0652E9804@drugs.dv.isc.org><4C656BC2.1060006@nic.cz> Subject: Re: [dnsext] the method of avoiding signal in bname In-reply-to: Your message of "Fri, 13 Aug 2010 17:58:58 +0200." <4C656BC2.1060006@nic.cz> Date: Sat, 14 Aug 2010 17:02:10 +1000 Message-Id: <20100814070210.D2D102EB71A@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4C656BC2.1060006@nic.cz>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= writes: > On 13.8.2010 17:00, Mark Andrews wrote: > > In message<4C650AE9.2030301@nic.cz>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= write > s: > >> On 12.8.2010 19:12, Jiankang YAO wrote: > >>> Dear all, > >>> I proposed the following method for bname to avoid the signaling: > >>> if the query is not dnssec query: > >>> If the owner name of the bname is the suffix of the name queryed but > >>> different, when preparing a response, a server performing a BNAME > >>> substitution will in all cases include the relevant BNAME RR in the > >>> answer section. A CNAME RR is synthesized and included in the answer > >>> section. This will help the client to reach the correct DNS data. > >>> > >>> If the owner name of the bname is same with the name queryed, when > >>> preparing a response, a server performing a BNAME substitution will > >>> not include the relevant BNAME RR in the answer section unless the > >>> type queryed is BNAME. A CNAME RR will be synthesized and included > >>> in the answer section unless the type queryed is BNAME or the query > >>> is the DNSSEC query. > >>> if the query is the dnssec query: > >>> only the bname is returned to the resolvers from the servers. > >>> this assumes that: if the resolvers does not recognize the bname but > >>> want dnssec, the synthesized > >>> cname is not useful for them. > >>> if the resolvers does recognize the bname and want dnssec, the resolvers > >>> can do the > >>> next query without the synthesized > >>> cname. > >>> through the method above, there will never issue cname and bname > >>> together with the same owner name. > >> > >> > >> > >>> if bname still needs the alias algorithm, it will follow the difiniton > >>> of draft-yao-dnsext-alias-algorithm-00.txt to avoid adding > >>> too many alias algorithms for the new rrtypes. > >> > >> You cannot avoid the signaling for the BNAME. You still need the > >> signaling for the BNAME support in the DNSSEC-validating resolver. > >> > >> You need to treat the non-BNAME aware DNSSEC validating resolver as your > >> case number #1. And then you have a unsolvable problem with chained > >> resolvers. Because downstream BNAME-aware resolver will not be able to > >> see BNAME record after the upstream resolver has a synthesized CNAME in > >> the cache. I think this won't fly [RFC1925]. > > > > NSEC3 doesn't work through chained nameservers that don't support NSEC3 > > but we still deployed NSEC3. > > > > DNSSEC doesn't work through chained nameserves that don't support DNSSEC > > but we still deployed DNSSEC. > > > > Now you are saying that we can't deploy BNAME because it won't work through > > chained nameservers that don't support BNAME. Sorry that just doesn't pass > > the laugh test as a reason to block it. Way too many counter examples here > . > > Mark, please read the original Yao's proposal to know what "this" means > before you turn your mean-mode on next time. I am not arguing against > BNAME in general, I am merely saying that "the method of avoiding signal > in bname" as proposed in this email is flawed and you probably want to > send BNAME along with synthesized CNAME. And if the intermediate server doesn't understand BNAME it will be dropped. Today servers that don't understand DNAME just drop the DNAME as it doesn't match the query. BNAME will be similar. It's just a waste of bits sending BNAME if the client doesn't understand it. 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 Sat Aug 14 07:13: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 6413F3A68CC; Sat, 14 Aug 2010 07:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 fQNFOKMF1LZC; Sat, 14 Aug 2010 07:13:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B7663A6781; Sat, 14 Aug 2010 07:13:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkHNy-000NRD-1e for namedroppers-data0@psg.com; Sat, 14 Aug 2010 14:06: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.72 (FreeBSD)) (envelope-from ) id 1OkHNw-000NQu-0I for namedroppers@ops.ietf.org; Sat, 14 Aug 2010 14:06:56 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 64572A1019 for ; Sat, 14 Aug 2010 14:06:53 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] The succinct version of the argument for "do nothing" (was: [dnsext] DNSEXT charter and treating DNS names as "the same") In-Reply-To: Your message of "Sat, 14 Aug 2010 07:54:04 +0100." References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <4C6542ED.1000700@nic.cz> <25187E64AF3BDAA68165A923@Ximines.local> <20100813170629.GB68767@shinkuro.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Sat, 14 Aug 2010 14:06:53 +0000 Message-ID: <95007.1281794813@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, 14 Aug 2010 07:54:04 +0100 > From: Alex Bligh > ... > So, if there are existing apps where DNS equivalence is problematic, > xNAME may do more harm than good because it /breaks/ the application > layer. Here, to make Ai.Bj.Ck.Dl work like A1.B1.C1.D1, you need > DIFFERENT DNS reponses, which xNAME PREVENTS. wouldn't you just not put in xNAME RR's on the names which needed different dns responses? or if you mean that you want difference for some apps and sameness for other apps, how would a provisioning hack support that? From owner-namedroppers@ops.ietf.org Sat Aug 14 08:36: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 492953A68B2; Sat, 14 Aug 2010 08:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.803 X-Spam-Level: X-Spam-Status: No, score=0.803 tagged_above=-999 required=5 tests=[AWL=-0.191, 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 WDyqGEfjkoGr; Sat, 14 Aug 2010 08:36:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E7423A689B; Sat, 14 Aug 2010 08:36:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkIhw-0007C8-AU for namedroppers-data0@psg.com; Sat, 14 Aug 2010 15:31:40 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkIht-0007Bd-2P for namedroppers@ops.ietf.org; Sat, 14 Aug 2010 15:31:37 +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 8FE71C56943; Sat, 14 Aug 2010 16:31:34 +0100 (BST) Date: Sat, 14 Aug 2010 16:31:33 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] The succinct version of the argument for "do nothing" (was: [dnsext] DNSEXT charter and treating DNS names as "the same") Message-ID: <7F516464E7D36F2C506D5E1C@Ximines.local> In-Reply-To: <95007.1281794813@nsa.vix.com> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <4C6542ED.1000700@nic.cz> <25187E64AF3BDAA68165A923@Ximines.local> <20100813170629.GB68767@shinkuro.com> <95007.1281794813@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 14 August 2010 14:06:53 +0000 Paul Vixie wrote: >> Date: Sat, 14 Aug 2010 07:54:04 +0100 >> From: Alex Bligh >> ... >> So, if there are existing apps where DNS equivalence is problematic, >> xNAME may do more harm than good because it /breaks/ the application >> layer. Here, to make Ai.Bj.Ck.Dl work like A1.B1.C1.D1, you need >> DIFFERENT DNS reponses, which xNAME PREVENTS. > > wouldn't you just not put in xNAME RR's on the names which needed > different dns responses? or if you mean that you want difference > for some apps and sameness for other apps, how would a provisioning > hack support that? An example will probably help. Let us suppose ICANN delegate z1. and z2. to the combined republic of Z-land, and want "names ending z1. and z2. to work the same". In an attempt to achieve this, they use the recent output of the DNSEXT working group to provide zone equivalence, and put the following in the root zone file: $ORIGIN . z1. IN NS ns.znic.net. z2. IN XNANE z1. znic is the registry for z1. (and hence z2.). It doesn't really matter whether the XNAME record lives in the root zone or whether znic has it at the apex of a z2. zone file for this region. One registrant within z1. is hugecorp, so z1's zonefile contains this: $ORIGIN z1. hugecorp IN NS ns.example.com. And within hugecorp, there is a regional entity: $ORIGIN hugecorp.z1. region IN NS ns.example2.com. And the regional entity has a web server $ORIGIN region.hugecorp.z1. www IN A 192.200.0.1 The web server operator wants his webserver to respond to both http://www.region.hugecorp.z1/ and http://www.region.hugecorp.z2/, and the XNAME neatly facilitates this, as both lookups produce 192.200.0.1. However, a problem comes when the operator tries to get HTTPS working. The operator's webserver runs IIS, which neither support SNI nor X509v3-SAN. Whilst he could change the web server software, lots of his users run old versions of IE, or use any versions of IE or Chrome on Windows XP, or use Blackberries, none of which support SNI or X509v3-SAN either. So if he puts up an https service on /either/ address, the other will give a certificate error, which is unhelpful as hugecorp is a bank. If, however, the XNAME hack had not been used, the following would be in the zone files. $ORIGIN . z1. IN NS ns.znic.net. z2. IN NS ns.znic.net. $ORIGIN z1. hugecorp IN NS ns.example.com. $ORIGIN z2. hugecorp IN NS ns.example.com. $ORIGIN hugecorp.z1. region IN NS ns.example2.com. $ORIGIN hugecorp.z2. region IN NS ns.example2.com. $ORIGIN region.hugecorp.z1. www IN A 192.200.0.1 $ORIGIN region.hugecorp.z2. www IN A 192.200.0.2 The administrator of the web server, who understands his application's needs, puts www.region.hugecorp.z1. on a different IP address from www.region.hugecorp.z2., and, whilst begrudging the fact he now has to pay for 2 certificates, at least has 2 working http addreses. Or alternatively (per paf) just makes one of them work, but at least the other doesn't produce an error. Neither of these options is possible if equivalence is forced on him higher up the chain. Forcing DNS to return equivalent records actually caused the application to perform DIFFERENTLY. Manual provisioning in this instance makes things BETTER. Also, no one needed to do any protocol design, worry about signalling, upgrade any nameservers or caching resolvers. It all worked out the box. -- Alex Bligh From owner-namedroppers@ops.ietf.org Sat Aug 14 08:45: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 DD0313A69DB; Sat, 14 Aug 2010 08:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[AWL=0.506, 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 XYzy26UkSzRa; Sat, 14 Aug 2010 08:45:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 589C03A67C2; Sat, 14 Aug 2010 08:45:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkIsw-0008PW-5R for namedroppers-data0@psg.com; Sat, 14 Aug 2010 15:43:02 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkIss-0008P4-F4 for namedroppers@ops.ietf.org; Sat, 14 Aug 2010 15:42:59 +0000 Received: by fxm10 with SMTP id 10so3064535fxm.11 for ; Sat, 14 Aug 2010 08:42:57 -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; bh=LiPfXUk+7yVyoxP8vsUpTMZKfJrqcVqFOrQjNh8tENY=; b=HUHFn09rPtyvKO1eLhfKTIFO+UXsqx8EIPvttwOIgT7WYYakVmQGxNteT4Zp4X4S23 oDggcPX9uSANRARsNn80IyKd/3go75Yc9Iw4hylSz7udLaUaGEWlx7xyk+qpXIbWtl3g j5OPD4RY4Y4AQBBLbiUzWZT1hkqR+ibjbWE2I= 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=HBS4o9+nUcuAKX/dJOag/i2jWiRZhE+KwYZeR5Q2eJxFneY0M/72aBgG6KWOyexMFv SRQoxdX9vLp4E1OogYVYN0Ypkwn/0yGRbE/t1pXw1qrPxvZwXKk76wl78INhUkj1ivPf 5pQdcimYmcY6PwP/KUlewmKnmJvWSOyOZKEU0= MIME-Version: 1.0 Received: by 10.223.112.10 with SMTP id u10mr3325897fap.50.1281800576678; Sat, 14 Aug 2010 08:42:56 -0700 (PDT) Received: by 10.223.126.138 with HTTP; Sat, 14 Aug 2010 08:42:56 -0700 (PDT) In-Reply-To: References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <4C6542ED.1000700@nic.cz> <25187E64AF3BDAA68165A923@Ximines.local> <20100813170629.GB68767@shinkuro.com> Date: Sat, 14 Aug 2010 12:42:56 -0300 Message-ID: Subject: Re: [dnsext] The succinct version of the argument for "do nothing" (was: [dnsext] DNSEXT charter and treating DNS names as "the same") From: Brian Dickson To: Alex Bligh Cc: Paul Hoffman , Andrew Sullivan , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=001636c5a56d0bb9eb048dca7406 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001636c5a56d0bb9eb048dca7406 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Aug 14, 2010 at 3:54 AM, Alex Bligh wrote: > > > --On 13 August 2010 10:57:31 -0700 Paul Hoffman > wrote: > > Another way to look at this is that, unless the users of the change we >> are going to make agree to it, don't do it. >> > > I think it may be worse than that. If the end requirement is to make > Ai.Bj.Ck.Dl work like A1.B1.C1.D1, DNS equivalence may hinder this. How? > Well, take the example of an application like https. The intention is that > the end user typing the https://Ai.Bj.Ck.Dl into her browser gets the same > thing as typing https://A1.B1.C1.D1. It may be (due to incomplete > deployment of SNI, e.g. support of IE prior to 7.0) that the only effective > way to do this is multiple IP addresses. Having a mirror will PREVENT that. > I would have to say that's an oversimplification, and not a unique conclusion. While it is always possible to type https:// into a browser, the vast majority of real-world use cases involves http:// which then, based either on general design or user interaction, results in the browser being sent to https://something. Two general mechanisms exist for support for the SNI issue -- one is to redirect the user to the https://A1.B1.C1.D1 site, the other is to present a "minimum browser" supported link. There are plenty of older browsers which web sites won't support, or requirements that browsers must meet (number of bits for SSL support, for instance.) > Moreover if the server admin doesn't want to buy I*J*K*L certs, the end > user will be presented with an invalid security cert rather than a simple > 'not found'. > > The issue of multiple certs was addressed elsewhere - SAN (subject alterntive name) certs handle this, i.e. only one cert is needed. Those can be used regardless of the single IP address or the many IP addresses. Orthogonal to the issue at hand. Brian P.S. Reminder - I'm in favor of provisioning hacks and/or meta-provisioning hacks. --001636c5a56d0bb9eb048dca7406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Aug 14, 2010 at 3:54 AM, Alex Bl= igh <alex@alex.org= .uk> wrote:


--On 13 August 2010 10:57:31 -0700 Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Another way to look at this is that, unless the users of the change we
are going to make agree to it, don't do it.

I think it may be worse than that. If the end requirement is to make
Ai.Bj.Ck.Dl work like A1.B1.C1.D1, DNS equivalence may hinder this. How? Well, take the example of an application like https. The intention is that<= br> the end user typing the h= ttps://Ai.Bj.Ck.Dl into her browser gets the same
thing as typing https://A= 1.B1.C1.D1. It may be (due to incomplete
deployment of SNI, e.g. support of IE prior to 7.0) that the only effective=
way to do this is multiple IP addresses. Having a mirror will PREVENT that.=


I would have to say that's an oversimplif= ication, and not a unique conclusion.

While it is always possible to= type https:// into a browser, the vast majority of
real-world use cases involves http:// which then, based either on general d= esign
or user interaction, results in the browser being sent to https://something.

Two general mechanisms= exist for support for the SNI issue -- one is to redirect
the user to the https://A1.B1.C1.D1 sit= e, the other is to present a "minimum browser"
supported link.= There are plenty of older browsers which web sites won't support,
or requirements that browsers must meet (number of bits for SSL support, fo= r instance.)

=A0
Moreover if the server admin doesn't want to buy I*J*K*L certs, the end=
user will be presented with an invalid security cert rather than a simple 'not found'.


The=A0 issue of multiple certs was addressed else= where - SAN (subject alterntive name)
certs handle this, i.e. only one c= ert is needed. Those can be used regardless of the
single IP address or = the many IP addresses. Orthogonal to the issue at hand.

=A0
Brian

P.S. Reminder - I'm in favor of provisioning ha= cks and/or meta-provisioning hacks.

--001636c5a56d0bb9eb048dca7406-- From owner-namedroppers@ops.ietf.org Sat Aug 14 19:13: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 AACAD3A699A; Sat, 14 Aug 2010 19:13:43 -0700 (PDT) X-Quarantine-ID: <1cQhCaE-Sisp> 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: -96.722 X-Spam-Level: X-Spam-Status: No, score=-96.722 tagged_above=-999 required=5 tests=[AWL=-1.186, 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, SARE_MILLIONSOF=0.315, 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 1cQhCaE-Sisp; Sat, 14 Aug 2010 19:13:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BBC9B3A6998; Sat, 14 Aug 2010 19:13:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkScO-000Fgr-8y for namedroppers-data0@psg.com; Sun, 15 Aug 2010 02:06:36 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkScK-000Fg4-OW for namedroppers@ops.ietf.org; Sun, 15 Aug 2010 02:06:33 +0000 Received: (eyou send program); Sun, 15 Aug 2010 10:06:13 +0800 Message-ID: <481837973.29785@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO abc) (127.0.0.1) by 127.0.0.1 with SMTP; Sun, 15 Aug 2010 10:06:13 +0800 Message-ID: From: "Yao Jiankang" To: "Alex Bligh" , "Paul Vixie" , Cc: "Alex Bligh" References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <4C6542ED.1000700@nic.cz> <25187E64AF3BDAA68165A923@Ximines.local> <20100813170629.GB68767@shinkuro.com> <95007.1281794813@nsa.vix.com> <481802217.05822@cnnic.cn> Subject: Re: [dnsext] The succinct version of the argument for "do nothing" (was: [dnsext] DNSEXT charter and treating DNS names as "the same") Date: Sun, 15 Aug 2010 10:04:34 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsZXggQmxpZ2giIDxhbGV4 QGFsZXgub3JnLnVrPg0KVG86ICJQYXVsIFZpeGllIiA8dml4aWVAaXNjLm9yZz47IDxuYW1lZHJv cHBlcnNAb3BzLmlldGYub3JnPg0KQ2M6ICJBbGV4IEJsaWdoIiA8YWxleEBhbGV4Lm9yZy51az4N ClNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMTQsIDIwMTAgMTE6MzEgUE0NClN1YmplY3Q6IFJlOiBb ZG5zZXh0XSBUaGUgc3VjY2luY3QgdmVyc2lvbiBvZiB0aGUgYXJndW1lbnQgZm9yICJkbyBub3Ro aW5nIiAod2FzOiBbZG5zZXh0XSBETlNFWFQgY2hhcnRlciBhbmQgdHJlYXRpbmcgRE5TIG5hbWVz IGFzICJ0aGUgc2FtZSIpIA0KDQoNCj4gDQo+IA0KPiAtLU9uIDE0IEF1Z3VzdCAyMDEwIDE0OjA2 OjUzICswMDAwIFBhdWwgVml4aWUgPHZpeGllQGlzYy5vcmc+IHdyb3RlOg0KPiANCj4+PiBEYXRl OiBTYXQsIDE0IEF1ZyAyMDEwIDA3OjU0OjA0ICswMTAwDQo+Pj4gRnJvbTogQWxleCBCbGlnaCA8 YWxleEBhbGV4Lm9yZy51az4NCj4+PiAuLi4NCj4+PiBTbywgaWYgdGhlcmUgYXJlIGV4aXN0aW5n IGFwcHMgd2hlcmUgRE5TIGVxdWl2YWxlbmNlIGlzIHByb2JsZW1hdGljLA0KPj4+IHhOQU1FIG1h eSBkbyBtb3JlIGhhcm0gdGhhbiBnb29kIGJlY2F1c2UgaXQgL2JyZWFrcy8gdGhlIGFwcGxpY2F0 aW9uDQo+Pj4gbGF5ZXIuICBIZXJlLCB0byBtYWtlIEFpLkJqLkNrLkRsIHdvcmsgbGlrZSBBMS5C MS5DMS5EMSwgeW91IG5lZWQNCj4+PiBESUZGRVJFTlQgRE5TIHJlcG9uc2VzLCB3aGljaCB4TkFN RSBQUkVWRU5UUy4NCj4+DQo+PiB3b3VsZG4ndCB5b3UganVzdCBub3QgcHV0IGluIHhOQU1FIFJS J3Mgb24gdGhlIG5hbWVzIHdoaWNoIG5lZWRlZA0KPj4gZGlmZmVyZW50IGRucyByZXNwb25zZXM/ ICBvciBpZiB5b3UgbWVhbiB0aGF0IHlvdSB3YW50IGRpZmZlcmVuY2UNCj4+IGZvciBzb21lIGFw cHMgYW5kIHNhbWVuZXNzIGZvciBvdGhlciBhcHBzLCBob3cgd291bGQgYSBwcm92aXNpb25pbmcN Cj4+IGhhY2sgc3VwcG9ydCB0aGF0Pw0KPiANCj4gQW4gZXhhbXBsZSB3aWxsIHByb2JhYmx5IGhl bHAuDQo+IA0KPiBMZXQgdXMgc3VwcG9zZSBJQ0FOTiBkZWxlZ2F0ZSB6MS4gYW5kIHoyLiB0byB0 aGUgY29tYmluZWQgcmVwdWJsaWMNCj4gb2YgWi1sYW5kLCBhbmQgd2FudCAibmFtZXMgZW5kaW5n IHoxLiBhbmQgejIuIHRvIHdvcmsgdGhlIHNhbWUiLg0KPiBJbiBhbiBhdHRlbXB0IHRvIGFjaGll dmUgdGhpcywgdGhleSB1c2UgdGhlIHJlY2VudCBvdXRwdXQgb2YNCj4gdGhlIEROU0VYVCB3b3Jr aW5nIGdyb3VwIHRvIHByb3ZpZGUgem9uZSBlcXVpdmFsZW5jZSwgYW5kIHB1dA0KPiB0aGUgZm9s bG93aW5nIGluIHRoZSByb290IHpvbmUgZmlsZToNCj4gDQo+ICRPUklHSU4gLg0KPiB6MS4gSU4g TlMgbnMuem5pYy5uZXQuDQo+IHoyLiBJTiBYTkFORSB6MS4NCj4gDQo+IHpuaWMgaXMgdGhlIHJl Z2lzdHJ5IGZvciB6MS4gKGFuZCBoZW5jZSB6Mi4pLiBJdCBkb2Vzbid0DQo+IHJlYWxseSBtYXR0 ZXIgd2hldGhlciB0aGUgWE5BTUUgcmVjb3JkIGxpdmVzIGluIHRoZSByb290DQo+IHpvbmUgb3Ig d2hldGhlciB6bmljIGhhcyBpdCBhdCB0aGUgYXBleCBvZiBhIHoyLiB6b25lIGZpbGUNCj4gZm9y IHRoaXMgcmVnaW9uLg0KPiANCj4gT25lIHJlZ2lzdHJhbnQgd2l0aGluIHoxLiBpcyBodWdlY29y cCwgc28gejEncyB6b25lZmlsZQ0KPiBjb250YWlucyB0aGlzOg0KPiAkT1JJR0lOIHoxLg0KPiBo dWdlY29ycCBJTiBOUyBucy5leGFtcGxlLmNvbS4NCj4gDQo+IEFuZCB3aXRoaW4gaHVnZWNvcnAs IHRoZXJlIGlzIGEgcmVnaW9uYWwgZW50aXR5Og0KPiAkT1JJR0lOIGh1Z2Vjb3JwLnoxLg0KPiBy ZWdpb24gSU4gTlMgbnMuZXhhbXBsZTIuY29tLg0KPiANCj4gQW5kIHRoZSByZWdpb25hbCBlbnRp dHkgaGFzIGEgd2ViIHNlcnZlcg0KPiAkT1JJR0lOIHJlZ2lvbi5odWdlY29ycC56MS4NCj4gd3d3 IElOIEEgMTkyLjIwMC4wLjENCj4gDQo+IFRoZSB3ZWIgc2VydmVyIG9wZXJhdG9yIHdhbnRzIGhp cyB3ZWJzZXJ2ZXIgdG8gcmVzcG9uZCB0byBib3RoDQo+IGh0dHA6Ly93d3cucmVnaW9uLmh1Z2Vj b3JwLnoxLyBhbmQgaHR0cDovL3d3dy5yZWdpb24uaHVnZWNvcnAuejIvLA0KPiBhbmQgdGhlIFhO QU1FIG5lYXRseSBmYWNpbGl0YXRlcyB0aGlzLCBhcyBib3RoIGxvb2t1cHMgcHJvZHVjZQ0KPiAx OTIuMjAwLjAuMS4NCj4gDQo+IEhvd2V2ZXIsIGEgcHJvYmxlbSBjb21lcyB3aGVuIHRoZSBvcGVy YXRvciB0cmllcyB0byBnZXQgSFRUUFMNCj4gd29ya2luZy4gVGhlIG9wZXJhdG9yJ3Mgd2Vic2Vy dmVyIHJ1bnMgSUlTLCB3aGljaCBuZWl0aGVyDQo+IHN1cHBvcnQgU05JIG5vciBYNTA5djMtU0FO LiBXaGlsc3QgaGUgY291bGQgY2hhbmdlIHRoZSB3ZWINCj4gc2VydmVyIHNvZnR3YXJlLCBsb3Rz IG9mIGhpcyB1c2VycyBydW4gb2xkIHZlcnNpb25zIG9mDQo+IElFLCBvciB1c2UgYW55IHZlcnNp b25zIG9mIElFIG9yIENocm9tZSBvbiBXaW5kb3dzIFhQLCBvcg0KPiB1c2UgQmxhY2tiZXJyaWVz LCBub25lIG9mIHdoaWNoIHN1cHBvcnQgU05JIG9yIFg1MDl2My1TQU4NCj4gZWl0aGVyLiBTbyBp ZiBoZSBwdXRzIHVwIGFuIGh0dHBzIHNlcnZpY2Ugb24gL2VpdGhlci8NCj4gYWRkcmVzcywgdGhl IG90aGVyIHdpbGwgZ2l2ZSBhIGNlcnRpZmljYXRlIGVycm9yLCB3aGljaA0KPiBpcyB1bmhlbHBm dWwgYXMgaHVnZWNvcnAgaXMgYSBiYW5rLg0KPiANCj4gSWYsIGhvd2V2ZXIsIHRoZSBYTkFNRSBo YWNrIGhhZCBub3QgYmVlbiB1c2VkLCB0aGUgZm9sbG93aW5nIHdvdWxkDQo+IGJlIGluIHRoZSB6 b25lIGZpbGVzLg0KPiAkT1JJR0lOIC4NCj4gejEuIElOIE5TIG5zLnpuaWMubmV0Lg0KPiB6Mi4g SU4gTlMgbnMuem5pYy5uZXQuDQo+IA0KPiAkT1JJR0lOIHoxLg0KPiBodWdlY29ycCBJTiBOUyBu cy5leGFtcGxlLmNvbS4NCj4gJE9SSUdJTiB6Mi4NCj4gaHVnZWNvcnAgSU4gTlMgbnMuZXhhbXBs ZS5jb20uDQo+IA0KPiAkT1JJR0lOIGh1Z2Vjb3JwLnoxLg0KPiByZWdpb24gSU4gTlMgbnMuZXhh bXBsZTIuY29tLg0KPiAkT1JJR0lOIGh1Z2Vjb3JwLnoyLg0KPiByZWdpb24gSU4gTlMgbnMuZXhh bXBsZTIuY29tLg0KPiANCj4gJE9SSUdJTiByZWdpb24uaHVnZWNvcnAuejEuDQo+IHd3dyBJTiBB IDE5Mi4yMDAuMC4xDQo+ICRPUklHSU4gcmVnaW9uLmh1Z2Vjb3JwLnoyLg0KPiB3d3cgSU4gQSAx OTIuMjAwLjAuMg0KPiANCj4gVGhlIGFkbWluaXN0cmF0b3Igb2YgdGhlIHdlYiBzZXJ2ZXIsIHdo byB1bmRlcnN0YW5kcyBoaXMgYXBwbGljYXRpb24ncw0KPiBuZWVkcywgcHV0cyB3d3cucmVnaW9u Lmh1Z2Vjb3JwLnoxLiBvbiBhIGRpZmZlcmVudCBJUCBhZGRyZXNzDQo+IGZyb20gd3d3LnJlZ2lv bi5odWdlY29ycC56Mi4sIGFuZCwgd2hpbHN0IGJlZ3J1ZGdpbmcgdGhlIGZhY3QNCj4gaGUgbm93 IGhhcyB0byBwYXkgZm9yIDIgY2VydGlmaWNhdGVzLCBhdCBsZWFzdCBoYXMgMiB3b3JraW5nDQo+ IGh0dHAgYWRkcmVzZXMuIE9yIGFsdGVybmF0aXZlbHkgKHBlciBwYWYpIGp1c3QgbWFrZXMgb25l IG9mDQo+IHRoZW0gd29yaywgYnV0IGF0IGxlYXN0IHRoZSBvdGhlciBkb2Vzbid0IHByb2R1Y2Ug YW4gZXJyb3IuDQo+IE5laXRoZXIgb2YgdGhlc2Ugb3B0aW9ucyBpcyBwb3NzaWJsZSBpZiBlcXVp dmFsZW5jZSBpcyBmb3JjZWQgb24NCj4gaGltIGhpZ2hlciB1cCB0aGUgY2hhaW4uIEZvcmNpbmcg RE5TIHRvIHJldHVybiBlcXVpdmFsZW50IHJlY29yZHMNCj4gYWN0dWFsbHkgY2F1c2VkIHRoZSBh cHBsaWNhdGlvbiB0byBwZXJmb3JtIERJRkZFUkVOVExZLiANCj4NCg0KbWF5YmUgbm90LCBpdCBk ZXBlbmRzIG9uIGhvdyB5b3UgY29uZmlndXJlIGl0Lg0KDQo+DQo+TWFudWFsDQo+IHByb3Zpc2lv bmluZyBpbiB0aGlzIGluc3RhbmNlIG1ha2VzIHRoaW5ncyBCRVRURVIuDQo+IA0KDQpzb21lIHpv bmUgaGFzIHRoZSBtaWxsaW9ucyBvZiBuYW1lcywgdGhlc2UgbmFtZXMgaGF2ZSB0aGUgbWlsbGlv bnMgY2hpbGRlcmVucy4NCg0KcHJvdmlzaW9uaW5nIGZvciBhIGZldyBuYW1lIGFyZSBlYXN5LCAg YnV0IGhvdyBhYm91dCBtaWxsaW9ucz8NCg0KDQo+DQo+IEFsc28sIG5vIG9uZSBuZWVkZWQgdG8g ZG8gYW55IHByb3RvY29sIGRlc2lnbiwgd29ycnkgYWJvdXQgc2lnbmFsbGluZywNCj4gdXBncmFk ZSBhbnkgbmFtZXNlcnZlcnMgb3IgY2FjaGluZyByZXNvbHZlcnMuIEl0IGFsbCB3b3JrZWQgb3V0 IHRoZSBib3guDQo+IA0KPiAtLSANCj4gQWxleCBCbGlnaA0KPiANCj4= From owner-namedroppers@ops.ietf.org Sat Aug 14 19:25: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 AC9013A6831; Sat, 14 Aug 2010 19:25:12 -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 ySDwyLAYa6QF; Sat, 14 Aug 2010 19:25:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AAE333A699A; Sat, 14 Aug 2010 19:25:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkSqa-000Gyo-BH for namedroppers-data0@psg.com; Sun, 15 Aug 2010 02:21:16 +0000 Received: from [2001:4f8:fff7:1::5] (helo=mail1.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkSqX-000GyW-Vr for namedroppers@ops.ietf.org; Sun, 15 Aug 2010 02:21:14 +0000 Received: from cust-63-209-227-45.bos-dynamic.gis.net ([63.209.227.45] helo=[10.10.10.101]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OkSq4-0009SG-Jc; Sun, 15 Aug 2010 02:20:55 +0000 Message-ID: <4C674EFA.6050205@gis.net> Date: Sat, 14 Aug 2010 22:20:42 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Nicholas Weaver CC: Florian Weimer , Alex Bligh , Joe Abley , Phillip Hallam-Baker , namedroppers References: <82y6cn202t.fsf@mid.bfk.de> <82eief1xgc.fsf@mid.bfk.de> <7143B370CED458C7B8AE6465@Ximines.local> <82k4o61rzb.fsf@mid.bfk.de> <82r5i8p1xj.fsf@mid.bfk.de> <3C27B9EE-D75B-483B-9D02-B660C539A477@ICSI.Berkeley.EDU> In-Reply-To: <3C27B9EE-D75B-483B-9D02-B660C539A477@ICSI.Berkeley.EDU> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 63.209.227.45 X-SA-Exim-Rcpt-To: nweaver@ICSI.Berkeley.EDU, fweimer@bfk.de, alex@alex.org.uk, jabley@hopcount.ca, hallam@gmail.com, namedroppers@ops.ietf.org X-SA-Exim-Mail-From: mayer@ntp.org Subject: Re: [dnsext] Charter discussion - Use of DNSSEC in applications X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 8/9/2010 11:15 AM, Nicholas Weaver wrote: > > On Aug 9, 2010, at 2:31 AM, Florian Weimer wrote: > >> * Nicholas Weaver: >> >>> Validating on the recursive resolver ranges between useless and >>> dangerous. >> >> How do you prevent cache poisoning without adding a validator to the >> cache? > > Out of path attacker cache poisoning is eliminated by a combination > of query entropy (if 40b is not sufficient from a combination of port randomization and 0x20, adopt EDNS0 ping) and glue policy (eliminates race-until-win attacks and all attacks using ancillatory data). It seems to me that you can almost totally eliminate race-until-win by looking to see if a second packet arrives on the same interface/port claiming to answer the same query. Since you have no way of knowing whether the good or bad packet arrived first you drop both of them. It is better to try again with a different DNS server for the required data. There is no need for special signaling like EDNS0 ping or 0x20, just look for unexpected second packets. Danny From owner-namedroppers@ops.ietf.org Sat Aug 14 20:03: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 EACBF3A68E1; Sat, 14 Aug 2010 20:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.738 X-Spam-Level: X-Spam-Status: No, score=-108.738 tagged_above=-999 required=5 tests=[AWL=0.042, 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, SARE_MILLIONSOF=0.315, 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 JWADn9APWGLu; Sat, 14 Aug 2010 20:03:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B384F3A68C6; Sat, 14 Aug 2010 20:03:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkTSM-000KPF-Sd for namedroppers-data0@psg.com; Sun, 15 Aug 2010 03:00:18 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkTSK-000KOu-A4 for namedroppers@ops.ietf.org; Sun, 15 Aug 2010 03:00:16 +0000 Received: (qmail 6218 invoked from network); 15 Aug 2010 03:00:14 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 15 Aug 2010 03:00:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=k1008; olt=johnl@user.iecc.com; bh=18lCUYBF3DPDmUZ2zHdb/c3Y45bVIqZQYrU/8O6o+GM=; b=yBDNBkxK9AP8CEeq1RtI4pbG1186R9t+8F8e63R92GW28VZ38srKogKreXUwbVWJjxFX3kxIFFSoSTBa5fVyTSYK+baZ0auHLou6rdYAeeYluQq7l52fM+zSEcD/ljk86qXaQeMjGllV7oWSTfeFUnSw60cRPz8jbwsrUP6zR1s= Date: 15 Aug 2010 03:00:14 -0000 Message-ID: <20100815030014.9111.qmail@joyce.lan> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: [dnsext] The succinct version of the argument for "do nothing" (was: [dnsext] DNSEXT charter and treating DNS names as "the same") In-Reply-To: <481837973.29785@cnnic.cn> Organization: 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: >some zone has the millions of names, these names have the millions childerens. >provisioning for a few name are easy, but how about millions? Don't you build your zone files with databases and automatic scripts? R's, John From owner-namedroppers@ops.ietf.org Sun Aug 15 00:11: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 811E43A6898; Sun, 15 Aug 2010 00:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.228 X-Spam-Level: X-Spam-Status: No, score=0.228 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, 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 JuZevOsMDB9B; Sun, 15 Aug 2010 00:11:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ED64D3A6814; Sun, 15 Aug 2010 00:11:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkXHL-000DZs-S3 for namedroppers-data0@psg.com; Sun, 15 Aug 2010 07:05:11 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkXHI-000DZT-Tb for namedroppers@ops.ietf.org; Sun, 15 Aug 2010 07:05:09 +0000 Received: from [192.168.1.68] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id ED8FFC56948; Sun, 15 Aug 2010 08:05:05 +0100 (BST) Date: Sun, 15 Aug 2010 08:05:06 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Yao Jiankang , Paul Vixie , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] The succinct version of the argument for "do nothing" (was: [dnsext] DNSEXT charter and treating DNS names as "the same") Message-ID: <7220ACC6B933BBA3C8CE9558@nimrod.local> In-Reply-To: <481837973.29785@cnnic.cn> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <4C6542ED.1000700@nic.cz> <25187E64AF3BDAA68165A923@Ximines.local> <20100813170629.GB68767@shinkuro.com> <95007.1281794813@nsa.vix.com> <481802217.05822@cnnic.cn> <481837973.29785@cnnic.cn> 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 August 2010 10:04:34 +0800 Yao Jiankang wrote: > Forcing DNS to return equivalent records >> actually caused the application to perform DIFFERENTLY. > > maybe not, it depends on how you configure it. Some applications appear not to be configurable (see examples given). The point is that if it breaks a few, manual provisioning would have been better. >> Manual >> provisioning in this instance makes things BETTER. >> > > some zone has the millions of names, these names have the millions > childerens. > > provisioning for a few name are easy, but how about millions? You are manually provisioning the applications anyway. As for creating the zone, is there a reason a tool like perl won't work for this (creating z2. from the zonefile for z1.)? Moreover, I am sure there would be an opportunity for server vendors to say "make this zone respond like that zone with the following exceptions" (though that would be harder with signed zones). -- Alex Bligh From owner-namedroppers@ops.ietf.org Sun Aug 15 14: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 20E463A68BF; Sun, 15 Aug 2010 14:51:58 -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=-0.249, 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 QxP6tPBbydYc; Sun, 15 Aug 2010 14:51:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 12CCD3A6894; Sun, 15 Aug 2010 14:51:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okl1G-000OUP-5F for namedroppers-data0@psg.com; Sun, 15 Aug 2010 21:45:30 +0000 Received: from [209.85.214.180] (helo=mail-iw0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okl1B-000OU8-34 for namedroppers@ops.ietf.org; Sun, 15 Aug 2010 21:45:25 +0000 Received: by iwn4 with SMTP id 4so1348819iwn.11 for ; Sun, 15 Aug 2010 14:45:22 -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=TcB8RE9KE10oinQyiySWYnX5uOjJUrFIGYARIVtsY80=; b=sdm62F2wTQul4lpdBOCX13SjGy5tF69rp1AeOv30TiZ0FTv++92olpn5p7mQ2veQmu UY8m78Cw5c/OOFS+fg+mr+wzRzO4csZnxC9vdWwyuk+aRT0LJCt+V4LivwF7WULaHlBQ AHqHeCu6Mt37FqvnufKARXo4Uci+fls2O9Zko= 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=SonWSDxj3dHsiNLio+RcMcO0PJ+i3++EqFA3xGF0oHxo9+G79d9lrNlLyb6BrQRT5D 49FqTPcVTswYbQ4jJ1PE/HIOzYAQtzuU2nzloQlsW77+B7iTWPPMDOlPnHtFa7VUsUjM gvnMPvCsaa6P4Q+vo9+uJznZgVTM4Kbs5ezh0= MIME-Version: 1.0 Received: by 10.231.154.75 with SMTP id n11mr5119527ibw.40.1281908721544; Sun, 15 Aug 2010 14:45:21 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Sun, 15 Aug 2010 14:45:21 -0700 (PDT) In-Reply-To: References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <4C6542ED.1000700@nic.cz> <25187E64AF3BDAA68165A923@Ximines.local> <20100813170629.GB68767@shinkuro.com> Date: Sun, 15 Aug 2010 17:45:21 -0400 Message-ID: Subject: Re: [dnsext] The succinct version of the argument for "do nothing" (was: [dnsext] DNSEXT charter and treating DNS names as "the same") From: Phillip Hallam-Baker To: Brian Dickson Cc: Alex Bligh , Paul Hoffman , Andrew Sullivan , 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: There are ways to fix this up in the certificates. But there is no way to have a secure scheme where a person types in x.y.z and there is no mention of x, y and z in the cert. So there is no way you can make this work by putting magic links into the apex zone. Not unless you can establish a trust chain for the equivalence statement that has the same degree of assurance (validation, insurance, etc.) as the chain it is mapped to. And ICANN is certainly not proposing to do that with their DNSSEC proposal. So if you take magic links off the table, you have provisioning hacks and 'Did You Mean' links or both as possible mechanisms. On Sat, Aug 14, 2010 at 11:42 AM, Brian Dickson wrote: > > > On Sat, Aug 14, 2010 at 3:54 AM, Alex Bligh wrote: >> >> >> --On 13 August 2010 10:57:31 -0700 Paul Hoffman >> wrote: >> >>> Another way to look at this is that, unless the users of the change we >>> are going to make agree to it, don't do it. >> >> I think it may be worse than that. If the end requirement is to make >> Ai.Bj.Ck.Dl work like A1.B1.C1.D1, DNS equivalence may hinder this. How? >> Well, take the example of an application like https. The intention is th= at >> the end user typing the https://Ai.Bj.Ck.Dl into her browser gets the sa= me >> thing as typing https://A1.B1.C1.D1. It may be (due to incomplete >> deployment of SNI, e.g. support of IE prior to 7.0) that the only >> effective >> way to do this is multiple IP addresses. Having a mirror will PREVENT >> that. > > > I would have to say that's an oversimplification, and not a unique > conclusion. > > While it is always possible to type https:// into a browser, the vast > majority of > real-world use cases involves http:// which then, based either on general > design > or user interaction, results in the browser being sent to https://somethi= ng. > > Two general mechanisms exist for support for the SNI issue -- one is to > redirect > the user to the https://A1.B1.C1.D1 site, the other is to present a "mini= mum > browser" > supported link. There are plenty of older browsers which web sites won't > support, > or requirements that browsers must meet (number of bits for SSL support, = for > instance.) > > >> >> Moreover if the server admin doesn't want to buy I*J*K*L certs, the end >> user will be presented with an invalid security cert rather than a simpl= e >> 'not found'. >> > > The=A0 issue of multiple certs was addressed elsewhere - SAN (subject > alterntive name) > certs handle this, i.e. only one cert is needed. Those can be used > regardless of the > single IP address or the many IP addresses. Orthogonal to the issue at ha= nd. > > > Brian > > P.S. Reminder - I'm in favor of provisioning hacks and/or meta-provisioni= ng > hacks. > > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Sun Aug 15 19:17: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 B60143A6903; Sun, 15 Aug 2010 19:17: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: -95.576 X-Spam-Level: X-Spam-Status: No, score=-95.576 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315, 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 EXMVQqUY24z3; Sun, 15 Aug 2010 19:17:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FDF93A6934; Sun, 15 Aug 2010 19:17:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkpCm-000Ki2-OB for namedroppers-data0@psg.com; Mon, 16 Aug 2010 02:13:40 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkpCf-000KhY-AG for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 02:13:33 +0000 Received: (eyou send program); Mon, 16 Aug 2010 10:13:33 +0800 Message-ID: <481924813.14103@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.9) by 159.226.7.146 with SMTP; Mon, 16 Aug 2010 10:13:33 +0800 Message-ID: <00e301cb3ce8$9f666c00$096ff1da@yaojk> From: "YAO Jiankang" To: Cc: "YAO Jiankang" Subject: [dnsext] why provisions fail in alias domain names? Date: Mon, 16 Aug 2010 10:13:31 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E0_01CB3D2B.AD6D2350" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_00E0_01CB3D2B.AD6D2350 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 dGhlcmUgaXMgYSB0bGQgY2FsbGVkIGV4YW1wbGUxIGFuZCBleGFtcGxlMi4NCndlIGhvcGUgdGhh dCBleGFtcGxlMSBhbmQgZXhhbXBsZTIgdG8gYmUgc2FtZSAoaW5jbHVkaW5nIHRoZWlyIGNoaWxk cmVucykuDQoNCmZvciB0aGUgc2Vjb25kIGxldmVsJ3MgZG9tYWluIG5hbWVzLA0KaWYgd2UgY29u ZmlndXJlIGEuZXhhbXBsZTEgYW5kIGEuZXhhbXBsZTIgdG8gYmUgc2FtZSwgdGhhdCBtYXkgYmUg ZmVhc2libGUuDQp0aGUgcmVnaXN0cnkgaGFzIGVub3VnaCBwb3dlcnMgYW5kIHJlc291cmNlcyB0 byBzY2FuIGFuZCBtb25pdG9yIHRoZXNlIGRvbWFpbiBuYW1lczogYS5leGFtcGxlMSBhbmQgYS5l eGFtcGxlMiwgIHRoZSByZWdpc3RyeSBjYW4gZm9yY2UgdGhlIHJlZ2lzdHJhbnRzIHRvIA0KbWFr ZSB0aGVzZSB0d28gZG9tYWluIG5hbWVzIHRvIGJlIHNhbWUgaWYgdGhleSBkZXRlY3QgdGhhdCB0 aGVzZSBuYW1lcyBjYW4gbm90IGdldCBwcm92aXNpb25zIGluIHRoZSBzYW1lIHdheS4NCg0KDQoN CmZvciB0aGUgM3JkIG9yIDR0aCBvciBtb3JlIGxldmxlJ3MgZG9tYWluIG5hbWVzLA0KDQppZiB0 aGVyZSBhcmUgZG9tYWluIG5hbWVzOiBhLmEuYS5hLmEuZXhhbXBsZTEgYW5kIGEuYS5hLmEuYS5l eGFtcGxlMiwgaG93IGRvIHRoZSByZWdpc3RyeSBvZiBleGFtcGxlMSBhbmQgZXhhbXBsZTIga25v dyBhbmQgbW9uaXRvciB0aGVzZSBkb21haW4gbmFtZXMgYS5hLmEuYS5hLmV4YW1wbGUxIGFuZCBh LmEuYS5hLmEuZXhhbXBsZTIuDQoNCnRoZSByZWdpc3RyeSBtYXkgbm90IGtub3cgaG93IG1hbnkg ZG9tYWluIG5hbWVzIGluIHRoZSB6b25lcyBvZiBhLmEuYS5hLmEuZXhhbXBsZTEgYW5kIGEuYS5h LmEuYS5leGFtcGxlMi4NCg0KZGlmZmVyZW50IGxldmVscyBkb21haW4gbmFtZXMgYXJlIG1hbmFn ZWQgYnkgZGlmZmVyZW50IG9yZ2FuaXphdGlvbnMuDQp0aGVyZSBhcmUgbWlsbGlvbnMgb2Ygb3Jn YW5pemF0aW9ucyB3aG8gbWFuYWdlIHRoZSBkaWZmZXJlbnQgbGV2ZWwncyBkb21haW4gbmFtZXMg b2YgdGhlIC5leGFtcGxlMSBhbmQgLmV4YW1wbGUyLg0KDQp3aG8gY2FuIHNheSB0aGF0IEkgY2Fu IG1ha2UgdGhlc2UgbWlsbGlvbnMgb2YgZGlmZmVyZW50IG9yZ2FuaXphdGlvbnMgdG8gYmUgcHJv dmlzaW9uZWQgaW4gdGhlIHNhbWUgd2F5Pw0KDQoNCkppYW5rYW5nIFlhbw== ------=_NextPart_000_00E0_01CB3D2B.AD6D2350 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjM2MDMiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj50aGVyZSBpcyBhIHRsZCBj YWxsZWQgZXhhbXBsZTEgYW5kIGV4YW1wbGUyLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPndlIGhvcGUgdGhhdCBleGFtcGxlMSBhbmQgZXhhbXBsZTIgdG8gYmUgc2FtZSAoaW5jbHVk aW5nIHRoZWlyIA0KY2hpbGRyZW5zKS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5mb3IgdGhlIHNlY29uZCBsZXZl bCdzIGRvbWFpbiBuYW1lcyw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5pZiB3ZSBj b25maWd1cmUgYS5leGFtcGxlMSBhbmQgYS5leGFtcGxlMiB0byBiZSBzYW1lLCB0aGF0IG1heSAN CmJlIGZlYXNpYmxlLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPnRoZSByZWdpc3Ry eSBoYXMgZW5vdWdoIHBvd2VycyBhbmQgcmVzb3VyY2VzIHRvIHNjYW4gYW5kIA0KbW9uaXRvciB0 aGVzZSBkb21haW4gbmFtZXM6IGEuZXhhbXBsZTEgYW5kIGEuZXhhbXBsZTIsJm5ic3A7IHRoZSBy ZWdpc3RyeSBjYW4gDQpmb3JjZSB0aGUgcmVnaXN0cmFudHMgdG8gPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+bWFrZSB0aGVzZSB0d28gZG9tYWluIG5hbWVzIHRvIGJlIHNhbWUgaWYg dGhleSBkZXRlY3QgdGhhdCANCnRoZXNlIG5hbWVzIGNhbiBub3QgZ2V0IHByb3Zpc2lvbnMgaW4g dGhlIHNhbWUgd2F5LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmZvciB0aGUg M3JkIG9yIDR0aCBvciBtb3JlIGxldmxlJ3MgZG9tYWluIG5hbWVzLDwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmlm IHRoZXJlIGFyZSBkb21haW4gbmFtZXM6Jm5ic3A7YS5hLmEuYS5hLmV4YW1wbGUxIGFuZCANCmEu YS5hLmEuYS5leGFtcGxlMiwgaG93IGRvIHRoZSByZWdpc3RyeSBvZiBleGFtcGxlMSBhbmQgZXhh bXBsZTIga25vdyBhbmQgDQptb25pdG9yIHRoZXNlIGRvbWFpbiBuYW1lcyBhLmEuYS5hLmEuZXhh bXBsZTEgYW5kIA0KYS5hLmEuYS5hLmV4YW1wbGUyLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj50aGUgcmVnaXN0cnkgbWF5IG5vdCBrbm93IGhvdyBt YW55IGRvbWFpbiBuYW1lcyBpbiB0aGUgem9uZXMgDQpvZiBhLmEuYS5hLmEuZXhhbXBsZTEgYW5k IGEuYS5hLmEuYS5leGFtcGxlMi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5kaWZmZXJlbnQgbGV2ZWxzIGRvbWFp biBuYW1lcyBhcmUgbWFuYWdlZCBieSBkaWZmZXJlbnQgDQpvcmdhbml6YXRpb25zLjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPnRoZXJlIGFyZSBtaWxsaW9ucyBvZiBvcmdhbml6YXRp b25zIHdobyBtYW5hZ2UgdGhlIGRpZmZlcmVudCANCmxldmVsJ3MgZG9tYWluIG5hbWVzIG9mIHRo ZSAuZXhhbXBsZTEgYW5kIC5leGFtcGxlMi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj53aG8gY2FuIHNheSB0aGF0 IEkgY2FuIG1ha2UgdGhlc2UgbWlsbGlvbnMgb2YgZGlmZmVyZW50IA0Kb3JnYW5pemF0aW9ucyB0 byBiZSBwcm92aXNpb25lZCBpbiB0aGUgc2FtZSB3YXk/PC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SmlhbmthbmcgWWFvPC9GT05UPjwvRElWPjwv Qk9EWT48L0hUTUw+DQo= ------=_NextPart_000_00E0_01CB3D2B.AD6D2350-- From owner-namedroppers@ops.ietf.org Sun Aug 15 19:49: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 332363A6848; Sun, 15 Aug 2010 19:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.582 X-Spam-Level: X-Spam-Status: No, score=-0.582 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 OtU80nzXWSYR; Sun, 15 Aug 2010 19:49:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC14E3A6831; Sun, 15 Aug 2010 19:49:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okphh-000NKX-0f for namedroppers-data0@psg.com; Mon, 16 Aug 2010 02:45:37 +0000 Received: from [209.85.214.180] (helo=mail-iw0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okphe-000NKG-1o for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 02:45:34 +0000 Received: by iwn4 with SMTP id 4so1602912iwn.11 for ; Sun, 15 Aug 2010 19:45:33 -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=FkBPIEkROJL6oUZAEIFPQ/DF6fvfdwkehTO9NVOX104=; b=Sq+7r6BUSKD4CZTEdJde9OhyLSDFV1zZWo8/KF176AyFjd8BBITKDpHf0CCO256ZYU feuNGR/70PZ1BIAUHIPd1dGkhY6JbIjEl7Ee8IQtW4fYDogi7tDde0ZSLnI5adxBxCgr g6pTuMJhfzdww8eQbViCKx/1V6iG5qh0xDHXo= 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=jzectlAx/sHwk1PZaJfCbVkZp60H7OQFZMo0y73wMt0ttOfLmKtkOhfs90ZvK8+nhU 0CuhG/XTF0ng/WII7zXV1Kq/bS6JqulVbZdX22b3yt9M7hEr8dCf0Hx58Hh7l0COkXbi V5WWVWNTsXX6NFWTmBIOOoUu0mdPzSIKzelqU= MIME-Version: 1.0 Received: by 10.231.146.141 with SMTP id h13mr5378480ibv.1.1281926732801; Sun, 15 Aug 2010 19:45:32 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Sun, 15 Aug 2010 19:45:32 -0700 (PDT) In-Reply-To: <481924813.14103@cnnic.cn> References: <481924813.14103@cnnic.cn> Date: Sun, 15 Aug 2010 22:45:32 -0400 Message-ID: Subject: Re: [dnsext] why provisions fail in alias domain names? From: Phillip Hallam-Baker To: YAO Jiankang 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 don't think anyone is proposing monitoring the domains to create shadow domains at the registry level. Making this work at the provisioning level means that the name holder has to be responsible for maintaining consistency. But as I have demonstrated, there is no way that the registry can effect this mapping on its own without knowledge on the part of the name holder and have the applications work. Magic pointers are going to break HTTP and SMTP. They are also going to break SSL. And there is absolutely no way to fix that. Application servers all have to support multiple domains these days. The application has to know which domain the email is being sent to or the HTTP request is being directed at. If we are going to have an application client side fix-up then it is only going to be supported by the limited number of applications that are fixup enabled. We certainly do not want recursive resolvers to be automatically following the pointers on behalf of the DNS client as that is going to cause the application to break. There are precisely two ways that work here. Either we have advisory pointers that are only used by applications that know about them, or there are sites who provision out multiple shadow trees through some form of automated means. 2010/8/15 YAO Jiankang : > there is a tld called example1 and example2. > we hope that example1 and example2 to be same (including their childrens)= . > > for the second level's domain names, > if we configure a.example1 and a.example2 to be same, that may be feasibl= e. > the registry has enough powers and resources to scan and monitor these > domain names: a.example1 and a.example2,=A0 the registry can force the > registrants to > make these two domain names to be same if they detect that these names ca= n > not get provisions in the same way. > > > > for the 3rd or 4th or more levle's domain names, > > if there are domain names:=A0a.a.a.a.a.example1 and a.a.a.a.a.example2, h= ow do > the registry of example1 and example2 know and monitor these domain names > a.a.a.a.a.example1 and a.a.a.a.a.example2. > > the registry may not know how many domain names in the zones of > a.a.a.a.a.example1 and a.a.a.a.a.example2. > > different levels domain names are managed by different organizations. > there are millions of organizations who manage the different level's doma= in > names of the .example1 and .example2. > > who can say that I can make these millions of different organizations to = be > provisioned in the same way? > > > Jiankang Yao --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Sun Aug 15 19:55: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 8FE1E3A690D; Sun, 15 Aug 2010 19:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.869 X-Spam-Level: ** X-Spam-Status: No, score=2.869 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 mC7bwLYZxMKG; Sun, 15 Aug 2010 19:55:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 171163A6831; Sun, 15 Aug 2010 19:55:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkppE-000O0V-9N for namedroppers-data0@psg.com; Mon, 16 Aug 2010 02:53:24 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkppA-000Nzy-Ty for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 02:53:21 +0000 Received: by fxm10 with SMTP id 10so3563504fxm.11 for ; Sun, 15 Aug 2010 19:53:19 -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; bh=Il9vKUzNBTKRp3dFi+k9/SidpcepD/2QrxdCa3hL3Zc=; b=Pty1sumshHj+FBoHeCwhWoRBpH7IzczFDCAtpMb+4Az3RUzVLrd8eFLf29ALzC2NPV Ty9sztc+tkXltdRsLM8Y4I7n68Ucc/Xd/FA5ssVUezXP38RDmRwFVddbWkFXEnGTe9vC 79v/2rN9Znct4CgQCt6WSAwl43SPdvAbJOS4c= 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=wniZLpeE4sZP0BL9CHeGF0jW8Ch68q91ZdkxAVwsSowBplVJWt6wDsh5R59Bp9weFG F2osvKzBC+prGFloFOc1K4wRb1tasRHV+ImKRmEGCsSiA7CIzasZ1BB8Qaq8Ew3oxBbr o25KKshlae+PWorJ+iZe3dZVspzzGW4jdWktA= MIME-Version: 1.0 Received: by 10.223.116.6 with SMTP id k6mr4603997faq.49.1281927199420; Sun, 15 Aug 2010 19:53:19 -0700 (PDT) Received: by 10.223.126.138 with HTTP; Sun, 15 Aug 2010 19:53:19 -0700 (PDT) In-Reply-To: <481924813.14103@cnnic.cn> References: <481924813.14103@cnnic.cn> Date: Sun, 15 Aug 2010 23:53:19 -0300 Message-ID: Subject: Re: [dnsext] why provisions fail in alias domain names? From: Brian Dickson To: YAO Jiankang Cc: namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=001636eef06459719d048de7ef1f Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001636eef06459719d048de7ef1f Content-Type: text/plain; charset=ISO-8859-1 2010/8/15 YAO Jiankang > there is a tld called example1 and example2. > we hope that example1 and example2 to be same (including their childrens). > > for the second level's domain names, > if we configure a.example1 and a.example2 to be same, that may be feasible. > the registry has enough powers and resources to scan and monitor these > domain names: a.example1 and a.example2, the registry can force the > registrants to > make these two domain names to be same if they detect that these names can > not get provisions in the same way. > > While it might not be possible to know the intentions of every registry, I would expect the common goal for registries is as follows: - If example1 and example2 are TLDs and IDN equivalents, they are operated intentionally "as one" - if a.example1 is registered, a.example2 is at a minimum reserved exclusively for the registrant of a.example1 - the registry will want to provide ways for a.example1 to have both a.example1 and a.example2 be "the same", as easily as possible - the registry might choose to mirror example1 as example2 "blindly" (although I expect ICANN would frown on this implementation method) - the registry might offer "blind" mirroring of individual registrant delegations, so a.example2 is a "blind mirror" of a.example1 (e.g. xNAME) I believe the registries have no intent or interest in "policing" the sameness of a.example1 and a.example2, except so far as to ensure that both are genuinely operated by the registrant, i.e. not hijacked. However, making it feasible/possible/easy for registrants to have multiple parallel identical "trees", or even label-by-label IDN-equivalence within trees, is in everyone's interest, in the sphere of IDNs. It doesn't solve all the problems, but it does address one of the problems. > > for the 3rd or 4th or more levle's domain names, > > if there are domain names: a.a.a.a.a.example1 and a.a.a.a.a.example2, how > do the registry of example1 and example2 know and monitor these domain names > a.a.a.a.a.example1 and a.a.a.a.a.example2. > > the registry may not know how many domain names in the zones of > a.a.a.a.a.example1 and a.a.a.a.a.example2. > > different levels domain names are managed by different organizations. > there are millions of organizations who manage the different level's domain > names of the .example1 and .example2. > > who can say that I can make these millions of different organizations to be > provisioned in the same way? > > If you want them to have them provisioned the same way, and they also want this, then providing tools and training is the advisable way. Opt-in works wonders, especially if the path for opting in is relatively painless, and there are many sharing the journey. Community forums and user groups always achieve more locally, than the best laid plans of the IETF. Brian --001636eef06459719d048de7ef1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2010/8/15 YAO Jiankang <yaojk@cnnic.cn>
there is a tld called example1 and example2.
we hope that example1 and example2 to be same (includ= ing their=20 childrens).
=A0
for the second level's domain names,
if we configure a.example1 and a.example2 to be same,= that may=20 be feasible.
the registry has enough powers and resources to scan = and=20 monitor these domain names: a.example1 and a.example2,=A0 the registry can= =20 force the registrants to
make these two domain names to be same if they detect= that=20 these names can not get provisions in the same way.
=A0

While it might not be possible to know the inte= ntions of every registry, I would expect the common goal for registries is = as follows:
- If example1 and example2 are TLDs and IDN equivalents, the= y are operated intentionally "as one"
- if a.example1 is registered, a.example2 is at a minimum reserved exclusiv= ely for the registrant of a.example1
- the registry will want to provide= ways for a.example1 to have both a.example1 and a.example2 be "the sa= me", as easily as possible
- the registry might choose to mirror example1 as example2 "blindly&qu= ot; (although I expect ICANN would frown on this implementation method)
= - the registry might offer "blind" mirroring of individual regist= rant delegations, so a.example2 is a "blind mirror" of a.example1= (e.g. xNAME)

I believe the registries have no intent or interest in "policing&q= uot; the sameness of a.example1 and a.example2, except so far as to ensure = that both are genuinely operated by the registrant, i.e. not hijacked.

However, making it feasible/possible/easy for registrants to have multi= ple parallel identical "trees", or even label-by-label IDN-equiva= lence within trees, is in everyone's interest, in the sphere of IDNs.
It doesn't solve all the problems, but it does address one of the p= roblems.
=A0
=A0
for the 3rd or 4th or more levle's domain names,<= /font>
=A0
if there are domain names:=A0a.a.a.a.a.example1 and= =20 a.a.a.a.a.example2, how do the registry of example1 and example2 know and= =20 monitor these domain names a.a.a.a.a.example1 and=20 a.a.a.a.a.example2.
=A0
the registry may not know how many domain names in th= e zones=20 of a.a.a.a.a.example1 and a.a.a.a.a.example2.
=A0
different levels domain names are managed by differen= t=20 organizations.
there are millions of organizations who manage the di= fferent=20 level's domain names of the .example1 and .example2.
=A0
who can say that I can make these millions of differe= nt=20 organizations to be provisioned in the same way?


If you want them to have them p= rovisioned the same way, and they also want this, then providing tools and = training is the advisable way.

Opt-in works wonders, especially if t= he path for opting in is relatively painless, and there are many sharing th= e journey.
Community forums and user groups always achieve more locally, than the best= laid plans of the IETF.

Brian
--001636eef06459719d048de7ef1f-- From owner-namedroppers@ops.ietf.org Sun Aug 15 21:04: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 CB4213A6819; Sun, 15 Aug 2010 21:04:01 -0700 (PDT) X-Quarantine-ID: <2RC1m3nnw4+r> 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: -95.714 X-Spam-Level: X-Spam-Status: No, score=-95.714 tagged_above=-999 required=5 tests=[AWL=0.138, 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, 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 2RC1m3nnw4+r; Sun, 15 Aug 2010 21:04:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D0D8A3A67D3; Sun, 15 Aug 2010 21:04:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okqrh-00040B-BM for namedroppers-data0@psg.com; Mon, 16 Aug 2010 04:00:01 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okqre-0003zq-80 for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 03:59:58 +0000 Received: (eyou send program); Mon, 16 Aug 2010 11:59:58 +0800 Message-ID: <481931198.04226@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.9) by 159.226.7.146 with SMTP; Mon, 16 Aug 2010 11:59:58 +0800 Message-ID: <030001cb3cf7$7d2a8b80$096ff1da@yaojk> From: "YAO Jiankang" To: "Mark Andrews" Cc: References: <481633111.17609@cnnic.cn> <481929142.02740@cnnic.cn> Subject: Re: [dnsext] the method of avoiding signal in bname Date: Mon, 16 Aug 2010 11:59:56 +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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmsgQW5kcmV3cyIgPG1h cmthQGlzYy5vcmc+DQpUbzogIkppYW5rYW5nIFlBTyIgPHlhb2prQGNubmljLmNuPg0KQ2M6IDxu YW1lZHJvcHBlcnNAb3BzLmlldGYub3JnPg0KU2VudDogTW9uZGF5LCBBdWd1c3QgMTYsIDIwMTAg MTE6MjUgQU0NClN1YmplY3Q6IFJlOiBbZG5zZXh0XSB0aGUgbWV0aG9kIG9mIGF2b2lkaW5nIHNp Z25hbCBpbiBibmFtZQ0KDQoNCj4gDQo+PiAgdGhpcyBhc3N1bWVzIHRoYXQ6IGlmIHRoZSByZXNv bHZlcnMgZG9lcyBub3QgcmVjb2duaXplIHRoZSBibmFtZSBidXQNCj4+ICAgd2FudCBkbnNzZWMs IHRoZSBzeW50aGVzaXplZA0KPiANCj4+ICAgY25hbWUgaXMgbm90IHVzZWZ1bCBmb3IgdGhlbS4N Cj4gDQo+IFRoaXMgYXNzdW1wdGlvbiBpcyB0b3RhbGx5IHdpdGhvdXQganVzdGlmaWNhdGlvbiBh bmQgZG9lc24ndCBtYXRjaA0KPiByZWFsaXR5LiAgSSBoYXZlIEROU1NFQyB0dXJuZWQgb24gdG9k YXkuICBJIGRvbid0ICpqdXN0KiB3YW50IGFuc3dlcnMNCj4gdGhhdCB2YWxpZGF0ZSBhcyBzZWN1 cmUuICBXaGF0IEkgd2FudCB0byBkbyBpcyB0byByZWplY3QgaW52YWxpZA0KPiBhbnN3ZXJzIHRv IHRoZSBiZXN0IG9mIG15IGFiaWxpdHkuICBUaGF0IG1lYW5zIHRoYXQgSSBhY2NlcHQgdGhlcmUN Cj4gd2lsbCBiZSBjYXNlcyB3aGVyZSBJIGNhbid0IHZhbGlkYXRlIGEgYW5zd2VyIGFzIHNlY3Vy ZSwgYnV0IHdpbGwNCj4gaGF2ZSB0byB0cmVhdCBpdCBhcyBpbnNlY3VyZSwgZXZlbiB0aG91Z2gg aXQgaXMgc2lnbmVkLg0KPiANCg0KeW91ciBwb2ludCBpcyByZWFzb25hYmxlLg0KDQpzbyBpdCBt ZWFucyB0aGF0IHdlIGhhdmUgdG8gZG8gc2lnbmFsIGZvciBibmFtZSBpbiBkbnNzZWM/DQoNCmFy ZSB0aGVyZSBzb21lIG1ldGhvZHMgb2YgYXZvZGluZyB0aGUgc2lnbmFsIGZvciBibmFtZSBpbiBk bnNzZWM/DQoNCj4NCj4gSWYgSSBuZWVkIHRvIGhhdmUgYSBwYXJ0aWN1bGFyIHpvbmUgdHJlYXRl ZCBhcyBzZWN1cmUgYW5kIGl0IHVzZXMNCj4gYSBhbGdvcml0aG0gdGhhdCBJIGRvbid0IGN1cnJl bnRseSBzdXBwb3J0IEkgd2lsbCB1cGdyYWRlIGFzIG5lZWRlZC4NCj4gDQoNCj4gTWFyaw0KPiAt LSANCj4gTWFyayBBbmRyZXdzLCBJU0MNCj4gMSBTZXltb3VyIFN0LiwgRHVuZGFzIFZhbGxleSwg TlNXIDIxMTcsIEF1c3RyYWxpYQ0KPiBQSE9ORTogKzYxIDIgOTg3MSA0NzQyICAgICAgICAgICAg ICAgICBJTlRFUk5FVDogbWFya2FAaXNjLm9yZw== From owner-namedroppers@ops.ietf.org Sun Aug 15 22:09: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 919FA3A6947; Sun, 15 Aug 2010 22:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.924 X-Spam-Level: **** X-Spam-Status: No, score=4.924 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_20=-0.74, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqIhWnK27+BA; Sun, 15 Aug 2010 22:09:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB33C3A67ED; Sun, 15 Aug 2010 22:09:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okrsh-0009tg-B6 for namedroppers-data0@psg.com; Mon, 16 Aug 2010 05:05:07 +0000 Received: from [2001:500:60::65] (helo=mx.ams1.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okrse-0009tI-RP for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 05:05:05 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 18D435F983B; Mon, 16 Aug 2010 05:04:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id DE696E6030; Mon, 16 Aug 2010 05:04:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5A1172F170D; Mon, 16 Aug 2010 15:04:43 +1000 (EST) To: "YAO Jiankang" Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <481633111.17609@cnnic.cn> <481929142.02740@cnnic.cn><481931198.04226@cnnic.cn> <030001cb3cf7$7d2a8b80$096ff1da@yaojk> Subject: Re: [dnsext] the method of avoiding signal in bname In-reply-to: Your message of "Mon, 16 Aug 2010 11:59:56 +0800." <481931198.04226@cnnic.cn> <030001cb3cf7$7d2a8b80$096ff1da@yaojk> Date: Mon, 16 Aug 2010 15:04:42 +1000 Message-Id: <20100816050443.5A1172F170D@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <481931198.04226@cnnic.cn> <030001cb3cf7$7d2a8b80$096ff1da@yaojk>, " YAO Jiankang" writes: > your point is reasonable. Thanks > so it means that we have to do signal for bname in dnssec? Yes as far as I can see. > are there some methods of avoding the signal for bname in dnssec? None that I've been able to work out. 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 Sun Aug 15 22:39: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 4D1B23A6948; Sun, 15 Aug 2010 22:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.05 X-Spam-Level: X-Spam-Status: No, score=-9.05 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 m7A9yjVR3Qcw; Sun, 15 Aug 2010 22:39:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC9F53A6822; Sun, 15 Aug 2010 22:39:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OksMr-000Cwb-Dl for namedroppers-data0@psg.com; Mon, 16 Aug 2010 05:36:17 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OksMo-000Cvu-AR for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 05:36:14 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJZraExAZnwN/2dsb2JhbACgQHGeS5pvhTsEiWI X-IronPort-AV: E=Sophos;i="4.55,374,1278288000"; d="scan'208";a="148019995" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 16 Aug 2010 05:36:12 +0000 Received: from [192.165.72.14] (ams3-vpn-dhcp7281.cisco.com [10.61.92.112]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7G5aB1t018137; Mon, 16 Aug 2010 05:36:12 GMT Subject: Re: [dnsext] why provisions fail in alias domain names? Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Mon, 16 Aug 2010 07:36:11 +0200 Cc: YAO Jiankang , namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <731A21A7-340B-4B53-9DB2-90DD9004ED51@cisco.com> References: <481924813.14103@cnnic.cn> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 aug 2010, at 04.45, Phillip Hallam-Baker wrote: > Magic pointers are going to break HTTP and SMTP. They are also going > to break SSL. And there is absolutely no way to fix that. It doesn't have to. It all depends on whether the application do "see" = the pointer or not. Ted Hardie suggested something that I almost missed in this discussion, = so I went offline asking him about it. I completely agree with his = finding. If the application do see the "magic alias", then the application also = do know what the canonical version of the domain name is. And the = application can in the further processing use that canonical name for = the processing. For example the HOST header in the HTTP protocol. Say we have: A1.example. IN A 1.2.3.4 A2.example. IN xNAME A1.example. A3.example. IN xNAME A1.example. A4.example. IN xNAME A1.example. Then we can say that application _MUST_ get to see the xNAME record, and = then use A1.example in the various protocols. Patrik From owner-namedroppers@ops.ietf.org Sun Aug 15 23: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 EE5983A695E; Sun, 15 Aug 2010 23:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.047 X-Spam-Level: X-Spam-Status: No, score=0.047 tagged_above=-999 required=5 tests=[AWL=0.542, 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 F-UBz3IdwSzE; Sun, 15 Aug 2010 23:24:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B5C533A68B8; Sun, 15 Aug 2010 23:24:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okt2X-000I4o-Rd for namedroppers-data0@psg.com; Mon, 16 Aug 2010 06:19:21 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okt2V-000I4M-6j for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 06:19:19 +0000 Received: from [192.168.1.68] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id CF865C56948; Mon, 16 Aug 2010 07:19:16 +0100 (BST) Date: Mon, 16 Aug 2010 07:19:17 +0100 From: Alex Bligh Reply-To: Alex Bligh To: YAO Jiankang , namedroppers@ops.ietf.org cc: YAO Jiankang , Alex Bligh Subject: Re: [dnsext] why provisions fail in alias domain names? Message-ID: <2808227A0628F86B45220122@nimrod.local> In-Reply-To: <481924813.14103@cnnic.cn> References: <481924813.14103@cnnic.cn> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 16 August 2010 10:13:31 +0800 YAO Jiankang wrote: > if there are domain names: a.a.a.a.a.example1 and a.a.a.a.a.example2, how > do the registry of example1 and example2 know and monitor these domain > names a.a.a.a.a.example1 and a.a.a.a.a.example2. If the end objective is to make the DNS trees equivalent, anything other than an xNAME type thing will fail. If the end objective is to make all names work equivalently, even this will fail (virtual hosts being a trivial example). -- Alex Bligh From owner-namedroppers@ops.ietf.org Sun Aug 15 23: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 B19313A6819; Sun, 15 Aug 2010 23:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.317 X-Spam-Level: * X-Spam-Status: No, score=1.317 tagged_above=-999 required=5 tests=[AWL=-0.788, 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 GF8EzqZHDjpb; Sun, 15 Aug 2010 23:59:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4FC73A68B8; Sun, 15 Aug 2010 23:59:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OktZg-000M5K-GC for namedroppers-data0@psg.com; Mon, 16 Aug 2010 06:53:36 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OktZc-000M4o-7G for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 06:53:32 +0000 Received: from [192.168.1.68] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 98643C5694A; Mon, 16 Aug 2010 07:53:27 +0100 (BST) Date: Mon, 16 Aug 2010 07:53:24 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Alex Bligh , YAO Jiankang , namedroppers@ops.ietf.org cc: YAO Jiankang , Alex Bligh Subject: Re: [dnsext] why provisions fail in alias domain names? Message-ID: In-Reply-To: <2808227A0628F86B45220122@nimrod.local> References: <481924813.14103@cnnic.cn> <2808227A0628F86B45220122@nimrod.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 16 August 2010 07:19:17 +0100 Alex Bligh wrote: >> if there are domain names: a.a.a.a.a.example1 and a.a.a.a.a.example2, how >> do the registry of example1 and example2 know and monitor these domain >> names a.a.a.a.a.example1 and a.a.a.a.a.example2. > > If the end objective is to make the DNS trees equivalent, anything other > than an xNAME type thing will fail. > > If the end objective is to make all names work equivalently, even this > will fail (virtual hosts being a trivial example). In fact Yao Jiankang actually hits the nail on the head. With a solution that mirrors a whole part of the tree, the registrant CANNOT put a deviating record in (unless we generate some sort of mirroring by exception) which means for many applications at least one equivalent name can't work. Thing about my bank example to Paul. With a solution that relies on manual provisioning, the registrant can take advantage of this, and put in two different records so as to support these applications. Of course they can also do other stuff ICANN didn't intend. I draw two conclusions from this: 1. The goals of having DNS work identically across two equivalent names and having applications work identically are irreconcilable and to a certain extent incompatible. As this is reasonably subtle, I wonder whether ICANN realised this, and which objective they had. 2. Enforcing equivalence "all the way down the tree" is an example of overrelying on technology to implement a policy solution. This could be better handled by the registry provisioning copy zones, then putting whatever policy rules are desirable into Ts & Cs. I suspect XNAME deployment will only encourage unpleasant hacks (e.g. hacking the resolver to detect and XNAME in the chain and if so try a modified version of the leftmost label to try to get SSL etc. to work on both). I am becoming convinced XNAME is not the answer (at least to ICANN's problem and registry deployment - it may be useful for mirroring small bits of tree, but probably not worth the resultant protocol entropy). That leaves us with advisory pointers, and the theoretical possibility of "mirror with exceptions". -- Alex Bligh From dnsext-archive@ietf.org Mon Aug 16 00:42: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 AE2B23A6819 for ; Mon, 16 Aug 2010 00:42:25 -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): Subject: ...-archive@ietf.org VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -76.321 X-Spam-Level: X-Spam-Status: No, score=-76.321 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, 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, MIME_8BIT_HEADER=0.3, RATWARE_MS_HASH=1.398, RATWARE_OUTLOOK_NONAME=2.171, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_QUAL_MEDS=3.568, 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 DqKE4ouEGqok for ; Mon, 16 Aug 2010 00:42:22 -0700 (PDT) Received: from ppp-58-8-127-45.revip2.asianet.co.th (ppp-58-8-127-45.revip2.asianet.co.th [58.8.127.45]) by core3.amsl.com (Postfix) with SMTP id 3DF813A6980 for ; Mon, 16 Aug 2010 00:42:21 -0700 (PDT) Message-Id: <005501cb3d51$507ee590$2d7f083a@truefaster> To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org VIAGRA ® Official Seller -86% From: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Mon, 16 Aug 2010 00:42:21 -0700 (PDT) Dear dnsext-archive@ietf.org Get ready to make her happy. Discount price store: ID43212328 http://groups.yahoo.com/group/gjptdjghkyan/message We do guarantee high-quality medications, instant worldwide delivery and friendly support. © 2001-2010 Pfizer Inc. All rights reserved. From owner-namedroppers@ops.ietf.org Mon Aug 16 00:43: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 AB4233A6981; Mon, 16 Aug 2010 00:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.395 X-Spam-Level: *** X-Spam-Status: No, score=3.395 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 ccsEEFrKDguK; Mon, 16 Aug 2010 00:43:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 615883A6819; Mon, 16 Aug 2010 00:43:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkuHl-0001kT-7C for namedroppers-data0@psg.com; Mon, 16 Aug 2010 07:39:09 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkuHi-0001hh-SZ for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 07:39:07 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1OkuHb-0001oh-8i; Mon, 16 Aug 2010 07:38:59 +0000 Received: by bfk.de with local id 1OkuHb-0004cU-2R; Mon, 16 Aug 2010 07:38:59 +0000 To: Mark Andrews Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] C+D vs. B References: <26902.1281722868@nsa.vix.com> <20100816012048.7E40F2ED101@drugs.dv.isc.org> From: Florian Weimer Date: Mon, 16 Aug 2010 07:38:59 +0000 In-Reply-To: <20100816012048.7E40F2ED101@drugs.dv.isc.org> (Mark Andrews's message of "Mon\, 16 Aug 2010 11\:20\:48 +1000") Message-ID: <828w47m2gc.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Mark Andrews: >> when we talk about C+D we're really talking about C+D+other, where "othe= r" >> is all the things that DNAME can presently coexist with. which means, w= hen >> we talk about C+D we're really talking about C+anything.=20=20 > > C+D mean C+D or D+other but not C+D+other (excluding DNSSEC). I think this means you have to create all your aliases in their respective parent zones. Is this desirable? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Mon Aug 16 00:46: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 038DB3A6819; Mon, 16 Aug 2010 00:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.884 X-Spam-Level: ** X-Spam-Status: No, score=2.884 tagged_above=-999 required=5 tests=[AWL=-0.466, 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 VVHgeBopVKLr; Mon, 16 Aug 2010 00:46:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C02803A6984; Mon, 16 Aug 2010 00:46:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkuNI-0002Rq-Bu for namedroppers-data0@psg.com; Mon, 16 Aug 2010 07:44:52 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkuNF-0002RA-Uz for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 07:44:50 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1OkuN8-0002K5-Rk; Mon, 16 Aug 2010 07:44:42 +0000 Received: by bfk.de with local id 1OkuN8-0001kJ-Ni; Mon, 16 Aug 2010 07:44:42 +0000 To: Alex Bligh Cc: YAO Jiankang , namedroppers@ops.ietf.org Subject: Re: [dnsext] why provisions fail in alias domain names? References: <481924813.14103@cnnic.cn> <2808227A0628F86B45220122@nimrod.local> From: Florian Weimer Date: Mon, 16 Aug 2010 07:44:42 +0000 In-Reply-To: (Alex Bligh's message of "Mon\, 16 Aug 2010 07\:53\:24 +0100") Message-ID: <824oevm26t.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Alex Bligh: > With a solution that mirrors a whole part of the tree, the registrant > CANNOT put a deviating record in (unless we generate some sort of > mirroring by exception) which means for many applications at least > one equivalent name can't work. Yes, this is yet another reason why it's difficult to produce correct zone content with xNAME. How many more do we need before these proposals can be discarded as non-workable? > I am becoming convinced XNAME is not the answer (at least to ICANN's > problem and registry deployment - it may be useful for mirroring small > bits of tree, but probably not worth the resultant protocol entropy). > That leaves us with advisory pointers, and the theoretical possibility > of "mirror with exceptions". IDNA has to work for email, which means that the A might not have access toe DNS, so DNS-based signalling will not work universally. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Mon Aug 16 02:21: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 F342A3A688B; Mon, 16 Aug 2010 02:21:32 -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: -95.782 X-Spam-Level: X-Spam-Status: No, score=-95.782 tagged_above=-999 required=5 tests=[AWL=0.069, 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, 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 vIec4PR8juTt; Mon, 16 Aug 2010 02:21:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 916323A6816; Mon, 16 Aug 2010 02:21:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okvoc-000FeY-W9 for namedroppers-data0@psg.com; Mon, 16 Aug 2010 09:17:11 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkvoZ-000Fdd-TM for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 09:17:08 +0000 Received: (eyou send program); Mon, 16 Aug 2010 17:17:07 +0800 Message-ID: <481950227.07802@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.9) by 159.226.7.146 with SMTP; Mon, 16 Aug 2010 17:17:07 +0800 Message-ID: <03b501cb3d23$cb0df3b0$096ff1da@yaojk> From: "YAO Jiankang" To: "Alex Bligh" Cc: References: <481924813.14103@cnnic.cn> <2808227A0628F86B45220122@nimrod.local> <481943396.02183@cnnic.cn> Subject: Re: [dnsext] why provisions fail in alias domain names? Date: Mon, 16 Aug 2010 17:17:04 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsZXggQmxpZ2giIDxhbGV4 QGFsZXgub3JnLnVrPg0KVG86ICJBbGV4IEJsaWdoIiA8YWxleEBhbGV4Lm9yZy51az47ICJZQU8g SmlhbmthbmciIDx5YW9qa0Bjbm5pYy5jbj47IDxuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnPg0K Q2M6ICJZQU8gSmlhbmthbmciIDx5YW9qa0Bjbm5pYy5jbj47ICJBbGV4IEJsaWdoIiA8YWxleEBh bGV4Lm9yZy51az4NClNlbnQ6IE1vbmRheSwgQXVndXN0IDE2LCAyMDEwIDI6NTMgUE0NClN1Ympl Y3Q6IFJlOiBbZG5zZXh0XSB3aHkgcHJvdmlzaW9ucyBmYWlsIGluIGFsaWFzIGRvbWFpbiBuYW1l cz8NCg0KDQpzbmlwcy4uLg0KPiBJIGRyYXcgdHdvIGNvbmNsdXNpb25zIGZyb20gdGhpczoNCj4g DQo+IDEuIFRoZSBnb2FscyBvZiBoYXZpbmcgRE5TIHdvcmsgaWRlbnRpY2FsbHkgYWNyb3NzIHR3 byBlcXVpdmFsZW50IG5hbWVzDQo+ICAgYW5kIGhhdmluZyBhcHBsaWNhdGlvbnMgd29yayBpZGVu dGljYWxseSBhcmUgaXJyZWNvbmNpbGFibGUgYW5kDQo+ICAgdG8gYSBjZXJ0YWluIGV4dGVudCBp bmNvbXBhdGlibGUuIEFzIHRoaXMgaXMgcmVhc29uYWJseSBzdWJ0bGUsDQo+ICAgSSB3b25kZXIg d2hldGhlciBJQ0FOTiByZWFsaXNlZCB0aGlzLCBhbmQgd2hpY2ggb2JqZWN0aXZlIHRoZXkgaGFk Lg0KPiANCj4gMi4gRW5mb3JjaW5nIGVxdWl2YWxlbmNlICJhbGwgdGhlIHdheSBkb3duIHRoZSB0 cmVlIiBpcyBhbiBleGFtcGxlIG9mDQo+ICAgb3ZlcnJlbHlpbmcgb24gdGVjaG5vbG9neSB0byBp bXBsZW1lbnQgYSBwb2xpY3kgc29sdXRpb24uIFRoaXMgY291bGQNCj4gICBiZSBiZXR0ZXIgaGFu ZGxlZCBieSB0aGUgcmVnaXN0cnkgcHJvdmlzaW9uaW5nIGNvcHkgem9uZXMsIHRoZW4NCj4gICBw dXR0aW5nIHdoYXRldmVyIHBvbGljeSBydWxlcyBhcmUgZGVzaXJhYmxlIGludG8gVHMgJiBDcy4N Cj4gDQo+IEkgc3VzcGVjdCBYTkFNRSBkZXBsb3ltZW50IHdpbGwgb25seSBlbmNvdXJhZ2UgdW5w bGVhc2FudCBoYWNrcyAoZS5nLg0KPiBoYWNraW5nIHRoZSByZXNvbHZlciB0byBkZXRlY3QgYW5k IFhOQU1FIGluIHRoZSBjaGFpbiBhbmQgaWYgc28gdHJ5IGENCj4gbW9kaWZpZWQgdmVyc2lvbiBv ZiB0aGUgbGVmdG1vc3QgbGFiZWwgdG8gdHJ5IHRvIGdldCBTU0wgZXRjLiB0byB3b3JrIG9uDQo+ IGJvdGgpLg0KPiANCmNuYW1lIG9yIGRuYW1lIGlzIGFsc28gYSBraW5kIG9mIFhOQU1FLg0KDQpk byB5b3UgbWVhbiB0aGF0IGNuYW1lIG9yIGRuYW1lIGVuY291cmFnZSB1bnBsZWFzYW50IGhhY2tz Pw0KDQo+DQo+IEkgYW0gYmVjb21pbmcgY29udmluY2VkIFhOQU1FIGlzIG5vdCB0aGUgYW5zd2Vy IChhdCBsZWFzdCB0byBJQ0FOTidzDQo+IHByb2JsZW0gYW5kIHJlZ2lzdHJ5IGRlcGxveW1lbnQg LSBpdCBtYXkgYmUgdXNlZnVsIGZvciBtaXJyb3Jpbmcgc21hbGwNCj4gYml0cyBvZiB0cmVlLCBi dXQgcHJvYmFibHkgbm90IHdvcnRoIHRoZSByZXN1bHRhbnQgcHJvdG9jb2wgZW50cm9weSkuDQo+ DQoNCmljYW5uIG5lZWRzIHRoZSBtaXJyb3Igb2YgYWxsIHRyZWUgZG93bi4NCg0KaWYgeW91IG5l ZWQgdG8gZGV2aWF0ZSBpdCwgeW91IGNhbiBkbyBpdCBpbiB0aGUgcHJvdmlzaW9uIHdheS4NCg0K Zm9yIHRoZSB3d3cudmlwLmJhbmsuY29tLmNvbG91ciBhbmQgd3d3LnZpcC5iYW5rLmNvbS5jb2xv ciAsDQoNCmRvIHlvdSB3aXNoIHRvIGdldCB0aGUgc2FtZSByZXNvbHV0aW9uIG9yIGRldmlhdGUg aXQgdG8gZ2V0IHRoZSBkaWZmZXJlbnQgZG5zIHJlc29sdXRpb24gYW5kIGNvbmZ1c2UgdGhlIHVz ZXJzIHRvIGdldCB0aGUgcG9zc2libGUgcGhpc2hpbmc/DQoNCg0KDQo+IFRoYXQgbGVhdmVzIHVz IHdpdGggYWR2aXNvcnkgcG9pbnRlcnMsIGFuZCB0aGUgdGhlb3JldGljYWwgcG9zc2liaWxpdHkN Cj4gb2YgIm1pcnJvciB3aXRoIGV4Y2VwdGlvbnMiLg0KPiANCj4gLS0gDQo+IEFsZXggQmxpZ2gN Cj4= From owner-namedroppers@ops.ietf.org Mon Aug 16 02:23: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 301763A681B; Mon, 16 Aug 2010 02:23:16 -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: -95.805 X-Spam-Level: X-Spam-Status: No, score=-95.805 tagged_above=-999 required=5 tests=[AWL=0.046, 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, 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 Wf5cf-q5nTgQ; Mon, 16 Aug 2010 02:23:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 328423A67DB; Mon, 16 Aug 2010 02:23:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okvse-000G6e-J5 for namedroppers-data0@psg.com; Mon, 16 Aug 2010 09:21:20 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okvsb-000G5y-G2 for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 09:21:17 +0000 Received: (eyou send program); Mon, 16 Aug 2010 17:21:18 +0800 Message-ID: <481950478.18667@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.9) by 159.226.7.146 with SMTP; Mon, 16 Aug 2010 17:21:18 +0800 Message-ID: <03ef01cb3d24$609d9c50$096ff1da@yaojk> From: "YAO Jiankang" To: "Alex Bligh" , "Florian Weimer" Cc: References: <481924813.14103@cnnic.cn> <2808227A0628F86B45220122@nimrod.local> <481944691.02183@cnnic.cn> Subject: Re: [dnsext] why provisions fail in alias domain names? Date: Mon, 16 Aug 2010 17:21: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.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkZsb3JpYW4gV2VpbWVyIiA8 ZndlaW1lckBiZmsuZGU+DQpUbzogIkFsZXggQmxpZ2giIDxhbGV4QGFsZXgub3JnLnVrPg0KQ2M6 ICJZQU8gSmlhbmthbmciIDx5YW9qa0Bjbm5pYy5jbj47IDxuYW1lZHJvcHBlcnNAb3BzLmlldGYu b3JnPg0KU2VudDogTW9uZGF5LCBBdWd1c3QgMTYsIDIwMTAgMzo0NCBQTQ0KU3ViamVjdDogUmU6 IFtkbnNleHRdIHdoeSBwcm92aXNpb25zIGZhaWwgaW4gYWxpYXMgZG9tYWluIG5hbWVzPw0KDQoN CiogQWxleCBCbGlnaDoNCg0KPiBXaXRoIGEgc29sdXRpb24gdGhhdCBtaXJyb3JzIGEgd2hvbGUg cGFydCBvZiB0aGUgdHJlZSwgdGhlIHJlZ2lzdHJhbnQNCj4gQ0FOTk9UIHB1dCBhIGRldmlhdGlu ZyByZWNvcmQgaW4gKHVubGVzcyB3ZSBnZW5lcmF0ZSBzb21lIHNvcnQgb2YNCj4gbWlycm9yaW5n IGJ5IGV4Y2VwdGlvbikgd2hpY2ggbWVhbnMgZm9yIG1hbnkgYXBwbGljYXRpb25zIGF0IGxlYXN0 DQo+IG9uZSBlcXVpdmFsZW50IG5hbWUgY2FuJ3Qgd29yay4NCg0KZm9yIHRoZSB3d3cudmlwLmJh bmsuY29tLmNvbG91ciBhbmQgd3d3LnZpcC5iYW5rLmNvbS5jb2xvciAsDQoNCmRvIHlvdSB3aXNo IHRvIGdldCB0aGUgc2FtZSByZXNvbHV0aW9uIG9yIGRldmlhdGUgaXQgdG8gZ2V0IHRoZSBkaWZm ZXJlbnQgZG5zIHJlc29sdXRpb24gYW5kIGNvbmZ1c2UgdGhlIHVzZXJzIHRvIGdldCB0aGUgcG9z c2libGUgcGhpc2hpbmc/DQoNCg0KLS0gDQpGbG9yaWFuIFdlaW1lciAgICAgICAgICAgICAgICA8 ZndlaW1lckBiZmsuZGU+DQpCRksgZWR2LWNvbnN1bHRpbmcgR21iSCAgICAgICBodHRwOi8vd3d3 LmJmay5kZS8NCktyaWVnc3N0cmHfZSAxMDAgICAgICAgICAgICAgIHRlbDogKzQ5LTcyMS05NjIw MS0xDQpELTc2MTMzIEthcmxzcnVoZSAgICAgICAgICAgICBmYXg6ICs0OS03MjEtOTYyMDEtOTk= From owner-namedroppers@ops.ietf.org Mon Aug 16 02: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 E7C0C3A6892; Mon, 16 Aug 2010 02:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.358 X-Spam-Level: * X-Spam-Status: No, score=1.358 tagged_above=-999 required=5 tests=[AWL=-0.747, 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 8vRmAJsWUMjd; Mon, 16 Aug 2010 02:27:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA6FF3A67DB; Mon, 16 Aug 2010 02:27:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okvwi-000Ghi-UN for namedroppers-data0@psg.com; Mon, 16 Aug 2010 09:25:32 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okvwg-000GhN-BS for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 09:25:30 +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 DF3E7C56948; Mon, 16 Aug 2010 10:25:28 +0100 (BST) Date: Mon, 16 Aug 2010 10:25:28 +0100 From: Alex Bligh Reply-To: Alex Bligh To: YAO Jiankang cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] why provisions fail in alias domain names? Message-ID: In-Reply-To: <481950227.07802@cnnic.cn> References: <481924813.14103@cnnic.cn> <2808227A0628F86B45220122@nimrod.local> <481943396.02183@cnnic.cn> <481950227.07802@cnnic.cn> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 16 August 2010 17:17:04 +0800 YAO Jiankang wrote: > cname or dname is also a kind of XNAME. > > do you mean that cname or dname encourage unpleasant hacks? If they were used to mirror whole branches of tree from the registry downwards, yes. >> I am becoming convinced XNAME is not the answer (at least to ICANN's >> problem and registry deployment - it may be useful for mirroring small >> bits of tree, but probably not worth the resultant protocol entropy). > > icann needs the mirror of all tree down. My question is whether ICANN wants the functionality or the data to be mirrored. If the latter, I suspect that is only because they wrongly think it implies the former. > if you need to deviate it, you can do it in the provision way. > > for the www.vip.bank.com.colour and www.vip.bank.com.color , You cannot do that if someone has done $ORIGIN. colour. IN XNAME color. That is my point. -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 16 02:30: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 912033A6849; Mon, 16 Aug 2010 02:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.44 X-Spam-Level: * X-Spam-Status: No, score=1.44 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=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 oihITDAHz1Pi; Mon, 16 Aug 2010 02:30:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7F8DB3A697D; Mon, 16 Aug 2010 02:30:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkvzH-000H7b-SS for namedroppers-data0@psg.com; Mon, 16 Aug 2010 09:28:11 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkvzC-000H5A-Mu for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 09:28:06 +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 11AD1C56931; Mon, 16 Aug 2010 10:28:04 +0100 (BST) Date: Mon, 16 Aug 2010 10:28:04 +0100 From: Alex Bligh Reply-To: Alex Bligh To: YAO Jiankang , Florian Weimer cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] why provisions fail in alias domain names? Message-ID: <40E819E813EC94896D83B74F@Ximines.local> In-Reply-To: <481950478.18667@cnnic.cn> References: <481924813.14103@cnnic.cn> <2808227A0628F86B45220122@nimrod.local> <481944691.02183@cnnic.cn> <481950478.18667@cnnic.cn> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 16 August 2010 17:21:15 +0800 YAO Jiankang wrote: > do you wish to get the same resolution or deviate it to get the different > dns resolution and confuse the users to get the possible phishing? I don't want to get the same resolution, I want the registrant to get a working service. Whatever risk of phishing there is can be eliminated by a registry policy saying only the registrant of 'foo.color' can register 'foo.colour', or, a fortiori, ensuring that the NS and glue records for foo.colour always match those of foo.color. IE just copy the zonefile. Confusion is GREATER with an XNAME as people will inevitably receive invalid certificates (e.g. if they run Windows XP, run IIS, etc. etc.) Saying the manual provisioning hack encourages phishing and confusion is just handwaving unless you explain why. -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 16 02:39: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 4B1C23A68B0; Mon, 16 Aug 2010 02:39:10 -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: -95.817 X-Spam-Level: X-Spam-Status: No, score=-95.817 tagged_above=-999 required=5 tests=[AWL=0.034, 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, 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 RZb4qYNKW9ks; Mon, 16 Aug 2010 02:39:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3BE083A6892; Mon, 16 Aug 2010 02:39:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okw7l-000IVx-Kb for namedroppers-data0@psg.com; Mon, 16 Aug 2010 09:36:57 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okw7i-000IVR-U0 for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 09:36:55 +0000 Received: (eyou send program); Mon, 16 Aug 2010 17:36:55 +0800 Message-ID: <481951415.18667@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.9) by 159.226.7.146 with SMTP; Mon, 16 Aug 2010 17:36:55 +0800 Message-ID: <047301cb3d26$8f023810$096ff1da@yaojk> From: "YAO Jiankang" To: "Alex Bligh" Cc: References: <481924813.14103@cnnic.cn> <2808227A0628F86B45220122@nimrod.local> <481943396.02183@cnnic.cn> <481950227.07802@cnnic.cn> <481950736.18938@cnnic.cn> Subject: Re: [dnsext] why provisions fail in alias domain names? Date: Mon, 16 Aug 2010 17:36:52 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsZXggQmxpZ2giIDxhbGV4 QGFsZXgub3JnLnVrPg0KVG86ICJZQU8gSmlhbmthbmciIDx5YW9qa0Bjbm5pYy5jbj4NCkNjOiA8 bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZz47ICJBbGV4IEJsaWdoIiA8YWxleEBhbGV4Lm9yZy51 az4NClNlbnQ6IE1vbmRheSwgQXVndXN0IDE2LCAyMDEwIDU6MjUgUE0NClN1YmplY3Q6IFJlOiBb ZG5zZXh0XSB3aHkgcHJvdmlzaW9ucyBmYWlsIGluIGFsaWFzIGRvbWFpbiBuYW1lcz8NCg0KDQo+ IA0KPiANCj4gLS1PbiAxNiBBdWd1c3QgMjAxMCAxNzoxNzowNCArMDgwMCBZQU8gSmlhbmthbmcg PHlhb2prQGNubmljLmNuPiB3cm90ZToNCj4gDQo+PiBjbmFtZSBvciBkbmFtZSBpcyBhbHNvIGEg a2luZCBvZiBYTkFNRS4NCj4+DQo+PiBkbyB5b3UgbWVhbiB0aGF0IGNuYW1lIG9yIGRuYW1lIGVu Y291cmFnZSB1bnBsZWFzYW50IGhhY2tzPw0KPiANCj4gSWYgdGhleSB3ZXJlIHVzZWQgdG8gbWly cm9yIHdob2xlIGJyYW5jaGVzIG9mIHRyZWUgZnJvbSB0aGUNCj4gcmVnaXN0cnkgZG93bndhcmRz LCB5ZXMuDQo+IA0KPj4+IEkgYW0gYmVjb21pbmcgY29udmluY2VkIFhOQU1FIGlzIG5vdCB0aGUg YW5zd2VyIChhdCBsZWFzdCB0byBJQ0FOTidzDQo+Pj4gcHJvYmxlbSBhbmQgcmVnaXN0cnkgZGVw bG95bWVudCAtIGl0IG1heSBiZSB1c2VmdWwgZm9yIG1pcnJvcmluZyBzbWFsbA0KPj4+IGJpdHMg b2YgdHJlZSwgYnV0IHByb2JhYmx5IG5vdCB3b3J0aCB0aGUgcmVzdWx0YW50IHByb3RvY29sIGVu dHJvcHkpLg0KPj4NCj4+IGljYW5uIG5lZWRzIHRoZSBtaXJyb3Igb2YgYWxsIHRyZWUgZG93bi4N Cj4gDQo+IE15IHF1ZXN0aW9uIGlzIHdoZXRoZXIgSUNBTk4gd2FudHMgdGhlIGZ1bmN0aW9uYWxp dHkgb3IgdGhlDQo+IGRhdGEgdG8gYmUgbWlycm9yZWQuIElmIHRoZSBsYXR0ZXIsIEkgc3VzcGVj dCB0aGF0IGlzIG9ubHkNCj4gYmVjYXVzZSB0aGV5IHdyb25nbHkgdGhpbmsgaXQgaW1wbGllcyB0 aGUgZm9ybWVyLg0KPiANCg0KaWNhbm4gb25seSBtYW5hZ2VzIHRoZSB0b3AgbGV2ZWwgZG9tYWlu LCBub3QgdGhlIHNlY29uZCBvciB0aGUgdGhpcmQuDQp0aGV5IHdhbnQgdGhlIHNlY29uZCBhbmQg dGhlIHRoaXJkIHRvIGJlIHJlc29sdmVkIGluIHRoZSBzYW1lIHdheSwNCnNvIGZ1bmN0aW9uIGlz IG5vdCBvayBmb3IgdGhlbS4NCg0KPj4gaWYgeW91IG5lZWQgdG8gZGV2aWF0ZSBpdCwgeW91IGNh biBkbyBpdCBpbiB0aGUgcHJvdmlzaW9uIHdheS4NCj4+DQo+PiBmb3IgdGhlIHd3dy52aXAuYmFu ay5jb20uY29sb3VyIGFuZCB3d3cudmlwLmJhbmsuY29tLmNvbG9yICwNCj4gDQo+IFlvdSBjYW5u b3QgZG8gdGhhdCBpZiBzb21lb25lIGhhcyBkb25lDQo+ICRPUklHSU4uDQo+IGNvbG91ci4gSU4g WE5BTUUgY29sb3IuDQo+IA0KPiBUaGF0IGlzIG15IHBvaW50Lg0KPiANCg0KdGhhdCBpcyB3aHkg eG5hbWUgc29sdmUgdGhlIGNvbmNlcm4gb2YgaWNhbm4uDQoNCnRoZXkgZG8gbm90IGxpa2UgdG8g ZGV2aWF0ZSBpdCBmb3IgdGhlc2UgMiBkb21haW4gbmFtZXMuDQoNCg0KPiAtLSANCj4gQWxleCBC bGlnaA== From owner-namedroppers@ops.ietf.org Mon Aug 16 02:48: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 EA0EE3A681F; Mon, 16 Aug 2010 02:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.431 X-Spam-Level: * X-Spam-Status: No, score=1.431 tagged_above=-999 required=5 tests=[AWL=-0.674, 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 k0797f1RdUtw; Mon, 16 Aug 2010 02:48:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 24A843A681B; Mon, 16 Aug 2010 02:48:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkwGz-000K90-EN for namedroppers-data0@psg.com; Mon, 16 Aug 2010 09:46:29 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkwGv-000K8Q-Rh for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 09:46:27 +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 647B5C56949; Mon, 16 Aug 2010 10:46:24 +0100 (BST) Date: Mon, 16 Aug 2010 10:46:23 +0100 From: Alex Bligh Reply-To: Alex Bligh To: YAO Jiankang cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] why provisions fail in alias domain names? Message-ID: <2A41CDE5F729C2F7025D2A05@Ximines.local> In-Reply-To: <481951415.18667@cnnic.cn> References: <481924813.14103@cnnic.cn> <2808227A0628F86B45220122@nimrod.local> <481943396.02183@cnnic.cn> <481950227.07802@cnnic.cn> <481950736.18938@cnnic.cn> <481951415.18667@cnnic.cn> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 16 August 2010 17:36:52 +0800 YAO Jiankang wrote: >> My question is whether ICANN wants the functionality or the >> data to be mirrored. If the latter, I suspect that is only >> because they wrongly think it implies the former. > > icann only manages the top level domain, not the second or the third. > they want the second and the third to be resolved in the same way, > so function is not ok for them. ... > that is why xname solve the concern of icann. > > they do not like to deviate it for these 2 domain names. If that is ICANN's concern, which I have my doubts about for the reasons above, then it is a concern which should not be addressed by a DNS protocol change of the XNAME type, because it would require a great deal of effort to produce an undesirable outcome. If registries want to come to agreements with ICANN to do broken stuff, that's fine by me, but we should not be facilitating that with protocol changes at the expense of everyone else. Note that personally I would be incredibly surprised if ICANN was consciously migrated something this broken (i.e. they may not have realised it /harms/ using equivalence at the application layer). -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 16 02:54: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 C4CFB3A6982; Mon, 16 Aug 2010 02:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.462 X-Spam-Level: * X-Spam-Status: No, score=1.462 tagged_above=-999 required=5 tests=[AWL=-0.643, 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 gsva+D5UC7EM; Mon, 16 Aug 2010 02:54:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 045F43A681B; Mon, 16 Aug 2010 02:54:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkwM8-000L6e-J9 for namedroppers-data0@psg.com; Mon, 16 Aug 2010 09:51:48 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkwM5-000L67-NK for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 09:51:46 +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 3ADCEC5694A; Mon, 16 Aug 2010 10:51:42 +0100 (BST) Date: Mon, 16 Aug 2010 10:51:41 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Alex Bligh , YAO Jiankang cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] why provisions fail in alias domain names? Message-ID: In-Reply-To: <2A41CDE5F729C2F7025D2A05@Ximines.local> References: <481924813.14103@cnnic.cn> <2808227A0628F86B45220122@nimrod.local> <481943396.02183@cnnic.cn> <481950227.07802@cnnic.cn> <481950736.18938@cnnic.cn> <481951415.18667@cnnic.cn> <2A41CDE5F729C2F7025D2A05@Ximines.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 16 August 2010 10:46:23 +0100 Alex Bligh wrote: > Note that personally I would be incredibly surprised if > ICANN was consciously *mandating* something this broken > (i.e. they may not have realised it /harms/ using > equivalence at the application layer). (typo fixed) -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 16 04:13: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 6650C3A698B; Mon, 16 Aug 2010 04:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=-1.425, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD72AEoY42W2; Mon, 16 Aug 2010 04:13:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C41433A6993; Mon, 16 Aug 2010 04:13:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkxXt-0006rD-PL for namedroppers-data0@psg.com; Mon, 16 Aug 2010 11:08:01 +0000 Received: from [131.111.8.132] (helo=ppsw-32.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkxXr-0006qO-7N for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 11:07:59 +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]:59797) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1OkxXl-0003rI-08 (Exim 4.72) (return-path ); Mon, 16 Aug 2010 12:07:53 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OkxXl-00022q-0u (Exim 4.67) (return-path ); Mon, 16 Aug 2010 12:07:53 +0100 Date: Mon, 16 Aug 2010 12:07:53 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= cc: Phillip Hallam-Baker , YAO Jiankang , namedroppers@ops.ietf.org Subject: Re: [dnsext] why provisions fail in alias domain names? In-Reply-To: <731A21A7-340B-4B53-9DB2-90DD9004ED51@cisco.com> Message-ID: References: <481924813.14103@cnnic.cn> <731A21A7-340B-4B53-9DB2-90DD9004ED51@cisco.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870024-1482245867-1281956873=:935" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870024-1482245867-1281956873=:935 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 16 Aug 2010, Patrik F=E4ltstr=F6m wrote: > > If the application do see the "magic alias", then the application also > do know what the canonical version of the domain name is. And the > application can in the further processing use that canonical name for > the processing. That is insecure. The TLS certificate MUST match the domain name that the user typed in otherwise the user is open to spoofing. Tony. --=20 f.anthony.n.finch http://dotat.at/ WIGHT PORTLAND PLYMOUTH: NORTHWEST BACKING WEST OR SOUTHWEST 4 OR 5, OCCASIONALLY 6 EXCEPT IN PORTLAND, DECREASING 3 AT TIMES IN PLYMOUTH. SLIGH= T OR MODERATE. RAIN LATER. MODERATE OR GOOD. --1870870024-1482245867-1281956873=:935-- From owner-namedroppers@ops.ietf.org Mon Aug 16 04:28: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 F3D103A69B2; Mon, 16 Aug 2010 04:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.011, 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 nYfdZ9hwd0ma; Mon, 16 Aug 2010 04:28:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D1D23A69B6; Mon, 16 Aug 2010 04:28:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okxob-0009VA-6h for namedroppers-data0@psg.com; Mon, 16 Aug 2010 11:25:17 +0000 Received: from [131.111.8.130] (helo=ppsw-30.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OkxoY-0009Uf-Hn for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 11:25:14 +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]:37130) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1OkxoP-0002Zi-dr (Exim 4.72) (return-path ); Mon, 16 Aug 2010 12:25:05 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OkxoP-0004XK-Ay (Exim 4.67) (return-path ); Mon, 16 Aug 2010 12:25:05 +0100 Date: Mon, 16 Aug 2010 12:25:05 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Alex Bligh cc: YAO Jiankang , namedroppers@ops.ietf.org Subject: Re: [dnsext] why provisions fail in alias domain names? In-Reply-To: Message-ID: References: <481924813.14103@cnnic.cn> <2808227A0628F86B45220122@nimrod.local> 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 Mon, 16 Aug 2010, Alex Bligh wrote: > > The goals of having DNS work identically across two equivalent names > and having applications work identically are irreconcilable and > to a certain extent incompatible. In some cases you don't want applications to work identially for equivalent names. For HTTP, it is better to redirect non-cacnonical URLs to their canonical equivalents, to avoid wasting cache space, to avoid cookie mismatches, to keep links and bookmarks consistent, etc. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER: NORTHWEST, BACKING WEST OR SOUTHWEST, 5 TO 7, OCCASIONALLY GALE 8 AT FIRST EXCEPT HUMBER. MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR. From owner-namedroppers@ops.ietf.org Mon Aug 16 06:31: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 3AB973A659B; Mon, 16 Aug 2010 06:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuLizkjvc7Wq; Mon, 16 Aug 2010 06:31:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DDEB63A6837; Mon, 16 Aug 2010 06:31:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okziv-0001mI-5I for namedroppers-data0@psg.com; Mon, 16 Aug 2010 13:27:33 +0000 Received: from [2001:4f8:fff7:1::5] (helo=mail1.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Okzip-0001ka-Oa for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 13:27:27 +0000 Received: from [198.22.153.9] (helo=[10.60.111.69]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OkziW-000M8B-HL; Mon, 16 Aug 2010 13:27:22 +0000 Message-ID: <4C693CA6.1080905@gis.net> Date: Mon, 16 Aug 2010 09:27:02 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jiankang YAO CC: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Andrew Sullivan , namedroppers@ops.ietf.org References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <20100811135657.GA57645@shinkuro.com> <481537251.30643@cnnic.cn> <481540852.30643@cnnic.cn> In-Reply-To: <481540852.30643@cnnic.cn> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 198.22.153.9 X-SA-Exim-Rcpt-To: yaojk@cnnic.cn, paf@cisco.com, ajs@shinkuro.com, namedroppers@ops.ietf.org X-SA-Exim-Mail-From: mayer@ntp.org Subject: [dnsext] Re: An argument why bname-style delegation is needed X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 8/11/2010 11:34 AM, Jiankang YAO wrote: > > ----- Original Message ----- > From: "Patrik Fältström" > To: "Andrew Sullivan" > Cc: > Sent: Wednesday, August 11, 2010 10:22 PM > Subject: Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same") > >> >> > > On 11 aug 2010, at 15.56, Andrew Sullivan wrote: > > > Under a provisioning-only regime, the requirement that N1.P and N2.P > > be "the same name" cannot be guaranteed. That is because under > > provisioning, it would be necessary to duplicate all the zones all the > > way down the tree, and there is no easy way in the DNS to check that > > two zones are equivalent without walking the zone. > > > > Is that the argument? > > For me, yes, with the addition that it is not to me perfectly clear > if the risk is zero that competition rules in various legislations might force the two zones N1.P and N2.P be delegated to entities according to some RFP process that MIGHT result in the two domains be run by two different registries. > > Specifically if N1.P exists, and N2.P is to be allocated. A > competitor to the registry for N1.P might very well ask to become the registry for N2.P, if N2.P was in reality delegated. > > If instead N1.P is delegated, and N2.P was some pointer to N1.P, > then that competition argument would not exist. > +1 If the problem is legislative, it really doesn't belong as a DNS issue. If you have this situation you can easily have N1.P copied to the owner of the N2.P registration and have it provision N2.P. danny From owner-namedroppers@ops.ietf.org Mon Aug 16 06:52: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 5C1D83A67BD; Mon, 16 Aug 2010 06:52:06 -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: -97.411 X-Spam-Level: X-Spam-Status: No, score=-97.411 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_05=-1.11, 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, 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 TOK9XF1va3rg; Mon, 16 Aug 2010 06:52:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 103473A659B; Mon, 16 Aug 2010 06:52:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ol04O-0005Cm-IP for namedroppers-data0@psg.com; Mon, 16 Aug 2010 13:49:44 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ol04L-0005BL-QQ for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 13:49:42 +0000 Received: (eyou send program); Mon, 16 Aug 2010 21:49:38 +0800 Message-ID: <481966578.11120@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, 16 Aug 2010 21:49:38 +0800 Message-ID: <37DE1A1A676B4F93B30C3B27021B3B57@LENOVO47E041CF> From: "Jiankang YAO" To: "Tony Finch" , "Alex Bligh" Cc: References: <481924813.14103@cnnic.cn> <2808227A0628F86B45220122@nimrod.local> <481959349.29055@cnnic.cn> Subject: Re: [dnsext] why provisions fail in alias domain names? Date: Mon, 16 Aug 2010 21:50:05 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlRvbnkgRmluY2giIDxkb3RA ZG90YXQuYXQ+DQpUbzogIkFsZXggQmxpZ2giIDxhbGV4QGFsZXgub3JnLnVrPg0KQ2M6ICJZQU8g SmlhbmthbmciIDx5YW9qa0Bjbm5pYy5jbj47IDxuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnPg0K U2VudDogTW9uZGF5LCBBdWd1c3QgMTYsIDIwMTAgNzoyNSBQTQ0KU3ViamVjdDogUmU6IFtkbnNl eHRdIHdoeSBwcm92aXNpb25zIGZhaWwgaW4gYWxpYXMgZG9tYWluIG5hbWVzPw0KDQoNCj4gT24g TW9uLCAxNiBBdWcgMjAxMCwgQWxleCBCbGlnaCB3cm90ZToNCj4+DQo+PiAgVGhlIGdvYWxzIG9m IGhhdmluZyBETlMgd29yayBpZGVudGljYWxseSBhY3Jvc3MgdHdvIGVxdWl2YWxlbnQgbmFtZXMN Cj4+ICAgYW5kIGhhdmluZyBhcHBsaWNhdGlvbnMgd29yayBpZGVudGljYWxseSBhcmUgaXJyZWNv bmNpbGFibGUgYW5kDQo+PiAgIHRvIGEgY2VydGFpbiBleHRlbnQgaW5jb21wYXRpYmxlLg0KPiAN Cj4gSW4gc29tZSBjYXNlcyB5b3UgZG9uJ3Qgd2FudCBhcHBsaWNhdGlvbnMgdG8gd29yayBpZGVu dGlhbGx5IGZvcg0KPiBlcXVpdmFsZW50IG5hbWVzLiBGb3IgSFRUUCwgaXQgaXMgYmV0dGVyIHRv IHJlZGlyZWN0IG5vbi1jYWNub25pY2FsIFVSTHMNCj4gdG8gdGhlaXIgY2Fub25pY2FsIGVxdWl2 YWxlbnRzLCB0byBhdm9pZCB3YXN0aW5nIGNhY2hlIHNwYWNlLCB0byBhdm9pZA0KPiBjb29raWUg bWlzbWF0Y2hlcywgdG8ga2VlcCBsaW5rcyBhbmQgYm9va21hcmtzIGNvbnNpc3RlbnQsIGV0Yy4N Cj4gDQoNCnRoYXQgbWF5IGJlIHRydWUuDQpidXQgZnJvbSB0aGUgcmVnaXN0cnkncyB2aWV3IG9y IGljYW5uJ3MgdmlldywNCnJlZ2lzdHJ5IHNlbGxzIHRoZSBuYW1lcyB3aXRoaW4gYSBwYWNrYWdl LiBzbyB0aGV5IGhvcGUgdGhlbSB0byBnZXQgdGhlIHNhbWUgaWRlbnRpY2FsIGRucyByZXNvbHV0 aW9uLg0KDQppZiB3ZSB0aGluayB0aGF0IHdlIGNhbiByZXNvbHZlIHRoZXNlIG5hbWVzIGluIGRp ZmZlcmVudCB3YXlzLCB3ZSBtYXkgZG8gbm90aGluZy4NCmJ1dCBzb21lIHJlZ2lzdHJpZXMgb3Ig aWNhbm4gb3IgdXNlcnMgbmVlZCBzb21lIGRvbWFpbiBuYW1lcyB0byBiZSByZXNvbHZlZCBpbiB0 aGUgc2FtZSB3YXkuDQp3ZSBuZWVkIGRvIHNvbWV0aGluZyBmb3IgdGhlbS4NCg0KYW5vdGhlciBy ZWFzb24gaXMgdGhhdCB3ZSB3aWxsIHJlZHVjZSB0aGUgY29uZnVzaW9uIGlmIHdlIHJlc29sdmUg dGhlIG5hbWVzIGluIGVxdWl2YWxlbnQgdG8gdGhlIHNhbWUgaWRlbnRpY2FsIHJlc29sdXRpb24u DQoNCg0KDQo+IFRvbnkuDQo+IC0tIA0KPiBmLmFudGhvbnkubi5maW5jaCAgPGRvdEBkb3RhdC5h dD4gIGh0dHA6Ly9kb3RhdC5hdC8NCj4gSFVNQkVSIFRIQU1FUyBET1ZFUjogTk9SVEhXRVNULCBC QUNLSU5HIFdFU1QgT1IgU09VVEhXRVNULCA1IFRPIDcsDQo+IE9DQ0FTSU9OQUxMWSBHQUxFIDgg QVQgRklSU1QgRVhDRVBUIEhVTUJFUi4gTU9ERVJBVEUgT1IgUk9VR0guIE9DQ0FTSU9OQUwNCj4g UkFJTi4gTU9ERVJBVEUgT1IgR09PRCwgT0NDQVNJT05BTExZIFBPT1Iu From owner-namedroppers@ops.ietf.org Mon Aug 16 07: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 ECB103A69E9; Mon, 16 Aug 2010 07:02:18 -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: -98.147 X-Spam-Level: X-Spam-Status: No, score=-98.147 tagged_above=-999 required=5 tests=[AWL=0.304, 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, 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 J69aw2ROZiw0; Mon, 16 Aug 2010 07:02:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C79B23A69E8; Mon, 16 Aug 2010 07:02:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ol0Dy-0007NV-At for namedroppers-data0@psg.com; Mon, 16 Aug 2010 13:59:38 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ol0Dp-0007KZ-C8 for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 13:59:35 +0000 Received: (eyou send program); Mon, 16 Aug 2010 21:59:21 +0800 Message-ID: <481967161.29047@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, 16 Aug 2010 21:59:21 +0800 Message-ID: <043D744AC0C64E498BF0F2094CCCC0C2@LENOVO47E041CF> From: "Jiankang YAO" To: Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Andrew Sullivan" , References: <481501584.15255@cnnic.cn> <481504066.03751@cnnic.cn> <20100811135657.GA57645@shinkuro.com> <481537251.30643@cnnic.cn> <481540852.30643@cnnic.cn> <4C693CA6.1080905@gis.net> Subject: Re: [dnsext] Re: An argument why bname-style delegation is needed Date: Mon, 16 Aug 2010 21:59:47 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRhbm55IE1heWVyIiA8bWF5 ZXJAZ2lzLm5ldD4NClRvOiAiSmlhbmthbmcgWUFPIiA8eWFvamtAY25uaWMuY24+DQpDYzogIlBh dHJpayBG5Gx0c3Ry9m0iIDxwYWZAY2lzY28uY29tPjsgIkFuZHJldyBTdWxsaXZhbiIgPGFqc0Bz aGlua3Vyby5jb20+OyA8bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZz4NClNlbnQ6IE1vbmRheSwg QXVndXN0IDE2LCAyMDEwIDk6MjcgUE0NClN1YmplY3Q6IFtkbnNleHRdIFJlOiBBbiBhcmd1bWVu dCB3aHkgYm5hbWUtc3R5bGUgZGVsZWdhdGlvbiBpcyBuZWVkZWQNCg0KDQo+IE9uIDgvMTEvMjAx MCAxMTozNCBBTSwgSmlhbmthbmcgWUFPIHdyb3RlOg0KPj4gDQo+PiAtLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIA0KPj4gRnJvbTogIlBhdHJpayBG5Gx0c3Ry9m0iIDxwYWZAY2lzY28uY29t Pg0KPj4gVG86ICJBbmRyZXcgU3VsbGl2YW4iIDxhanNAc2hpbmt1cm8uY29tPg0KPj4gQ2M6IDxu YW1lZHJvcHBlcnNAb3BzLmlldGYub3JnPg0KPj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTEs IDIwMTAgMTA6MjIgUE0NCj4+IFN1YmplY3Q6IFJlOiBBbiBhcmd1bWVudCB3aHkgYm5hbWUtc3R5 bGUgZGVsZWdhdGlvbiBpcyBuZWVkZWQgKHdhczogW2Ruc2V4dF0gRE5TRVhUIGNoYXJ0ZXIgYW5k IHRyZWF0aW5nIEROUyBuYW1lcyBhcyAidGhlIHNhbWUiKQ0KPj4gDQo+Pj4NCj4+Pg0KPj4gDQo+ PiAgIE9uIDExIGF1ZyAyMDEwLCBhdCAxNS41NiwgQW5kcmV3IFN1bGxpdmFuIHdyb3RlOg0KPj4g DQo+PiAgID4gVW5kZXIgYSBwcm92aXNpb25pbmctb25seSByZWdpbWUsIHRoZSByZXF1aXJlbWVu dCB0aGF0IE4xLlAgYW5kIE4yLlANCj4+ICAgPiBiZSAidGhlIHNhbWUgbmFtZSIgY2Fubm90IGJl IGd1YXJhbnRlZWQuICBUaGF0IGlzIGJlY2F1c2UgdW5kZXINCj4+ICAgPiBwcm92aXNpb25pbmcs IGl0IHdvdWxkIGJlIG5lY2Vzc2FyeSB0byBkdXBsaWNhdGUgYWxsIHRoZSB6b25lcyBhbGwgdGhl DQo+PiAgID4gd2F5IGRvd24gdGhlIHRyZWUsIGFuZCB0aGVyZSBpcyBubyBlYXN5IHdheSBpbiB0 aGUgRE5TIHRvIGNoZWNrIHRoYXQNCj4+ICAgPiB0d28gem9uZXMgYXJlIGVxdWl2YWxlbnQgd2l0 aG91dCB3YWxraW5nIHRoZSB6b25lLg0KPj4gICA+IA0KPj4gICA+IElzIHRoYXQgdGhlIGFyZ3Vt ZW50Pw0KPj4gDQo+PiBGb3IgbWUsIHllcywgd2l0aCB0aGUgYWRkaXRpb24gdGhhdCBpdCBpcyBu b3QgdG8gbWUgcGVyZmVjdGx5IGNsZWFyDQo+PiBpZg0KPiB0aGUgcmlzayBpcyB6ZXJvIHRoYXQg Y29tcGV0aXRpb24gcnVsZXMgaW4gdmFyaW91cyBsZWdpc2xhdGlvbnMgbWlnaHQNCj4gZm9yY2Ug dGhlIHR3byB6b25lcyBOMS5QIGFuZCBOMi5QIGJlIGRlbGVnYXRlZCB0byBlbnRpdGllcyBhY2Nv cmRpbmcgdG8NCj4gc29tZSBSRlAgcHJvY2VzcyB0aGF0IE1JR0hUIHJlc3VsdCBpbiB0aGUgdHdv IGRvbWFpbnMgYmUgcnVuIGJ5IHR3bw0KPiBkaWZmZXJlbnQgcmVnaXN0cmllcy4NCj4NCg0KdGhl IHByb2JsZW1zIGlzIHRoYXQgIGlmIHRoZSB0d28gem9uZXMgTjEuUCBhbmQgTjIuUCBhcmUgZGVs ZWdhdGVkIHRvIHRoZSBzYW1lIGVudGl0aWVzLA0Kd2UgbmVlZCBkbyBzb21ldGhpbmcgZm9yIHRo ZW0uDQoNCmJ0dywgaWYgYmFuay5wMSBhbmQgYmFuay5wMiBhcmUgb3duZWQgYnkgdGhlIGRpZmZl cmVudCB1c2VycywgdGhlcmUgaGFzIGEgYmlnIHBoaXNoaW5nIHByb2JsZW1zLg0KSSB0aGluayB0 aGF0IGlmIHZhcmlvdXMgbGVnaXNsYXRpb25zIGJvZHkgcmVjb2duaXplIGl0LCBpdCB3aWxsIGNo YW5nZSB0aGUgcG9saWN5Lg0KDQphcyBmYXIgYXMgSSBrbm93LCBpY2FubiB3aWxsIG5vdCBmb3Jj ZSAgdGhlIHR3byB6b25lcyBOMS5QIGFuZCBOMi5QIGJlIGRlbGVnYXRlZCB0byBlbnRpdGllcy4N Cg0KDQo+DQo+PiANCj4+IFNwZWNpZmljYWxseSBpZiBOMS5QIGV4aXN0cywgYW5kIE4yLlAgaXMg dG8gYmUgYWxsb2NhdGVkLiBBDQo+PiBjb21wZXRpdG9yDQo+IHRvIHRoZSByZWdpc3RyeSBmb3Ig TjEuUCBtaWdodCB2ZXJ5IHdlbGwgYXNrIHRvIGJlY29tZSB0aGUgcmVnaXN0cnkgZm9yDQo+IE4y LlAsIGlmIE4yLlAgd2FzIGluIHJlYWxpdHkgZGVsZWdhdGVkLg0KPj4gDQo+PiBJZiBpbnN0ZWFk IE4xLlAgaXMgZGVsZWdhdGVkLCBhbmQgTjIuUCB3YXMgc29tZSBwb2ludGVyIHRvIE4xLlAsDQo+ PiB0aGVuDQo+IHRoYXQgY29tcGV0aXRpb24gYXJndW1lbnQgd291bGQgbm90IGV4aXN0Lg0KPj4g KzENCj4gDQo+IElmIHRoZSBwcm9ibGVtIGlzIGxlZ2lzbGF0aXZlLCBpdCByZWFsbHkgZG9lc24n dCBiZWxvbmcgYXMgYSBETlMgaXNzdWUuDQo+IElmIHlvdSBoYXZlIHRoaXMgc2l0dWF0aW9uIHlv dSBjYW4gZWFzaWx5IGhhdmUgTjEuUCBjb3BpZWQgdG8gdGhlIG93bmVyDQo+IG9mIHRoZSBOMi5Q IHJlZ2lzdHJhdGlvbiBhbmQgaGF2ZSBpdCBwcm92aXNpb24gTjIuUC4NCj4gDQo+IGRhbm55DQo+ From owner-namedroppers@ops.ietf.org Mon Aug 16 07:20: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 D68BC3A6829; Mon, 16 Aug 2010 07:20:12 -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: -96.573 X-Spam-Level: X-Spam-Status: No, score=-96.573 tagged_above=-999 required=5 tests=[AWL=-1.282, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 ibeAuuNsW2Pr; Mon, 16 Aug 2010 07:20:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 221F53A686A; Mon, 16 Aug 2010 07:20:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ol0Uy-000Alc-Kf for namedroppers-data0@psg.com; Mon, 16 Aug 2010 14:17:12 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ol0Uw-000Al4-37 for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 14:17:10 +0000 Received: (eyou send program); Mon, 16 Aug 2010 22:17:11 +0800 Message-ID: <481968231.03365@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, 16 Aug 2010 22:17:11 +0800 Message-ID: <12389FB4BD90402CA6C0238F35E65D0A@LENOVO47E041CF> From: "Jiankang YAO" To: Subject: [dnsext] application issues for the alias names Date: Mon, 16 Aug 2010 22:17:39 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0429_01CB3D90.D69E13A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0429_01CB3D90.D69E13A0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 dGhlcmUgdHdvIGFsaWFzIG5hbWVzOiBhbGlhczEuZXhhbXBsZSBhbmQgYWxpYXMyLmV4YW1wbGUu DQp0aGVyZSB0d28gZGlmZmVyZW50IG5hbWVzOiB0ZXN0LmV4YW1wbGUgYW5kIGRpZmZlcmVudC5l eG1hcGxlLnRlc3QuDQoNCmlmIHdlIGNvbmZpZ3VyZSB0aGVzZSBuYW1lcyBiZWxvdzoNCg0KYWxp YXMxLmV4YW1wbGUgeG5hbWUgYWxpYXMyLmV4YW1wbGUNCmFsaWFzMi5leG1hcGxlIEEgMTkyLjE2 OC4xLjENCg0KDQp0ZXN0LmV4YW1wbGUgQSAxOTIuMTY4LjEuMQ0KZGlmZmVyZW50LmV4bWFwbGUu dGVzdCBBIDE5Mi4xNjguMS4xDQoNCg0KYWZ0ZXIgdGhlIGRucyBsb29rdXAsDQoNCnRoZSBhcHBs aWNhdGlvbiB3aWxsIGdldDoNCg0KYWxpYXMxLmV4YW1wbGUgIEEgMTkyLjE2OC4xLjENCmFsaWFz Mi5leG1hcGxlIEEgMTkyLjE2OC4xLjENCg0KdGVzdC5leGFtcGxlIEEgMTkyLjE2OC4xLjENCmRp ZmZlcmVudC5leG1hcGxlLnRlc3QgQSAxOTIuMTY4LjEuMQ0KDQppZiBvbmUgY29tcGFueSBoYXMg dHdvIGRvbWFpbiBuYW1lcywgZGlmZmVyZW50LmV4bWFwbGUudGVzdCAgYW5kIHRlc3QuZXhhbXBs ZSAsDQp0aGV5IG1heSBjb25maWd1cmUgaXQgdG8gZ2V0IHRoZSBzYW1lIGRucyByZXNvbHVpb24g dmlhIHByb3Zpc2lvbi4NCg0Kb25lIGNvbXBhbnkgbWF5IHByb2Nlc3MgdGhlIGFsaWFzIG5hbWVz IHRocm91Z2ggdGhlIHhuYW1lIHdheS4NCg0KZmluYWxseSwNCg0KdGhleSBnZXQgdGhlIGFkZHJl c3MgMTkyLjE2OC4xLjEuDQoNCmlzIHRoZXJlIGFueSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlc2Ug bmFtZXMgdG8gdGhlaXIgZmluYWwgcmVzdWx0cyBleGNlcHQgTVggcHJvYmxlbXMgYW5kIGRpZmZl cmVudCBkbnMgbG9va3VwIHByb2NlZHVyZT8NCg0KaWYgdGhlIGZpbmFsIHJlc3VsdHMgYXJlIHNh bWUsIHNvIHRoZSBhcHBsaWNhdGlvbiBjb25maWd1cmF0aW9uIGlzIHNhbWUgZm9yIHByb3Zpc2lv bmFsIHdheSBhbmQgeG5hbWUgd2F5Lg0KDQoNCg0KDQoNCg== ------=_NextPart_000_0429_01CB3D90.D69E13A0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE4OTI4Ij4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jY2NlOGNmPg0KPERJVj48Rk9OVCBzaXplPTI+dGhlcmUgdHdvIGFsaWFz IG5hbWVzOiBhbGlhczEuZXhhbXBsZSBhbmQgDQphbGlhczIuZXhhbXBsZS48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj50aGVyZSB0d28gZGlmZmVyZW50IG5hbWVzOiB0ZXN0LmV4YW1w bGUgYW5kIA0KZGlmZmVyZW50LmV4bWFwbGUudGVzdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5pZiB3ZSBjb25m aWd1cmUgdGhlc2UgbmFtZXMgYmVsb3c6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+YWxpYXMxLmV4YW1wbGUgeG5h bWUgYWxpYXMyLmV4YW1wbGU8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5hbGlhczIu ZXhtYXBsZSBBIDE5Mi4xNjguMS4xPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+dGVzdC5leGFtcGxlIEEgMTkyLjE2OC4xLjE8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5kaWZmZXJlbnQuZXhtYXBsZS50ZXN0IEEgMTkyLjE2OC4xLjE8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5hZnRl ciB0aGUgZG5zIGxvb2t1cCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj50aGUgYXBwbGljYXRpb24gd2lsbCBnZXQ6 PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+YWxpYXMxLmV4YW1wbGUmbmJzcDsgQSAxOTIuMTY4LjEuMTwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmFsaWFzMi5leG1hcGxlIEEgMTkyLjE2OC4xLjE8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIHNpemU9Mj4NCjxESVY+PEZPTlQgc2l6ZT0yPnRlc3QuZXhhbXBsZSBBIDE5Mi4xNjguMS4x PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ZGlmZmVyZW50LmV4bWFwbGUudGVzdCBB IDE5Mi4xNjguMS4xPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+aWYgb25l IGNvbXBhbnkgaGFzIHR3byBkb21haW4gbmFtZXMsIGRpZmZlcmVudC5leG1hcGxlLnRlc3QmbmJz cDsgYW5kIA0KdGVzdC5leGFtcGxlICw8L0RJVj4NCjxESVY+dGhleSBtYXkgY29uZmlndXJlIGl0 IHRvIGdldCB0aGUgc2FtZSBkbnMgcmVzb2x1aW9uIHZpYSBwcm92aXNpb24uPC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj5vbmUgY29tcGFueSBtYXkgcHJvY2VzcyB0aGUgYWxpYXMgbmFt ZXMgdGhyb3VnaCB0aGUgeG5hbWUgd2F5LjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ ZmluYWxseSw8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPnRoZXkgZ2V0IHRoZSBhZGRy ZXNzIDE5Mi4xNjguMS4xLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+aXMgdGhlcmUg YW55IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGVzZSBuYW1lcyB0byB0aGVpciBmaW5hbCByZXN1bHRz IGV4Y2VwdCANCk1YIHByb2JsZW1zIGFuZCBkaWZmZXJlbnQgZG5zIGxvb2t1cCBwcm9jZWR1cmU/ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5pZiB0aGUgZmluYWwgcmVzdWx0cyBhcmUg c2FtZSwgc28gdGhlIGFwcGxpY2F0aW9uIGNvbmZpZ3VyYXRpb24gaXMgc2FtZSBmb3IgDQpwcm92 aXNpb25hbCB3YXkgYW5kIHhuYW1lIHdheS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJz cDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0429_01CB3D90.D69E13A0-- From owner-namedroppers@ops.ietf.org Mon Aug 16 08:53: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 70F4E3A69EC; Mon, 16 Aug 2010 08:53:36 -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 peZjyMY6yeyY; Mon, 16 Aug 2010 08:53:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9AFE13A67B2; Mon, 16 Aug 2010 08:53:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ol1uf-000ORj-EG for namedroppers-data0@psg.com; Mon, 16 Aug 2010 15:47:49 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ol1ub-000ORF-ED for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 15:47:46 +0000 Received: from [192.168.1.68] (unknown [86.53.162.241]) by mail.avalus.com (Postfix) with ESMTPSA id 4679FC5694A; Mon, 16 Aug 2010 16:47:43 +0100 (BST) Date: Mon, 16 Aug 2010 16:47:42 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jiankang YAO , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] application issues for the alias names Message-ID: <456C030E79D8EB4274F20052@nimrod.local> In-Reply-To: <481968231.03365@cnnic.cn> References: <481968231.03365@cnnic.cn> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 16 August 2010 22:17:39 +0800 Jiankang YAO wrote: > if the final results are same, so the application configuration is same > for provisional way and xname way. If I understand your example, you have shown that it is always possible to configure "the provisioning hack" to produce the same result as XNAME. You have not shown the converse (i.e. how XNAME can produce 192.168.1.1 for one query and 192.168.1.2 for the other, like 2 A records can). -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 16 11:36: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 A75223A6A0F; Mon, 16 Aug 2010 11:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[AWL=-0.388, 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 rNwo-nhHILT6; Mon, 16 Aug 2010 11:36:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3542C3A6A40; Mon, 16 Aug 2010 11:36:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ol4T7-000OqF-6J for namedroppers-data0@psg.com; Mon, 16 Aug 2010 18:31:33 +0000 Received: from [209.85.213.52] (helo=mail-yw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ol4T4-000Oq3-Ar for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 18:31:30 +0000 Received: by ywl5 with SMTP id 5so3053797ywl.11 for ; Mon, 16 Aug 2010 11:31:29 -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=BVCcZszubjVDtgFn9JMfGIPrfo2iAX6zdF7el+kWAiA=; b=IyhjwsRdwTu6Y3oEXNqcB5+FycgWFb983OJ0PN96wmDozSo1NZ0jOm7oxcchg/hWJa g3K/ntX+m0f+B+HOYeNglHptrc2s6Tt9vlTt/cwMFIP6dlBW9F7SSADSSUNHP8vq/j44 FG73Q5Fg3XtPhnzgqfsfYMixkw4sE1qPtMJFo= 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=xTQYfheqPh5hC+68XNDomCxafMW1skWQr56iqRMKjS8SoH/xXTz+SKAcXLhVGmuBPs zXPJQt1nbS19zvJXoVypt+oSomLXfc/eVk1IPAeqvSmyKuSNrx9sL8UmNdBy2t3SEKtz x51eWaS16botll0QqaS5Ms7G/Nz4Apzqelki4= MIME-Version: 1.0 Received: by 10.100.23.2 with SMTP id 2mr6297866anw.119.1281983489477; Mon, 16 Aug 2010 11:31:29 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Mon, 16 Aug 2010 11:31:29 -0700 (PDT) In-Reply-To: <731A21A7-340B-4B53-9DB2-90DD9004ED51@cisco.com> References: <481924813.14103@cnnic.cn> <731A21A7-340B-4B53-9DB2-90DD9004ED51@cisco.com> Date: Mon, 16 Aug 2010 14:31:29 -0400 Message-ID: Subject: Re: [dnsext] why provisions fail in alias domain names? From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: YAO Jiankang , 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: By 'magic pointer', I mean fixing everything up in the DNS so the packets get routed to the right IP address regardless of whether the application knows how to follow these pointers. If we are not going to have magic fixup in the core of the DNS protocol then the problem is really very easy. You put pointers in the DNS for apps that can follow them and place the whole responsibility for managing this problem where it belongs - at the endpoint. If people try to put magic fixup in the DNS core that is going to cause existing applications to break then its game over. This working group will never converge and nor will the result be accepted by the wider IETF. This is a problem that actually does calls out for an end-to-end solution. I am not a fan of end-to-end absolutism. I think you put the complexity where it makes most sense. But in this case there is no solution unless the endpoints are modified to make use of it. Therefore there is no justification for a middlebox type approach, much as I like those in many cases. As you point out, application side fixup does work. I would suggest though that your example works best if the XNames are understood to be the second class citizens they are. Applications should translate xnames before placing the names in address books or in URLs. Otherwise the links are going to break when they are used by a non-capable application. 2010/8/16 Patrik F=E4ltstr=F6m : > > On 16 aug 2010, at 04.45, Phillip Hallam-Baker wrote: > >> Magic pointers are going to break HTTP and SMTP. They are also going >> to break SSL. And there is absolutely no way to fix that. > > It doesn't have to. It all depends on whether the application do "see" th= e pointer or not. > > Ted Hardie suggested something that I almost missed in this discussion, s= o I went offline asking him about it. I completely agree with his finding. > > If the application do see the "magic alias", then the application also do= know what the canonical version of the domain name is. And the application= can in the further processing use that canonical name for the processing. = For example the HOST header in the HTTP protocol. > > Say we have: > > A1.example. IN A 1.2.3.4 > A2.example. IN xNAME A1.example. > A3.example. IN xNAME A1.example. > A4.example. IN xNAME A1.example. > > Then we can say that application _MUST_ get to see the xNAME record, and = then use A1.example in the various protocols. > > =A0 Patrik > > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Mon Aug 16 12:11: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 D242E3A6A4D; Mon, 16 Aug 2010 12:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.081 X-Spam-Level: X-Spam-Status: No, score=-100.081 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 BR2NzxK6SYZ2; Mon, 16 Aug 2010 12:11:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 314023A6A53; Mon, 16 Aug 2010 12:11:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ol53E-0004JU-B6 for namedroppers-data0@psg.com; Mon, 16 Aug 2010 19:08:52 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ol53C-0004JC-3Q for namedroppers@ops.ietf.org; Mon, 16 Aug 2010 19:08: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 952931ECB408 for ; Mon, 16 Aug 2010 19:08:48 +0000 (UTC) Date: Mon, 16 Aug 2010 15:08:46 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] why provisions fail in alias domain names? Message-ID: <20100816190846.GG84641@shinkuro.com> References: <481924813.14103@cnnic.cn> <731A21A7-340B-4B53-9DB2-90DD9004ED51@cisco.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: No hat. On Mon, Aug 16, 2010 at 02:31:29PM -0400, Phillip Hallam-Baker wrote: > the second class citizens they are. Applications should translate > xnames before placing the names in address books or in URLs. Otherwise > the links are going to break when they are used by a non-capable > application. A few comments about this: 1. What does an application that happens to be offline or not really a network client (think "URL highlighting in a word processor", for instance) do about this? 2. If you're going to normalize to the canonical name, don't you need some way of knowing that you've normalized? In the context of the IDN use case (the only one we've really been exploring), a significant part of the point is to display in a way that is natural to the user, even if that isn't the "real" domain name. So now we need a way to go "back". 3. If we need a way to go "back", don't we need a way to tell that there _is_ a "back"? That is, is it necessary to invent the "AKA" RRTYPE (or something like that) so that in the canonical zone you can indicate what other names are good and valid pointers to the zone (and which are "unauthorized")? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Aug 16 17:54: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 E1C5F3A6894; Mon, 16 Aug 2010 17:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.208 X-Spam-Level: X-Spam-Status: No, score=-0.208 tagged_above=-999 required=5 tests=[AWL=0.287, 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 0JMVLbx+-ZFp; Mon, 16 Aug 2010 17:54:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8A4893A6835; Mon, 16 Aug 2010 17:54:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlANB-000PAX-KT for namedroppers-data0@psg.com; Tue, 17 Aug 2010 00:49:49 +0000 Received: from [74.125.83.52] (helo=mail-gw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlAN8-000PAE-Oq for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 00:49:46 +0000 Received: by gwj20 with SMTP id 20so3322010gwj.11 for ; Mon, 16 Aug 2010 17:49:46 -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=UEJwXSoY2kWrs2nlhk/R4C+51XxCFNwfR4Eo83fBpTM=; b=bLMVONyXNBQCHjISVAlcxuZsXh9nW1RSsbMCT3kUW+OVTEKRJL8gfjUW+X0cuwXpt4 jJLNM272Rjc06dSR0JYx7OLQxVF6NcJE2alJeDRMK+4Zma0YX8xwwsDjZAWisSL+EHJW ednUoEZSSqbJy6bu1K3jRQzd+DeyKoMQUSAUE= 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=woMOeQdO17dzk3VImEFIE/SXq6B3mE8g+jbz09VTA+VMEVAxikWGQ4SqFoXRmt0dVX DctVwrTlFGN41dq9ixI2CowfmGKZZDaoWXMOiTc78LxV6pFgq74iROU4B6BL55pv9Y1l 8BMIAbZpVEPie+AOaghJGbFC9HKtBCVgoE8QI= MIME-Version: 1.0 Received: by 10.231.35.77 with SMTP id o13mr6901680ibd.92.1282006185953; Mon, 16 Aug 2010 17:49:45 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Mon, 16 Aug 2010 17:49:45 -0700 (PDT) In-Reply-To: <20100816190846.GG84641@shinkuro.com> References: <481924813.14103@cnnic.cn> <731A21A7-340B-4B53-9DB2-90DD9004ED51@cisco.com> <20100816190846.GG84641@shinkuro.com> Date: Mon, 16 Aug 2010 20:49:45 -0400 Message-ID: Subject: Re: [dnsext] why provisions fail in alias domain names? From: Phillip Hallam-Baker 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: On Mon, Aug 16, 2010 at 3:08 PM, Andrew Sullivan wrote: > No hat. > > On Mon, Aug 16, 2010 at 02:31:29PM -0400, Phillip Hallam-Baker wrote: >> the second class citizens they are. Applications should translate >> xnames before placing the names in address books or in URLs. Otherwise >> the links are going to break when they are used by a non-capable >> application. > > A few comments about this: > > 1. =A0What does an application that happens to be offline or not really > a network client (think "URL highlighting in a word processor", for > instance) do about this? Same thing it does with every other URL that it is unable to check - accept it as specified. If people are going to put documents online they generally have to perform a link check if the links are to be expected to work. > 2. =A0If you're going to normalize to the canonical name, don't you need > some way of knowing that you've normalized? =A0In the context of the IDN > use case (the only one we've really been exploring), a significant > part of the point is to display in a way that is natural to the user, > even if that isn't the "real" domain name. =A0So now we need a way to go > "back". Well HTML has that issue sorted already. The hyperlink destination is specified by the href attribute of the tag. Any text shown to the user need not correspond to the actual link. We may well have an ongoing requirement for such programs to actually store both forms if they are going to be really be able to work as expected in every case. > 3. =A0If we need a way to go "back", don't we need a way to tell that > there _is_ a "back"? =A0That is, is it necessary to invent the "AKA" > RRTYPE (or something like that) so that in the canonical zone you can > indicate what other names are good and valid pointers to the zone (and > which are "unauthorized")? That might be desirable or it might be necessary. Clearly the more that this is automated, the more that type of link becomes a necessity. > A > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Mon Aug 16 19:40: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 B8A3E3A67EC; Mon, 16 Aug 2010 19:40:58 -0700 (PDT) X-Quarantine-ID: <84CBS5Aa04SM> 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: -96.922 X-Spam-Level: X-Spam-Status: No, score=-96.922 tagged_above=-999 required=5 tests=[AWL=-0.885, 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, 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 84CBS5Aa04SM; Mon, 16 Aug 2010 19:40:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D915B3A67F8; Mon, 16 Aug 2010 19:40:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlC2q-000CZr-VQ for namedroppers-data0@psg.com; Tue, 17 Aug 2010 02:36:56 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlC2o-000CZU-33 for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 02:36:54 +0000 Received: (eyou send program); Tue, 17 Aug 2010 10:36:51 +0800 Message-ID: <482012611.23795@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, 17 Aug 2010 10:36:51 +0800 Message-ID: <8AB441D9217C4D1D8FF492CB001BED80@LENOVO47E041CF> From: "Jiankang YAO" To: "Alex Bligh" Cc: References: <481968231.03365@cnnic.cn> <481975906.17099@cnnic.cn> Subject: Re: [dnsext] application issues for the alias names Date: Tue, 17 Aug 2010 10:37:23 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsZXggQmxpZ2giIDxhbGV4 QGFsZXgub3JnLnVrPg0KVG86ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj47IDxuYW1l ZHJvcHBlcnNAb3BzLmlldGYub3JnPg0KQ2M6ICJBbGV4IEJsaWdoIiA8YWxleEBhbGV4Lm9yZy51 az4NClNlbnQ6IE1vbmRheSwgQXVndXN0IDE2LCAyMDEwIDExOjQ3IFBNDQpTdWJqZWN0OiBSZTog W2Ruc2V4dF0gYXBwbGljYXRpb24gaXNzdWVzIGZvciB0aGUgYWxpYXMgbmFtZXMgDQoNCg0KPiAN Cj4gDQo+IC0tT24gMTYgQXVndXN0IDIwMTAgMjI6MTc6MzkgKzA4MDAgSmlhbmthbmcgWUFPIDx5 YW9qa0Bjbm5pYy5jbj4gd3JvdGU6DQo+IA0KPj4gaWYgdGhlIGZpbmFsIHJlc3VsdHMgYXJlIHNh bWUsIHNvIHRoZSBhcHBsaWNhdGlvbiBjb25maWd1cmF0aW9uIGlzIHNhbWUNCj4+IGZvciBwcm92 aXNpb25hbCB3YXkgYW5kIHhuYW1lIHdheS4NCj4gDQo+IElmIEkgdW5kZXJzdGFuZCB5b3VyIGV4 YW1wbGUsIHlvdSBoYXZlIHNob3duIHRoYXQgaXQgaXMgYWx3YXlzIHBvc3NpYmxlIHRvDQo+IGNv bmZpZ3VyZSAidGhlIHByb3Zpc2lvbmluZyBoYWNrIiB0byBwcm9kdWNlIHRoZSBzYW1lIHJlc3Vs dCBhcyBYTkFNRS4NCj4NCg0Kd2hhdCBpIG1lYW4gaXMgdGhhdCBpZiB0aGVyZSBhcmUgcHJvYmxl bXMgZm9yIHhuYW1lIGluIGFwcGxpY2F0aW9uLCB0aGVyZSBhcmUgYWxzbyBzb21lIHByb2JsZW1z IGZvciBwcm92aXNpb25zIGluIGFwcGxpY2F0b25zLg0KdGhlIGFwcGxpY2F0aW9ucyBpc3N1ZXMg YXJlIGZvciBib3RoIHByb3Zpc2lvbnMgYW5kIHhuYW1lIHdheXMuDQoNCj4NCj4gWW91IGhhdmUg bm90IHNob3duIHRoZSBjb252ZXJzZSAoaS5lLiBob3cgWE5BTUUgY2FuIHByb2R1Y2UgMTkyLjE2 OC4xLjENCj4gZm9yIG9uZSBxdWVyeSBhbmQgMTkyLjE2OC4xLjIgZm9yIHRoZSBvdGhlciwgbGlr ZSAyIEEgcmVjb3JkcyBjYW4pLg0KPiANCg0KeG5hbWUgaXMgdHJ5aW5nIHRvIG1pcnJvciB0aGUg d2hvbGUgdHJlZSwgbm90IGRldmlhdGUgaXQuDQoNCmlmIHdlIHdhbnQgdG8gZGV2aWF0ZSBpdCwg dGhlIGN1cnJlbnQgcHJvdmlzaW9uIGlzIG9rLg0KDQpKaWFua2FuZyBZYW8NCg0KDQoNCg0KDQoN Cj4gLS0gDQo+IEFsZXggQmxpZ2gNCj4= From owner-namedroppers@ops.ietf.org Tue Aug 17 06:29: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 C547C3A6981; Tue, 17 Aug 2010 06:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.011, 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 jopO-zBR1ZFw; Tue, 17 Aug 2010 06:29:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E40813A6971; Tue, 17 Aug 2010 06:29:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlM9Z-000Pim-4X for namedroppers-data0@psg.com; Tue, 17 Aug 2010 13:24:33 +0000 Received: from [131.111.8.130] (helo=ppsw-30.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlM9W-000PiA-L1 for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 13:24:30 +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]:51169) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1OlM9T-00078I-di (Exim 4.72) (return-path ); Tue, 17 Aug 2010 14:24:27 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OlM9T-0006Bs-9P (Exim 4.67) (return-path ); Tue, 17 Aug 2010 14:24:27 +0100 Date: Tue, 17 Aug 2010 14:24:27 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker cc: =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= , YAO Jiankang , namedroppers@ops.ietf.org Subject: Re: [dnsext] why provisions fail in alias domain names? In-Reply-To: Message-ID: References: <481924813.14103@cnnic.cn> <731A21A7-340B-4B53-9DB2-90DD9004ED51@cisco.com> 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 Mon, 16 Aug 2010, Phillip Hallam-Baker wrote: > > If we are not going to have magic fixup in the core of the DNS > protocol then the problem is really very easy. You put pointers in the > DNS for apps that can follow them and place the whole responsibility > for managing this problem where it belongs - at the endpoint. If you do that it'll never be deployable. Tony. -- f.anthony.n.finch http://dotat.at/ ROCKALL: SOUTHWEST BECOMING CYCLONIC, 5 TO 7. MODERATE OR ROUGH. SHOWERS. GOOD. From owner-namedroppers@ops.ietf.org Tue Aug 17 07: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 CCBE73A688F; Tue, 17 Aug 2010 07:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.421 X-Spam-Level: X-Spam-Status: No, score=-98.421 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 aZ8CL1p1jrNd; Tue, 17 Aug 2010 07:30:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F48F3A6979; Tue, 17 Aug 2010 07:30:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlN7L-0008p8-QJ for namedroppers-data0@psg.com; Tue, 17 Aug 2010 14:26:19 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlN7E-0008kz-UC for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 14:26:13 +0000 Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7HEQ3w5038792; Tue, 17 Aug 2010 10:26:03 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Tue, 17 Aug 2010 10:26:09 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 17 Aug 2010 10:26:09 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 17 Aug 2010 10:24:41 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: [dnsext] Problem with Section 2.2 of RFC 4035 Cc: ed.lewis@neustar.biz Content-Type: multipart/alternative; boundary="============_-930067333==_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: --============_-930067333==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" On another list, operators have identified an issue with this passage > "There MUST be an RRSIG for each RRset using at least one DNSKEY of > each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset > itself MUST be signed by each algorithm appearing in the DS RRset > located at the delegating parent (if any)." and being able to "roll an algorithm." The problem is - what if a cache has a copy of a DNSKEY set with algorithms 5 and 7 and it receives a set only signed with algorithm 7? (A longer winded discussion is available here: http://dnssec-deployment.org/pipermail/dnssec-deployment/2010-August/004330.html ) The problem I see is that validators are inappropriately enforcing the first MUST. The MUST was for generation, not for validation. My suggestion is to add text like this around that section (or added to the DNSSECbis document): To clean up the specification, "it should be emphasized that although the signer is supposed to supply one of every signature, the validator only needs one working signature to okay the data." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh. --============_-930067333==_ma============ Content-Type: text/html; charset="us-ascii" Problem with Section 2.2 of RFC 4035
On another list, operators have identified an issue with this passage

>    "There MUST be an RRSIG for each RRset using at least one DNSKEY of
>    each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
>    itself MUST be signed by each algorithm appearing in the DS RRset
>    located at the delegating parent (if any)."

and being able to "roll an algorithm."

The problem is - what if a cache has a copy of a DNSKEY set with algorithms 5 and 7 and it receives a set only signed with algorithm 7?

(A longer winded discussion is available here:
http://dnssec-deployment.org/pipermail/dnssec-deployment/2010-August/004330.html
)

The problem I see is that validators are inappropriately enforcing the first MUST.  The MUST was for generation, not for validation.

My suggestion is to add text like this around that section (or added to the DNSSECbis document):

To clean up the specification, "it should be emphasized that although the signer is supposed to supply one of every signature, the validator only needs
one working signature to okay the data."


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

Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.
--============_-930067333==_ma============-- From owner-namedroppers@ops.ietf.org Tue Aug 17 07:35: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 3F48C3A6926; Tue, 17 Aug 2010 07:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.512 X-Spam-Level: ** X-Spam-Status: No, score=2.512 tagged_above=-999 required=5 tests=[AWL=-1.206, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2CB+DSMV1TR; Tue, 17 Aug 2010 07:35:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC5403A68C6; Tue, 17 Aug 2010 07:35:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlNE5-0009zj-ET for namedroppers-data0@psg.com; Tue, 17 Aug 2010 14:33:17 +0000 Received: from [209.86.89.69] (helo=elasmtp-mealy.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlNE2-0009xx-83 for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 14:33:14 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=P1MTvwXkr9ezjgz7GX74pyH1GOdELeDZX5BLxqpCNCx1MsNR1XMzjzSt/DsyAhLx; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Transfer-Encoding:X-Mailer:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.44] (helo=elwamui-ovcar.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OlNE1-0000R3-CX for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 10:33:13 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Tue, 17 Aug 2010 10:33:13 -0400 Message-ID: <26290332.1282055593370.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> Date: Tue, 17 Aug 2010 09:33:13 -0500 (GMT-05:00) From: "Jeffrey A. Williams" Reply-To: "Jeffrey A. Williams" To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Problem with Section 2.2 of RFC 4035 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 Content-Type: text/html; charset=UTF-8 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606885aea0f400426dee81b708c5f414f031c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.44 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Problem with Section 2.2 of RFC 4035

Ed and all,

 

  I agree with Ed here as well...


-----Original Message-----
From: Edward Lewis
Sent: Aug 17, 2010 9:24 AM
To: namedroppers@ops.ietf.org
Cc: ed.lewis@neustar.biz
Subject: [dnsext] Problem with Section 2.2 of RFC 4035

On another list, operators have identified an issue with this passage

>    "There MUST be an RRSIG for each RRset using at least one DNSKEY of
>    each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
>    itself MUST be signed by each algorithm appearing in the DS RRset
>    located at the delegating parent (if any)."

and being able to "roll an algorithm."

The problem is - what if a cache has a copy of a DNSKEY set with algorithms 5 and 7 and it receives a set only signed with algorithm 7?

(A longer winded discussion is available here:
http://dnssec-deployment.org/pipermail/dnssec-deployment/2010-August/004330.html
)

The problem I see is that validators are inappropriately enforcing the first MUST.  The MUST was for generation, not for validation.

My suggestion is to add text like this around that section (or added to the DNSSECbis document):

To clean up the specification, "it should be emphasized that although the signer is supposed to supply one of every signature, the validator only needs
one working signature to okay the data."


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

Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.
 
Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 294k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com
Phone: 214-244-4827
From owner-namedroppers@ops.ietf.org Tue Aug 17 07:51: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 1466E3A6947; Tue, 17 Aug 2010 07:51:32 -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 Gd79DIdeyWP4; Tue, 17 Aug 2010 07:51:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB4D13A6848; Tue, 17 Aug 2010 07:51:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlNSX-000CNt-Ik for namedroppers-data0@psg.com; Tue, 17 Aug 2010 14:48:13 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlNSR-000CKU-Lb for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 14:48:08 +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.4/8.14.3) with ESMTP id o7HElwLd088287 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 17 Aug 2010 16:47:58 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4C6AA11E.5030008@nlnetlabs.nl> Date: Tue, 17 Aug 2010 16:47:58 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1 MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Problem with Section 2.2 of RFC 4035 References: In-Reply-To: X-Enigmail-Version: 1.1.2 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.5 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 17 Aug 2010 16:47:58 +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 Ed, On 08/17/2010 04:24 PM, Edward Lewis wrote: > The problem is - what if a cache has a copy of a DNSKEY set with > algorithms 5 and 7 and it receives a set only signed with algorithm 7? If the validator does not support algorithm 7, then the validator has to mark that set as bogus. Thus this rollover is a failure - it does not support validators that do not support algorithm 7 - they get a BOGUS outage for a TTL. Therefore during rollover you have to accomodate validators that support one of the algorithms but not the other. Thus distribute data sets signed with both algorithms during the TTL when validators can have both algorithms in the DNSKEY. (Thus a check that signatures 5 and 7 are present is a good thing? Zone-lint tools should do this?) And, no, you cannot require validators to 'fetch data from the authority', because they cannot signal an intermediate cache to do so. (unless you think sending queries to cause cache memory-exhaustion is ok :-) ). (Not sure you claim this, but people may be tempted to use this to 'fix' things). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxqoR4ACgkQkDLqNwOhpPgBWwCcD/Ko1nAVNqZSdQN2U376lBcN 3lcAnjoOelHn3X4WeWWUxpW+SdSQX36p =q3LR -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Tue Aug 17 09:03: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 30CFD3A68DE; Tue, 17 Aug 2010 09:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.727 X-Spam-Level: X-Spam-Status: No, score=-0.727 tagged_above=-999 required=5 tests=[AWL=-0.232, 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 kRQfwZbDwNvA; Tue, 17 Aug 2010 09:03:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C75D43A6ACD; Tue, 17 Aug 2010 09:03:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlOYd-000MFk-MT for namedroppers-data0@psg.com; Tue, 17 Aug 2010 15:58:35 +0000 Received: from [209.85.161.180] (helo=mail-gx0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlOYb-000MFH-E4 for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 15:58:33 +0000 Received: by gxk22 with SMTP id 22so3906820gxk.11 for ; Tue, 17 Aug 2010 08:58:32 -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=CSavkjctz/P4fKVhXzlyNU0ohTWts0HFr1aGOSJxSak=; b=TRmGLWa+TVv1WcCm3Ac+QjDvvttpZa4k+qirUSVEroPNKRuVAqPTB2yWdYFK/9b3wg l1GJOZt8bKX+W8wwt5Wd44i3U7swT9lCbihCh5updiy+r5+6As2canaPeu7lwGbrQVIY dClskAUAmc/DWdgXNB+E27c7hFjvr16ZahK9A= 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=qe0JkvCAX302q656pWJSO4K2x47jy4Y7PF23UHK2qMmb4SWRrqoK2bitCKlB9NqJLe 9CTZncPKjtYcyXyAbLMa2ikzJNca749gv7UcoJ1z6yo2VB+6ac2dmVnnrdspFOTqqDL5 72a1TsAuMnZ6f2QAAVib9iNvB1rG5dou/n4VI= MIME-Version: 1.0 Received: by 10.90.101.14 with SMTP id y14mr4697171agb.64.1282060712519; Tue, 17 Aug 2010 08:58:32 -0700 (PDT) Received: by 10.231.12.77 with HTTP; Tue, 17 Aug 2010 08:58:32 -0700 (PDT) In-Reply-To: References: <481924813.14103@cnnic.cn> <731A21A7-340B-4B53-9DB2-90DD9004ED51@cisco.com> Date: Tue, 17 Aug 2010 11:58:32 -0400 Message-ID: Subject: Re: [dnsext] why provisions fail in alias domain names? From: Phillip Hallam-Baker To: Tony Finch Cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , YAO Jiankang , 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: Quite probably. But you can't deploy in the DNS core without breaking existing applications. And that is both undeployable and unacceptable. I don't see why people who use I18N apps and want I18N domains would not switch to applications that are aware. I think that you are going to get a respectable amount of deployment over a realistic time-frame. Magic pointers are not going to solve this problem for people without upgraded apps, instead they will cause existing apps to be unable to connect to the I18N sites for reasons that are not explainable. 2010/8/17 Tony Finch : > On Mon, 16 Aug 2010, Phillip Hallam-Baker wrote: >> >> If we are not going to have magic fixup in the core of the DNS >> protocol then the problem is really very easy. You put pointers in the >> DNS for apps that can follow them and place the whole responsibility >> for managing this problem where it belongs - at the endpoint. > > If you do that it'll never be deployable. > > Tony. > -- > f.anthony.n.finch =A0 =A0http://dotat.at/ > ROCKALL: SOUTHWEST BECOMING CYCLONIC, 5 TO 7. MODERATE OR ROUGH. SHOWERS. > GOOD. > --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Tue Aug 17 10:56: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 CDF8F3A68BD; Tue, 17 Aug 2010 10:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.938 X-Spam-Level: X-Spam-Status: No, score=-108.938 tagged_above=-999 required=5 tests=[AWL=0.157, 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, 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 XWtT+fF5QY0m; Tue, 17 Aug 2010 10:56:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 64F133A67FB; Tue, 17 Aug 2010 10:56:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlQK8-000BgF-4P for namedroppers-data0@psg.com; Tue, 17 Aug 2010 17:51:44 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlQK5-000Bft-Gg for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 17:51:41 +0000 Received: (qmail 10300 invoked from network); 17 Aug 2010 17:51:39 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 17 Aug 2010 17:51: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=k1008; olt=johnl@user.iecc.com; bh=J1MpsFC/m/n4IR2so1I8VbfAeUOsM4tRD0pvimFbVzQ=; b=K9MgHxyTLn2PSoXZEvtbT+E28Z4ElT/JMoQzYn4jbfbp8q9XATkeTqZIpEJJH/JKaEIWwmisDCrRPJh3a/eK1Z+OIu2l+bjjnHrrOF6Q1UpAEf3rnSBqTyvQ5QYv/VccRkNowj0BlezmV9x2xJBC+LbohCn3uh+hj6BjfMb+QB0= Date: 17 Aug 2010 17:51:39 -0000 Message-ID: <20100817175139.216.qmail@joyce.lan> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: [dnsext] application issues for the alias names In-Reply-To: <482012611.23795@cnnic.cn> Organization: Cc: yaojk@cnnic.cn 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: >what i mean is that if there are problems for xname in application, >there are also some problems for provisions in applicatons. the >applications issues are for both provisions and xname ways. It is certainly possible for people to misconfigure applications, no matter what's in the DNS. Also, again no matter what is in the DNS, there will be application-specific provisioning rules. To use a popular example, if all of the web sites under a domain use HTTP, the alias A records all resolve to the same address, but if some use HTTPS, the alias A records need to resolve to different addresses. Successful i18n will always need some manual or locally scripted provisioning. My position has always been that xNAME does not avoid enough of the manual or scripted work to be worth its cost. R's, John From owner-namedroppers@ops.ietf.org Tue Aug 17 11:14: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 93FB43A6AC6; Tue, 17 Aug 2010 11:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.396 X-Spam-Level: X-Spam-Status: No, score=-98.396 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MANGLED_LOW=2.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 zCHDYcQUuA7V; Tue, 17 Aug 2010 11:13:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A75CD3A69F1; Tue, 17 Aug 2010 11:13:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlQc4-000Egu-CT for namedroppers-data0@psg.com; Tue, 17 Aug 2010 18:10:16 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlQbq-000Eeq-07 for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 18:10:02 +0000 Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7HI9nPV040664; Tue, 17 Aug 2010 14:09:49 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Tue, 17 Aug 2010 14:09:55 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 17 Aug 2010 14:09:55 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4C6AA11E.5030008@nlnetlabs.nl> References: <4C6AA11E.5030008@nlnetlabs.nl> Date: Tue, 17 Aug 2010 14:07:48 -0400 To: "W.C.A. Wijngaards" From: Edward Lewis Subject: Re: [dnsext] Problem with Section 2.2 of RFC 4035 Cc: Edward Lewis , 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: This isn't the same problem. If a validator understands 5, sees 5 and 7 in the DNSKEY set it holds, and then gets a data set signed only with 7, that's an error and rather insurmountable because we don't want to allow a downgrade to succeed. If a validator understands 5 and 7, sees 5 and 7 in the DNSKEY set it holds, and then gets a data set signed only with 7, this is a non-problem unless the validator gets pedantic and demands the 5 signature be there. In the other-list discussion, I used this matrix: >> The cache has:--> old-alg-only both-alg-keys new-alg-only >> The cache gets-v >> Old sig only I II III >> Both sigs IV V VI >> New sig only VII VIII IX That assumed that the validator understood both the old and new algorithm. If the validator only understands the old algorithm, then states II, V, and VIII become the same as I, IV, and VII. The states to avoid are III and VII. So, the first situation above, which matches VIII, folded into VII, yeah, we have to avoid that. Thinking... The best I can come up with now, is that if you only know of the old keys, and the new DNSKEY set shows that there's a new algorithm and it is matching the signature you have, you can reliably deduce that "something is up" in the sense that the authority is changing the zone. Even though you cannot validate the signature, you can validate the expectation that the data is still signed. Remembering the danger is that you could be vulnerable to a downgrade, the potential attacker would have had to add a new algorithm to the DNSKEY set (signed with the algorithm you do know - we call this the both-alg-keys set in the matrix) inorder to pull this off. If the attacker would forge in a new set of keys, they could just as easily forge in a new signature and probably get away with more. (Sorry, I haven't been able to fully think this out.) At 16:47 +0200 8/17/10, W.C.A. Wijngaards wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi Ed, > >On 08/17/2010 04:24 PM, Edward Lewis wrote: >> The problem is - what if a cache has a copy of a DNSKEY set with >> algorithms 5 and 7 and it receives a set only signed with algorithm 7? > >If the validator does not support algorithm 7, then the validator has to >mark that set as bogus. Thus this rollover is a failure - it does not >support validators that do not support algorithm 7 - they get a BOGUS >outage for a TTL. > >Therefore during rollover you have to accomodate validators that support >one of the algorithms but not the other. Thus distribute data sets >signed with both algorithms during the TTL when validators can have both >algorithms in the DNSKEY. (Thus a check that signatures 5 and 7 are >present is a good thing? Zone-lint tools should do this?) > >And, no, you cannot require validators to 'fetch data from the >authority', because they cannot signal an intermediate cache to do so. >(unless you think sending queries to cause cache memory-exhaustion is ok >:-) ). (Not sure you claim this, but people may be tempted to use this >to 'fix' things). > >Best regards, > Wouter >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v2.0.14 (GNU/Linux) >Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > >iEYEARECAAYFAkxqoR4ACgkQkDLqNwOhpPgBWwCcD/Ko1nAVNqZSdQN2U376lBcN >3lcAnjoOelHn3X4WeWWUxpW+SdSQX36p >=q3LR >-----END PGP SIGNATURE----- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh. From owner-namedroppers@ops.ietf.org Tue Aug 17 13:09: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 DD08D3A6869; Tue, 17 Aug 2010 13:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.822 X-Spam-Level: X-Spam-Status: No, score=-99.822 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_15=0.6, 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 noris1Y6k1l9; Tue, 17 Aug 2010 13:09:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6F7C3A6875; Tue, 17 Aug 2010 13:09:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlSOY-0001Oe-Ac for namedroppers-data0@psg.com; Tue, 17 Aug 2010 20:04:26 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlSOV-0001O8-BC for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 20:04:23 +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 10A1F1ECB408 for ; Tue, 17 Aug 2010 20:04:22 +0000 (UTC) Date: Tue, 17 Aug 2010 16:04:20 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? Message-ID: <20100817200420.GC89703@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, We've spilled a lot of 1s and 0s over the question of whether xNAME will solve enough of the aliasing issues to be worth the cost to the protocol. I still don't know where the community is heading on that, but it appears there are people who feel quite strongly (and with good arguments) that it is _not_ worth the cost. This question is explicitly addressed to those participants. If you think that some xNAME strategy is too costly for its advantages, it would be excellent if, in this thread, you stated your reasons for thinking that the SHADOW approach is or is not worth adopting. Just as with the details of (say) BNAME vs. C+DNAME, the particular details of SHADOW are not too important just now. The main thrust is "some provisioning metadata/hints in-protocol and in-zone". Thanks, A (as co-chair, and still hoping to drive to some consensus on what the charter will be.) -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Aug 17 14:13: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 038363A6817; Tue, 17 Aug 2010 14:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.306 X-Spam-Level: X-Spam-Status: No, score=-100.306 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 TPhWjFgt87A1; Tue, 17 Aug 2010 14:13:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E86B73A67EF; Tue, 17 Aug 2010 14:13:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlTP7-0009HQ-BH for namedroppers-data0@psg.com; Tue, 17 Aug 2010 21:09:05 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlTP4-0009H0-SC for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 21:09:02 +0000 Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7HL8pEO041337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Aug 2010 14:08:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 17 Aug 2010 14:08:50 -0700 To: namedroppers@ops.ietf.org, tls@ietf.org From: Paul Hoffman Subject: [dnsext] Of interest to this 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 11:36 AM -0700 8/17/10, IETF Secretariat wrote: >From: IETF Secretariat >To: IETF Announcement list >Subject: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC >Date: Tue, 17 Aug 2010 11:36:02 -0700 (PDT) > >A new IETF non-working group email list has been created. > >List address: keyassure@ietf.org >Archive: >http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html >To subscribe: https://www.ietf.org/mailman/listinfo/keyassure > >Description: This list is for discussion relating to using >DNSSEC-protected DNS queries to get greater assurance for keys and >certificates that are passed in existing IETF protocols. The main idea is >that a relying party can get additional information about a domain name to >eliminate the need for using a certificate in a protocol, to eliminate the >need for sending certificates in the protocol if they are optional, and/or >to assure that the certificate given in a protocol is associated with the >domain name used by the application. In all three cases, the >application associates the key or key fingerprint securely retrieved from >the DNS with the domain name that was used in the DNS query. From owner-namedroppers@ops.ietf.org Tue Aug 17 14:13: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 26ACE3A6869; Tue, 17 Aug 2010 14:13:59 -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 D7u+Px2HPLvO; Tue, 17 Aug 2010 14:13:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9CBCB3A6817; Tue, 17 Aug 2010 14:13:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlTS3-0009cf-19 for namedroppers-data0@psg.com; Tue, 17 Aug 2010 21:12:07 +0000 Received: from [2a02:760:1002:15::14] (helo=mail.kirei.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlTRz-0009cJ-Nw for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 21:12:03 +0000 From: Jakob Schlyter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [dnsext] FYI: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC Date: Tue, 17 Aug 2010 23:11:59 +0200 References: <20100817183602.CF0433A6807@core3.amsl.com> To: namedroppers WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 forwarded message: > From: IETF Secretariat > Date: 17 augusti 2010 20.36.02 CEST > To: IETF Announcement list > Cc: ondrej.sury@nic.cz, keyassure@ietf.org > Subject: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC > > A new IETF non-working group email list has been created. > > List address: keyassure@ietf.org > Archive: > http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html > To subscribe: https://www.ietf.org/mailman/listinfo/keyassure > > Description: This list is for discussion relating to using > DNSSEC-protected DNS queries to get greater assurance for keys and > certificates that are passed in existing IETF protocols. The main idea is > that a relying party can get additional information about a domain name to > eliminate the need for using a certificate in a protocol, to eliminate the > need for sending certificates in the protocol if they are optional, and/or > to assure that the certificate given in a protocol is associated with the > domain name used by the application. In all three cases, the > application associates the key or key fingerprint securely retrieved from > the DNS with the domain name that was used in the DNS query. > > For additional information, please contact the list administrators. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From owner-namedroppers@ops.ietf.org Tue Aug 17 14:37: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 692093A685C; Tue, 17 Aug 2010 14:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.125 X-Spam-Level: X-Spam-Status: No, score=-100.125 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 ECPwZs4d9OCg; Tue, 17 Aug 2010 14:37:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 57A0D3A684B; Tue, 17 Aug 2010 14:37:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlTnW-000CEU-Io for namedroppers-data0@psg.com; Tue, 17 Aug 2010 21:34:18 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlTnT-000CDJ-Kk for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 21:34:15 +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 B94461ECB408 for ; Tue, 17 Aug 2010 21:34:12 +0000 (UTC) Date: Tue, 17 Aug 2010 17:34:11 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? Message-ID: <20100817213410.GN89703@shinkuro.com> References: <20100817200420.GC89703@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100817200420.GC89703@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: On Tue, Aug 17, 2010 at 04:04:20PM -0400, Andrew Sullivan wrote: > thinking that the SHADOW approach is or is not worth adopting. Just Paul Hoffman helpfully nudged me to provide the reference. Here we are: http://tools.ietf.org/html/draft-vixie-dnsext-dnsshadow-00 A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Aug 17 14:44: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 D7B013A6838; Tue, 17 Aug 2010 14:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.49 X-Spam-Level: X-Spam-Status: No, score=0.49 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=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 jDGdkSYczzMZ; Tue, 17 Aug 2010 14:44:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D84DB3A67F3; Tue, 17 Aug 2010 14:44:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlTvM-000DSh-5r for namedroppers-data0@psg.com; Tue, 17 Aug 2010 21:42:24 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlTvJ-000DRF-4c for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 21:42:21 +0000 Received: from [192.168.1.68] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 88B4CC56931; Tue, 17 Aug 2010 22:42:19 +0100 (BST) Date: Tue, 17 Aug 2010 22:42:18 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Andrew Sullivan , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? Message-ID: In-Reply-To: <20100817200420.GC89703@shinkuro.com> References: <20100817200420.GC89703@shinkuro.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 17 August 2010 16:04:20 -0400 Andrew Sullivan wrote: > We've spilled a lot of 1s and 0s over the question of whether xNAME > will solve enough of the aliasing issues to be worth the cost to the > protocol. I still don't know where the community is heading on that, > but it appears there are people who feel quite strongly (and with good > arguments) that it is _not_ worth the cost. > > This question is explicitly addressed to those participants. If you > think that some xNAME strategy is too costly for its advantages, it > would be excellent if, in this thread, you stated your reasons for > thinking that the SHADOW approach is or is not worth adopting. Just > as with the details of (say) BNAME vs. C+DNAME, the particular details > of SHADOW are not too important just now. The main thrust is "some > provisioning metadata/hints in-protocol and in-zone". I fall into this group. Without wishing to be irritating, I'm not sufficiently certain what you mean by SHADOW to answer your question (perhaps Message-IDs would help). If by "hints in protocol" you mean an RR that says "hey you should be looking over here" that requires application support, I think that will require too much application layer change. My current view is that viable ways forward are: * dumb provisioning hack (copy zones) * automated provisioning hack (so for instance a zonefile format pre-signature a bit like a patch) * XNAME+exceptions (I'm far from convinced this works, but it hasn't yet been run to ground). By this I mean a sort of "default value" for a zonefile. -- Alex Bligh From owner-namedroppers@ops.ietf.org Tue Aug 17 14:52: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 0E5DA3A67F3; Tue, 17 Aug 2010 14:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.174 X-Spam-Level: X-Spam-Status: No, score=0.174 tagged_above=-999 required=5 tests=[AWL=0.669, 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 hpuHLGBXvdww; Tue, 17 Aug 2010 14:52:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C61F3A6869; Tue, 17 Aug 2010 14:52:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlU2J-000EZ4-4E for namedroppers-data0@psg.com; Tue, 17 Aug 2010 21:49:35 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlU2E-000EYK-JV for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 21:49:31 +0000 Received: from [192.168.1.68] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 33B89C5694D; Tue, 17 Aug 2010 22:49:28 +0100 (BST) Date: Tue, 17 Aug 2010 22:49:27 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Andrew Sullivan , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? Message-ID: <9BE1E5EDF1364B050B61136E@nimrod.local> In-Reply-To: <20100817213410.GN89703@shinkuro.com> References: <20100817200420.GC89703@shinkuro.com> <20100817213410.GN89703@shinkuro.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 17 August 2010 17:34:11 -0400 Andrew Sullivan wrote: > Paul Hoffman helpfully nudged me to provide the reference. Here we are: > > http://tools.ietf.org/html/draft-vixie-dnsext-dnsshadow-00 That would have been useful 10 seconds earlier :-) I this approach is worth further investigation (hadn't seen it before) -- Alex Bligh From owner-namedroppers@ops.ietf.org Tue Aug 17 14:54: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 406A83A67F3; Tue, 17 Aug 2010 14:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.918 X-Spam-Level: X-Spam-Status: No, score=-104.918 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_15=0.6, 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 hImbk5Ej6uWz; Tue, 17 Aug 2010 14:54:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 39E3A3A66B4; Tue, 17 Aug 2010 14:54:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlU4u-000Eyn-Al for namedroppers-data0@psg.com; Tue, 17 Aug 2010 21:52:16 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlU4r-000Ex7-Ag for namedroppers@ops.ietf.org; Tue, 17 Aug 2010 21:52:13 +0000 Received: from sjc-office-nat-210.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id C54F2A945E2; Tue, 17 Aug 2010 21:52:11 +0000 (UTC) Message-ID: <4C6B048B.8070005@mail-abuse.org> Date: Tue, 17 Aug 2010 14:52:11 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? References: <20100817200420.GC89703@shinkuro.com> In-Reply-To: <20100817200420.GC89703@shinkuro.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 8/17/10 1:04 PM, Andrew Sullivan wrote: > Dear colleagues, > > We've spilled a lot of 1s and 0s over the question of whether xNAME > will solve enough of the aliasing issues to be worth the cost to the > protocol. I still don't know where the community is heading on that, > but it appears there are people who feel quite strongly (and with good > arguments) that it is _not_ worth the cost. > > This question is explicitly addressed to those participants. If you > think that some xNAME strategy is too costly for its advantages, it > would be excellent if, in this thread, you stated your reasons for > thinking that the SHADOW approach is or is not worth adopting. Just > as with the details of (say) BNAME vs. C+DNAME, the particular details > of SHADOW are not too important just now. The main thrust is "some > provisioning metadata/hints in-protocol and in-zone". If the BNAME extension is not adopted, the SHADOW approach standardizes how IDN related issues might be solved at the registered domain, and impact a smaller number of servers. It might be hard to arrive at a general consensus for either SHADOW or BNAME, with the IDN problem not being universally experienced. With respect to BNAME, versus C+DNAME, BNAME provides a resource paradigm, which should offer less uncertainty in how cached data is to be handled. It would be nice if neither alias scheme were needed, but without the full alias feature, IDN domain names will be less user friendly. Many domains already use aliases with CDN services, and this has not resulted in dire issues. Warnings should be included in the BNAME draft regarding use of aliased targets in MX, SRV and PTR records. -Doug From owner-namedroppers@ops.ietf.org Wed Aug 18 00:58: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 00F1E3A6A2D; Wed, 18 Aug 2010 00:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.357 X-Spam-Level: * X-Spam-Status: No, score=1.357 tagged_above=-999 required=5 tests=[AWL=-0.893, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, MANGLED_LOW=2.3, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OES9ELssqzIZ; Wed, 18 Aug 2010 00:58:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A9713A6A28; Wed, 18 Aug 2010 00:58:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OldSo-000MZ8-Qh for namedroppers-data0@psg.com; Wed, 18 Aug 2010 07:53:34 +0000 Received: from [85.17.178.138] (helo=rotring.dds.nl) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OldSl-000MYa-S5 for namedroppers@ops.ietf.org; Wed, 18 Aug 2010 07:53:32 +0000 Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id C83BC58208; Wed, 18 Aug 2010 09:53:29 +0200 (CEST) Received: from vylkir.localdomain (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id E480857E79; Wed, 18 Aug 2010 09:53:14 +0200 (CEST) Message-ID: <4C6B916A.7080507@nlnetlabs.nl> Date: Wed, 18 Aug 2010 09:53:14 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1 MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Problem with Section 2.2 of RFC 4035 References: <4C6AA11E.5030008@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.1 at rotring X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Ed, I do not see how 'fixing this' gains us something. If somehow the resolvers that understand both 5 and 7 act differently, how does that help with rollover? You must accommodate the resolvers that understand 5, not 7. (and the ones that understand 7 not 5). I understand that possibly, we can be more lenient in checking signatures, in the case where you understand both algorithms and one is missing. But that situation should not happen because it breaks all the resolvers that understand only one and that one is missing? It can therefore certainly not be the 'recommended' rollover method. Your map of cases assumes the target understands both algorithms, and I am with you and I see it could be made more lenient. But it is that same map for resolvers that support one algorithm that is the issue. And if you accommodate those other maps, I think that the case where you understand both could just as well validate both signatures (and be 'pedantic' :-) but the pedantry does tell you that you are botching the rollover ). Best regards, Wouter On 08/17/2010 08:07 PM, Edward Lewis wrote: > This isn't the same problem. > > If a validator understands 5, sees 5 and 7 in the DNSKEY set it holds, > and then gets a data set signed only with 7, that's an error and rather > insurmountable because we don't want to allow a downgrade to succeed. > > If a validator understands 5 and 7, sees 5 and 7 in the DNSKEY set it > holds, and then gets a data set signed only with 7, this is a > non-problem unless the validator gets pedantic and demands the 5 > signature be there. > > In the other-list discussion, I used this matrix: > >>> The cache has:--> old-alg-only both-alg-keys >>> new-alg-only >>> The cache gets-v >>> Old sig only I II III >>> Both sigs IV V VI >>> New sig only VII VIII IX > > That assumed that the validator understood both the old and new algorithm. > If the validator only understands the old algorithm, then states II, V, and > VIII become the same as I, IV, and VII. > > The states to avoid are III and VII. So, the first situation above, > which matches VIII, folded into VII, yeah, we have to avoid that. > > Thinking... > > The best I can come up with now, is that if you only know of the old > keys, and the new DNSKEY set shows that there's a new algorithm and it > is matching the signature you have, you can reliably deduce that > "something is up" in the sense that the authority is changing the zone. > Even though you cannot validate the signature, you can validate the > expectation that the data is still signed. > > Remembering the danger is that you could be vulnerable to a downgrade, > the potential attacker would have had to add a new algorithm to the > DNSKEY set (signed with the algorithm you do know - we call this the > both-alg-keys set in the matrix) inorder to pull this off. If the > attacker would forge in a new set of keys, they could just as easily > forge in a new signature and probably get away with more. > > (Sorry, I haven't been able to fully think this out.) > > At 16:47 +0200 8/17/10, W.C.A. Wijngaards wrote: > Hi Ed, > > On 08/17/2010 04:24 PM, Edward Lewis wrote: >>>> The problem is - what if a cache has a copy of a DNSKEY set with >>>> algorithms 5 and 7 and it receives a set only signed with algorithm 7? > > If the validator does not support algorithm 7, then the validator has to > mark that set as bogus. Thus this rollover is a failure - it does not > support validators that do not support algorithm 7 - they get a BOGUS > outage for a TTL. > > Therefore during rollover you have to accomodate validators that support > one of the algorithms but not the other. Thus distribute data sets > signed with both algorithms during the TTL when validators can have both > algorithms in the DNSKEY. (Thus a check that signatures 5 and 7 are > present is a good thing? Zone-lint tools should do this?) > > And, no, you cannot require validators to 'fetch data from the > authority', because they cannot signal an intermediate cache to do so. > (unless you think sending queries to cause cache memory-exhaustion is ok > :-) ). (Not sure you claim this, but people may be tempted to use this > to 'fix' things). > > Best regards, > Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxrkWkACgkQkDLqNwOhpPifLgCdFZobWQj2pttQX3ZutTKEuuGv GVAAoJQHLD/OmwUgSM7tyFR6s2XE3K4W =qNqd -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Wed Aug 18 03:34: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 21AB53A6927; Wed, 18 Aug 2010 03:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.010, 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 vfpLwEUSC+H7; Wed, 18 Aug 2010 03:34:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 851793A68F8; Wed, 18 Aug 2010 03:34:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlfuI-000FDl-LG for namedroppers-data0@psg.com; Wed, 18 Aug 2010 10:30:06 +0000 Received: from [131.111.8.133] (helo=ppsw-33.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlfuG-000FDL-3R for namedroppers@ops.ietf.org; Wed, 18 Aug 2010 10:30:04 +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]:44459) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1OlfuC-0002C3-g4 (Exim 4.72) (return-path ); Wed, 18 Aug 2010 11:30:00 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OlfuC-0006un-0q (Exim 4.67) (return-path ); Wed, 18 Aug 2010 11:30:00 +0100 Date: Wed, 18 Aug 2010 11:30:00 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker cc: =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= , YAO Jiankang , namedroppers@ops.ietf.org Subject: Re: [dnsext] why provisions fail in alias domain names? In-Reply-To: Message-ID: References: <481924813.14103@cnnic.cn> <731A21A7-340B-4B53-9DB2-90DD9004ED51@cisco.com> 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 Tue, 17 Aug 2010, Phillip Hallam-Baker wrote: > > But you can't deploy in the DNS core without breaking existing > applications. And that is both undeployable and unacceptable. The BNAME proposal (like DNAME) synthesizes CNAMEs for backwards compatibility with existing code. Configuration for each new name is still required in each application server. What you propose requires new code for every application client, which is MUCH more difficult than a server-side configuration tweak. > I don't see why people who use I18N apps and want I18N domains would > not switch to applications that are aware. I think that you are going > to get a respectable amount of deployment over a realistic time-frame. That's a reasonable counter-argument :-) Tony. -- f.anthony.n.finch http://dotat.at/ SOUTH UTSIRE: NORTHEASTERLY 5 TO 7, PERHAPS GALE 8 LATER. SLIGHT OR MODERATE, OCCASIONALLY ROUGH IN SOUTH. OCCASIONAL RAIN. GOOD, OCCASIONALLY POOR. From owner-namedroppers@ops.ietf.org Wed Aug 18 05:58: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 0C3A83A6955; Wed, 18 Aug 2010 05:58:31 -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: -98.218 X-Spam-Level: X-Spam-Status: No, score=-98.218 tagged_above=-999 required=5 tests=[AWL=0.233, 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, 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 KyJVZ+qH-u2x; Wed, 18 Aug 2010 05:58:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A37313A6934; Wed, 18 Aug 2010 05:58:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oli8w-0006QZ-Ua for namedroppers-data0@psg.com; Wed, 18 Aug 2010 12:53:22 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oli8t-0006Q5-UD for namedroppers@ops.ietf.org; Wed, 18 Aug 2010 12:53:20 +0000 Received: (eyou send program); Wed, 18 Aug 2010 20:53:17 +0800 Message-ID: <482135997.19355@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO abc) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 18 Aug 2010 20:53:17 +0800 Message-ID: <5BB7B3E13394403C96655331C815D10A@abc> From: "Yao Jiankang" To: "Tony Finch" , "Phillip Hallam-Baker" Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , References: <481924813.14103@cnnic.cn> <731A21A7-340B-4B53-9DB2-90DD9004ED51@cisco.com> <482128449.09377@cnnic.cn> Subject: Re: [dnsext] why provisions fail in alias domain names? Date: Wed, 18 Aug 2010 20:53:08 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlRvbnkgRmluY2giIDxkb3RA ZG90YXQuYXQ+DQpUbzogIlBoaWxsaXAgSGFsbGFtLUJha2VyIiA8aGFsbGFtQGdtYWlsLmNvbT4N CkNjOiAiUGF0cmlrIEbkbHRzdHL2bSIgPHBhZkBjaXNjby5jb20+OyAiWUFPIEppYW5rYW5nIiA8 eWFvamtAY25uaWMuY24+OyA8bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZz4NClNlbnQ6IFdlZG5l c2RheSwgQXVndXN0IDE4LCAyMDEwIDY6MzAgUE0NClN1YmplY3Q6IFJlOiBbZG5zZXh0XSB3aHkg cHJvdmlzaW9ucyBmYWlsIGluIGFsaWFzIGRvbWFpbiBuYW1lcz8NCg0KDQo+IE9uIFR1ZSwgMTcg QXVnIDIwMTAsIFBoaWxsaXAgSGFsbGFtLUJha2VyIHdyb3RlOg0KPj4NCj4+IEJ1dCB5b3UgY2Fu J3QgZGVwbG95IGluIHRoZSBETlMgY29yZSB3aXRob3V0IGJyZWFraW5nIGV4aXN0aW5nDQo+PiBh cHBsaWNhdGlvbnMuIEFuZCB0aGF0IGlzIGJvdGggdW5kZXBsb3lhYmxlIGFuZCB1bmFjY2VwdGFi bGUuDQo+IA0KPiBUaGUgQk5BTUUgcHJvcG9zYWwgKGxpa2UgRE5BTUUpIHN5bnRoZXNpemVzIENO QU1FcyBmb3IgYmFja3dhcmRzDQo+IGNvbXBhdGliaWxpdHkgd2l0aCBleGlzdGluZyBjb2RlLiBD b25maWd1cmF0aW9uIGZvciBlYWNoIG5ldyBuYW1lIGlzDQo+IHN0aWxsIHJlcXVpcmVkIGluIGVh Y2ggYXBwbGljYXRpb24gc2VydmVyLiBXaGF0IHlvdSBwcm9wb3NlIHJlcXVpcmVzIG5ldw0KPiBj b2RlIGZvciBldmVyeSBhcHBsaWNhdGlvbiBjbGllbnQsIHdoaWNoIGlzIE1VQ0ggbW9yZSBkaWZm aWN1bHQgdGhhbiBhDQo+IHNlcnZlci1zaWRlIGNvbmZpZ3VyYXRpb24gdHdlYWsuDQo+IA0KDQp3 aGF0IGRvIHlvdSBtZWFuIGZvciAiIFdoYXQgeW91IHByb3Bvc2UgcmVxdWlyZXMgbmV3DQpjb2Rl IGZvciBldmVyeSBhcHBsaWNhdGlvbiBjbGllbnQiPw0KDQpkb2VzIHlvdXIgYXBwbGljYXRpb24g Y2xpZW50IHJlZmVyIHRvIHRoZSBhcHBsaWNhaW9ucyBzdWNoIGFzIElFIGJyb3dzZXIgb3IgZmly ZWZveCBicm93c2VyPw0KZG8geW91IG1lYW4gdGhhdCB0aGUgSUUgYnJvd3NlciBvciBmaXJlZm94 IGJyb3dzZXIgaGFzIHRvIGNoYW5nZSBpdHMgcnVubmluZyBjb2RlIHRvIHN1cHBvcnQgYm5hbWU/ DQoNCm15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBvbmx5IHNlcnZlciBjb25maWd1cmF0aW9uIGlz IG5lZWRlZCB0byBzdXBwb3J0IGJuYW1lLg0KDQp0aGUgYXBwbGljYXRpb24gY2xpZW50IHN1Y2gg YXMgdGhlIElFIGJyb3dzZXIgb3IgZmlyZWZveCBicm93c2VyIGRvZXMgbm90IG5lZWQgdXBkYXRp bmcuDQoNCmZvciBleGFtcGxlLCBpZiBnb29nbGUuY29tIGFuZCBhbmQgZ29vZ2xlLmV4YW1wbGUg YXJlIGNvbmZpZ3VyZSB0byB0aGUgc2FtZSBJUCBhZGRyZXNzLg0KDQp0aGUgSUUgYnJvd3NlciBv ciBmaXJlZm94IGJyb3dzZXIganVzdCBmb2xsb3cgdGhlIHNhbWUgSVAgYWRkcmVzcyB0byBjb25u ZWN0IHRoZSB3ZWJzaXRlLg0KdGhlIGdvb2dsZSB3ZWJzaXRlIGFkbWluaXN0cmF0b3IgbWF5IGRv IHNvbWUgY29uZmlndXJhdGlvbiBmb3IgdGhlaXIgaHR0cCBzZXJ2ZXJzLg0KdGhlIGFwcGxpY2F0 aW9uIHNlcnZlciBjb25maWd1cmF0aW9uIGlzIHRyYW5zcGFyZW50IHRvIHRoZSBhcHBsaWNhdGlv biBjbGllbnQuDQoNCkJUVywgYWxsIHRoZSBtYWpvciBicm93c2VycyBoYXZlIGFsbCBhbHJlYWR5 IHN1cHBvcnRlZCBJRE4uDQp3aGV0aGVyIHRoZSBicm93c2VyIHN1cHBvcnQgSUROIG9yIG5vdCBp cyBub3QgYm5hbWUgaXNzdWUsIGJ1dCBJRE4gaXNzdWUuDQoNCg0KSmlhbmthbmcgWWFvDQoNCg0K DQo+DQo+PiBJIGRvbid0IHNlZSB3aHkgcGVvcGxlIHdobyB1c2UgSTE4TiBhcHBzIGFuZCB3YW50 IEkxOE4gZG9tYWlucyB3b3VsZA0KPj4gbm90IHN3aXRjaCB0byBhcHBsaWNhdGlvbnMgdGhhdCBh cmUgYXdhcmUuIEkgdGhpbmsgdGhhdCB5b3UgYXJlIGdvaW5nDQo+PiB0byBnZXQgYSByZXNwZWN0 YWJsZSBhbW91bnQgb2YgZGVwbG95bWVudCBvdmVyIGEgcmVhbGlzdGljIHRpbWUtZnJhbWUuDQo+ IA0KPiBUaGF0J3MgYSByZWFzb25hYmxlIGNvdW50ZXItYXJndW1lbnQgOi0pDQo+IA0KPiBUb255 Lg0KPiAtLSANCj4gZi5hbnRob255Lm4uZmluY2ggIDxkb3RAZG90YXQuYXQ+ICBodHRwOi8vZG90 YXQuYXQvDQo+IFNPVVRIIFVUU0lSRTogTk9SVEhFQVNURVJMWSA1IFRPIDcsIFBFUkhBUFMgR0FM RSA4IExBVEVSLiBTTElHSFQgT1IgTU9ERVJBVEUsDQo+IE9DQ0FTSU9OQUxMWSBST1VHSCBJTiBT T1VUSC4gT0NDQVNJT05BTCBSQUlOLiBHT09ELCBPQ0NBU0lPTkFMTFkgUE9PUi4NCj4gDQo+ From owner-namedroppers@ops.ietf.org Wed Aug 18 06:04: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 A5F093A68A0; Wed, 18 Aug 2010 06:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.935 X-Spam-Level: X-Spam-Status: No, score=-100.935 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=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 tJti3EZ6ydLo; Wed, 18 Aug 2010 06:04:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 77E913A6965; Wed, 18 Aug 2010 06:04:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OliHc-0007hW-Hk for namedroppers-data0@psg.com; Wed, 18 Aug 2010 13:02:20 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OliHa-0007h5-1m for namedroppers@ops.ietf.org; Wed, 18 Aug 2010 13:02:18 +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 B5E037343A1; Wed, 18 Aug 2010 15:02:15 +0200 (CEST) Message-ID: <4C6BD9D7.2010303@nic.cz> Date: Wed, 18 Aug 2010 15:02:15 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Mark Andrews CC: Florian Weimer , Paul Vixie , namedroppers@ops.ietf.org Subject: C+others (Was: [dnsext] C+D vs. B) References: <26902.1281722868@nsa.vix.com> <20100816012048.7E40F2ED101@drugs.dv.isc.org><828w47m2gc.fsf@mid.bfk.de> <20100816143856.B32A230692C@drugs.dv.isc.org> In-Reply-To: <20100816143856.B32A230692C@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.8.2010 16:38, Mark Andrews wrote: > In message<828w47m2gc.fsf@mid.bfk.de>, Florian Weimer writes: >> * Mark Andrews: >> >>>> when we talk about C+D we're really talking about C+D+other, where "othe= >> r" >>>> is all the things that DNAME can presently coexist with. which means, w= >> hen >>>> we talk about C+D we're really talking about C+anything.=20=20 >>> >>> C+D mean C+D or D+other but not C+D+other (excluding DNSSEC). >> >> I think this means you have to create all your aliases in their >> respective parent zones. Is this desirable? Personally I don't see that as a big problem. But I speak with just .CZ registry hat on. > C+D is a delegation alternative. > B is a delegation alternative. > > B is not allowed at a apex (or where there is other data) as it > acts like C. > > C+D+SOA+NS would allow for the child to add C+D at the apex but that > isn't part of the current C+D proposal. So... can we have B+SOA+NS (and +DNSKEY+NSEC+RRSIG)? That would be less controversial than adding support for C+SOA+NS. On the other hand - maybe separate C+NS+SOA would be great to have as well (not only because you can see that in the wild). Allowing C+D is just an added bonus. O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Wed Aug 18 06:52: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 071393A6956; Wed, 18 Aug 2010 06:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kO1s80Jq1k6o; Wed, 18 Aug 2010 06:52:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7ED143A6954; Wed, 18 Aug 2010 06:52:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Olj0j-000Dcw-ET for namedroppers-data0@psg.com; Wed, 18 Aug 2010 13:48:57 +0000 Received: from [131.111.8.130] (helo=ppsw-30.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Olj0g-000Dca-L7 for namedroppers@ops.ietf.org; Wed, 18 Aug 2010 13:48:54 +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]:36670) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:cet1) id 1Olj0f-0004l7-e1 (Exim 4.72) (return-path ); Wed, 18 Aug 2010 14:48:53 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1Olj0f-0001Tp-CX (Exim 4.67) (return-path ); Wed, 18 Aug 2010 14:48:53 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.3); 18 Aug 2010 14:48:53 +0100 Date: 18 Aug 2010 14:48:53 +0100 From: Chris Thompson To: namedroppers@ops.ietf.org Cc: Edward Lewis Reply-To: cet1@cam.ac.uk Subject: Re: [dnsext] Problem with Section 2.2 of RFC 4035 Message-ID: In-Reply-To: References: X-Mailer: Prayer v1.3.3 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 Aug 17 2010, Edward Lewis wrote: >On another list, operators have identified an issue with this passage > >> "There MUST be an RRSIG for each RRset using at least one DNSKEY of >> each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset >> itself MUST be signed by each algorithm appearing in the DS RRset >> located at the delegating parent (if any)." > >and being able to "roll an algorithm." > >The problem is - what if a cache has a copy of a DNSKEY set with >algorithms 5 and 7 and it receives a set only signed with algorithm 7? > >(A longer winded discussion is available here: >http://dnssec-deployment.org/pipermail/dnssec-deployment/2010-August/004330.html >) > >The problem I see is that validators are inappropriately enforcing >the first MUST. The MUST was for generation, not for validation. > >My suggestion is to add text like this around that section (or added >to the DNSSECbis document): > >To clean up the specification, "it should be emphasized that although >the signer is supposed to supply one of every signature, the >validator only needs >one working signature to okay the data." This seems to completely nullify the protection against the downgrade attack that the 4035/2.2 text was meant to provide. (Or else I misunderstsnd what that was.) A validator can never be sure it has all the RRSIGs signing an RRset, because the this set is not itself signed. A MitM can selectively remove RRSIGs to taste. If he can get away with removing all RRSIGs for a stronger algorithm, he can force the validator to rely on the weaker one. If he has also cracked the weaker algorithm, he can start feeding the validator fake responses. This doesn't depend in any way on the validator only understanding one of the algorithms. The conceptual mismatch here is that 4035/2.2 is assuming long-term signing with more than one algorithm. When doing a prophylactic algorithm rollover, one usually isn't worried about downgrade attacks of this sort, because you assume that the old algorithm isn't broken *yet*, and won't be before the rollover is completed. -- 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 Aug 18 07:03: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 D99CC3A6956; Wed, 18 Aug 2010 07:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.29 X-Spam-Level: X-Spam-Status: No, score=-101.29 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, J_CHICKENPOX_23=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 fPEMBErYlloA; Wed, 18 Aug 2010 07:03:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5326A3A6919; Wed, 18 Aug 2010 07:03:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OljBl-000Fc4-QO for namedroppers-data0@psg.com; Wed, 18 Aug 2010 14:00:21 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OljBi-000FbX-PM for namedroppers@ops.ietf.org; Wed, 18 Aug 2010 14:00:19 +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 A7F337343AA for ; Wed, 18 Aug 2010 16:00:17 +0200 (CEST) Message-ID: <4C6BE771.4010406@nic.cz> Date: Wed, 18 Aug 2010 16:00:17 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "namedroppers@ops.ietf.org" Subject: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-at-apex-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 have pursued Mark's idea about having CNAME to live peacefully with SOA and NS. I left out DNAME out on purpose to not turn the discussion around aliasing. This is purely meant as an improvement on the existing CNAME record. And extending this proposal with DNAME is just a added bonus we can get if we can agree on this proposal. Ondrej -------- Original Message -------- Subject: New Version Notification for draft-sury-dnsext-cname-at-apex-00 Date: Wed, 18 Aug 2010 06:56:15 -0700 (PDT) From: IETF I-D Submission Tool To: ondrej.sury@nic.cz A new version of I-D, draft-sury-dnsext-cname-at-apex-00.txt has been successfully submitted by Ondrej Sury and posted to the IETF repository. Filename: draft-sury-dnsext-cname-at-apex Revision: 00 Title: CNAME at the zone apex Creation_date: 2010-08-18 WG ID: Independent Submission Number_of_pages: 6 Abstract: This document proposes a modification to CNAME record to coexist with SOA and NS records at the zone apex. This proposal will improve aliasing in the DNS system. The users are often forced to manually add duplicate A, AAAA and MX records by copying data from the target zone to the aliased zone. This forces zone owner to keep track of target domain name since the mismatch in the data could cause failures. This administrative burden will be eliminated by allowing CNAME to coexist with NS and SOA resource records. The IETF Secretariat. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 Wed Aug 18 08:53: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 698923A6942; Wed, 18 Aug 2010 08:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.010, 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 jNcwU05BKzD0; Wed, 18 Aug 2010 08:53:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA3F63A6848; Wed, 18 Aug 2010 08:53:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlkrZ-0004K0-CZ for namedroppers-data0@psg.com; Wed, 18 Aug 2010 15:47:37 +0000 Received: from [131.111.8.132] (helo=ppsw-32.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlkrW-0004IM-ED for namedroppers@ops.ietf.org; Wed, 18 Aug 2010 15:47:34 +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]:39486) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1OlkrS-0001aL-0q (Exim 4.72) (return-path ); Wed, 18 Aug 2010 16:47:30 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OlkrS-0002g2-7x (Exim 4.67) (return-path ); Wed, 18 Aug 2010 16:47:30 +0100 Date: Wed, 18 Aug 2010 16:47:30 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Yao Jiankang cc: Phillip Hallam-Baker , =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] why provisions fail in alias domain names? In-Reply-To: <482135997.19355@cnnic.cn> Message-ID: References: <481924813.14103@cnnic.cn> <731A21A7-340B-4B53-9DB2-90DD9004ED51@cisco.com> <482128449.09377@cnnic.cn> <482135997.19355@cnnic.cn> 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 Wed, 18 Aug 2010, Yao Jiankang wrote: > > what do you mean for " What you propose requires new > code for every application client"? I meant the non-BNAME "see other" proposal that Phill has been talking about. Tony. -- f.anthony.n.finch http://dotat.at/ SOUTHEAST ICELAND: NORTHEASTERLY 6 TO GALE 8, PERHAPS SEVERE GALE 9 LATER IN NORTH. ROUGH, BECOMING VERY ROUGH. OCCASIONAL RAIN. MODERATE OR POOR. From yoxyeemue3964@comcast.net Wed Aug 18 10:01: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 02D5D3A69E4 for ; Wed, 18 Aug 2010 10:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.741 X-Spam-Level: X-Spam-Status: No, score=-45.741 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, 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 u3SmJY+BVFgu for ; Wed, 18 Aug 2010 10:01:52 -0700 (PDT) Received: from comcast.net (c-71-196-80-125.hsd1.fl.comcast.net [71.196.80.125]) by core3.amsl.com (Postfix) with ESMTP id C12CE3A69A6 for ; Wed, 18 Aug 2010 10:01:51 -0700 (PDT) From: To: dnsext-archive@ietf.org Reply-To: Subject: Know how to make her come Date: Wed, 18 Aug 2010 13:02:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100818170151.C12CE3A69A6@core3.amsl.com> Watch her lose her virginity and come, all in one night. http://www.dewaxe.ru/ From owner-namedroppers@ops.ietf.org Wed Aug 18 10:27: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 AA3C53A6873; Wed, 18 Aug 2010 10:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.495 X-Spam-Level: X-Spam-Status: No, score=-99.495 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 rl5RZiL+XIfV; Wed, 18 Aug 2010 10:27:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6ED493A6844; Wed, 18 Aug 2010 10:27:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlmMI-000HkV-Eg for namedroppers-data0@psg.com; Wed, 18 Aug 2010 17:23:26 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlmMD-000Hh6-Aj for namedroppers@ops.ietf.org; Wed, 18 Aug 2010 17:23:21 +0000 Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7IHMfj3048942; Wed, 18 Aug 2010 13:22:41 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Wed, 18 Aug 2010 13:22:48 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 18 Aug 2010 13:22:48 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 18 Aug 2010 13:19:14 -0400 To: From: Edward Lewis Subject: Re: [dnsext] Problem with Section 2.2 of RFC 4035 Cc: , Edward Lewis 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:48 +0100 8/18/10, Chris Thompson wrote: >On Aug 17 2010, Edward Lewis wrote: >>To clean up the specification, "it should be emphasized that although the >>signer is supposed to supply one of every signature, the validator only >>needs one working signature to okay the data." > >This seems to completely nullify the protection against the >downgrade attack that the 4035/2.2 text was meant to provide. >(Or else I misunderstsnd what that was.) Yes, there's a misunderstanding. As one operator said "It's not a downgrade attack if something removes signatures that I can't validate...." (Operator being Michael Richardson) The downgrade vulnerability is not that a signature can be stripped but rather that a data set's protection can be dropped from signed to insecure. In reality, the first step is for the protocol to convey to the validator that there is an expectation of a signature, second step is to convey the data, and third step to convey the signature. >A validator can never be sure it has all the RRSIGs signing an RRset, >because the this set is not itself signed. A MitM can selectively >remove RRSIGs to taste. If he can get away with removing all RRSIGs >for a stronger algorithm, he can force the validator to rely on the >weaker one. If he has also cracked the weaker algorithm, he can >start feeding the validator fake responses. One of the misconceptions is that there a notion of "weaker" and "stronger" algorithms. If the MitM has "cracked the weaker" then why not just sign a DNSKEY set with the attacker's key in it and sign the rest of the data? With a "stronger" key? When RFC 2065 was under development (DNSSEC the 1st), we had a notion of strong and weak keys. It just didn't make sense. >This doesn't depend in any way on the validator only understanding >one of the algorithms. It changes the state machine. >The conceptual mismatch here is that 4035/2.2 is assuming long-term >signing with more than one algorithm. When doing a prophylactic >algorithm rollover, one usually isn't worried about downgrade >attacks of this sort, because you assume that the old algorithm >isn't broken *yet*, and won't be before the rollover is completed. I can tell you that is not what was assumed. The situation behind the derivation of the text was this: how does a verifier, in a mixed algorithm environment, determine the expected state of security of a RR set in a zone? Starting with being able to validate records from the parent, meaning, you can verify a signature over the DS set for the child, you can tell if the child is using an algorithm you understand. (States: There is at least one algorithm I understand, There is no algorithm I understand, There are no algorithms in use.) If a zone could choose to sign just some record sets with one algorithm and then use another for others, the validator would not be able to set up an expectation, especially in a situation in which not all algorithms are known. This is why the requirement for "each algorithm" at each set. Note, the restriction isn't "each key." The assumption was that signer had a matching DNSKEY an data set for zone, matching meaning same serial number. But the serial number of a set is not known by a cache's verifier. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh. From owner-namedroppers@ops.ietf.org Wed Aug 18 10: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 3EDD33A6A02; Wed, 18 Aug 2010 10:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.616 X-Spam-Level: X-Spam-Status: No, score=-97.616 tagged_above=-999 required=5 tests=[AWL=-1.280, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MANGLED_LOW=2.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 vBFQmnDY0ms7; Wed, 18 Aug 2010 10:34:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41D553A67FE; Wed, 18 Aug 2010 10:32:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlmRu-000ITi-R2 for namedroppers-data0@psg.com; Wed, 18 Aug 2010 17:29:14 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlmRr-000IT9-4n for namedroppers@ops.ietf.org; Wed, 18 Aug 2010 17:29:11 +0000 Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7IHSvDG049003; Wed, 18 Aug 2010 13:28:57 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Wed, 18 Aug 2010 13:29:03 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 18 Aug 2010 13:29:03 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4C6B916A.7080507@nlnetlabs.nl> References: <4C6AA11E.5030008@nlnetlabs.nl> <4C6B916A.7080507@nlnetlabs.nl> Date: Wed, 18 Aug 2010 13:28:53 -0400 To: "W.C.A. Wijngaards" From: Edward Lewis Subject: Re: [dnsext] Problem with Section 2.2 of RFC 4035 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: First, it's too late to help the existing deployments. Given that there's little difference between algorithms 5 and 7, that's kind of a bad example. What are we solving? Two streams here. One, in operations, the act of algorithm roll over has become a significant concern. I'm avoiding using the word "big" on purpose. Operations should not be required to walk a fine, distinct line to maintain a healthy system. DNS has scaled because it has a wide tolerance in operations. Two, in documentation, clearing up the meaning of the section should be done in the name of accurately recording the design of the protocol. The intent of the section was to tell the signer what had to be done, and to allow verifiers to know what to expect. However, the mistake I made in the analysis period was to neglect to consider that a verifier may, unlike the signer, be looking at the DNSKEY set and the subject data set from different serial number versions of the zone. The map of cases isn't assuming anything about the recipients knowledge of the algorithms. If it does not understand one, the other, or both, there still is a "old" and a "new" algorithm (because the topic is algorithm roll), what differs is how the cases "collapse" in analysis. In essence, "both" is effectively the same as "old" or "new" depending on which of the algorithms a recipient knows. (If the recipient knows neither, the change doesn't matter - unless there's a third algorithm involved.) But even if the recipient does not know the new algorithm, the recipient is aware of it. So it's not complete ignorance, it's the inability to handle the cryptographic elements. The problem is that if we have to account for a situation in which a verifier has an older version of a DNSKEY set than a received data set, it is nearly impossible to retire an algorithm. I suppose that we would have to have servers that continue to serve signatures for which the key has been pulled from the DNSKEY set and even if all of the keys of an algorithm were pulled. IOW, I need to simultaneously allow for the old key sets to expire and fill caches with the new data sets without distributing the algorithm to be retired's keys. I suppose we could accomplish this by pulling the DS records from the parent for an algorithm that is being retired but still push out the keys and signatures. Then the chain of security is quasi-broken for that zone, verifiers knowing only the retired algorithm would see it as insecure. For verifiers knowing all the algorithms involved, they could use the old algorithm, but also have the new available. The latter works better if the verifiers do not enforce the "all algorithms" rule that was meant to apply to the signing process. Are any of these reasonings any more convincing? (I'm still swating at flies here and there while I try to think about this.) At 9:53 +0200 8/18/10, W.C.A. Wijngaards wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi Ed, > >I do not see how 'fixing this' gains us something. If somehow the >resolvers that understand both 5 and 7 act differently, how does that >help with rollover? You must accommodate the resolvers that understand >5, not 7. (and the ones that understand 7 not 5). > >I understand that possibly, we can be more lenient in checking >signatures, in the case where you understand both algorithms and one is >missing. But that situation should not happen because it breaks all the >resolvers that understand only one and that one is missing? It can >therefore certainly not be the 'recommended' rollover method. > >Your map of cases assumes the target understands both algorithms, and I >am with you and I see it could be made more lenient. But it is that >same map for resolvers that support one algorithm that is the issue. >And if you accommodate those other maps, I think that the case where you >understand both could just as well validate both signatures (and be >'pedantic' :-) but the pedantry does tell you that you are botching the >rollover ). > >Best regards, > Wouter > >On 08/17/2010 08:07 PM, Edward Lewis wrote: >> This isn't the same problem. >> >> If a validator understands 5, sees 5 and 7 in the DNSKEY set it holds, >> and then gets a data set signed only with 7, that's an error and rather >> insurmountable because we don't want to allow a downgrade to succeed. >> >> If a validator understands 5 and 7, sees 5 and 7 in the DNSKEY set it >> holds, and then gets a data set signed only with 7, this is a >> non-problem unless the validator gets pedantic and demands the 5 >> signature be there. >> >> In the other-list discussion, I used this matrix: >> >>>> The cache has:--> old-alg-only both-alg-keys >>>> new-alg-only >>>> The cache gets-v >>>> Old sig only I II III >>>> Both sigs IV V VI >>>> New sig only VII VIII IX >> >> That assumed that the validator understood both the old and new algorithm. >> If the validator only understands the old algorithm, then states II, V, and >> VIII become the same as I, IV, and VII. >> >> The states to avoid are III and VII. So, the first situation above, >> which matches VIII, folded into VII, yeah, we have to avoid that. >> >> Thinking... >> >> The best I can come up with now, is that if you only know of the old >> keys, and the new DNSKEY set shows that there's a new algorithm and it >> is matching the signature you have, you can reliably deduce that >> "something is up" in the sense that the authority is changing the zone. >> Even though you cannot validate the signature, you can validate the >> expectation that the data is still signed. >> >> Remembering the danger is that you could be vulnerable to a downgrade, >> the potential attacker would have had to add a new algorithm to the >> DNSKEY set (signed with the algorithm you do know - we call this the >> both-alg-keys set in the matrix) inorder to pull this off. If the >> attacker would forge in a new set of keys, they could just as easily >> forge in a new signature and probably get away with more. >> >> (Sorry, I haven't been able to fully think this out.) >> >> At 16:47 +0200 8/17/10, W.C.A. Wijngaards wrote: >> Hi Ed, >> >> On 08/17/2010 04:24 PM, Edward Lewis wrote: >>>>> The problem is - what if a cache has a copy of a DNSKEY set with >>>>> algorithms 5 and 7 and it receives a set only signed with algorithm 7? >> >> If the validator does not support algorithm 7, then the validator has to >> mark that set as bogus. Thus this rollover is a failure - it does not >> support validators that do not support algorithm 7 - they get a BOGUS >> outage for a TTL. >> >> Therefore during rollover you have to accomodate validators that support >> one of the algorithms but not the other. Thus distribute data sets >> signed with both algorithms during the TTL when validators can have both >> algorithms in the DNSKEY. (Thus a check that signatures 5 and 7 are >> present is a good thing? Zone-lint tools should do this?) >> >> And, no, you cannot require validators to 'fetch data from the >> authority', because they cannot signal an intermediate cache to do so. >> (unless you think sending queries to cause cache memory-exhaustion is ok >> :-) ). (Not sure you claim this, but people may be tempted to use this >> to 'fix' things). >> >> Best regards, >> Wouter >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v2.0.14 (GNU/Linux) >Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > >iEYEARECAAYFAkxrkWkACgkQkDLqNwOhpPifLgCdFZobWQj2pttQX3ZutTKEuuGv >GVAAoJQHLD/OmwUgSM7tyFR6s2XE3K4W >=qNqd >-----END PGP SIGNATURE----- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh. From owner-namedroppers@ops.ietf.org Wed Aug 18 13:31: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 318343A6A12; Wed, 18 Aug 2010 13:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynLUhkjVwp50; Wed, 18 Aug 2010 13:31:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC8533A6A08; Wed, 18 Aug 2010 13:31:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlpCV-000EIB-PJ for namedroppers-data0@psg.com; Wed, 18 Aug 2010 20:25:31 +0000 Received: from [2001:41d0:1:6d55:211:5bff:fe98:d51e] (helo=givry.fdupont.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlpCS-000EHu-SZ for namedroppers@ops.ietf.org; Wed, 18 Aug 2010 20:25:29 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id o7IKPQLa003332 for ; Wed, 18 Aug 2010 20:25:26 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201008182025.o7IKPQLa003332@givry.fdupont.fr> From: Francis Dupont To: namedroppers@ops.ietf.org Subject: [dnsext] about draft-hoffman-dnssec-ecdsa-03.txt Date: Wed, 18 Aug 2010 22:25:26 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I have 3 questions/comments/concerns about this document: 1- IMHO the SHA-384 DS spec should be moved into a stand-alone document. BTW: * the relationship between ECDSA and SHA-384 DS is unclear, at least it was not written down. * there is no equivalent of the RFC 4509 6.1. This is true for GOST (RFC 5933) too, i.e., we need a document about relative strengths of DS algorithms (a relative ordering) and what to do in order to avoid downgrade attacks, even I don't believe we already have a real world problem. 2- some informative details are missing, for instance a private key is a (big) number of the same size than the EC group. 3- the last point can become more important: with previous algorithms of the same kind, even for the RSASHA256/RSASHA512 pair, the key size offers the freedom to choose the 'strength'. This is no longer true for ECDSA so if someone wants to use ECDSAP256SHA256 for ZSKs and ECDSAP384SHA384 for KSKs (s)he gets some trouble with RFC 4035 requirements, for instance: There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. (BTW these requirements are by them-selves the subject of another discussion). Thanks Francis.Dupont@fdupont.fr From owner-namedroppers@ops.ietf.org Wed Aug 18 14: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 1D5F93A6A1D; Wed, 18 Aug 2010 14:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.297 X-Spam-Level: X-Spam-Status: No, score=-100.297 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 2Rha19Y0-r8G; Wed, 18 Aug 2010 14:15:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C4413A6A0C; Wed, 18 Aug 2010 14:15:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlpwN-000KVl-Al for namedroppers-data0@psg.com; Wed, 18 Aug 2010 21:12:55 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlpwK-000KVM-IC for namedroppers@ops.ietf.org; Wed, 18 Aug 2010 21:12:52 +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 o7ILCgMf013725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Aug 2010 14:12:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <201008182025.o7IKPQLa003332@givry.fdupont.fr> References: <201008182025.o7IKPQLa003332@givry.fdupont.fr> Date: Wed, 18 Aug 2010 14:12:41 -0700 To: Francis Dupont , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] about draft-hoffman-dnssec-ecdsa-03.txt 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:25 PM +0200 8/18/10, Francis Dupont wrote: >I have 3 questions/comments/concerns about this document: > > 1- IMHO the SHA-384 DS spec should be moved into a stand-alone > document. It doesn't seem useful to create another RFC just so we can have more RFCs. If someone wants to use SHA-384 without ECDSA, they can still point to this eventual RFC. >BTW: > * the relationship between ECDSA and SHA-384 DS is unclear, > at least it was not written down. Section 4 defines two signing algorithms where the key sizes and the hash sizes are matched: o DNSKEY and RRSIG RRs signifying ECDSA with the P-256 curve and SHA-256 use the algorithm number {TBA-2}. o DNSKEY and RRSIG RRs signifying ECDSA with the P-384 curve and SHA-384 use the algorithm number {TBA-3}. It would be silly to have a mismatched pair of algorithms because that lets an attacker try to break the weaker of the pair. (And, yes, I know that people are currently doing silly things like RSA2048-with-SHA-1, but I don't think we want to keep promoting things like that...) > * there is no equivalent of the RFC 4509 6.1. Good catch! I'll add a pointer to all of RFC 4509 section 6 to the security considerations. > 2- some informative details are missing, for instance a private > key is a (big) number of the same size than the EC group. That isn't a "detail", it is an inherent part of the elliptic curves used in the document. I don't think it is appropriate to have an entire treatise on the properties of the elliptic curves here, just as it wasn't required for any of the other RFCs that use P256 and P384. > 3- the last point can become more important: with previous algorithms > of the same kind, even for the RSASHA256/RSASHA512 pair, the key > size offers the freedom to choose the 'strength'. This is no > longer true for ECDSA so if someone wants to use ECDSAP256SHA256 > for ZSKs and ECDSAP384SHA384 for KSKs (s)he gets some trouble > with RFC 4035 requirements, for instance: > There MUST be an RRSIG for each RRset using at least one DNSKEY of > each algorithm in the zone apex DNSKEY RRset. > (BTW these requirements are by them-selves the subject of another > discussion). That doesn't seem to be a problem, or at least any more problem than if you wanted to use RSA in one place and ECDSA in another. Unless you are saying that we should not allow any signature algorithm other than RSA, the same problem will exist. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Wed Aug 18 14:15: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 011413A6898; Wed, 18 Aug 2010 14:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.49 X-Spam-Level: X-Spam-Status: No, score=0.49 tagged_above=-999 required=5 tests=[AWL=0.927, BAYES_00=-2.599, 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 8HSxLgsNcYen; Wed, 18 Aug 2010 14:15:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 68F533A6A12; Wed, 18 Aug 2010 14:15:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlpxL-000Kq9-SM for namedroppers-data0@psg.com; Wed, 18 Aug 2010 21:13:55 +0000 Received: from [209.86.89.62] (helo=elasmtp-dupuy.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlpxJ-000Kpl-82 for namedroppers@ops.ietf.org; Wed, 18 Aug 2010 21:13:53 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=UhrJ+PCwJV7iIMn97vKbvinoHKITpkouaegL1EEV2JrYUb9Vk5QO8rrjYm/sgYTI; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OlpxI-0003Zz-MO; Wed, 18 Aug 2010 17:13:52 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 18 Aug 2010 17:13:52 -0400 Message-ID: <1458514.1282166032435.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Wed, 18 Aug 2010 16:13:52 -0500 (GMT-05:00) From: "Jeffrey A. Williams" Reply-To: "Jeffrey A. Williams" To: namedroppers@ops.ietf.org Subject: Re: [dnsext] about draft-hoffman-dnssec-ecdsa-03.txt Cc: william.barker@nist.gov Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688ddde207f8366218026033b3b2c508a7f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Francis and all, My responses are in-line this time around, see below... -----Original Message----- >From: Francis Dupont >Sent: Aug 18, 2010 3:25 PM >To: namedroppers@ops.ietf.org >Subject: [dnsext] about draft-hoffman-dnssec-ecdsa-03.txt > >I have 3 questions/comments/concerns about this document: > > 1- IMHO the SHA-384 DS spec should be moved into a stand-alone > document. BTW: > * the relationship between ECDSA and SHA-384 DS is unclear, > at least it was not written down. > * there is no equivalent of the RFC 4509 6.1. This is true > for GOST (RFC 5933) too, i.e., we need a document about > relative strengths of DS algorithms (a relative ordering) > and what to do in order to avoid downgrade attacks, even > I don't believe we already have a real world problem. i strongly disagree. There already are avaliable hacks for key strengts/sizes up to 1024k. Downgrade attacks are much more likely with a standard that is less than 1024k. > > 2- some informative details are missing, for instance a private > key is a (big) number of the same size than the EC group. agreed here. > > 3- the last point can become more important: with previous algorithms > of the same kind, even for the RSASHA256/RSASHA512 pair, the key > size offers the freedom to choose the 'strength'. This is no > longer true for ECDSA so if someone wants to use ECDSAP256SHA256 > for ZSKs and ECDSAP384SHA384 for KSKs (s)he gets some trouble > with RFC 4035 requirements, for instance: > There MUST be an RRSIG for each RRset using at least one DNSKEY of > each algorithm in the zone apex DNSKEY RRset. > (BTW these requirements are by them-selves the subject of another > discussion). Agreed here as well. However limited or limiting the 'kinds' of algorithms gives me some concern presently, although I recognize that LEA's have problems/issues with unknown or not well documented 'kinds' of algorithms for perhaps good and obvious reasons. > >Thanks > >Francis.Dupont@fdupont.fr > Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From owner-namedroppers@ops.ietf.org Wed Aug 18 17:03: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 4396E3A68F5; Wed, 18 Aug 2010 17:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.846 X-Spam-Level: **** X-Spam-Status: No, score=4.846 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_05=-1.11, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m45CygVuVNqe; Wed, 18 Aug 2010 17:03:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 476C63A68C4; Wed, 18 Aug 2010 17:02:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlsVy-000Dy2-51 for namedroppers-data0@psg.com; Wed, 18 Aug 2010 23:57:50 +0000 Received: from [2001:500:60::65] (helo=mx.ams1.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OlsVt-000DxK-KL for namedroppers@ops.ietf.org; Wed, 18 Aug 2010 23:57:45 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 047EB5F98E9; Wed, 18 Aug 2010 23:57:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id BFF28E6030; Wed, 18 Aug 2010 23:57:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2C7ED31CC39; Thu, 19 Aug 2010 09:57:25 +1000 (EST) To: John Levine Cc: namedroppers@ops.ietf.org, yaojk@cnnic.cn From: Mark Andrews References: <20100817175139.216.qmail@joyce.lan> Subject: Re: [dnsext] application issues for the alias names In-reply-to: Your message of "17 Aug 2010 17:51:39 GMT." <20100817175139.216.qmail@joyce.lan> Date: Thu, 19 Aug 2010 09:57:24 +1000 Message-Id: <20100818235725.2C7ED31CC39@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <20100817175139.216.qmail@joyce.lan>, John Levine writes: > >what i mean is that if there are problems for xname in application, > >there are also some problems for provisions in applicatons. the > >applications issues are for both provisions and xname ways. > > It is certainly possible for people to misconfigure applications, no > matter what's in the DNS. Also, again no matter what is in the DNS, > there will be application-specific provisioning rules. To use a > popular example, if all of the web sites under a domain use HTTP, the > alias A records all resolve to the same address, but if some use > HTTPS, the alias A records need to resolve to different addresses. Or you need to use the correct types of cert or you need to add SRV support or ... > Successful i18n will always need some manual or locally scripted > provisioning. My position has always been that xNAME does not avoid > enough of the manual or scripted work to be worth its cost. Reducing part of the work load is always useful. xNAME by itself is useful. xNAME is not a magic bullet but it is part of the solution. 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 Aug 18 17:59: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 BEEEA3A680A; Wed, 18 Aug 2010 17:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.955 X-Spam-Level: X-Spam-Status: No, score=-108.955 tagged_above=-999 required=5 tests=[AWL=0.140, 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, 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 0+q-teSW5DgP; Wed, 18 Aug 2010 17:59:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8E2F73A6765; Wed, 18 Aug 2010 17:59:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OltQ1-000KmV-Qx for namedroppers-data0@psg.com; Thu, 19 Aug 2010 00:55:45 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OltPy-000KkC-Iu for namedroppers@ops.ietf.org; Thu, 19 Aug 2010 00:55:43 +0000 Received: (qmail 91618 invoked from network); 19 Aug 2010 00:55:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=y1mwR6umNtxyLyc/yyLGc9+ATOJdPyGkudPUi7WFZFw=; b=M81w6myI6lH5HJQ+paqToJ0w4znWOQRNnXYV0Bwst5oh5WHcx8VSgTw72+CWHj5jGLHXvWG55tEHSqSWtugYy3tUNXwpbauMjzUjGVOplrhQ+Ikh+W5Kz2q1iXQ9Xl36FJTA30hxKAT0agcjyaX1cmjX0CpSwbrE9YfqMo/lSCY= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Aug 2010 00:55:18 -0000 Date: 18 Aug 2010 20:55:40 -0400 Message-ID: From: "John R. Levine" To: "Mark Andrews" Cc: namedroppers@ops.ietf.org, yaojk@cnnic.cn Subject: Re: [dnsext] application issues for the alias names In-Reply-To: <20100818235725.2C7ED31CC39@drugs.dv.isc.org> References: <20100817175139.216.qmail@joyce.lan> <20100818235725.2C7ED31CC39@drugs.dv.isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Reducing part of the work load is always useful. Agreed, but it's important to keep in mind the overall costs of proposed changes when deciding whether we're actually reducing the workload. > xNAME by itself is useful. Maybe, but we have yet to see whether its utility is worth the cost of changing a zillion pieces of depoyed software to support it. > xNAME is not a magic bullet Definitely > but it is part of the solution. Maybe, maybe not. R's, John From owner-namedroppers@ops.ietf.org Wed Aug 18 19:27: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 101BC3A6A8F; Wed, 18 Aug 2010 19:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.012 X-Spam-Level: X-Spam-Status: No, score=-99.012 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_50=0.001, FH_RELAY_NODNS=1.451, 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 vQM-jNA10LYi; Wed, 18 Aug 2010 19:27:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E1253A6A8B; Wed, 18 Aug 2010 19:27:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Olunu-0004mp-H9 for namedroppers-data0@psg.com; Thu, 19 Aug 2010 02:24:30 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oluns-0004mK-8c for namedroppers@ops.ietf.org; Thu, 19 Aug 2010 02:24:28 +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 o7J2OPiO027663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Aug 2010 19:24:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100817200420.GC89703@shinkuro.com> References: <20100817200420.GC89703@shinkuro.com> Date: Wed, 18 Aug 2010 19:24:24 -0700 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? 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: I have read the SHADOW/CLONE draft. I am not sure I like the specific semantics in this draft, but I suspect that adding replication directives in a zone file that show up on the wire is better than just comments in the zone file, and better than an informational BCP about how to write replication programs in Perl^WPython^Ruby^Wthe current scripting flavor of the month. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Thu Aug 19 00:46: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 31A403A692C; Thu, 19 Aug 2010 00:46:05 -0700 (PDT) X-Quarantine-ID: <0t2MugqkJ4A1> 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: -99.157 X-Spam-Level: X-Spam-Status: No, score=-99.157 tagged_above=-999 required=5 tests=[AWL=1.047, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MSGID_FROM_MTA_HEADER=0.803, 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 0t2MugqkJ4A1; Thu, 19 Aug 2010 00:46:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 402003A68BF; Thu, 19 Aug 2010 00:46:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Olzk9-000Iax-PX for namedroppers-data0@psg.com; Thu, 19 Aug 2010 07:40:57 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Olzk7-000Iab-1y for namedroppers@ops.ietf.org; Thu, 19 Aug 2010 07:40:55 +0000 Received: (eyou send program); Thu, 19 Aug 2010 15:40:52 +0800 Message-ID: <482203652.06373@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, 19 Aug 2010 15:40:52 +0800 Message-ID: From: "Jiankang YAO" To: Subject: [dnsext] Fw: New Version Notification for draft-yao-dnsext-bname-05 Date: Thu, 19 Aug 2010 15:41:27 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: bmV3IHZlcnNpb24gaXMgYXZhaWxhYmxlLg0KDQp1cGRhdGluZyBpcyA6DQoNCiAgIG8gIGFkZCBz ZWN0aW9uOiBibmFtZSBleGFtcGxlcw0KICAgbyAgYWRkIHNlY3Rpb246IFNpZ25hbGluZyBvZiBC TkFNRQ0KDQp0aGFua3MuDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206 ICJJRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wiIDxpZHN1Ym1pc3Npb25AaWV0Zi5vcmc+DQpUbzog PHlhb2prQGNubmljLmNuPg0KQ2M6IDxsZWVAY25uaWMuY24+OyA8dml4aWVAaXNjLm9yZz4NClNl bnQ6IFRodXJzZGF5LCBBdWd1c3QgMTksIDIwMTAgMzozMSBQTQ0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15YW8tZG5zZXh0LWJuYW1lLTA1IA0KDQoNCj4gDQo+ IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC15YW8tZG5zZXh0LWJuYW1lLTA1LnR4dCBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEppYW5rYW5nIFlhbyBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBGaWxlbmFtZTogZHJhZnQteWFvLWRuc2V4dC1i bmFtZQ0KPiBSZXZpc2lvbjogMDUNCj4gVGl0bGU6IEJ1bmRsZWQgRE5TIE5hbWUgUmVkaXJlY3Rp b24NCj4gQ3JlYXRpb25fZGF0ZTogMjAxMC0wOC0xOQ0KPiBXRyBJRDogSW5kZXBlbmRlbnQgU3Vi bWlzc2lvbg0KPiBOdW1iZXJfb2ZfcGFnZXM6IDE1DQo+IA0KPiBBYnN0cmFjdDoNCj4gVGhpcyBk b2N1bWVudCBkZWZpbmVzIGEgbmV3IEROUyBSZXNvdXJjZSBSZWNvcmQgY2FsbGVkICJCTkFNRSIs IHdoaWNoDQo+IHByb3ZpZGVzIHRoZSBjYXBhYmlsaXR5IHRvIG1hcCBpdHNlbGYgYW5kIGl0cyBz dWJ0cmVlIG9mIHRoZSBETlMgbmFtZQ0KPiBzcGFjZSB0byBhbm90aGVyIGRvbWFpbi4gIEl0IGRp ZmZlcnMgZnJvbSB0aGUgQ05BTUUgcmVjb3JkIHdoaWNoIG9ubHkNCj4gbWFwcyBhIHNpbmdsZSBu b2RlIG9mIHRoZSBETlMgbmFtZSBzcGFjZSwgZnJvbSB0aGUgRE5BTUUgd2hpY2ggb25seQ0KPiBt YXBzIHRoZSBzdWJ0cmVlIG9mIHRoZSBETlMgbmFtZSBzcGFjZSB0byBhbm90aGVyIGRvbWFpbi4N Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJp YXQuDQo+IA0KPg== From owner-namedroppers@ops.ietf.org Thu Aug 19 01: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 C0BAB3A689C; Thu, 19 Aug 2010 01:34:44 -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 E5M-ILceui64; Thu, 19 Aug 2010 01:34:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 438123A67F2; Thu, 19 Aug 2010 01:34:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Om0WP-0000AJ-DG for namedroppers-data0@psg.com; Thu, 19 Aug 2010 08:30:49 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Om0WM-00009B-BK for namedroppers@ops.ietf.org; Thu, 19 Aug 2010 08:30:46 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.3) with ESMTP id o7J8Uf7B049345 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 10:30:42 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4C6CEBB1.2030903@nlnetlabs.nl> Date: Thu, 19 Aug 2010 10:30:41 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1 MIME-Version: 1.0 To: Paul Hoffman CC: Francis Dupont , namedroppers@ops.ietf.org Subject: Re: [dnsext] about draft-hoffman-dnssec-ecdsa-03.txt References: <201008182025.o7IKPQLa003332@givry.fdupont.fr> In-Reply-To: X-Enigmail-Version: 1.1.2 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.5 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 19 Aug 2010 10:30:42 +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 Paul, Francis, On 08/18/2010 11:12 PM, Paul Hoffman wrote: > At 10:25 PM +0200 8/18/10, Francis Dupont wrote: >> I have 3 questions/comments/concerns about this document: >> >> 1- IMHO the SHA-384 DS spec should be moved into a stand-alone >> document. > > It doesn't seem useful to create another RFC just so we can have more > RFCs. If someone wants to use SHA-384 without ECDSA, they can still > point to this eventual RFC. Agree with Paul. >> BTW: * the relationship between ECDSA and SHA-384 DS is unclear, at >> least it was not written down. I think for hash strengths some future document could be written about strengths, right now it is pretty clear that 384 has more bits than the others, and thus would be preferable. (I understand the math might break differently as the algorithms are different). It is possible to avoid 'picking the strongest', by changing the requirement 'to ignore the weaker algorithm' to 'every DS hash algorithm must have a match'. (Similar to 4035sec2.2 text about DNSKEY algorithms). This would also protect against downgrades, but by forcing both hash algorithms to match, so without having to pick favorites. Given signing requirements this change is backwards compatible. However, the ecdsa draft is not the place for changes to the handling of multiple hash algorithms (if this needs to be changed). >> 3- the last point can become more important: with previous >> algorithms of the same kind, even for the RSASHA256/RSASHA512 pair, >> the key size offers the freedom to choose the 'strength'. This is >> no longer true for ECDSA so if someone wants to use >> ECDSAP256SHA256 for ZSKs and ECDSAP384SHA384 for KSKs (s)he gets >> some trouble with RFC 4035 requirements, for instance: There MUST >> be an RRSIG for each RRset using at least one DNSKEY of each >> algorithm in the zone apex DNSKEY RRset. (BTW these requirements >> are by them-selves the subject of another discussion). > > That doesn't seem to be a problem, or at least any more problem than > if you wanted to use RSA in one place and ECDSA in another. Unless > you are saying that we should not allow any signature algorithm other > than RSA, the same problem will exist. What could be possible is to make one DNSKEY algorithm ID, TBA-2, and use the length of the DNSKEY key data to signify the ECDSA key size. P-256 would store 2 256-bit numbers, P-384 stores 2 384 bit numbers and so on. Then the zone can be signed with the TBA-2 number, and use a longer key for the KSK than for ZSK. It is SHA256 or SHA384 also depending on the key-size which is 'different'. There must then be fixed list of key sizes and the ec groups used. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxs67EACgkQkDLqNwOhpPjG4gCgkZoK2CIEW0yS2k0EQirsL/pT 74YAoJ1HGZjWc5OBR1z/rIurDubZfYgq =OfY+ -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Thu Aug 19 01:46: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 03ADB3A67E1; Thu, 19 Aug 2010 01:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MANGLED_LOW=2.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 x94x7yvcxb7M; Thu, 19 Aug 2010 01:46:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B96B3A63EC; Thu, 19 Aug 2010 01:46:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Om0hJ-0001SC-Vu for namedroppers-data0@psg.com; Thu, 19 Aug 2010 08:42:05 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Om0hF-0001RI-Hh for namedroppers@ops.ietf.org; Thu, 19 Aug 2010 08:42:02 +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.4/8.14.3) with ESMTP id o7J8frGp051703 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 10:41:53 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4C6CEE51.4080003@nlnetlabs.nl> Date: Thu, 19 Aug 2010 10:41:53 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1 MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Problem with Section 2.2 of RFC 4035 References: <4C6AA11E.5030008@nlnetlabs.nl> <4C6B916A.7080507@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 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.5 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 19 Aug 2010 10:41:54 +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 Ed, So, going back to your table, go over the issue. There is an algorithm rollover. The cache may support old, support new, or support both old and new algorithms or support neither. Caches that support neither old, nor new algorithm will see this when they encounter the DS record from the parent and go to insecure. This is backwards compatibility from the DNSSEC spec. If the cache supports the old, but not the new algorithm. * It has the old DNSKEY. - It gets the old signature: OK. - It gets the old+new signature: OK. It ignores the extra signature here. DNSSEC spec tells validators to ignore 'extra' signatures. - It gets the new signature: Bogus. It looks like the old signature has been removed and some unknown signature inserted. * It has the old+new DNSKEYs The same as for the old DNSKEY only. It might get pedantic and complain if the new signature is not there that it should be there (but it cannot understand it). * It has the new DNSKEY. Because it does not support the new algorithm, it will see that the DS record has only unknown algorithms and fall to insecure for this domain. If the validator supports both the old and the new algorithm. * It has the old DNSKEY. - it gets the old signature: OK. - it gets old+new signatures: OK. Ignores extra signature. - it gets new signature, Bogus. old signature is missing, and there is no key for this new signature. * It has the old+new DNSKEYs. - it gets the old signature: the strict implementation of 4035-2.2 rejects this because the new signature is missing. Since the old signature is understood, this may constitute enough crypto to trust the data. - it gets the old+new signatures: OK. - it gets the new signature: same as only the old, strict complains that this zone is badly signed, lenient may see enough crypto that it can understand. * It has the new DNSKEY. - it gets the old signature: Bogus. new signature missing, no old key present. - it gets old+new signatures: OK. Ignores extra signature. - it gets the new signature: OK. If the cache supports the new algorithm but not the old. This is similar to supporting only the old algorithm, but with 'old' and 'new' interchanged. The only thing that is not symmetrical in the DNSSEC spec is the DS-hash algorithm treatment, where the 'weaker algorithm is ignored'. So a successful rollover will have to avoid the Bogus state, it is undesirable to create outages. At the end, the validators that support the old but not the new algorithm end up going to insecure for the zone. The first thing you want to do is insert the new DNSKEY with the new algorith, but doing so, because of DNS TTLs, will cause validators to see the old+new DNSKEYs with old(cached) data with only the old signature, and validators that support only the new algorithm but not the old will go BOGUS since the signature they understand is missing. So, before you can insert the new DNSKEY you have to distribute the new signatures. This is fine because the extra signatures are ignored. Once old+new signatures are distributed, you then can insert the new key. Validators that understand only the old algorithm continue validating the old signature from the old key (and ignore the added new signature if they encounter it, and do not understand the new key). Validators that understand the new but not the old algorithms do not get their hands on the new DNSKEY until the new signatures are also certain to be available. Validators that understand both have no reason to complain as they get both signatures when they hold both keys. So, then you are in a state with old+new DNSKEY and old+new signatures. You want to remove the old DNSKEY and old signatures. You cannot remove the signatures with the old algorithm right away, because validators that understand the old but not the new algorithm would go Bogus if the signature they can understand is no longer available. You have to remove the old DNSKEY first. Wait TTL. Then you can remove the old signatures. Because after you waited TTL, the validators that did not understand the new algorithm have to refetch their DNSKEY and see it now has only the new algorithm, which they do not support, and they go to insecure for the zone. And then you can remove the old signatures as well. Validators which understand both old and new algorithms also pick up the new DNSKEY (without the old) and no longer have cause to complain about missing old signatures. Validators that only understand the new algorithm are fine too. If you have a parent, then also, you have to in the state when you are double-signed, perform a DS-exchange. You can change your DS from the old to only the new. (I think you can do this in one go, because you are neatly double signed). You then wait TTL before removing the old DNSKEY. So, after all this rollover stuff, you can see that you have to accommodate for validators that do not support both algorithms. And that by doing so, you make sure that signatures for every algorithm are available for validators that hold DNSKEYs with multiple algorithms. Thus, checking strictly that such signatures are available should only fail when validators that support only one algorithm go Bogus. And if you do the rollover properly, that should never occur. Best regards, Wouter On 08/18/2010 07:28 PM, Edward Lewis wrote: > First, it's too late to help the existing deployments. Given that > there's little difference between algorithms 5 and 7, that's kind of a > bad example. > > What are we solving? Two streams here. > > One, in operations, the act of algorithm roll over has become a > significant concern. I'm avoiding using the word "big" on purpose. > Operations should not be required to walk a fine, distinct line to > maintain a healthy system. DNS has scaled because it has a wide > tolerance in operations. > > Two, in documentation, clearing up the meaning of the section should be > done in the name of accurately recording the design of the protocol. > The intent of the section was to tell the signer what had to be done, > and to allow verifiers to know what to expect. However, the mistake I > made in the analysis period was to neglect to consider that a verifier > may, unlike the signer, be looking at the DNSKEY set and the subject > data set from different serial number versions of the zone. > > The map of cases isn't assuming anything about the recipients knowledge > of the algorithms. If it does not understand one, the other, or both, > there still is a "old" and a "new" algorithm (because the topic is > algorithm roll), what differs is how the cases "collapse" in analysis. > In essence, "both" is effectively the same as "old" or "new" depending > on which of the algorithms a recipient knows. (If the recipient knows > neither, the change doesn't matter - unless there's a third algorithm > involved.) > > But even if the recipient does not know the new algorithm, the recipient > is aware of it. So it's not complete ignorance, it's the inability to > handle the cryptographic elements. > > The problem is that if we have to account for a situation in which a > verifier has an older version of a DNSKEY set than a received data set, > it is nearly impossible to retire an algorithm. > > I suppose that we would have to have servers that continue to serve > signatures for which the key has been pulled from the DNSKEY set and > even if all of the keys of an algorithm were pulled. IOW, I need to > simultaneously allow for the old key sets to expire and fill caches with > the new data sets without distributing the algorithm to be retired's keys. > > I suppose we could accomplish this by pulling the DS records from the > parent for an algorithm that is being retired but still push out the > keys and signatures. Then the chain of security is quasi-broken for > that zone, verifiers knowing only the retired algorithm would see it as > insecure. For verifiers knowing all the algorithms involved, they could > use the old algorithm, but also have the new available. > > The latter works better if the verifiers do not enforce the "all > algorithms" rule that was meant to apply to the signing process. > > Are any of these reasonings any more convincing? (I'm still swating at > flies here and there while I try to think about this.) > > > At 9:53 +0200 8/18/10, W.C.A. Wijngaards wrote: > Hi Ed, > > I do not see how 'fixing this' gains us something. If somehow the > resolvers that understand both 5 and 7 act differently, how does that > help with rollover? You must accommodate the resolvers that understand > 5, not 7. (and the ones that understand 7 not 5). > > I understand that possibly, we can be more lenient in checking > signatures, in the case where you understand both algorithms and one is > missing. But that situation should not happen because it breaks all the > resolvers that understand only one and that one is missing? It can > therefore certainly not be the 'recommended' rollover method. > > Your map of cases assumes the target understands both algorithms, and I > am with you and I see it could be made more lenient. But it is that > same map for resolvers that support one algorithm that is the issue. > And if you accommodate those other maps, I think that the case where you > understand both could just as well validate both signatures (and be > 'pedantic' :-) but the pedantry does tell you that you are botching the > rollover ). > > Best regards, > Wouter > > On 08/17/2010 08:07 PM, Edward Lewis wrote: >>>> This isn't the same problem. >>>> >>>> If a validator understands 5, sees 5 and 7 in the DNSKEY set it holds, >>>> and then gets a data set signed only with 7, that's an error and rather >>>> insurmountable because we don't want to allow a downgrade to succeed. >>>> >>>> If a validator understands 5 and 7, sees 5 and 7 in the DNSKEY set it >>>> holds, and then gets a data set signed only with 7, this is a >>>> non-problem unless the validator gets pedantic and demands the 5 >>>> signature be there. >>>> >>>> In the other-list discussion, I used this matrix: >>>> >>>>>> The cache has:--> old-alg-only both-alg-keys >>>>>> new-alg-only >>>>>> The cache gets-v >>>>>> Old sig only I >>>>>> II III >>>>>> Both sigs IV >>>>>> V VI >>>>>> New sig only VII >>>>>> VIII IX >>>> >>>> That assumed that the validator understood both the old and new >>>> algorithm. >>>> If the validator only understands the old algorithm, then states II, >>>> V, and >>>> VIII become the same as I, IV, and VII. >>>> >>>> The states to avoid are III and VII. So, the first situation above, >>>> which matches VIII, folded into VII, yeah, we have to avoid that. >>>> >>>> Thinking... >>>> >>>> The best I can come up with now, is that if you only know of the old >>>> keys, and the new DNSKEY set shows that there's a new algorithm and it >>>> is matching the signature you have, you can reliably deduce that >>>> "something is up" in the sense that the authority is changing the zone. >>>> Even though you cannot validate the signature, you can validate the >>>> expectation that the data is still signed. >>>> >>>> Remembering the danger is that you could be vulnerable to a downgrade, >>>> the potential attacker would have had to add a new algorithm to the >>>> DNSKEY set (signed with the algorithm you do know - we call this the >>>> both-alg-keys set in the matrix) inorder to pull this off. If the >>>> attacker would forge in a new set of keys, they could just as easily >>>> forge in a new signature and probably get away with more. >>>> >>>> (Sorry, I haven't been able to fully think this out.) >>>> >>>> At 16:47 +0200 8/17/10, W.C.A. Wijngaards wrote: >>>> Hi Ed, >>>> >>>> On 08/17/2010 04:24 PM, Edward Lewis wrote: >>>>>>> The problem is - what if a cache has a copy of a DNSKEY set with >>>>>>> algorithms 5 and 7 and it receives a set only signed with >>>>>>> algorithm 7? >>>> >>>> If the validator does not support algorithm 7, then the validator >>>> has to >>>> mark that set as bogus. Thus this rollover is a failure - it does not >>>> support validators that do not support algorithm 7 - they get a BOGUS >>>> outage for a TTL. >>>> >>>> Therefore during rollover you have to accomodate validators that >>>> support >>>> one of the algorithms but not the other. Thus distribute data sets >>>> signed with both algorithms during the TTL when validators can have >>>> both >>>> algorithms in the DNSKEY. (Thus a check that signatures 5 and 7 are >>>> present is a good thing? Zone-lint tools should do this?) >>>> >>>> And, no, you cannot require validators to 'fetch data from the >>>> authority', because they cannot signal an intermediate cache to do so. >>>> (unless you think sending queries to cause cache memory-exhaustion >>>> is ok >>>> :-) ). (Not sure you claim this, but people may be tempted to use this >>>> to 'fix' things). >>>> >>>> Best regards, >>>> Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxs7lEACgkQkDLqNwOhpPhmbACgreUMXSlfAo/iWvvOd0c0w9U2 NS0An1B1JVPZxAAz0yBRBE/TSAWvVJdc =Hwxu -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Thu Aug 19 03:24: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 70F253A6822; Thu, 19 Aug 2010 03:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.097 X-Spam-Level: X-Spam-Status: No, score=-3.097 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, J_CHICKENPOX_15=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 uMkB98BVG-dg; Thu, 19 Aug 2010 03:24:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 762043A6818; Thu, 19 Aug 2010 03:24:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Om2Dp-000Eku-WE for namedroppers-data0@psg.com; Thu, 19 Aug 2010 10:19:46 +0000 Received: from [131.111.8.133] (helo=ppsw-33.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Om2Dn-000Ejm-8P for namedroppers@ops.ietf.org; Thu, 19 Aug 2010 10:19:43 +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]:52866) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Om2Dm-0004HR-gg (Exim 4.72) (return-path ); Thu, 19 Aug 2010 11:19:42 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Om2Dm-0001Yn-7B (Exim 4.67) (return-path ); Thu, 19 Aug 2010 11:19:42 +0100 Date: Thu, 19 Aug 2010 11:19:42 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Andrew Sullivan cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? In-Reply-To: <20100817200420.GC89703@shinkuro.com> Message-ID: References: <20100817200420.GC89703@shinkuro.com> 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 Tue, 17 Aug 2010, Andrew Sullivan wrote: > > This question is explicitly addressed to those participants. If you > think that some xNAME strategy is too costly for its advantages, it > would be excellent if, in this thread, you stated your reasons for > thinking that the SHADOW approach is or is not worth adopting. SHADOW is simpler from the protocol semantics point of view - CNAME and DNAME have proven to be difficult in the past and BNAME and C+DNAME look like they are as well, especially WRT DNSSEC. SHADOW is easier to deploy since the only code changes necessary are at the DNS hosting providers of the cloned domains. Tony. -- f.anthony.n.finch http://dotat.at/ DOGGER FISHER GERMAN BIGHT HUMBER THAMES DOVER WIGHT PORTLAND CYCLONIC 6 TO GALE 8 IN NORTH FISHER AT FIRST, OTHERWISE SOUTHWESTERLY BACKING SOUTHERLY, 4 OR 5, OCCASIONALLY 6. MODERATE OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. From kucharski350@yahoo.com Thu Aug 19 05: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 A574E3A68E7 for ; Thu, 19 Aug 2010 05:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.366 X-Spam-Level: *** X-Spam-Status: No, score=3.366 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, SUSPICIOUS_RECIPS=2.912] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPq4nzfwanPo for ; Thu, 19 Aug 2010 05:45:37 -0700 (PDT) Received: from web82604.mail.mud.yahoo.com (web82604.mail.mud.yahoo.com [68.142.201.121]) by core3.amsl.com (Postfix) with SMTP id D45BB3A6937 for ; Thu, 19 Aug 2010 05:45:37 -0700 (PDT) Received: (qmail 85470 invoked by uid 60001); 19 Aug 2010 12:46:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1282221962; bh=kaliwzOeepZ3dvW+Xpxre5TVQIrqO52odxLpfcFxS+A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=gtHBvCLxJoOL1LVcbppIwZ7erGBTlL6/yvXcKeelKMmghfMcWbKKEF2LjnHk6QsH7quU31ZPxoo1XaPeQHZTuNxWAREpVxMe6GizjI/Qrpdh8NaImEwY4aLdRZOjACg44s8VH8e9XXRZ/tl8i8ZMNDBqYyF0ModSMzrh56c1uDQ= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=Bpeyn9x5dXNfAkzFFmXQgOphW/iiJ/eR0law5DqvVqPwoRsbF3TwA1OQh6OjJbrNyKCkTlUwQ/aqVlOubpWhLNvJ9Y75MWeLNYrfA2lEfu46YVv5tXta3PpSx79QW/iOB5gbel72YuJPnvZE0vVtQDZQk5sguHAklojKF8av/oA=; Message-ID: <471635.82618.qm@web82604.mail.mud.yahoo.com> X-YMail-OSG: R.fvp4EVM1nW52rdfj_IDLMKvFceoYLVx_5SG2ZwOHPqpZi uuPGvjuPDhTWXBFKPNpBhtV8rUK6mig3_0twmUrIzGjqh1F156dfw0KvjEGf 5v_q_n9DhTTmns3fHjglynGpmOH8G0R88tRS0eZs2U1xu7Fr8lkQsgmHLYJX fzbFp06DlQXQ.B4.lT1HmBI0CTokKvpF9HTyS0C1i8ebxnH8yjrXZxQgXFHi x3tpWqw_fL_x8XbUN6obNEA6Cqxcqpbpy9FcgxA-- Received: from [116.7.114.241] by web82604.mail.mud.yahoo.com via HTTP; Thu, 19 Aug 2010 05:46:02 PDT X-Mailer: YahooMailClassic/11.3.2 YahooMailWebService/0.8.105.279950 Date: Thu, 19 Aug 2010 05:46:02 -0700 (PDT) From: Tony Kucharski Subject: =?utf-8?B?T+OAkOWQiOS9nOOAkQ==?= To: dnsccn@163.com, dnsl@0797dnsl.com, dnsrens@qq.com, dnsky2004@down.dnsky.net, dnsor@msn.com, dns-admin@lycos-inc.com, dnsdq@163.com, dnsoftx@hotmail.com, dnsk1981@163.com, dnsmith@must.edu.mo, dnsntrade01@hotmail.com, dnsext-archive@lists.ietf.org, dnsonline@gmail.com, dnsomh@sogou.com, dnsmcq@hotmail.com, dnsong@tom.com, dnsoft775885@sina.com, dnsbot@iasoft.es, dnsila@xizya.com, dnscorp@bdcom.com, dnsong@163.net, dns-admin@starwave.com, dn-sale10@163.com, dns@dnstm.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-239283635-1282221962=:82618" --0-239283635-1282221962=:82618 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =E8=B2=A0=E8=B2=AC=E4=BA=BA(=E7=B6=93=E7=90=86/=E8=B2=A1=E5=8B=99=EF=BC=89= =E6=82=A8=E5=A5=BD=20 =C2=A0 =E6=9C=89=E4=BD=99=E9=A1=8D=E7=9A=84=E7=A5=A8//=E6=93=9A=E5=90=91=E5= =A4=96=E4=BB=A3=E9=96=8B,=E6=88=91=E5=8F=B8=E5=8F=AF=E7=82=BA=E8=B2=B4=E5= =85=AC=E5=8F=B8=E6=8F=90=E4=BE=9B=E5=A6=82=E4=B8=8B=E5=A2=9E=E5=80=BC=E7=A8= =85=EF=BC=8C=E5=95=86=E5=93=81=E9=8A=B7=E5=94=AE=EF=BC=8C=E5=BB=A3=E5=91=8A= =E6=A5=AD=EF=BC=8C=E6=9C=8D=E5=8B=99=E6=A5=AD=EF=BC=8C =E9=81=8B=E8=BC=B8=EF=BC=8C=E5=BB=BA=E7=AF=89=E5=AE=89=E8=A3=9D=EF=BC=8C=E6= =9C=83=E8=AD=B0=E8=B2=BB=EF=BC=8C=E5=B7=A5=E6=A5=AD=E7=B5=B1=E4=B8=80=E7=AD= =89=EF=BC=8C=E4=BB=A5=E5=8F=8A=E5=9C=8B=E5=85=A7=E5=90=84=E7=9C=81=E5=B8=82= =E5=9C=8B=E7=A8=85/=E5=9C=B0=E7=A8=85//[=E7=99=BC//=E7=A5=A8] (0.5%-2%), =C2=A0=20 =C2=A0=E8=81=94=E7=B3=BB;=E5=BC=A0=E5=B0=8F=E5=A7=90=20 =C2=A0=E7=94=B5=E8=AF=9D:=EF=BC=91=EF=BC=93=EF=BC=96=EF=BC=93=EF=BC=92=EF= =BC=99=EF=BC=93=EF=BC=90=EF=BC=92=EF=BC=92=EF=BC=93=C2=A0=C2=A0=C2=A0=20 =C2=A0 Q=E3=80=80Q;=EF=BC=93=EF=BC=90=EF=BC=92=EF=BC=95=EF=BC=94=EF=BC=90= =EF=BC=92=EF=BC=98=EF=BC=90=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =E6=B3=A8=EF=BC=9A=E8=AF=B7=E4=B8=8D=E8=A6=81=E5=9B=9E=E5=A4=8D=E6=AD= =A4=E9=82=AE=E7=AE=B1=EF=BC=81 =0A=0A=0A --0-239283635-1282221962=:82618 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

=E8=B2=A0=E8=B2=AC=E4=BA=BA(=E7=B6=93=E7= =90=86/=E8=B2=A1=E5=8B=99=EF=BC=89=E6=82=A8=E5=A5=BD

  =E6=9C= =89=E4=BD=99=E9=A1=8D=E7=9A=84=E7=A5=A8//=E6=93=9A=E5=90=91=E5=A4=96=E4=BB= =A3=E9=96=8B,=E6=88=91=E5=8F=B8=E5=8F=AF=E7=82=BA=E8=B2=B4=E5=85=AC=E5=8F= =B8=E6=8F=90=E4=BE=9B=E5=A6=82=E4=B8=8B=E5=A2=9E=E5=80=BC=E7=A8=85=EF=BC=8C= =E5=95=86=E5=93=81=E9=8A=B7=E5=94=AE=EF=BC=8C=E5=BB=A3=E5=91=8A=E6=A5=AD=EF= =BC=8C=E6=9C=8D=E5=8B=99=E6=A5=AD=EF=BC=8C

=E9=81=8B=E8=BC=B8=EF=BC= =8C=E5=BB=BA=E7=AF=89=E5=AE=89=E8=A3=9D=EF=BC=8C=E6=9C=83=E8=AD=B0=E8=B2=BB= =EF=BC=8C=E5=B7=A5=E6=A5=AD=E7=B5=B1=E4=B8=80=E7=AD=89=EF=BC=8C=E4=BB=A5=E5= =8F=8A=E5=9C=8B=E5=85=A7=E5=90=84=E7=9C=81=E5=B8=82=E5=9C=8B=E7=A8=85/=E5= =9C=B0=E7=A8=85//[=E7=99=BC//=E7=A5=A8] (0.5%-2%),
 
 =E8= =81=94=E7=B3=BB;=E5=BC=A0=E5=B0=8F=E5=A7=90
 =E7=94=B5=E8=AF=9D:= =EF=BC=91=EF=BC=93=EF=BC=96=EF=BC=93=EF=BC=92=EF=BC=99=EF=BC=93=EF=BC=90=EF= =BC=92=EF=BC=92=EF=BC=93   
  Q=E3=80=80Q;=EF=BC=93= =EF=BC=90=EF=BC=92=EF=BC=95=EF=BC=94=EF=BC=90=EF=BC=92=EF=BC=98=EF=BC=90&nb= sp;            =          =E6=B3=A8=EF=BC=9A=E8=AF= =B7=E4=B8=8D=E8=A6=81=E5=9B=9E=E5=A4=8D=E6=AD=A4=E9=82=AE=E7=AE=B1=EF=BC=81=

=0A=0A --0-239283635-1282221962=:82618-- From owner-namedroppers@ops.ietf.org Thu Aug 19 11:15: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 265B73A67FD; Thu, 19 Aug 2010 11:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.958 X-Spam-Level: X-Spam-Status: No, score=-108.958 tagged_above=-999 required=5 tests=[AWL=0.137, 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, 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 rK-aZrzDkKsR; Thu, 19 Aug 2010 11:15:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8EC273A68DE; Thu, 19 Aug 2010 11:15:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Om9Z9-0002W6-S3 for namedroppers-data0@psg.com; Thu, 19 Aug 2010 18:10:15 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Om9Z6-0002VC-BT for namedroppers@ops.ietf.org; Thu, 19 Aug 2010 18:10:12 +0000 Received: (qmail 82403 invoked from network); 19 Aug 2010 18:10:05 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 19 Aug 2010 18:10: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=k1008; olt=johnl@user.iecc.com; bh=W0rc9tWQHf9ceWCHoUx/5LzYa7ZwaklBBq1LBLMunlA=; b=dhLAgIsZ5NfgJu/4YokAGku36KuDEmH3iuei9Z/vgN/2XZzXWdf9DGrUaNvkPwXjqBwEo0nLuz+qP1oZ7V+fyhHtk2Htva1uHAJjLdaX9RCW8B7343NgrlnJLWu2siYQQWzJmPtddERBZjHpI8Uhdgelebwg1x+P8+uJGy+8CVI= Date: 19 Aug 2010 18:10:05 -0000 Message-ID: <20100819181005.47680.qmail@joyce.lan> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? In-Reply-To: <20100817200420.GC89703@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: I like the idea of SHADOW, although I hate the proposed implementation. One good thing about it is that it's easy to roll out incrementally. All you need is a group of servers that share zone info and understand some version of SHADOW. It's easy to do experiments, since its effects should be transparent outside that server group, and multiple incompatible experiments are easy to do so long as server groups don't overlap. Another good thing about it is that it admits that making two zones "the same" is more than mechanically copying one subtree to another, and could involve both modifications that SHADOW can describe and modifications that have to be described some other way. The proposed implementation is hopeless, since the assumption that secondaries work from copies of a master's zone file is usually wrong. I'd want the SHADOW info to be in the zone itself, so it gets copied using AXFR or RSYNC or whatever the secondaries use. Here's a sketch, no doubt with both syntactic and semantic bugs. ; Make the zone at S a copy of the zone at A A SHADOW COPY S ; When copying records at name N of type RR, copy names within ; the record literally. Intended for MX, SRV, etc. N SHADOW LIT RR ; When copying records at name N of type RR, use local policy to ; modify the copy, fail if no local policy exists. Intended for ; A records pointing to HTTPS servers, etc. The local policy ; language is NOT specified, per Paul H's note about perl, ruby, etc. N SHADOW LOCAL RR It would also be nice if there were some way to propagate shadow info to subzones, but that breaks the useful characteristic that you know what servers will be interpreting your SHADOW instructions. R's, John From dnsext-archive@ietf.org Thu Aug 19 11:17: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 A42373A686A for ; Thu, 19 Aug 2010 11:17:49 -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): Subject: ...-archive@ietf.org VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_MISMATCH_NET=0.611, 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_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7xTVi7IzZaZ for ; Thu, 19 Aug 2010 11:17:42 -0700 (PDT) Received: from 89-115-133-161.cl.ipv4ilink.net (unknown [89.115.133.161]) by core3.amsl.com (Postfix) with SMTP id 56B973A6899 for ; Thu, 19 Aug 2010 11:17:42 -0700 (PDT) Received: (qmail 2492 by uid 786); Thu, 19 Aug 2010 20:01:39 +0400 Message-Id: <20100819200139.2494.qmail@89-115-133-161.cl.ipv4ilink.net> From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org VIAGRA ® Official Seller -61% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 19 Aug 2010 11:17:42 -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 All rights reserved.
From owner-namedroppers@ops.ietf.org Thu Aug 19 11:38: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 338A53A68C3; Thu, 19 Aug 2010 11:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 dCxOppGnpXRf; Thu, 19 Aug 2010 11:38:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 731AA3A6844; Thu, 19 Aug 2010 11:38:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Om9xa-0005u8-Lx for namedroppers-data0@psg.com; Thu, 19 Aug 2010 18:35: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.72 (FreeBSD)) (envelope-from ) id 1Om9xY-0005tg-1q for namedroppers@ops.ietf.org; Thu, 19 Aug 2010 18:35:28 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id B6376A1031; Thu, 19 Aug 2010 18:35:26 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: John Levine cc: namedroppers@ops.ietf.org, ajs@shinkuro.com Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? In-Reply-To: Your message of "19 Aug 2010 18:10:05 GMT." <20100819181005.47680.qmail@joyce.lan> References: <20100819181005.47680.qmail@joyce.lan> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 19 Aug 2010 18:35:26 +0000 Message-ID: <22590.1282242926@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: 19 Aug 2010 18:10:05 -0000 > From: John Levine > > The proposed implementation is hopeless, since the assumption that > secondaries work from copies of a master's zone file is usually wrong. > I'd want the SHADOW info to be in the zone itself, so it gets copied > using AXFR or RSYNC or whatever the secondaries use. it depends on axfr. the thing it isn't compatible with is the various private multimaster implementations. there's no call for zone file access. From owner-namedroppers@ops.ietf.org Thu Aug 19 12:03: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 CFE123A68D0; Thu, 19 Aug 2010 12:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.974 X-Spam-Level: X-Spam-Status: No, score=-108.974 tagged_above=-999 required=5 tests=[AWL=0.121, 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, 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 MC+2fCBJmRb7; Thu, 19 Aug 2010 12:03:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9AC4A3A6842; Thu, 19 Aug 2010 12:03:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmALn-0009fN-FF for namedroppers-data0@psg.com; Thu, 19 Aug 2010 19:00:31 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmALk-0009ee-I0 for namedroppers@ops.ietf.org; Thu, 19 Aug 2010 19:00:28 +0000 Received: (qmail 12082 invoked from network); 19 Aug 2010 19:00:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=2euOO6NY0ooH23xxvSbPXOQoMcDwbzWrqlpMdhDE11c=; b=hOjdgX31RcEnBPZ9JoAQkrtDbPvxE4IlKc1OQEHbWghbybl3xEU54/l323WEZFVsoOD8t7OaH3Av7QofsxTEpLrunfBP1XMeXUX9GsewDIHfmaf8f4Pv2fR4nT6T8XpHoCT/6YiGKNKWEECDXAQBBrwI9AG162tSG5ycH8BMZzU= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Aug 2010 19:00:05 -0000 Date: 19 Aug 2010 15:00:26 -0400 Message-ID: From: "John R. Levine" To: "Paul Vixie" Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? In-Reply-To: <22590.1282242926@nsa.vix.com> References: <20100819181005.47680.qmail@joyce.lan> <22590.1282242926@nsa.vix.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: >> The proposed implementation is hopeless, since the assumption that >> secondaries work from copies of a master's zone file is usually wrong. >> I'd want the SHADOW info to be in the zone itself, so it gets copied >> using AXFR or RSYNC or whatever the secondaries use. > > it depends on axfr. the thing it isn't compatible with is the various > private multimaster implementations. there's no call for zone file access. I must be missing something. If I get a copy of the zone by AXFR, how can I tell whether a name was fully or partially qualified in the master file so I know whether to copy it or shadow it? R's, John From owner-namedroppers@ops.ietf.org Thu Aug 19 12:11: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 476073A69E3; Thu, 19 Aug 2010 12:11:18 -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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzHArmNEvFPe; Thu, 19 Aug 2010 12:11:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F7CC3A698E; Thu, 19 Aug 2010 12:11:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmAT5-000ApQ-49 for namedroppers-data0@psg.com; Thu, 19 Aug 2010 19:08: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.72 (FreeBSD)) (envelope-from ) id 1OmASx-000AoX-Pf for namedroppers@ops.ietf.org; Thu, 19 Aug 2010 19:07:55 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 69EFAA101E; Thu, 19 Aug 2010 19:07:55 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "John R. Levine" cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? In-Reply-To: Your message of "19 Aug 2010 15:00:26 -0400." References: <20100819181005.47680.qmail@joyce.lan> <22590.1282242926@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 19 Aug 2010 19:07:55 +0000 Message-ID: <24409.1282244875@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: 19 Aug 2010 15:00:26 -0400 > From: "John R. Levine" > > I must be missing something. If I get a copy of the zone by AXFR, how can > I tell whether a name was fully or partially qualified in the master file > so I know whether to copy it or shadow it? this is an open issue. see 4.1. From owner-namedroppers@ops.ietf.org Thu Aug 19 13:06: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 579043A6943; Thu, 19 Aug 2010 13:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.15 X-Spam-Level: X-Spam-Status: No, score=-95.15 tagged_above=-999 required=5 tests=[AWL=-1.999, 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 mnRf3kY+OuZF; Thu, 19 Aug 2010 13:06:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0BB3F3A68D4; Thu, 19 Aug 2010 13:06:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmBHp-000HRm-MM for namedroppers-data0@psg.com; Thu, 19 Aug 2010 20:00:29 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmBHl-000HR5-Ve for namedroppers@ops.ietf.org; Thu, 19 Aug 2010 20:00:26 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA259927882; Thu, 19 Aug 2010 21:58:02 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA24285; Thu, 19 Aug 2010 21:58:01 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201008191958.VAA24285@TR-Sys.de> Subject: Re: [dnsext] Problem with Section 2.2 of RFC 4035 To: wouter@NLnetLabs.nl Date: Thu, 19 Aug 2010 21:58:01 +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: Wouter, I agree with most parts of your detailed analysis (http://ops.IETF.ORG/lists/namedroppers/namedroppers.2010/msg02286.html), but the final conclusion that the DS "swap" could easily happen in one step seems inappropriate. Already the seminal tutorial paper from M. Rose on DNSSEC algorithm rollover quoted earlier in this thread [*] has pointed out that between the addition of the first "new" DS and the removal of the last "old" DS, there will be most likely the longest period in the whole procedure -- to be measured in years perhaps (M. Rose quotes expected time spans of 3-6 years), so there will likely happen multiple full (per-algorithm) rekey events in between. This period is needed for "new" verifier releases to be deployed. M. Rose recommends waiting for two major software update cycles to happen for all major resolver/verifier implementations before withdrawing the "old" DS (and subsequently the "old" key and signatures). The roughly four-fold DNSSEC payload in responses during rekey phases during algorithm rollover seems to be, from an operational and stability point of view, the most important argument for avoiding such algorithm rollover entirely -- whenever possible, and hence reinforcing the recommendation to start with stronger algorithms from the beginning if you start deploying DNSSEC in a zone now, although there might not be cryptanalytical reasons to do so. Kind regards, Alfred. [*] http://www-x.antd.nist.gov/dnssec/download/DNSSEC_Algorithm_rollover.pdf From owner-namedroppers@ops.ietf.org Thu Aug 19 13:52: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 18D773A6859; Thu, 19 Aug 2010 13:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.963 X-Spam-Level: X-Spam-Status: No, score=-108.963 tagged_above=-999 required=5 tests=[AWL=0.132, 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, 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 xdsess-IINr9; Thu, 19 Aug 2010 13:52:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3EB3E3A6846; Thu, 19 Aug 2010 13:52:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmC2F-000Nk2-3s for namedroppers-data0@psg.com; Thu, 19 Aug 2010 20:48:27 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmC2C-000NjX-Ez for namedroppers@ops.ietf.org; Thu, 19 Aug 2010 20:48:25 +0000 Received: (qmail 59263 invoked from network); 19 Aug 2010 20:48:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=HmmdJNKT6RnKrgjn1fJcRiAWKrgXH6OLnDnFG7bEb9w=; b=ehVFAhPveoNizE/cKMGQpEArzI+IuGomMest6ywFRWHjB9t3JFYiRRq+RFFyqn7KMDa8FF8H1gN7WX884LRdg42/vPLqD5MqPaoYjMSkQtXLASHvhYBtoFQknXWAG/Ji6nhK572dXZvQqbph+i2cceNayd19tLstwwcERQCvI9I= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Aug 2010 20:48:00 -0000 Date: 19 Aug 2010 16:48:22 -0400 Message-ID: From: "John R. Levine" To: "Paul Vixie" Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? In-Reply-To: <24409.1282244875@nsa.vix.com> References: <20100819181005.47680.qmail@joyce.lan> <22590.1282242926@nsa.vix.com> <24409.1282244875@nsa.vix.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: >> I must be missing something. If I get a copy of the zone by AXFR, how can >> I tell whether a name was fully or partially qualified in the master file >> so I know whether to copy it or shadow it? > > this is an open issue. see 4.1. Right, hence my suggested hack to resolve it. R's, John From owner-namedroppers@ops.ietf.org Thu Aug 19 16:47: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 0554E3A68DC; Thu, 19 Aug 2010 16:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 3lZPdm1o4EdN; Thu, 19 Aug 2010 16:47:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7323E3A687D; Thu, 19 Aug 2010 16:47:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmEkF-000Hpc-Nu for namedroppers-data0@psg.com; Thu, 19 Aug 2010 23:42: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.72 (FreeBSD)) (envelope-from ) id 1OmEkD-000HpO-4m for namedroppers@ops.ietf.org; Thu, 19 Aug 2010 23:42:01 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 18F65A1019; Thu, 19 Aug 2010 23:42:00 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "John R. Levine" cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? In-Reply-To: Your message of "19 Aug 2010 16:48:22 -0400." References: <20100819181005.47680.qmail@joyce.lan> <22590.1282242926@nsa.vix.com> <24409.1282244875@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 19 Aug 2010 23:42:00 +0000 Message-ID: <39785.1282261320@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: 19 Aug 2010 16:48:22 -0400 > From: "John R. Levine" > > > this is an open issue. see 4.1. > > Right, hence my suggested hack to resolve it. do you feel that the proposal is worthless without such a resolution? from my point of view, a transformation that only works on owner names is adequate, and a transformation that works on tail-replace of both owner names and target names would also be acceptable. i'm not in love with the idea of a knob for this kind of per-name rewrite capability on day 1. From owner-namedroppers@ops.ietf.org Thu Aug 19 17: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 31F6D3A68E7; Thu, 19 Aug 2010 17:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.967 X-Spam-Level: X-Spam-Status: No, score=-108.967 tagged_above=-999 required=5 tests=[AWL=0.128, 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, 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 W5KhM-zXXoJz; Thu, 19 Aug 2010 17:02:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8C1DA3A6359; Thu, 19 Aug 2010 17:02:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmF11-000JXt-Dx for namedroppers-data0@psg.com; Thu, 19 Aug 2010 23:59:23 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmF0y-000JXb-L8 for namedroppers@ops.ietf.org; Thu, 19 Aug 2010 23:59:20 +0000 Received: (qmail 29577 invoked from network); 19 Aug 2010 23:59:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=yugzANqsntEcRapwVDCyUDvZMQjS5sVaqw1B38YvNAc=; b=JXPuQKING4gLc5FEByJlEVSBeIY2Q1Gwbzl99wl2tEzJNyXNnZxRYdNHO6udWTnibyJnlB1Gg5V//+39kK+galalj44Id+I2huv3wiU9qnIubIMT0vPNnusiefscTYD6eMjeABi54eB4RqQwiqK5StsIkfu0qVjeDgU6awNm+oo= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Aug 2010 23:58:56 -0000 Date: 19 Aug 2010 19:59:18 -0400 Message-ID: From: "John R. Levine" To: "Paul Vixie" Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? In-Reply-To: <39785.1282261320@nsa.vix.com> References: <20100819181005.47680.qmail@joyce.lan> <22590.1282242926@nsa.vix.com> <24409.1282244875@nsa.vix.com> <39785.1282261320@nsa.vix.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: >> Right, hence my suggested hack to resolve it. > > do you feel that the proposal is worthless without such a resolution? > > from my point of view, a transformation that only works on owner names is > adequate, and a transformation that works on tail-replace of both owner > names and target names would also be acceptable. i'm not in love with > the idea of a knob for this kind of per-name rewrite capability on day 1. It seems to me that if it doesn't offer some way to handle the exceptions we all know we need, it's basically the same as DNAME, where the name server generates an exact clone of a zone under a different name. Fixing the names of mail servers actually isn't all that important since mail servers don't need to have unique names. Adjusting A records for HTTPS servers is essential because people who run them aren't going to run out and get upgraded server software and buy combined multi-name certs just because we tell them to. (The places where I buy my certs do not, as far as I can tell, even offer them.) I'm certainly not arguing that my list of hacks is ideal, but for SHADOW to be useful, it needs some way to solve the problems that now can only be dealt with by local provisioning hacks. All of the prior approaches seem to me to fail catastrophically in the sense that even if they do 95% of what you want them to do, you still can't use them because they don't provide any way to do the other 5%. R's, John From owner-namedroppers@ops.ietf.org Thu Aug 19 17:24: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 9108C3A6A0A; Thu, 19 Aug 2010 17:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.962 X-Spam-Level: X-Spam-Status: No, score=-3.962 tagged_above=-999 required=5 tests=[AWL=-0.663, 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 ypPorTjOW3PV; Thu, 19 Aug 2010 17:24:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 70BA83A6907; Thu, 19 Aug 2010 17:24:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmFLV-000Lp8-32 for namedroppers-data0@psg.com; Fri, 20 Aug 2010 00:20:33 +0000 Received: from [131.111.8.131] (helo=ppsw-31.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmFLS-000Log-29 for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 00:20:30 +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]:53300) by ppsw-31.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1OmFLK-0001GO-JM (Exim 4.72) (return-path ); Fri, 20 Aug 2010 01:20:22 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OmFLJ-0005vM-Vf (Exim 4.67) (return-path ); Fri, 20 Aug 2010 01:20:21 +0100 Date: Fri, 20 Aug 2010 01:20:21 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "John R. Levine" cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? In-Reply-To: Message-ID: References: <20100819181005.47680.qmail@joyce.lan> <22590.1282242926@nsa.vix.com> <24409.1282244875@nsa.vix.com> <39785.1282261320@nsa.vix.com> 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 Fri, 19 Aug 2010, John R. Levine wrote: > > It seems to me that if it doesn't offer some way to handle the exceptions we > all know we need, it's basically the same as DNAME, where the name server > generates an exact clone of a zone under a different name. No, because DNAME requires manual cloning of the zone apex, and extra DNSSEC management, and it introduces synthetic CNAME RRs. But I agree that IE6's lack of SNI support and lack of CA support for useful x.509 features are problems. > I'm certainly not arguing that my list of hacks is ideal, but for SHADOW to be > useful, it needs some way to solve the problems that now can only be dealt > with by local provisioning hacks. Does it need to solve these problems? BNAME does not and SHADOW is still simpler. Tony. -- f.anthony.n.finch http://dotat.at/ FITZROY: VARIABLE 4 IN SOUTHEAST, AND FOR A TIME IN FAR NORTHWEST, OTHERWISE SOUTHWESTERLY 5 TO 7. MODERATE OR ROUGH. RAIN. GOOD, OCCASIONALLY POOR. From owner-namedroppers@ops.ietf.org Thu Aug 19 19:00: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 B8D133A698D; Thu, 19 Aug 2010 19:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.969 X-Spam-Level: X-Spam-Status: No, score=-108.969 tagged_above=-999 required=5 tests=[AWL=0.126, 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, 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 a04KmFLIZpRK; Thu, 19 Aug 2010 19:00:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 04E633A691A; Thu, 19 Aug 2010 19:00:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmGpB-0005x2-F6 for namedroppers-data0@psg.com; Fri, 20 Aug 2010 01:55:17 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmGp8-0005wg-6k for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 01:55:15 +0000 Received: (qmail 67400 invoked from network); 20 Aug 2010 01:55:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=edtpdcuAEJd5c71+ioW87p71/mx4WAma+3WXf8QfbJ0=; b=dl3vaVkQUxLQarRXZqVar+1nMOCbCDOjrGkE7R7OkA0dZCL9xAsq1GSnVl77+XgjefA0VcJ+BoaQv+jIGBDaPLChJ56FYh496bcdqWQl4J6b6PCSVVJ4sZ2b5l9VPEXabJNjbCER+rRmiAttCs1VNmFJZwD16VFiqFM1jDRXMr4= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Aug 2010 01:54:50 -0000 Date: 19 Aug 2010 21:55:12 -0400 Message-ID: From: "John R. Levine" To: "Tony Finch" Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? In-Reply-To: References: <20100819181005.47680.qmail@joyce.lan> <22590.1282242926@nsa.vix.com> <24409.1282244875@nsa.vix.com> <39785.1282261320@nsa.vix.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: >> I'm certainly not arguing that my list of hacks is ideal, but for SHADOW to be >> useful, it needs some way to solve the problems that now can only be dealt >> with by local provisioning hacks. > > Does it need to solve these problems? BNAME does not and SHADOW is still > simpler. I can only speak for myself, but I'm not going to use BNAME or XNAME or SHADOW if it can't generate the records I need in the shadow zone. That can't be unusual. R's, John From owner-namedroppers@ops.ietf.org Thu Aug 19 20:24: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 A037F3A635F; Thu, 19 Aug 2010 20:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.37 X-Spam-Level: * X-Spam-Status: No, score=1.37 tagged_above=-999 required=5 tests=[AWL=1.864, 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 Yt6IYN9z6WM8; Thu, 19 Aug 2010 20:24:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B72E3A6781; Thu, 19 Aug 2010 20:24:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmI8w-000F1k-J0 for namedroppers-data0@psg.com; Fri, 20 Aug 2010 03:19:46 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmI8t-000F0J-9A for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 03:19:43 +0000 Received: by fxm10 with SMTP id 10so1879634fxm.11 for ; Thu, 19 Aug 2010 20:19:41 -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; bh=BUB+BJ+S0NsJZKjJpF1/YRYfBabOZePymV8uVwwzWHM=; b=tBilFNBK9dYauSq/xLXXXCmItHp24NurJC6yPcCRccF+nvLyzMIWjoKbgsxXFXKcbf HRa3MTuT8P9+cgexjI5jTktCmde9YlCTWlsF54vV2SWxWT6WrS1piIYQ5DuNOUrQMgqC hbefFNYNV3hxihMwZBBtx1a32jntHPDx8nRs0= 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=CWBWAdD/CIVC4QlvcUuTgbi/OrZW7kW7IpYKrBYfdBqV1NTLiII+ze7G4RKQjSxWhX 0xd96jfdcKlAbib0whnEkGc7W2UyQCp9UZEIfx0lbcvig5q6NHqL5SZUUTwfLxmoefjo uEzv2uOafbkGFYFN0vj1gZhrl1/gwqQuaT3Kg= MIME-Version: 1.0 Received: by 10.223.119.136 with SMTP id z8mr568863faq.63.1282274381011; Thu, 19 Aug 2010 20:19:41 -0700 (PDT) Received: by 10.223.126.138 with HTTP; Thu, 19 Aug 2010 20:19:40 -0700 (PDT) In-Reply-To: References: <20100819181005.47680.qmail@joyce.lan> <22590.1282242926@nsa.vix.com> <24409.1282244875@nsa.vix.com> <39785.1282261320@nsa.vix.com> Date: Fri, 20 Aug 2010 00:19:40 -0300 Message-ID: Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? From: Brian Dickson To: "John R. Levine" Cc: Tony Finch , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=001636c5a8ddfc1e83048e38c41f Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001636c5a8ddfc1e83048e38c41f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 19, 2010 at 10:55 PM, John R. Levine wrote: > I'm certainly not arguing that my list of hacks is ideal, but for SHADOW to >>> be >>> useful, it needs some way to solve the problems that now can only be >>> dealt >>> with by local provisioning hacks. >>> >> >> Does it need to solve these problems? BNAME does not and SHADOW is still >> simpler. >> > > I can only speak for myself, but I'm not going to use BNAME or XNAME or > SHADOW if it can't generate the records I need in the shadow zone. That > can't be unusual. > > It might be helpful to dissect what a typical set of zones would need to look like, and/or what elements underneath a zone would need to exist and/or differ based on the parent name. I'll take a stab at it, and see if it's possible to accommodate those needs while still benefiting from the strengths of BNAME/xNAME/SHADOW... zone a.b.example.com aka c.d.example.com aka e.b.example.com aka f.example.com (the usual apex stuff - SOA bits, NS, plus DNSKEYs, perhaps MX records) x A 10.20.30.40 ; HTTP server for all names x.* y NS my.own.ip.address ; zone cuts for all names y.* zone y.a.b.example.com (standard apex stuff) A 10.20.30.41 ; HTTPS server for only this y zone y.c.d.example.com (standard apex stuff) A 10.20.30.42 ; HTTPS server for only this y zone y.e.b.example.com (standard apex stuff) A 10.20.30.43 ; HTTPS server for only this y zone y.f.example.com (standard apex stuff) A 10.20.30.44 ; HTTPS server for only this y I think this scales reasonably well, and is easy enough to build tools for, automate, document, and maintain. Think of the first portion as kind of a template, and the remainders as overlays to that template. Does this example match what you believe the usual needs of folks? Do you think this would be something you would/could/would want to use? Thanks, Brian --001636c5a8ddfc1e83048e38c41f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 19, 2010 at 10:55 PM, John R. Le= vine <johnl@iecc.com= > wrote:
I'm certainly not arguing that my list of hacks is ideal, but for SHADO= W to be
useful, it needs some way to solve the problems that now can only be dealt<= br> with by local provisioning hacks.

Does it need to solve these problems? BNAME does not and SHADOW is still simpler.

I can only speak for myself, but I'm not going to use BNAME or XNAME or= SHADOW if it can't generate the records I need in the shadow zone. =A0= That can't be unusual.



It might be helpful to dissect what a typical= set of zones would need to look like, and/or what elements underneath a zo= ne would need to exist and/or differ based on the parent name.

I'll take a stab at it, and see if it's possible to accommodate tho= se needs while still benefiting from the strengths of BNAME/xNAME/SHADOW...=

zone a.b.example.com
aka = c.d.example.com
aka e.b.example.com
aka f.example.com
(the usual apex stuff - SOA = bits, NS, plus DNSKEYs, perhaps MX records)
x =A0 A=A0 10.20.30.40 ; HTT= P server for all names x.*
y=A0 NS my.own.ip.address ; zone cuts for all names y.*

zone y.a.b.example.com
(standard apex stuf= f)
=A0 A=A0 10.20.30.41 ; HTTPS server for only this y

zone y.c.d.example.com
(standard apex stuff)
=A0 A=A0 10.20.30.42 ; HTTPS server for only this = y

zone y.e.b.example.com(standard apex stuff)
=A0 A=A0 10.20.30.43 ; HTTPS server for only this= y

zone y.f.example.com
(standar= d apex stuff)
=A0 A=A0 10.20.30.44 ; HTTPS server for only this y

I think this scales reasonably well, and is easy enough to build tools= for, automate, document, and maintain.
Think of the first portion as kind of a template, and the remainders as ove= rlays to that template.

Does this example match what you believe the= usual needs of folks?
Do you think this would be something you would/co= uld/would want to use?

Thanks,
Brian

--001636c5a8ddfc1e83048e38c41f-- From owner-namedroppers@ops.ietf.org Thu Aug 19 20:43: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 069C53A67B3; Thu, 19 Aug 2010 20:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 c3mbWsGex1lN; Thu, 19 Aug 2010 20:43:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0863B3A698D; Thu, 19 Aug 2010 20:43:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmITR-000HFB-RP for namedroppers-data0@psg.com; Fri, 20 Aug 2010 03:40:57 +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.72 (FreeBSD)) (envelope-from ) id 1OmITP-000HEp-E7 for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 03:40:55 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 52C0CA1019; Fri, 20 Aug 2010 03:40:54 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "John R. Levine" cc: "Tony Finch" , namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? In-Reply-To: Your message of "19 Aug 2010 21:55:12 -0400." References: <20100819181005.47680.qmail@joyce.lan> <22590.1282242926@nsa.vix.com> <24409.1282244875@nsa.vix.com> <39785.1282261320@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Fri, 20 Aug 2010 03:40:54 +0000 Message-ID: <54594.1282275654@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: 19 Aug 2010 21:55:12 -0400 > From: "John R. Levine" > > I can only speak for myself, but I'm not going to use BNAME or XNAME or > SHADOW if it can't generate the records I need in the shadow zone. That > can't be unusual. ok, let's deal with open issue 4.1 if this approach is generally wanted. From owner-namedroppers@ops.ietf.org Fri Aug 20 00:38: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 DF2773A6A51; Fri, 20 Aug 2010 00:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.753 X-Spam-Level: ** X-Spam-Status: No, score=2.753 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_40=-0.185, 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 clTKg4LR99ln; Fri, 20 Aug 2010 00:38:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 92A923A6A6B; Fri, 20 Aug 2010 00:38:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmM5F-000Hw0-KQ for namedroppers-data0@psg.com; Fri, 20 Aug 2010 07:32:13 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmM5D-000HvH-30 for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 07:32:11 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1OmM54-0007lx-LD; Fri, 20 Aug 2010 07:32:02 +0000 Received: by bfk.de with local id 1OmM54-0005uv-Fo; Fri, 20 Aug 2010 07:32:02 +0000 To: Paul Hoffman Cc: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? References: <20100817200420.GC89703@shinkuro.com> From: Florian Weimer Date: Fri, 20 Aug 2010 07:32:02 +0000 In-Reply-To: (Paul Hoffman's message of "Wed\, 18 Aug 2010 19\:24\:24 -0700") Message-ID: <82fwy9yc25.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Paul Hoffman: > I have read the SHADOW/CLONE draft. I am not sure I like the > specific semantics in this draft, but I suspect that adding > replication directives in a zone file that show up on the wire is > better than just comments in the zone file, As far as I understand it, shadowing a zone (that is, the rewriting required on the master) has to work on the textual representation of the zone, not the wire format ("Content of a Shadow zone will be generated by parsing the Amber zone's master file using a different default $ORIGIN."). A good way around that does not seem to exist. Perhaps you could use a magic TLD or SLD under ARPA, but that's probably not "good", either. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Fri Aug 20 00: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 2B2A33A68E8; Fri, 20 Aug 2010 00:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.571 X-Spam-Level: * X-Spam-Status: No, score=1.571 tagged_above=-999 required=5 tests=[AWL=0.821, 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 NSAZVINkWFMc; Fri, 20 Aug 2010 00:43:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EFFA03A6894; Fri, 20 Aug 2010 00:43:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmMCv-000Iwl-W6 for namedroppers-data0@psg.com; Fri, 20 Aug 2010 07:40:09 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmMCt-000Ivo-G5 for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 07:40:07 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1OmMCp-0000aa-NU; Fri, 20 Aug 2010 07:40:03 +0000 Received: by bfk.de with local id 1OmMCn-0006ty-W4; Fri, 20 Aug 2010 07:40:02 +0000 To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? References: <20100817200420.GC89703@shinkuro.com> From: Florian Weimer Date: Fri, 20 Aug 2010 07:40:01 +0000 In-Reply-To: <20100817200420.GC89703@shinkuro.com> (Andrew Sullivan's message of "Tue\, 17 Aug 2010 16\:04\:20 -0400") Message-ID: <82bp8xybou.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Andrew Sullivan: > We've spilled a lot of 1s and 0s over the question of whether xNAME > will solve enough of the aliasing issues to be worth the cost to the > protocol. I still don't know where the community is heading on that, > but it appears there are people who feel quite strongly (and with good > arguments) that it is _not_ worth the cost. SHADOW actually works as advertized and creates truly equivalent names (as far as I can tell). But as I've tried to explain before, it is impossible to solve the IDNA woes with DNS tweaks because IDNA-aware applications generally lack access to DNS (think email submission), distinct IDNA versions cannot be converted to each other, and an intermediate relay will not always be able to translate a name to an IDNA version which is expected by the recipient server. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Fri Aug 20 07:27: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 B68233A695A; Fri, 20 Aug 2010 07:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 kjnOjrW0PEwg; Fri, 20 Aug 2010 07:27:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9711A3A67B4; Fri, 20 Aug 2010 07:27:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmSTY-000MJB-VK for namedroppers-data0@psg.com; Fri, 20 Aug 2010 14:21: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.72 (FreeBSD)) (envelope-from ) id 1OmSTU-000MIU-N8 for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 14:21:40 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 1082CA1021 for ; Fri, 20 Aug 2010 14:21:40 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? In-Reply-To: Your message of "Fri, 20 Aug 2010 07:32:02 GMT." <82fwy9yc25.fsf@mid.bfk.de> References: <20100817200420.GC89703@shinkuro.com> <82fwy9yc25.fsf@mid.bfk.de> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Fri, 20 Aug 2010 14:21:40 +0000 Message-ID: <90995.1282314100@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: Florian Weimer > Date: Fri, 20 Aug 2010 07:32:02 +0000 > > As far as I understand it, shadowing a zone (that is, the rewriting > required on the master) has to work on the textual representation of > the zone, not the wire format ("Content of a Shadow zone will be > generated by parsing the Amber zone's master file using a different > default $ORIGIN."). yeah, that's weak. and it's noted in the open issues. > A good way around that does not seem to exist. Perhaps you could use a > magic TLD or SLD under ARPA, but that's probably not "good", either. i agree that there's no good way. but paul hoffman's right in my opin: > ... but I suspect that adding replication directives in a zone file that > show up on the wire is better than just comments in the zone file, ... in other words the transformation on the master server should probably be done on FQDN's after all of the zone parsing ($ORIGIN etc) has been done, and should therefore be a tail-replace (.amber -> .shadow) everywhere, including both the owner and target names. because we need to be able to do this transformation even when the zone data source is a database rather than a text file, the exceptions (like, i really want this target name to be what is, and not get the tail-replace) would have to be expressed via some metadata (which a database source could also have) rather than via "zone file" directives (which only a zone file source would have.) john levine suggested: A SHADOW COPY S ... N SHADOW LIT RR ... N SHADOW LOCAL RR which is not my preferred approach (syntactically or semantically) but does demonstrate the approach i'm describing (in-zone data, not file directives.) in any case we can treat this as a work item if we adopt this approach. at the moment it's not worth our time or this mailing list's bandwidth to try to fix this stuff, since the WG hasn't reached consensus on the basic SHADOW approach. if we do reach that consensus, nothing i've heard on this thread would be a showstopper as far as fixing it before it reaches the RFC editor. From owner-namedroppers@ops.ietf.org Fri Aug 20 07:29: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 4CBAB3A6A77; Fri, 20 Aug 2010 07:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 x5oFCW69lsZI; Fri, 20 Aug 2010 07:29:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7CF833A68C5; Fri, 20 Aug 2010 07:29:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmSYs-000N6o-DL for namedroppers-data0@psg.com; Fri, 20 Aug 2010 14:27: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.72 (FreeBSD)) (envelope-from ) id 1OmSYn-000N64-U2 for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 14:27:09 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 93B32A103E for ; Fri, 20 Aug 2010 14:27:09 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? In-Reply-To: Your message of "Fri, 20 Aug 2010 07:40:01 GMT." <82bp8xybou.fsf@mid.bfk.de> References: <20100817200420.GC89703@shinkuro.com> <82bp8xybou.fsf@mid.bfk.de> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Fri, 20 Aug 2010 14:27:09 +0000 Message-ID: <91386.1282314429@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: Florian Weimer > Date: Fri, 20 Aug 2010 07:40:01 +0000 > > SHADOW actually works as advertized and creates truly equivalent names > (as far as I can tell). > > But as I've tried to explain before, it is impossible to solve the IDNA > woes with DNS tweaks because IDNA-aware applications generally lack > access to DNS (think email submission), distinct IDNA versions cannot be > converted to each other, and an intermediate relay will not always be > able to translate a name to an IDNA version which is expected by the > recipient server. if we need to solve IDNA woes with DNS tweaks, then it is possible, as long as we're willing to require that IDN-aware applications be changed. i'm thinking we could add some more backpointers (similar to what PTR does, but without some of PTR's limitations) and teach IDN-aware apps and servers how to query for the new backpointers. "tell me all the other ways this same name can be reached in DNS" would be a new feature, which IDN-aware apps would use to solve their DNS-related woes. i agree that it's impossible to solve these IDN-related woes transparently and with only DNS-tweaks and no application changes. we need to get the whole WG to consensus on that point so that we can all move forward on that shared basis. and if the IDN community isn't then willing to use new DNS features to solve their woes, then we should stop talking about adding new DNS features for IDN. but i don't think the IDN community will speak with one voice on that matter. and i don't think BNAME and SHADOW are limited to IDN in their usefulness. i'd like both, with or without IDN as a motivator. From owner-namedroppers@ops.ietf.org Fri Aug 20 09:22: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 535AA3A6958; Fri, 20 Aug 2010 09:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.336 X-Spam-Level: X-Spam-Status: No, score=-98.336 tagged_above=-999 required=5 tests=[AWL=-2.536, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6, 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 CgMYM+cYt+HV; Fri, 20 Aug 2010 09:22:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF0473A6937; Fri, 20 Aug 2010 09:22:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmUIO-000FmD-H0 for namedroppers-data0@psg.com; Fri, 20 Aug 2010 16:18:20 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmUIK-000Flo-9u for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 16:18:16 +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 56D771ECB408 for ; Fri, 20 Aug 2010 16:18:14 +0000 (UTC) Date: Fri, 20 Aug 2010 12:18:12 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft minutes for IETF 78 Message-ID: <20100820161811.GD96071@shinkuro.com> References: <20100810205452.GC54011@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20100810205452.GC54011@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: Having received no corrections, we'll submit these as the minutes for the sessions. Thanks again to the scribes. A On Tue, Aug 10, 2010 at 04:54:52PM -0400, Andrew Sullivan wrote: > Dear colleagues, >=20 > Attached are minutes for the meetings of the WG at IETF 78, for > comment. IF you wish to make corrections, please send mail to the > list or directly to me. >=20 > Best regards, >=20 > Andrew >=20 > --=20 > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > Minutes of the DNS Extensions Working Group meetings > IETF 78: Maastricht, NL. >=20 > Meeting dates:=20 > 2010-07-26. Minutes prepared by Mark Mcfadden > 2010-07-28. Minutes prepared by Paul Hoffman. >=20 > Chairs' note: >=20 > These minutes are in radically different styles. The first > covers action to come from the meeting and contains less of > the discussion. The second covers the discussion and contains > few actions to come. This is because the goals of the two > meetings were different, so the styles are appropriate. >=20 > =3D=3D=3D=3D Session I -- 2010-07-26 =3D=3D=3D=3D=3D > =3D=3D=3D=3D The chairs thank Mark Mcfaddon =3D=3D=3D=3D >=20 > Action Items for DNSEXT - 2010 07 26 >=20 > Existing item: RFC 2671bis >=20 > Existing item: RFC 2672bis-dname > - needs more text and should go back to the list > - intent for this to be last-called again. >=20 > Existing item: dnssec-registry-fixes > - a new document will show up soon and thus there is no discussion in the= WG > - process issue will be dealt with a discussion on the list when there is= a new version >=20 > Existing item: draft-ietf-dnsext-dnssec-bis-updates > - small number of hums for the "roll over and die" text is not okay and n= o hums for the text is okay > - observation: few seem to have read the draft > - demonstration of the "roll over and die" behaviour was given > - CD-bit handling: nobody objected to having a default - unlike the two p= eople on the mailing list > - CD-bit handling: propose "Always set" as the default - nobody objected = to this proposal > - CD-bit handling: this proposal will be taken to the list > - CD-bit handling: the intent is to last call this document in short order >=20 > Proposed new major work item: "aliasing", "synonymy", &c. >=20 > - BNAME, C+DNAME, other ideas. > - discussion: should we do one of these regardless of the situation with = IDN? > - discussion: is this a solution for an existing problem, or a general ap= proach that might be of use for many problem=20 >=20 > definitions. > - discussion: it is possible to do this through provisioning rather than = through protocol changes. > - discussion: C+DNAME testing by Ondrej Sury - fundamentally works proper= ly in a test zone; with some known problems > - observation: are there are problems that cannot be solved by either of = these solutions? There appears to be a list that=20 >=20 > will be provided to the mailing list > - Observation: some resolvers do not support DNAME > - Sense of the room: 2/3 of the room had read BNAME, C+DNAME, and Shadow = Drafts > - Sense of the room: 1/3 of the room had read the Problem Statement draft >=20 > - Shadow zones =20 > o draft-vixie-dnsext-dnsshadow-00 > - agreement: shadow does have utility outside of BNAME and C+DNAME > - discussion: seems to be some disagreement over whether or not to do thi= s work > - action: whether or not to proceed on Shadow Zones will go to the mailin= g list >=20 > - Rationale/applicability. =20 > o draft-yao-dnsext-identical-resolution-01 > - discussion: Suzanne Wolff presented an overview of the probglem stateme= nt draft and its goals >=20 > Proposed new charter. >=20 > - The proposed charter was posted to the mailing list: =20 > http://www.psg.com/lists/namedroppers/namedroppers.2010/msg01836.html >=20 > - Sense of the room: Could the work be moved earlier? two hands only Cou= ld not? two hands only > - Discussion: implementation is separate from making decisions about what= work to do in the WG > - Rough consensus: move the dates up compared to the original draft prepa= red with the charter > - Action Item: chairs will prpoduce another draft and send that to the IE= SG >=20 > Returning work items. >=20 > draft-crocker-dnssec-algo-signal-06 > - In Stockholm last year, Patrik Faltstrom determined that this document = would be needed if and only if something like=20 >=20 > draft-ietf-dnsext-dnssec-alg-allocation were published. Since that is ab= out to happen, this document appears to be up for=20 >=20 > adoption. =20 > - Patrik has agreed to be shepherd. > - Rough consensus: No objection to the arrangements for moving this docum= ent forward >=20 > Additional work items. >=20 > IXFR-only: draft-kerr-ixfr-only-01 > - Rough consensus: not proceed with this work, replace it with a larger d= ocument with more material (15 September or=20 >=20 > proceed witht the current draft) >=20 > DNSCURVE draft: draft-dempsky-dnscurve-01 > - Supporters of the document need to come up with timelines > - Consensus needs to be reached on the objections to adopting the document > - Consensus by the 15 of Sepatember or this will default to a WG document >=20 > URI DNSRR: draft-faltstrom-uri-05 > - Don't need to adopt this in the Working Group because it is going throu= gh the expert review process >=20 >=20 > =3D=3D=3D=3D Session II -- 2010-07-28 =3D=3D=3D=3D > =3D=3D=3D=3D The chairs thank Paul Hoffman =3D=3D=3D=3D >=20 > DNSEXT > Wednesday morning, 2010-07-28 > Andrew Sullivan and Olafur Gudmundsson > Minutes taken by Paul Hoffman > Things from the slides not copied here > You must read the slides to get more details >=20 > Goal of this meeting: see if we are on the right track with the aliasing = work we might add to the charter >=20 > Andrew's introduction to the meeting > What we have today > CNAME and DNAME > Second-class citizens > Cannot be the target of an MX record > Some people think (wrongly) that we already have aliasing finished > Proposals so far > CNAME+DNAME > Many recursive servers don't do DNAME today > BNAME > SHADOW > Provisioning > Currently has deployment and usability issues > Many people have said that "just provision" is not viable > May not have the same folks administering the two sides > Lots of things are out of scope > All solutions will have some problems > "First class citizen" issues for all of current proposals > Purpose: to collect use cases >=20 > Olaf Kolkman: does the "don't do anything" come under that header > John Klensin: user community thinks that it has names that are equivalent > Based on Unicode rules that say two spellings are equivalent > One needs a pair of names (equal and symmetric) > Real aliases > Can be at any level > Some people wants to ask about both names > CNAMEs pointing in both directions: heads explode > Andrew: is this about a character-to-character maps? > John: that's only part of it: it is really label-to-label > Related: changing the matching rules > You made these ASCII labels match, make my language match the same way > Antoin Verschuren: design of the DNS it self > Worried if we are going to design something with aliases for nodes in th= e system > Becomes a web, not a tree: bad > Only work if the aliases are for outside the DNS > Ond=1Aej Sur=1A: which solutions need signalling? > BNAME needs signalling, CNAME+DNAME doesn't > Andrew: maybe both do > Harald Alvestrand: most common use case for "we want these two be the sam= e" is the web > If everything is friendly, we don't need the DNS > There are lots of ifs > Someone owning a higher-level zone want to tell people in lower zones ho= w to do things > Maybe easier for the top to do things correctly underneath than having a= ll the bottom pieces do it right > Aliases can be helpful, but is neither necessary nor sufficient; makes t= hings a good bit simpler > Towards John: I don't have any idea what "equal" means > John: if we optimize for the web, we are making a bad decision > EAI means we will see a whole new domain of use cases > From Phill Hallam-Baker on Jabber: > We need to do the shadow approach > Same fixes needed for shadow will be needed for the other solutions as w= ell > John: making lots of assumptions of what applications need > I thought that we were not cutting things off here > Doug Barton on Jabber: > What is the use cases for equivalence? > John: Unicode is a mixture of legacy scripts that made a strange mixture > People type on keyboards (input method editors) > Easy to get different characters from similar users > Can type things the same that look the same on the screen, they might n= ot match > Spelling cases of different sorts: color vs. colour > Lots of divergence even in one spoken language > When normal people look at them, they see the same things > Expectation that computers will fix this > Suzanne Woolf: we need more examples on the mailing list in order to full= y develop the problem statement > Ond=1Aej: equivalence of two labels doesn't need to be equivalence in the= DNS > Can make a framework that will work elsewhere, not in the DNS > Andrew: can have the underlying DNS layer and a different layer where th= ey are looked up > Ond=1Aej: you already have that in other layers: Apache handles this > Andrew: mail server has this problem > Ond=1Aej: can relax the rule for mail servers > Andrew: the mail specifications are outside our scope > Paul Hoffman: you can choose them to be > Andrew: there is tension between working groups > Ond=1Aej: you just need to be careful what your target is pointing to > Andrew: see what Harald said earlier: the entire tree issue > People down the tree won't know that they are in an alias > Suppose we have two input methods: can't know you are inside an aliase = tree > Ond=1Aej: If you are there, you can't change anything anyway > This is just one more place where things go wrong if you do them wrong > John: when we first looked at IDNs, one conclusion was that we couldn't d= o this fully in DNS > This is a descendent from before > Some decided either DNSNG or something else that did mapping > Design systems princidple is where you draw the line > Instead of keep kludging in the DNS, consider doing one of those options > Could have different deployment options between them > Maybe say "at this level of DNS abuse, we must stop" > Paul: we tried to work on some of these, but there was no user interest > John: if we have something that almost works, we can't start work on som= ething that might be better > But we might be approaching "the current stuff doesn't work" > Andrew: what are the weird effect > John: if the user hears "x is equivalent to y", they think "everyplace I= use x I can use y" > Also "I can find y if I look up x" > Pure trees are lousy for human knowledge and queries > Have to careful with cross-tree pointers > Andrew: send this to Suzanne > Olaf: what is the timescales in which we need solutions > Different time scales might allow kludges or might force real solutions > Adding kludges to a point where you making a promised that it will be a = workable solution: > You wasted time and energy > Yao Jiankang: the problem is that the user says domain a and domain b are= equal > Thus they want same resolution > Harald: domains will be declared equal whether we like it or not > Question is: will doing standards work in the IETF make life better or w= orse > Alfred H?nes: the DNS is tree structured > You can't have true equivalence in a tree > Some points will be first class > Only solution is the have replication > All examples from Unicode show only the registrant can decide what is eq= uivalent to what they registered > We might be able to capture what the registrant wants equivalent > We need a canonical form for correctness: DNSSEC > We need a canonical form to avoid combinational explosion at multiple le= vels of the tree > Pointers to the canonical form > Olafur asks questions: > Apps folks: do the proposals help here: not enough information, no one s= aid yes, some said no > Timeline: this is in the next few weeks > Get your examples to us soon that --=20 Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Aug 20 09:26: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 B49F23A6AA7; Fri, 20 Aug 2010 09:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.202 X-Spam-Level: X-Spam-Status: No, score=-100.202 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 bsutHDGg3GGq; Fri, 20 Aug 2010 09:26:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ACB6C3A6937; Fri, 20 Aug 2010 09:26:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmUO1-000Ga1-4A for namedroppers-data0@psg.com; Fri, 20 Aug 2010 16:24:09 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmUNz-000GZX-0x for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 16:24: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 07FAE1ECB408 for ; Fri, 20 Aug 2010 16:24:04 +0000 (UTC) Date: Fri, 20 Aug 2010 12:24:03 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? Message-ID: <20100820162403.GE96071@shinkuro.com> References: <20100819181005.47680.qmail@joyce.lan> <22590.1282242926@nsa.vix.com> <24409.1282244875@nsa.vix.com> <39785.1282261320@nsa.vix.com> <54594.1282275654@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54594.1282275654@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: On Fri, Aug 20, 2010 at 03:40:54AM +0000, Paul Vixie wrote: > ok, let's deal with open issue 4.1 if this approach is generally wanted. Before tackling that, I'd really like to see the list of problems in the problem statement document (that Suzanne is currently editing) updated. Please send text on what problems there are here. W -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dnsext-archive@ietf.org Fri Aug 20 09: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 DE34D3A6912 for ; Fri, 20 Aug 2010 09:41:46 -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 Official ; Fri, 20 Aug 2010 09:41:40 -0700 (PDT) Received: from 122-126-127-83.dynamic.hinet.net (122-126-127-83.dynamic.hinet.net [122.126.127.83]) by core3.amsl.com (Postfix) with SMTP id 219163A695B for ; Fri, 20 Aug 2010 09:41:38 -0700 (PDT) Received: (qmail 2949 by uid 829); Fri, 20 Aug 2010 16:19:44 +0400 Message-Id: <20100821004157.2602.qmail@122-126-127-83.dynamic.hinet.net> From: USA VIAGRA ® Official To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org VIAGRA ® Official Seller -84% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Fri, 20 Aug 2010 09:41:38 -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 All rights reserved.
From owner-namedroppers@ops.ietf.org Fri Aug 20 10:26: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 E39B93A6AF4; Fri, 20 Aug 2010 10:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.359 X-Spam-Level: X-Spam-Status: No, score=-99.359 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, 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 H-zxq0gSziBy; Fri, 20 Aug 2010 10:26:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 118FA3A6AF1; Fri, 20 Aug 2010 10:26:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmVIS-000PvU-Qq for namedroppers-data0@psg.com; Fri, 20 Aug 2010 17:22:28 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmVIQ-000Puv-Ct for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 17:22:26 +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 o7KHMNXs072440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Aug 2010 10:22:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100820162403.GE96071@shinkuro.com> References: <20100819181005.47680.qmail@joyce.lan> <22590.1282242926@nsa.vix.com> <24409.1282244875@nsa.vix.com> <39785.1282261320@nsa.vix.com> <54594.1282275654@nsa.vix.com> <20100820162403.GE96071@shinkuro.com> Date: Fri, 20 Aug 2010 10:22:22 -0700 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Paul Hoffman Subject: [dnsext] Problem statement additions 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 12:24 PM -0400 8/20/10, Andrew Sullivan wrote: >On Fri, Aug 20, 2010 at 03:40:54AM +0000, Paul Vixie wrote: >> ok, let's deal with open issue 4.1 if this approach is generally wanted. > >Before tackling that, I'd really like to see the list of problems in >the problem statement document (that Suzanne is currently editing) >updated. Please send text on what problems there are here. Assuming that we are still talking about draft-yao-dnsext-identical-resolution, which is at -01, I am unsure what you are asking for. The document is a list of use cases (section 2) and proposals (section 3). The document itself seems to describe the problems that DNS users have well. Are you asking for a list of problems that zone owners would have? If so, are they the apex owners, the subdomain owners, or ...? --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Fri Aug 20 10:44: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 3E8E43A6980; Fri, 20 Aug 2010 10:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.947 X-Spam-Level: X-Spam-Status: No, score=-108.947 tagged_above=-999 required=5 tests=[AWL=0.148, 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, 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 b9JAUWQqkJ-L; Fri, 20 Aug 2010 10:44:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF9D03A68A7; Fri, 20 Aug 2010 10:44:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmVau-0002ds-Nz for namedroppers-data0@psg.com; Fri, 20 Aug 2010 17:41:32 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmVas-0002dW-FE for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 17:41:30 +0000 Received: (qmail 90126 invoked from network); 20 Aug 2010 17:41:29 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 20 Aug 2010 17:41:29 -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=k1008; olt=johnl@user.iecc.com; bh=knIJyT8AvwkcsGt/bkyK6SjLnW31imKf/ZxhXEqyaX0=; b=sk5/ejAR63CTkA0jfJv3zJHHQGBXOViANjq9KdN2JLlgWBC+Khl9Yr8BgLgWD+6+EXXg63ixBBR3RYc+K3immW335CD1woX0WPdPFBp8YQqkH3rnWIIMM0u76CDRmQAHPP+H8sJjoH/rG7gKCnFT2IawEkCkIGlxVlyhX0SkdNA= Date: 20 Aug 2010 17:41:28 -0000 Message-ID: <20100820174128.90020.qmail@joyce.lan> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: [dnsext] If you think "xNAME" doesn't work, what about SHADOW? In-Reply-To: <20100820162403.GE96071@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: >Before tackling that, I'd really like to see the list of problems in >the problem statement document (that Suzanne is currently editing) >updated. Please send text on what problems there are here. I see two somewhat different problems we might be trying to solve. (Well, three if you accept "whatever xNAME does" as the problem.) Small version) Automate as much of the process of making two domains "the same" in the DNS as we can, while not getting in the way of the scripts or manual process people use to do the rest of the work. Large version) Small version plus sufficient hooks in the DNS that an application can auto-configure itself to handle the aliases and whatever involved in making names in other zones "the same" as a name it's already been set up to handle. R's, John From owner-namedroppers@ops.ietf.org Fri Aug 20 11:26: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 4997D3A68F9; Fri, 20 Aug 2010 11:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.223 X-Spam-Level: X-Spam-Status: No, score=-100.223 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 RqDi59xqizvq; Fri, 20 Aug 2010 11:26:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 429F83A6801; Fri, 20 Aug 2010 11:26:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmWDb-0009Ek-W3 for namedroppers-data0@psg.com; Fri, 20 Aug 2010 18:21:31 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmWDZ-0009ER-1a for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 18:21:29 +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 46D6D1ECB408 for ; Fri, 20 Aug 2010 18:21:27 +0000 (UTC) Date: Fri, 20 Aug 2010 14:21:25 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Re: Problem statement additions Message-ID: <20100820182125.GJ96071@shinkuro.com> References: <24409.1282244875@nsa.vix.com> <39785.1282261320@nsa.vix.com> <54594.1282275654@nsa.vix.com> <20100820162403.GE96071@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, Aug 20, 2010 at 10:22:22AM -0700, Paul Hoffman wrote: > > Assuming that we are still talking about > draft-yao-dnsext-identical-resolution, which is at -01, I am unsure > what you are asking for. The document is a list of use cases Yes, I was. > (section 2) and proposals (section 3). The document itself seems to > describe the problems that DNS users have well. Are you asking for a > list of problems that zone owners would have? If so, are they the > apex owners, the subdomain owners, or ...? Well, presumably the problems of zone owners are in some other sense a problem for DNS users, no? But yeah, I think we probably need to address issues for zone owners. And while it's apex owners, it's _every_ apex owner, I'd like to think. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Aug 20 11:51: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 42EAC3A6B12; Fri, 20 Aug 2010 11:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.281 X-Spam-Level: X-Spam-Status: No, score=-100.281 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 2zsf3WfaK3ra; Fri, 20 Aug 2010 11:51:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 141903A6B2C; Fri, 20 Aug 2010 11:51:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmWbm-000CVZ-7c for namedroppers-data0@psg.com; Fri, 20 Aug 2010 18:46:30 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmWbj-000CVE-Qi for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 18:46:28 +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 o7KIkNga076715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Aug 2010 11:46:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100820182125.GJ96071@shinkuro.com> References: <24409.1282244875@nsa.vix.com> <39785.1282261320@nsa.vix.com> <54594.1282275654@nsa.vix.com> <20100820162403.GE96071@shinkuro.com> <20100820182125.GJ96071@shinkuro.com> Date: Fri, 20 Aug 2010 11:46:22 -0700 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Paul Hoffman Subject: [dnsext] Re: Problem statement additions 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 2:21 PM -0400 8/20/10, Andrew Sullivan wrote: >On Fri, Aug 20, 2010 at 10:22:22AM -0700, Paul Hoffman wrote: >> >> Assuming that we are still talking about >> draft-yao-dnsext-identical-resolution, which is at -01, I am unsure >> what you are asking for. The document is a list of use cases > >Yes, I was. > >> (section 2) and proposals (section 3). The document itself seems to >> describe the problems that DNS users have well. Are you asking for a >> list of problems that zone owners would have? If so, are they the >> apex owners, the subdomain owners, or ...? > >Well, presumably the problems of zone owners are in some other sense a >problem for DNS users, no? But yeah, I think we probably need to >address issues for zone owners. And while it's apex owners, it's >_every_ apex owner, I'd like to think. Yes, it is every apex owner. The case of .com is just as interesting as .. I'll +1 John's proposals: At 5:41 PM +0000 8/20/10, John Levine wrote: >Small version) Automate as much of the process of making two domains > "the same" in the DNS as we can, while not getting in the way of the > scripts or manual process people use to do the rest of the work. > >Large version) Small version plus sufficient hooks in the DNS that an > application can auto-configure itself to handle the aliases and > whatever involved in making names in other zones "the same" as a > name it's already been set up to handle. I am skeptical about whether the "large version" is even possible, but there are a lot of clever people and highly motivated DNS operators on this list. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Fri Aug 20 14:37: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 2EBDF3A680D; Fri, 20 Aug 2010 14:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, 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 nxk4w52KoCXv; Fri, 20 Aug 2010 14:37:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB2B23A69F8; Fri, 20 Aug 2010 14:37:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmZD6-0009Vu-7H for namedroppers-data0@psg.com; Fri, 20 Aug 2010 21:33:12 +0000 Received: from [209.86.89.63] (helo=elasmtp-junco.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmZD0-0009VJ-F2 for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 21:33:06 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=l9MUn4uRr4EN6xYke3iptVRzZNpJ5VsWuMxZpU4+3aI9U2QexmRPZwVVKiORcBwq; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.50] (helo=mswamui-swiss.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OmZCy-0000Gw-Sv for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 17:33:04 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 20 Aug 2010 17:33:04 -0400 Message-ID: <28181957.1282339984814.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> Date: Fri, 20 Aug 2010 16:33:04 -0500 (GMT-05:00) From: "Jeffrey A. Williams" Reply-To: "Jeffrey A. Williams" To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Problem statement additions Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688eabef3e5c90be21933bf19a5e5f6a5ff350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.50 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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, John, and all, -----Original Message----- >From: Paul Hoffman >Sent: Aug 20, 2010 1:46 PM >To: Andrew Sullivan , namedroppers@ops.ietf.org >Subject: [dnsext] Re: Problem statement additions > >At 2:21 PM -0400 8/20/10, Andrew Sullivan wrote: >>On Fri, Aug 20, 2010 at 10:22:22AM -0700, Paul Hoffman wrote: >>> >>> Assuming that we are still talking about >>> draft-yao-dnsext-identical-resolution, which is at -01, I am unsure >>> what you are asking for. The document is a list of use cases >> >>Yes, I was. >> >>> (section 2) and proposals (section 3). The document itself seems to >>> describe the problems that DNS users have well. Are you asking for a >>> list of problems that zone owners would have? If so, are they the >>> apex owners, the subdomain owners, or ...? >> >>Well, presumably the problems of zone owners are in some other sense a >>problem for DNS users, no? But yeah, I think we probably need to >>address issues for zone owners. And while it's apex owners, it's >>_every_ apex owner, I'd like to think. > >Yes, it is every apex owner. The case of .com is just as interesting as .. > >I'll +1 John's proposals: > >At 5:41 PM +0000 8/20/10, John Levine wrote: >>Small version) Automate as much of the process of making two domains >> "the same" in the DNS as we can, while not getting in the way of the >> scripts or manual process people use to do the rest of the work. >> >>Large version) Small version plus sufficient hooks in the DNS that an >> application can auto-configure itself to handle the aliases and >> whatever involved in making names in other zones "the same" as a >> name it's already been set up to handle. > >I am skeptical about whether the "large version" is even possible, but there are a lot of clever people and highly motivated DNS operators on this list. I prefer the large version but also understand Pauls thoughtful concerns. My additional concern with John's large version is the greater possibility of unintended consequences, which will be many. Most should be able to be addressed. John's small version has the nicity of being simple and stay's out of the way of other scripts doing other work of various sorts, but may make some of those functions/scripts unable to be authenticated appropriately. Such may not be a serious issue though. > > >--Paul Hoffman, Director >--VPN Consortium > Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From owner-namedroppers@ops.ietf.org Fri Aug 20 14:58: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 9B6133A67FB; Fri, 20 Aug 2010 14:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.241, 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 AlpLYLjW8rfJ; Fri, 20 Aug 2010 14:58:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E0163A691B; Fri, 20 Aug 2010 14:58:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmZZ8-000CWr-8R for namedroppers-data0@psg.com; Fri, 20 Aug 2010 21:55:58 +0000 Received: from [2001:4f8:0:2::2b] (helo=mx.pao1.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmZZ6-000CWD-2k for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 21:55:56 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 7D446C9422; Fri, 20 Aug 2010 21:55:53 +0000 (UTC) (envelope-from woolf@isc.org) Received: by farside.isc.org (Postfix, from userid 10265) id 57514E60DF; Fri, 20 Aug 2010 21:55:53 +0000 (UTC) Date: Fri, 20 Aug 2010 21:55:53 +0000 From: Suzanne Woolf To: Paul Hoffman Cc: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Problem statement additions Message-ID: <20100820215553.GA24798@farside.isc.org> References: <24409.1282244875@nsa.vix.com> <39785.1282261320@nsa.vix.com> <54594.1282275654@nsa.vix.com> <20100820162403.GE96071@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Fri, Aug 20, 2010 at 10:22:22AM -0700, Paul Hoffman wrote: > > Assuming that we are still talking about > draft-yao-dnsext-identical-resolution, which is at -01, I am unsure > what you are asking for. The document is a list of use cases > (section 2) and proposals (section 3). The document itself seems to > describe the problems that DNS users have well. Are you asking for a > list of problems that zone owners would have? If so, are they the > apex owners, the subdomain owners, or ...? As editor of the document I've come to the conclusion that the next rev needs an explicit "requirements" section, to gather the ones so far identified and help further with digging out the hidden assumptions we seem to be excavating in recent discussion. In fact....Broadly speaking, I think the next rev needs: 1. More detail on use cases, IDN-related an otherwise. We have basic descriptions of two IDN-related cases. We need more. I have some contributions on a couple, but more text is welcome. What we most need is detailed descriptions of the desired behavior with regards to what applications see, what caches see, and what users can reasonably assume. 2. More detail on identified limitations on both problems and solutions. 3. An expanded security considerations section, including not only more discussion of DNSSEC but the SSL issues raised and psosibly others as well. 4. An explicit "requirements" section, including those proposed in Anaheim and the implicit ones that have been emerging in the list discussion since Maastricht. 5. An overview of the complexity/tradeoffs analyses we've been doing informally here, with an eye towards explaining to people who are not DNS protocol experts what the side effects are to even apparently simple changes to the DNS. Text/suggestions welcome. Best, Suzanne From owner-namedroppers@ops.ietf.org Fri Aug 20 15:11: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 A2B1D3A69B2; Fri, 20 Aug 2010 15:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.937 X-Spam-Level: X-Spam-Status: No, score=-108.937 tagged_above=-999 required=5 tests=[AWL=0.158, 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, 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 yT1ZzA0itwIQ; Fri, 20 Aug 2010 15:10:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1ACC53A6A14; Fri, 20 Aug 2010 15:10:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmZl4-000EFV-Eq for namedroppers-data0@psg.com; Fri, 20 Aug 2010 22:08:18 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmZl2-000EEt-3o for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 22:08:16 +0000 Received: (qmail 3622 invoked from network); 20 Aug 2010 22:08:14 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 20 Aug 2010 22:08:14 -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=k1008; olt=johnl@user.iecc.com; bh=GpRb+TzOjjuTCV0CroC9cI2mpenc5Bnhz4BwOkx4ka0=; b=P7rI+UHImPTexIJV7XnasBU56cNrdeYtKwryS8p3rEMz+r1bBzh9znGMoVZvWhVAFB7ZFPt5eqNAyqzrdCLgYG+vzyRZbml3xbHDb1wpU/sWc8YwhaKn0bUSRO+MfaoCkEWQDLMM+rI9ilm65S5x5XPfGiqDlguL9Fg93qaGCK4= Date: 20 Aug 2010 22:08:14 -0000 Message-ID: <20100820220814.54488.qmail@joyce.lan> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Problem statement additions In-Reply-To: Organization: Cc: paul.hoffman@vpnc.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: >>Large version) Small version plus sufficient hooks in the DNS that an >> application can auto-configure itself to handle the aliases and >> whatever involved in making names in other zones "the same" as a >> name it's already been set up to handle. > >I am skeptical about whether the "large version" is even possible, but >there are a lot of clever people and highly motivated DNS operators on >this list. In case it wasn't clear, I wasn't anticipating any way to make multiple names work transparently to applications. The idea was that an application configured for one name could query the DNS to find out what other names are "the same" (shadowed or whatever) so it can then look and see what DNS records the other names have and adjust its configuration appropriately. R's, John From owner-namedroppers@ops.ietf.org Fri Aug 20 15:55: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 67AEC3A67FA; Fri, 20 Aug 2010 15:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.316 X-Spam-Level: X-Spam-Status: No, score=-0.316 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_57=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 UevfFOt7sM8t; Fri, 20 Aug 2010 15:55:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF9583A680B; Fri, 20 Aug 2010 15:55:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmaQe-000JYy-AY for namedroppers-data0@psg.com; Fri, 20 Aug 2010 22:51:16 +0000 Received: from [209.85.215.52] (helo=mail-ew0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmaQb-000JYi-DV for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 22:51:13 +0000 Received: by ewy20 with SMTP id 20so3198578ewy.11 for ; Fri, 20 Aug 2010 15:51: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:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2J3nxEV0LrwCbUqxBmPJPUswBiiE/I8iUWW5aa348YE=; b=xKeFkxvIy1qFNHnNKm1pVwJJFnfeAtUd00oUNLRLylrAxjRd3X4g0Ujcb+9xL+8ovj JarRyxhP3Z/+jxHgpwmam4zvsfxxlggW1/tE6oajA/HOm6qnpFVGKoZViezIXoj9/omX Ov22q3g5AdGtq7trsEQaLaIQHAOH4GD7a5RRE= 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=wjg/pqGfzdXq2+8LjUMBBxrg+0fxervFE8wXyaChqojT4CYw0x/3rai+J3/lVHp40X hzvyX9JIyadnlfWsENJClOa4n5DrA0h5+14puptbJ27JKjloYuwW1tBjYahNWKGgHQf/ XZD2RvU4uCwxH3eREvTaAZ8JlcKz3wdGhp9LQ= MIME-Version: 1.0 Received: by 10.213.113.141 with SMTP id a13mr930004ebq.7.1282344672289; Fri, 20 Aug 2010 15:51:12 -0700 (PDT) Received: by 10.14.127.195 with HTTP; Fri, 20 Aug 2010 15:51:12 -0700 (PDT) In-Reply-To: <20100820220814.54488.qmail@joyce.lan> References: <20100820220814.54488.qmail@joyce.lan> Date: Fri, 20 Aug 2010 15:51:12 -0700 Message-ID: Subject: Re: [dnsext] Re: Problem statement additions From: Ted Hardie To: John Levine Cc: namedroppers@ops.ietf.org, paul.hoffman@vpnc.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 Fri, Aug 20, 2010 at 3:08 PM, John Levine wrot > > In case it wasn't clear, I wasn't anticipating any way to make > multiple names work transparently to applications. =C2=A0The idea was tha= t > an application configured for one name could query the DNS to find out > what other names are "the same" (shadowed or whatever) so it can then > look and see what DNS records the other names have and adjust its > configuration appropriately. > > R's, > John I'm a bit concerned about "look and see what DNS records the other names have". CNAME works because it functions to identify the one name at which the RRs reside. I think anything we come up with should have that same property--there should be one entry where the data is, whatever mechanisms are necessary to point to that entry in a safe and sane manner. The example I've used privately is a company that wants to support both British and American spellings of its domain, humor/humour.example . If one spelling is canonical, then solutions in this space work to give something equivalent to a domain-inclusive CNAME wildcard. They're the moral equivalent of "for i in humor.example CNAME $i.humour.example" with humor.example mapped to humour.example as well. This works, though APIs may need to pass up the equivalent of "The DNS lead you to someplace new". But if I want to allow subdomains to put the RRs either place, things get tricky. To allow RRs at british.humour.example (with a pointer from british.humor.example) b= ut RRs at american.humor.example (with a pointer from american.humour.example), I think I've ruled out an architecturally clean domain-level mechanism used at the humor/humour.example level. It gets particularly bad if I want to have the client check both american.humour.example (where the NS records might be configured) but also check american.humor.example for other records (like MX) and then act as if they both applied equally. To put this another way, if the semantics of this are "$variable.humor.example is a valid alternate to $variable.humour.example, please check both for any RR you're interested in", I think the apps confusion will overwhelm any benefit. So folks realize that this is not just a pure hypothetical, consider the ca= se of .=E4=B8=AD=E5=9B=BD and .=E4=B8=AD=E5=9C=8B. If one is canonical and the o= ther a variant, we have the CNAME-on-steroids case. But if the domain administrators wish to allow =E9=A6=99=E6=B8=AF=E3=80=82=E4=B8=AD=E5=9C=8B (Hong Kong, China, using the = complex characters in use in Hong Kong) to be primary but prefer =E5=8C=97=E4=BA=AC=E3=80=82=E4=B8=AD=E5=9B=BD (Bei= jing, China, using the simplified characters in use in Beijing), to be primary, a domain-level solution at the .=E4=B8=AD=E5=9B=BD=EF=BC=8F= =E4=B8=AD=E5=9C=8B level may actually be out of the question. Which is an alias and which the target will vary below that point. I fear that my own muddled thinking on these examples may hinder the question, so I'll try to repeat it succinctly: "Can we agree that any solution can rely on there being a single entry at which all RRs other than pointers are found?" regards, Ted Hardie From owner-namedroppers@ops.ietf.org Fri Aug 20 16:20: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 1F0523A6832; Fri, 20 Aug 2010 16:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.639 X-Spam-Level: X-Spam-Status: No, score=-108.639 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HABEAS_ACCREDITED_SOI=-4.3, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_37=0.6, RCVD_IN_BSP_TRUSTED=-4.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 oLphNN45cavI; Fri, 20 Aug 2010 16:20:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CEBC93A6898; Fri, 20 Aug 2010 16:20:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Omaqe-000N6e-Gc for namedroppers-data0@psg.com; Fri, 20 Aug 2010 23:18:08 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Omaqc-000N6N-7V for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 23:18:06 +0000 Received: (qmail 26032 invoked from network); 20 Aug 2010 23:18:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=TFEdU6VYYRGrBDiwZ1cR04UpUBYy6IYRRw5654eAdfo=; b=1Sq/RXV1n84gMD1MNca2A/TdQd3U6Q02VZPNnMjV8xdWvvDyIeQiXhSo/8q+Sj0sX7yMrTLl3i88rigHgF/OfyYEhY52luk9dR8Fo1RQodRZW0asAQTwKkflprvoxaG4y09mcQeFQJNTRvNcLVhRY410mlqUHTSAbYfAgOnXG1w= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Aug 2010 23:17:42 -0000 Date: 20 Aug 2010 19:18:03 -0400 Message-ID: From: "John R. Levine" To: "Ted Hardie" Cc: namedroppers@ops.ietf.org, paul.hoffman@vpnc.org Subject: Re: [dnsext] Re: Problem statement additions In-Reply-To: References: <20100820220814.54488.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > I'm a bit concerned about "look and see what DNS records the other names > have". I was thinking of something like this: foo.example A 12.34.56.78 ; normal record for web server or whatever THESAME bar.example THESAME baz.example Nothing sees THESAME records unless they ask for them, so they're just for applications that know how to use them to autoconfigure. There still has to be A records at bar.example and baz.example, whether from shadow or something else. > "Can we agree that any solution can rely on there being a > single entry at which all RRs other than pointers are found?" That was my assumption, but it's a good question. R's, John From owner-namedroppers@ops.ietf.org Fri Aug 20 19:06: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 A396C3A68C1; Fri, 20 Aug 2010 19:06: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: -96.454 X-Spam-Level: X-Spam-Status: No, score=-96.454 tagged_above=-999 required=5 tests=[AWL=-1.763, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 AQZW8OQq9oyf; Fri, 20 Aug 2010 19:06:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 730393A6405; Fri, 20 Aug 2010 19:06:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmdOu-000Gia-Dc for namedroppers-data0@psg.com; Sat, 21 Aug 2010 02:01:40 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmdOq-000Gi9-VY for namedroppers@ops.ietf.org; Sat, 21 Aug 2010 02:01:37 +0000 Received: (eyou send program); Sat, 21 Aug 2010 10:01:31 +0800 Message-ID: <482356091.17828@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO abc) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 21 Aug 2010 10:01:31 +0800 Message-ID: From: "Yao Jiankang" To: Subject: [dnsext] does C+D fail in current resolver? Date: Sat, 21 Aug 2010 09:52:35 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01CB4116.94B6E050" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0016_01CB4116.94B6E050 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 YmFzZWQgb24gdGhlIHBhdWwncyBjbG9zZWQgY29kZSwNCg0KSSBoYXZlIGEgZmVlbGluZyB0aGF0 IEMrRCB3aWxsIGZhaWwgaW4gc29tZSBjdXJyZW50IHJlc29sdmVycy4NCg0KZm9yIGV4YW1wbGU6 DQoNCmluIHRoZSB6b25lLCB5b3Ugc2V0DQoNCmEuZXhhbXBsZSBjbmFtZSBhLnRlc3QNCmEuZXhh bXBsZSBkbmFtZSBhLnRlc3QNCg0Kbm93IHlvdSBxdWVyeSBhLmV4YW1wbGUsDQoNCnRoZSByZXNv bHZlciBjYW4gZ2V0IHRoZSByZXN1bHQgImEuZXhhbXBsZSBjbmFtZSBhLnRlc3QiIGFuZCBjYWNo ZSBpdC4NCnRoZW4sIHlvdSBxdWVyeSBhLmEuZXhhbXBsZSwgYW5kIGdldCB0aGUgcmVzdWx0IGFu ZCBjYWNoZSB0aGVtOg0KDQoiYS5hLmV4YW1wbGUgY25hbWUgYS5hLnRlc3QNCmEuZXhhbXBsZSBk bmFtZSBhLnRlc3QiDQoNCmZpbmFsbHksDQoNCnRoZSBjYWNoZSB3aWxsIGhhdmUgDQp0aGUgZm9s bG93aW5nIFJScyBiZWZvcmUgdGhlIHRpbWUgb3V0Og0KIg0KYS5leGFtcGxlIGNuYW1lIGEudGVz dA0KYS5hLmV4YW1wbGUgY25hbWUgYS5hLnRlc3QNCmEuZXhhbXBsZSBkbmFtZSBhLnRlc3QNCiIN Cg0Kc28gYWNjb3JkaW5nIHRvIHRoZSBjbG9zZWQgY29kZSBwcm92aWRlZCBieSBQYXVsLA0KDQpl aXRob3IgY25hbWUgb3IgZG5hbWUgd2lsbCBub3QgYmUgcmVzb2x2ZWQgY29ycmVjdGx5Lg0KDQpp ZiB5b3Ugd2FudCB0byBtYWtlIGMrZCB0byB3b3JrIGNvcnJlY3RseSwgc2lnbmFsaW5nIGlzIGEg TVVTVCBldmVuIGlmIHRoZSByZXNvbHZlciBpcyBub24tZG5zc2VjIHJlc29sdmVyLg0KDQpKaWFu a2FuZyBZYW8NCg0KDQoNCj5JbiBtZXNzYWdlIDwyNjkwMi4xMjgxNzIyODY4QG5zYS52aXguY29t PiwgUGF1bCBWaXhpZSB3cml0ZXM6DQo+IHRoZSBmb2xsb3dpbmcgY29kZSBleGlzdHMgaW4gYSBk ZXBsb3llZCAoY29tbWVyY2lhbCwgY2xvc2VkLXNvdXJjZSkNCj4gcmVjdXJzaXZlIGRucyBzZXJ2 ZXIuICAod2hpY2ggaSB3cm90ZSBkdXJpbmcgYSBzYWJiYXRpY2FsIGluIDIwMDMuKQ0KPiANCj4g CS4uLg0KPiANCj4gCS8qIENhY2hlIGVycm9yIG1lYW5zIHRoZXJlIGNhbid0IGJlIGEgQ05BTUUu ICBUaGlzIGhhcHBlbnMNCj4gCSAqIHdoZW4gd2UgaGF2ZSBubyByb290IGhpbnRzIGF0IGFsbC4N Cj4gCSAqLw0KPiAJaWYgKGRvbSA9PSBOVUxMKQ0KPiAJICAgICAgICBicmVhazsNCj4gDQo+IAkv KiBJZiBRVFlQRSBpcyBDTkFNRSB0aGVuIHJldHVybiBpdCByYXRoZXIgdGhhbiBmb2xsb3dpbmcg aXQuDQo+IAkgKi8NCj4gCWlmIChxdHlwZSA9PSBuc190X2NuYW1lKQ0KPiAJICAgICAgICBicmVh azsNCj4gDQo+IAkvKiBJZiB0aGVyZSdzIG5vIENOQU1FIGluIGNhY2hlIGJ1dCB0aGVyZSdzIGFu eSBvdGhlciB0eXBlDQo+IAkgKiAodW5leHBpcmVkKSwgdGhlbiB0aGVyZSBjYW5ub3QgYmUgYSBD TkFNRSBhbmQgd2UncmUgZG9uZS4NCj4gCSAqIE5vdGU6IHRoaXMgaXMgYW4gb3B0aW1pemF0aW9u IHRvIGF2b2lkIGRuc19jYWNoZV9maW5kdHlwZS4NCj4gCSAqLw0KPiAJYW55dHlwZSA9IChkbnNf Y2FjaGVfYW55dHlwZShkb20sIG5vdy50dl9zZWMpICE9IE5VTEwpOw0KPiAJaWYgKChkbnNfZG9t X2dldGZsYWdzKGRvbSkgJiBETlNfRE9NX0lTQUxJQVMpID09IDAgJiYNCj4gCSAgICBhbnl0eXBl KQ0KPiAJICAgICAgICBicmVhazsNCj4gDQo+IAkvKiBIYW5kbGUgQ05BTUUgKGlmIGl0IGV4aXN0 cykgY2hhaW5pbmcuICovDQo+IAlzd2l0Y2ggKGRuc19jYWNoZV9maW5kdHlwZShkYywgZG9tLCBx Y2xhc3MsIG5zX3RfY25hbWUsDQo+IAkJCQkgICBGQUxTRSwgJnJyc2V0LCBub3cudHZfc2VjKSkN Cj4gCXsNCj4gCQkuLi4NCg== ------=_NextPart_000_0016_01CB4116.94B6E050 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC42MDAwLjE3MDgwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jY2NlOGNmPg0KPERJVj48Rk9OVCBzaXplPTI+YmFzZWQgb24gdGhlIHBh dWwncyBjbG9zZWQgY29kZSw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIGhhdmUgYSBmZWVsaW5nIHRoYXQgQytE IHdpbGwgZmFpbCBpbiBzb21lIGN1cnJlbnQgDQpyZXNvbHZlcnMuPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Zm9y IGV4YW1wbGU6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+aW4gdGhlIHpvbmUsIHlvdSBzZXQ8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5hLmV4YW1wbGUgY25hbWUgYS50ZXN0PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ YS5leGFtcGxlIGRuYW1lIGEudGVzdDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPm5vdyB5b3UgcXVlcnkgYS5leGFt cGxlLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPnRoZSByZXNvbHZlciBjYW4gZ2V0IHRoZSByZXN1bHQgImEuZXhh bXBsZSBjbmFtZSBhLnRlc3QiIA0KYW5kJm5ic3A7Y2FjaGUgaXQuPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+dGhlbiwgeW91IHF1ZXJ5IGEuYS5leGFtcGxlLCBhbmQgZ2V0IHRoZSBy ZXN1bHQgYW5kIGNhY2hlIA0KdGhlbTo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4iPEZPTlQgc2l6ZT0yPmEuYS5l eGFtcGxlIGNuYW1lIGEuYS50ZXN0PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+YS5l eGFtcGxlIGRuYW1lIGEudGVzdDwvRk9OVD4iPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj5maW5hbGx5LDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+dGhlIGNhY2hlIHdpbGwg aGF2ZSA8L0RJVj4NCjxESVY+dGhlIGZvbGxvd2luZyBSUnMgYmVmb3JlIHRoZSB0aW1lIG91dDo8 L0RJVj4NCjxESVY+IjwvRElWPg0KPERJVj5hLmV4YW1wbGUgY25hbWUgYS50ZXN0PC9ESVY+DQo8 RElWPmEuYS5leGFtcGxlIGNuYW1lIGEuYS50ZXN0DQo8RElWPjxGT05UIHNpemU9Mj5hLmV4YW1w bGUgZG5hbWUgYS50ZXN0PC9GT05UPjwvRElWPjwvRElWPg0KPERJVj4iPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ c28gYWNjb3JkaW5nIHRvIHRoZSBjbG9zZWQgY29kZSBwcm92aWRlZCBieSBQYXVsLDwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPmVpdGhvciBjbmFtZSBvciBkbmFtZSB3aWxsIG5vdCBiZSByZXNvbHZlZCANCmNvcnJl Y3RseS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5pZiB5b3Ugd2FudCB0byBtYWtlIGMrZCB0byB3b3JrIGNvcnJl Y3RseSwgc2lnbmFsaW5nIGlzIGEgTVVTVCANCmV2ZW4gaWYgdGhlIHJlc29sdmVyIGlzIG5vbi1k bnNzZWMgcmVzb2x2ZXIuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SmlhbmthbmcgWWFvPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj4mZ3Q7SW4gbWVzc2FnZSAmbHQ7PEEgDQpocmVmPSJodHRwOi8vd3d3Lm9wcy5pZXRm Lm9yZy9saXN0cy9uYW1lZHJvcHBlcnMvbmFtZWRyb3BwZXJzLjIwMTAvbXNnMDIyMTEuaHRtbCI+ MjY5MDIuMTI4MTcyMjg2OEBuc2Eudml4LmNvbTwvQT4mZ3Q7LCANClBhdWwgVml4aWUgd3JpdGVz OjxCUj4mZ3Q7IHRoZSBmb2xsb3dpbmcgY29kZSBleGlzdHMgaW4gYSBkZXBsb3llZCAoY29tbWVy Y2lhbCwgDQpjbG9zZWQtc291cmNlKTxCUj4mZ3Q7IHJlY3Vyc2l2ZSBkbnMgc2VydmVyLiZuYnNw OyAod2hpY2ggaSB3cm90ZSBkdXJpbmcgYSANCnNhYmJhdGljYWwgaW4gMjAwMy4pPEJSPiZndDsg PEJSPiZndDsgCS4uLjxCUj4mZ3Q7IDxCUj4mZ3Q7IAkvKiBDYWNoZSBlcnJvciANCm1lYW5zIHRo ZXJlIGNhbid0IGJlIGEgQ05BTUUuJm5ic3A7IFRoaXMgaGFwcGVuczxCUj4mZ3Q7IAkgKiB3aGVu IHdlIGhhdmUgbm8gDQpyb290IGhpbnRzIGF0IGFsbC48QlI+Jmd0OyAJICovPEJSPiZndDsgCWlm IChkb20gPT0gTlVMTCk8QlI+Jmd0OyANCgkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgYnJlYWs7PEJSPiZndDsgPEJSPiZndDsgCS8qIElmIFFUWVBFIA0KaXMgQ05B TUUgdGhlbiByZXR1cm4gaXQgcmF0aGVyIHRoYW4gZm9sbG93aW5nIGl0LjxCUj4mZ3Q7IAkgKi88 QlI+Jmd0OyAJaWYgDQoocXR5cGUgPT0gbnNfdF9jbmFtZSk8QlI+Jmd0OyAJJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KYnJlYWs7PEJSPiZndDsgPEJSPiZndDsg CS8qIElmIHRoZXJlJ3Mgbm8gQ05BTUUgaW4gY2FjaGUgYnV0IHRoZXJlJ3MgYW55IG90aGVyIA0K dHlwZTxCUj4mZ3Q7IAkgKiAodW5leHBpcmVkKSwgdGhlbiB0aGVyZSBjYW5ub3QgYmUgYSBDTkFN RSBhbmQgd2UncmUgDQpkb25lLjxCUj4mZ3Q7IAkgKiBOb3RlOiB0aGlzIGlzIGFuIG9wdGltaXph dGlvbiB0byBhdm9pZCANCmRuc19jYWNoZV9maW5kdHlwZS48QlI+Jmd0OyAJICovPEJSPiZndDsg CWFueXR5cGUgPSAoZG5zX2NhY2hlX2FueXR5cGUoZG9tLCANCm5vdy50dl9zZWMpICE9IE5VTEwp OzxCUj4mZ3Q7IAlpZiAoKGRuc19kb21fZ2V0ZmxhZ3MoZG9tKSAmYW1wOyBETlNfRE9NX0lTQUxJ QVMpIA0KPT0gMCAmYW1wOyZhbXA7PEJSPiZndDsgCSZuYnNwOyZuYnNwOyZuYnNwOyBhbnl0eXBl KTxCUj4mZ3Q7IA0KCSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBi cmVhazs8QlI+Jmd0OyA8QlI+Jmd0OyAJLyogSGFuZGxlIA0KQ05BTUUgKGlmIGl0IGV4aXN0cykg Y2hhaW5pbmcuICovPEJSPiZndDsgCXN3aXRjaCAoZG5zX2NhY2hlX2ZpbmR0eXBlKGRjLCBkb20s IA0KcWNsYXNzLCBuc190X2NuYW1lLDxCUj4mZ3Q7IAkJCQkmbmJzcDsmbmJzcDsgRkFMU0UsICZh bXA7cnJzZXQsIA0Kbm93LnR2X3NlYykpPEJSPiZndDsgCXs8QlI+Jmd0OyAJCS4uLjxCUj48L0RJ Vj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0016_01CB4116.94B6E050-- From owner-namedroppers@ops.ietf.org Sun Aug 22 06:41: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 D81E13A687C; Sun, 22 Aug 2010 06:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 9A6KPtCmZUb9; Sun, 22 Aug 2010 06:41:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9A5633A6852; Sun, 22 Aug 2010 06:41:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnAfC-0006jX-VK for namedroppers-data0@psg.com; Sun, 22 Aug 2010 13:32:42 +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.72 (FreeBSD)) (envelope-from ) id 1OnAf9-0006iy-JC for namedroppers@ops.ietf.org; Sun, 22 Aug 2010 13:32:39 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5A88EA101E for ; Sun, 22 Aug 2010 13:32:37 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Problem statement additions In-Reply-To: Your message of "Fri\, 20 Aug 2010 15\:51\:12 MST." References: <20100820220814.54488.qmail@joyce.lan> 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: Sun, 22 Aug 2010 13:32:37 +0000 Message-ID: <44811.1282483957@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, 20 Aug 2010 15:51:12 -0700 > From: Ted Hardie >=20 > I'm a bit concerned about "look and see what DNS records the other names > have". CNAME works because it functions to identify the one name at > which the RRs reside. I think anything we come up with should have that > same property--there should be one entry where the data is, whatever > mechanisms are necessary to point to that entry in a safe and sane > manner. disagreed. we don't have that today, and we don't need it anyway. gethostbyname() can return many addresses and many aliases, and gethostbyaddr() can do likewise, and someone who wants to know _all_ the names by which a host is reachable has to call both (like getruserok() does.) > ... >=20 > To put this another way, if the semantics of this are > "$variable.humor.example is a valid alternate to > $variable.humour.example, please check both for any RR you're interested > in", I think the apps confusion will overwhelm any benefit. agreed. > So folks realize that this is not just a pure hypothetical, consider the > case of .=E4=B8=AD=E5=9B=BD and .=E4=B8=AD=E5=9C=8B. If one is canonical= and the other a variant, we > have the CNAME-on-steroids case. But if the domain administrators wish > to allow=E9=A6=99=E6=B8=AF=E3=80=82=E4=B8=AD=E5=9C=8B (Hong Kong, China, = using the complex characters in use > in Hong Kong) to be primary but prefer =E5=8C=97=E4=BA=AC=E3=80=82=E4=B8= =AD=E5=9B=BD (Beijing, China, using > the simplified characters in use in Beijing), to be primary, a > domain-level solution at the .=E4=B8=AD=E5=9B=BD=EF=BC=8F=E4=B8=AD=E5=9C= =8B level may actually be out of the > question. Which is an alias and which the target will vary below that > point. yes. but we're presuming a new RR or new placement of existing RR's as a way for IDN-aware apps to do extra work to get some extra functionality. > I fear that my own muddled thinking on these examples may hinder the > question, so I'll try to repeat it succinctly: "Can we agree that any > solution can rely on there being a single entry at which all RRs other > than pointers are found?" i don't agree on this, since i know how A/AAAA/PTR clouds work today. From owner-namedroppers@ops.ietf.org Sun Aug 22 14:43: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 ABA063A6964; Sun, 22 Aug 2010 14:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.044 X-Spam-Level: X-Spam-Status: No, score=0.044 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_55=0.6, J_CHICKENPOX_57=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 vEAbR9Kmnvsy; Sun, 22 Aug 2010 14:43:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 697B03A6960; Sun, 22 Aug 2010 14:43:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnIEz-0008v3-HW for namedroppers-data0@psg.com; Sun, 22 Aug 2010 21:38:09 +0000 Received: from [209.85.215.52] (helo=mail-ew0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnIEw-0008uk-Nc for namedroppers@ops.ietf.org; Sun, 22 Aug 2010 21:38:07 +0000 Received: by ewy20 with SMTP id 20so3724600ewy.11 for ; Sun, 22 Aug 2010 14:38:05 -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=EbHvnvzlSHy7P7gdbSr0oHouwge1YXZlwyQzVLUkIQ0=; b=R1PARLcRUVfzxM40qIjtrAnMd3iQ5/imbT0ScuHFc3juyhtIxjWMe7mNMu7CM9tWQg u4sThLIqOOMOvr7hfirI+6x+gL+9w83GW+eh3Cg1RCqvnO+7yRKQXzotMrRIUfk1VK7T zSYddwi0yVN65sD2/csUa05pFk82kLEoyk7Fg= 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=qZP1PvOQYdciNzncJyaIQXYxDcwN9okAdRjXIoAXKixmPvaEPvxu10cuHmwuxDVb3q 0eH50TZ6mduYxRGXV3xHOdAypQn9QkNqg8NsdkvREkthS9GvcZnoz3w5y6B+r0lVYIAS THgsKS4VCI/eKzvxN+KvJ6HzJYcVac6JUVHT8= MIME-Version: 1.0 Received: by 10.213.104.203 with SMTP id q11mr2711354ebo.12.1282513085510; Sun, 22 Aug 2010 14:38:05 -0700 (PDT) Received: by 10.14.45.66 with HTTP; Sun, 22 Aug 2010 14:38:05 -0700 (PDT) In-Reply-To: <44811.1282483957@nsa.vix.com> References: <20100820220814.54488.qmail@joyce.lan> <44811.1282483957@nsa.vix.com> Date: Sun, 22 Aug 2010 14:38:05 -0700 Message-ID: Subject: Re: [dnsext] Re: Problem statement additions From: Ted Hardie To: Paul Vixie 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 Sun, Aug 22, 2010 at 6:32 AM, Paul Vixie wrote: >> Date: Fri, 20 Aug 2010 15:51:12 -0700 >> From: Ted Hardie >> >> I'm a bit concerned about "look and see what DNS records the other names >> have". =C2=A0CNAME works because it functions to identify the one name a= t >> which the RRs reside. =C2=A0I think anything we come up with should have= that >> same property--there should be one entry where the data is, whatever >> mechanisms are necessary to point to that entry in a safe and sane >> manner. > > disagreed. > > we don't have that today, and we don't need it anyway. =C2=A0gethostbynam= e() can > return many addresses and many aliases, and gethostbyaddr() can do likewi= se, > and someone who wants to know _all_ the names by which a host is reachabl= e > has to call both (like getruserok() does.) The way the man page for gethostbyname and gethostbyaddr runs, though, puts the structure this way: struct hostent { char *h_name; /* official name of host */ char **h_aliases; /* alias list */ int h_addrtype; /* host address type */ int h_length; /* length of address */ char **h_addr_list; /* list of addresses from name server = */ }; #define h_addr h_addr_list[0] /* address, for backward compatibility= */ The members of this structure are: h_name Official name of the host. h_aliases A NULL-terminated array of alternate names for the host. h_addrtype The type of address being returned; usually AF_INET. h_length The length, in bytes, of the address. h_addr_list A NULL-terminated array of network addresses for the host= . Host addresses are returned in network byte order. h_addr The first address in h_addr_list; this is for backward compatibility. This actually tends to reinforce the common view that there is one "real" name and a list of aliases. The number of addresses (and the address families they fall in) is actually kind of a different question than what I meant to raise). To try to refocus this, would you expect anyone using gethostbya= ddr() to find the names of a host to look up further RRs at the h_name or one of the names found in the h_aliases array? > >> ... >> >> To put this another way, if the semantics of this are >> "$variable.humor.example is a valid alternate to >> $variable.humour.example, please check both for any RR you're interested >> in", I think the apps confusion will overwhelm any benefit. > > agreed. > >> So folks realize that this is not just a pure hypothetical, consider the >> case of .=E4=B8=AD=E5=9B=BD and .=E4=B8=AD=E5=9C=8B. =C2=A0If one is can= onical and the other a variant, we >> have the CNAME-on-steroids case. =C2=A0But if the domain administrators = wish >> to allow=E9=A6=99=E6=B8=AF=E3=80=82=E4=B8=AD=E5=9C=8B (Hong Kong, China,= using the complex characters in use >> in Hong Kong) to be primary but prefer =E5=8C=97=E4=BA=AC=E3=80=82=E4=B8= =AD=E5=9B=BD (Beijing, China, using >> the simplified characters in use in Beijing), to be primary, a >> domain-level solution at the .=E4=B8=AD=E5=9B=BD=EF=BC=8F=E4=B8=AD=E5=9C= =8B level may actually be out of the >> question. =C2=A0Which is an alias and which the target will vary below t= hat >> point. > > yes. =C2=A0but we're presuming a new RR or new placement of existing RR's= as a > way for IDN-aware apps to do extra work to get some extra functionality. > >> I fear that my own muddled thinking on these examples may hinder the >> question, so I'll try to repeat it succinctly: "Can we agree that any >> solution can rely on there being a single entry at which all RRs other >> than pointers are found?" > > i don't agree on this, since i know how A/AAAA/PTR clouds work today. > I think cname+bname actually falls into the category I'm trying to lay out, and the origin and shadow zones of the dnsshadow draft does as well. Do you see cases in either of these where humor.example and humour.example are related but the names below them have RRs in both? That is where a query to geek.humor.example must be repeated to geek.humour.example in order to collect a full set of the relevant RRs? regards, Ted Hardie From owner-namedroppers@ops.ietf.org Sun Aug 22 20:04: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 E1ED73A680A; Sun, 22 Aug 2010 20:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.853 X-Spam-Level: X-Spam-Status: No, score=-108.853 tagged_above=-999 required=5 tests=[AWL=0.242, 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, 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 kvLbiHNTUgf2; Sun, 22 Aug 2010 20:04:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C7C73A67C3; Sun, 22 Aug 2010 20:04:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnNEZ-000EOa-DC for namedroppers-data0@psg.com; Mon, 23 Aug 2010 02:58:03 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnNEV-000EOI-AA for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 02:58:00 +0000 Received: (qmail 51319 invoked from network); 23 Aug 2010 02:57:52 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 23 Aug 2010 02:57:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=k1008; olt=johnl@user.iecc.com; bh=l5iTr3vAU9YwY4u0AcsWOEosqhcycEWczueXrZbTLJQ=; b=PY8yGedckyl/wvn5qL/3/Qv+pl/podfILpC33a36ia3vohR6ZwhokEHHuH2S8Ht/eWUY3Ib5N9WhriwXDk3tSOF1z6WDxBjeIeIP77CQbEG0EgI0ylGxvGut8yDKCDtjkGvluIm0YL7NHTVD2EjBtZ7MFCiioGifIzISG1xKToQ= Date: 23 Aug 2010 02:57:47 -0000 Message-ID: <20100823025747.35936.qmail@joyce.lan> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Problem statement additions In-Reply-To: <44811.1282483957@nsa.vix.com> Organization: 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: >> I fear that my own muddled thinking on these examples may hinder the >> question, so I'll try to repeat it succinctly: "Can we agree that any >> solution can rely on there being a single entry at which all RRs other >> than pointers are found?" Nope. (That is, I agree with Paul.) Think of the well-worn HTTPS example, where names that are "the same" nonetheless have different IP addresses.* The more I think about it, the more I think we need to separate the declaration "A and B are the same" from whatever other RRs A and B happen to have. My goal is to provide enough hints in the DNS that an application server that has been configured to handle some set of names can find out all the other names that are "the same" and automatically handle those, too. I'm not too worried if there are ways that people can screw up the hints; I'm more concerned that there be some way to publish adequate hints if you, or more likely your DNS maintenance scripts, know what they're doing. I realize that there might be a combinational explosion if there are aliases at multiple levels of naming, but if there are 10,000 different ways to spell some resource's name, I'd sure rather there be some way for the servers to discover them and configure themselves. If a web server has 10,000 different names for the same web page, that's not necessarily a problem, so long as we don't have to type them all into httpd.conf. R's, John * - With sufficient upgrades to every web server and browser in the world we can force this particular application to work with CNAMEs, and a single A record, but it's an example. From owner-namedroppers@ops.ietf.org Sun Aug 22 22:49: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 690943A6886; Sun, 22 Aug 2010 22:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.023 X-Spam-Level: X-Spam-Status: No, score=-9.023 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 soGJZoaO38pO; Sun, 22 Aug 2010 22:49:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E9FF3A67A1; Sun, 22 Aug 2010 22:49:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnPrA-00059L-Ay for namedroppers-data0@psg.com; Mon, 23 Aug 2010 05:46:04 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnPr8-00058w-4E for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 05:46:02 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAESncUxAZnwM/2dsb2JhbACgL3GbLZpjhTcEiXY X-IronPort-AV: E=Sophos;i="4.56,255,1280707200"; d="scan'208";a="150538753" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Aug 2010 05:44:00 +0000 Received: from [192.165.72.14] (ams3-vpn-dhcp7310.cisco.com [10.61.92.141]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7N5hxYF023900; Mon, 23 Aug 2010 05:43:59 GMT Subject: Re: [dnsext] Re: Problem statement additions Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100823025747.35936.qmail@joyce.lan> Date: Mon, 23 Aug 2010 07:43:58 +0200 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> References: <20100823025747.35936.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 aug 2010, at 04.57, John Levine wrote: > The more I think about it, the more I think we need to separate the > declaration "A and B are the same" from whatever other RRs A and B > happen to have. The question is not whether A and B are the same. It is "Resolving A and = B leads to the same response". But I agree with Ted that it would be very good if this problem is = solved by having B be the canonical name, and A refer to it. And then = have the referral from A to B in such a way that application layer do = know that is what should happen. Applications then part from getting the = same response when resolving A and B also get to know that B is the = canonical name. And because of that B is what is to be used on the = application layer. For example the HOST header of http. I do not see any need though for "given B, let me know all A that refer = to it as the canonical name". Specifically as this referral might happen = on multiple times on each level in the name hierarchy which implies the = number of A will explode exponentially. Patrik From owner-namedroppers@ops.ietf.org Sun Aug 22 23:15: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 32D3C3A6971; Sun, 22 Aug 2010 23:15: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: -96.858 X-Spam-Level: X-Spam-Status: No, score=-96.858 tagged_above=-999 required=5 tests=[AWL=-1.307, BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 q2lu1OR1RHIB; Sun, 22 Aug 2010 23:15:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 427053A6969; Sun, 22 Aug 2010 23:15:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnQH0-00085w-Vb for namedroppers-data0@psg.com; Mon, 23 Aug 2010 06:12:46 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnQGy-00085L-MR for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 06:12:45 +0000 Received: (eyou send program); Mon, 23 Aug 2010 14:12:42 +0800 Message-ID: <482543962.24067@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, 23 Aug 2010 14:12:42 +0800 Message-ID: <1A2D95BFAF0F46F9B1FF5FEE4EB001CA@LENOVO47E041CF> From: "Jiankang YAO" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "John Levine" Cc: References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> Subject: Re: [dnsext] Re: Problem statement additions Date: Mon, 23 Aug 2010 14:12:47 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBhdHJpayBG5Gx0c3Ry9m0i IDxwYWZAY2lzY28uY29tPg0KVG86ICJKb2huIExldmluZSIgPGpvaG5sQGllY2MuY29tPg0KQ2M6 IDxuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnPg0KU2VudDogTW9uZGF5LCBBdWd1c3QgMjMsIDIw MTAgMTo0MyBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIFJlOiBQcm9ibGVtIHN0YXRlbWVudCBh ZGRpdGlvbnMNCg0KDQoNCk9uIDIzIGF1ZyAyMDEwLCBhdCAwNC41NywgSm9obiBMZXZpbmUgd3Jv dGU6DQoNCj4+IFRoZSBtb3JlIEkgdGhpbmsgYWJvdXQgaXQsIHRoZSBtb3JlIEkgdGhpbmsgd2Ug bmVlZCB0byBzZXBhcmF0ZSB0aGUNCj4+IGRlY2xhcmF0aW9uICJBIGFuZCBCIGFyZSB0aGUgc2Ft ZSIgZnJvbSB3aGF0ZXZlciBvdGhlciBSUnMgQSBhbmQgQg0KPiA+aGFwcGVuIHRvIGhhdmUuDQoN Cj5UaGUgcXVlc3Rpb24gaXMgbm90IHdoZXRoZXIgQSBhbmQgQiBhcmUgdGhlIHNhbWUuIEl0IGlz ICJSZXNvbHZpbmcgQSBhbmQgQiBsZWFkcyB0byB0aGUgc2FtZSByZXNwb25zZSIuDQoNCisxLg0K ZXhjZWxsZW50IHBvaW50Lg0KDQpKaWFua2FuZyBZYW8NCg0K From owner-namedroppers@ops.ietf.org Mon Aug 23 01:05: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 0D6373A69B0; Mon, 23 Aug 2010 01:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.042 X-Spam-Level: * X-Spam-Status: No, score=1.042 tagged_above=-999 required=5 tests=[AWL=-0.252, 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 CkaaHs1mQFjJ; Mon, 23 Aug 2010 01:05:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 167EE3A69A2; Mon, 23 Aug 2010 01:05:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnRxe-000KpI-HN for namedroppers-data0@psg.com; Mon, 23 Aug 2010 08:00:54 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnRxb-000Kor-RB for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 08:00:52 +0000 Received: from [192.168.1.68] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id A7D57C56953; Mon, 23 Aug 2010 09:00:48 +0100 (BST) Date: Mon, 23 Aug 2010 09:01:06 +0100 From: Alex Bligh Reply-To: Alex Bligh To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , John Levine cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Re: Problem statement additions Message-ID: <6C1512DA57AC548FDED4852B@nimrod.local> In-Reply-To: <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 23 August 2010 07:43:58 +0200 Patrik F=C3=A4ltstr=C3=B6m = wrote: > The question is not whether A and B are the same. It is "Resolving A and > B leads to the same response". Is it? I thought we already had examples where this is counterproductive in making 2 names "act the same". If the idea is to ensure at all times identical resolution, xNAME works perfectly well. But I don't think that /is/ the problem (or at least is not a useful problem to solve). --=20 Alex Bligh From dnsext-archive@ietf.org Mon Aug 23 04:09: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 6AD0A3A69DB for ; Mon, 23 Aug 2010 04:09:11 -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): Subject: ...-archive@ietf.org VIAGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -41.606 X-Spam-Level: X-Spam-Status: No, score=-41.606 tagged_above=-999 required=5 tests=[BAYES_80=2, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_08=1.787, 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, SUBJECT_NEEDS_ENCODING=0.001, 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 TgBdoyprJVlz for ; Mon, 23 Aug 2010 04:09:04 -0700 (PDT) Received: from 20158199056.user.veloxzone.com.br (20158199056.user.veloxzone.com.br [201.58.199.56]) by core3.amsl.com (Postfix) with SMTP id 8A67B3A69CF for ; Mon, 23 Aug 2010 04:09:03 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org VIAGRA ® Official Seller -02% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100823110903.8A67B3A69CF@core3.amsl.com> Date: Mon, 23 Aug 2010 04:09:03 -0700 (PDT)
Click here!

From owner-namedroppers@ops.ietf.org Mon Aug 23 04:17: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 1D6293A6955; Mon, 23 Aug 2010 04:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, J_CHICKENPOX_15=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 nU0NUT-e0kVz; Mon, 23 Aug 2010 04:17:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 255D23A672E; Mon, 23 Aug 2010 04:17:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnUxu-0002Lh-42 for namedroppers-data0@psg.com; Mon, 23 Aug 2010 11:13:22 +0000 Received: from [2001:4f8:0:2::2b] (helo=mx.pao1.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnUxr-0002LJ-Sb for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 11:13:19 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 76DFDC941A; Mon, 23 Aug 2010 11:13:17 +0000 (UTC) (envelope-from woolf@isc.org) Received: by farside.isc.org (Postfix, from userid 10265) id 48461E60D8; Mon, 23 Aug 2010 11:13:17 +0000 (UTC) Date: Mon, 23 Aug 2010 11:13:17 +0000 From: Suzanne Woolf To: Patrik F?ltstr?m Cc: John Levine , namedroppers@ops.ietf.org Subject: scalability constraints? Re: [dnsext] Re: Problem statement additions Message-ID: <20100823111317.GA3450@farside.isc.org> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> 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 Mon, Aug 23, 2010 at 07:43:58AM +0200, Patrik F?ltstr?m wrote: > > I do not see any need though for "given B, let me know all A that > refer to it as the canonical name". Specifically as this referral > might happen on multiple times on each level in the name hierarchy > which implies the number of A will explode exponentially. This raises the question of what scalability assumptions are being made in this discussion. Exponential explosions of anything are clearly to be avoided if at all possible. At the same time, however, my sense so far for what people will reasonably want to do in terms of counts or chains of things they want to be "the same" will be in small numbers, either at a single level or recursing down multiple subdomains. Does it follow that "unbounded scalability" should be an explicit non-goal for this endeavor? What kind of limits sound sensible? thx, Suzanne From owner-namedroppers@ops.ietf.org Mon Aug 23 04:54: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 4D4133A69F5; Mon, 23 Aug 2010 04:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-5.517, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZagEwqRaVG2L; Mon, 23 Aug 2010 04:54:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 02CD63A6869; Mon, 23 Aug 2010 04:54:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnVYu-0006vf-TM for namedroppers-data0@psg.com; Mon, 23 Aug 2010 11:51:36 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnVYs-0006us-7d for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 11:51:34 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7NBpU2H087923 for ; Mon, 23 Aug 2010 07:51:30 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o7NBpUNq087922 for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 07:51:30 -0400 (EDT) (envelope-from namedroppers) Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmZiz-000Dxo-A6 for namedroppers@ops.ietf.org; Fri, 20 Aug 2010 22:06:09 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0GADSZbkyrRN+J/2dsb2JhbACHa5d1WAJxn1KbVYU3BIlzgm2ELw X-IronPort-AV: E=Sophos;i="4.56,242,1280707200"; d="scan'208";a="243176315" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 20 Aug 2010 22:06:08 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7KM671Z019634; Fri, 20 Aug 2010 22:06:08 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 21 Aug 2010 00:06:06 +0200 Received: from 128.107.191.114 ([128.107.191.114]) by XMB-AMS-106.cisco.com ([144.254.74.81]) with Microsoft Exchange Server HTTP-DAV ; Fri, 20 Aug 2010 22:06:05 +0000 Subject: Re: [dnsext] Problem statement additions References: <20100819181005.47680.qmail@joyce.lan> <22590.1282242926@nsa.vix.com> <24409.1282244875@nsa.vix.com> <39785.1282261320@nsa.vix.com> <54594.1282275654@nsa.vix.com> <20100820162403.GE96071@shinkuro.com> Content-Transfer-Encoding: quoted-printable Thread-Topic: [dnsext] Problem statement additions Thread-Index: ActAs+K9BqtnFCQgQxyHUcRGxiAwYg== From: "Patrik Faltstrom (pfaltstr)" Content-Type: text/plain; charset="us-ascii" In-Reply-To: Message-ID: Date: Sat, 21 Aug 2010 00:04:48 +0200 To: "Paul Hoffman" Cc: "Andrew Sullivan" , MIME-Version: 1.0 (iPhone Mail 8A400) X-OriginalArrivalTime: 20 Aug 2010 22:06:06.0739 (UTC) FILETIME=[E3531E30:01CB40B3] 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 20 aug 2010, at 19:25, Paul Hoffman wrote: > The document is a list of use cases (section 2) and proposals (section 3).= The document itself seems to describe the problems that DNS users have well= From owner-namedroppers@ops.ietf.org Mon Aug 23 04:54: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 4FB413A69F5; Mon, 23 Aug 2010 04:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.823 X-Spam-Level: X-Spam-Status: No, score=-2.823 tagged_above=-999 required=5 tests=[AWL=-4.395, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1FyXs157i6b; Mon, 23 Aug 2010 04:54:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 58C4B3A6869; Mon, 23 Aug 2010 04:54:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnVZq-00073X-TF for namedroppers-data0@psg.com; Mon, 23 Aug 2010 11:52:34 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnVZn-00072I-7N for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 11:52:31 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7NBqT2p087936 for ; Mon, 23 Aug 2010 07:52:29 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o7NBqTm5087935 for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 07:52:29 -0400 (EDT) (envelope-from namedroppers) Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnQOI-00097j-Iz for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 06:20:19 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAHACqwcUyrRN+J/2dsb2JhbACDF4RTl2laAnGbIYlekRGBIoMicwSJdoJthDE X-IronPort-AV: E=Sophos;i="4.56,255,1280707200"; d="scan'208";a="175391073" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 23 Aug 2010 06:20:18 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7N6KFIl014311; Mon, 23 Aug 2010 06:20:17 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Aug 2010 08:20:14 +0200 Received: from 128.107.191.32 ([128.107.191.32]) by XMB-AMS-106.cisco.com ([144.254.74.81]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 Aug 2010 06:20:14 +0000 Subject: Re: [dnsext] Re: Problem statement additions References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <482543962.24067@cnnic.cn> Content-Transfer-Encoding: base64 From: "Patrik Faltstrom (pfaltstr)" Content-Type: text/plain; charset="utf-8" In-Reply-To: <482543962.24067@cnnic.cn> Message-ID: <3DE1ABC9-48F6-4F8C-9900-0AF0CDAB176A@cisco.com> Date: Mon, 23 Aug 2010 08:20:11 +0200 To: "Jiankang YAO" Cc: "John Levine" , Thread-Topic: [dnsext] Re: Problem statement additions Thread-Index: ActCiz+jsnDLgUx6QMOD8ZD+0hPIPw== MIME-Version: 1.0 (iPhone Mail 8A400) X-OriginalArrivalTime: 23 Aug 2010 06:20:14.0900 (UTC) FILETIME=[3FD4F740:01CB428B] 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. ] T24gMjMgYXVnIDIwMTAsIGF0IDA4OjEyLCAiSmlhbmthbmcgWUFPIiA8eWFvamtAY25uaWMuY24+ IHdyb3RlOg0KDQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPiBGcm9tOiAi UGF0cmlrIEbDpGx0c3Ryw7ZtIiA8cGFmQGNpc2NvLmNvbT4NCj4gVG86ICJKb2huIExldmluZSIg PGpvaG5sQGllY2MuY29tPg0KPiBDYzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQo+IFNl bnQ6IE1vbmRheSwgQXVndXN0IDIzLCAyMDEwIDE6NDMgUE0NCj4gU3ViamVjdDogUmU6IFtkbnNl eHRdIFJlOiBQcm9ibGVtIHN0YXRlbWVudCBhZGRpdGlvbnMNCj4gDQo+IA0KPiANCj4gT24gMjMg YXVnIDIwMTAsIGF0IDA0LjU3LCBKb2huIExldmluZSB3cm90ZToNCj4gDQo+Pj4gVGhlIG1vcmUg SSB0aGluayBhYm91dCBpdCwgdGhlIG1vcmUgSSB0aGluayB3ZSBuZWVkIHRvIHNlcGFyYXRlIHRo ZQ0KPj4+IGRlY2xhcmF0aW9uICJBIGFuZCBCIGFyZSB0aGUgc2FtZSIgZnJvbSB3aGF0ZXZlciBv dGhlciBSUnMgQSBhbmQgQg0KPj4+IGhhcHBlbiB0byBoYXZlLg0KPiANCj4+IFRoZSBxdWVzdGlv biBpcyBub3Qgd2hldGhlciBBIGFuZCBCIGFyZSB0aGUgc2FtZS4gSXQgaXMgIlJlc29sdmluZyBB IGFuZCBCIGxlYWRzIHRvIHRoZSBzYW1lIHJlc3BvbnNlIi4NCj4gDQo+ICsxLg0KPiBleGNlbGxl bnQgcG9pbnQuDQoNCkxldCBtZSBjaGFuZ2UgbXkgb3duIHdvcmRpbmcuDQoNCiJsZWFkcyB0byB0 aGUgc2FtZSByZXN1bHQiIChzbyB0aGF0IGFwcGxpY2F0aW9ucyBjYW4gZG8gInRoZSByaWdodCB0 aGluZyIsIHJlZ2FyZGluZyB1c2VyIGV4cGVyaWVuY2UpLiBUaGUgcmVzcG9uc2VzIChmcm9tIERO UykgbWlnaHQgYmUgZGlmZmVyZW50Lg0KDQogICBQYXRyaWsNCg0KPiANCj4gSmlhbmthbmcgWWFv DQo+IA0K From owner-namedroppers@ops.ietf.org Mon Aug 23 04:54: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 3F7013A69F5; Mon, 23 Aug 2010 04:54:45 -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 Iy4us4fuLrZd; Mon, 23 Aug 2010 04:54:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 34C723A6869; Mon, 23 Aug 2010 04:54:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnVZS-0006yp-Uw for namedroppers-data0@psg.com; Mon, 23 Aug 2010 11:52:10 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnVZP-0006yG-Kr for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 11:52:08 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7NBq5uD087930 for ; Mon, 23 Aug 2010 07:52:05 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o7NBq56Y087929 for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 07:52:05 -0400 (EDT) (envelope-from namedroppers) Received: from [2001:4f8:fff7:1::5] (helo=mail1.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OmoSo-000Ay8-4y for namedroppers@ops.ietf.org; Sat, 21 Aug 2010 13:50:26 +0000 Received: from [205.157.206.7] (helo=[192.168.1.214]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OmoSc-000AwK-OC; Sat, 21 Aug 2010 13:50:25 +0000 Message-ID: <4C6FD98E.2020502@ntp.org> Date: Sat, 21 Aug 2010 09:50:06 -0400 From: Danny Mayer Reply-To: mayer@ntp.org Organization: NTP User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <18374.1281714027@nsa.vix.com> In-Reply-To: <18374.1281714027@nsa.vix.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 205.157.206.7 X-SA-Exim-Rcpt-To: vixie@isc.org, namedroppers@ops.ietf.org X-SA-Exim-Mail-From: mayer@ntp.org Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) 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 8/13/2010 11:40 AM, Paul Vixie wrote: >> Date: Fri, 13 Aug 2010 10:33:45 +0100 >> From: Alex Bligh >> >> I agree that this is being driven partly (mostly?) by the >> registry/registrar community. However, what I don't understand is that >> even if we come up with a magic DNS aliasing solution so that Ai.Bj >> always gives the same result as A1.B1, what is the use of it if it >> doesn't work at the application layer too? number of users of web >> browsers and email exceed number of users of dig by many orders of >> magnitude. I have yet to find one application the "magic xNAME" proposal >> would work with out the box. > > there's no way to get total sameness without application changes. consider > an application who looks for the A and AAAA for an MX target, and then > looks for PTR's for the resulting addresses, and insists that the one be > found within the other. if the original name is Ai.Bj then there's not > enough state in DNS itself to ensure that the final name is also Ai.Bj, > it's going to be A1.B1. this example is not contrived. this yields a hard > choice: add a constraint. require that Ai.Bj be normalized to A1.B1 > before it is used either for DNS lookups or any host identity (like SMTP > HELO). this means we wouldn't have true "sameness" across the names > {A1.B1, Ai.Bj}, one would be a first class name, the other would be a > second class name. Why is SMTP a problem? You can always set up the MX records for aliased zones to point to just one FQDN and have the PTR record point back to the same FQDN. Or am I looking at it from the wrong end? Danny From dnsext-archive@lists.ietf.org Mon Aug 23 04: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 EB9643A6819 for ; Mon, 23 Aug 2010 04:57:32 -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 Official ; Mon, 23 Aug 2010 04:57:32 -0700 (PDT) Received: from 130-177-133-95.pool.ukrtel.net (130-177-133-95.pool.ukrtel.net [95.133.177.130]) by core3.amsl.com (Postfix) with ESMTP id 92D053A69F5 for ; Mon, 23 Aug 2010 04:57:31 -0700 (PDT) From: USA VIAGRA ® Official To: dnsext-archive@lists.ietf.org Subject: dnsext-archive@lists.ietf.org VIAGRA ® Official Seller -59% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100823115731.92D053A69F5@core3.amsl.com> Date: Mon, 23 Aug 2010 04:57:31 -0700 (PDT)
Click here!

From owner-namedroppers@ops.ietf.org Mon Aug 23 05:02: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 1EB893A69E3; Mon, 23 Aug 2010 05:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.855 X-Spam-Level: X-Spam-Status: No, score=-108.855 tagged_above=-999 required=5 tests=[AWL=0.240, 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, 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 vrXyMmzrvNen; Mon, 23 Aug 2010 05:02:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D71AA3A6864; Mon, 23 Aug 2010 05:02:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnVhO-0008Hd-0f for namedroppers-data0@psg.com; Mon, 23 Aug 2010 12:00:22 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnVhK-0008HE-SS for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 12:00:19 +0000 Received: (qmail 73578 invoked from network); 23 Aug 2010 12:00:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=JwaQFTrh0okYZQae16Xn/nESXvswzLaQGy8u6gDjhrI=; b=vBzd/eZ4NdrfzPYPFWPqrAwDv5Ws7MgJ+Pc2ugCRrMogY3SBAhjIu+OU73iyrSDbI+PTzoDfMKg3MqgQ4MivRAU3Ef2xhJuv0WexHF+H0Lybnp5SJ5nm6FLdq8YhuTpg5RYx+wAMowheFBUImiR7RA6dKaZfALXL9BIICkrqnkQ= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Aug 2010 11:59:55 -0000 Date: 23 Aug 2010 08:00:11 -0400 Message-ID: From: "John R. Levine" To: "Patrik Faltstrom (pfaltstr)" Cc: "Jiankang YAO" , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Problem statement additions In-Reply-To: <3DE1ABC9-48F6-4F8C-9900-0AF0CDAB176A@cisco.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <482543962.24067@cnnic.cn> <3DE1ABC9-48F6-4F8C-9900-0AF0CDAB176A@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Let me change my own wording. > > "leads to the same result" (so that applications can do "the right > thing", regarding user experience). The responses (from DNS) might be > different. Sure. That's what I meant by "A and B are the same." I gather that we agree that it does NOT mean that there is a simple mechanical relationship between the two sets of RRs. R's, John From owner-namedroppers@ops.ietf.org Mon Aug 23 05:17: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 6AA383A69F8; Mon, 23 Aug 2010 05:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.006 X-Spam-Level: X-Spam-Status: No, score=-9.006 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 fVwGBU6Sre0q; Mon, 23 Aug 2010 05:17:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 67E113A69E3; Mon, 23 Aug 2010 05:17:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnVuS-000Ait-GU for namedroppers-data0@psg.com; Mon, 23 Aug 2010 12:13:52 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnVuL-000Ahw-TW for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 12:13:46 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMGAF8DckxAZnwN/2dsb2JhbACTJY0LcZ04mymFNwSJdg X-IronPort-AV: E=Sophos;i="4.56,257,1280707200"; d="scan'208";a="150825673" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Aug 2010 12:13:38 +0000 Received: from [192.165.72.14] (ams3-vpn-dhcp7310.cisco.com [10.61.92.141]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7NCDbED028903; Mon, 23 Aug 2010 12:13:37 GMT Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4C6FD98E.2020502@ntp.org> Date: Mon, 23 Aug 2010 14:13:37 +0200 Cc: Paul Vixie , namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3EFF9C9D-DBEA-4498-B727-B003812C6602@cisco.com> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <18374.1281714027@nsa.vix.com> <4C6FD98E.2020502@ntp.org> To: mayer@ntp.org X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 aug 2010, at 15.50, Danny Mayer wrote: > Why is SMTP a problem? You can always set up the MX records for = aliased > zones to point to just one FQDN and have the PTR record point back to > the same FQDN. Or am I looking at it from the wrong end? Because in reality you do not have A1.B1 and A2.B2. You might have = instead, for example: AnBnCnDn.EnFnGnHn where you have n=3D1,..,n=3D4 and a delegation at the = period. So in reality you might in this example talk about more than two = permutations (although of course not all values and combinations of = n=3D1,..,n=3D4 makes any sense). Patrik From owner-namedroppers@ops.ietf.org Mon Aug 23 05:21: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 10EE83A69F8; Mon, 23 Aug 2010 05:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.689 X-Spam-Level: X-Spam-Status: No, score=-8.689 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, 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 xoyFoI3fbaUS; Mon, 23 Aug 2010 05:21:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EEF383A69A0; Mon, 23 Aug 2010 05:21:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnVzN-000BW0-KH for namedroppers-data0@psg.com; Mon, 23 Aug 2010 12:18:57 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnVzJ-000BVA-IC for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 12:18:53 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANYDckxAZnwM/2dsb2JhbACgMHGdQJsphTcEiXY X-IronPort-AV: E=Sophos;i="4.56,257,1280707200"; d="scan'208";a="150642983" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Aug 2010 12:18:51 +0000 Received: from [192.165.72.14] (ams3-vpn-dhcp7310.cisco.com [10.61.92.141]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7NCIodv005759; Mon, 23 Aug 2010 12:18:50 GMT Subject: Re: scalability constraints? Re: [dnsext] Re: Problem statement additions Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100823111317.GA3450@farside.isc.org> Date: Mon, 23 Aug 2010 14:18:50 +0200 Cc: John Levine , namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <20100823111317.GA3450@farside.isc.org> To: Suzanne Woolf X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 aug 2010, at 13.13, Suzanne Woolf wrote: > On Mon, Aug 23, 2010 at 07:43:58AM +0200, Patrik F?ltstr?m wrote: >>=20 >> I do not see any need though for "given B, let me know all A that >> refer to it as the canonical name". Specifically as this referral >> might happen on multiple times on each level in the name hierarchy >> which implies the number of A will explode exponentially. >=20 > This raises the question of what scalability assumptions are being > made in this discussion. >=20 > Exponential explosions of anything are clearly to be avoided if at all > possible. At the same time, however, my sense so far for what people > will reasonably want to do in terms of counts or chains of things they > want to be "the same" will be in small numbers, either at a single > level or recursing down multiple subdomains.=20 >=20 > Does it follow that "unbounded scalability" should be an explicit > non-goal for this endeavor? What kind of limits sound sensible? I do not think we talk about "unbounded scalability", but if we have a = delegation between two zones, and we have such "aliases" in both the = parent and child zone, then we even at that point in time start to get = problems keeping track of all permutations. If we instead in the parent zone can have pointer(s) from all aliases to = whatever the canonical name is, and then repeat that at each level in = the namespace, then the number of permutations do not increase and we = get a linear growth of "stuff" in the DNS. I think we already agreed to = that (i.e. something that works similar to DNAME). But, we still get the same explosion in the application layer, for = example the HTTP HOST header, if not the application layer get some = "hint" of which one of multiple possible domain names is the canonical = one. Yes, of course the application might have all combinations of characters = enumerated, but...well...it would be "nice" if the application layer get = to know which hostname is the canonical one. Patrik From owner-namedroppers@ops.ietf.org Mon Aug 23 06:22: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 96EDE3A6A42; Mon, 23 Aug 2010 06:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.719 X-Spam-Level: X-Spam-Status: No, score=-108.719 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HABEAS_ACCREDITED_SOI=-4.3, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_BSP_TRUSTED=-4.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 kkah5IgjN0Ni; Mon, 23 Aug 2010 06:22:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 285A03A6A35; Mon, 23 Aug 2010 06:22:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnWuk-000LR9-LN for namedroppers-data0@psg.com; Mon, 23 Aug 2010 13:18:14 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnWuh-000LQi-Jz for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 13:18:12 +0000 Received: (qmail 13770 invoked from network); 23 Aug 2010 13:18:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=DOPEOuyKOdDXDD7v8M19JubIQ6Kh78b5pOpM2qxRppw=; b=LN+LXLxl+ASsf4zkF8bwcCUaz+9M3IDL2zIPKy4v59MrdHpcGkOUxhsbZBtASly4uCRR5haSEWK1rw75F1vIq++Qx+o6hthSPPURNXML+LFCDmYTkc6mK4XIF31sxF5cvhiVIHZFWO2G9EjQTFD1JFocyzLEaXKYa0q7O33Wm7I= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Aug 2010 13:17:48 -0000 Date: 23 Aug 2010 09:18:04 -0400 Message-ID: From: "John R. Levine" To: "=?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?=" Cc: namedroppers@ops.ietf.org Subject: [dnsext] Predictive vs. reactive name aliasing models In-Reply-To: <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; 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: > I do not see any need though for "given B, let me know all A that refer > to it as the canonical name". We seem to have two different models of auto-configuration here, which I'll call predictive and reactive. In the predictive model, a server knows that it's been configured for A, looks around to find all the aliases for A (call them B through Z), adds them to its configuration, then doesn't worry about aliases any more, at least not until the next time it checks to see if the list of aliases has changed. In the reactive model, a server does nothing special until it sees a name show up for name Q, then in real time looks up Q, finds that it's an alias for A, and then proceeds more or less as though the request had been for A. The reactive model certainly has nicer scaling properties, since the application doesn't have to preconfigure or even know all of the names it might have to handle. Really, the only flaw I can see with it is that IT DOESN'T WORK. Please consider, once again, the hoary HTTPS example with different names on different IPs. The server doesn't know what IPs to listen to until it knows what names it has to handle. Having a certain amount of experience with mail servers, I wouldn't want to run a server that needed to figure out on the fly whether each random incoming message is for a domain it's supposed to handle. We could explicitly say that we're only going to handle situations that work with the reactive model, but if that were adequate, CNAMEs would have solved all our problems. I'm not opposed to supporting the reactive model, but if you want to solve the actual problems that people have making multiple names "the same", you have to provide some way for an applications to enumerate the names they handle so they can configure themselves appropriately. The enumeration doesn't have to be silly, we can probably figure out some way to encode wildcards so the DNS doesn't have to expand every cross-product, but you can't avoid it. R's, John From owner-namedroppers@ops.ietf.org Mon Aug 23 06:45: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 08DF03A6A70; Mon, 23 Aug 2010 06:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.667 X-Spam-Level: X-Spam-Status: No, score=-8.667 tagged_above=-999 required=5 tests=[AWL=-1.072, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, 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 aJBhlK+5nrYT; Mon, 23 Aug 2010 06:45:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E0D153A6A64; Mon, 23 Aug 2010 06:45:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnXG2-000OdK-Nu for namedroppers-data0@psg.com; Mon, 23 Aug 2010 13:40:14 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnXFz-000Oca-1u for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 13:40:11 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFsXckxAZnwN/2dsb2JhbACgLnGeaps6hTcEiXY X-IronPort-AV: E=Sophos;i="4.56,257,1280707200"; d="scan'208";a="150861562" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Aug 2010 13:40:09 +0000 Received: from [192.165.72.14] (dhcp-10-55-83-170.cisco.com [10.55.83.170]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7NDe8m8010486; Mon, 23 Aug 2010 13:40:09 GMT Subject: [dnsext] Re: Predictive vs. reactive name aliasing models Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Mon, 23 Aug 2010 15:40:08 +0200 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> To: "John R. Levine" X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 aug 2010, at 15.18, John R. Levine wrote: > We seem to have two different models of auto-configuration here, which = I'll call predictive and reactive. I am not talking about configuration at all. > In the predictive model, a server knows that it's been configured for = A, looks around to find all the aliases for A (call them B through Z), = adds them to its configuration, then doesn't worry about aliases any = more, at least not until the next time it checks to see if the list of = aliases has changed. >=20 > In the reactive model, a server does nothing special until it sees a = name show up for name Q, then in real time looks up Q, finds that it's = an alias for A, and then proceeds more or less as though the request had = been for A. No, a client is to use B for a service, finds it is an alias for A and = uses A when communicating with the server. The server only knows about = A, not B. There is no configuration "on the fly" going on. > We could explicitly say that we're only going to handle situations = that work with the reactive model, but if that were adequate, CNAMEs = would have solved all our problems. CNAME would have worked for the HTTPS aliasing problem if we did not = have the issue with "no other records should exist with the same owner", = and I think maybe CNAME+DNAME could work. > I'm not opposed to supporting the reactive model, but if you want to = solve the actual problems that people have making multiple names "the = same", you have to provide some way for an applications to enumerate the = names they handle so they can configure themselves appropriately. They only have to know about the canonical domain names clients will use = when communicating with them. Not the other aliases. > The enumeration doesn't have to be silly, we can probably figure out = some way to encode wildcards so the DNS doesn't have to expand every = cross-product, but you can't avoid it. Patrik From owner-namedroppers@ops.ietf.org Mon Aug 23 06:54: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 5CBC43A69F0; Mon, 23 Aug 2010 06:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.562 X-Spam-Level: X-Spam-Status: No, score=-108.562 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HABEAS_ACCREDITED_SOI=-4.3, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_BSP_TRUSTED=-4.3, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315, 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 C2+HTbCoz4Vk; Mon, 23 Aug 2010 06:54:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 328953A69D8; Mon, 23 Aug 2010 06:54:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnXQV-0000PX-SV for namedroppers-data0@psg.com; Mon, 23 Aug 2010 13:51:04 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnXQT-0000P0-HN for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 13:51:01 +0000 Received: (qmail 30579 invoked from network); 23 Aug 2010 13:51:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=FIf5in+ID5tNPIhoT0Afidc0Br1a9e++FF/am5lnHvw=; b=SHntU9iHHPo9A0OIMlFFUcui4q466hYF81MmBwKu4oskDrnwnIUNIOGApV2w+YJYu67HcUxptcps1fL2qB1yuPOoEwL5wtEJxs/HPnI93rvYioLe1AKneZnh+zGveRXnxJJS6OQGYJttZI2g+qmfseRpfDm9nemXmyJgDonp+yI= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Aug 2010 13:50:38 -0000 Date: 23 Aug 2010 09:50:54 -0400 Message-ID: From: "John R. Levine" To: "=?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?=" Cc: namedroppers@ops.ietf.org Subject: [dnsext] Re: Predictive vs. reactive name aliasing models In-Reply-To: <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > No, a client is to use B for a service, finds it is an alias for A and > uses A when communicating with the server. The server only knows about > A, not B. There is no configuration "on the fly" going on. Hmmn, so we upgrade billions of client programs rather than millions of servers. I suppose. I'm also thinking about the security model in which a client says "the user asked for B but I'm pretending he asked for A". At the very least, the server better verify that's an alias it approves of. R's, John From owner-namedroppers@ops.ietf.org Mon Aug 23 08:00: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 110683A6A31; Mon, 23 Aug 2010 08:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.764 X-Spam-Level: X-Spam-Status: No, score=-8.764 tagged_above=-999 required=5 tests=[AWL=-0.884, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 NNAEkiUiwDyr; Mon, 23 Aug 2010 08:00:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 13E9F3A657C; Mon, 23 Aug 2010 08:00:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnYQz-0009YT-7q for namedroppers-data0@psg.com; Mon, 23 Aug 2010 14:55:37 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnYQw-0009X7-K7 for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 14:55:34 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACsockxAZnwM/2dsb2JhbACgLnGfbZtIhTcEiXY X-IronPort-AV: E=Sophos;i="4.56,257,1280707200"; d="scan'208";a="150709929" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Aug 2010 14:55:33 +0000 Received: from [192.165.72.14] (dhcp-10-55-83-170.cisco.com [10.55.83.170]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7NEtWWY019524; Mon, 23 Aug 2010 14:55:33 GMT Subject: [dnsext] Re: Predictive vs. reactive name aliasing models Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Mon, 23 Aug 2010 16:55:32 +0200 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> To: "John R. Levine" X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 aug 2010, at 15.50, John R. Levine wrote: >> No, a client is to use B for a service, finds it is an alias for A = and uses A when communicating with the server. The server only knows = about A, not B. There is no configuration "on the fly" going on. >=20 > Hmmn, so we upgrade billions of client programs rather than millions = of servers. I suppose. Billions? Yes, I do talk about upgrading tons of stuff. You and I have had this discussion before on where to upgrade things, = and how to optimize. And we do have different idea on what is the best. I am really trying to see a long term solution here. Where the number of = "aliases" is large. And for a client to know what the canonical name is = would really help many application layer situations. Just look at the = number of HTTP redirect that is currently happening that instead could = have been just DNS lookups. Or the TLS situation that you mentions. But, also, I wanted to list requirements. Wishes. X-mas presents I want = to have. When we have a complete list of those we can compare the = various proposals, and we pick the proposal that we think is the best. = Maybe none of the proposals do implement what I am asking for? I do not = know yet. We need the list of requirements. And having a "this is the canonical = name" that works also across delegation points, would be extremely = helpful for applications. > I'm also thinking about the security model in which a client says "the = user asked for B but I'm pretending he asked for A". At the very least, = the server better verify that's an alias it approves of. Yes, I call that DNSSEC. Patrik From owner-namedroppers@ops.ietf.org Mon Aug 23 08: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 EFC4A3A6A65; Mon, 23 Aug 2010 08:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.307 X-Spam-Level: X-Spam-Status: No, score=0.307 tagged_above=-999 required=5 tests=[AWL=0.502, 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 LtathszHgtWK; Mon, 23 Aug 2010 08:16:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 668D23A6A77; Mon, 23 Aug 2010 08:16:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnYhB-000BqB-05 for namedroppers-data0@psg.com; Mon, 23 Aug 2010 15:12:21 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnYh8-000Bpu-FC for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 15:12:18 +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 F3947C5694D; Mon, 23 Aug 2010 16:12:16 +0100 (BST) Date: Mon, 23 Aug 2010 16:12:16 +0100 From: Alex Bligh Reply-To: Alex Bligh To: "John R. Levine" , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Predictive vs. reactive name aliasing models Message-ID: <91857D63189FF7D0F375F3FE@Ximines.local> In-Reply-To: References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.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 23 August 2010 09:18:04 -0400 "John R. Levine" wrote: > In the reactive model, a server does nothing special until it sees a name > show up for name Q, then in real time looks up Q, finds that it's an > alias for A, and then proceeds more or less as though the request had > been for A. Is that always possible? I presume not, given the https example, where best case may demand adding a new alternative name to an existing cert (which may require an offline private key to be typed), and worse case involves registering a new cert. -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 23 08:37: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 4796B3A68D8; Mon, 23 Aug 2010 08:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.364 X-Spam-Level: X-Spam-Status: No, score=-99.364 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, 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 XJsabNygHqZc; Mon, 23 Aug 2010 08:37:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 49E3B3A68B0; Mon, 23 Aug 2010 08:37:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnZ20-000Epa-81 for namedroppers-data0@psg.com; Mon, 23 Aug 2010 15:33:52 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnZ1x-000Eoz-Pg for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 15:33:49 +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 o7NFXT7c064321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Aug 2010 08:33:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100823111317.GA3450@farside.isc.org> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <20100823111317.GA3450@farside.isc.org> Date: Mon, 23 Aug 2010 08:33:27 -0700 To: Suzanne Woolf From: Paul Hoffman Subject: Re: scalability constraints? Re: [dnsext] Re: Problem statement additions 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 11:13 AM +0000 8/23/10, Suzanne Woolf wrote: >Does it follow that "unbounded scalability" should be an explicit >non-goal for this endeavor? No, because... >What kind of limits sound sensible? ...is impossible to define. Obviously, "unbounded scalability" is not desired, but making it an explicit non-goal means that everyone's definition of that, weighed against the value, must be the same. It will never be. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Mon Aug 23 10:02: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 DEA973A68BF; Mon, 23 Aug 2010 10:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.323 X-Spam-Level: X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[AWL=-0.128, 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 LbmQDJShNogD; Mon, 23 Aug 2010 10:02:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF1D93A689C; Mon, 23 Aug 2010 10:02:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnaLS-0002CI-JJ for namedroppers-data0@psg.com; Mon, 23 Aug 2010 16:58:02 +0000 Received: from [209.85.161.180] (helo=mail-gx0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnaLQ-0002Bk-0o for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 16:58:00 +0000 Received: by gxk22 with SMTP id 22so3316420gxk.11 for ; Mon, 23 Aug 2010 09:57:59 -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=V0DpBI73bbt3RelihuJ1LiN3cUgqV81x1FMUJkKTw58=; b=e7fhr1KGcd1dJmUIPpIO3zAl/XwJZAcpuA2+Hzi42Rb7jEcDyaUIdLH4magzrfRmrs IejaYOBqXRLlw3zHnsUph+DQAQtJLIZ5FoWaOpEkMkarY27sbCBFADoPQFNC2sYGhw36 kOiAnadVBbRFNWxFnQPGBzYqufq5pXSBCYxas= 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=Yh9fnyfGMALPZkDKOFMwx7hcoc9LZHltvoKwUGs9Vt2LV9+VMf6v9lfmpN3oy7HygL hrJtlNLByAWO4PIp+shwgH2xr2ACx+DBnzvn6p4lPhCBjbdUU/nxRbVD+X1efv/6bPTM y0NUpEC3tR2dwPazmp3eDkcNlVWXskvdt7B2A= MIME-Version: 1.0 Received: by 10.213.22.207 with SMTP id o15mr3269250ebb.92.1282582678759; Mon, 23 Aug 2010 09:57:58 -0700 (PDT) Received: by 10.14.45.66 with HTTP; Mon, 23 Aug 2010 09:57:58 -0700 (PDT) In-Reply-To: <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> Date: Mon, 23 Aug 2010 09:57:58 -0700 Message-ID: Subject: Re: [dnsext] Re: Problem statement additions From: Ted Hardie To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: John Levine , 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: 2010/8/22 Patrik F=E4ltstr=F6m : > > On 23 aug 2010, at 04.57, John Levine wrote: > >> The more I think about it, the more I think we need to separate the >> declaration "A and B are the same" from whatever other RRs A and B >> happen to have. > > The question is not whether A and B are the same. It is "Resolving A and = B leads to the same response". This is a much better formulation than mine, thanks. What I'm trying to avoid in part is the situation where you must query both A and B to get a full set of responses; this implies that you must know about both A and B to get one. If we start from your formulation, a client that queries either A or B gets the same (full) result. It doesn't need to know about the other. I also think part of what should be returned is "X is the canonical name", so that applications can use this data to construct things like HOST strings in HTTP (and test for the presence of the string in certs, etc.). This doesn't eliminate the problem entirely, but it provides at least one clear path through the thicket of permutations--it creates a normalization path, in other words. regards, Ted > > But I agree with Ted that it would be very good if this problem is solved= by having B be the canonical name, and A refer to it. And then have the re= ferral from A to B in such a way that application layer do know that is wha= t should happen. Applications then part from getting the same response when= resolving A and B also get to know that B is the canonical name. And becau= se of that B is what is to be used on the application layer. For example th= e HOST header of http. > > I do not see any need though for "given B, let me know all A that refer t= o it as the canonical name". Specifically as this referral might happen on = multiple times on each level in the name hierarchy which implies the number= of A will explode exponentially. > > =A0 Patrik > > > From owner-namedroppers@ops.ietf.org Mon Aug 23 10: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 747863A68D8; Mon, 23 Aug 2010 10:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.469 X-Spam-Level: X-Spam-Status: No, score=-99.469 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 OYzWLFnt+JIG; Mon, 23 Aug 2010 10:23:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7C9C53A68F3; Mon, 23 Aug 2010 10:23:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnahW-0005lO-PU for namedroppers-data0@psg.com; Mon, 23 Aug 2010 17:20:50 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnahU-0005l3-1P for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 17:20:48 +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 CF4D01ECB41D for ; Mon, 23 Aug 2010 17:20:46 +0000 (UTC) Date: Mon, 23 Aug 2010 13:20:45 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models Message-ID: <20100823172045.GE7863@shinkuro.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> 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: No hat On Mon, Aug 23, 2010 at 04:55:32PM +0200, Patrik Fältström wrote: > On 23 aug 2010, at 15.50, John R. Levine wrote: > > I'm also thinking about the security model in which a client says "the user asked for B but I'm pretending he asked for A". At the very least, the server better verify that's an alias it approves of. > > Yes, I call that DNSSEC. But without a record in A's zone to say, "Yep, B really does point to me," you can't actually prove that A and B are "the same" as far as A's operator is concerned, right? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dnsext-archive@ietf.org Mon Aug 23 10:27: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 8855F3A68F8 for ; Mon, 23 Aug 2010 10:27:47 -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 Official ; Mon, 23 Aug 2010 10:27:46 -0700 (PDT) Received: from for57-1-88-172-125-180.fbx.proxad.net (for57-1-88-172-125-180.fbx.proxad.net [88.172.125.180]) by core3.amsl.com (Postfix) with ESMTP id 3ECAA3A67B5 for ; Mon, 23 Aug 2010 10:27:46 -0700 (PDT) From: USA VIAGRA ® Official To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org VIAGRA ® Official Seller -88% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100823172746.3ECAA3A67B5@core3.amsl.com> Date: Mon, 23 Aug 2010 10:27:46 -0700 (PDT)
Click here!

From owner-namedroppers@ops.ietf.org Mon Aug 23 10:37: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 A71643A67B5; Mon, 23 Aug 2010 10:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.905 X-Spam-Level: X-Spam-Status: No, score=-8.905 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 kPZ+kWMLXEde; Mon, 23 Aug 2010 10:37:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 449613A68C2; Mon, 23 Aug 2010 10:37:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnauX-0007WC-Qg for namedroppers-data0@psg.com; Mon, 23 Aug 2010 17:34:17 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnauU-0007VZ-5U for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 17:34:14 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOdNckxAZnwM/2dsb2JhbACgL3GhBJtmhTcEiXY X-IronPort-AV: E=Sophos;i="4.56,258,1280707200"; d="scan'208";a="150769918" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Aug 2010 17:34:12 +0000 Received: from [192.165.72.14] (dhcp-10-55-83-170.cisco.com [10.55.83.170]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7NHYCbq023619; Mon, 23 Aug 2010 17:34:12 GMT Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100823172045.GE7863@shinkuro.com> Date: Mon, 23 Aug 2010 19:34:11 +0200 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 aug 2010, at 19.20, Andrew Sullivan wrote: > On Mon, Aug 23, 2010 at 04:55:32PM +0200, Patrik F=E4ltstr=F6m wrote: >> On 23 aug 2010, at 15.50, John R. Levine wrote: >=20 >>> I'm also thinking about the security model in which a client says = "the user asked for B but I'm pretending he asked for A". At the very = least, the server better verify that's an alias it approves of. >>=20 >> Yes, I call that DNSSEC. >=20 > But without a record in A's zone to say, "Yep, B really does point to > me," you can't actually prove that A and B are "the same" as far as > A's operator is concerned, right? No. Or I must misunderstand what you ask for. We have tons of one-way-pointers already today. Like the A and PTR = records. And CNAME. This is not worse. What you want to know is that both A and B authoritatively resolve to = the same data, so you must be able to trust each step in the resolution = process: A->data B->A->data For this to work, one sign "A->data". And one sign "B->A". Then resolution of A->data and B->A->data can be secured. I do not feel A have to "approve" B is referring to A. It is the B->A = pointer that should be secured. Just like PTRs, or A records or = whatever. The world is full of one way pointers. Patrik From owner-namedroppers@ops.ietf.org Mon Aug 23 10: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 4FA663A6942; Mon, 23 Aug 2010 10:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.486 X-Spam-Level: X-Spam-Status: No, score=-99.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 AzRnQOBBwcjf; Mon, 23 Aug 2010 10:44:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 706BF3A692C; Mon, 23 Aug 2010 10:44:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onb0t-0008Pf-VQ for namedroppers-data0@psg.com; Mon, 23 Aug 2010 17:40:51 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onb0p-0008PE-5k for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 17:40: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 15F451ECB41D for ; Mon, 23 Aug 2010 17:40:46 +0000 (UTC) Date: Mon, 23 Aug 2010 13:40:44 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models Message-ID: <20100823174044.GG7863@shinkuro.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> 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: No hat. On Mon, Aug 23, 2010 at 07:34:11PM +0200, Patrik Fältström wrote: > > We have tons of one-way-pointers already today. Like the A and PTR records. And CNAME. This is not worse. > Well, A and PTR are sort of different from this case. But CNAME isn't, agreed. > What you want to know is that both A and B authoritatively resolve to the same data, so you must be able to trust each step in the resolution process: > No, _one_ of the things you want to know is that both A and B authoritatively resolve to the same data (waving madly away just what "the same", "data", and so on means). I think what John was arguing was that knowing that much is perhaps enough in some cases, but not others. I can create my.searchy.example.com today, with a CNAME to www.google.com, and sign the CNAME record. It'll validate. But that gives the user no assurance whatever that my name is an "authentic" interface to Google. I think it's cases like this that John was worrying about. > I do not feel A have to "approve" B is referring to A. Why not? (I'm not saying you're wrong, but I've heard arguments more than once in this thread for having such a rule, and it doesn't strike me as obviously wrong.) Your argument here ("just like PTRs, CNAMEs, &c.) isn't enough: that's just an appeal to tradition. If we have that avenue open to us, then we can dismiss all this aliasing work as needless because we've never done it before. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Aug 23 10:46: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 E6E813A68F6; Mon, 23 Aug 2010 10:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.892 X-Spam-Level: X-Spam-Status: No, score=-8.892 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 GXadlznw2hQ7; Mon, 23 Aug 2010 10:46:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF3753A6A72; Mon, 23 Aug 2010 10:46:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onb40-0008rA-TO for namedroppers-data0@psg.com; Mon, 23 Aug 2010 17:44:04 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onb3x-0008qY-IX for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 17:44:01 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABFQckxAZnwM/2dsb2JhbACgMHGhCZtvhTcEiXY X-IronPort-AV: E=Sophos;i="4.56,258,1280707200"; d="scan'208";a="150773271" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Aug 2010 17:44:00 +0000 Received: from [192.165.72.14] (dhcp-10-55-83-170.cisco.com [10.55.83.170]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7NHhx1G027372; Mon, 23 Aug 2010 17:43:59 GMT Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100823174044.GG7863@shinkuro.com> Date: Mon, 23 Aug 2010 19:43:59 +0200 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <934DD6B9-F0AE-4994-A821-6F4E20626A26@cisco.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> <20100823174044.GG7863@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 aug 2010, at 19.40, Andrew Sullivan wrote: >> I do not feel A have to "approve" B is referring to A. > > Why not? (I'm not saying you're wrong, but I've heard arguments more > than once in this thread for having such a rule, and it doesn't strike > me as obviously wrong.) Your argument here ("just like PTRs, CNAMEs, > &c.) isn't enough: that's just an appeal to tradition. If we have > that avenue open to us, then we can dismiss all this aliasing work as > needless because we've never done it before. Because we do not do it for the domain name -> IP address mapping. Patrik From owner-namedroppers@ops.ietf.org Mon Aug 23 11:03: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 0A7F53A6A64; Mon, 23 Aug 2010 11:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.288 X-Spam-Level: X-Spam-Status: No, score=0.288 tagged_above=-999 required=5 tests=[AWL=0.483, 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 QhNFME8EksE9; Mon, 23 Aug 2010 11:03:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EAE013A691A; Mon, 23 Aug 2010 11:03:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnbHi-000Ask-TQ for namedroppers-data0@psg.com; Mon, 23 Aug 2010 17:58:14 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnbHe-000As5-E7 for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 17:58:11 +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 9B222C56951; Mon, 23 Aug 2010 18:58:08 +0100 (BST) Date: Mon, 23 Aug 2010 18:58:07 +0100 From: Alex Bligh Reply-To: Alex Bligh To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , Andrew Sullivan cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models Message-ID: <49B04FF675B7B91F8B642693@Ximines.local> In-Reply-To: References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 23 August 2010 19:34:11 +0200 Patrik F=C3=A4ltstr=C3=B6m = wrote: > No. Or I must misunderstand what you ask for. > > We have tons of one-way-pointers already today. Like the A and PTR > records. And CNAME. This is not worse. > > What you want to know is that both A and B authoritatively resolve to the > same data, so you must be able to trust each step in the resolution > process: > > A->data > B->A->data > > For this to work, one sign "A->data". > > And one sign "B->A". > > Then resolution of A->data and B->A->data can be secured. At risk of misunderstanding it too (it appears from an off-list conversation that I misunderstood John). Let us suppose Alice owns A, and Malory owns B. Malory (without Alice's consent) sets B to be equivalent to A and signs it. Alice's (say) mail server now treats mail to B as local mail, because it gets a signature on B saying it's equivalent to A. Is this a good idea? I'm sort of nervous about applications considering a foreign domain as equivalent to mine without any local confirmation. I know we have existing one way pointers, but applications do not in general trust them unconditionally, which is what you may need for a reactive model (in John's terms), isn't it? --=20 Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 23 11:04: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 EAFA83A68D8; Mon, 23 Aug 2010 11:04:34 -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 BIroGvViSfYE; Mon, 23 Aug 2010 11:04:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 940C33A691A; Mon, 23 Aug 2010 11:04:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnbLM-000BjZ-5N for namedroppers-data0@psg.com; Mon, 23 Aug 2010 18:02:00 +0000 Received: from [74.125.83.52] (helo=mail-gw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnbLH-000Bj8-3G for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 18:01:55 +0000 Received: by gwj20 with SMTP id 20so3350310gwj.11 for ; Mon, 23 Aug 2010 11:01:54 -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=CO1ytKorQMM5z3mAR3Aeq2AkU8dpCtRSrPl+D19R2R4=; b=IJjTKwx4ifSHKeJgmiibRNN2/UeJtl+LrmE/6w5MYzRaCwnEzEkyACJ97c/NPuDyss nQRKXYeZrRNJA8vK4utKpHyya+poqzhaQbSBfr5Ez2R7ZuQUho/XGHoNIWCSOJmkcukZ zQlo1Dbayd2bjxEM4NRoP6PNVTkr+lGftAmQQ= 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=aU2zH1AuS3TvIMr6giHdbeOyL8devuRAz7E0X71MqCsWDIVYOZhSiJ3NAdZ+494f6c g448PR1J1E3Ja7slnXfo/+3e7NNnEhKAcuW9E1hmpPBZ4HFVFSKZ2+kvExjqFuZoLUhu BYLDmcFT5FBrB0R9Z5peHHH585qZK5sfI0XCY= MIME-Version: 1.0 Received: by 10.213.19.211 with SMTP id c19mr4319959ebb.93.1282586513774; Mon, 23 Aug 2010 11:01:53 -0700 (PDT) Received: by 10.14.45.66 with HTTP; Mon, 23 Aug 2010 11:01:53 -0700 (PDT) In-Reply-To: <20100823174044.GG7863@shinkuro.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> <20100823174044.GG7863@shinkuro.com> Date: Mon, 23 Aug 2010 11:01:53 -0700 Message-ID: Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models From: Ted Hardie 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: On Mon, Aug 23, 2010 at 10:40 AM, Andrew Sullivan wrote: > No hat. > > No, _one_ of the things you want to know is that both A and B > authoritatively resolve to the same data (waving madly away just what > "the same", "data", and so on means). =A0I think what John was arguing > was that knowing that much is perhaps enough in some cases, but not > others. > > I can create my.searchy.example.com today, with a CNAME to > www.google.com, and sign the CNAME record. =A0It'll validate. =A0But that > gives the user no assurance whatever that my name is an "authentic" > interface to Google. =A0I think it's cases like this that John was > worrying about. > I think Patrik is saying that the information "The zone maintainer of searchy.example.com has created a CNAME that points my.searchy.example.com to www.google.com" has to be validated by "searchy.example.com"; no data signed by google.com can validate that. If you want to also have a record in which Google asserts "here are CNAMES I am okay with pointing to me", Google would sign that record. But, frankly, I'm not sure what use an application is going to make of such an assertion. I can picture app-specific meanings ("if you present a host header with any of the following, I'll do the same thing as I would do when presented with www.google.com"), and a generic meaning could be similar ("any of these strings will be accepted by services running on this service and the results will be the same as the canonical name string"). But I think Patrik and I are heading toward a slightly different application/dns behavior--in which the DNS passes up the canonical name and the app adjusts to use it. With that behavior, the second RR with Google's assertion is a no-op, because the app will have learned to use www.google.com instead of my.searchy.example.com. There's nothing for anyone to approve there, as the app is intereacting with the canonical name as expected by the time the app-layer interaction starts. Is there other behavior desired in defining something as "authentic"? I'm a little worried about hand waving there if we're already hand-waving "the same" and "data" regards, Ted >> I do not feel A have to "approve" B is referring to A. > > Why not? =A0(I'm not saying you're wrong, but I've heard arguments more > than once in this thread for having such a rule, and it doesn't strike > me as obviously wrong.) =A0Your argument here ("just like PTRs, CNAMEs, > &c.) isn't enough: that's just an appeal to tradition. =A0If we have > that avenue open to us, then we can dismiss all this aliasing work as > needless because we've never done it before. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > > From owner-namedroppers@ops.ietf.org Mon Aug 23 11:06: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 DA6DC3A6934; Mon, 23 Aug 2010 11:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.754 X-Spam-Level: X-Spam-Status: No, score=-98.754 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 b6MaNJOIk3it; Mon, 23 Aug 2010 11:06:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E68DE3A691A; Mon, 23 Aug 2010 11:06:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnbMz-000C2E-11 for namedroppers-data0@psg.com; Mon, 23 Aug 2010 18:03:41 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnbMu-000C0a-Fc for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 18:03:36 +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 4EF081ECB41D for ; Mon, 23 Aug 2010 18:03:35 +0000 (UTC) Date: Mon, 23 Aug 2010 14:03:33 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models Message-ID: <20100823180333.GI7863@shinkuro.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> <20100823174044.GG7863@shinkuro.com> <934DD6B9-F0AE-4994-A821-6F4E20626A26@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <934DD6B9-F0AE-4994-A821-6F4E20626A26@cisco.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 Mon, Aug 23, 2010 at 07:43:59PM +0200, Patrik Fältström wrote: > >> I do not feel A have to "approve" B is referring to A. > Because we do not do it for the domain name -> IP address mapping. Interesting you should argue that. In a long-expired draft over in dnsop, we made the following distinctions: - existent and non-existent reverse mapping - matching and non-matching reverse mapping At least historically, we had a class of behaviour where people insisted on matching reverse mapping: for a given name, you looked up the IP address (A record), then did the PTR lookup for that and checked to see if you got the hostname you expected. If not, then the host was "bad", for some definition of bad. This use fell out of favour, partly because DNS without DNSSEC was not hard to spoof (so the test added practically no security or other kind of assurance). It will be interesting to see whether it is resurrected in the age of DNSSEC. Moreover, your argument is basically that because we haven't had a particular facility so far, then we don't need it. But of course, we have never had the sort of aliasing behaviour we're now talking about _at all_. I don't think it's an acceptable answer to say, "Well, we never did that before," and expect that response to be treated as an argument for why not to do this thing. The same therefore goes for the back-pointer idea. There's something very attractive, I think, in having a mechanism for the canonical name to list all the aliases by which it is known. Moreover, with DNSSEC in all the zones, you could prove that they really were related as they claim to be. What's wrong with specifying that as part of the work? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Aug 23 11:09: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 C1AD23A6934; Mon, 23 Aug 2010 11:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.879 X-Spam-Level: X-Spam-Status: No, score=-8.879 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 bHZaOgaawPDs; Mon, 23 Aug 2010 11:09:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F7A83A68AC; Mon, 23 Aug 2010 11:09:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnbQI-000CYI-6D for namedroppers-data0@psg.com; Mon, 23 Aug 2010 18:07:06 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnbQF-000CXq-3R for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 18:07:03 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABpWckxAZnwM/2dsb2JhbACgMHGhUptwhTcEiXY X-IronPort-AV: E=Sophos;i="4.56,258,1280707200"; d="scan'208";a="150781993" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Aug 2010 18:06:58 +0000 Received: from [192.165.72.14] (dhcp-10-55-83-170.cisco.com [10.55.83.170]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7NI6vQR008168; Mon, 23 Aug 2010 18:06:57 GMT Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <49B04FF675B7B91F8B642693@Ximines.local> Date: Mon, 23 Aug 2010 20:06:57 +0200 Cc: Andrew Sullivan , namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> <49B04FF675B7B91F8B642693@Ximines.local> To: Alex Bligh X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 aug 2010, at 19.58, Alex Bligh wrote: >> Then resolution of A->data and B->A->data can be secured. >=20 > At risk of misunderstanding it too (it appears from an off-list > conversation that I misunderstood John). >=20 > Let us suppose Alice owns A, and Malory owns B. Malory (without > Alice's consent) sets B to be equivalent to A and signs it. Alice's > (say) mail server now treats mail to B as local mail, because it > gets a signature on B saying it's equivalent to A. Is this a good = idea? >=20 > I'm sort of nervous about applications considering a foreign domain > as equivalent to mine without any local confirmation. I know we have > existing one way pointers, but applications do not in general trust > them unconditionally, which is what you may need for a reactive > model (in John's terms), isn't it? Ok, I got it now... You are correct on the danger that the B->A pointer unconditionally on = application layer say for example x@A and x@B are the same, so when = wanting to send mail to x@B, the mail will be sent to x@A, and the mail = server at A can not know that x@B was the intended recipient as the = email address x@A is presented to it. What I was (sloppy of me) thinking of is that in many cases each = SMTP/HTTP/whatever server do have a default domain configured, and = x@DEFAULTDOMAIN will work anyways. Mumble... I still think we should list requirements. And compile a list. Then we = can discuss in a more constructive way. I am nervous we have tons of requirements here and there, but not in one = place. Patrik From owner-namedroppers@ops.ietf.org Mon Aug 23 11:14: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 CF6753A68AC; Mon, 23 Aug 2010 11:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.867 X-Spam-Level: X-Spam-Status: No, score=-8.867 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 vrCTGvEfTYe4; Mon, 23 Aug 2010 11:14:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 403E33A68FC; Mon, 23 Aug 2010 11:14:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnbUj-000DAH-2D for namedroppers-data0@psg.com; Mon, 23 Aug 2010 18:11:41 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnbUf-000D9l-Uz for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 18:11:38 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEdXckxAZnwN/2dsb2JhbACgMHGhRJtwhTcEiXY X-IronPort-AV: E=Sophos;i="4.56,258,1280707200"; d="scan'208";a="150783547" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 Aug 2010 18:11:36 +0000 Received: from [192.165.72.14] (dhcp-10-55-83-170.cisco.com [10.55.83.170]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7NIBZu0002914; Mon, 23 Aug 2010 18:11:36 GMT Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100823180333.GI7863@shinkuro.com> Date: Mon, 23 Aug 2010 20:11:35 +0200 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <426DA81A-ED54-440F-8B1D-7CDDA69D313C@cisco.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> <20100823174044.GG7863@shinkuro.com> <934DD6B9-F0AE-4994-A821-6F4E20626A26@cisco.com> <20100823180333.GI7863@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 aug 2010, at 20.03, Andrew Sullivan wrote: > Moreover, your argument is basically that because we haven't had a > particular facility so far, then we don't need it. For the DNS I do think we have learned how to live without it, and we do = argue about whether a domain name where A->PTR->A->PTR etc is stable = compared to a case where it is not. For the domain mapping on application layer, we do have a validation in = the form of handshake, for example HOST header in HTTP. So I get it now... Patrik From owner-namedroppers@ops.ietf.org Mon Aug 23 11: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 029BD3A694A; Mon, 23 Aug 2010 11:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.505 X-Spam-Level: X-Spam-Status: No, score=-98.505 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 Zbfulu0NHnOg; Mon, 23 Aug 2010 11:22:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8551C3A6889; Mon, 23 Aug 2010 11:22:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onbd2-000EeO-Vu for namedroppers-data0@psg.com; Mon, 23 Aug 2010 18:20:16 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onbcz-000Edg-Q8 for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 18:20:14 +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 2EE7B1ECB41D for ; Mon, 23 Aug 2010 18:20:12 +0000 (UTC) Date: Mon, 23 Aug 2010 14:20:10 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models Message-ID: <20100823182010.GJ7863@shinkuro.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> <20100823174044.GG7863@shinkuro.com> 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: Hat still doffed. On Mon, Aug 23, 2010 at 11:01:53AM -0700, Ted Hardie wrote: > I think Patrik is saying that the information "The zone maintainer of > searchy.example.com has created a CNAME that points my.searchy.example.com > to www.google.com" has to be validated by "searchy.example.com"; no data > signed by google.com can validate that. Right. > If you want to also have a record in which Google asserts "here are > CNAMES I am okay with pointing to me", Google would sign that record. Also right. > name string"). But I think Patrik and I are heading toward a slightly > different application/dns behavior--in which the DNS passes up the > canonical name and the app adjusts to use it. With that behavior, > the second RR with Google's assertion is a no-op, because the app > will have learned to use www.google.com instead of my.searchy.example.com. > There's nothing for anyone to approve there, as the app is intereacting > with the canonical name as expected by the time the app-layer interaction > starts. Recall, however, that at least part of our goal amounts to solving a user interface problem. We have users who type things in one way, but that is not the "canonical" way. Nevertheless, it's the way that is natural for them, given their input methods and so on. I would be somewhat surprised if the communities who have that problem would think it just fine and dandy if the canonical name ended up being the only thing that users could actually use (i.e. that their display would quickly convert to the canonical name once that link was discovered in the DNS): this is more "second-class citizen" than I had heretofore contemplated. Since this isn't my itch, I can't tell how to scratch it. Is such a restriction really ok? To be clear about what we're supposing: I was moderately surprised just now at the results for the following names, for instance: bonjourquebec.com bonjourquebec.ca bonjourquébec.com bonjourquébec.ca If you go to the website, the first three are the same (and they all get you to the first of them; the last one doesn't work because .ca doesn't have IDNA support). None of this is done in the DNS. What's interesting is that the accent on the e gets dropped. Is that what we'd expect? Is it ok? > Is there other behavior desired in defining something as "authentic"? I'm > a little worried about hand waving there if we're already hand-waving > "the same" and "data" Me, too. I'm not sure that we need to overload the word "authentic" here, however. The point is to deliver behaviour that is predictable and more or less intuitive, I think. One of those intuitions might lead one to say that nobody can make an alias of your name unless you say so. That's not the way we've historically done it, but it's not hard to imagine. After all, if you go making symlinks on a filesystem to files you can't read, you still can't open them. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Aug 23 11:25: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 19AD23A6A69; Mon, 23 Aug 2010 11:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.121 X-Spam-Level: X-Spam-Status: No, score=0.121 tagged_above=-999 required=5 tests=[AWL=0.616, 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 JFpTlJ-53GwH; Mon, 23 Aug 2010 11:25:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0E9623A6A64; Mon, 23 Aug 2010 11:25:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onbfy-000F4q-S5 for namedroppers-data0@psg.com; Mon, 23 Aug 2010 18:23:18 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onbfs-000F3x-Ej for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 18:23:12 +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 D9213C56951; Mon, 23 Aug 2010 19:23:10 +0100 (BST) Date: Mon, 23 Aug 2010 19:23:10 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Andrew Sullivan , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models Message-ID: In-Reply-To: <20100823180333.GI7863@shinkuro.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> <20100823174044.GG7863@shinkuro.com> <934DD6B9-F0AE-4994-A821-6F4E20626A26@cisco.com> <20100823180333.GI7863@shinkuro.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 23 August 2010 14:03:33 -0400 Andrew Sullivan wrote: > There's something very attractive, I think, in having a mechanism for > the canonical name to list all the aliases by which it is known. > Moreover, with DNSSEC in all the zones, you could prove that they > really were related as they claim to be. What's wrong with specifying > that as part of the work? You may well want to be able to confirm that an alias is an alias, but perhaps a list of records are not the way to do it. It doesn't take a lot of imagination to come up with a situation where the number of possible equivalent forwards is beyond a million, and I'm not sure I fancy returning a list of a million addresses in response to a query (whether that be PTR or anything else). Would it not be better to use some crypto solution to this: e.g. (completely off the top of my head) for the (putative) alias zone to hold some record signed with the same key as the canonical zone? -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 23 11: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 4F45A3A6A69; Mon, 23 Aug 2010 11:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.225 X-Spam-Level: X-Spam-Status: No, score=-3.225 tagged_above=-999 required=5 tests=[AWL=-1.415, 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 3bBuuZwfSJaj; Mon, 23 Aug 2010 11:26:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 13C733A6889; Mon, 23 Aug 2010 11:26:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onbgt-000FCh-Ci for namedroppers-data0@psg.com; Mon, 23 Aug 2010 18:24:15 +0000 Received: from [131.111.8.132] (helo=ppsw-32.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onbgq-000FCE-D4 for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 18:24:12 +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]:41383) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Onbgj-0001fJ-26 (Exim 4.72) (return-path ); Mon, 23 Aug 2010 19:24:05 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Onbgj-0002kn-KU (Exim 4.67) (return-path ); Mon, 23 Aug 2010 19:24:05 +0100 Date: Mon, 23 Aug 2010 19:24:05 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "John R. Levine" cc: =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models In-Reply-To: Message-ID: References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> 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 Mon, 23 Aug 2010, John R. Levine wrote: > > I'm also thinking about the security model in which a client says "the user > asked for B but I'm pretending he asked for A". At the very least, the server > better verify that's an alias it approves of. The client should treat it as a redirect. At the moment redirects are unauthenticated in HTTP and SMTP at least. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER: WEST OR SOUTHWEST 7 TO SEVERE GALE 9, OCCASIONALLY STORM 10 AT FIRST IN HUMBER AND THAMES. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From owner-namedroppers@ops.ietf.org Mon Aug 23 11:31: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 261B23A6889; Mon, 23 Aug 2010 11:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.215 X-Spam-Level: * X-Spam-Status: No, score=1.215 tagged_above=-999 required=5 tests=[AWL=1.709, 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 jPfGdrHdp0qI; Mon, 23 Aug 2010 11:31:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E0983A6927; Mon, 23 Aug 2010 11:31:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onbky-000Ft2-Cy for namedroppers-data0@psg.com; Mon, 23 Aug 2010 18:28:28 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onbku-000FsE-DQ for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 18:28:24 +0000 Received: by fxm10 with SMTP id 10so3911804fxm.11 for ; Mon, 23 Aug 2010 11:28:23 -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; bh=dD7+VJIZ9p85gqJSLGMintA+juygkX9Uoxn5uUq2+OE=; b=i9v/6oALMQYHj4Y1zZlBbLSv6SgwNyb+aN9IVQDsaNfWRrLOUDPezGC7kTCRAS3/+Y J7uoMDxLMYs1Af56va8XyRUy+fTKbXEVEsNmyX4x0aguumz+V12a6gEBQKzwTkl+Y1Nq yQw5Td5eyNRWUrii9OGNVmN69Ie5lKgcy25HM= 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=rkqNfRqNLT6nklJDO9PZPcujLgjn4c9cfjPsketl4PQonQ71J9N9nNxhk1xVPS3sNe JGJxErFstWHHbT3878MwOdWeSvENYg/Z1cvJr+/NBLnaHlKvRbqYIm4p4h7cTjMFDDrf 5p5t+8qhvVM4rP58oz540lpmsc2oZ071Kcz6Y= MIME-Version: 1.0 Received: by 10.223.103.134 with SMTP id k6mr4884994fao.5.1282588101203; Mon, 23 Aug 2010 11:28:21 -0700 (PDT) Received: by 10.223.126.138 with HTTP; Mon, 23 Aug 2010 11:28:21 -0700 (PDT) In-Reply-To: References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> <20100823174044.GG7863@shinkuro.com> Date: Mon, 23 Aug 2010 15:28:21 -0300 Message-ID: Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models From: Brian Dickson To: Ted Hardie Cc: Andrew Sullivan , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=001636c5a5572a58d9048e81d0c9 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001636c5a5572a58d9048e81d0c9 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 23, 2010 at 3:01 PM, Ted Hardie wrote: > On Mon, Aug 23, 2010 at 10:40 AM, Andrew Sullivan > wrote: > > No hat. > > > > > No, _one_ of the things you want to know is that both A and B > > authoritatively resolve to the same data (waving madly away just what > > "the same", "data", and so on means). I think what John was arguing > > was that knowing that much is perhaps enough in some cases, but not > > others. > > > > I can create my.searchy.example.com today, with a CNAME to > > www.google.com, and sign the CNAME record. It'll validate. But that > > gives the user no assurance whatever that my name is an "authentic" > > interface to Google. I think it's cases like this that John was > > worrying about. > > > > I think Patrik is saying that the information "The zone maintainer of > searchy.example.com has created a CNAME that points my.searchy.example.com > to www.google.com" has to be validated by "searchy.example.com"; no data > signed by google.com can validate that. > > If you want to also have a record in which Google asserts "here are > CNAMES I am okay with pointing to me", Google would sign that record. > Yes, and there are several similar things that I'd suggest are of some value: - something indicating, within an authority domain, what set of labels is associated with what "canonical" label - something else, indicating what labels and/or fqdn's, are authoritatively "equivalent" from the authority owner's perspective The former is a "goto" pointer. The latter is a "come-from" pointer, which, when signed, gives strong authentication of the pointer chain. > But, frankly, I'm not sure what use an application is going to make of > such an assertion. I don't think this is something which needs to be *exclusively* an app thing. I think that the model(s) we choose to support for "equivalent" and "dnssec" at the same time, need to enforce this, at the DNS level. In other words, that the DNSSEC-aware validator would only give a "trusted" response if B->A->rdata has A saying "I have signed my approval of B->A". It's something missing from the current model, for sure - but I think it needs to be there. > I can picture app-specific meanings ("if you present > a host header with any of the following, I'll do the same thing as I would > do when presented with www.google.com"), and a generic meaning > could be similar ("any of these strings will be accepted by services > running on this service and the results will be the same as the canonical > name string"). But I think Patrik and I are heading toward a slightly > different application/dns behavior--in which the DNS passes up the > canonical name and the app adjusts to use it. With that behavior, > the second RR with Google's assertion is a no-op, because the app > will have learned to use www.google.com instead of my.searchy.example.com. > There's nothing for anyone to approve there, as the app is intereacting > with the canonical name as expected by the time the app-layer interaction > starts. > > That only works if the application is secure itself, e.g. https. If the application is not secure, i.e. the server->client is in the open, then the client can pretty easily be spoofed with embedded my.searchy.example.com in a page that also contains evil.searchy.example.com. Both signed by searchy.example.com, both valid and secure, from a protocol perspective - but combined, creating a security nightmare and phisher's dream. You need to think like a bad guy first, before thinking like either a (big) good guy or a little guy. There's a reason for the DNSSEC model of chained authenticated delegations from a trust anchor. Deviations need to be thought out carefully, to ensure they don't create vectors for compromising that trust relationship. Brian > Is there other behavior desired in defining something as "authentic"? I'm > a little worried about hand waving there if we're already hand-waving > "the same" and "data" > > regards, > > Ted > > >> I do not feel A have to "approve" B is referring to A. > > > > Why not? (I'm not saying you're wrong, but I've heard arguments more > > than once in this thread for having such a rule, and it doesn't strike > > me as obviously wrong.) Your argument here ("just like PTRs, CNAMEs, > > &c.) isn't enough: that's just an appeal to tradition. If we have > > that avenue open to us, then we can dismiss all this aliasing work as > > needless because we've never done it before. > > > > A > > > > -- > > Andrew Sullivan > > ajs@shinkuro.com > > Shinkuro, Inc. > > > > > > --001636c5a5572a58d9048e81d0c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 23, 2010 at 3:01 PM, Ted Har= die <ted.ietf@gm= ail.com> wrote:
On Mon, Aug 23, 2010 at 10:40 AM, Andrew Sullivan <ajs@shinkuro.com> wrote:
> No hat.
>

> No, _one_ of the things you want to know is that both A and B
> authoritatively resolve to the same data (waving madly away just what<= br> > "the same", "data", and so on means). =A0I think w= hat John was arguing
> was that knowing that much is perhaps enough in some cases, but not > others.
>
> I can create my.searchy.example.com today, with a CNAME to
> www.google.com= , and sign the CNAME record. =A0It'll validate. =A0But that
> gives the user no assurance whatever that my name is an "authenti= c"
> interface to Google. =A0I think it's cases like this that John was=
> worrying about.
>

I think Patrik is saying that the information "The zone maintain= er of
searchy.example.co= m has created a CNAME that points my.searchy.example.com
to www.google.com&q= uot; has to be validated by "searchy.example.com"; no data
signed by google.com ca= n validate that.

If you want to also have a record in which Google asserts "here are CNAMES I am okay with pointing to me", Google would sign that record.<= br>


Yes, and there are several similar things that= I'd suggest are of some value:
- something indicating, within an au= thority domain, what set of labels is associated with what "canonical&= quot; label
- something else, indicating what labels and/or fqdn's, are authoritati= vely "equivalent" from the authority owner's perspective
<= br>The former is a "goto" pointer.
The latter is a "come-= from" pointer, which, when signed, gives strong authentication of the = pointer chain.
=A0
But, frankly, I'm not sure what use an application is going to make of<= br> such an assertion.

I don't think this is somethin= g which needs to be *exclusively* an app thing.

I think that the mod= el(s) we choose to support for "equivalent" and "dnssec"= ; at the same time,
need to enforce this, at the DNS level.

In other words, that the DNS= SEC-aware validator would only give a "trusted" response if B->= ;A->rdata has A saying "I have signed my approval of B->A".=

It's something missing from the current model, for sure - but I thi= nk it needs to be there.
=A0
=A0I can picture app-specific meanings ("if you present
=A0a host header with any of the following, I'll do the same thing as I= would
do when presented with = www.google.com"), and a generic meaning
could be similar ("any of these strings will be accepted by services running on this service and the results will be the same as the canonical name string"). =A0But I think Patrik and I are heading toward a slight= ly
different application/dns behavior--in which the DNS passes up the
canonical name and the app adjusts to use it. =A0 =A0With that behavior, the second RR with Google's assertion is a no-op, because the app
will have learned to use www.google.com instead of my.searchy.example.com.
There's =A0nothing for anyone to approve there, as the app is intereact= ing
with the canonical name as expected by the time the app-layer interaction starts.


That only works if the application is secure itse= lf, e.g. https.

If the application is not secure, i.e. the server-&g= t;client is in the open, then the client
can pretty easily be spoofed wi= th embedded my.searchy.example.co= m in a page that also
contains evil.searchy.example.c= om. Both signed by searchy.examp= le.com, both valid and secure,
from a protocol perspective - but com= bined, creating a security nightmare and phisher's dream.

You need to think like a bad guy first, before thinking like either a (= big) good guy or a little guy.

There's a reason for the DNSSEC m= odel of chained authenticated delegations from a trust anchor.
Deviation= s need to be thought out carefully, to ensure they don't create vectors= for compromising that trust relationship.

Brian
=A0
Is there other behavior desired in defining something as "authentic&qu= ot;? =A0I'm
a little worried about hand waving there if we're already hand-waving "the same" and "data"

regards,

Ted

>> I do not feel A have to "approve" B is referring to A. >
> Why not? =A0(I'm not saying you're wrong, but I've heard a= rguments more
> than once in this thread for having such a rule, and it doesn't st= rike
> me as obviously wrong.) =A0Your argument here ("just like PTRs, C= NAMEs,
> &c.) isn't enough: that's just an appeal to tradition. =A0= If we have
> that avenue open to us, then we can dismiss all this aliasing work as<= br> > needless because we've never done it before.
>
> A
>
> --
> Andrew Sullivan
> ajs@shinkuro.com
> Shinkuro, Inc.
>
>


--001636c5a5572a58d9048e81d0c9-- From owner-namedroppers@ops.ietf.org Mon Aug 23 11:31: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 58E6D3A6889; Mon, 23 Aug 2010 11:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.855 X-Spam-Level: X-Spam-Status: No, score=-8.855 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 lrrNw1UfN2qp; Mon, 23 Aug 2010 11:31:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 414AA3A6937; Mon, 23 Aug 2010 11:31:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnblP-000FyT-RJ for namedroppers-data0@psg.com; Mon, 23 Aug 2010 18:28:55 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnblL-000Fxs-OJ for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 18:28:51 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE1bckxAZnwM/2dsb2JhbACgMHGhVJt0hTcEiXY X-IronPort-AV: E=Sophos;i="4.56,258,1280707200"; d="scan'208";a="150973688" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 23 Aug 2010 18:28:42 +0000 Received: from [192.165.72.14] (dhcp-10-55-83-170.cisco.com [10.55.83.170]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7NISfxi016052; Mon, 23 Aug 2010 18:28:41 GMT Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20100823182010.GJ7863@shinkuro.com> Date: Mon, 23 Aug 2010 20:28:40 +0200 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> <20100823174044.GG7863@shinkuro.com> <20100823182010.GJ7863@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 aug 2010, at 20.20, Andrew Sullivan wrote: > To be clear about what we're supposing: I was moderately surprised > just now at the results for the following names, for instance: >=20 > bonjourquebec.com > bonjourquebec.ca > bonjourqu=E9bec.com > bonjourqu=E9bec.ca >=20 > If you go to the website, the first three are the same (and they all > get you to the first of them; the last one doesn't work because .ca > doesn't have IDNA support). None of this is done in the DNS. What's > interesting is that the accent on the e gets dropped. Is that what > we'd expect? Is it ok? That is an application layer issue, and unfortunately (I think) due to = the way many CMS systems work (like Wordpress). You can only have one = canonical domain name for a host, and the rest are aliases that result = in redirects. For example http://xn--bonjourqubec-jeb.com/ result in a redirect to = http://www.bonjourquebec.com/ That is not always needed. See http://www.led=E5sa.se/idn/. Patrik From owner-namedroppers@ops.ietf.org Mon Aug 23 11:35: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 0F9EA3A692C; Mon, 23 Aug 2010 11:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.936 X-Spam-Level: X-Spam-Status: No, score=-3.936 tagged_above=-999 required=5 tests=[AWL=-0.637, 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 8d7yjDuFHZCC; Mon, 23 Aug 2010 11:35:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 021A73A6937; Mon, 23 Aug 2010 11:35:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onbot-000GWz-CI for namedroppers-data0@psg.com; Mon, 23 Aug 2010 18:32:31 +0000 Received: from [131.111.8.131] (helo=ppsw-31.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onbon-000GW4-5E for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 18:32:25 +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]:35849) by ppsw-31.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Onbom-0004Sj-KM (Exim 4.72) (return-path ); Mon, 23 Aug 2010 19:32:24 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Onbom-0003lK-9R (Exim 4.67) (return-path ); Mon, 23 Aug 2010 19:32:24 +0100 Date: Mon, 23 Aug 2010 19:32:24 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Andrew Sullivan cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models In-Reply-To: <20100823182010.GJ7863@shinkuro.com> Message-ID: References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> <20100823174044.GG7863@shinkuro.com> <20100823182010.GJ7863@shinkuro.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870024-1448007541-1282588344=:14263" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870024-1448007541-1282588344=:14263 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 23 Aug 2010, Andrew Sullivan wrote: > > bonjourquebec.com > bonjourquebec.ca > bonjourqu=C3=A9bec.com > bonjourqu=C3=A9bec.ca > > If you go to the website, the first three are the same (and they all > get you to the first of them; the last one doesn't work because .ca > doesn't have IDNA support). None of this is done in the DNS. What's > interesting is that the accent on the e gets dropped. Is that what > we'd expect? Is it ok? It's good from the point of view of http cache behaviour. Tony. --=20 f.anthony.n.finch http://dotat.at/ SOLE LUNDY FASTNET IRISH SEA SHANNON ROCKALL MALIN WEST OR NORTHWEST, 5 TO = 7, OCCASIONALLY GALE 8 IN IRISH SEA, ROCKALL AND MALIN, DECREASING 3 OR 4 LATE= R IN SOLE, FASTNET, SHANNON AND ROCKALL. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH IN ROCKALL AND MALIN. SQUALLY SHOWERS, RAIN IN ROCKALL AND MALIN. MODERATE OR GOOD. --1870870024-1448007541-1282588344=:14263-- From owner-namedroppers@ops.ietf.org Mon Aug 23 11:48: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 C57193A6A99; Mon, 23 Aug 2010 11:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.869 X-Spam-Level: X-Spam-Status: No, score=-108.869 tagged_above=-999 required=5 tests=[AWL=0.226, 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, 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 BoslxbRnclpB; Mon, 23 Aug 2010 11:48:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A1303A6A7D; Mon, 23 Aug 2010 11:48:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onc0u-000IQe-CY for namedroppers-data0@psg.com; Mon, 23 Aug 2010 18:44:56 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onc0q-000IQ6-IB for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 18:44:52 +0000 Received: (qmail 86775 invoked from network); 23 Aug 2010 18:44:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=SOmtcRFLzpGqtqOfYTRMbU0OwuPu508buey4BOOUSdQ=; b=rI8SrqonnH3D6HadInfnDgaF+4QTircL7bTh8U/Y0aje4jLSjxl9hupPVvUXv3tGSlbLGCCk2Mzeu13GryqzuHgTw2fB+yJvHfgCD8O7A9konrFDr8hHXCRZLzxbSDg7sZoxknkkQTyTfY4qi5ajbTNFWntl0hg/fep8pZzE4Ks= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Aug 2010 18:44:28 -0000 Date: 23 Aug 2010 14:44:44 -0400 Message-ID: From: "John R. Levine" To: "Tony Finch" Cc: "=?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?=" , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models In-Reply-To: References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: >> I'm also thinking about the security model in which a client says "the user >> asked for B but I'm pretending he asked for A". At the very least, the server >> better verify that's an alias it approves of. > > The client should treat it as a redirect. At the moment redirects are > unauthenticated in HTTP and SMTP at least. Right. This isn't something DNSSEC addresses at all. In this model, the set of alias names is entirely under control of the operators of the aliases, not the resource they redirect to. With HTTP redirects, they may not be authenticated but at least they're under control of the server. I haven't worked out all the various threat models, but the idea that random bad guys can invent new names for my web servers or my mail system and I wouldn't even know about them does not give me a warm feeling. Also, although I certainly don't think we should try to define user interfaces, we should at least have reasonable answers for questions like if the user asked for B, and his client asked the server for A instead, what name should appear in feedback like a browser's address bar? Oh, and one more data point: the mail RFCs consistently say that mail clients should resolve CNAMEs and use the resolved name, and mail clients consistently don't do that (and not just because the authors haven't read the RFCs.) There's a lesson there. R's, John From owner-namedroppers@ops.ietf.org Mon Aug 23 11:55: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 6975E3A6AAC; Mon, 23 Aug 2010 11:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.844 X-Spam-Level: X-Spam-Status: No, score=-8.844 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 Ys7FF3HcNGPd; Mon, 23 Aug 2010 11:55:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 59BEE3A6AAB; Mon, 23 Aug 2010 11:55:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onc92-000JlP-W4 for namedroppers-data0@psg.com; Mon, 23 Aug 2010 18:53:20 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onc8z-000Jkr-ER for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 18:53:17 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPJfckxAZnwN/2dsb2JhbACgMHGhfpt6hTcEiXY X-IronPort-AV: E=Sophos;i="4.56,259,1280707200"; d="scan'208";a="150983554" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Aug 2010 18:53:16 +0000 Received: from [192.165.72.14] (dhcp-10-55-83-170.cisco.com [10.55.83.170]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7NIrFx2016947; Mon, 23 Aug 2010 18:53:15 GMT Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Mon, 23 Aug 2010 20:53:15 +0200 Cc: "Tony Finch" , namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9149197A-431B-4CEB-B83B-C3F06C56F721@cisco.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> To: "John R. Levine" X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 aug 2010, at 20.44, John R. Levine wrote: > I haven't worked out all the various threat models, but the idea that = random bad guys can invent new names for my web servers or my mail = system and I wouldn't even know about them does not give me a warm = feeling. Today if I put up an HTTP server, I can either do a forward-proxy or a = redirect to your server. In the first case, the client does not notice, = and in the second you do not notice. But as Andrew says, just because we already have this problem already = (CNAME, A record, on application layer etc), should we make the problem = worse? Will the problem get worse? I do not know. But it is one issue to look at when evaluating possible solutions. Patrik From owner-namedroppers@ops.ietf.org Mon Aug 23 12: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 C91CE3A6AA0; Mon, 23 Aug 2010 12:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[AWL=0.036, 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 OukVkxjk0khY; Mon, 23 Aug 2010 12:07:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 922D83A6ACF; Mon, 23 Aug 2010 12:06:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OncH3-000L1w-Re for namedroppers-data0@psg.com; Mon, 23 Aug 2010 19:01:37 +0000 Received: from [209.85.213.52] (helo=mail-yw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OncGw-000L0A-1W for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 19:01:31 +0000 Received: by ywo32 with SMTP id 32so970090ywo.11 for ; Mon, 23 Aug 2010 12:01:29 -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=b7fUtJHwMcVlly4qauJlDmMrvYRcstSrhsRANGfIR8Y=; b=CNPl4ygTRauN4o8TJMzh9XtZFlFWCObClljtuyLbY+cPq6tZQ4P0utPxKzn9H2ofS+ vMdg1KsU3MN/oDzxaUOKRG0aefT2u6y70M+aqLdVLUsumCWAmpqhj+ad2zAvpkg/2mUH mK815Sb+6giuFuO48YQFwnTzsUqx5z+vEghEQ= 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=kfPgKdllENzMD+VTG2fW76+98nnW586jVsG6N2A48gr6hZ0jTSRXlImHXC4KlC5cc8 2nZFxTT5VOLhtkpv21ecDxmVYCmUEMHBAsWKUb6R/CL2SCMB3Ym2zdWhha5ibGL2OgcR uKA3EqQJGetGjl9hsLtxzPCRKFE8l/YeImspA= MIME-Version: 1.0 Received: by 10.213.112.130 with SMTP id w2mr3534020ebp.43.1282590086824; Mon, 23 Aug 2010 12:01:26 -0700 (PDT) Received: by 10.14.45.66 with HTTP; Mon, 23 Aug 2010 12:01:26 -0700 (PDT) In-Reply-To: References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> <20100823174044.GG7863@shinkuro.com> Date: Mon, 23 Aug 2010 12:01:26 -0700 Message-ID: Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models From: Ted Hardie To: Brian Dickson Cc: Andrew Sullivan , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 23, 2010 at 11:28 AM, Brian Dickson wrote: > > If the application is not secure, i.e. the server->client is in the open, > then the client > can pretty easily be spoofed with embedded my.searchy.example.com in a pa= ge > that also > contains evil.searchy.example.com. Both signed by searchy.example.com, bo= th > valid and secure, > from a protocol perspective - but combined, creating a security nightmare > and phisher's dream. When I try to work this out in venn diagrams in my head, I'm afraid I fail. If the reference is to my.searchy.example.com, the pointer is to www.google= .com, but the signature is searchy.example.com's. There's no trust being given here other than "searchy.example.com asserts my.searchy.example.com is a pointer to www.google.com". How would it increase the trust in evil.searchy.example.com? There are, of course, existing attacks that allow you to embed trusted content from a different host in an untrusted context (early frame attacks, etc.), but this doesn't seem to actual touch on those in any way I can see. > > You need to think like a bad guy first, before thinking like either a (bi= g) > good guy or a little guy. > > There's a reason for the DNSSEC model of chained authenticated delegation= s > from a trust anchor. > Deviations need to be thought out carefully, to ensure they don't create > vectors for compromising that trust relationship. > But this isn't a deviation. DNSSEC is a mechanism for ensuring what you go= t was what the zone maintainer entered. It has no protection for an evil zon= e, and never did. What Patrik pointed out was that you need to separate the data asserted by one zone (the CNAME-ing zone) from that which must be asserted by the other (the target one). I don't think I understand how the existence of a different label under the CNAME-ing zone relates to this at all. More explanation gratefully received.... Ted > Brian > >> >> Is there other behavior desired in defining something as "authentic"? = =A0I'm >> a little worried about hand waving there if we're already hand-waving >> "the same" and "data" >> >> regards, >> >> Ted >> >> >> I do not feel A have to "approve" B is referring to A. >> > >> > Why not? =A0(I'm not saying you're wrong, but I've heard arguments mor= e >> > than once in this thread for having such a rule, and it doesn't strike >> > me as obviously wrong.) =A0Your argument here ("just like PTRs, CNAMEs= , >> > &c.) isn't enough: that's just an appeal to tradition. =A0If we have >> > that avenue open to us, then we can dismiss all this aliasing work as >> > needless because we've never done it before. >> > >> > A >> > >> > -- >> > Andrew Sullivan >> > ajs@shinkuro.com >> > Shinkuro, Inc. >> > >> > >> > > From owner-namedroppers@ops.ietf.org Mon Aug 23 12:22: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 0E09B3A6A7D; Mon, 23 Aug 2010 12:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.684 X-Spam-Level: * X-Spam-Status: No, score=1.684 tagged_above=-999 required=5 tests=[AWL=0.978, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_47=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 f7aqG-J5x3as; Mon, 23 Aug 2010 12:22:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27DB53A6942; Mon, 23 Aug 2010 12:22:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OncUo-000N9F-HO for namedroppers-data0@psg.com; Mon, 23 Aug 2010 19:15:50 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OncUf-000N7O-Tt for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 19:15:42 +0000 Received: by fxm10 with SMTP id 10so3972733fxm.11 for ; Mon, 23 Aug 2010 12:15:40 -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; bh=mOkWzkYq3S3GUwErfRHFtXTx2aBFfYiVSgfUrw/sI8k=; b=hF0Doe+EbofvmooIDpfyUOyo6p06ZNDAvvCVso0RHVSBBFOP5V5O8jJWwsDrAWh59g svEAVln+P/8/pfTiWbv+cXeM2uCWlZW136vFmrXtHpUsrNdPnwop3ifp8DCOIEIRXBZi 5q+h1O40JM91jqVhdCektbol7GJ7FL2oP5REY= 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=WOW8SfdKyCHlPwJLnWwbKWNIAdkaqlkqkkx+q1PfWIR4LxG2AnheMBHi9qH9O80l56 a0rXOZGdwPTUSrlacuEq81tFZvYrDRdrOOlxvW6RlhBZrp7VM7Q3atnVIgPoC4La0DCk FyeKgHrbYVYqSMPaNlzItJxAIdnllAFEl5HYE= MIME-Version: 1.0 Received: by 10.223.121.16 with SMTP id f16mr4865003far.72.1282590940174; Mon, 23 Aug 2010 12:15:40 -0700 (PDT) Received: by 10.223.126.138 with HTTP; Mon, 23 Aug 2010 12:15:40 -0700 (PDT) In-Reply-To: References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> <20100823174044.GG7863@shinkuro.com> Date: Mon, 23 Aug 2010 16:15:40 -0300 Message-ID: Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models From: Brian Dickson To: Ted Hardie Cc: Andrew Sullivan , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=001636c5a4fd619a0a048e827909 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001636c5a4fd619a0a048e827909 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 23, 2010 at 4:01 PM, Ted Hardie wrote: > On Mon, Aug 23, 2010 at 11:28 AM, Brian Dickson > wrote: > > > > If the application is not secure, i.e. the server->client is in the open, > > then the client > > can pretty easily be spoofed with embedded my.searchy.example.com in a > page > > that also > > contains evil.searchy.example.com. Both signed by searchy.example.com, > both > > valid and secure, > > from a protocol perspective - but combined, creating a security nightmare > > and phisher's dream. > > When I try to work this out in venn diagrams in my head, I'm afraid I fail. > If the reference is to my.searchy.example.com, the pointer is to > www.google.com, > but the signature is searchy.example.com's. There's no trust being given > here other than "searchy.example.com asserts my.searchy.example.com is > a pointer to www.google.com". How would it increase the trust in > evil.searchy.example.com? > There are, of course, existing attacks that allow you to embed trusted > content from > a different host in an untrusted context (early frame attacks, etc.), > but this doesn't seem > to actual touch on those in any way I can see. > It was in fact what I was thinking of - the embedded content (early frame attacks), under the new method of securing things (DNSSEC). Normally, if you combine insecure and secure content, the browser application will generate a warning (which the user can ignore, or even select to suppress all such warnings). In the analogous set-up, having a DNSSEC-aware browser present analogous emblems for the security level of the DNS names present in the content, having signed CNAMEs for my.searchy, and signed other-RRs for evil.searchy, would suggest that all the content was DNSSEC-"safe". I'm suggesting that the overall usefulness of DNSSEC is diminished without having the target also validate the pointer - or rather, that we miss the opportunity to provide a means to increase the usefulness of DNSSEC, if we don't provide such a means. > > > > > > You need to think like a bad guy first, before thinking like either a > (big) > > good guy or a little guy. > > > > There's a reason for the DNSSEC model of chained authenticated > delegations > > from a trust anchor. > > Deviations need to be thought out carefully, to ensure they don't create > > vectors for compromising that trust relationship. > > > > But this isn't a deviation. DNSSEC is a mechanism for ensuring what you > got > was what the zone maintainer entered. It has no protection for an evil > zone, > and never did. What Patrik pointed out was that you need to separate the > data asserted by one zone (the CNAME-ing zone) from that which must > be asserted by the other (the target one). I don't think I understand how > the existence of a different label under the CNAME-ing zone relates > to this at all. > > More explanation gratefully received.... > > It would be a label under the target zone, not under the CNAME-ing zone, which gives protection against unilateral signed pointing at a target label in a target zone. It's kind of like the difference between single-entry (cash) accounting, versus double-entry accounting, where debits and credits need to match up. In accounting, it makes it possible to audit the books. In DNS, it provides ways for domain owners (registrants) to exert much more control over their domain. Brian > Ted > > > > Brian > > > >> > >> Is there other behavior desired in defining something as "authentic"? > I'm > >> a little worried about hand waving there if we're already hand-waving > >> "the same" and "data" > >> > >> regards, > >> > >> Ted > >> > >> >> I do not feel A have to "approve" B is referring to A. > >> > > >> > Why not? (I'm not saying you're wrong, but I've heard arguments more > >> > than once in this thread for having such a rule, and it doesn't strike > >> > me as obviously wrong.) Your argument here ("just like PTRs, CNAMEs, > >> > &c.) isn't enough: that's just an appeal to tradition. If we have > >> > that avenue open to us, then we can dismiss all this aliasing work as > >> > needless because we've never done it before. > >> > > >> > A > >> > > >> > -- > >> > Andrew Sullivan > >> > ajs@shinkuro.com > >> > Shinkuro, Inc. > >> > > >> > > >> > > > > > --001636c5a4fd619a0a048e827909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 23, 2010 at 4:01 PM, Ted Har= die <ted.ietf@gm= ail.com> wrote:
On Mon, Aug 23, 2010 at 11:28 AM, Brian Dickson
<brian.peter.dickson@gm= ail.com> wrote:
>
> If the application is not secure, i.e. the server->client is in the= open,
> then the client
> can pretty easily be spoofed with embedded my.searchy.example.com in a page
> that also
> contains evil.searchy.example.com. Both signed by searchy.example.com, both
> valid and secure,
> from a protocol perspective - but combined, creating a security nightm= are
> and phisher's dream.

When I try to work this out in venn diagrams in my head, I'm afra= id I fail.
If the reference is to my.searchy.example.com, the pointer is to www.google.com,
but the signature is searchy.example.com's. =A0There's no trust being given
here other than "searchy.example.com asserts my.searchy.example.com is
a pointer to www.google= .com". =A0How would it increase the trust in
evil.searchy.= example.com?
There are, of course, existing attacks that allow you to embed trusted
content from
a different host in an untrusted context (early frame attacks, etc.),
but this doesn't seem
to actual touch on those in any way I can see.

It was in fact what I was thinking of - the embedded content (early frame = attacks), under
the new method of securing things (DNSSEC).

Normally, if you combine insecure and secure content, the browser applicati= on will generate a warning
(which the user can ignore, or even select to= suppress all such warnings).

In the analogous set-up, having a DNSS= EC-aware browser present analogous emblems for the security
level of the DNS names present in the content, having signed CNAMEs for my.= searchy, and signed other-RRs
for evil.searchy, would suggest that all t= he content was DNSSEC-"safe".

I'm suggesting that the = overall usefulness of DNSSEC is diminished without having the target also v= alidate
the pointer - or rather, that we miss the opportunity to provide a means to= increase the usefulness of DNSSEC,
if we don't provide such a means= .
=A0


>
> You need to think like a bad guy first, before thinking like either a = (big)
> good guy or a little guy.
>
> There's a reason for the DNSSEC model of chained authenticated del= egations
> from a trust anchor.
> Deviations need to be thought out carefully, to ensure they don't = create
> vectors for compromising that trust relationship.
>

But this isn't a deviation. =A0DNSSEC is a mechanism for ensuring= what you got
was what the zone maintainer entered. =A0It has no protection for an evil z= one,
and never did. =A0What Patrik pointed out was that you need to separate the=
data asserted by one zone (the CNAME-ing zone) from that which must
be asserted by the other (the target one). =A0I don't think I understan= d how
the existence of a different label under the CNAME-ing zone =A0relates
to this at all.

More explanation gratefully received....



It would be a = label under the target zone, not under the CNAME-ing zone, which gives prot= ection
against unilateral signed pointing at a target label in a target = zone.

It's kind of like the difference between single-entry (cash) accoun= ting, versus double-entry accounting,
where debits and credits need to m= atch up. In accounting, it makes it possible to audit the books.
In DNS,= it provides ways for domain owners (registrants) to exert much more contro= l over their domain.

Brian

=A0
Ted


> Brian
>
>>
>> Is there other behavior desired in defining something as "aut= hentic"? =A0I'm
>> a little worried about hand waving there if we're already hand= -waving
>> "the same" and "data"
>>
>> regards,
>>
>> Ted
>>
>> >> I do not feel A have to "approve" B is referrin= g to A.
>> >
>> > Why not? =A0(I'm not saying you're wrong, but I'v= e heard arguments more
>> > than once in this thread for having such a rule, and it doesn= 't strike
>> > me as obviously wrong.) =A0Your argument here ("just lik= e PTRs, CNAMEs,
>> > &c.) isn't enough: that's just an appeal to tradi= tion. =A0If we have
>> > that avenue open to us, then we can dismiss all this aliasing= work as
>> > needless because we've never done it before.
>> >
>> > A
>> >
>> > --
>> > Andrew Sullivan
>> > ajs@shinkuro.com
>> > Shinkuro, Inc.
>> >
>> >
>>
>
>

--001636c5a4fd619a0a048e827909-- From owner-namedroppers@ops.ietf.org Mon Aug 23 12: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 699CC3A6ACF; Mon, 23 Aug 2010 12:45:35 -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 tWrMVKST99wK; Mon, 23 Aug 2010 12:45:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E1EDF3A6A7D; Mon, 23 Aug 2010 12:45:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OncuB-0001VI-OC for namedroppers-data0@psg.com; Mon, 23 Aug 2010 19:42:03 +0000 Received: from [2001:4f8:fff7:1::5] (helo=mail1.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oncu8-0001TK-EO for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 19:42:00 +0000 Received: from [198.22.153.9] (helo=[10.60.111.36]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Onctv-000NUD-1i; Mon, 23 Aug 2010 19:41:57 +0000 Message-ID: <4C72CEF9.9080301@gis.net> Date: Mon, 23 Aug 2010 15:41:45 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: Paul Vixie , namedroppers@ops.ietf.org References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <18374.1281714027@nsa.vix.com> <4C6FD98E.2020502@ntp.org> <3EFF9C9D-DBEA-4498-B727-B003812C6602@cisco.com> In-Reply-To: <3EFF9C9D-DBEA-4498-B727-B003812C6602@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 198.22.153.9 X-SA-Exim-Rcpt-To: paf@cisco.com, vixie@isc.org, namedroppers@ops.ietf.org X-SA-Exim-Mail-From: mayer@ntp.org Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 8/23/2010 8:13 AM, Patrik Fältström wrote: > > On 21 aug 2010, at 15.50, Danny Mayer wrote: > >> Why is SMTP a problem? You can always set up the MX records for aliased >> zones to point to just one FQDN and have the PTR record point back to >> the same FQDN. Or am I looking at it from the wrong end? > > Because in reality you do not have A1.B1 and A2.B2. You might have instead, for example: > > AnBnCnDn.EnFnGnHn where you have n=1,..,n=4 and a delegation at the period. > > So in reality you might in this example talk about more than two permutations (although of course not all values and combinations of n=1,..,n=4 makes any sense). But the MX record can point to just one FQDN, no matter what the domain name you choose to use. The target of the MX does not need to have all of the variations of the domain name. The SMTP server just needs to be able to accept all of the possible domains that point to it and that is an SMTP problem and not a DNS problem. Danny From owner-namedroppers@ops.ietf.org Mon Aug 23 13:10: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 BDA8A3A6926; Mon, 23 Aug 2010 13:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 tests=[AWL=0.445, 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 h4FeN28uYk1L; Mon, 23 Aug 2010 13:10:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 88F213A6AD2; Mon, 23 Aug 2010 13:10:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OndIU-000572-3n for namedroppers-data0@psg.com; Mon, 23 Aug 2010 20:07:10 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OndIQ-00056d-QL for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 20:07:07 +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 4253EC5694D; Mon, 23 Aug 2010 21:07:04 +0100 (BST) Date: Mon, 23 Aug 2010 21:07:03 +0100 From: Alex Bligh Reply-To: Alex Bligh To: mayer@gis.net, =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= cc: Paul Vixie , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" Message-ID: <01A3703B1DD6AC4BD168DF06@Ximines.local> In-Reply-To: <4C72CEF9.9080301@gis.net> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <18374.1281714027@nsa.vix.com> <4C6FD98E.2020502@ntp.org> <3EFF9C9D-DBEA-4498-B727-B003812C6602@cisco.com> <4C72CEF9.9080301@gis.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 23 August 2010 15:41:45 -0400 Danny Mayer wrote: > But the MX record can point to just one FQDN, no matter what the domain > name you choose to use. The target of the MX does not need to have all > of the variations of the domain name. The SMTP server just needs to be > able to accept all of the possible domains that point to it and that is > an SMTP problem and not a DNS problem. How does the MX server know whether the domain is local (i.e. whether it should accept mail for it) and if so which local domain it is equivalent to, without manual configuration? -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 23 14: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 4FA693A6AE1; Mon, 23 Aug 2010 14:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ei7FX-r+r8A; Mon, 23 Aug 2010 14:05:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2393E3A686D; Mon, 23 Aug 2010 14:05:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1One98-000CXr-Gw for namedroppers-data0@psg.com; Mon, 23 Aug 2010 21:01:34 +0000 Received: from [2001:4f8:fff7:1::5] (helo=mail1.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1One95-000CXH-S6 for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 21:01:31 +0000 Received: from [198.22.153.9] (helo=[10.60.111.36]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1One8b-0005Zu-MB; Mon, 23 Aug 2010 21:01:12 +0000 Message-ID: <4C72E186.7010901@gis.net> Date: Mon, 23 Aug 2010 17:00:54 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alex Bligh CC: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Paul Vixie , namedroppers@ops.ietf.org References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <18374.1281714027@nsa.vix.com> <4C6FD98E.2020502@ntp.org> <3EFF9C9D-DBEA-4498-B727-B003812C6602@cisco.com> <4C72CEF9.9080301@gis.net> <01A3703B1DD6AC4BD168DF06@Ximines.local> In-Reply-To: <01A3703B1DD6AC4BD168DF06@Ximines.local> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 198.22.153.9 X-SA-Exim-Rcpt-To: alex@alex.org.uk, paf@cisco.com, vixie@isc.org, namedroppers@ops.ietf.org X-SA-Exim-Mail-From: mayer@ntp.org Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 8/23/2010 4:07 PM, Alex Bligh wrote: > > > --On 23 August 2010 15:41:45 -0400 Danny Mayer wrote: > >> But the MX record can point to just one FQDN, no matter what the domain >> name you choose to use. The target of the MX does not need to have all >> of the variations of the domain name. The SMTP server just needs to be >> able to accept all of the possible domains that point to it and that is >> an SMTP problem and not a DNS problem. > > How does the MX server know whether the domain is local (i.e. whether > it should accept mail for it) and if so which local domain it is > equivalent to, without manual configuration? > The same way that you configure any SMTP server. It has to know what it will accept. There's no magic involved. The mail servers that I've configured always expect me to tell it. Besides that's out of scope for this WG. Danny From owner-namedroppers@ops.ietf.org Mon Aug 23 14:43: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 9B99E3A6B03; Mon, 23 Aug 2010 14:43:07 -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.580, 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 i1W8xGlJ7dZ5; Mon, 23 Aug 2010 14:43:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 498253A6AE4; Mon, 23 Aug 2010 14:43:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oneik-000HhC-2k for namedroppers-data0@psg.com; Mon, 23 Aug 2010 21:38:22 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oneif-000Hfn-KO for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 21:38:18 +0000 Received: from [192.168.1.68] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 113A9C56954; Mon, 23 Aug 2010 22:38:14 +0100 (BST) Date: Mon, 23 Aug 2010 22:38:32 +0100 From: Alex Bligh Reply-To: Alex Bligh To: mayer@gis.net cc: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , Paul Vixie , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" Message-ID: In-Reply-To: <4C72E186.7010901@gis.net> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <18374.1281714027@nsa.vix.com> <4C6FD98E.2020502@ntp.org> <3EFF9C9D-DBEA-4498-B727-B003812C6602@cisco.com> <4C72CEF9.9080301@gis.net> <01A3703B1DD6AC4BD168DF06@Ximines.local> <4C72E186.7010901@gis.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 23 August 2010 17:00:54 -0400 Danny Mayer wrote: > The same way that you configure any SMTP server. It has to know what it > will accept. There's no magic involved. The mail servers that I've > configured always expect me to tell it. Besides that's out of scope for > this WG. I thought this was a reply to John Levine's thread on predictive vs. reactive name aliasing. He was in essence making the point reactive name aliasing doesn't work. That means you have to be able to configure names in advance. Firstly, there may be a large number combinatorially. Secondly, the available aliases may change over time and the rules may not be immediately apparent to the mail system owner (e.g. TLDs changing their rules). Thirdly, if the application layer needs to be preconfigured, that makes automatic XNAME stuff less useful. I don't see the point in doing a lot of work at the DNS layer without considering the problems it generates at the application layer. Is asking whether work is actually useful or counterproductive to the application layer really out of scope? -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 23 14:43: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 39C4B3A6B0B; Mon, 23 Aug 2010 14:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.314 X-Spam-Level: ** X-Spam-Status: No, score=2.314 tagged_above=-999 required=5 tests=[AWL=0.208, 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 FjWD5PWM1la6; Mon, 23 Aug 2010 14:43:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 988AB3A6B09; Mon, 23 Aug 2010 14:43:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnejR-000Hly-NE for namedroppers-data0@psg.com; Mon, 23 Aug 2010 21:39:05 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnejJ-000Hkw-TU for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 21:38:58 +0000 Received: by fxm10 with SMTP id 10so4152654fxm.11 for ; Mon, 23 Aug 2010 14:38:56 -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; bh=2WZrMQCMaoQHmHC8RKHWyfdTn1b4RAaMwZTAJO/Ndbs=; b=MQVOP/xKIWAmg1mzhsIDnLVSPb7y5deekzRKO6cfZIJGd34Vna4wdZULakJXL2yqvr rWj1pIx0TAPRE5P54n3F01gYzBBuSy0d0b9YXaXd0XmqDi8r3tfBXB313n0lF9H+aaji aXn1YwfkMSVGuM4RtNIE7HloLt5LiukjkVPqU= 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=Q0+2OAtVK8kUIDqWMTDRE82PefqyXY9vqjUEXv/GjIOg3MgIlpZKyeETlwXvauZygo jjgvbwuPyGyVpCdSNmBr0sY720c5Go01XXq1xOJf1Lvq/kAR1BXnw6cpK+ZRPF4eOTPC 8IP4bPJ8pwDMLvgYgDm5YDwwggW5m9eKr4hfc= MIME-Version: 1.0 Received: by 10.223.108.71 with SMTP id e7mr5149303fap.13.1282599536325; Mon, 23 Aug 2010 14:38:56 -0700 (PDT) Received: by 10.223.126.138 with HTTP; Mon, 23 Aug 2010 14:38:56 -0700 (PDT) In-Reply-To: <20100820215553.GA24798@farside.isc.org> References: <24409.1282244875@nsa.vix.com> <39785.1282261320@nsa.vix.com> <54594.1282275654@nsa.vix.com> <20100820162403.GE96071@shinkuro.com> <20100820215553.GA24798@farside.isc.org> Date: Mon, 23 Aug 2010 18:38:56 -0300 Message-ID: Subject: Re: [dnsext] Problem statement additions From: Brian Dickson To: Suzanne Woolf Cc: Paul Hoffman , Andrew Sullivan , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=001636c5a4e8c07a49048e8479a1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001636c5a4e8c07a49048e8479a1 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 20, 2010 at 6:55 PM, Suzanne Woolf wrote: > On Fri, Aug 20, 2010 at 10:22:22AM -0700, Paul Hoffman wrote: > > > > Assuming that we are still talking about > > draft-yao-dnsext-identical-resolution, which is at -01, I am unsure > > what you are asking for. The document is a list of use cases > > (section 2) and proposals (section 3). The document itself seems to > > describe the problems that DNS users have well. Are you asking for a > > list of problems that zone owners would have? If so, are they the > > apex owners, the subdomain owners, or ...? > > As editor of the document I've come to the conclusion that the next > rev needs an explicit "requirements" section, to gather the ones so > far identified and help further with digging out the hidden > assumptions we seem to be excavating in recent discussion. > > In fact....Broadly speaking, I think the next rev needs: > > 1. More detail on use cases, IDN-related an otherwise. We have basic > descriptions of two IDN-related cases. We need more. I have some > contributions on a couple, but more text is welcome. What we most need > is detailed descriptions of the desired behavior with regards to what > applications see, what caches see, and what users can reasonably > assume. > > 2. More detail on identified limitations on both problems and > solutions. > > 3. An expanded security considerations section, including not only > more discussion of DNSSEC but the SSL issues raised and psosibly > others as well. > > 4. An explicit "requirements" section, including those proposed in > Anaheim and the implicit ones that have been emerging in the list > discussion since Maastricht. > > 5. An overview of the complexity/tradeoffs analyses we've been doing > informally here, with an eye towards explaining to people who are not > DNS protocol experts what the side effects are to even apparently > simple changes to the DNS. > > Text/suggestions welcome. > > I've been giving some thought to a variety of aspects to the problem space and some of the possible solutions (both those in ID form already, and those not yet fully fleshed out). I think, in some use cases, we should think about the deployment timeline, not just generally, but collectively (as in set-wise) across multiple actors in the respective spaces. And, to do so from the perspective of several categories of actor: - domain owner (i.e. registrant who either intrinsically receives, or explicitly requests, multiple domains, IDN or otherwise) - delegation-only zone owner - registry owner - generic, sponsored, cctld - registrar - software vendor for registrar (EPP client) - software vendor for registry (EPP server0 - software vendor for DNS authority server - software vendor for DNS resolver - software vendor for DNS stub resolver - operator of DNS resolver (included with ISP service) - operator of DNS resolver (open resolver) - any others? And to complicate things further, let us consider that not all such actors are going to be what is considered a "rational actor", i.e. looking at the big picture, acting logically, or even acting in their own self interest. We sometimes forget that even when a large proportion of actors in a given space act rationally, not all do, and not always on the same time scale. (Or maybe we don't, but it just hasn't surfaced in the present discussion.) I think we need to consider, for each proposed solution, in addition to the benefits and costs, how universally it needs to be implemented and deployed, in what segments in the list of actors, before the solution can be considered useful enough to warrant use by its target use case group. Here are some examples of the deployment issues, as I see them: - If a new RR type is needed for equivalence, *above* the apex of the domain owner (e.g. in any of the delegation zones), it matters a great deal: -- which parent zones support that RR type -- whether, given the owner's desire to have N equivalent names, all parents of the N names support the RR type -- or whether N-1 parents support the RR type -- and if the number is N-1, whether the N'th parent supports other necessary elements (from the perspective of the owner), such as DNSSEC -- which registrars support the new RR type, and how -- which vendors support serving the new RR type (if such type is not generically supported) -- which operators have deployed support for the new RR type - If more than one means for achieving equivalence is available: -- that they are sufficiently compatible so as to co-exist for the same "target" name for a given owner -- that there be incremental incentives for all parties involved, to deploy anything "new" -- that there be a progression between methods, which always involves a positive benefit to the party making the needed change -- Having one minimal cost early-deployment mechanism makes a lot of sense, pragmatically -- Having a maximum-benefit mechanism available with the fewest "moving parts" which need to be changed makes a lot of sense -- The long tail needs to be considered not only in each component, but on a collective basis ---- This suggests that unless universal deployment in at least one dimension (all TLDs, all validators, all recursive resolvers, or all stub resolvers), the diminishing returns from individual domain owners being members of the non-deployed overlap zones leads away from solutions involving larger number of required component changes - If possible, isolate the changes to elements which are involved in DNSSEC, so as to minimize the need to change non-DNSSEC components, for maximum backwards compatibility -- Most of the scaling issues have to do with either duplication of data, or the performance penalty of DNSSEC signing of duplicated data (with different signers) - If possible, isolate the changes needed to local components, so as to not require coordinated changes to the participants in multiple segments of the food chain -- Otherwise, there is a non-zero probability that some subset of the domain owners will be unable to benefit from the changes, as the providers they must use or choose among, don't support the needed functionality -- This comes from thinking of things from the perspective of a domain owner, and "not blaming the victim" - the domain owner does not get to choose his situation, i.e. which TLDs he needs to register domains in - If possible, ensure that there is no need to choose between multiple domain support (IDN et al) and DNSSEC support -- Further, ensure that there is no performance penalty for using both, as this would present a barrier to deployment -- Again, this points towards isolated elements rather than interconnected functionality (above the apex) changes, since multiple domains are by definition involved - There is a non-obvious benefit to focusing on the zone apex, for where to implement solutions(s): -- Every zone _has_ an apex -- Every zone, no matter how large or small, has _one_ apex -- Large zones benefit from apex-specific solutions in that the least number of changes are required, and the greatest benefit is seen by large zones, if there is a performance benefit to be seen -- Small zones benefit by having the changes being local to within their own sphere of operations (zone of control as it were) -- Coordination is not required, either operationally (between registrants, registrars, registries, and DNS authority delegation-only servers) or developmentally (multi-vendor, multi-function coordination being the worst-case scenario from a software perspective) -- Additional elements fit semantically quite nicely there: canonical zone identity, permitted zone aliases (AKA), any others? -- The apex is in some respects "label-free" (at least relative to the zone owner name) (Um, sorry for another long analytical post...) Here's where I see this analysis pointing: - SHADOW has operational benefit to domain owners, but still has performance penalties (each name needs to be signed by every owner combination) - Changes to validation (and *only* validation), by either: -- simply changing the rules to allow apex KSK-only signing of DNSKEY sets, as a means of signaling zone equivalence (implicitly) -- adding new RR types to the apex, to explicitly signal allowed signers (canonical) plus zone names to which this applies (AKA names) - C+D might work (but take a long time and have signaling issues) - bname might work (but take a very long time for similar reasons) - provisioned zones with DNAMES (Andrew's suggestion) might be feasible - The above are increasing time to deploy, and decreased incentive to deploy - The TLDs and ICANN are likely to play a large roll in deployment - Finding ways to play nice with the TLDs, and *not* *require* any changes by them to achieve most of the benefits, should be a large consideration to the choices of solution - No single solution can be considered adequate. Brian --001636c5a4e8c07a49048e8479a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Aug 20, 2010 at 6:55 PM, Suzanne= Woolf <woolf@isc.org= > wrote:
On Fri, Aug 20, 2010 at 10:22:22AM -0700, Paul Hoffman wr= ote:
>
> Assuming that we are still talking about
> draft-yao-dnsext-identical-resolution, which is at -01, I am unsure > what you are asking for. The document is a list of use cases
> (section 2) and proposals (section 3). The document itself seems to > describe the problems that DNS users have well. Are you asking for a > list of problems that zone owners would have? If so, are they the
> apex owners, the subdomain owners, or ...?

As editor of the document I've come to the conclusion that the ne= xt
rev needs an explicit "requirements" section, to gather the ones = so
far identified and help further with digging out the hidden
assumptions we seem to be excavating in recent discussion.

In fact....Broadly speaking, I think the next rev needs:

1. More detail on use cases, IDN-related an otherwise. We have basic
descriptions of two IDN-related cases. We need more. I have some
contributions on a couple, but more text is welcome. What we most need
is detailed descriptions of the desired behavior with regards to what
applications see, what caches see, and what users can reasonably
assume.

2. More detail on identified limitations on both problems and
solutions.

3. An expanded security considerations section, including not only
more discussion of DNSSEC but the SSL issues raised and psosibly
others as well.

4. An explicit "requirements" section, including those proposed i= n
Anaheim and the implicit ones that have been emerging in the list
discussion since Maastricht.

5. An overview of the complexity/tradeoffs analyses we've been doing informally here, with an eye towards explaining to people who are not
DNS protocol experts what the side effects are to even apparently
simple changes to the DNS.

Text/suggestions welcome.



I've been giving some thought to a variet= y of aspects to the problem space and some of the possible solutions (both = those in ID form already, and those not yet fully fleshed out).

I think, in some use cases, we should think about the deployment timeline, = not just generally, but collectively (as in set-wise) across multiple actor= s in the respective spaces.

And, to do so from the perspective of se= veral categories of actor:
- domain owner (i.e. registrant who either intrinsically receives, or expli= citly requests, multiple domains, IDN or otherwise)
- delegation-only zo= ne owner
- registry owner - generic, sponsored, cctld
- registrar
- software vendor for registrar (EPP client)
- software vendor for regis= try (EPP server0
- software vendor for DNS authority server
- softwar= e vendor for DNS resolver
- software vendor for DNS stub resolver
- operator of DNS resolver (included with ISP service)
- operator of DNS= resolver (open resolver)
- any others?

And to complicate things = further, let us consider that not all such actors are going to be what is c= onsidered a "rational actor", i.e. looking at the big picture, ac= ting logically, or even acting in their own self interest.

We sometimes forget that even when a large proportion of actors in a gi= ven space act rationally, not all do, and not always on the same time scale= . (Or maybe we don't, but it just hasn't surfaced in the present di= scussion.)

I think we need to consider, for each proposed solution, in addition to= the benefits and costs, how universally it needs to be implemented and dep= loyed, in what segments in the list of actors, before the solution can be c= onsidered useful enough to warrant use by its target use case group.

Here are some examples of the deployment issues, as I see them:

= - If a new RR type is needed for equivalence, *above* the apex of the domai= n owner (e.g. in any of the delegation zones), it matters a great deal:
-- which parent zones support that RR type
-- whether, given the owner&#= 39;s desire to have N equivalent names, all parents of the N names support = the RR type
-- or whether N-1 parents support the RR type
-- and if t= he number is N-1, whether the N'th parent supports other necessary elem= ents (from the perspective of the owner), such as DNSSEC
-- which registrars support the new RR type, and how
-- which vendors su= pport serving the new RR type (if such type is not generically supported)-- which operators have deployed support for the new RR type

- If = more than one means for achieving equivalence is available:
-- that they are sufficiently compatible so as to co-exist for the same &qu= ot;target" name for a given owner
-- that there be incremental ince= ntives for all parties involved, to deploy anything "new"
-- that there be a progression between methods, which always involves a pos= itive benefit to the party making the needed change
-- Having one minima= l cost early-deployment mechanism makes a lot of sense, pragmatically
-- Having a maximum-benefit mechanism available with the fewest "movin= g parts" which need to be changed makes a lot of sense
-- The long = tail needs to be considered not only in each component, but on a collective= basis
---- This suggests that unless universal deployment in at least one dimensi= on (all TLDs, all validators, all recursive resolvers, or all stub resolver= s), the diminishing returns from individual domain owners being members of = the non-deployed overlap zones leads away from solutions involving larger n= umber of required component changes

- If possible, isolate the changes to elements which are involved in DN= SSEC, so as to minimize the need to change non-DNSSEC components, for maxim= um backwards compatibility
-- Most of the scaling issues have to do with= either duplication of data, or the performance penalty of DNSSEC signing o= f duplicated data (with different signers)

- If possible, isolate the changes needed to local components, so as to= not require coordinated changes to the participants in multiple segments o= f the food chain
-- Otherwise, there is a non-zero probability that some= subset of the domain owners will be unable to benefit from the changes, as= the providers they must use or choose among, don't support the needed = functionality
-- This comes from thinking of things from the perspective of a domain owne= r, and "not blaming the victim" - the domain owner does not get t= o choose his situation, i.e. which TLDs he needs to register domains in

- If possible, ensure that there is no need to choose between multiple = domain support (IDN et al) and DNSSEC support
-- Further, ensure that th= ere is no performance penalty for using both, as this would present a barri= er to deployment
-- Again, this points towards isolated elements rather than interconnected = functionality (above the apex) changes, since multiple domains are by defin= ition involved

- There is a non-obvious benefit to focusing on the z= one apex, for where to implement solutions(s):
-- Every zone _has_ an apex
-- Every zone, no matter how large or small,= has _one_ apex
-- Large zones benefit from apex-specific solutions in t= hat the least number of changes are required, and the greatest benefit is s= een by large zones, if there is a performance benefit to be seen
-- Small zones benefit by having the changes being local to within their ow= n sphere of operations (zone of control as it were)
-- Coordination is n= ot required, either operationally (between registrants, registrars, registr= ies, and DNS authority delegation-only servers) or developmentally (multi-v= endor, multi-function coordination being the worst-case scenario from a sof= tware perspective)
-- Additional elements fit semantically quite nicely there: canonical zone = identity, permitted zone aliases (AKA), any others?
-- The apex is in so= me respects "label-free" (at least relative to the zone owner nam= e)

(Um, sorry for another long analytical post...)

Here= 's where I see this analysis pointing:
- SHADOW has operational bene= fit to domain owners, but still has performance penalties (each name needs = to be signed by every owner combination)
- Changes to validation (and *only* validation), by either:
-- simply ch= anging the rules to allow apex KSK-only signing of DNSKEY sets, as a means = of signaling zone equivalence (implicitly)
-- adding new RR types to the= apex, to explicitly signal allowed signers (canonical) plus zone names to = which this applies (AKA names)
- C+D might work (but take a long time and have signaling issues)
- bnam= e might work (but take a very long time for similar reasons)
- provision= ed zones with DNAMES (Andrew's suggestion) might be feasible
- The a= bove are increasing time to deploy, and decreased incentive to deploy
- The TLDs and ICANN are likely to play a large roll in deployment
- Fin= ding ways to play nice with the TLDs, and *not* *require* any changes by th= em to achieve most of the benefits, should be a large consideration to the = choices of solution
- No single solution can be considered adequate.

Brian
--001636c5a4e8c07a49048e8479a1-- From owner-namedroppers@ops.ietf.org Mon Aug 23 14:51: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 1C6EC3A68C3; Mon, 23 Aug 2010 14:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.17 X-Spam-Level: X-Spam-Status: No, score=-102.17 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, 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 1ww-8SUKmBQK; Mon, 23 Aug 2010 14:51:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D777D3A688B; Mon, 23 Aug 2010 14:51:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnesL-000J7p-Vt for namedroppers-data0@psg.com; Mon, 23 Aug 2010 21:48:17 +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.72 (FreeBSD)) (envelope-from ) id 1OnesG-000Ivh-LL for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 21:48:14 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o7NLkkA1021044; Mon, 23 Aug 2010 21:46:51 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o7NLkjDT021043; Mon, 23 Aug 2010 21:46:45 GMT Date: Mon, 23 Aug 2010 21:46:45 +0000 From: bmanning@vacation.karoshi.com To: "John R. Levine" Cc: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models Message-ID: <20100823214645.GA20956@vacation.karoshi.com.> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.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 Mon, Aug 23, 2010 at 09:50:54AM -0400, John R. Levine wrote: > >No, a client is to use B for a service, finds it is an alias for A and > >uses A when communicating with the server. The server only knows about > >A, not B. There is no configuration "on the fly" going on. > > Hmmn, so we upgrade billions of client programs rather than millions of > servers. I suppose. stub resolvers seem to gets swapped out more frequently than servers. the focus on stubs also reduces the attack surface, if that is of interest. (noting that 15+years of empericial survey data suggest that the spread of code varients in servers is widening instead of shrinking) just saying. > I'm also thinking about the security model in which a client says "the > user asked for B but I'm pretending he asked for A". At the very least, > the server better verify that's an alias it approves of. oh well - yet another vector for tortuous interference by random third parties - eh? --bill > > R's, > John From owner-namedroppers@ops.ietf.org Mon Aug 23 15:20: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 F03473A6AF2; Mon, 23 Aug 2010 15:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.282 X-Spam-Level: X-Spam-Status: No, score=0.282 tagged_above=-999 required=5 tests=[AWL=-0.712, 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 Dd92PTR15i-y; Mon, 23 Aug 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 7DF5F3A688B; Mon, 23 Aug 2010 15:20:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnfJJ-000NN3-VZ for namedroppers-data0@psg.com; Mon, 23 Aug 2010 22:16:10 +0000 Received: from [209.85.161.180] (helo=mail-gx0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnfJG-000NMF-75 for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 22:16:06 +0000 Received: by gxk22 with SMTP id 22so3535143gxk.11 for ; Mon, 23 Aug 2010 15:16:05 -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=gT2P2XMDXfEfj140LBeDaqvROpAGKSYkcJnHXpzY9VY=; b=soJBsTrBJfMMKtMV1mQfPSsQ52gcLjSwGr9yYJqVkZ4lHi0nbc30z1VcXBEevCB7LW wi3fo5Yj/Y7I2fasA2w0l651kffl7p/YSM9rMk6cFEt+UaWTurJo6GOii6TwXMs4yLCW nlOAm1AIj4A7fVyC4VMOEfvfq+NI0GqIPpgBA= 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=ojAqFODkVtt6sy/KP23J8F6lyjwCbcisTvu8pu1GGmfQCYH0QaN0V95VxlxX14vGnz g3233wUY3jAsm6HUTJoqg/AUhX71WXRvPam7bw7gL+7z5vY25vLP+48Ec12tc4PvVqlY VVA5sI4hZSwEIDYy3RIRAuwcSW6z09M1TOB4E= MIME-Version: 1.0 Received: by 10.213.98.82 with SMTP id p18mr4394117ebn.46.1282601764961; Mon, 23 Aug 2010 15:16:04 -0700 (PDT) Received: by 10.14.45.66 with HTTP; Mon, 23 Aug 2010 15:16:04 -0700 (PDT) In-Reply-To: <20100823182010.GJ7863@shinkuro.com> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823172045.GE7863@shinkuro.com> <20100823174044.GG7863@shinkuro.com> <20100823182010.GJ7863@shinkuro.com> Date: Mon, 23 Aug 2010 15:16:04 -0700 Message-ID: Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models From: Ted Hardie 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: On Mon, Aug 23, 2010 at 11:20 AM, Andrew Sullivan wrote: > Hat still doffed. > > Recall, however, that at least part of our goal amounts to solving a > user interface problem. =A0We have users who type things in one way, but > that is not the "canonical" way. =A0Nevertheless, it's the way that is > natural for them, given their input methods and so on. > > I would be somewhat surprised if the communities who have that problem > would think it just fine and dandy if the canonical name ended up > being the only thing that users could actually use (i.e. that their > display would quickly convert to the canonical name once that link was > discovered in the DNS): this is more "second-class citizen" than I had > heretofore contemplated. =A0Since this isn't my itch, I can't tell how > to scratch it. =A0Is such a restriction really ok? > And the answer is awful: it depends. In some of these contexts, the idea that something is moved to a normalized version will no doubt be okay; the user will treat this as a handy fix-up of their entry. In others, I su= spect that there will be real political pressure to retain multiple "real" domain= s. My off-the-cuff guess is that in the latter cases xName, shadow, et al. won= 't work in practice because the situation requires the complexity to allow british.humour.example to be the "real domain" american.humor.example to be the "real domain" and geek.humor.example and geek.humour.example to be on equal fotting. You can do any of the above using a canonical name, but you need something acting as a presentation layer to get the user view right (and it is likely to be an app-specific presentation layer in our current world). > To be clear about what we're supposing: I was moderately surprised > just now at the results for the following names, for instance: > > =A0 =A0bonjourquebec.com > =A0 =A0bonjourquebec.ca > =A0 =A0bonjourqu=E9bec.com > =A0 =A0bonjourqu=E9bec.ca > > If you go to the website, the first three are the same (and they all > get you to the first of them; the last one doesn't work because .ca > doesn't have IDNA support). =A0None of this is done in the DNS. =A0What's > interesting is that the accent on the e gets dropped. =A0Is that what > we'd expect? =A0Is it ok? > I would personally suspect that once the 4th is live, all the others will point to it and the result would no longer be a surprise. But that's the view of an anglophone non-Canadian, and I'm not a good test. >> Is there other behavior desired in defining something as "authentic"? = =A0I'm >> a little worried about hand waving there if we're already hand-waving >> "the same" and "data" > > Me, too. > > I'm not sure that we need to overload the word "authentic" here, > however. =A0The point is to deliver behaviour that is predictable and > more or less intuitive, I think. =A0One of those intuitions might lead > one to say that nobody can make an alias of your name unless you say > so. I think trying to match intuitions which aren't going to be consistent is a very hard task indeed. I also suspect that your last statement isn't true in the state Patrik originally envisioned--in which you get back a pointer to the real name passed up the stack. It doesn't leave the app dealing with a symlink--it acts closer to a redirect. (And analogies here are going to bite us in the long run, but I don't see a way around it right now). >=A0That's not the way we've historically done it, but it's not hard > to imagine. =A0After all, if you go making symlinks on a filesystem to > files you can't read, you still can't open them. > The broken behavior here would be allow the app to be presented the CNAME and use it to talk to google.com without ever passing the forward pointer up the stack. If the google search engine accepted any host string, that might be an issue. > A > > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > > From owner-namedroppers@ops.ietf.org Mon Aug 23 15: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 918233A6AFB; Mon, 23 Aug 2010 15:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.922 X-Spam-Level: X-Spam-Status: No, score=-3.922 tagged_above=-999 required=5 tests=[AWL=-0.623, 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 Rv6cnmsowirA; Mon, 23 Aug 2010 15:42:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 58FFB3A67FE; Mon, 23 Aug 2010 15:42:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onff8-0000KX-4X for namedroppers-data0@psg.com; Mon, 23 Aug 2010 22:38:42 +0000 Received: from [131.111.8.133] (helo=ppsw-33.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onff5-0000JK-Bv for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 22:38:39 +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]:34389) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Onff1-0004GS-hp (Exim 4.72) (return-path ); Mon, 23 Aug 2010 23:38:35 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Onff1-0005OV-IT (Exim 4.67) (return-path ); Mon, 23 Aug 2010 23:38:35 +0100 Date: Mon, 23 Aug 2010 23:38:35 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "John R. Levine" cc: =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models In-Reply-To: Message-ID: References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> 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 Mon, 23 Aug 2010, John R. Levine wrote: > > Right. This isn't something DNSSEC addresses at all. In this model, the set > of alias names is entirely under control of the operators of the aliases, not > the resource they redirect to. Yes. > With HTTP redirects, they may not be authenticated but at least they're > under control of the server. Under control of the server referred to by the alias but not the target server. > I haven't worked out all the various threat models, but the idea that random > bad guys can invent new names for my web servers or my mail system and I > wouldn't even know about them does not give me a warm feeling. > > Also, although I certainly don't think we should try to define user > interfaces, we should at least have reasonable answers for questions like if > the user asked for B, and his client asked the server for A instead, what name > should appear in feedback like a browser's address bar? At least HTTP redirects replace the contents of the URL bar. SMTP doesn't have a sensible way of providing that kind of feedback. Other protocols don't have any kind of redirect support. > Oh, and one more data point: the mail RFCs consistently say that mail clients > should resolve CNAMEs and use the resolved name, and mail clients consistently > don't do that (and not just because the authors haven't read the RFCs.) > There's a lesson there. That was true in RFC 821 + RFC 1123, but it was dropped by DRUMS and is no longer required by RFC 2821 / RFC 5321. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT: CYCLONIC SEVERE GALE 9 TO VIOLENT STORM 11, BECOMING WEST 6 TO GALE 8. ROUGH OR VERY ROUGH. RAIN OR SQUALLY SHOWERS. MODERATE OR POOR. From owner-namedroppers@ops.ietf.org Mon Aug 23 15:59: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 4D7783A6B35; Mon, 23 Aug 2010 15:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.713 X-Spam-Level: X-Spam-Status: No, score=-108.713 tagged_above=-999 required=5 tests=[AWL=0.067, 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, SARE_MILLIONSOF=0.315, 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 duTwLwjCv6Gn; Mon, 23 Aug 2010 15:59:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E708C3A6AFB; Mon, 23 Aug 2010 15:59:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onfw9-0002it-5N for namedroppers-data0@psg.com; Mon, 23 Aug 2010 22:56:17 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onfw6-0002iO-IE for namedroppers@ops.ietf.org; Mon, 23 Aug 2010 22:56:14 +0000 Received: (qmail 87138 invoked from network); 23 Aug 2010 22:56:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=gMe85IvenNdod1Mrgu++nYYZiqjwU+nPOM/iQVZhfRc=; b=j2L7cfxcLRcVaRDsMX4+fUTsjlbKxG8bjZ6u3jpNGLxDknhD9Q6Unf0AVsVAJkHVNEagJqeU7cOsGlFr24sJ4Ot69nEi+gUWfUAcNaRWLahLGYU6falzM1wBIsz5CiMEMEmxmk+unNC4VuhLCUgaHJGIUKaVtTGN0vWBmDLolIs= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Aug 2010 22:55:50 -0000 Date: 23 Aug 2010 18:56:06 -0400 Message-ID: From: "John R. Levine" To: bmanning@vacation.karoshi.com Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models In-Reply-To: <20100823214645.GA20956@vacation.karoshi.com.> References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> <4D09F03B-6158-47F3-B4F5-F956486D6F24@cisco.com> <20100823214645.GA20956@vacation.karoshi.com.> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: >> Hmmn, so we upgrade billions of client programs rather than millions of >> servers. I suppose. > > stub resolvers seem to gets swapped out more frequently than > servers. the focus on stubs also reduces the attack surface, > if that is of interest. That's different from my experience, but in any event, it ain't just stub resolvers. It seems to me that if the world were going to handle aliases in the clients, they'd be doing it now. If we imagine an HTTP extension in which the client can send both the original name and the canonical name, you'd publish the alias via CNAME, clients would do a normal lookup for an A record, and if the name of the A record returned didn't match the name it looked up via a CNAME chain, now it's got the original name and the alias. Web clients don't do that and show no likelihood of doing that. Why not? Blaming it on gethostbyname() seems pretty feeble, and in the meantime, we're using our scripts to generate shadow zones for servers. > (noting that 15+years of empericial survey data suggest that > the spread of code varients in servers is widening instead of > shrinking) I believe it, but there's literally a billion, maybe two billion web browsers in use, quite a lot of which won't be upgraded until the device on which they're running is discarded. People who run servers have the incentive to make this stuff work so their clients can get to them. Clients who find web sites or whatever inaccessible are much more likely to blame the remote site (well, other sites work so it can't be my problem) and will just look elsewhere. > oh well - yet another vector for tortuous interference by > random third parties - eh? tortious, too. R's, John From owner-namedroppers@ops.ietf.org Mon Aug 23 17:46: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 56F553A6A3F; Mon, 23 Aug 2010 17:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.059 X-Spam-Level: X-Spam-Status: No, score=-102.059 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, J_CHICKENPOX_93=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 y1qpIUDpokHd; Mon, 23 Aug 2010 17:46:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F7063A6966; Mon, 23 Aug 2010 17:46:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnhZM-000EMA-Qx for namedroppers-data0@psg.com; Tue, 24 Aug 2010 00:40:52 +0000 Received: from [2001:1890:1112:1::2f] (helo=rfc-editor.org) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnhZJ-000ELj-Eo for namedroppers@ops.ietf.org; Tue, 24 Aug 2010 00:40:49 +0000 Received: by rfc-editor.org (Postfix, from userid 30) id 78C72E06CE; Mon, 23 Aug 2010 17:40:48 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: [dnsext] RFC 5966 on DNS Transport over TCP - Implementation Requirements From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org Message-Id: <20100824004048.78C72E06CE@rfc-editor.org> Date: Mon, 23 Aug 2010 17:40:48 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: A new Request for Comments is now available in online RFC libraries. RFC 5966 Title: DNS Transport over TCP - Implementation Requirements Author: R. Bellis Status: Standards Track Stream: IETF Date: August 2010 Mailbox: ray.bellis@nominet.org.uk Pages: 7 Characters: 14970 Updates: RFC1035, RFC1123 I-D Tag: draft-ietf-dnsext-dns-tcp-requirements-03.txt URL: http://www.rfc-editor.org/rfc/rfc5966.txt This document updates the requirements for the support of TCP as a transport protocol for DNS implementations. [STANDARDS TRACK] This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From owner-namedroppers@ops.ietf.org Mon Aug 23 19:08: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 3375A3A680B; Mon, 23 Aug 2010 19:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.871 X-Spam-Level: X-Spam-Status: No, score=-108.871 tagged_above=-999 required=5 tests=[AWL=0.224, 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, 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 g-SZC19p437C; Mon, 23 Aug 2010 19:08:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E36413A6973; Mon, 23 Aug 2010 19:08:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oniqj-000NGm-Rs for namedroppers-data0@psg.com; Tue, 24 Aug 2010 02:02:53 +0000 Received: from [64.57.183.53] (helo=gal.iecc.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oniqg-000NGC-Qa for namedroppers@ops.ietf.org; Tue, 24 Aug 2010 02:02:51 +0000 Received: (qmail 47250 invoked from network); 24 Aug 2010 02:02:46 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 24 Aug 2010 02:02:46 -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=k1008; olt=johnl@user.iecc.com; bh=CZYfrsUur8FdiSSmxeWNmfYOvn4JdsfU8XPbvwvne0g=; b=bwrtMlNQ9Pdf1Mg2gI1taSN8bSUOsWQ5X0x7a2sHzwz2NZOc/QttnbiPw7DxUWRRk8JKADbnTLne8GnOQpd6/e5XbizpprDdVsRt7RhDIy4+naHQYXMJ/lnnWmXl0wC8D/s0FFQ3PoO6FN51gGVi3ZT+9Mv6hgTLfamkgzeA5z8= Date: 24 Aug 2010 02:02:41 -0000 Message-ID: <20100824020241.71502.qmail@joyce.lan> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Predictive vs. reactive name aliasing models In-Reply-To: Organization: Cc: paf@cisco.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: Man, I go away for a few hours to take my daughter to the dentist, and look how much I missed. >I still think we should list requirements. And compile a list. Then >we can discuss in a more constructive way. Yes indeed. Let me see if I can clarify what my thinking a little. I hope we agree that a design where there are two parallel sets of info that have to be kept in sync by hand for a system to work is, at least, something we'd like to avoid. As a concrete example, if a web site has a bunch of equivalent names, both the DNS and the web server have to be configured to handle them all. So what could we add to the DNS so that the list of equivalent names is only stored in one place? My thought was that the application is manually configured with the canonical name, and it pulls the rest of the names from the DNS. As far as users can tell, all the names can be equivalent; picking one as canonical is just to give the application a place to start. That's the point of the backward pointers in the DNS, so that the application can tell what names it's supposed to handle, as opposed to which ones are just pointed by random possibly hostile parties. R's, John From owner-namedroppers@ops.ietf.org Tue Aug 24 01:04: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 BB0BA3A6875; Tue, 24 Aug 2010 01:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.673 X-Spam-Level: * X-Spam-Status: No, score=1.673 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwXb4K4RCx34; Tue, 24 Aug 2010 01:04:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 412BE3A6834; Tue, 24 Aug 2010 01:04:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnoOH-000C6r-Q0 for namedroppers-data0@psg.com; Tue, 24 Aug 2010 07:57:53 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OnoOF-000C6F-Bq for namedroppers@ops.ietf.org; Tue, 24 Aug 2010 07:57:51 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1OnoO4-0000Rx-LU; Tue, 24 Aug 2010 07:57:40 +0000 Received: by bfk.de with local id 1OnoO4-0005DL-EC; Tue, 24 Aug 2010 07:57:40 +0000 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: John Levine , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Problem statement additions References: <20100823025747.35936.qmail@joyce.lan> <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> From: Florian Weimer Date: Tue, 24 Aug 2010 07:57:40 +0000 In-Reply-To: <182AAB93-8F0E-4F2A-8369-0E0104E043C8@cisco.com> ("Patrik =?iso-8859-1?Q?F=E4ltstr=F6m=22's?= message of "Mon\, 23 Aug 2010 07\:43\:58 +0200") Message-ID: <82eido5tor.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Patrik F=E4ltstr=F6m: > I do not see any need though for "given B, let me know all A that > refer to it as the canonical name". Initialization of the Cw macro in Sendmail (which contains the list of domains for which mail is to be delivered locally). This was not needed for CNAME because resolving CNAMEs was the responsibility of the sender. However, these days, few senders resolver CNAMEs (and I don't think Sendmail got it right, either), so you need to explicitly configure the local domain list anyway, and the reverse lookup capability seems less important. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Tue Aug 24 09:21: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 B3F0E3A689E; Tue, 24 Aug 2010 09:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.291 X-Spam-Level: X-Spam-Status: No, score=-99.291 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, 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 L2B6R9Ovyy5R; Tue, 24 Aug 2010 09:21:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 014D43A6897; Tue, 24 Aug 2010 09:21:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onw9h-0007k5-5P for namedroppers-data0@psg.com; Tue, 24 Aug 2010 16:15:21 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Onw9d-0007jL-AL for namedroppers@ops.ietf.org; Tue, 24 Aug 2010 16:15:17 +0000 Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7OGF6k0099458; Tue, 24 Aug 2010 12:15:07 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Tue, 24 Aug 2010 12:15:12 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 24 Aug 2010 12:15:12 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4C29F2FE.50302@cisco.com> References: <55156.1274856474@nsa.vix.com> <33BE205400654B708840CBF6E0A3D5D8@local> <4C29F2FE.50302@cisco.com> Date: Tue, 24 Aug 2010 12:10:00 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: [dnsext] draft-eastlake-dnsext-xnamercode-02 was Re: CNAME and NXDOMAIN Cc: Donald Eastlake , ed.lewis@neustar.biz Content-Type: multipart/alternative; boundary="============_-929455990==_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: --============_-929455990==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" (http://tools.ietf.org/html/draft-eastlake-dnsext-xnamercode-02) Okay, so I am not letting the go easily. In RFC 1035, section 4.1.1, the definition of the RCODE=Name Error is given as this: 3 Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist. "Referenced in the query" is the phrase that piques my interest here. In RFC 2308, section 2.1, 2.1 - Name Error Name errors (NXDOMAIN) are indicated by the presence of "Name Error" in the RCODE field. In this case the domain referred to by the QNAME does not exist. Note: the answer section may have SIG and CNAME RRs and the authority section may have SOA, NXT [RFC2065] and SIG RRsets. followed by its TYPE 1 example. From comparing these two, I'd say that 2308 is mistaken in the example. In 1035, an NXDOMAIN referring to the name in the query to me reads as there would no RR sets matching (no CNAME and nothing to sign). I ran across this again in looking carefully at the AA bit - which is defined to apply to the queried name only. The only appearance of AA in 2308 is in section 10 (titled "Example") and that example is at best under-specified. This is a query against a cache, not the authority. Today, caches don't work this way. Also, looking at the definition in 1035, I wonder if a cache should ever return a Name Error. (Obviously, the goal isn't to declare all known recursive servers wrong, the alternative is to document the deviation from the full standard...and at some point elevate the deviation to full standard too.) At 9:19 -0400 6/29/10, Josh Littlefield wrote: >I think the I-D captures the alternatives correctly, and I agree that >"B" is the best alternative, as well as being consistent with RFC 2308. > >-josh > >Donald Eastlake wrote: >> I also agree that B is the best alternative and should be the >> mandatory behavior. >> >> Thanks, >> Donald >> >> On Tue, Jun 22, 2010 at 1:30 PM, George Barwood >> wrote: >> >>> It's my view that alternative 3.B is correct. >>> >>> When an xNAME chain is followed, all but the last query cycle >>> necessarily had no error. The RCODE in the ultimate DNS response MUST >>> BE set based on the final query cycle leading to that response. If >>> the xNAME chain was terminated by an error, it will be that error >>> code. If the xNAME chain terminated without error, it will be zero. >>> >>> If the final query cycle gives rise to a NXDOMAIN, then there must be a >>> NXDOMAIN >>> NSEC proof in the response, and a validating resolver will check that this >>> proof is correct. >>> >>> It would be bizarre I think for the RCODE not to match the NSEC proof that >>> is present. >>> >>> George >>> >>> ----- Original Message ----- >>> From: Donald Eastlake >>> To: namedroppers@ops.ietf.org >>> Sent: Tuesday, June 08, 2010 3:27 PM >>> Subject: Re: [dnsext] CNAME and NXDOMAIN >>> To help facilitate the resolution of this question I have written a draft, >>> current version >>> http://tools.ietf.org/html/draft-eastlake-dnsext-xnamercode-02 >>> >>> >>> >> >> > >-- >Josh Littlefield Cisco Systems, Inc. >joshl@cisco.com 1414 Massachusetts Avenue >Phone: +1 978-936-0001 Boxborough, MA 01719-2205 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh. --============_-929455990==_ma============ Content-Type: text/html; charset="us-ascii" draft-eastlake-dnsext-xnamercode-02 was Re: CNAME and NXDO
(http://tools.ietf.org/html/draft-eastlake-dnsext-xnamercode-02)

Okay, so I am not letting the go easily.

In RFC 1035, section 4.1.1, the definition of the RCODE=Name Error is given as this:

                3               Name Error - Meaningful only for
                                responses from an authoritative name
                                server, this code signifies that the
                                domain name referenced in the query does
                                not exist.
"Referenced in the query" is the phrase that piques my interest here.

In RFC 2308, section 2.1,

2.1 - Name Error

   Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
   in the RCODE field.  In this case the domain referred to by the QNAME
   does not exist.  Note: the answer section may have SIG and CNAME RRs
   and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.
followed by its TYPE 1 example.

From comparing these two, I'd say that 2308 is mistaken in the example.  In 1035, an NXDOMAIN referring to the name in the query to me reads as there would no RR sets matching (no CNAME and nothing to sign).

I ran across this again in looking carefully at the AA bit - which is defined to apply to the queried name only.

The only appearance of AA in 2308 is in section 10 (titled "Example") and that example is at best under-specified.  This is a query against a cache, not the authority.  Today, caches don't work this way.  Also, looking at the definition in 1035, I wonder if a cache should ever return a Name Error.

(Obviously, the goal isn't to declare all known recursive servers wrong, the alternative is to document the deviation from the full standard...and at some point elevate the deviation to full standard too.)

At 9:19 -0400 6/29/10, Josh Littlefield wrote:
>I think the I-D captures the alternatives correctly, and I agree that
>"B" is the best alternative, as well as being consistent with RFC 2308.
>
>-josh
>
>Donald Eastlake wrote:
>> I also agree that B is the best alternative and should be the
>> mandatory behavior.
>>
>> Thanks,
>> Donald
>>
>> On Tue, Jun 22, 2010 at 1:30 PM, George Barwood
>> <george.barwood@blueyonder.co.uk> wrote:
>>  
>>> It's my view that alternative 3.B is correct.
>>>
>>>    When an xNAME chain is followed, all but the last query cycle
>>>    necessarily had no error. The RCODE in the ultimate DNS response MUST
>>>    BE set based on the final query cycle leading to that response. If
>>>    the xNAME chain was terminated by an error, it will be that error
>>>    code. If the xNAME chain terminated without error, it will be zero.
>>>
>>> If the final query cycle gives rise to a NXDOMAIN, then there must be a
>>> NXDOMAIN
>>> NSEC proof in the response, and a validating resolver will check that this
>>> proof is correct.
>>>
>>> It would be bizarre I think for the RCODE not to match the NSEC proof that
>>> is present.
>>>
>>> George
>>>
>>> ----- Original Message -----
>>> From: Donald Eastlake
>>> To: namedroppers@ops.ietf.org
>>> Sent: Tuesday, June 08, 2010 3:27 PM
>>> Subject: Re: [dnsext] CNAME and NXDOMAIN
>>> To help facilitate the resolution of this question I have written a draft,
>>> current version
>>> http://tools.ietf.org/html/draft-eastlake-dnsext-xnamercode-02
>>>
>>>
>>>    
>>
>>  
>
>--
>Josh Littlefield                                  Cisco Systems, Inc.
>joshl@cisco.com                             1414 Massachusetts Avenue
>Phone: +1 978-936-0001                     Boxborough, MA  01719-2205

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

Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.
--============_-929455990==_ma============-- From owner-namedroppers@ops.ietf.org Tue Aug 24 19:02: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 0EB393A693A; Tue, 24 Aug 2010 19:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.51 X-Spam-Level: X-Spam-Status: No, score=-100.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_54=0.6, 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 pWAGdjuufBhp; Tue, 24 Aug 2010 19:02:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C03E3A67FB; Tue, 24 Aug 2010 19:02:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oo5D9-000KPN-SV for namedroppers-data0@psg.com; Wed, 25 Aug 2010 01:55:31 +0000 Received: from [2001:500:60::65] (helo=mx.ams1.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oo5D6-000KOr-JP for namedroppers@ops.ietf.org; Wed, 25 Aug 2010 01:55:29 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 3281F5F9891; Wed, 25 Aug 2010 01:55:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 F1F0DE6030; Wed, 25 Aug 2010 01:55:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 3DE46347E5B; Wed, 25 Aug 2010 11:55:06 +1000 (EST) To: Edward Lewis Cc: namedroppers@ops.ietf.org, Donald Eastlake From: Mark Andrews References: <55156.1274856474@nsa.vix.com> <33BE205400654B708840CBF6E0A3D5D8@local> <4C29F2FE.50302@cisco.com> Subject: Re: [dnsext] draft-eastlake-dnsext-xnamercode-02 was Re: CNAME and NXDOMAIN In-reply-to: Your message of "Tue, 24 Aug 2010 12:10:00 -0400." Date: Wed, 25 Aug 2010 11:55:06 +1000 Message-Id: <20100825015506.3DE46347E5B@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Edward Lewis writes: > --============_-929455990==_ma============ > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > > (http://tools.ietf.org/html/draft-eastlake-dnsext-xnamercode-02) > > Okay, so I am not letting the go easily. > > In RFC 1035, section 4.1.1, the definition of the RCODE=Name Error is > given as this: > > 3 Name Error - Meaningful only for > responses from an authoritative name > server, this code signifies that the > domain name referenced in the query does > not exist. > > "Referenced in the query" is the phrase that piques my interest here. > > In RFC 2308, section 2.1, > > 2.1 - Name Error > > Name errors (NXDOMAIN) are indicated by the presence of "Name Error" > in the RCODE field. In this case the domain referred to by the QNAME > does not exist. Note: the answer section may have SIG and CNAME RRs > and the authority section may have SOA, NXT [RFC2065] and SIG RRsets. > > followed by its TYPE 1 example. > > From comparing these two, I'd say that 2308 is mistaken in the > example. In 1035, an NXDOMAIN referring to the name in the query to > me reads as there would no RR sets matching (no CNAME and nothing to > sign). > > I ran across this again in looking carefully at the AA bit - which is > defined to apply to the queried name only. > > The only appearance of AA in 2308 is in section 10 (titled "Example") > and that example is at best under-specified. This is a query against > a cache, not the authority. Today, caches don't work this way. > Also, looking at the definition in 1035, I wonder if a cache should > ever return a Name Error. The point of RFC 2308 was to allow caches to return name error by providing a mechanism which allowed it to be cached for a prescribed amount of time. The intent was to also make it clear that it applied to the QNAME at the end of a CNAME chain. You couldn't have a pure cache with RFC 1035. You needed a cache/proxy hybrid. > (Obviously, the goal isn't to declare all known recursive servers > wrong, the alternative is to document the deviation from the full > standard...and at some point elevate the deviation to full standard > too.) > -- 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 Aug 25 05:27: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 A5DED3A6ADD; Wed, 25 Aug 2010 05:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.098 X-Spam-Level: X-Spam-Status: No, score=-100.098 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 S64UKNUNi3K7; Wed, 25 Aug 2010 05:27:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A1BAD3A6AC0; Wed, 25 Aug 2010 05:27:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OoEzO-000BId-J4 for namedroppers-data0@psg.com; Wed, 25 Aug 2010 12:21:58 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OoEzM-000BI8-8z for namedroppers@ops.ietf.org; Wed, 25 Aug 2010 12:21:56 +0000 Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7PCLlI1007332; Wed, 25 Aug 2010 08:21:48 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Wed, 25 Aug 2010 08:21:53 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 25 Aug 2010 08:21:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20100825015506.3DE46347E5B@drugs.dv.isc.org> References: <55156.1274856474@nsa.vix.com> <33BE205400654B708840CBF6E0A3D5D8@local> <4C29F2FE.50302@cisco.com> <20100825015506.3DE46347E5B@drugs.dv.isc.org> Date: Wed, 25 Aug 2010 08:17:55 -0400 To: From: Edward Lewis Subject: Re: [dnsext] draft-eastlake-dnsext-xnamercode-02 ... Cc: Edward Lewis 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:55 +1000 8/25/10, Mark Andrews wrote: >The point of RFC 2308 was to allow caches to return name error by >providing a mechanism which allowed it to be cached for a prescribed >amount of time. The intent was to also make it clear that it applied >to the QNAME at the end of a CNAME chain. That should be documented in the Draft Standard/Full Standard revision. (Or we have to deal with the same issues that came up with the alleged "clarify" documents - that they weren't just clarifications, they altered the base in some way.) > >You couldn't have a pure cache with RFC 1035. You needed a cache/proxy >hybrid. I'm curious about that statement. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh. From owner-namedroppers@ops.ietf.org Wed Aug 25 05: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 B21813A698B; Wed, 25 Aug 2010 05:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.493 X-Spam-Level: X-Spam-Status: No, score=-100.493 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, J_CHICKENPOX_23=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 FQj75B-6+B+q; Wed, 25 Aug 2010 05:56:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8608C3A6995; Wed, 25 Aug 2010 05:56:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OoFU0-000Ezd-Cs for namedroppers-data0@psg.com; Wed, 25 Aug 2010 12:53:36 +0000 Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OoFTx-000Ez5-Ko for namedroppers@ops.ietf.org; Wed, 25 Aug 2010 12:53:33 +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 38BD37342DD for ; Wed, 25 Aug 2010 14:53:32 +0200 (CEST) Message-ID: <4C75124B.6080703@nic.cz> Date: Wed, 25 Aug 2010 14:53:31 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] does C+D fail in current resolver? References: <482356091.17828@cnnic.cn> In-Reply-To: <482356091.17828@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 21.8.2010 03:52, Yao Jiankang wrote: > so according to the closed code provided by Paul, > either cname or dname will not be resolved correctly. > if you want to make c+d to work correctly, signaling is a MUST even if > the resolver is non-dnssec resolver. Yes, and I thought we already agreed on that. The draft on signaling is in: draft-sury-dnsext-cname-at-apex-00 It's very rough at the edges, uses incorrect RFCs etc., I'll publish better version soon, but you can get the basic idea. Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- 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 dnsext-archive@lists.ietf.org Wed Aug 25 06:08: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 4A0FC3A6AF5 for ; Wed, 25 Aug 2010 06:08:43 -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 Official ; Wed, 25 Aug 2010 06:08:38 -0700 (PDT) Received: from 136-92-135-95.pool.ukrtel.net (136-92-135-95.pool.ukrtel.net [95.135.92.136]) by core3.amsl.com (Postfix) with ESMTP id 81AE93A69A4 for ; Wed, 25 Aug 2010 06:08:37 -0700 (PDT) From: USA VIAGRA ® Official To: dnsext-archive@lists.ietf.org Subject: dnsext-archive@lists.ietf.org VIAGRA ® Official Seller -85% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100825130837.81AE93A69A4@core3.amsl.com> Date: Wed, 25 Aug 2010 06:08:37 -0700 (PDT)
Click here!

From owner-namedroppers@ops.ietf.org Wed Aug 25 17:58: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 AA2113A68D0; Wed, 25 Aug 2010 17:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.625 X-Spam-Level: X-Spam-Status: No, score=-100.625 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_20=-0.74, 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 dTZYcOkXyhvt; Wed, 25 Aug 2010 17:58:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 96C6E3A68C3; Wed, 25 Aug 2010 17:58:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OoQhB-000OMU-Dr for namedroppers-data0@psg.com; Thu, 26 Aug 2010 00:51:57 +0000 Received: from [2001:500:60::65] (helo=mx.ams1.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OoQh8-000OKe-IX for namedroppers@ops.ietf.org; Thu, 26 Aug 2010 00:51:54 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 7EBFB5F9863; Thu, 26 Aug 2010 00:51:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 5540FE6032; Thu, 26 Aug 2010 00:51:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2C9FC3593DE; Thu, 26 Aug 2010 10:44:35 +1000 (EST) To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <55156.1274856474@nsa.vix.com> <33BE205400654B708840CBF6E0A3D5D8@local> <4C29F2FE.50302@cisco.com> <20100825015506.3DE46347E5B@drugs.dv.isc.org> Subject: Re: [dnsext] draft-eastlake-dnsext-xnamercode-02 ... In-reply-to: Your message of "Wed, 25 Aug 2010 08:17:55 -0400." Date: Thu, 26 Aug 2010 10:44:34 +1000 Message-Id: <20100826004435.2C9FC3593DE@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Edward Lewis writes: > At 11:55 +1000 8/25/10, Mark Andrews wrote: > > >The point of RFC 2308 was to allow caches to return name error by > >providing a mechanism which allowed it to be cached for a prescribed > >amount of time. The intent was to also make it clear that it applied > >to the QNAME at the end of a CNAME chain. > > That should be documented in the Draft Standard/Full Standard revision. > > (Or we have to deal with the same issues that came up with the > alleged "clarify" documents - that they weren't just clarifications, > they altered the base in some way.) RFC 2308's intent was to change things. It was never a clarifying document. Now I may not have done a good job of replace old text with new text. > >You couldn't have a pure cache with RFC 1035. You needed a cache/proxy > >hybrid. > > I'm curious about that statement. Early caches basically checked to see if the answer was in the cache then if it wasn't made the upstream queries and basically passed the answer back to the client just correcting the qid. CNAMEs modified it a little bit as you would copy the records to the end of the partially constructed response. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh. > -- 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 Aug 26 03:49: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 EB68D3A681D; Thu, 26 Aug 2010 03:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.489 X-Spam-Level: * X-Spam-Status: No, score=1.489 tagged_above=-999 required=5 tests=[AWL=0.739, 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 zZZbcxmdrrKi; Thu, 26 Aug 2010 03:49:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE8EC3A6782; Thu, 26 Aug 2010 03:49:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OoZvL-0009PJ-27 for namedroppers-data0@psg.com; Thu, 26 Aug 2010 10:43:11 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OoZvI-0009OY-KN for namedroppers@ops.ietf.org; Thu, 26 Aug 2010 10:43:08 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1OoZv2-000639-G3; Thu, 26 Aug 2010 10:42:52 +0000 Received: by bfk.de with local id 1OoZv2-0007zw-A3; Thu, 26 Aug 2010 10:42:52 +0000 To: Mark Andrews Cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-eastlake-dnsext-xnamercode-02 ... References: <55156.1274856474@nsa.vix.com> <33BE205400654B708840CBF6E0A3D5D8@local> <4C29F2FE.50302@cisco.com> <20100825015506.3DE46347E5B@drugs.dv.isc.org> <20100826004435.2C9FC3593DE@drugs.dv.isc.org> From: Florian Weimer Date: Thu, 26 Aug 2010 10:42:52 +0000 In-Reply-To: <20100826004435.2C9FC3593DE@drugs.dv.isc.org> (Mark Andrews's message of "Thu\, 26 Aug 2010 10\:44\:34 +1000") Message-ID: <82iq2xmz83.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Mark Andrews: > Early caches basically checked to see if the answer was in the cache > then if it wasn't made the upstream queries and basically passed the > answer back to the client just correcting the qid. CNAMEs modified > it a little bit as you would copy the records to the end of the > partially constructed response. Are you saying that early implementations did not try to complete the CNAME chain? I'm sure that this step was not required very often because you didn't throw away untrusted data back then. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Thu Aug 26 07:11: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 9E44F3A67E5; Thu, 26 Aug 2010 07:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.138 X-Spam-Level: X-Spam-Status: No, score=-100.138 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 5cz0Pu--HtnQ; Thu, 26 Aug 2010 07:11:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5DC953A681A; Thu, 26 Aug 2010 07:11:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ood69-0007ZS-FQ for namedroppers-data0@psg.com; Thu, 26 Aug 2010 14:06:33 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ood66-0007Yy-HW for namedroppers@ops.ietf.org; Thu, 26 Aug 2010 14:06:30 +0000 Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7QE6LUB016153; Thu, 26 Aug 2010 10:06:21 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Thu, 26 Aug 2010 10:06:27 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 26 Aug 2010 10:06:27 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20100826004435.2C9FC3593DE@drugs.dv.isc.org> References: <55156.1274856474@nsa.vix.com> <33BE205400654B708840CBF6E0A3D5D8@local> <4C29F2FE.50302@cisco.com> <20100825015506.3DE46347E5B@drugs.dv.isc.org> <20100826004435.2C9FC3593DE@drugs.dv.isc.org> Date: Thu, 26 Aug 2010 10:02:30 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] draft-eastlake-dnsext-xnamercode-02 ... Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 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:44 +1000 8/26/10, Mark Andrews wrote: >RFC 2308's intent was to change things. It was never a clarifying >document. Now I may not have done a good job of replace old text with >new text. Just to be clear about all this. There's no issue with changing things in general. It is just that having not otherwise read any text stating that change was the intent, I assumed that 2308 (and other docuements) was just filling in missing parts of the original specification. I'm picking on 2308 because it has related to some issues, on the list and internal to our development team, recently. Otherwise 2308 is not special, no better and certainly no worse (worthy of criticism), in this regard. I am not saying that 2308 is in any way deficient or anyone didn't do a good job. What I am saying is that we should improve the state of the documents by capturing more of the things left unsaid. New programmers are those who benefit. Sooner or later those of us who wrote these documents are going to stop answering emails about them (for one reason or another) and the text left behind is all that the next generation can rely on. Don't take any "the text needs to be clearer" as a criticism on the effort back in the day but as a comment on how we can improve the legacy for the future. > >> >You couldn't have a pure cache with RFC 1035. You needed a cache/proxy >> >hybrid. >> >> I'm curious about that statement. > >Early caches basically checked to see if the answer was in the cache >then if it wasn't made the upstream queries and basically passed the >answer back to the client just correcting the qid. CNAMEs modified >it a little bit as you would copy the records to the end of the >partially constructed response. Asking for clarification - I understand this is the way older recursive servers with caches worked. I guess I'm mystified by can't "have a pure cache with RFC 1035" and what is called a "cache/proxy hybrid." I know that there are points in STD 13 (1034/1035) that show that no one really thought through servers that were both authoritative and caches - yes, they are mentioned in places but left open issues. In 4.3.2 of 1034, the algorithm there mentions consulting authoritative data and cache lookups, but in other places there are conflicts in the concept (I can't think of a specific now). Do you think 1035 didn't allow for hybirds? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh. From owner-namedroppers@ops.ietf.org Thu Aug 26 07: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 940E23A6989; Thu, 26 Aug 2010 07:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.587 X-Spam-Level: ** X-Spam-Status: No, score=2.587 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, HTML_MESSAGE=0.001, J_CHICKENPOX_54=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 eg2+P7Tc4AOh; Thu, 26 Aug 2010 07:55:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5FA303A697D; Thu, 26 Aug 2010 07:55:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oodnz-000CEP-2Z for namedroppers-data0@psg.com; Thu, 26 Aug 2010 14:51:51 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oodnu-000CCS-0T for namedroppers@ops.ietf.org; Thu, 26 Aug 2010 14:51:48 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o7QEphu0016449 for ; Thu, 26 Aug 2010 10:51:43 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o7QEph6U016448 for namedroppers@ops.ietf.org; Thu, 26 Aug 2010 10:51:43 -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.72 (FreeBSD)) (envelope-from ) id 1OoYjv-0001Lh-7r for namedroppers@ops.ietf.org; Thu, 26 Aug 2010 09:27:19 +0000 Received: from mail-yw0-f52.google.com ([209.85.213.52]) by xs.powerdns.com with esmtpsa (TLS1.0:RSA_ARCFOUR_MD5:16) (Exim 4.69) (envelope-from ) id 1OoYjm-0004nA-LZ for namedroppers@ops.ietf.org; Thu, 26 Aug 2010 11:27:12 +0200 Received: by ywo32 with SMTP id 32so847137ywo.11 for ; Thu, 26 Aug 2010 02:27:04 -0700 (PDT) Received: by 10.151.122.6 with SMTP id z6mr10286819ybm.91.1282814824188; Thu, 26 Aug 2010 02:27:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.27.1 with HTTP; Thu, 26 Aug 2010 02:26:44 -0700 (PDT) In-Reply-To: <20100825015506.3DE46347E5B@drugs.dv.isc.org> References: <55156.1274856474@nsa.vix.com> <33BE205400654B708840CBF6E0A3D5D8@local> <4C29F2FE.50302@cisco.com> <20100825015506.3DE46347E5B@drugs.dv.isc.org> From: bert hubert Date: Thu, 26 Aug 2010 11:26:44 +0200 Message-ID: Subject: Re: [dnsext] draft-eastlake-dnsext-xnamercode-02 was Re: CNAME and NXDOMAIN To: Mark Andrews Cc: Edward Lewis , namedroppers@ops.ietf.org, Donald Eastlake Content-Type: multipart/alternative; boundary=000e0cd5c500e88a64048eb6996a X-Spam_score: -3.9 X-Spam_score_int: -38 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: Perhaps relevant in this context, there are now a number of domains sending out NXDOMAIN CNAMEs, like for example: $ dig +norecurs my.smsfeedback.ru @ns.majordomo.ru ; <<>> DiG 9.6.1-P2 <<>> +norecurs my.smsfeedback.ru @ns.majordomo.ru ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10885 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 [...] Content analysis details: (-3.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.5 AWL AWL: From: address is in the auto white-list X-Scanned-By: MIMEDefang 2.68 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: --000e0cd5c500e88a64048eb6996a Content-Type: text/plain; charset=ISO-8859-1 Perhaps relevant in this context, there are now a number of domains sending out NXDOMAIN CNAMEs, like for example: $ dig +norecurs my.smsfeedback.ru @ns.majordomo.ru ; <<>> DiG 9.6.1-P2 <<>> +norecurs my.smsfeedback.ru @ns.majordomo.ru ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10885 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;my.smsfeedback.ru. IN A ;; ANSWER SECTION: my.smsfeedback.ru. 3600 IN CNAME click.smsbliss.ru. ;; AUTHORITY SECTION: . 3600 IN SOA ns.majordomo.ru. support.majordomo.ru. 2004032900 3600 900 3600000 3600 Users demand that this works, and BIND and Unbound support this. But I'm confused, it says NXDOMAIN, and proceeds to send some data, plus a bogus authority section. What do people think? On Wed, Aug 25, 2010 at 3:55 AM, Mark Andrews wrote: > > In message , Edward Lewis writes: > > --============_-929455990==_ma============ > > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > > > > (http://tools.ietf.org/html/draft-eastlake-dnsext-xnamercode-02) > > > > Okay, so I am not letting the go easily. > > > > In RFC 1035, section 4.1.1, the definition of the RCODE=Name Error is > > given as this: > > > > 3 Name Error - Meaningful only for > > responses from an authoritative name > > server, this code signifies that the > > domain name referenced in the query does > > not exist. > > > > "Referenced in the query" is the phrase that piques my interest here. > > > > In RFC 2308, section 2.1, > > > > 2.1 - Name Error > > > > Name errors (NXDOMAIN) are indicated by the presence of "Name Error" > > in the RCODE field. In this case the domain referred to by the QNAME > > does not exist. Note: the answer section may have SIG and CNAME RRs > > and the authority section may have SOA, NXT [RFC2065] and SIG RRsets. > > > > followed by its TYPE 1 example. > > > > From comparing these two, I'd say that 2308 is mistaken in the > > example. In 1035, an NXDOMAIN referring to the name in the query to > > me reads as there would no RR sets matching (no CNAME and nothing to > > sign). > > > > I ran across this again in looking carefully at the AA bit - which is > > defined to apply to the queried name only. > > > > The only appearance of AA in 2308 is in section 10 (titled "Example") > > and that example is at best under-specified. This is a query against > > a cache, not the authority. Today, caches don't work this way. > > Also, looking at the definition in 1035, I wonder if a cache should > > ever return a Name Error. > > The point of RFC 2308 was to allow caches to return name error by > providing a mechanism which allowed it to be cached for a prescribed > amount of time. The intent was to also make it clear that it applied > to the QNAME at the end of a CNAME chain. > > You couldn't have a pure cache with RFC 1035. You needed a cache/proxy > hybrid. > > > (Obviously, the goal isn't to declare all known recursive servers > > wrong, the alternative is to document the deviation from the full > > standard...and at some point elevate the deviation to full standard > > too.) > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > --000e0cd5c500e88a64048eb6996a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perhaps relevant in this context, there are now a number of domains sending= out NXDOMAIN CNAMEs, like for example:

; <<>> DiG 9.6.1-P2 <<>> +norec= urs my.smsfeedback.ru @ns.majordomo.ru
;; ->>HEADER<= ;<- opcode: QUERY, status: NXDOMAIN, id: 10885
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;my.smsfeedback.ru. =A0 =A0 =A0 =A0 =A0 =A0 IN =A0 =A0 = =A0A

;; ANSWER SECTION:
my.smsfeedback.ru. =A0 =A0 =A03600 =A0 =A0IN =A0 =A0 =A0CNAME =A0 click.smsbliss.ru.

;; AUTHORITY SECTION:
. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3600 =A0 =A0IN =A0 =A0 = =A0SOA =A0 =A0 ns.majordomo.ru. support.majordomo.ru. 2004032900 36= 00 900 3600000 3600

Users demand that this works, and BIND and Unbound support this. But I= 'm confused, it says NXDOMAIN, and proceeds to send some data, plus a b= ogus authority section.

What do people think?
On Wed, Aug 25, 2010 at 3:55 AM, Mark Andrew= s <marka@isc.org&= gt; wrote:

In message <a06240800c89996ea6d2c@[192.168.129.32]>, Edward Lewis wri= tes:
> --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D_-929455990=3D=3D_ma=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
> Content-Type: text/plain; charset=3D"us-ascii" ; format=3D&q= uot;flowed"
>
> (http://tools.ietf.org/html/draft-eastlake-dnsext-xn= amercode-02)
>
> Okay, so I am not letting the go easily.
>
> In RFC 1035, section 4.1.1, the definition of the RCODE=3DName Error i= s
> given as this:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A03 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Name = Error - Meaningful only for
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0res= ponses from an authoritative name
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ser= ver, this code signifies that the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dom= ain name referenced in the query does
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0not= exist.
>
> "Referenced in the query" is the phrase that piques my inter= est here.
>
> In RFC 2308, section 2.1,
>
> 2.1 - Name Error
>
> =A0 =A0 Name errors (NXDOMAIN) are indicated by the presence of "= Name Error"
> =A0 =A0 in the RCODE field. =A0In this case the domain referred to by = the QNAME
> =A0 =A0 does not exist. =A0Note: the answer section may have SIG and C= NAME RRs
> =A0 =A0 and the authority section may have SOA, NXT [RFC2065] and SIG = RRsets.
>
> followed by its TYPE 1 example.
>
> =A0From comparing these two, I'd say that 2308 is mistaken in the<= br> > example. =A0In 1035, an NXDOMAIN referring to the name in the query to=
> me reads as there would no RR sets matching (no CNAME and nothing to > sign).
>
> I ran across this again in looking carefully at the AA bit - which is<= br> > defined to apply to the queried name only.
>
> The only appearance of AA in 2308 is in section 10 (titled "Examp= le")
> and that example is at best under-specified. =A0This is a query agains= t
> a cache, not the authority. =A0Today, caches don't work this way.<= br> > Also, looking at the definition in 1035, I wonder if a cache should > ever return a Name Error.

The point of RFC 2308 was to allow caches to = return name error by
providing a mechanism which allowed it to be cached for a prescribed
amount of time. =A0The intent was to also make it clear that it applied
to the QNAME at the end of a CNAME chain.

You couldn't have a pure cache with RFC 1035. = =A0You needed a cache/proxy
hybrid.

> (Obviously, the goal isn't to declare all = known recursive servers
> wrong, the alternative is to document the deviation from the full
> standard...and at some point elevate the deviation to full standard > too.)
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org


--000e0cd5c500e88a64048eb6996a-- From owner-namedroppers@ops.ietf.org Thu Aug 26 17: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 7FF673A6A64; Thu, 26 Aug 2010 17:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.612 X-Spam-Level: X-Spam-Status: No, score=-101.612 tagged_above=-999 required=5 tests=[AWL=0.987, 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 w0SGqzT9MyP7; Thu, 26 Aug 2010 17:11:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D20C33A6A35; Thu, 26 Aug 2010 17:11:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OomQp-000MK1-40 for namedroppers-data0@psg.com; Fri, 27 Aug 2010 00:04:31 +0000 Received: from [2001:4f8:0:2::2b] (helo=mx.pao1.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OomQl-000MJn-7M for namedroppers@ops.ietf.org; Fri, 27 Aug 2010 00:04:27 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id DB15CC9421; Fri, 27 Aug 2010 00:04:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 3C776E60D8; Fri, 27 Aug 2010 00:04:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4C011361B11; Fri, 27 Aug 2010 10:03:59 +1000 (EST) To: bert hubert Cc: Edward Lewis , namedroppers@ops.ietf.org, Donald Eastlake From: Mark Andrews References: <55156.1274856474@nsa.vix.com> <33BE205400654B708840CBF6E0A3D5D8@local> <4C29F2FE.50302@cisco.com> <20100825015506.3DE46347E5B@drugs.dv.isc.org> Subject: Re: [dnsext] draft-eastlake-dnsext-xnamercode-02 was Re: CNAME and NXDOMAIN In-reply-to: Your message of "Thu, 26 Aug 2010 11:26:44 +0200." Date: Fri, 27 Aug 2010 10:03:58 +1000 Message-Id: <20100827000359.4C011361B11@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , bert hubert writes: > > Perhaps relevant in this context, there are now a number of domains sending > out NXDOMAIN CNAMEs, like for example: > $ dig +norecurs my.smsfeedback.ru @ns.majordomo.ru > > ; <<>> DiG 9.6.1-P2 <<>> +norecurs my.smsfeedback.ru @ns.majordomo.ru > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10885 > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;my.smsfeedback.ru. IN A > > ;; ANSWER SECTION: > my.smsfeedback.ru. 3600 IN CNAME click.smsbliss.ru. > > ;; AUTHORITY SECTION: > . 3600 IN SOA ns.majordomo.ru. > support.majordomo.ru. 2004032900 3600 900 3600000 3600 > > Users demand that this works, and BIND and Unbound support this. But I'm > confused, it says NXDOMAIN, and proceeds to send some data, plus a bogus > authority section. > > What do people think? I think ns.majordomo.ru is mis-configured and is accidentally leaking answers from internal namespace (the private version of the root zone). The NXDOMAIN just indicates that the name or the name it is a alias for does not exist. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From lizzyumary@katamail.com Thu Aug 26 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 A291F3A6964 for ; Thu, 26 Aug 2010 17:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.338 X-Spam-Level: **** X-Spam-Status: No, score=4.338 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WL5D+Ik+A-Li for ; Thu, 26 Aug 2010 17:39:18 -0700 (PDT) Received: from smtp1-pc.aruba.it (smtp183-pc.aruba.it [62.149.157.183]) by core3.amsl.com (Postfix) with SMTP id 1289D3A68A7 for ; Thu, 26 Aug 2010 17:39:17 -0700 (PDT) Received: (qmail 9965 invoked by uid 89); 27 Aug 2010 00:38:42 -0000 Received: from unknown (HELO localhost) (10.10.176.108) by smtp1-pc.ad.aruba.it with SMTP; 27 Aug 2010 00:38:42 -0000 MIME-Version: 1.0 X-Mailer: AtMail PHP 5.1 Message-ID: <2477.1282869522@katamail.com> To: Reply-To: elizabeth_umar@hotmail.com Content-Type: text/html; charset="utf-8" X-Origin: 218.29.234.50 Date: Fri, 27 Aug 2010 02:38:42 +0200 Subject: Please get back to me as soon as possible. From: lizzyumary@katamail.com Content-Transfer-Encoding: quoted-printable
Good day to you.

I am Lizzy Umar.
I have something
important to share=20
with you. Please
get back.

Thanks.
Nuova grafica e nuove funzionalit=C3=A0! Crea subito Gratis= la tua nuova Casella di Posta Katamail From lizzyumary@katamail.com Thu Aug 26 17:50: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 CDE133A6AA0 for ; Thu, 26 Aug 2010 17:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.338 X-Spam-Level: **** X-Spam-Status: No, score=4.338 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OS5dX3OrDDCU for ; Thu, 26 Aug 2010 17:50:53 -0700 (PDT) Received: from smtp1-pc.aruba.it (smtp184-pc.aruba.it [62.149.157.184]) by core3.amsl.com (Postfix) with SMTP id EC9523A6837 for ; Thu, 26 Aug 2010 17:50:51 -0700 (PDT) Received: (qmail 10585 invoked by uid 89); 27 Aug 2010 00:51:14 -0000 Received: from unknown (HELO localhost) (10.10.176.108) by smtp1-pc.ad.aruba.it with SMTP; 27 Aug 2010 00:51:14 -0000 MIME-Version: 1.0 X-Mailer: AtMail PHP 5.1 Message-ID: <1117.1282870274@katamail.com> To: Reply-To: elizabeth_umar@hotmail.com Content-Type: text/html; charset="utf-8" X-Origin: 218.29.234.50 Date: Fri, 27 Aug 2010 02:51:13 +0200 Subject: Please get back to me as soon as possible. From: lizzyumary@katamail.com Content-Transfer-Encoding: quoted-printable
Good day to you.

I am Lizzy Umar.
I have something
important to share=20
with you. Please
get back.

Thanks.
Nuova grafica e nuove funzionalit=C3=A0! Crea subito Gratis= la tua nuova Casella di Posta Katamail From owner-namedroppers@ops.ietf.org Thu Aug 26 19:56: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 90A8B3A6AE7; Thu, 26 Aug 2010 19:56:58 -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 ZXwlzlbWgXox; Thu, 26 Aug 2010 19:56:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 108773A68D0; Thu, 26 Aug 2010 19:56:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oop2s-00040U-Pg for namedroppers-data0@psg.com; Fri, 27 Aug 2010 02:51:58 +0000 Received: from [2001:4f8:fff7:1::5] (helo=mail1.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oop2q-0003zz-AJ for namedroppers@ops.ietf.org; Fri, 27 Aug 2010 02:51:56 +0000 Received: from cust-63-209-227-45.bos-dynamic.gis.net ([63.209.227.45] helo=[10.10.10.101]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Oop2W-0005CF-HO; Fri, 27 Aug 2010 02:51:47 +0000 Message-ID: <4C772836.7010105@gis.net> Date: Thu, 26 Aug 2010 22:51:34 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alex Bligh CC: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Paul Vixie , namedroppers@ops.ietf.org References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <18374.1281714027@nsa.vix.com> <4C6FD98E.2020502@ntp.org> <3EFF9C9D-DBEA-4498-B727-B003812C6602@cisco.com> <4C72CEF9.9080301@gis.net> <01A3703B1DD6AC4BD168DF06@Ximines.local> <4C72E186.7010901@gis.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 63.209.227.45 X-SA-Exim-Rcpt-To: alex@alex.org.uk, paf@cisco.com, vixie@isc.org, namedroppers@ops.ietf.org X-SA-Exim-Mail-From: mayer@ntp.org Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 8/23/2010 5:38 PM, Alex Bligh wrote: > > > --On 23 August 2010 17:00:54 -0400 Danny Mayer wrote: > >> The same way that you configure any SMTP server. It has to know what it >> will accept. There's no magic involved. The mail servers that I've >> configured always expect me to tell it. Besides that's out of scope for >> this WG. > > I thought this was a reply to John Levine's thread on predictive vs. > reactive name aliasing. He was in essence making the point reactive > name aliasing doesn't work. That means you have to be able to configure > names in advance. Firstly, there may be a large number combinatorially. > Secondly, the available aliases may change over time and the rules > may not be immediately apparent to the mail system owner (e.g. TLDs > changing their rules). Thirdly, if the application layer needs to > be preconfigured, that makes automatic XNAME stuff less useful. I don't > see the point in doing a lot of work at the DNS layer without > considering the problems it generates at the application layer. > Is asking whether work is actually useful or counterproductive to > the application layer really out of scope? > This sounds like you are suggesting that if a mail server is set up for domain X and it has a shadow zone or a xDNAME copy to a Y domain then it should automatically be able to configure itself based on the DNS records with both X *and* Y. That requires enumerating all of the "equivalent" domains which would argue more in favor of something like Paul's shadow zone proposal since those records would have to exist in the zone. Danny From ibiomazi1366@comcast.net Thu Aug 26 22:08: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 5EC713A6B3A for ; Thu, 26 Aug 2010 22:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.741 X-Spam-Level: X-Spam-Status: No, score=-65.741 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 xWIyGFWwrk-u for ; Thu, 26 Aug 2010 22:08:25 -0700 (PDT) Received: from comcast.net (c-68-56-70-87.hsd1.fl.comcast.net [68.56.70.87]) by core3.amsl.com (Postfix) with ESMTP id 650953A67AB for ; Thu, 26 Aug 2010 22:08:25 -0700 (PDT) From: To: dnsext-archive@ietf.org Date: Fri, 27 Aug 2010 01:09:00 -0400 Subject: Dating 101 made easy with large tool Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100827050825.650953A67AB@core3.amsl.com> A special remedy to remember, a mind blowing experience for both of you. http://www.pangain.ru/ From owner-namedroppers@ops.ietf.org Fri Aug 27 08:39: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 3F55C3A69DC; Fri, 27 Aug 2010 08:39:24 -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.504, 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 OqoDYX8NKTbn; Fri, 27 Aug 2010 08:39:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD56C3A6A74; Fri, 27 Aug 2010 08:38:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Op0vq-00027t-Sl for namedroppers-data0@psg.com; Fri, 27 Aug 2010 15:33:30 +0000 Received: from [209.85.214.180] (helo=mail-iw0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Op0vn-00027Z-NO for namedroppers@ops.ietf.org; Fri, 27 Aug 2010 15:33:28 +0000 Received: by iwn6 with SMTP id 6so3808939iwn.11 for ; Fri, 27 Aug 2010 08:33:27 -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; bh=Qg0t2saDgRK238fKGWmG21SQrogIjXKv6FkyLtOcFIc=; b=girtWi2wxxnQVfALfjUOX1hBU1wuRcUaF9qCUQqQdPqMWjR5XiR5bHyLF2WCc3dDsz 1//Hbxgi3j2DhvHUtkItVtpi17EXSluaiydvewcviwP/oL9z+d1Fu6pjFzyVJnLiQgRS rJ9qcMz1ZCW4sGjH0k0sYdQnrAy7Ccg+qW9Dw= 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=sfoFS2PQfgEI+Sgq/bUXRbIPqgJbu1M0Sml+0BaafMeGHgQ0F9ZaiIqWL9g6V/4gEM T7cgsydW1OaFMpuh9fRV+dmNs/pADpu961jp0qSgGVBwN03WpzCq+PJ4oAy79/TTpY4H TqqEr2hEY3DmqV0I1GkXg86ih9yitIfgUcDrQ= MIME-Version: 1.0 Received: by 10.231.130.145 with SMTP id t17mr1245943ibs.144.1282923206827; Fri, 27 Aug 2010 08:33:26 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Fri, 27 Aug 2010 08:33:26 -0700 (PDT) In-Reply-To: <4C772836.7010105@gis.net> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <18374.1281714027@nsa.vix.com> <4C6FD98E.2020502@ntp.org> <3EFF9C9D-DBEA-4498-B727-B003812C6602@cisco.com> <4C72CEF9.9080301@gis.net> <01A3703B1DD6AC4BD168DF06@Ximines.local> <4C72E186.7010901@gis.net> <4C772836.7010105@gis.net> Date: Fri, 27 Aug 2010 11:33:26 -0400 Message-ID: Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" From: Phillip Hallam-Baker To: mayer@gis.net Cc: Alex Bligh , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Paul Vixie , 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: Exactly, and this is precisely the reason that I do not consider magic pointer approaches to have any value. It is impossible to make existing applications work without them being aware that the names they are using are being aliased. So if there is magic fixup in the core of the DNS it will break legacy application servers for sure. Proposals that only work after every server in the world has upgraded almost always fail. In this case I think that there is a negligible chance that any work done here is going to have the industry support needed to achieve deployment because I do not believe it is possible to arrive at an implementable statement of what new servers should do. The reason for rejecting client side fixup appeared to be that deployment would take too long. What I would expect to happen with magic fixup is that once implemented it would break servers in random and unexpected ways. While some people think this would be a driver for deployment, I think it rather more likely that people would simply start filtering out the magic fixup pointers from their recursive DNS. This will lead ISPs to block these records and redirect the user to a landing page from where they can attempt to access the site. We can all see where that leads. If a provisioning or client side fixup is too slow for people a fixup that breaks noncompliant servers is going to be worse. 2010/8/26 Danny Mayer : > On 8/23/2010 5:38 PM, Alex Bligh wrote: >> >> >> --On 23 August 2010 17:00:54 -0400 Danny Mayer wrote: >> >>> The same way that you configure any SMTP server. It has to know what it >>> will accept. There's no magic involved. The mail servers that I've >>> configured always expect me to tell it. Besides that's out of scope for >>> this WG. >> >> I thought this was a reply to John Levine's thread on predictive vs. >> reactive name aliasing. He was in essence making the point reactive >> name aliasing doesn't work. That means you have to be able to configure >> names in advance. Firstly, there may be a large number combinatorially. >> Secondly, the available aliases may change over time and the rules >> may not be immediately apparent to the mail system owner (e.g. TLDs >> changing their rules). Thirdly, if the application layer needs to >> be preconfigured, that makes automatic XNAME stuff less useful. I don't >> see the point in doing a lot of work at the DNS layer without >> considering the problems it generates at the application layer. >> Is asking whether work is actually useful or counterproductive to >> the application layer really out of scope? >> > > This sounds like you are suggesting that if a mail server is set up for > domain X and it has a shadow zone or a xDNAME copy to a Y domain then it > should automatically be able to configure itself based on the DNS > records with both X *and* Y. That requires enumerating all of the > "equivalent" domains which would argue more in favor of something like > Paul's shadow zone proposal since those records would have to exist in > the zone. > > Danny > > -- Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Fri Aug 27 09:53: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 800EB3A6985; Fri, 27 Aug 2010 09:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 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 F-z3ICJDyDfC; Fri, 27 Aug 2010 09:53:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 918103A6843; Fri, 27 Aug 2010 09:53:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Op27M-000BDM-Pi for namedroppers-data0@psg.com; Fri, 27 Aug 2010 16:49:28 +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.72 (FreeBSD)) (envelope-from ) id 1Op27I-000BD2-GN for namedroppers@ops.ietf.org; Fri, 27 Aug 2010 16:49:24 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C672FA1051; Fri, 27 Aug 2010 16:49:22 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: mayer@gis.net cc: Alex Bligh , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" In-Reply-To: Your message of "Thu, 26 Aug 2010 22:51:34 -0400." <4C772836.7010105@gis.net> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <18374.1281714027@nsa.vix.com> <4C6FD98E.2020502@ntp.org> <3EFF9C9D-DBEA-4498-B727-B003812C6602@cisco.com> <4C72CEF9.9080301@gis.net> <01A3703B1DD6AC4BD168DF06@Ximines.local> <4C72E186.7010901@gis.net> <4C772836.7010105@gis.net> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Fri, 27 Aug 2010 16:49:22 +0000 Message-ID: <83105.1282927762@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, 26 Aug 2010 22:51:34 -0400 > From: Danny Mayer > > This sounds like you are suggesting that if a mail server is set up for > domain X and it has a shadow zone or a xDNAME copy to a Y domain then it > should automatically be able to configure itself based on the DNS records > with both X *and* Y. That requires enumerating all of the "equivalent" > domains which would argue more in favor of something like Paul's shadow > zone proposal since those records would have to exist in the zone. and indeed, the need for an API function like this informed the SHADOW design. From owner-namedroppers@ops.ietf.org Fri Aug 27 10:01: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 F29713A6985; Fri, 27 Aug 2010 10:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.066 X-Spam-Level: X-Spam-Status: No, score=0.066 tagged_above=-999 required=5 tests=[AWL=0.561, 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 9UrSLVAy-PON; Fri, 27 Aug 2010 10:01:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC1DD3A6843; Fri, 27 Aug 2010 10:01:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Op2GK-000CSN-CC for namedroppers-data0@psg.com; Fri, 27 Aug 2010 16:58:44 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Op2GH-000CS4-S2 for namedroppers@ops.ietf.org; Fri, 27 Aug 2010 16:58:42 +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 9CDCBC56956; Fri, 27 Aug 2010 17:58:38 +0100 (BST) Date: Fri, 27 Aug 2010 17:58:38 +0100 From: Alex Bligh Reply-To: Alex Bligh To: mayer@gis.net cc: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , Paul Vixie , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" Message-ID: In-Reply-To: <4C772836.7010105@gis.net> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <18374.1281714027@nsa.vix.com> <4C6FD98E.2020502@ntp.org> <3EFF9C9D-DBEA-4498-B727-B003812C6602@cisco.com> <4C72CEF9.9080301@gis.net> <01A3703B1DD6AC4BD168DF06@Ximines.local> <4C72E186.7010901@gis.net> <4C772836.7010105@gis.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 26 August 2010 22:51:34 -0400 Danny Mayer wrote: > This sounds like you are suggesting that if a mail server is set up for > domain X and it has a shadow zone or a xDNAME copy to a Y domain then it > should automatically be able to configure itself based on the DNS > records with both X *and* Y. That requires enumerating all of the > "equivalent" domains which would argue more in favor of something like > Paul's shadow zone proposal since those records would have to exist in > the zone. I think shadow is worth investigating further. I'm not yet convinced that the best answer isn't "do nothing", though. -- Alex Bligh From owner-namedroppers@ops.ietf.org Fri Aug 27 12: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 CDEB83A6AC4; Fri, 27 Aug 2010 12:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=-0.626, 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 IFEpc7YaIZas; Fri, 27 Aug 2010 12:11:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A6CA3A6ABE; Fri, 27 Aug 2010 12:11:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Op4GP-0001eV-RA for namedroppers-data0@psg.com; Fri, 27 Aug 2010 19:06:57 +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.72 (FreeBSD)) (envelope-from ) id 1Op4GN-0001eG-Oa for namedroppers@ops.ietf.org; Fri, 27 Aug 2010 19:06:55 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 73523A101E for ; Fri, 27 Aug 2010 19:06:55 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: [dnsext] error in RFC 5782 X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Fri, 27 Aug 2010 19:06:55 +0000 Message-ID: <91192.1282936015@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: i had no idea this existed until somebody mentioned it to me today. it says: Many network managers wanted to use the RBL to block unwanted e-mail, but weren't prepared to use a BGP feed. Rand and Vixie created a DNS-based distribution scheme that quickly became more popular than the original BGP distribution. ... this is wrong. rand and vixie were executives, not technologists, at MAPS. the person who created a DNS-based distribution scheme for the MAPS RBL was eric ziegast, who was employed at that time as a sysadmin for vixie enterprises where the MAPS RBL was at that time being hosted. eric wanted to get the BGP feed out of his routers since it was hurting him, and he knew enough about Sendmail to make it all work using a simple DNS technique. the role of vixie and rand was just to say, well if that works, let's offer it to other subscribers also. if there was a patent on the technique we used, it would be in ziegast't name. the fact that he was directly employed by vixie (and indirectly by rand) does not make rand or vixie an inventor of this technique. i would very much like all public records to correctly give credit only where it is due. john, please add this to the errata for RFC 5782 when you get a chance. i have given the full story during many public appearances over the years, but ultimately it will be documents that inform historians, not my appearances. i have also corrected . if anyone is aware or becomes aware of some other document that gets these historical details wrong, then please correct them yourself or bring them to my attention. i would *never* have thought of the DNSBL idea in this form, as it relied on features in Sendmail that were much newer than i'd written about with Fred Avolio in "Sendmail: Theory and Practice." From paryejo7442@comcast.net Sat Aug 28 03:11: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 8FD723A6853 for ; Sat, 28 Aug 2010 03:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.36 X-Spam-Level: X-Spam-Status: No, score=-6.36 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, 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, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edx2b6GK4wZ6 for ; Sat, 28 Aug 2010 03:11:34 -0700 (PDT) Received: from comcast.net (c-71-61-92-181.hsd1.pa.comcast.net [71.61.92.181]) by core3.amsl.com (Postfix) with ESMTP id B08843A684B for ; Sat, 28 Aug 2010 03:11:29 -0700 (PDT) Date: Sat, 28 Aug 2010 06:11:33 -0400 To: dnsext-archive@ietf.org From: Reply-To: Subject: Get the most out of your package MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20100828101129.B08843A684B@core3.amsl.com> Women will go crazy at the sight of your huge new member http://www.tastygrape.ru/ In July 2005, Glasgow side Rangers F. Even though Argentina is considered to be a predominantly white country, recent genetic studies have shown that Argentines do have a degree on non-White admixture, mainly due to miscegenation in the Spanish colonial era between the fifteenth- and seventeenth-centuries. Later when Ley fled Germany because he was a Jew, Von Braun took over the leadership and changed its activity to military development. Knowing Teaching and Learning History, National and International Perspectives. Pirates were and still are the only Southern Hemisphere club to have won the African Champions League. Conflict seems to have broken out between the towns of Sybaris and Croton. Northern Ireland accounts for just 14,160square kilometres (5,470 sqmi) and is mostly hilly. Most of this sentence is in the present tense because the process is still ongoing. With half-filled legion XX defeated the Pannonii led by Bato I (Bato the Daesitiate) and prevented spread of the uprising. Greenwich Mean Time (GMT) was established in 1675 when the Royal Observatory was built as an aid to (English) mariners to determine longitude at sea. Largest concentration of 19th-century rowhouses in city. The Whitney government initiated massive public works projects such as the creation of Ontario Hydro. During one expedition, 10th Cavalry and 4th Cavalry forces under First Lieutenant James W. From owner-namedroppers@ops.ietf.org Sat Aug 28 09:56: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 95CE93A6809; Sat, 28 Aug 2010 09:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=-0.509, 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 8VZ9z1nx-vnl; Sat, 28 Aug 2010 09:56:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 452EB3A692D; Sat, 28 Aug 2010 09:56:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OpObQ-0007Tt-Pj for namedroppers-data0@psg.com; Sat, 28 Aug 2010 16:50:00 +0000 Received: from [209.85.214.180] (helo=mail-iw0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OpObO-0007TT-7y for namedroppers@ops.ietf.org; Sat, 28 Aug 2010 16:49:58 +0000 Received: by iwn6 with SMTP id 6so5028726iwn.11 for ; Sat, 28 Aug 2010 09:49:56 -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; bh=5zfIFJqvOInBONnFvvJBIr72r2Bs7AtRafoiRxhspOE=; b=WqyvMIiKQcM3BohELrifMj4SDprwLbmbbWH3h8q00X2u1Ke/6oSG7QFdSq9iUAHFhB IJZR0zv2A5bccsWly9hlnDT0KG8Fo15bJiTG3TkVyjm5DttEfNRTpy4dKsGrI8e6MeCx sWnEaJxXuBNqKOwtsyKp6KPXQjZ+1XcdCO+BI= 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=e5qtnM0Bq1ElWyP2/QRM7a+htheEy/TFwBHGS+I9toozKqY44By/i3b1NaudmnSGTM jXFMW2HMCyR1reK45suj+ahiWTU4k+ZTHEMzughWd32GFCSO5mucFb+hKcVAZbK2tTGC enGLaR/UcLUV337tbwSrZYwJ2eNixzDIt+AEQ= MIME-Version: 1.0 Received: by 10.231.161.16 with SMTP id p16mr2821813ibx.61.1283014196079; Sat, 28 Aug 2010 09:49:56 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Sat, 28 Aug 2010 09:49:56 -0700 (PDT) In-Reply-To: References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <18374.1281714027@nsa.vix.com> <4C6FD98E.2020502@ntp.org> <3EFF9C9D-DBEA-4498-B727-B003812C6602@cisco.com> <4C72CEF9.9080301@gis.net> <01A3703B1DD6AC4BD168DF06@Ximines.local> <4C72E186.7010901@gis.net> <4C772836.7010105@gis.net> Date: Sat, 28 Aug 2010 12:49:56 -0400 Message-ID: Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" From: Phillip Hallam-Baker To: Alex Bligh Cc: mayer@gis.net, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Paul Vixie , 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: There are three choices: 1) Attempt to meet a set of requirements that appear to be inconsistent 2) Meet a reduced set of requirements we know that we can meet but fall short of the need 3) Do nothing I proposed the Did You Mean (DYM) record because that is a lower bound for what we might achieve. We can definitely describe and implement a DYM record and make it work. It does not meet the full set of requirements that people think that they want but I don't consider them to be satisfiable. The Internet is very large and very complex. It is not possible to make major changes to the core infrastructure and have them work overnight. It takes a minimum of about ten years for certain types of changes to work through. We seem to end up with a situation where the people who are realistic about deployment constraints get shoved aside by the people who insist that change must come faster. So instead we end up with proposals from people who think that wishes are ponies and RFCs are deployments. And ten or so years later we are still at the starting line. 2010/8/27 Alex Bligh : > > > --On 26 August 2010 22:51:34 -0400 Danny Mayer wrote: > >> This sounds like you are suggesting that if a mail server is set up for >> domain X and it has a shadow zone or a xDNAME copy to a Y domain then it >> should automatically be able to configure itself based on the DNS >> records with both X *and* Y. That requires enumerating all of the >> "equivalent" domains which would argue more in favor of something like >> Paul's shadow zone proposal since those records would have to exist in >> the zone. > > I think shadow is worth investigating further. I'm not yet convinced > that the best answer isn't "do nothing", though. > > -- > Alex Bligh > > -- Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Sat Aug 28 12:21: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 B0AF23A693E; Sat, 28 Aug 2010 12:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 gejlcXHnHLXm; Sat, 28 Aug 2010 12:21:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 771BA3A693B; Sat, 28 Aug 2010 12:21:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OpQtL-000L1c-RE for namedroppers-data0@psg.com; Sat, 28 Aug 2010 19:16:39 +0000 Received: from [2001:4f8:fff7:1::5] (helo=mail1.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OpQtJ-000L1S-QP for namedroppers@ops.ietf.org; Sat, 28 Aug 2010 19:16:37 +0000 Received: from [198.22.153.6] (helo=[10.60.100.45]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OpQsx-000MPd-6i; Sat, 28 Aug 2010 19:16:25 +0000 Message-ID: <4C79607B.6020503@gis.net> Date: Sat, 28 Aug 2010 15:16:11 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alex Bligh CC: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Paul Vixie , namedroppers@ops.ietf.org References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <18374.1281714027@nsa.vix.com> <4C6FD98E.2020502@ntp.org> <3EFF9C9D-DBEA-4498-B727-B003812C6602@cisco.com> <4C72CEF9.9080301@gis.net> <01A3703B1DD6AC4BD168DF06@Ximines.local> <4C72E186.7010901@gis.net> <4C772836.7010105@gis.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 198.22.153.6 X-SA-Exim-Rcpt-To: alex@alex.org.uk, paf@cisco.com, vixie@isc.org, namedroppers@ops.ietf.org X-SA-Exim-Mail-From: mayer@ntp.org Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 8/27/2010 12:58 PM, Alex Bligh wrote: > > > --On 26 August 2010 22:51:34 -0400 Danny Mayer wrote: > >> This sounds like you are suggesting that if a mail server is set up for >> domain X and it has a shadow zone or a xDNAME copy to a Y domain then it >> should automatically be able to configure itself based on the DNS >> records with both X *and* Y. That requires enumerating all of the >> "equivalent" domains which would argue more in favor of something like >> Paul's shadow zone proposal since those records would have to exist in >> the zone. > > I think shadow is worth investigating further. I'm not yet convinced > that the best answer isn't "do nothing", though. +1 From dnsext-archive@ietf.org Sat Aug 28 19:40: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 976953A6922 for ; Sat, 28 Aug 2010 19:40:42 -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): Subject: ...-archive@ietf.org V|AGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -4.724 X-Spam-Level: X-Spam-Status: No, score=-4.724 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.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, FUZZY_VPILL=0.687, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, J_CHICKENPOX_14=0.6, MANGLED_VIAGRA=2.5, 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, RDNS_DYNAMIC=0.1, SARE_OBFU_VIAGRA=1.666, SUBJECT_NEEDS_ENCODING=0.001, TT_OBSCURED_VIAGRA=1.652, TVD_RCVD_IP=1.931, 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 mYVuiv9N0jSS for ; Sat, 28 Aug 2010 19:40:41 -0700 (PDT) Received: from 200-96-165-144.bsace706.dsl.brasiltelecom.net.br (200-96-165-144.bsace706.dsl.brasiltelecom.net.br [200.96.165.144]) by core3.amsl.com (Postfix) with SMTP id 26CD83A68F8 for ; Sat, 28 Aug 2010 19:40:39 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org V|AGRA ® Official Seller -09% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100829024040.26CD83A68F8@core3.amsl.com> Date: Sat, 28 Aug 2010 19:40:39 -0700 (PDT)
Click here!

From owner-namedroppers@ops.ietf.org Sun Aug 29 19:36: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 BC1583A68E4; Sun, 29 Aug 2010 19:36:28 -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: -97.871 X-Spam-Level: X-Spam-Status: No, score=-97.871 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_40=-0.185, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 vbqxnEbONmgq; Sun, 29 Aug 2010 19:36:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 816753A659B; Sun, 29 Aug 2010 19:36:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Opu8P-000BdA-J6 for namedroppers-data0@psg.com; Mon, 30 Aug 2010 02:30:09 +0000 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Opu8I-000BYq-2q for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 02:30:02 +0000 Received: (eyou send program); Mon, 30 Aug 2010 10:29:59 +0800 Message-ID: <483135399.29271@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, 30 Aug 2010 10:29:59 +0800 Message-ID: From: "Jiankang YAO" To: "Phillip Hallam-Baker" , "Alex Bligh" Cc: , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Paul Vixie" , References: <20100810133649.GC52191@shinkuro.com><4C650D10.8070809@nic.cz><18374.1281714027@nsa.vix.com><4C6FD98E.2020502@ntp.org><3EFF9C9D-DBEA-4498-B727-B003812C6602@cisco.com><4C72CEF9.9080301@gis.net><01A3703B1DD6AC4BD168DF06@Ximines.local><4C72E186.7010901@gis.net><4C772836.7010105@gis.net> Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" Date: Mon, 30 Aug 2010 10:30:04 +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.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBoaWxsaXAgSGFsbGFtLUJh a2VyIiA8aGFsbGFtQGdtYWlsLmNvbT4NClRvOiAiQWxleCBCbGlnaCIgPGFsZXhAYWxleC5vcmcu dWs+DQpDYzogPG1heWVyQGdpcy5uZXQ+OyAiUGF0cmlrIEbkbHRzdHL2bSIgPHBhZkBjaXNjby5j b20+OyAiUGF1bCBWaXhpZSIgPHZpeGllQGlzYy5vcmc+OyA8bmFtZWRyb3BwZXJzQG9wcy5pZXRm Lm9yZz4NClNlbnQ6IFN1bmRheSwgQXVndXN0IDI5LCAyMDEwIDEyOjQ5IEFNDQpTdWJqZWN0OiBS ZTogW2Ruc2V4dF0gRE5TRVhUIGNoYXJ0ZXIgYW5kIHRyZWF0aW5nIEROUyBuYW1lcyBhcyAidGhl IHNhbWUiDQoNCg0KPiBUaGVyZSBhcmUgdGhyZWUgY2hvaWNlczoNCj4gDQo+IDEpIEF0dGVtcHQg dG8gbWVldCBhIHNldCBvZiByZXF1aXJlbWVudHMgdGhhdCBhcHBlYXIgdG8gYmUgaW5jb25zaXN0 ZW50DQo+IDIpIE1lZXQgYSByZWR1Y2VkIHNldCBvZiByZXF1aXJlbWVudHMgd2Uga25vdyB0aGF0 IHdlIGNhbiBtZWV0IGJ1dA0KPiBmYWxsIHNob3J0IG9mIHRoZSBuZWVkDQo+IDMpIERvIG5vdGhp bmcNCj4gDQo+IEkgcHJvcG9zZWQgdGhlIERpZCBZb3UgTWVhbiAoRFlNKSByZWNvcmQgYmVjYXVz ZSB0aGF0IGlzIGEgbG93ZXIgYm91bmQNCj4gZm9yIHdoYXQgd2UgbWlnaHQgYWNoaWV2ZS4gV2Ug Y2FuIGRlZmluaXRlbHkgZGVzY3JpYmUgYW5kIGltcGxlbWVudCBhDQo+IERZTSByZWNvcmQgYW5k IG1ha2UgaXQgd29yay4gSXQgZG9lcyBub3QgbWVldCB0aGUgZnVsbCBzZXQgb2YNCj4gcmVxdWly ZW1lbnRzIHRoYXQgcGVvcGxlIHRoaW5rIHRoYXQgdGhleSB3YW50IGJ1dCBJIGRvbid0IGNvbnNp ZGVyDQo+IHRoZW0gdG8gYmUgc2F0aXNmaWFibGUuDQo+IA0KPiBUaGUgSW50ZXJuZXQgaXMgdmVy eSBsYXJnZSBhbmQgdmVyeSBjb21wbGV4LiBJdCBpcyBub3QgcG9zc2libGUgdG8NCj4gbWFrZSBt YWpvciBjaGFuZ2VzIHRvIHRoZSBjb3JlIGluZnJhc3RydWN0dXJlIGFuZCBoYXZlIHRoZW0gd29y aw0KPiBvdmVybmlnaHQuIEl0IHRha2VzIGEgbWluaW11bSBvZiBhYm91dCB0ZW4geWVhcnMgZm9y IGNlcnRhaW4gdHlwZXMgb2YNCj4gY2hhbmdlcyB0byB3b3JrIHRocm91Z2guDQo+DQoNCmlmIHdl IGNob29zZSB0byB1c2UgeE5hbWUsIEkgdGhpbmsgdGhhdCB4TmFtZSBpcyBub3QgYSBraW5kIG9m IGludGVybmV0IG1ham9yIGNoYW5nZXMuDQpmb3IgZXhhbXBsZSwgYWx0aG91Z2ggdGhlIEJOQU1F IHByb3Bvc2VzIGEgbmV3IFJSVFlQRSwgb25seSB0aGUgc2VydmVycyB3aGljaCB3YW50IHRvIHVz ZSBpdCBuZWVkIHRvIHVwZGF0ZSB0aGUgc2VydmVycy4NCnRoZSBjdXJyZW50IG5vbi1kbnNzZWMg cmVzb2x2ZXJzIGRvIG5vdCBuZWVkIHRvIGJlIHVwZGF0ZWQuIHRoZSBkbnNzZWMtcmVzb2x2ZXJz IG5lZWQgdG8gYmUgdXBkYXRlZCwgYnV0IHRoZSBkbnNzZWMgaXMganVzdCBzdGFydGluZyB0byBk ZXBsb3kuDQpzbyBpZiB3ZSBjYW4gY29tZSBvdXQgdGhlIHNvbHV0aW9uIHNvb24sIHRoZSBibmFt ZSBjYW4gZ2V0IHRoZSBkZXBsb3ltZW50IHdpdGggdGhlIGRuc3NlYy4gaXQgbWVhbnMgdGhhdCB3 ZSBkbyBub3QgbmVlZCB0ZW4geWVhcnMuDQoNCmlmIHdlIHRoaW5rIHRoYXQgYWRkaW5nIHRoZSBu ZXcgUlJUWVBFIHN1Y2ggYXMgQk5BTUUgaXMgYSBtYWpvciBpbnRlcm5ldCBjaGFuZ2UsIHRoZXJl IHdvdWxkIGhhdmUgaGFkIHRvbyBtYW55IG1ham9yIGludGVybmV0IGNoYW5nZXMgZHVyaW5nIHRo ZXNlIGRheXMuDQoNCmlmIHdlIHJlYWxseSBjYXJlIGZvciB0aGUgbWFqb3IgaW50ZXJuZXQgY2hh bmdlcywgZG8gd2Ugbm90aWNlIHRoYXQgdGhlcmUgaXMgYSByZWFsIGludGVybmV0IG1ham9yIGNo YW5nZS4gDQogdGhlIGRucyByb290IGhhcyB0aGUgSUROIFRMRHMgYW5kIHRoZXJlIHdpbGwgaGF2 ZSB0aG91c2FuZHMgb2YgSUROIFRMRHMgaW4gdGhlIGZ1dHVyZS4gVGhlIG51bWJlciBvZiBJRE4g VExEcyB3aWxsIGJlIGxhcmdlciB0aGFuIHRoZSBBU0NJSSBJRE4gVExEcyBpbiB0aGUgZnV0dXJl Lg0KDQpNb3N0IElETiBwcm90b2NvbHMgYXBwZWFyZWQgYmVmb3JlIHRoZSBJRE4gVExEcyBvciBJ RE5zIGNvbWUgdG8gdGhlIHdvcmxkLg0KaWYgd2UgY2FsbCB0aGUgY3VycmVudCBETlMgcHJvdG9j b2xzIGFzIHRoZSAiQVNDSUkgb3JpZW50ZWQgRE5TIHByb3RvY29scyIsIGRvIHdlIG5lZWQgZG8g c29tZXRoaW5nIGZvciB0aGUgSUROIEROUz8NCnRoZXJlIGFyZSBtb3JlIHRoYW4gMyBiaWxsaW9u IG9mIElETiB1c2VycyBpbiB0aGUgd29ybGQuIA0KaW4gMjAwNyBpZXRmIG1lZXRpbmcsIG9uZSBJ QUIgcGxlbmFyeSBpcyBhYm91dCB0aGUgSUROIGFuZCBpbnRlcm5hdGlvbmFsaXplZCBpZXRmIHBy b3RvY29scy4gSSB0aGluayB0aGF0IElBQiBoYXMgbm90aWNlZCBpdCBhbmQgbW9zdCBJRVRGIHBy b3RvY29scyB3aWxsIGRlYWwgd2l0aCBzb21lIGludGVybmF0aW9uYWxpemVkIGlzc3Vlcy4NCg0K SSB0aGluayB0aGF0IGlmICB3ZSBjYW4gZG8gc29tZXRoaW5nIGJlbmVmaXQgdG8gdGhlIDMgYmls bGlvbnMgb2YgaW50ZXJuZXQgdXNlcnMsIGl0IGlzIHdvcnRoIHRvIGRvIGl0IGV2ZW4gaWYgdGhh dCBpcyAidGhlIG1ham9yIGluZXJuZXQgY2hhbmdlcyB5b3UgY2FsbGVkIi4NCg0KDQpKaWFua2Fu ZyBZYW8NCg0KDQoNCg0KDQoNCg0KDQoNCg0KPg0KPiANCj4gV2Ugc2VlbSB0byBlbmQgdXAgd2l0 aCBhIHNpdHVhdGlvbiB3aGVyZSB0aGUgcGVvcGxlIHdobyBhcmUgcmVhbGlzdGljDQo+IGFib3V0 IGRlcGxveW1lbnQgY29uc3RyYWludHMgZ2V0IHNob3ZlZCBhc2lkZSBieSB0aGUgcGVvcGxlIHdo byBpbnNpc3QNCj4gdGhhdCBjaGFuZ2UgbXVzdCBjb21lIGZhc3Rlci4gU28gaW5zdGVhZCB3ZSBl bmQgdXAgd2l0aCBwcm9wb3NhbHMgZnJvbQ0KPiBwZW9wbGUgd2hvIHRoaW5rIHRoYXQgd2lzaGVz IGFyZSBwb25pZXMgYW5kIFJGQ3MgYXJlIGRlcGxveW1lbnRzLiBBbmQNCj4gdGVuIG9yIHNvIHll YXJzIGxhdGVyIHdlIGFyZSBzdGlsbCBhdCB0aGUgc3RhcnRpbmcgbGluZS4NCj4gDQo+IA0KPiAN Cj4gMjAxMC84LzI3IEFsZXggQmxpZ2ggPGFsZXhAYWxleC5vcmcudWs+Og0KPj4NCj4+DQo+PiAt LU9uIDI2IEF1Z3VzdCAyMDEwIDIyOjUxOjM0IC0wNDAwIERhbm55IE1heWVyIDxtYXllckBnaXMu bmV0PiB3cm90ZToNCj4+DQo+Pj4gVGhpcyBzb3VuZHMgbGlrZSB5b3UgYXJlIHN1Z2dlc3Rpbmcg dGhhdCBpZiBhIG1haWwgc2VydmVyIGlzIHNldCB1cCBmb3INCj4+PiBkb21haW4gWCBhbmQgaXQg aGFzIGEgc2hhZG93IHpvbmUgb3IgYSB4RE5BTUUgY29weSB0byBhIFkgZG9tYWluIHRoZW4gaXQN Cj4+PiBzaG91bGQgYXV0b21hdGljYWxseSBiZSBhYmxlIHRvIGNvbmZpZ3VyZSBpdHNlbGYgYmFz ZWQgb24gdGhlIEROUw0KPj4+IHJlY29yZHMgd2l0aCBib3RoIFggKmFuZCogWS4gVGhhdCByZXF1 aXJlcyBlbnVtZXJhdGluZyBhbGwgb2YgdGhlDQo+Pj4gImVxdWl2YWxlbnQiIGRvbWFpbnMgd2hp Y2ggd291bGQgYXJndWUgbW9yZSBpbiBmYXZvciBvZiBzb21ldGhpbmcgbGlrZQ0KPj4+IFBhdWwn cyBzaGFkb3cgem9uZSBwcm9wb3NhbCBzaW5jZSB0aG9zZSByZWNvcmRzIHdvdWxkIGhhdmUgdG8g ZXhpc3QgaW4NCj4+PiB0aGUgem9uZS4NCj4+DQo+PiBJIHRoaW5rIHNoYWRvdyBpcyB3b3J0aCBp bnZlc3RpZ2F0aW5nIGZ1cnRoZXIuIEknbSBub3QgeWV0IGNvbnZpbmNlZA0KPj4gdGhhdCB0aGUg YmVzdCBhbnN3ZXIgaXNuJ3QgImRvIG5vdGhpbmciLCB0aG91Z2guDQo+Pg0KPj4gLS0NCj4+IEFs ZXggQmxpZ2gNCj4+DQo+Pg0KPiANCj4gDQo+IA0KPiAtLSANCj4gV2Vic2l0ZTogaHR0cDovL2hh bGxhbWJha2VyLmNvbS8NCj4= From owner-namedroppers@ops.ietf.org Sun Aug 29 22:13: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 EB0D73A6953; Sun, 29 Aug 2010 22:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.535, 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 2970styfsBDw; Sun, 29 Aug 2010 22:12:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C6333A6875; Sun, 29 Aug 2010 22:12:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Opwat-0000md-Fj for namedroppers-data0@psg.com; Mon, 30 Aug 2010 05:07:43 +0000 Received: from mail-iw0-f180.google.com ([209.85.214.180]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Opwam-0000lu-4N for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 05:07:36 +0000 Received: by iwn6 with SMTP id 6so6534244iwn.11 for ; Sun, 29 Aug 2010 22:07:32 -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=QIyWt7rNvpp9rrprFFGCd91b1zlv8Al20I2KAKFy4G8=; b=OkCkhjpq20p4xhom6+VjONTUyBwO1ZFcytHFD8sdK5Fs3JGiC8ra2YR+kD5qFQCI0q JvEXTsU0uG7o8RvYWZ4RGKVWkYYTuy6JJI6O4sdLeS7wPTziqi8d/Nv1Wp5UweVfBxJT pL3a2P5sp6TxwCCifNpvb/3rntKFAKtJD46eY= 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=aRhM3yjbPFwAe2U80bh5aguYtmVofwNdpKgEteqLd879v9ofNGSFoU7JR/n7nTAIjV PnExE2yyWQqMT4wFDP5HYBz3te12S+1nDCEnu1sdK6u1Qmn+CCSxsZlhHN21FogLveb5 4VM5qmL5InF/V0ILmtH/WlW9/77f6j+AxMcZE= MIME-Version: 1.0 Received: by 10.231.192.80 with SMTP id dp16mr4807986ibb.39.1283144852347; Sun, 29 Aug 2010 22:07:32 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Sun, 29 Aug 2010 22:07:32 -0700 (PDT) In-Reply-To: <483135399.29271@cnnic.cn> References: <20100810133649.GC52191@shinkuro.com> <4C650D10.8070809@nic.cz> <18374.1281714027@nsa.vix.com> <4C6FD98E.2020502@ntp.org> <3EFF9C9D-DBEA-4498-B727-B003812C6602@cisco.com> <4C72CEF9.9080301@gis.net> <01A3703B1DD6AC4BD168DF06@Ximines.local> <4C72E186.7010901@gis.net> <4C772836.7010105@gis.net> <483135399.29271@cnnic.cn> Date: Mon, 30 Aug 2010 01:07:32 -0400 Message-ID: Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" From: Phillip Hallam-Baker To: Jiankang YAO Cc: Alex Bligh , mayer@gis.net, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , 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: The issue is not the cost of the changes, it will be the amount of infrastructure that will have to have changed before the changes may be used successfully. The problem is not the DNS infrastructure, it is the fact that Web servers will not know what to do with the connection attempts unless we require changes in administration to be made that render the need for a new DNS record superfluous. 2010/8/29 Jiankang YAO : > > ----- Original Message ----- > From: "Phillip Hallam-Baker" > To: "Alex Bligh" > Cc: ; "Patrik F=E4ltstr=F6m" ; "Paul Vixie"= ; > Sent: Sunday, August 29, 2010 12:49 AM > Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" > > >> There are three choices: >> >> 1) Attempt to meet a set of requirements that appear to be inconsistent >> 2) Meet a reduced set of requirements we know that we can meet but >> fall short of the need >> 3) Do nothing >> >> I proposed the Did You Mean (DYM) record because that is a lower bound >> for what we might achieve. We can definitely describe and implement a >> DYM record and make it work. It does not meet the full set of >> requirements that people think that they want but I don't consider >> them to be satisfiable. >> >> The Internet is very large and very complex. It is not possible to >> make major changes to the core infrastructure and have them work >> overnight. It takes a minimum of about ten years for certain types of >> changes to work through. >> > > if we choose to use xName, I think that xName is not a kind of internet m= ajor changes. > for example, although the BNAME proposes a new RRTYPE, only the servers w= hich want to use it need to update the servers. > the current non-dnssec resolvers do not need to be updated. the dnssec-re= solvers need to be updated, but the dnssec is just starting to deploy. > so if we can come out the solution soon, the bname can get the deployment= with the dnssec. it means that we do not need ten years. > > if we think that adding the new RRTYPE such as BNAME is a major internet = change, there would have had too many major internet changes during these d= ays. > > if we really care for the major internet changes, do we notice that there= is a real internet major change. > =A0the dns root has the IDN TLDs and there will have thousands of IDN TLD= s in the future. The number of IDN TLDs will be larger than the ASCII IDN T= LDs in the future. > > Most IDN protocols appeared before the IDN TLDs or IDNs come to the world= . > if we call the current DNS protocols as the "ASCII oriented DNS protocols= ", do we need do something for the IDN DNS? > there are more than 3 billion of IDN users in the world. > in 2007 ietf meeting, one IAB plenary is about the IDN and internationali= zed ietf protocols. I think that IAB has noticed it and most IETF protocols= will deal with some internationalized issues. > > I think that if =A0we can do something benefit to the 3 billions of inter= net users, it is worth to do it even if that is "the major inernet changes = you called". > > > Jiankang Yao > > > > > > > > > > >> >> >> We seem to end up with a situation where the people who are realistic >> about deployment constraints get shoved aside by the people who insist >> that change must come faster. So instead we end up with proposals from >> people who think that wishes are ponies and RFCs are deployments. And >> ten or so years later we are still at the starting line. >> >> >> >> 2010/8/27 Alex Bligh : >>> >>> >>> --On 26 August 2010 22:51:34 -0400 Danny Mayer wrote: >>> >>>> This sounds like you are suggesting that if a mail server is set up fo= r >>>> domain X and it has a shadow zone or a xDNAME copy to a Y domain then = it >>>> should automatically be able to configure itself based on the DNS >>>> records with both X *and* Y. That requires enumerating all of the >>>> "equivalent" domains which would argue more in favor of something like >>>> Paul's shadow zone proposal since those records would have to exist in >>>> the zone. >>> >>> I think shadow is worth investigating further. I'm not yet convinced >>> that the best answer isn't "do nothing", though. >>> >>> -- >>> Alex Bligh >>> >>> >> >> >> >> -- >> Website: http://hallambaker.com/ >> --=20 Website: http://hallambaker.com/ From dnsext-archive@ietf.org Mon Aug 30 01:43: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 03AEC3A67D1 for ; Mon, 30 Aug 2010 01:43: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 AE hex): Subject: ...-archive@ietf.org V|AGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -18.063 X-Spam-Level: X-Spam-Status: No, score=-18.063 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.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, FUZZY_VPILL=0.687, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, J_CHICKENPOX_14=0.6, MANGLED_VIAGRA=2.5, 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_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_OBFU_VIAGRA=1.666, SUBJECT_NEEDS_ENCODING=0.001, TT_OBSCURED_VIAGRA=1.652, 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 HAf4RuchL-hR for ; Mon, 30 Aug 2010 01:43:25 -0700 (PDT) Received: from host-94-243-98-237.hspa.orange.md (host-94-243-98-237.hspa.orange.md [94.243.98.237]) by core3.amsl.com (Postfix) with SMTP id 66AC93A679F for ; Mon, 30 Aug 2010 01:43:24 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org V|AGRA ® Official Seller -55% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100830084324.66AC93A679F@core3.amsl.com> Date: Mon, 30 Aug 2010 01:43:24 -0700 (PDT)
Click here!

From owner-namedroppers@ops.ietf.org Mon Aug 30 01:50: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 A5C3E3A67D1; Mon, 30 Aug 2010 01:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.174 X-Spam-Level: X-Spam-Status: No, score=-106.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgLCuAR7w1mI; Mon, 30 Aug 2010 01:50:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 46D0D3A679F; Mon, 30 Aug 2010 01:50:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Opzys-0004Ez-DM for namedroppers-data0@psg.com; Mon, 30 Aug 2010 08:44:42 +0000 Received: from mx2.nic.fr ([2001:660:3003:2::4:11]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Opzym-0004DO-4Y for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 08:44:36 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 892DE1C008F; Mon, 30 Aug 2010 10:44:34 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 849961C006A; Mon, 30 Aug 2010 10:44:34 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 82E9F568122; Mon, 30 Aug 2010 10:44:34 +0200 (CEST) Date: Mon, 30 Aug 2010 10:44:34 +0200 From: Stephane Bortzmeyer To: Jiankang YAO Cc: namedroppers@ops.ietf.org Subject: [dnsext] Re: DNSEXT charter and treating DNS names as "the same" Message-ID: <20100830084434.GA20399@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 5.0.5 X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Aug 30, 2010 at 10:30:04AM +0800, Jiankang YAO wrote a message of 70 lines which said: > the dns root has the IDN TLDs and there will have thousands of IDN > TLDs in the future. The number of IDN TLDs will be larger than the > ASCII IDN TLDs in the future. I don't see the point. I'm a big fan of IDN, I agree that we will have one day more IDN TLDs than ASCII TLD but so what? What's the connection with the whole discussion about "synchronous domains" and the possible solutions (xNAME, SHADOW, etc)? Unless you claim that *every* IDN TLD require synchronization of content (something that not everyone will agree with) *and* that this synchronization requires a non-provisioning method to be done, something that you often repeat but which is not true. Please provide hard facts, not just hand-waving about IDN. We can deploy IDN (actually, it is already done) without xNAME. Domain synchronization is not an IDN issue. (I would like to have bortzmeyer.fr and bortzmeyer.org synchronized, even if they are ASCII names.) From owner-namedroppers@ops.ietf.org Mon Aug 30 02:24: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 D5E083A67A3; Mon, 30 Aug 2010 02:24:48 -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: -99.074 X-Spam-Level: X-Spam-Status: No, score=-99.074 tagged_above=-999 required=5 tests=[AWL=0.928, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 e9aDJHJdiH5M; Mon, 30 Aug 2010 02:24:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 77F513A679F; Mon, 30 Aug 2010 02:24:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oq0Y2-0009is-7n for namedroppers-data0@psg.com; Mon, 30 Aug 2010 09:21:02 +0000 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oq0Xv-0009iJ-IG for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 09:20:55 +0000 Received: (eyou send program); Mon, 30 Aug 2010 17:20:52 +0800 Message-ID: <483160052.08202@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, 30 Aug 2010 17:20:52 +0800 Message-ID: <328DCC4D8C7C45A1A31B5759A3C9442C@LENOVO47E041CF> From: "Jiankang YAO" To: "Stephane Bortzmeyer" Cc: References: <483158956.02282@cnnic.cn> Subject: Re: [dnsext] Re: DNSEXT charter and treating DNS names as "the same" Date: Mon, 30 Aug 2010 17:20:57 +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.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlN0ZXBoYW5lIEJvcnR6bWV5 ZXIiIDxib3J0em1leWVyQG5pYy5mcj4NClRvOiAiSmlhbmthbmcgWUFPIiA8eWFvamtAY25uaWMu Y24+DQpDYzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIEF1Z3Vz dCAzMCwgMjAxMCA0OjQ0IFBNDQpTdWJqZWN0OiBbZG5zZXh0XSBSZTogRE5TRVhUIGNoYXJ0ZXIg YW5kIHRyZWF0aW5nIEROUyBuYW1lcyBhcyAidGhlIHNhbWUiDQoNCg0KPiBPbiBNb24sIEF1ZyAz MCwgMjAxMCBhdCAxMDozMDowNEFNICswODAwLA0KPiBKaWFua2FuZyBZQU8gPHlhb2prQGNubmlj LmNuPiB3cm90ZSANCj4gYSBtZXNzYWdlIG9mIDcwIGxpbmVzIHdoaWNoIHNhaWQ6DQo+IA0KPj4g IHRoZSBkbnMgcm9vdCBoYXMgdGhlIElETiBUTERzIGFuZCB0aGVyZSB3aWxsIGhhdmUgdGhvdXNh bmRzIG9mIElETg0KPj4gIFRMRHMgaW4gdGhlIGZ1dHVyZS4gVGhlIG51bWJlciBvZiBJRE4gVExE cyB3aWxsIGJlIGxhcmdlciB0aGFuIHRoZQ0KPj4gIEFTQ0lJIElETiBUTERzIGluIHRoZSBmdXR1 cmUuDQo+IA0KPiBJIGRvbid0IHNlZSB0aGUgcG9pbnQuIEknbSBhIGJpZyBmYW4gb2YgSUROLCBJ IGFncmVlIHRoYXQgd2Ugd2lsbCBoYXZlDQo+IG9uZSBkYXkgbW9yZSBJRE4gVExEcyB0aGFuIEFT Q0lJIFRMRCBidXQgc28gd2hhdD8gV2hhdCdzIHRoZQ0KPiBjb25uZWN0aW9uIHdpdGggdGhlIHdo b2xlIGRpc2N1c3Npb24gYWJvdXQgInN5bmNocm9ub3VzIGRvbWFpbnMiIGFuZA0KPiB0aGUgcG9z c2libGUgc29sdXRpb25zICh4TkFNRSwgU0hBRE9XLCBldGMpPw0KPg0KDQpJRE4gVExEcyBvciBz b21lIHNlY29uZCBsZXZlbHMgSUROIGRvbWFpbiBuYW1lcyBtYXkgbmVlZCB0aGUgc29sdXRpb24u DQoNCmZvciBleGFtcGxlLCBncmVlY2UsIGNoaW5lc2UsIGFyYWJpYywgaW5kaWEgY2hhcmFjdGVy Lg0KDQp0aGVyZSBpcyBhIGNoYXJhY3RlciB2YXJpYW50IGdyb3VwIGluIElDQU5OLCB3aGljaCBm b2N1cyBvbiBkaXNjdXNzaW9uIG9mIHRoZSB2YXJpYW50IGNoYXJhY3RlcnMgZnJvbSBkaWZmZXJl bnQgbGFuZ3VhZ2VzLg0KDQo+DQo+IFVubGVzcyB5b3UgY2xhaW0gdGhhdCAqZXZlcnkqIElETiBU TEQgcmVxdWlyZSBzeW5jaHJvbml6YXRpb24gb2YNCj4gY29udGVudCAoc29tZXRoaW5nIHRoYXQg bm90IGV2ZXJ5b25lIHdpbGwgYWdyZWUgd2l0aCkgKmFuZCogdGhhdCB0aGlzDQo+IHN5bmNocm9u aXphdGlvbiByZXF1aXJlcyBhIG5vbi1wcm92aXNpb25pbmcgbWV0aG9kIHRvIGJlIGRvbmUsDQo+ IHNvbWV0aGluZyB0aGF0IHlvdSBvZnRlbiByZXBlYXQgYnV0IHdoaWNoIGlzIG5vdCB0cnVlLg0K Pg0KDQpJIGNhbiBub3QgcHJvdmUgdGhhdCBldmVyeSBJRE4gVExEIG5lZWQgaXQuDQpidXQgc29t ZSBJRE4gVExEIGFuZCBzZWNvbmQgbGV2ZWwgSUROIGRvbWFpbiBuYW1lcyBuZWVkIGl0Lg0KDQp0 aGUgdXNlcnMgb2YgdGhhdCBraW5kIG9mICBJRE4gVExEIG9yIHNlY29uZCBsZXZlbCBJRE4gZG9t YWluIG5hbWVzIGlzIG5vdCBtaWxsaW9ucywgYnV0IGJpbGxpb25zLg0KDQpJIHRoaW5rIHRoYXQg RE5TIGlzIG5vdCBvbmx5IGZvciBBU0NJSSBiYXNlZCBjaGFyYWN0ZXJzLCBidXQgYWxzbyBJRE4u DQoNCg0KPg0KPiANCj4gUGxlYXNlIHByb3ZpZGUgaGFyZCBmYWN0cywgbm90IGp1c3QgaGFuZC13 YXZpbmcgYWJvdXQgSUROLiBXZSBjYW4NCj4gZGVwbG95IElETiAoYWN0dWFsbHksIGl0IGlzIGFs cmVhZHkgZG9uZSkgd2l0aG91dCB4TkFNRS4gDQo+DQoNCndlIGNhbiB1c2Ugc29tZSBpZG5zIG5v dywgYnV0IHdlIHNob3VsZCBtYWtlIHRoZW0gd29yayBiZXR0ZXIuDQoNCg0KPg0KPiANCj4gRG9t YWluIHN5bmNocm9uaXphdGlvbiBpcyBub3QgYW4gSUROIGlzc3VlLg0KPg0KDQpEb21haW4gc3lu Y2hyb25pemF0aW9uIGlzIGZyb20gdGhlICBJRE4gaXNzdWUsIG1heSBiZSByZXNvbHZlZCBpbiB0 aGUgRE5TLg0KDQo+DQo+IChJIHdvdWxkIGxpa2UgdG8gaGF2ZQ0KPiBib3J0em1leWVyLmZyIGFu ZCBib3J0em1leWVyLm9yZyBzeW5jaHJvbml6ZWQsIGV2ZW4gaWYgdGhleSBhcmUgQVNDSUkNCj4g bmFtZXMuKQ0KPg0KDQp0aGlzIGlzIGEga2luZCBvZiBkb21haW4gbmFtZXMgd2Ugc2hvdWxkIG1h a2UgaXQgc3luY2hyb25pemVkLg0KDQoNCj4gDQo+IA0KPiANCj4= From owner-namedroppers@ops.ietf.org Mon Aug 30 02:34: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 87A2F3A67A3; Mon, 30 Aug 2010 02:34:48 -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: -99.087 X-Spam-Level: X-Spam-Status: No, score=-99.087 tagged_above=-999 required=5 tests=[AWL=0.915, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 CGTnve700fvy; Mon, 30 Aug 2010 02:34:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9EC2A3A679F; Mon, 30 Aug 2010 02:34:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oq0iI-000BCw-FW for namedroppers-data0@psg.com; Mon, 30 Aug 2010 09:31:38 +0000 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oq0iB-000BBz-0P for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 09:31:31 +0000 Received: (eyou send program); Mon, 30 Aug 2010 17:31:30 +0800 Message-ID: <483160690.05013@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, 30 Aug 2010 17:31:30 +0800 Message-ID: From: "Jiankang YAO" To: "Phillip Hallam-Baker" Cc: "Alex Bligh" , , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Paul Vixie" , References: <20100810133649.GC52191@shinkuro.com><4C650D10.8070809@nic.cz><18374.1281714027@nsa.vix.com><4C6FD98E.2020502@ntp.org><3EFF9C9D-DBEA-4498-B727-B003812C6602@cisco.com><4C72CEF9.9080301@gis.net><01A3703B1DD6AC4BD168DF06@Ximines.local><4C72E186.7010901@gis.net><4C772836.7010105@gis.net><483135399.29271@cnnic.cn> Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same" Date: Mon, 30 Aug 2010 17:31:35 +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.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBoaWxsaXAgSGFsbGFtLUJh a2VyIiA8aGFsbGFtQGdtYWlsLmNvbT4NClRvOiAiSmlhbmthbmcgWUFPIiA8eWFvamtAY25uaWMu Y24+DQpDYzogIkFsZXggQmxpZ2giIDxhbGV4QGFsZXgub3JnLnVrPjsgPG1heWVyQGdpcy5uZXQ+ OyAiUGF0cmlrIEbkbHRzdHL2bSIgPHBhZkBjaXNjby5jb20+OyAiUGF1bCBWaXhpZSIgPHZpeGll QGlzYy5vcmc+OyA8bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZz4NClNlbnQ6IE1vbmRheSwgQXVn dXN0IDMwLCAyMDEwIDE6MDcgUE0NClN1YmplY3Q6IFJlOiBbZG5zZXh0XSBETlNFWFQgY2hhcnRl ciBhbmQgdHJlYXRpbmcgRE5TIG5hbWVzIGFzICJ0aGUgc2FtZSINCg0KDQo+VGhlIGlzc3VlIGlz IG5vdCB0aGUgY29zdCBvZiB0aGUgY2hhbmdlcywgDQo+DQoNCmhvcGUgc28uDQoNCj4NCj5pdCB3 aWxsIGJlIHRoZSBhbW91bnQgb2YNCj5pbmZyYXN0cnVjdHVyZSB0aGF0IHdpbGwgaGF2ZSB0byBo YXZlIGNoYW5nZWQgYmVmb3JlIHRoZSBjaGFuZ2VzIG1heQ0KPmJlIHVzZWQgc3VjY2Vzc2Z1bGx5 Lg0KPg0KDQpJIGRvbid0IHRoaW5rIHRoYXQgaXQgaXMgbmVjZXNzYXJ5Lg0KaWYgIHlvdSB3YW50 IHRvIHVzZSB0aGUgIGFsaWFzMS5jb20gYW5kIGFsaWFzLmNvbSwgdGhlIGRvbWFpbiBhZG1pbmlz dHJhdG9yICBtdXN0ICByZWdpc3QgdGhlbSBmaXJzdCAodGhlIGRvbWFpbiBhZG1pbmlzdHJhdG9y IGtub3dzIGhvdyBtYW55IGFsaWFzIGRvbWFpbiBuYW1lcyByZWdpc3RlcmVkLCB5b3UgbWF5IHNl ZSByZmMzNzQzIHRvbykgYW5kIHRoZW4gcHV0IHRoZW0gdG8gdGhlIGRucy4NCnNvIHRoZSBhZG1p bmlzdHJhdG9yIGtub3cgdGhlc2UgYWxpYXMgZG9tYWluIG5hbWVzIGFuZCB3aWxsIGNvbmZpZ3Vy ZSB0aGVtIHByb3Blcmx5Lg0KDQp0aGlzIGNvbmZpZ3VyZWF0aW9uIGlzIHNpbWlsYXIgdG8gdGhl IGN1cnJlbnQgcHJhY3Rpc2Ugb2YgY29uZmlndXJhdGlvbiBvZiBnb29nbGUuY29tIGFuZCBnb29n bGUudWsgcG9pbnRpbmcgdG8gdGhlIHNhbWUgYWRkcmVzcy4NCg0KDQoNCj4NCj5UaGUgcHJvYmxl bSBpcyBub3QgdGhlIEROUyBpbmZyYXN0cnVjdHVyZSwgaXQgaXMgdGhlIGZhY3QgdGhhdCBXZWIN Cj5zZXJ2ZXJzIHdpbGwgbm90IGtub3cgd2hhdCB0byBkbyB3aXRoIHRoZSBjb25uZWN0aW9uIGF0 dGVtcHRzIHVubGVzcw0KPndlIHJlcXVpcmUgY2hhbmdlcyBpbiBhZG1pbmlzdHJhdGlvbiB0byBi ZSBtYWRlIHRoYXQgcmVuZGVyIHRoZSBuZWVkDQo+Zm9yIGEgbmV3IEROUyByZWNvcmQgc3VwZXJm bHVvdXMuDQo+DQoNCnBscyBzZWUgdGhlIGV4YW1wbGUgYWJvdmUuDQoNCkppYW5rYW5nIFlhbw0K DQoyMDEwLzgvMjkgSmlhbmthbmcgWUFPIDx5YW9qa0Bjbm5pYy5jbj46DQo+DQo+IC0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogIlBoaWxsaXAgSGFsbGFtLUJha2VyIiA8aGFs bGFtQGdtYWlsLmNvbT4NCj4gVG86ICJBbGV4IEJsaWdoIiA8YWxleEBhbGV4Lm9yZy51az4NCj4g Q2M6IDxtYXllckBnaXMubmV0PjsgIlBhdHJpayBG5Gx0c3Ry9m0iIDxwYWZAY2lzY28uY29tPjsg IlBhdWwgVml4aWUiIDx2aXhpZUBpc2Mub3JnPjsgPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+ DQo+IFNlbnQ6IFN1bmRheSwgQXVndXN0IDI5LCAyMDEwIDEyOjQ5IEFNDQo+IFN1YmplY3Q6IFJl OiBbZG5zZXh0XSBETlNFWFQgY2hhcnRlciBhbmQgdHJlYXRpbmcgRE5TIG5hbWVzIGFzICJ0aGUg c2FtZSINCj4NCj4NCj4+IFRoZXJlIGFyZSB0aHJlZSBjaG9pY2VzOg0KPj4NCj4+IDEpIEF0dGVt cHQgdG8gbWVldCBhIHNldCBvZiByZXF1aXJlbWVudHMgdGhhdCBhcHBlYXIgdG8gYmUgaW5jb25z aXN0ZW50DQo+PiAyKSBNZWV0IGEgcmVkdWNlZCBzZXQgb2YgcmVxdWlyZW1lbnRzIHdlIGtub3cg dGhhdCB3ZSBjYW4gbWVldCBidXQNCj4+IGZhbGwgc2hvcnQgb2YgdGhlIG5lZWQNCj4+IDMpIERv IG5vdGhpbmcNCj4+DQo+PiBJIHByb3Bvc2VkIHRoZSBEaWQgWW91IE1lYW4gKERZTSkgcmVjb3Jk IGJlY2F1c2UgdGhhdCBpcyBhIGxvd2VyIGJvdW5kDQo+PiBmb3Igd2hhdCB3ZSBtaWdodCBhY2hp ZXZlLiBXZSBjYW4gZGVmaW5pdGVseSBkZXNjcmliZSBhbmQgaW1wbGVtZW50IGENCj4+IERZTSBy ZWNvcmQgYW5kIG1ha2UgaXQgd29yay4gSXQgZG9lcyBub3QgbWVldCB0aGUgZnVsbCBzZXQgb2YN Cj4+IHJlcXVpcmVtZW50cyB0aGF0IHBlb3BsZSB0aGluayB0aGF0IHRoZXkgd2FudCBidXQgSSBk b24ndCBjb25zaWRlcg0KPj4gdGhlbSB0byBiZSBzYXRpc2ZpYWJsZS4NCj4+DQo+PiBUaGUgSW50 ZXJuZXQgaXMgdmVyeSBsYXJnZSBhbmQgdmVyeSBjb21wbGV4LiBJdCBpcyBub3QgcG9zc2libGUg dG8NCj4+IG1ha2UgbWFqb3IgY2hhbmdlcyB0byB0aGUgY29yZSBpbmZyYXN0cnVjdHVyZSBhbmQg aGF2ZSB0aGVtIHdvcmsNCj4+IG92ZXJuaWdodC4gSXQgdGFrZXMgYSBtaW5pbXVtIG9mIGFib3V0 IHRlbiB5ZWFycyBmb3IgY2VydGFpbiB0eXBlcyBvZg0KPj4gY2hhbmdlcyB0byB3b3JrIHRocm91 Z2guDQo+Pg0KPg0KPiBpZiB3ZSBjaG9vc2UgdG8gdXNlIHhOYW1lLCBJIHRoaW5rIHRoYXQgeE5h bWUgaXMgbm90IGEga2luZCBvZiBpbnRlcm5ldCBtYWpvciBjaGFuZ2VzLg0KPiBmb3IgZXhhbXBs ZSwgYWx0aG91Z2ggdGhlIEJOQU1FIHByb3Bvc2VzIGEgbmV3IFJSVFlQRSwgb25seSB0aGUgc2Vy dmVycyB3aGljaCB3YW50IHRvIHVzZSBpdCBuZWVkIHRvIHVwZGF0ZSB0aGUgc2VydmVycy4NCj4g dGhlIGN1cnJlbnQgbm9uLWRuc3NlYyByZXNvbHZlcnMgZG8gbm90IG5lZWQgdG8gYmUgdXBkYXRl ZC4gdGhlIGRuc3NlYy1yZXNvbHZlcnMgbmVlZCB0byBiZSB1cGRhdGVkLCBidXQgdGhlIGRuc3Nl YyBpcyBqdXN0IHN0YXJ0aW5nIHRvIGRlcGxveS4NCj4gc28gaWYgd2UgY2FuIGNvbWUgb3V0IHRo ZSBzb2x1dGlvbiBzb29uLCB0aGUgYm5hbWUgY2FuIGdldCB0aGUgZGVwbG95bWVudCB3aXRoIHRo ZSBkbnNzZWMuIGl0IG1lYW5zIHRoYXQgd2UgZG8gbm90IG5lZWQgdGVuIHllYXJzLg0KPg0KPiBp ZiB3ZSB0aGluayB0aGF0IGFkZGluZyB0aGUgbmV3IFJSVFlQRSBzdWNoIGFzIEJOQU1FIGlzIGEg bWFqb3IgaW50ZXJuZXQgY2hhbmdlLCB0aGVyZSB3b3VsZCBoYXZlIGhhZCB0b28gbWFueSBtYWpv ciBpbnRlcm5ldCBjaGFuZ2VzIGR1cmluZyB0aGVzZSBkYXlzLg0KPg0KPiBpZiB3ZSByZWFsbHkg Y2FyZSBmb3IgdGhlIG1ham9yIGludGVybmV0IGNoYW5nZXMsIGRvIHdlIG5vdGljZSB0aGF0IHRo ZXJlIGlzIGEgcmVhbCBpbnRlcm5ldCBtYWpvciBjaGFuZ2UuDQo+IHRoZSBkbnMgcm9vdCBoYXMg dGhlIElETiBUTERzIGFuZCB0aGVyZSB3aWxsIGhhdmUgdGhvdXNhbmRzIG9mIElETiBUTERzIGlu IHRoZSBmdXR1cmUuIFRoZSBudW1iZXIgb2YgSUROIFRMRHMgd2lsbCBiZSBsYXJnZXIgdGhhbiB0 aGUgQVNDSUkgSUROIFRMRHMgaW4gdGhlIGZ1dHVyZS4NCj4NCj4gTW9zdCBJRE4gcHJvdG9jb2xz IGFwcGVhcmVkIGJlZm9yZSB0aGUgSUROIFRMRHMgb3IgSUROcyBjb21lIHRvIHRoZSB3b3JsZC4N Cj4gaWYgd2UgY2FsbCB0aGUgY3VycmVudCBETlMgcHJvdG9jb2xzIGFzIHRoZSAiQVNDSUkgb3Jp ZW50ZWQgRE5TIHByb3RvY29scyIsIGRvIHdlIG5lZWQgZG8gc29tZXRoaW5nIGZvciB0aGUgSURO IEROUz8NCj4gdGhlcmUgYXJlIG1vcmUgdGhhbiAzIGJpbGxpb24gb2YgSUROIHVzZXJzIGluIHRo ZSB3b3JsZC4NCj4gaW4gMjAwNyBpZXRmIG1lZXRpbmcsIG9uZSBJQUIgcGxlbmFyeSBpcyBhYm91 dCB0aGUgSUROIGFuZCBpbnRlcm5hdGlvbmFsaXplZCBpZXRmIHByb3RvY29scy4gSSB0aGluayB0 aGF0IElBQiBoYXMgbm90aWNlZCBpdCBhbmQgbW9zdCBJRVRGIHByb3RvY29scyB3aWxsIGRlYWwg d2l0aCBzb21lIGludGVybmF0aW9uYWxpemVkIGlzc3Vlcy4NCj4NCj4gSSB0aGluayB0aGF0IGlm IHdlIGNhbiBkbyBzb21ldGhpbmcgYmVuZWZpdCB0byB0aGUgMyBiaWxsaW9ucyBvZiBpbnRlcm5l dCB1c2VycywgaXQgaXMgd29ydGggdG8gZG8gaXQgZXZlbiBpZiB0aGF0IGlzICJ0aGUgbWFqb3Ig aW5lcm5ldCBjaGFuZ2VzIHlvdSBjYWxsZWQiLg0KPg0KPg0KPiBKaWFua2FuZyBZYW8NCj4NCg== From owner-namedroppers@ops.ietf.org Mon Aug 30 02:49: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 B866F3A67A3; Mon, 30 Aug 2010 02:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.003 X-Spam-Level: X-Spam-Status: No, score=-1.003 tagged_above=-999 required=5 tests=[AWL=1.596, 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 oycwZL-VEoo3; Mon, 30 Aug 2010 02:49:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8553C3A679F; Mon, 30 Aug 2010 02:49:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oq0w3-000DNL-IE for namedroppers-data0@psg.com; Mon, 30 Aug 2010 09:45:51 +0000 Received: from mail.avalus.com ([89.16.176.221]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oq0vw-000DMi-Sr for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 09:45:45 +0000 Received: from [195.173.23.106] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 11660C5695A; Mon, 30 Aug 2010 10:45:42 +0100 (BST) Date: Mon, 30 Aug 2010 10:45:44 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jiankang YAO , Stephane Bortzmeyer cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Re: DNSEXT charter and treating DNS names as "the same" Message-ID: In-Reply-To: <483160052.08202@cnnic.cn> References: <483158956.02282@cnnic.cn> <483160052.08202@cnnic.cn> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 30 August 2010 17:20:57 +0800 Jiankang YAO wrote: >> Unless you claim that *every* IDN TLD require synchronization of >> content (something that not everyone will agree with) *and* that this >> synchronization requires a non-provisioning method to be done, >> something that you often repeat but which is not true. > > I can not prove that every IDN TLD need it. > but some IDN TLD and second level IDN domain names need it. *Why* do these TLDs need XNAME as opposed to the provisioning method? Let us assume the provisioning method means synchronized entries move together between registrants etc. The only thing XNAME gives you beyond the provisioning method AFAICS is ensuring the tree below the delegation point is also synchronized, which is (in some circumstances) disadvantageous in making the applications perform similarly (as demonstrated several times). So what is the /advantage/ of XNAME over provisioning, given its trivial to demonstrate provisioning is capable of doing the same thing and is more flexible when 'the same thing' is sometimes wrong? -- Alex Bligh From dnsext-archive@ietf.org Mon Aug 30 05: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 38ADB3A69B0 for ; Mon, 30 Aug 2010 05:23:51 -0700 (PDT) X-Quarantine-ID: <7IVSE6EexNDQ> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org V|AGRA \256 Official Selle[...] X-Spam-Flag: NO X-Spam-Score: -17.423 X-Spam-Level: X-Spam-Status: No, score=-17.423 tagged_above=-999 required=5 tests=[BAYES_95=3, DRUGS_ERECTILE=1, DRUGS_ERECTILE_OBFU=1.5, FUZZY_VPILL=0.687, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, J_CHICKENPOX_14=0.6, MANGLED_VIAGRA=2.5, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_OBFU_VIAGRA=1.666, SUBJECT_NEEDS_ENCODING=0.001, TT_OBSCURED_VIAGRA=1.652, 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 7IVSE6EexNDQ for ; Mon, 30 Aug 2010 05:23:45 -0700 (PDT) Received: from cpc4-lanc3-0-0-cust475.3-3.cable.virginmedia.com (cpc4-lanc3-0-0-cust475.3-3.cable.virginmedia.com [80.3.13.220]) by core3.amsl.com (Postfix) with SMTP id 42BA13A69A0 for ; Mon, 30 Aug 2010 05:22:18 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org V|AGRA ® Official Seller -76% MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20100830122218.42BA13A69A0@core3.amsl.com> Date: Mon, 30 Aug 2010 05:22:18 -0700 (PDT)
Click here!

From owner-namedroppers@ops.ietf.org Mon Aug 30 09:08: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 5AE813A6826; Mon, 30 Aug 2010 09:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, J_CHICKENPOX_22=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 P2HN4zu9qiIH; Mon, 30 Aug 2010 09:08:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D42E3A682F; Mon, 30 Aug 2010 09:08:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oq6ne-000Fcy-49 for namedroppers-data0@psg.com; Mon, 30 Aug 2010 16:01:34 +0000 Received: from mail-px0-f180.google.com ([209.85.212.180]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oq6nW-000FcS-W5 for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 16:01:27 +0000 Received: by pxi7 with SMTP id 7so4249748pxi.11 for ; Mon, 30 Aug 2010 09:01:26 -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; bh=JN2jVulqRN91xc2Wmf+W0Yj4KeLdgkvroXERG3/hTJ4=; b=kzTRPwPMx1vsNrs21jkltAXb1U80pyCUkeRFzQ5aW0VYpJsiUB1VM9ENjdsqzayoc2 QEQKVZeafrnHA5Y5LUnzKYCi5f4nTU7gNeny2wi1d57HaXbwfeIppJKdQ8k/KLlwuiBx HJbJtukrRjob6q01/HjtwWU/mvImBVv6v/jQw= 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=XrWaTWpkWOjrCVRsW+NDsrfweTQhAk54i8glfC1L79rbORwvvpjeUFTpqgIT6EJftR s9I7gztyc+al3v5HP9qlBblrmL8bAWi+xXyk4pc4h7vysGh1i5CF50z8FDT3KA5/aIJw vdNNv1vg1es1vqwA/h2gyb2Q5UQ01NMRPrRWY= MIME-Version: 1.0 Received: by 10.142.174.4 with SMTP id w4mr4811987wfe.119.1283184085930; Mon, 30 Aug 2010 09:01:25 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Mon, 30 Aug 2010 09:01:24 -0700 (PDT) In-Reply-To: References: <483158956.02282@cnnic.cn> <483160052.08202@cnnic.cn> Date: Mon, 30 Aug 2010 12:01:24 -0400 Message-ID: Subject: Re: [dnsext] Re: DNSEXT charter and treating DNS names as "the same" From: Phillip Hallam-Baker To: Alex Bligh Cc: Jiankang YAO , Stephane Bortzmeyer , 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: The only reason I can see to reject the provisioning method is that the provisioning may not work across zones of authority. So for example, let us imagine that I want to synchronize hallambaker.com with hallambaker.co.uk. If I registered the .co.uk version I would be able to program my DNS configurator to create the same records in each domain. The same infrastructure tells my Web server to map www.hallambaker.co.uk to www.hallambaker.com through an internal redirect. I get precisely the effect desired with no need to change any of the DNS infrastructure. The only (minor) downside being that this may not work identically if I decide to make radical changes to my DN configuration and end up with records that are out of sync. But this is not really a major difference to what happens with a single zone, cutovers take time to propagate, that is the way the Web is. Now imagine that .co.uk decide that they want to synchronize *.co.uk and *.co.gb. So now I start to see traffic from www.hallam.co.gb. My Web server has no idea that this should be redirected to hallam.com and no way to find out. The only way that I can see to make an XNAME type scheme work would be as follows: 1) CANONICALIZE I don't care if you want the two trees to be peers. That type of system simply does not work reliably in my view. If you want multiple naming to work then you have to pick one set of names that is canonical and map all the equivalents to those forms. If you can't pick one set of names then do like they are doing with IPv9 and map everything to numbers which is probably where IDNs will end up in any case because there isn't a single keyboard on the planet that can type every UNICODE code point direct without the user learning a coding scheme and there never will be (I don't think handwriting recognition is likely to work much better either). On the other hand, every telephone handset in the world has decimal Arabic numerals and can call every other telephone handset in the world. 2) ZNAME pointer to describe the forward reference. This contains the following fields * Canonical domain * Alias link The canonical domain has a ZNAME link pointing to itself and the first alias in the list. The first alias points to the second and so on. co.uk ZNAME co.uk co.gb co.gb ZNAME co.uk co.unitedkingdom co.unitedkingdom ZNAME co.uk co.uk This is the bare minimum of information required to make the scheme work. And it is somewhat flawed since we would ideally want to have all these records signed using the .co.uk ZSK and this is not something that DNSSEC really supports/enforces. Better would be the following co.uk ZPTR co.gb co.gb._ZNAME.co.uk ZPTR co.unitedkingdom co.unitedkingdom._ZNAME.co.uk ZPTR co.gb ZNAME co.uk co.unitedkingdom ZNAME co.uk OK so we have removed all arbitrary limits from the scheme, what does that buy us over the DYM record which is an advisory pointer as follows: co.gb DYM co.uk co.unitedkingdom DYM co.uk The only difference between ZNAME and DYM is that with DYM there are no processing rules defined in the DNS system. So processing for ZNAME would be: Client looks up www.hallambaker.co.uk, gets A record returned for www.hallambaker.com. All clients automatically support ZNAME because the processing rules are in the DNS system If their DNS resolver supports ZNAME - user gets to see site. Otherwise - user gets 'site not found' page from web client If Server supports ZNAME lookup - user gets to see site. If Server does not support ZNAME - user gets 'site not found' page from web server Processing for DYM on the other hand would be Client looks up www.hallambaker.co.uk, gets A record returned for www.hallambaker.com. If client supports DYM - user gets directed to the right site Otherwise user does not get directed to the right site. No other part of the infrastructure needs to provide support. The dependence on the resolver is particularly difficult from a user experience perspective. Changing their means of accessing the net will cause sites that were reachable to suddenly become unreachable for unknown reasons. On Mon, Aug 30, 2010 at 5:45 AM, Alex Bligh wrote: > > > --On 30 August 2010 17:20:57 +0800 Jiankang YAO wrote: > >>> Unless you claim that *every* IDN TLD require synchronization of >>> content (something that not everyone will agree with) *and* that this >>> synchronization requires a non-provisioning method to be done, >>> something that you often repeat but which is not true. >> >> I can not prove that every IDN TLD need it. >> but some IDN TLD and second level IDN domain names need it. > > *Why* do these TLDs need XNAME as opposed to the provisioning method? > > Let us assume the provisioning method means synchronized entries move > together between registrants etc. The only thing XNAME gives you beyond the > provisioning method AFAICS is ensuring the tree below the delegation point > is also synchronized, which is (in some circumstances) disadvantageous in > making the applications perform similarly (as demonstrated several times). > So what is the /advantage/ of XNAME over provisioning, given its trivial > to demonstrate provisioning is capable of doing the same thing and is > more flexible when 'the same thing' is sometimes wrong? > > -- > Alex Bligh > > -- Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Mon Aug 30 09:14: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 BE5CB3A6826; Mon, 30 Aug 2010 09:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 nTNHf5zTL5p9; Mon, 30 Aug 2010 09:14:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E09F33A6840; Mon, 30 Aug 2010 09:14:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oq6wC-000Gyx-Df for namedroppers-data0@psg.com; Mon, 30 Aug 2010 16:10:24 +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.72 (FreeBSD)) (envelope-from ) id 1Oq6w5-000GyP-Sr for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 16:10:18 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id E15A5A1031 for ; Mon, 30 Aug 2010 16:10:15 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: [dnsext] regulatory problem statement (was Re: ... as "the same") In-Reply-To: Your message of "Mon, 30 Aug 2010 10:44:34 +0200." <20100830084434.GA20399@nic.fr> References: <20100830084434.GA20399@nic.fr> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Mon, 30 Aug 2010 16:10:15 +0000 Message-ID: <34484.1283184615@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, 30 Aug 2010 10:44:34 +0200 > From: Stephane Bortzmeyer > ... > Unless you claim that *every* IDN TLD require synchronization of content > (something that not everyone will agree with) *and* that this > synchronization requires a non-provisioning method to be done, something > that you often repeat but which is not true. ICANN's regulatory regime (such as it is) makes adding "new tld's" difficult. it is very hard to create a new IDN TLD which isn't synchronized to a current one since this would run afoul of competitive issues ("why does CNNIC get so many TLD's and my national name registry get so few?") and also commercial issues ("you're calling that an IDN TLD but it is basically another .COM for a specific language and has no relation to any ISO3166 TLD's namespace.") it is comparatively much easier for ICANN to create synchronized IDN TLD's since they are just new windows into an existing namespace. provisioning hacks are not a strong enough guaranty that synchronization will occur -- ICANN is doing it now just to get things started but they will not do it for the many hundreds/thousands of IDN TLD's yet to come. if everybody here could expand their horizons a bit, stop looking at this as a simple engineering problem where the simplest/cheapest solution is usually the right one, then we'd stop seeing the repeated refuge of "just use a provisioning hack and stop asking for a protocol change". that will not work since the problem statement is in ICANN's regulatory regime not in the DNS. ICANN has been uncharacteristically clear about this, and yao has explained it several times, and i've explained it at least once. no provisioning hack of any kind will answer ICANN's problem statement. please stop proposing it. > Please provide hard facts, not just hand-waving about IDN. We can > deploy IDN (actually, it is already done) without xNAME. done. (again.) > Domain synchronization is not an IDN issue. (I would like to have > bortzmeyer.fr and bortzmeyer.org synchronized, even if they are ASCII > names.) sounds as if you'd appreciate SHADOW then. but, IDN TLD's have regulatory issues that your personal domain does not have, so, the situations are not similar. From owner-namedroppers@ops.ietf.org Mon Aug 30 10: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 7716B3A6841; Mon, 30 Aug 2010 10:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.336 X-Spam-Level: X-Spam-Status: No, score=-0.336 tagged_above=-999 required=5 tests=[AWL=-0.337, 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 a1SUvnV2tSdp; Mon, 30 Aug 2010 10:48:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9CA1F3A68DA; Mon, 30 Aug 2010 10:48:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oq8OM-0006B5-NW for namedroppers-data0@psg.com; Mon, 30 Aug 2010 17:43:34 +0000 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oq8OG-0006Ac-3u for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 17:43:28 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=MGdL937avWa5bqgo7XOd5Z4ExKE07G4RnvTC8Na0Uz39w4SrnOvv3oDp+3O9dORH; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.29] (helo=mswamui-cedar.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Oq8OE-0003Qa-9J for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 13:43:26 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Mon, 30 Aug 2010 13:43:25 -0400 Message-ID: <22707592.1283190206223.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> Date: Mon, 30 Aug 2010 12:43:25 -0500 (GMT-05:00) From: "Jeffrey A. Williams" Reply-To: "Jeffrey A. Williams" To: namedroppers@ops.ietf.org Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688b4f0d9d6e27a557e51b9765906023bae350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.29 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 and all, Sorry Paul but I have to disagree with your contention as well ICANN's 'Problem Statement'. That 'Problem Statement' is in effect a political one that does not address the current demand. IDN's of many variations are coming wheather or not ICANN likes it as such decisions are of particular national/nations interest. Therefore syncrinization into the name space via a DNS hack is preferrable if not necessary. ISO3166 TLD's namespace is and has been out of date now from a public demand standpoint for a few years. Multipul IDN TLD name spaces already exist most o which are not syncronized, some will perhaps never be, and those that will or wish to be will not relinquish their established customer base easily or simply based on ICANN's desire. Same is and has been true for other non IDN TLD's for several years now AND was acknowledged by DOC/NTIA way back in 2002. -----Original Message----- >From: Paul Vixie >Sent: Aug 30, 2010 11:10 AM >To: namedroppers@ops.ietf.org >Subject: [dnsext] regulatory problem statement (was Re: ... as "the same") > >> Date: Mon, 30 Aug 2010 10:44:34 +0200 >> From: Stephane Bortzmeyer >> ... >> Unless you claim that *every* IDN TLD require synchronization of content >> (something that not everyone will agree with) *and* that this >> synchronization requires a non-provisioning method to be done, something >> that you often repeat but which is not true. > >ICANN's regulatory regime (such as it is) makes adding "new tld's" difficult. >it is very hard to create a new IDN TLD which isn't synchronized to a current >one since this would run afoul of competitive issues ("why does CNNIC get so >many TLD's and my national name registry get so few?") and also commercial >issues ("you're calling that an IDN TLD but it is basically another .COM for >a specific language and has no relation to any ISO3166 TLD's namespace.") > >it is comparatively much easier for ICANN to create synchronized IDN TLD's >since they are just new windows into an existing namespace. provisioning >hacks are not a strong enough guaranty that synchronization will occur -- >ICANN is doing it now just to get things started but they will not do it for >the many hundreds/thousands of IDN TLD's yet to come. > >if everybody here could expand their horizons a bit, stop looking at this as >a simple engineering problem where the simplest/cheapest solution is usually >the right one, then we'd stop seeing the repeated refuge of "just use a >provisioning hack and stop asking for a protocol change". that will not work >since the problem statement is in ICANN's regulatory regime not in the DNS. > >ICANN has been uncharacteristically clear about this, and yao has explained >it several times, and i've explained it at least once. no provisioning hack >of any kind will answer ICANN's problem statement. please stop proposing it. > >> Please provide hard facts, not just hand-waving about IDN. We can >> deploy IDN (actually, it is already done) without xNAME. > >done. (again.) > >> Domain synchronization is not an IDN issue. (I would like to have >> bortzmeyer.fr and bortzmeyer.org synchronized, even if they are ASCII >> names.) > >sounds as if you'd appreciate SHADOW then. but, IDN TLD's have regulatory >issues that your personal domain does not have, so, the situations are not >similar. > Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From owner-namedroppers@ops.ietf.org Mon Aug 30 10: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 5F46A3A69F4; Mon, 30 Aug 2010 10:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.324 X-Spam-Level: X-Spam-Status: No, score=-1.324 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, J_CHICKENPOX_22=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 R-GieHvAlYBH; Mon, 30 Aug 2010 10:57:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 67B3D3A69EF; Mon, 30 Aug 2010 10:57:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oq8YX-0007hQ-BK for namedroppers-data0@psg.com; Mon, 30 Aug 2010 17:54:05 +0000 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oq8YQ-0007ga-Ac for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 17:53:58 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=QJuNHl7I8SuLIDWWj8uPKBKlPHlC8TsNP4lsbgb4GkeM/476AaCzbm5uQ0HQC+Li; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.29] (helo=mswamui-cedar.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Oq8YO-0007eU-Iz for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 13:53:56 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Mon, 30 Aug 2010 13:53:55 -0400 Message-ID: <8303035.1283190836638.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> Date: Mon, 30 Aug 2010 12:53:56 -0500 (GMT-05:00) From: "Jeffrey A. Williams" Reply-To: "Jeffrey A. Williams" To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: DNSEXT charter and treating DNS names as "the same" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688048ae808ed4a5c212cb986407b75600a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.29 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Phillip and all, Percisely and nicely done! Unfortunately what you discribe/outline will not set well with ICANN. Some may/will find that attitude inconsequencial as exceptance of other name spaces will wait or market for the market to come to them, as IPv9 for instance and by design, indicates. Wheather or not ICANN chooses to recognize such may influence the burgioning marketplace to retreat and some to seek other DNS hack alternitives that are both safe and inclusive but not directly associated with the present legacy name space in any way. -----Original Message----- >From: Phillip Hallam-Baker >Sent: Aug 30, 2010 11:01 AM >To: Alex Bligh >Cc: Jiankang YAO , Stephane Bortzmeyer , namedroppers@ops.ietf.org >Subject: Re: [dnsext] Re: DNSEXT charter and treating DNS names as "the same" > >The only reason I can see to reject the provisioning method is that >the provisioning may not work across zones of authority. > >So for example, let us imagine that I want to synchronize >hallambaker.com with hallambaker.co.uk. If I registered the .co.uk >version I would be able to program my DNS configurator to create the >same records in each domain. > >The same infrastructure tells my Web server to map >www.hallambaker.co.uk to www.hallambaker.com through an internal >redirect. > >I get precisely the effect desired with no need to change any of the >DNS infrastructure. The only (minor) downside being that this may not >work identically if I decide to make radical changes to my DN >configuration and end up with records that are out of sync. But this >is not really a major difference to what happens with a single zone, >cutovers take time to propagate, that is the way the Web is. > > >Now imagine that .co.uk decide that they want to synchronize *.co.uk >and *.co.gb. > >So now I start to see traffic from www.hallam.co.gb. My Web server has >no idea that this should be redirected to hallam.com and no way to >find out. > > >The only way that I can see to make an XNAME type scheme work would be >as follows: > >1) CANONICALIZE > >I don't care if you want the two trees to be peers. That type of >system simply does not work reliably in my view. If you want multiple >naming to work then you have to pick one set of names that is >canonical and map all the equivalents to those forms. > >If you can't pick one set of names then do like they are doing with >IPv9 and map everything to numbers which is probably where IDNs will >end up in any case because there isn't a single keyboard on the planet >that can type every UNICODE code point direct without the user >learning a coding scheme and there never will be (I don't think >handwriting recognition is likely to work much better either). On the >other hand, every telephone handset in the world has decimal Arabic >numerals and can call every other telephone handset in the world. > > >2) ZNAME pointer to describe the forward reference. > >This contains the following fields > >* Canonical domain >* Alias link > >The canonical domain has a ZNAME link pointing to itself and the first >alias in the list. The first alias points to the second and so on. > >co.uk ZNAME co.uk co.gb >co.gb ZNAME co.uk co.unitedkingdom >co.unitedkingdom ZNAME co.uk co.uk > > >This is the bare minimum of information required to make the scheme >work. And it is somewhat flawed since we would ideally want to have >all these records signed using the .co.uk ZSK and this is not >something that DNSSEC really supports/enforces. > >Better would be the following > >co.uk ZPTR co.gb >co.gb._ZNAME.co.uk ZPTR co.unitedkingdom >co.unitedkingdom._ZNAME.co.uk ZPTR > >co.gb ZNAME co.uk >co.unitedkingdom ZNAME co.uk > > >OK so we have removed all arbitrary limits from the scheme, what does >that buy us over the DYM record which is an advisory pointer as >follows: > >co.gb DYM co.uk >co.unitedkingdom DYM co.uk > >The only difference between ZNAME and DYM is that with DYM there are >no processing rules defined in the DNS system. > >So processing for ZNAME would be: > >Client looks up www.hallambaker.co.uk, gets A record returned for >www.hallambaker.com. >All clients automatically support ZNAME because the processing rules >are in the DNS system > >If their DNS resolver supports ZNAME - user gets to see site. >Otherwise - user gets 'site not found' page from web client > >If Server supports ZNAME lookup - user gets to see site. >If Server does not support ZNAME - user gets 'site not found' page >from web server > > >Processing for DYM on the other hand would be > >Client looks up www.hallambaker.co.uk, gets A record returned for >www.hallambaker.com. > >If client supports DYM - user gets directed to the right site >Otherwise user does not get directed to the right site. > >No other part of the infrastructure needs to provide support. > > >The dependence on the resolver is particularly difficult from a user >experience perspective. Changing their means of accessing the net will >cause sites that were reachable to suddenly become unreachable for >unknown reasons. > > > >On Mon, Aug 30, 2010 at 5:45 AM, Alex Bligh wrote: >> >> >> --On 30 August 2010 17:20:57 +0800 Jiankang YAO wrote: >> >>>> Unless you claim that *every* IDN TLD require synchronization of >>>> content (something that not everyone will agree with) *and* that this >>>> synchronization requires a non-provisioning method to be done, >>>> something that you often repeat but which is not true. >>> >>> I can not prove that every IDN TLD need it. >>> but some IDN TLD and second level IDN domain names need it. >> >> *Why* do these TLDs need XNAME as opposed to the provisioning method? >> >> Let us assume the provisioning method means synchronized entries move >> together between registrants etc. The only thing XNAME gives you beyond the >> provisioning method AFAICS is ensuring the tree below the delegation point >> is also synchronized, which is (in some circumstances) disadvantageous in >> making the applications perform similarly (as demonstrated several times). >> So what is the /advantage/ of XNAME over provisioning, given its trivial >> to demonstrate provisioning is capable of doing the same thing and is >> more flexible when 'the same thing' is sometimes wrong? >> >> -- >> Alex Bligh >> >> > > > >-- >Website: http://hallambaker.com/ > Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From owner-namedroppers@ops.ietf.org Mon Aug 30 12:24: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 6A4703A6856; Mon, 30 Aug 2010 12:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=1.547, 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 IxzA9vs+cUG8; Mon, 30 Aug 2010 12:24:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A01AF3A69BA; Mon, 30 Aug 2010 12:24:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oq9t7-000MXJ-D2 for namedroppers-data0@psg.com; Mon, 30 Aug 2010 19:19:25 +0000 Received: from mail.avalus.com ([89.16.176.221]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oq9t0-000MWe-Ks for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 19:19:19 +0000 Received: from [195.173.23.106] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 894CCC56953; Mon, 30 Aug 2010 20:19:16 +0100 (BST) Date: Mon, 30 Aug 2010 20:19:18 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Message-ID: <5831A1FCBAF9396EF92D3914@nimrod.local> In-Reply-To: <34484.1283184615@nsa.vix.com> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 30 August 2010 16:10:15 +0000 Paul Vixie wrote: > if everybody here could expand their horizons a bit, stop looking at this > as a simple engineering problem where the simplest/cheapest solution is > usually the right one, then we'd stop seeing the repeated refuge of "just > use a provisioning hack and stop asking for a protocol change". that > will not work since the problem statement is in ICANN's regulatory regime > not in the DNS. > > ICANN has been uncharacteristically clear about this, and yao has > explained it several times, and i've explained it at least once. no > provisioning hack of any kind will answer ICANN's problem statement. > please stop proposing it. I am not saying it's necessarily the case here, but... In the hypothetical situation where ICANN or anyone else for that matter were to propose solving a political problem with an unpleasant technical hack which cause adverse side effects, and possibly without fully thinking through the problems space, I believe a valid potential response from the working group concerned is "we think this is a bad idea and we are not going to to support it". Or, is what you are saying, that if ICANN proposes a technical solution for a political problem, and says jump, we should merely ask how high? To the specific point: > provisioning > hacks are not a strong enough guaranty that synchronization will occur >From a technical point of view, I am far from convinced that synchronization is a good thing, whatever ICANN thinks. If it is, what ICANN gives, ICANN can take away, and thus a contractual solution is perfectly possible. If this (strong guarantee of synchorization) is the only reason to do this, I would say "don't do it". -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 30 13: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 2D7403A6814; Mon, 30 Aug 2010 13:28:27 -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 Hz-ORDg+NU8j; Mon, 30 Aug 2010 13:28:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E35823A684C; Mon, 30 Aug 2010 13:28:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqAsm-0007Kt-K6 for namedroppers-data0@psg.com; Mon, 30 Aug 2010 20:23:08 +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.72 (FreeBSD)) (envelope-from ) id 1OqAsg-0007K4-MF for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 20:23:02 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id CD82BA1031 for ; Mon, 30 Aug 2010 20:23:01 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") In-Reply-To: Your message of "Mon, 30 Aug 2010 20:19:18 +0100." <5831A1FCBAF9396EF92D3914@nimrod.local> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <5831A1FCBAF9396EF92D3914@nimrod.local> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Mon, 30 Aug 2010 20:23:01 +0000 Message-ID: <49228.1283199781@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, 30 Aug 2010 20:19:18 +0100 > From: Alex Bligh > ... > Or, is what you are saying, that if ICANN proposes a technical solution > for a political problem, and says jump, we should merely ask how high? neither. i'm saying that the DNS is not just a technological device, it is also extant as an economic and political device. the root and its TLDs have always been handled differently than private domains. we've already pulled DNSSEC off the rails once for TLD's (see 5155) and once for the root (see RFC 5011) so i'm just not ready to hear that we won't take real world needs into account when doing our engineering. in fact an engineer who doesn't take real world needs into account cannot succeed. (see .) > To the specific point: > > > provisioning hacks are not a strong enough guaranty that > > synchronization will occur > > From a technical point of view, I am far from convinced that > synchronization is a good thing, whatever ICANN thinks. ICANN (speaking of the community, not the staff) is a hive mind and you can not usefully ask what it thinks. i'm describing its (reality) constraints. > If it is, what ICANN gives, ICANN can take away, and thus a contractual > solution is perfectly possible. that's a pure engineering mindset speaking, and i strongly suggest otherwise. > If this (strong guarantee of synchorization) is the only reason to do > this, I would say "don't do it". it's not the only reason. and when i proposed SHADOW i had other uses in mind, such as the symmetry i'd like to have in the namespaces at VIX.COM, VIXIE.ORG, VIXIE.SF.CA.US, and maybe others i'm forgetting here. the only difference is, for me personally, provisioning hacks can also be used. but ICANN is not the only entity for whom that's not true. any larger and more complex domain holder could want to do multivendor in a way that would make the "provisioning hacks" approach really expensive (in TCO terms.) From owner-namedroppers@ops.ietf.org Mon Aug 30 15:07: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 1DCC13A69F6; Mon, 30 Aug 2010 15:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.405 X-Spam-Level: X-Spam-Status: No, score=-100.405 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_20=-0.74, 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 J95YbzdA6whU; Mon, 30 Aug 2010 15:07:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 148BF3A68DD; Mon, 30 Aug 2010 15:07:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqCQk-000M10-JU for namedroppers-data0@psg.com; Mon, 30 Aug 2010 22:02:18 +0000 Received: from hoffman.proper.com ([207.182.41.81]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqCQe-000M0b-MR for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 22:02:12 +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 o7UM1wWf009995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Aug 2010 15:01:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <49228.1283199781@nsa.vix.com> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <5831A1FCBAF9396EF92D3914@nimrod.local> <49228.1283199781@nsa.vix.com> Date: Mon, 30 Aug 2010 15:01:56 -0700 To: Paul Vixie , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") 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:23 PM +0000 8/30/10, Paul Vixie wrote: >ICANN (speaking of the community, not the staff) is a hive mind and you can >not usefully ask what it thinks. i'm describing its (reality) constraints. It doesn't feel that way. It feels like you are describing the constraints that some parts of that hive feels, but certainly not all. If it was all parts, then ICANN would not now be putting into the root TLDs that "require" synchronization. That synchronization is not happening, which proves that the requirement is mislabeled. (Corrections from ICANN staff are welcomed here.) >any larger and more >complex domain holder could want to do multivendor in a way that would make >the "provisioning hacks" approach really expensive (in TCO terms.) Of course. All the proposed solutions are "really expensive (in TCO terms)"; otherwise, we would have already probably picked the one that was clearly the least expensive. Instead, what we have discovered is that the costs for the different solutions are orthogonal and thus nearly impossible to compare. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Mon Aug 30 15:26: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 87BCD3A68D3; Mon, 30 Aug 2010 15:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.921, 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 XJQmKSHlNlLZ; Mon, 30 Aug 2010 15:26:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0CA8E3A68B9; Mon, 30 Aug 2010 15:26:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqCjm-000PGx-PR for namedroppers-data0@psg.com; Mon, 30 Aug 2010 22:21:58 +0000 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqCjg-000PFl-Cl for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 22:21:52 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=Zga3eNUYePpLsNIs1Vx4sJxGiy02ATS7AFl/ffCg6lS/tecA1MkqK7vp73zzOsnH; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.29] (helo=mswamui-cedar.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OqCjd-0000Bj-Vv; Mon, 30 Aug 2010 18:21:49 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Mon, 30 Aug 2010 18:21:49 -0400 Message-ID: <22056462.1283206909921.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> Date: Mon, 30 Aug 2010 17:21:49 -0500 (GMT-05:00) From: "Jeffrey A. Williams" Reply-To: "Jeffrey A. Williams" To: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688eb3f477d2348ec4e1c21fbec4eaef2f9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.29 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 and all, I think your right that ICANN in particular is not going to go along with "provisioning hacks" as will not some larger and more complex domain holder could want to do multivendor as you say below. But some more complex domain holder may do so if the reward could be seen worth the precieved risk on the business side of the equation. The above said for me anyway and others I know of, wheather or not ICANN goes along or likes "provisioning hacks" or not is irrelevant to what is underway or already exists in the wild now. However some more complex domain name holders may be less 'Hivish' and see significant rewards looking at taking some advantage of "provisioning hacks" that arn't already doing so but not advertizing they are. >;) -----Original Message----- >From: Paul Vixie >Sent: Aug 30, 2010 3:23 PM >To: namedroppers@ops.ietf.org >Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") > >> Date: Mon, 30 Aug 2010 20:19:18 +0100 >> From: Alex Bligh >> ... >> Or, is what you are saying, that if ICANN proposes a technical solution >> for a political problem, and says jump, we should merely ask how high? > >neither. i'm saying that the DNS is not just a technological device, it >is also extant as an economic and political device. the root and its TLDs >have always been handled differently than private domains. we've already >pulled DNSSEC off the rails once for TLD's (see 5155) and once for the root >(see RFC 5011) so i'm just not ready to hear that we won't take real world >needs into account when doing our engineering. > >in fact an engineer who doesn't take real world needs into account cannot >succeed. (see .) > >> To the specific point: >> >> > provisioning hacks are not a strong enough guaranty that >> > synchronization will occur >> >> From a technical point of view, I am far from convinced that >> synchronization is a good thing, whatever ICANN thinks. > >ICANN (speaking of the community, not the staff) is a hive mind and you can >not usefully ask what it thinks. i'm describing its (reality) constraints. > >> If it is, what ICANN gives, ICANN can take away, and thus a contractual >> solution is perfectly possible. > >that's a pure engineering mindset speaking, and i strongly suggest otherwise. > >> If this (strong guarantee of synchorization) is the only reason to do >> this, I would say "don't do it". > >it's not the only reason. and when i proposed SHADOW i had other uses in >mind, such as the symmetry i'd like to have in the namespaces at VIX.COM, >VIXIE.ORG, VIXIE.SF.CA.US, and maybe others i'm forgetting here. the only >difference is, for me personally, provisioning hacks can also be used. but >ICANN is not the only entity for whom that's not true. any larger and more >complex domain holder could want to do multivendor in a way that would make >the "provisioning hacks" approach really expensive (in TCO terms.) > Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From owner-namedroppers@ops.ietf.org Mon Aug 30 15:45: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 432C13A68AD; Mon, 30 Aug 2010 15:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.717 X-Spam-Level: X-Spam-Status: No, score=-101.717 tagged_above=-999 required=5 tests=[AWL=0.882, 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 JLVpDvS+OvaG; Mon, 30 Aug 2010 15:45:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 903E03A68BB; Mon, 30 Aug 2010 15:45:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqD49-0002gb-9T for namedroppers-data0@psg.com; Mon, 30 Aug 2010 22:43:01 +0000 Received: from mail.yitter.info ([208.86.224.201]) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqD43-0002fK-Ar for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 22:42: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 2F4F01ECB408 for ; Mon, 30 Aug 2010 22:42:53 +0000 (UTC) Date: Mon, 30 Aug 2010 18:42:51 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Message-ID: <20100830224251.GF24538@shinkuro.com> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34484.1283184615@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: On Mon, Aug 30, 2010 at 04:10:15PM +0000, Paul Vixie wrote: > if everybody here could expand their horizons a bit, stop looking at this as > a simple engineering problem where the simplest/cheapest solution is usually > the right one, then we'd stop seeing the repeated refuge of "just use a > provisioning hack and stop asking for a protocol change". that will not work > since the problem statement is in ICANN's regulatory regime not in the DNS. > > ICANN has been uncharacteristically clear about this, and yao has explained > it several times, and i've explained it at least once. no provisioning hack > of any kind will answer ICANN's problem statement. please stop proposing it. Where exactly is ICANN's problem statement? As one of the chairs who needs to agree to herd this work through the IETF, I'd like to see it. The only actual evidence we have from ICANN is that they _can_ do what they thought the synchronization stuff would achieve with provisioning, because in fact they already have. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Aug 30 15:48: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 257BA3A6814; Mon, 30 Aug 2010 15:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[AWL=1.502, 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 xtFhd9+01yfv; Mon, 30 Aug 2010 15:48:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 212AE3A67F9; Mon, 30 Aug 2010 15:48:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqD6k-0003Jz-2t for namedroppers-data0@psg.com; Mon, 30 Aug 2010 22:45:42 +0000 Received: from mail.avalus.com ([89.16.176.221]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqD6d-0003JO-VB for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 22:45:36 +0000 Received: from [195.173.23.106] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 73FF7C56958; Mon, 30 Aug 2010 23:45:34 +0100 (BST) Date: Mon, 30 Aug 2010 23:45:36 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Message-ID: <232890023F1F44341FAD59F5@nimrod.local> In-Reply-To: <49228.1283199781@nsa.vix.com> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <5831A1FCBAF9396EF92D3914@nimrod.local> <49228.1283199781@nsa.vix.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 30 August 2010 20:23:01 +0000 Paul Vixie wrote: > ICANN (speaking of the community, not the staff) is a hive mind and you > can not usefully ask what it thinks. i'm describing its (reality) > constraints. I don't think it is true that we cannot ask what it thinks. I think, for instance, we can enquire (*) as to the purpose of synchronization, especially where the proposal is arguably unhelpful to at least one possible rationale for synchronization (application layer consistency). (*) and if we receive no useful answer, do nothing. -- Alex Bligh From owner-namedroppers@ops.ietf.org Mon Aug 30 15:49: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 17E593A6814; Mon, 30 Aug 2010 15:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.727 X-Spam-Level: X-Spam-Status: No, score=-101.727 tagged_above=-999 required=5 tests=[AWL=0.872, 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 3Qidq8myKjet; Mon, 30 Aug 2010 15:49:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1FF883A68AD; Mon, 30 Aug 2010 15:49:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqD7p-0003VV-0l for namedroppers-data0@psg.com; Mon, 30 Aug 2010 22:46:49 +0000 Received: from mail.yitter.info ([208.86.224.201]) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqD7i-0003Uf-UI for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 22:46: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 B7B271ECB408 for ; Mon, 30 Aug 2010 22:46:40 +0000 (UTC) Date: Mon, 30 Aug 2010 18:46:39 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: DNSEXT charter and treating DNS names as "the same" Message-ID: <20100830224638.GG24538@shinkuro.com> References: <483158956.02282@cnnic.cn> <328DCC4D8C7C45A1A31B5759A3C9442C@LENOVO47E041CF> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <328DCC4D8C7C45A1A31B5759A3C9442C@LENOVO47E041CF> 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, Aug 30, 2010 at 05:20:57PM +0800, Jiankang YAO wrote: > > there is a character variant group in ICANN, which focus on discussion of the variant characters from different languages. > Good. I would like for them to explain what problems they think they have, and why they think those problems can be solved by changes to the DNS. I would like those explanations to take the form of textual contributions to the WG for inclusion in some requirements statement. We've already held two major sessions on this topic at IETF meetings, and with limited (but important) exceptions we've had not too much input from ICANN character variant group participants. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Aug 30 16: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 9B3A43A689E; Mon, 30 Aug 2010 16:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.082 X-Spam-Level: * X-Spam-Status: No, score=1.082 tagged_above=-999 required=5 tests=[AWL=1.081, 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 mwDPwaSMXY+x; Mon, 30 Aug 2010 16:02:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5876F3A6866; Mon, 30 Aug 2010 16:02:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqDKM-0005yi-KP for namedroppers-data0@psg.com; Mon, 30 Aug 2010 22:59:46 +0000 Received: from abenaki.wabanaki.net ([65.99.1.133]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqDKE-0005wq-2h for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 22:59:38 +0000 Received: from limpet.local (cpe-67-255-5-237.twcny.res.rr.com [67.255.5.237]) by abenaki.wabanaki.net (8.14.4/8.14.4) with ESMTP id o7ULsH6N034295; Mon, 30 Aug 2010 17:54:17 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4C7C37C0.30603@abenaki.wabanaki.net> Date: Mon, 30 Aug 2010 18:59:12 -0400 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> In-Reply-To: <34484.1283184615@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 8/30/10 12:10 PM, Paul Vixie wrote: >> Date: Mon, 30 Aug 2010 10:44:34 +0200 >> From: Stephane Bortzmeyer >> ... >> Unless you claim that *every* IDN TLD require synchronization of content >> (something that not everyone will agree with) *and* that this >> synchronization requires a non-provisioning method to be done, something >> that you often repeat but which is not true. > > ICANN's regulatory regime (such as it is) makes adding "new tld's" difficult. True, but it is self-inflicted difficulty. The authors of the policy to add new gTLDs in 2000, in 2004, and in 2008, did not constrain ICANN's choices from incremental, policy-based changes. ICANN Staff have chosen to implement the policy so as not to have incremental, policy-based changes, in the present, and thus far ICANN's Board have not chosen to have incremental, policy-based changes after the 2004 round. Further, the initial authors of the IDN for ccTLDs policy, did not constrain the policy to one script per ccTLD, or the consequence of the UTC's Han Unification of referring to SC and TC as a single script. On just such crap serious problems follow. > it is very hard to create a new IDN TLD which isn't synchronized to a current > one since this would run afoul of competitive issues ("why does CNNIC get so > many TLD's and my national name registry get so few?") and also commercial > issues ("you're calling that an IDN TLD but it is basically another .COM for > a specific language and has no relation to any ISO3166 TLD's namespace.") Why CNNIC gets so many TLDs and some other applicant from a state that uses a script other than Han gets fewer is _not_ a "competitive issue". It is a management-of-difference issue. I'm not aware of an application for an IDN TLD that is "basically another .COM" within the ccTLD IDN FastTrack. There is at least one such pending application, but it won't be made as an application for a ccTLD, and it exists in a policy framework in which a vendor is known to seek a priority claim to labels "like" .COM in several languages. > it is comparatively much easier for ICANN to create synchronized IDN TLD's > since they are just new windows into an existing namespace. provisioning > hacks are not a strong enough guaranty that synchronization will occur -- > ICANN is doing it now just to get things started but they will not do it for > the many hundreds/thousands of IDN TLD's yet to come. This really assumes things not in evidence. The SC/TC issue is real, and it has been since ... before the CDNC/JET people were unable to get the intermediate table fix into IDNA2003. But the necessity for some form of provisioning-or-stronger mechanism is not generalized for other scripts where the density of variant-capable slots in a string is vastly less than 1.0. > if everybody here could expand their horizons a bit, stop looking at this as > a simple engineering problem where the simplest/cheapest solution is usually > the right one, then we'd stop seeing the repeated refuge of "just use a > provisioning hack and stop asking for a protocol change". that will not work > since the problem statement is in ICANN's regulatory regime not in the DNS. I've never looked at this as a simple engineering problem. I was asked my advice in July 2001, I gave it. In November 2001 it became possible to resolve Chinese domain names correctly, at least where it mattered. > ICANN has been uncharacteristically clear about this, We must be sitting in different sections of the church. At Brussels I listened to Chris Despain attempt to make a requirements statement. He wasn't able to. The next day I listened to speak very loudly from the open mic at the poor guys (Arabic Script and Han Script ccTLD IDN FT implementers) sharing the stage with the non-policy-making ICANN IDN staffer at the lack of a clear requirements statement. He made the point to these poor honest implementers and the non-policy-making ICANN IDN staffer that a requirements statement was required. > and yao has explained > it several times, and i've explained it at least once. no provisioning hack > of any kind will answer ICANN's problem statement. please stop proposing it. This could be true, if there was an ICANN problem statement. >> Please provide hard facts, not just hand-waving about IDN. We can >> deploy IDN (actually, it is already done) without xNAME. To repeat what I said after the very tall and very loud fellow ... to the Han Script implementors -- "is it the case that most labels are five Han characters or less?" to the Arabic Script implementors -- "is it the case that 'variant' characters are 'sparce' in the label space, and occur primarily at label boundaries?" A "yes" answer to both questions, which is what was given by the implementers, leads to the conclusion that the SC/TC problem is very unlike the Arabic Script problem, the first being dense in the string space of labels, the latter being sparse in the string space of labels, and therefore we have a technical basis for distinguishing these two 'variant' cases from each other. Further, the five-or-less property means that the "combinatorial explosion" has a sharp knee between 4 and 6 and a very small tail. With registry policy capable of restricting equivalence sets to five or fewer characters, "bundle" size remains feasible, hence provisioning remains feasible. I want to re-iterate my admiration for the approach the CDNC members took in 2001, in considering cross-registration of equivalences within the four independently operated name spaces to achieve end user perception of correctness. > done. (again.) > >> Domain synchronization is not an IDN issue. (I would like to have >> bortzmeyer.fr and bortzmeyer.org synchronized, even if they are ASCII >> names.) > > sounds as if you'd appreciate SHADOW then. but, IDN TLD's have regulatory > issues that your personal domain does not have, so, the situations are not > similar. As I pointed out early in this discourse, and you made the same point, arbitrary equivalence has use cases, and it is over-specification to think of equivalence as being at the same level, or with the same (assumed) administrative model. It is true that _some_ IDN TLDs have issues (and I avoid the word "regulatory" because ICANN is a 501(c)(3), which enters into contracts for registry and registrar functions, as well as other relationships for registry functions, where the registry is associated with an iso3166-1 code point allocation. But not all IDN TLDs. I will submit an application for a gTLD with an Arabic Script string as the string to be delegated into the IANA root. No "regulatory" issues attach to any such application, or to the operation of a registry subsequent to delegation, only contractual issues. The same will be true for my application for a gTLD with a Han Script string, and my application for a gTLD with a Cyrillic Script string, and for anyone else's applications. Eric * The rhetorical "I", though it could actually be the literal me. From owner-namedroppers@ops.ietf.org Mon Aug 30 16:41: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 825D93A6882; Mon, 30 Aug 2010 16:41:58 -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 OdRW8t65v12F; Mon, 30 Aug 2010 16:41:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E1013A6859; Mon, 30 Aug 2010 16:41:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqDvs-000BwQ-BZ for namedroppers-data0@psg.com; Mon, 30 Aug 2010 23:38: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.72 (FreeBSD)) (envelope-from ) id 1OqDvm-000Bvt-Nn for namedroppers@ops.ietf.org; Mon, 30 Aug 2010 23:38:26 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5CD0BA1031 for ; Mon, 30 Aug 2010 23:38:26 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") In-Reply-To: Your message of "Mon, 30 Aug 2010 23:45:36 +0100." <232890023F1F44341FAD59F5@nimrod.local> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <5831A1FCBAF9396EF92D3914@nimrod.local> <49228.1283199781@nsa.vix.com> <232890023F1F44341FAD59F5@nimrod.local> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Mon, 30 Aug 2010 23:38:26 +0000 Message-ID: <60220.1283211506@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, 30 Aug 2010 23:45:36 +0100 > From: Alex Bligh > > I don't think it is true that we cannot ask what it thinks. i didn't say you couldn't ask. i said you couldn't usefully ask. > I think, for instance, we can enquire (*) as to the purpose of > synchronization, especially where the proposal is arguably unhelpful to > at least one possible rationale for synchronization (application layer > consistency). to the extent that some solution will not serve existing applications at all, then it won't matter whether it also helps ICANN fit its constraints, since ICANN would not be able to "sell" (politically speaking) a solution like that to its stakeholders. i think ICANN has been pretty clear about why it wants this stuff. i'm not saying anything newsworthy in this thread. > (*) and if we receive no useful answer, do nothing. that would be bad engineering. not all questions have useful answers. it is not our job here to judge the worthiness of ICANN's constraints. let's please not go down this avenue in any form. From owner-namedroppers@ops.ietf.org Mon Aug 30 17:07: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 21BFE3A68BB; Mon, 30 Aug 2010 17:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.341 X-Spam-Level: X-Spam-Status: No, score=-101.341 tagged_above=-999 required=5 tests=[AWL=1.258, 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 39r9BbjmuvWE; Mon, 30 Aug 2010 17:07:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1AC333A68B1; Mon, 30 Aug 2010 17:07:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqEL0-000Fjb-EG for namedroppers-data0@psg.com; Tue, 31 Aug 2010 00:04:30 +0000 Received: from hoffman.proper.com ([207.182.41.81]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqEKt-000FhH-SV for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 00:04:24 +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 o7V04B3c015425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Aug 2010 17:04:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <60220.1283211506@nsa.vix.com> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <5831A1FCBAF9396EF92D3914@nimrod.local> <49228.1283199781@nsa.vix.com> <232890023F1F44341FAD59F5@nimrod.local> <60220.1283211506@nsa.vix.com> Date: Mon, 30 Aug 2010 17:04:10 -0700 To: Paul Vixie , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") 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 11:38 PM +0000 8/30/10, Paul Vixie wrote: >i think ICANN has been pretty clear about why it wants this stuff. why it wants != requirements If you think ICANN has been pretty clear about its requirements, a URL would be handy. An ICANN staffer speaking up would be even more useful. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Mon Aug 30 17: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 28EDF3A68B1; Mon, 30 Aug 2010 17:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.516, 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 ZAuQ4eiO1RS0; Mon, 30 Aug 2010 17:08:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 902233A68BB; Mon, 30 Aug 2010 17:08:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqEMr-000Frz-C9 for namedroppers-data0@psg.com; Tue, 31 Aug 2010 00:06:25 +0000 Received: from mail-iw0-f180.google.com ([209.85.214.180]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqEMj-000Fra-1C for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 00:06:18 +0000 Received: by iwn6 with SMTP id 6so7560005iwn.11 for ; Mon, 30 Aug 2010 17:06:16 -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=TIi3hFr7y2xDAUeZkIs+S0dPPQbI8HHOUp5Mtzdv+rI=; b=nlo5d2+tm8ExTK1kELOXJUzhVUQ6HG95T4vqXemoOwzfvCWOtT51dKqSPEbwLbNqLI BtmYiN5yC5Fh0gi+VSeM0waq5jIs1RhjGq9z4d0VJf/PtrJ4rYh6rxv+SufbJUIY4Lcp bC38Mheus5bpfeQZ3KKLUxmwivG2vSrHAtExU= 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=sF9Iy4xJZauSubTesOS8M6yPKfNhCgKu5IJvNx44zKtslRGofW9HfJ/Juk3+GgBrDu X7+U6k5s7VRdVXG5KpQayFfbWxMlRlVuuQ3oP3EDUsPXNxntqAo6jJlCAcI9SGMME16m x3HdFxRLMe+bsq5Z5lOX24nfSOn37Jt4Pbj+U= MIME-Version: 1.0 Received: by 10.231.174.84 with SMTP id s20mr5831120ibz.94.1283213176531; Mon, 30 Aug 2010 17:06:16 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Mon, 30 Aug 2010 17:06:16 -0700 (PDT) In-Reply-To: <49228.1283199781@nsa.vix.com> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <5831A1FCBAF9396EF92D3914@nimrod.local> <49228.1283199781@nsa.vix.com> Date: Mon, 30 Aug 2010 20:06:16 -0400 Message-ID: Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") From: Phillip Hallam-Baker 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 Mon, Aug 30, 2010 at 4:23 PM, Paul Vixie wrote: >> Date: Mon, 30 Aug 2010 20:19:18 +0100 >> From: Alex Bligh >> ... >> Or, is what you are saying, that if ICANN proposes a technical solution >> for a political problem, and says jump, we should merely ask how high? > > neither. =A0i'm saying that the DNS is not just a technological device, i= t > is also extant as an economic and political device. =A0the root and its T= LDs > have always been handled differently than private domains. =A0we've alrea= dy > pulled DNSSEC off the rails once for TLD's (see 5155) and once for the ro= ot > (see RFC 5011) so i'm just not ready to hear that we won't take real worl= d > needs into account when doing our engineering. You forget that some of us actually watched that process and were participants therein. This group ignored the practical realities for five years before finally accepting that ignoring them would not make them go away. In 2002 I stated that if OPTIN was accepted that DNSSEC would deploy in .com, otherwise it would not. Everyone decided to call my bluff and the moment was lost. I wasn't bluffing. It has taken eight years to get back to that point. > it's not the only reason. =A0and when i proposed SHADOW i had other uses = in > mind, such as the symmetry i'd like to have in the namespaces at VIX.COM, > VIXIE.ORG, VIXIE.SF.CA.US, and maybe others i'm forgetting here. =A0the o= nly > difference is, for me personally, provisioning hacks can also be used. = =A0but > ICANN is not the only entity for whom that's not true. =A0any larger and = more > complex domain holder could want to do multivendor in a way that would ma= ke > the "provisioning hacks" approach really expensive (in TCO terms.) The fact that the provisioning hacks are too expensive does not mean that the alternatives must work or be more practical. Sure we can do a magic pointer approach but it won't work for any people who don't have both an aware DNS resolver and are attempting to contact an aware Web server. So during the introduction period the service will work unpredictably. And that is the worst possible outcome in my view. When it comes to deployment I actually run models. I use simulations. I have a methodology that allows me to identify stakeholders whose cooperation is needed. In short I approach deployment as an engineering problem. What I am seeing from you here Paul is not an engineering approach. It is something else. --=20 Website: http://hallambaker.com/ From owner-namedroppers@ops.ietf.org Mon Aug 30 17:28: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 835243A68C5; Mon, 30 Aug 2010 17:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fE4pO39ANQ2; Mon, 30 Aug 2010 17:28:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62C003A68C0; Mon, 30 Aug 2010 17:28:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqEes-000IJw-Ks for namedroppers-data0@psg.com; Tue, 31 Aug 2010 00:25:04 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqEel-000IJM-Eb for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 00:24:55 +0000 Received: (qmail 76367 invoked from network); 31 Aug 2010 00:29:11 -0000 Received: from softbank219178199025.bbtec.net (HELO ?192.168.11.11?) (219.178.199.25) by necom830.hpcl.titech.ac.jp with SMTP; 31 Aug 2010 00:29:11 -0000 Message-ID: <4C7C49FB.1050605@necom830.hpcl.titech.ac.jp> Date: Tue, 31 Aug 2010 09:16:59 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> In-Reply-To: <34484.1283184615@nsa.vix.com> Content-Type: text/plain; charset=ISO-2022-JP 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: Paul Vixie wrote: > ICANN's regulatory regime (such as it is) makes adding "new tld's" difficult. > it is very hard to create a new IDN TLD which isn't synchronized to a current > one since this would run afoul of competitive issues ("why does CNNIC get so > many TLD's and my national name registry get so few?") and also commercial > issues ("you're calling that an IDN TLD but it is basically another .COM for > a specific language and has no relation to any ISO3166 TLD's namespace.") What's wrong with CN. NS ... CN0. DNAME CN. CN1. DNAME CN. CN2. DNAME CN. CN3. DNAME CN. . . . in the root zone? If you also need "CN?" have RRs other than DNAME, let ICANN arrange so. Same RRs in different "CN?"s can be same or different according to the policy of ICANN. Masataka Ohta PS I'm tired of the boring attempt to modify DNS protocol only to combine useless DNSSEC and useless IDN. From owner-namedroppers@ops.ietf.org Mon Aug 30 19:55: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 5DF783A6860; Mon, 30 Aug 2010 19:55:41 -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: -99.1 X-Spam-Level: X-Spam-Status: No, score=-99.1 tagged_above=-999 required=5 tests=[AWL=0.902, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 vpgP8rOn253F; Mon, 30 Aug 2010 19:55:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 367FE3A63C9; Mon, 30 Aug 2010 19:55:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqGu4-000B23-Fu for namedroppers-data0@psg.com; Tue, 31 Aug 2010 02:48:52 +0000 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqGtx-000B1X-Ji for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 02:48:45 +0000 Received: (eyou send program); Tue, 31 Aug 2010 10:48:43 +0800 Message-ID: <483222923.22085@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, 31 Aug 2010 10:48:43 +0800 Message-ID: <95D38339FC4643B99DDA480DD12719EF@LENOVO47E041CF> From: "Jiankang YAO" To: "Alex Bligh" , "Stephane Bortzmeyer" Cc: , "Alex Bligh" References: <483158956.02282@cnnic.cn> <483160052.08202@cnnic.cn> <483161548.08201@cnnic.cn> Subject: Re: [dnsext] Re: DNSEXT charter and treating DNS names as "the same" Date: Tue, 31 Aug 2010 10:48:50 +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.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsZXggQmxpZ2giIDxhbGV4 QGFsZXgub3JnLnVrPg0KVG86ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj47ICJTdGVw aGFuZSBCb3J0em1leWVyIiA8Ym9ydHptZXllckBuaWMuZnI+DQpDYzogPG5hbWVkcm9wcGVyc0Bv cHMuaWV0Zi5vcmc+OyAiQWxleCBCbGlnaCIgPGFsZXhAYWxleC5vcmcudWs+DQpTZW50OiBNb25k YXksIEF1Z3VzdCAzMCwgMjAxMCA1OjQ1IFBNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gUmU6IERO U0VYVCBjaGFydGVyIGFuZCB0cmVhdGluZyBETlMgbmFtZXMgYXMgInRoZSBzYW1lIg0KDQoNCj4g DQo+IA0KPiAtLU9uIDMwIEF1Z3VzdCAyMDEwIDE3OjIwOjU3ICswODAwIEppYW5rYW5nIFlBTyA8 eWFvamtAY25uaWMuY24+IHdyb3RlOg0KPiANCj4+PiBVbmxlc3MgeW91IGNsYWltIHRoYXQgKmV2 ZXJ5KiBJRE4gVExEIHJlcXVpcmUgc3luY2hyb25pemF0aW9uIG9mDQo+Pj4gY29udGVudCAoc29t ZXRoaW5nIHRoYXQgbm90IGV2ZXJ5b25lIHdpbGwgYWdyZWUgd2l0aCkgKmFuZCogdGhhdCB0aGlz DQo+Pj4gc3luY2hyb25pemF0aW9uIHJlcXVpcmVzIGEgbm9uLXByb3Zpc2lvbmluZyBtZXRob2Qg dG8gYmUgZG9uZSwNCj4+PiBzb21ldGhpbmcgdGhhdCB5b3Ugb2Z0ZW4gcmVwZWF0IGJ1dCB3aGlj aCBpcyBub3QgdHJ1ZS4NCj4+DQo+PiBJIGNhbiBub3QgcHJvdmUgdGhhdCBldmVyeSBJRE4gVExE IG5lZWQgaXQuDQo+PiBidXQgc29tZSBJRE4gVExEIGFuZCBzZWNvbmQgbGV2ZWwgSUROIGRvbWFp biBuYW1lcyBuZWVkIGl0Lg0KPiANCj4gKldoeSogZG8gdGhlc2UgVExEcyBuZWVkIFhOQU1FIGFz IG9wcG9zZWQgdG8gdGhlIHByb3Zpc2lvbmluZyBtZXRob2Q/DQo+IA0KPiBMZXQgdXMgYXNzdW1l IHRoZSBwcm92aXNpb25pbmcgbWV0aG9kIG1lYW5zIHN5bmNocm9uaXplZCBlbnRyaWVzIG1vdmUN Cj4gdG9nZXRoZXIgYmV0d2VlbiByZWdpc3RyYW50cyBldGMuIFRoZSBvbmx5IHRoaW5nIFhOQU1F IGdpdmVzIHlvdSBiZXlvbmQgdGhlDQo+IHByb3Zpc2lvbmluZyBtZXRob2QgQUZBSUNTIGlzIGVu c3VyaW5nIHRoZSB0cmVlIGJlbG93IHRoZSBkZWxlZ2F0aW9uIHBvaW50DQo+IGlzIGFsc28gc3lu Y2hyb25pemVkLCB3aGljaCBpcyAoaW4gc29tZSBjaXJjdW1zdGFuY2VzKSBkaXNhZHZhbnRhZ2Vv dXMgaW4NCj4gbWFraW5nIHRoZSBhcHBsaWNhdGlvbnMgcGVyZm9ybSBzaW1pbGFybHkgKGFzIGRl bW9uc3RyYXRlZCBzZXZlcmFsIHRpbWVzKS4NCj4NCg0KaWYgeW91IHRhbGsgYWJvdXQgc3luY2hy b25pemVkIGVudHJpZXMgb3Igc3luY2hyb25pemVkIG5hbWVzLCBpdCBtZWFucyB0aGF0IHlvdSBo YXZlIHRvIG1ha2UgaWVzZWxmIGFuZCBpdHMgY2hpbGRyZW5zIGdldCB0aGUgc2FtZSBETlMgcmVz b2x1dGlvbi4NCnRoYXQgaXMgYWxzbyB3aGF0IHRoZSBzeW5jaHJvbml6ZWQgbmFtZXMgbWVhbi4N Cg0KPg0KPg0KPiBTbyB3aGF0IGlzIHRoZSAvYWR2YW50YWdlLyBvZiBYTkFNRSBvdmVyIHByb3Zp c2lvbmluZywgZ2l2ZW4gaXRzIHRyaXZpYWwNCj4gdG8gZGVtb25zdHJhdGUgcHJvdmlzaW9uaW5n IGlzIGNhcGFibGUgb2YgZG9pbmcgdGhlIHNhbWUgdGhpbmcgYW5kIGlzDQo+IG1vcmUgZmxleGli bGUgd2hlbiAndGhlIHNhbWUgdGhpbmcnIGlzIHNvbWV0aW1lcyB3cm9uZz8NCj4gDQoNCnByb3Zp c2lvbiBtYXkgbWFrZSB0aGUgbmFtZXMgaW4gb25lIHpvbmUgd29yaywgYnV0IG1heSBub3QgbWFr ZSBpdHMgY2hpbGRlcm4gem9uZSB3b3JrLg0KDQoNCkkgdGhpbmsgdGhhdCB3ZSBzaG91bGQgYmUg Y2xlYXIgYWJvdXQgb25lIHBvaW50IHdlIGRpc2N1c3NlZCBiZWZvcmU6DQoNClRoZSBxdWVzdGlv biBpcyBub3Qgd2hldGhlciBBIGFuZCBCIGFyZSB0aGUgc2FtZS4gSXQgaXMgIlJlc29sdmluZyBB IGFuZCBCIGxlYWRzIHRvIHRoZSBzYW1lIGRucyByZXNvbHV0aW9uIHJlc3VsdCIuDQoNCmlmIHlv dSBkbyBub3Qgd2FudCB0byAiUmVzb2x2aW5nIEEgYW5kIEIgbGVhZHMgdG8gdGhlIHNhbWUgZG5z IHJlc29sdXRpb24gcmVzdWx0IiwgdGhlbiB0aGUgcHJvdmlzaW9uIHdvcmtzLCB5b3UgbWF5IGNo b29zZSBwcm92aXNpb24uDQoNCmJ1dCBpZiB3ZSB3YW50IHRvICIiUmVzb2x2aW5nIEEgYW5kIEIg bGVhZHMgdG8gdGhlIHNhbWUgZG5zIHJlc29sdXRpb24gcmVzdWx0IiIsIHRoZW4gdGhlIHByb3Zp c2lvbiBkb2VzIG5vdCB3b3JrLCB3ZSBjYW4gbm90IGNob29zZSBwcm92aXNpb24gYW5kIG1heSBj aG9vc2UgWE5BTUUuDQoNCg0KSmlhbmthbmcgWWFvDQoNCg0KDQoNCg0KDQo+DQo+IC0tIA0KPiBB bGV4IEJsaWdo From owner-namedroppers@ops.ietf.org Mon Aug 30 20:19: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 2B19D3A687A; Mon, 30 Aug 2010 20:19:24 -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: -99.112 X-Spam-Level: X-Spam-Status: No, score=-99.112 tagged_above=-999 required=5 tests=[AWL=0.890, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 b6LwMf8N1zYg; Mon, 30 Aug 2010 20:19:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 035553A6452; Mon, 30 Aug 2010 20:19:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqHKs-000FTb-2s for namedroppers-data0@psg.com; Tue, 31 Aug 2010 03:16:34 +0000 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqHKl-000FT2-DI for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 03:16:27 +0000 Received: (eyou send program); Tue, 31 Aug 2010 11:16:26 +0800 Message-ID: <483224586.22087@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, 31 Aug 2010 11:16:26 +0800 Message-ID: <2A3F0F738A644468A1F885CC1DF421F8@LENOVO47E041CF> From: "Jiankang YAO" To: "Paul Vixie" , , "Paul Hoffman" References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <5831A1FCBAF9396EF92D3914@nimrod.local> <49228.1283199781@nsa.vix.com> <232890023F1F44341FAD59F5@nimrod.local> <60220.1283211506@nsa.vix.com> <483213682.08432@cnnic.cn> Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Date: Tue, 31 Aug 2010 11:16:32 +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.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBhdWwgSG9mZm1hbiIgPHBh dWwuaG9mZm1hbkB2cG5jLm9yZz4NClRvOiAiUGF1bCBWaXhpZSIgPHZpeGllQGlzYy5vcmc+OyA8 bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAzMSwgMjAx MCA4OjA0IEFNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gcmVndWxhdG9yeSBwcm9ibGVtIHN0YXRl bWVudCAod2FzIFJlOiAuLi4gYXMgInRoZSBzYW1lIikNCg0KDQo+IEF0IDExOjM4IFBNICswMDAw IDgvMzAvMTAsIFBhdWwgVml4aWUgd3JvdGU6DQo+PmkgdGhpbmsgSUNBTk4gaGFzIGJlZW4gcHJl dHR5IGNsZWFyIGFib3V0IHdoeSBpdCB3YW50cyB0aGlzIHN0dWZmLg0KPiANCj4gd2h5IGl0IHdh bnRzICE9IHJlcXVpcmVtZW50cw0KPiANCj4gSWYgeW91IHRoaW5rIElDQU5OIGhhcyBiZWVuIHBy ZXR0eSBjbGVhciBhYm91dCBpdHMgcmVxdWlyZW1lbnRzLCBhIFVSTCB3b3VsZCBiZSBoYW5keS4g QW4gSUNBTk4gc3RhZmZlciBzcGVha2luZyB1cCB3b3VsZCBiZSBldmVuIG1vcmUgdXNlZnVsLg0K PiANCg0KVGluYSBmcm9tIElDQU5OIGhhcyBhIHJlcG9ydCBpbiBCcnVzc2VscyBtZWV0aW5nLiB0 aGlzIG1heSBoZWxwIHVzIHRvIHVuZGVyc3RhbmQgaXQuDQoNCmh0dHBzOi8vYnJ1c3NlbHMzOC5p Y2Fubi5vcmcvbWVldGluZ3MvYnJ1c3NlbHMyMDEwL3ByZXNlbnRhdGlvbi1pZG5zLWRhbS0yM2p1 bjEwLWVuLnBkZg0KDQphbHNvIHNvbWUgaWRuIHNlZXNzaW9uczoNCmh0dHBzOi8vYnJ1c3NlbHMz OC5pY2Fubi5vcmcvbm9kZS8xMjY4Mw0KDQpodHRwczovL2JydXNzZWxzMzguaWNhbm4ub3JnL2Z1 bGwtc2NoZWR1bGUNCg0KDQoNCj4NCj4gLS1QYXVsIEhvZmZtYW4sIERpcmVjdG9yDQo+IC0tVlBO IENvbnNvcnRpdW0NCj4= From owner-namedroppers@ops.ietf.org Mon Aug 30 20:38: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 B89C73A6894; Mon, 30 Aug 2010 20:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 qJTCbrGFqMGG; Mon, 30 Aug 2010 20:38:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5CCD43A659B; Mon, 30 Aug 2010 20:38:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqHch-000ICH-4q for namedroppers-data0@psg.com; Tue, 31 Aug 2010 03:34:59 +0000 Received: from trantor.virtualized.org ([204.152.189.190] helo=virtualized.org) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqHca-000IBj-NW for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 03:34:52 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 32E25DF81E3; Mon, 30 Aug 2010 20:34:51 -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 Xk+1szQ6njul; Mon, 30 Aug 2010 20:34:49 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 270DDDF81C6; Mon, 30 Aug 2010 20:34:49 -0700 (PDT) Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Mon, 30 Aug 2010 20:34:48 -0700 Cc: namedroppers WG Content-Transfer-Encoding: quoted-printable Message-Id: <091622CE-4DBE-4707-A274-2F9F2A46FF32@virtualized.org> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <5831A1FCBAF9396EF92D3914@nimrod.local> <49228.1283199781@nsa.vix.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 30, 2010, at 3:01 PM, Paul Hoffman wrote: > It feels like you are describing the constraints that some parts of = that hive feels, but certainly not all. My impression is that the specific problem affects a relatively small = number of participants of the ICANN collective. It's not that the other = parts of the collective disagree with the constraints, it is more that = the other parts don't (yet?) have the itch that the xNAME/SHADOW/etc. = are proposed to scratch. That is, folks in China and Greece (to my knowledge) have said "hey, = there's a problem here" because they're facing that problem now. As = more IDNs get deployed, it's possible/likely/certain others will see the = same problem. > If it was all parts, then ICANN would not now be putting into the root = TLDs that "require" synchronization. The synchronization approach was (in my personal opinion) an egregious = hack that was necessitated to address non-technical considerations and = was done so with the (perhaps mistaken) assumption that the IETF would = be providing a less egregious hack to deal with the more generic problem = of "the same". The fact that synchronization is required in (some of) the IDNs that are = being inserted into the root now has no relation to whether all of ICANN = believes a DNS protocol-based solution is desired. > That synchronization is not happening, which proves that the = requirement is mislabeled. (Corrections from ICANN staff are welcomed = here.) Not ICANN staff, but... I wasn't aware that synchronization wasn't happening. I believe the = issue is that synchronization is (was assumed to be) a _temporary_ hack = until a better solution came along and as such, the fact that it is = going to be _really_ hard to ensure that all levels of names in a = synchronized set are "the same" could be dealt with while people were = waiting. However, I am far from authoritative on this. Regards, -drc From owner-namedroppers@ops.ietf.org Mon Aug 30 20:43: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 8FEB53A68EA; Mon, 30 Aug 2010 20:43:48 -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: -98.504 X-Spam-Level: X-Spam-Status: No, score=-98.504 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, SARE_LWSHORTT=1.24, 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 AlG8Nu5uNvGm; Mon, 30 Aug 2010 20:43:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 454E93A68C7; Mon, 30 Aug 2010 20:43:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqHim-000JPR-P2 for namedroppers-data0@psg.com; Tue, 31 Aug 2010 03:41:16 +0000 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqHif-000JMi-Tl for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 03:41:10 +0000 Received: (eyou send program); Tue, 31 Aug 2010 11:41:05 +0800 Message-ID: <483226065.22084@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, 31 Aug 2010 11:41:05 +0800 Message-ID: <535EA9D909F740B6A2EF59E77AA12441@LENOVO47E041CF> From: "Jiankang YAO" To: "Andrew Sullivan" , References: <483158956.02282@cnnic.cn> <328DCC4D8C7C45A1A31B5759A3C9442C@LENOVO47E041CF> <20100830224638.GG24538@shinkuro.com> Subject: Re: [dnsext] Re: DNSEXT charter and treating DNS names as "thesame" Date: Tue, 31 Aug 2010 11:41:11 +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.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 OiBUdWVzZGF5LCBBdWd1c3QgMzEsIDIwMTAgNjo0NiBBTQ0KU3ViamVjdDogUmU6IFtkbnNleHRd IFJlOiBETlNFWFQgY2hhcnRlciBhbmQgdHJlYXRpbmcgRE5TIG5hbWVzIGFzICJ0aGVzYW1lIg0K DQoNCj4gT24gTW9uLCBBdWcgMzAsIDIwMTAgYXQgMDU6MjA6NTdQTSArMDgwMCwgSmlhbmthbmcg WUFPIHdyb3RlOg0KPj4gDQo+PiB0aGVyZSBpcyBhIGNoYXJhY3RlciB2YXJpYW50IGdyb3VwIGlu IElDQU5OLCB3aGljaCBmb2N1cyBvbiBkaXNjdXNzaW9uIG9mIHRoZSB2YXJpYW50IGNoYXJhY3Rl cnMgZnJvbSBkaWZmZXJlbnQgbGFuZ3VhZ2VzLg0KPj4gDQo+IA0KPiBHb29kLiAgSSB3b3VsZCBs aWtlIGZvciB0aGVtIHRvIGV4cGxhaW4gd2hhdCBwcm9ibGVtcyB0aGV5IHRoaW5rIHRoZXkNCj4g aGF2ZSwgYW5kIHdoeSB0aGV5IHRoaW5rIHRob3NlIHByb2JsZW1zIGNhbiBiZSBzb2x2ZWQgYnkg Y2hhbmdlcyB0bw0KPiB0aGUgRE5TLiAgDQo+DQoNCnRoZXkgZG8gbm90IHNheSB0aGF0IHdlIG11 c3QgY2hhbmdlIHRoZSBkbnMuIHRoZXkgZmVlbCB0aGF0IHRoZSBwcm92aXNpb24gaXMganVzdCBh IHNob3J0IHRlcm0gc2xvdXRpb24sIG5vdCBhbiBpZGVhbCBzb2x1dGlvbi4NCg0KeW91IG1heSB0 YWtlIGEgbG9vayBhdCB0aGUgZm9sbG93aW5nIGxpbms6DQoNClRpbmEgZnJvbSBJQ0FOTiBoYXMg YSByZXBvcnQgaW4gQnJ1c3NlbHMgbWVldGluZy4gdGhpcyBtYXkgaGVscCB1cyB0byB1bmRlcnN0 YW5kIGl0Lg0KDQpodHRwczovL2JydXNzZWxzMzguaWNhbm4ub3JnL21lZXRpbmdzL2JydXNzZWxz MjAxMC9wcmVzZW50YXRpb24taWRucy1kYW0tMjNqdW4xMC1lbi5wZGYNCg0KYWxzbyBzb21lIGlk biBzZWVzc2lvbnM6DQpodHRwczovL2JydXNzZWxzMzguaWNhbm4ub3JnL25vZGUvMTI2ODMNCg0K aHR0cHM6Ly9icnVzc2VsczM4LmljYW5uLm9yZy9mdWxsLXNjaGVkdWxlDQoNCkkgdGhpbmsgVGlu YSBmcm9tIElDQU5OIGlzIGFsc28gb24gdGhlIGxpc3QuIFNoZSBtYXkgZ2l2ZSB1cyBtb3JlIGRv Y3VtZW50cyBvciBsaW5rcyBvciBjb21tZW50cyBzaW5jZSB0aGVyZSBhcmUgbWFueSBJRE4gcmVs YXRlZCB3b3JraW5nIGdyb3VwcyBpbiBJQ0FOTi4NCg0KDQpKaWFua2FuZyBZYW8NCg0KDQoNCj4N Cj5JIHdvdWxkIGxpa2UgdGhvc2UgZXhwbGFuYXRpb25zIHRvIHRha2UgdGhlIGZvcm0gb2YgdGV4 dHVhbA0KPiBjb250cmlidXRpb25zIHRvIHRoZSBXRyBmb3IgaW5jbHVzaW9uIGluIHNvbWUgcmVx dWlyZW1lbnRzIHN0YXRlbWVudC4NCj4gV2UndmUgYWxyZWFkeSBoZWxkIHR3byBtYWpvciBzZXNz aW9ucyBvbiB0aGlzIHRvcGljIGF0IElFVEYgbWVldGluZ3MsDQo+IGFuZCB3aXRoIGxpbWl0ZWQg KGJ1dCBpbXBvcnRhbnQpIGV4Y2VwdGlvbnMgd2UndmUgaGFkIG5vdCB0b28gbXVjaA0KPiBpbnB1 dCBmcm9tIElDQU5OIGNoYXJhY3RlciB2YXJpYW50IGdyb3VwIHBhcnRpY2lwYW50cy4NCj4gDQo+ IEENCj4gDQo+IC0tIA0KPiBBbmRyZXcgU3VsbGl2YW4NCj4gYWpzQHNoaW5rdXJvLmNvbQ0KPiBT aGlua3VybywgSW5jLg0KPg== From owner-namedroppers@ops.ietf.org Mon Aug 30 20:53: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 3BA0E3A68C5; Mon, 30 Aug 2010 20:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 C01BJxnDDWXn; Mon, 30 Aug 2010 20:53:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F1CE83A6860; Mon, 30 Aug 2010 20:53:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqHrQ-000Kry-P2 for namedroppers-data0@psg.com; Tue, 31 Aug 2010 03:50:12 +0000 Received: from trantor.virtualized.org ([204.152.189.190] helo=virtualized.org) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqHrJ-000KjJ-BB for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 03:50:06 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 2F61BDF83B4; Mon, 30 Aug 2010 20:50:03 -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 adHQ8-iZfT7f; Mon, 30 Aug 2010 20:50:01 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id F1E52DF83A6; Mon, 30 Aug 2010 20:49:56 -0700 (PDT) Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20100830224251.GF24538@shinkuro.com> Date: Mon, 30 Aug 2010 20:49:49 -0700 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <06D5B425-2292-4809-9A03-EBDC7C16682A@virtualized.org> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <20100830224251.GF24538@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 30, 2010, at 3:42 PM, Andrew Sullivan wrote: > Where exactly is ICANN's problem statement? As one of the chairs who = needs to agree to herd this work through the IETF, I'd like to see it. An understandable request. While not "ICANN's problem statement", I = gather you do not believe = http://tools.ietf.org/html/draft-yao-dnsext-identical-resolution-00 is = sufficient? > The only actual evidence we have from ICANN is that they _can_ do what = they thought the synchronization stuff would achieve with provisioning, = because in fact they already have. I believe the concern is that this is analogous to the person who fell = off the Empire State building being heard to say "So far, so good" as he = passed each floor on the way down... Regards, -drc From owner-namedroppers@ops.ietf.org Mon Aug 30 21:27: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 DC0AA3A68C7; Mon, 30 Aug 2010 21:27:16 -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 zJU6Ps762X-P; Mon, 30 Aug 2010 21:27:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 864F13A672F; Mon, 30 Aug 2010 21:27:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqINt-000Peq-Sy for namedroppers-data0@psg.com; Tue, 31 Aug 2010 04:23:45 +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.72 (FreeBSD)) (envelope-from ) id 1OqINo-000PeX-12 for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 04:23:40 +0000 Received: from [199.212.90.26] (helo=dh26.r1.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OqINY-000Pb2-Ik; Tue, 31 Aug 2010 04:23:25 +0000 Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <4C7C49FB.1050605@necom830.hpcl.titech.ac.jp> Date: Tue, 31 Aug 2010 00:23:23 -0400 Cc: Paul Vixie , namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4217F5EE-3F03-4935-8CA3-F59A568C46E6@hopcount.ca> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <4C7C49FB.1050605@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1081) X-SA-Exim-Connect-IP: 199.212.90.26 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-08-30, at 20:16, Masataka Ohta wrote: > What's wrong with >=20 > CN. NS ... > CN0. DNAME CN. > CN1. DNAME CN. > CN2. DNAME CN. > CN3. DNAME CN. > . > . > . >=20 > in the root zone? Good question. Part of the reason this thread continues to spiral around the plughole = is that I don't believe anybody has taken the time to ask that question = and others like it of non-technical policy people in a form they could = understand. I think a survey of existing mechanisms which could provide = equivalence-type functionality (e.g. for registry operators and for end = users) together with a clear description of the pros and cons of each = would be really quite useful to guide policymakers. While we're at it, a = clear indication that we might need to wait decades before certain = classes of solution are ready to use might also come in handy (e.g. = approaches that require changes to resolver behaviour). You never know, = the result might be policy that is actually implementable. I have a suspicion that to date the policy that is driving the noise we = are hearing assumes that the technical problem space is unconstrained, = which I think we believe (if we speak with one voice about anything) not = to be true. Joe From owner-namedroppers@ops.ietf.org Mon Aug 30 21:40: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 566CC3A68F3; Mon, 30 Aug 2010 21:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 G6YFFN6xXHAr; Mon, 30 Aug 2010 21:40:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4934D3A68F6; Mon, 30 Aug 2010 21:40:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqIb7-0001bX-HZ for namedroppers-data0@psg.com; Tue, 31 Aug 2010 04:37:25 +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.72 (FreeBSD)) (envelope-from ) id 1OqIb1-0001au-TR for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 04:37:20 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A1B83A1031 for ; Tue, 31 Aug 2010 04:37:17 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") In-Reply-To: Your message of "Mon, 30 Aug 2010 20:06:16 -0400." References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <5831A1FCBAF9396EF92D3914@nimrod.local> <49228.1283199781@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Tue, 31 Aug 2010 04:37:17 +0000 Message-ID: <79210.1283229437@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, 30 Aug 2010 20:06:16 -0400 > From: Phillip Hallam-Baker > > You forget that some of us actually watched that process and were > participants therein. i didn't forget. i was there, and i was disgusted with the way that the community ignored the clear need for opt-in. you, sir, deserved better treatment than you got. and you were later proved right when several CCTLD operators said "without opt-in there will be no DNSSEC in my CC". > When it comes to deployment I actually run models. I use simulations. I > have a methodology that allows me to identify stakeholders whose > cooperation is needed. In short I approach deployment as an engineering > problem. kewl. > What I am seeing from you here Paul is not an engineering approach. It is > something else. that's off topic so i won't ask for details nor offer any reply to it. From owner-namedroppers@ops.ietf.org Mon Aug 30 21:40: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 ED0463A68BC; Mon, 30 Aug 2010 21:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.215, 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 OxjniCDt4BT5; Mon, 30 Aug 2010 21:40:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 492D23A68C7; Mon, 30 Aug 2010 21:40:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqIb4-0001bI-86 for namedroppers-data0@psg.com; Tue, 31 Aug 2010 04:37:22 +0000 Received: from mx.pao1.isc.org ([2001:4f8:0:2::2b]) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqIay-0001af-3z for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 04:37:16 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id C7FDAC94EB; Tue, 31 Aug 2010 04:37:13 +0000 (UTC) (envelope-from woolf@isc.org) Received: by farside.isc.org (Postfix, from userid 10265) id 9CAA9E6032; Tue, 31 Aug 2010 04:37:13 +0000 (UTC) Date: Tue, 31 Aug 2010 04:37:13 +0000 From: Suzanne Woolf To: Joe Abley Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Message-ID: <20100831043713.GA23493@farside.isc.org> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <4C7C49FB.1050605@necom830.hpcl.titech.ac.jp> <4217F5EE-3F03-4935-8CA3-F59A568C46E6@hopcount.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4217F5EE-3F03-4935-8CA3-F59A568C46E6@hopcount.ca> 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 Tue, Aug 31, 2010 at 12:23:23AM -0400, Joe Abley wrote: > I think a survey of existing mechanisms which could provide > equivalence-type functionality (e.g. for registry operators and for > end users) together with a clear description of the pros and cons of > each would be really quite useful to guide policymakers. While we're > at it, a clear indication that we might need to wait decades before > certain classes of solution are ready to use might also come in > handy (e.g. approaches that require changes to resolver > behaviour). You never know, the result might be policy that is > actually implementable. That document is under construction. Feel free to send text. (That sounds flippant. It's not.) > I have a suspicion that to date the policy that is driving the noise > we are hearing assumes that the technical problem space is > unconstrained, which I think we believe (if we speak with one voice > about anything) not to be true. Yep. And now we get to characterize the constraints in a way that non-technical people will understand. Which is actually a manageable task, and a problem statement that's coherent to us is a good step. thanks, Suzanne From owner-namedroppers@ops.ietf.org Mon Aug 30 22: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 6064A3A68E9; Mon, 30 Aug 2010 22:25:32 -0700 (PDT) X-Quarantine-ID: <6R62fatMvaF8> 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: -99.128 X-Spam-Level: X-Spam-Status: No, score=-99.128 tagged_above=-999 required=5 tests=[AWL=0.874, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 6R62fatMvaF8; Mon, 30 Aug 2010 22:25:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 94B9A3A680F; Mon, 30 Aug 2010 22:25:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqJGX-0008Lx-Ua for namedroppers-data0@psg.com; Tue, 31 Aug 2010 05:20:13 +0000 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqJGQ-0008Kf-Dn for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 05:20:06 +0000 Received: (eyou send program); Tue, 31 Aug 2010 13:20:05 +0800 Message-ID: <483232005.15063@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, 31 Aug 2010 13:20:05 +0800 Message-ID: <66DB91879CF649BF89F9E3F068BD7D9A@LENOVO47E041CF> From: "Jiankang YAO" To: "Masataka Ohta" , "Paul Vixie" Cc: References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <483215030.00496@cnnic.cn> Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Date: Tue, 31 Aug 2010 13:20:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hc2F0YWthIE9odGEiIDxt b2h0YUBuZWNvbTgzMC5ocGNsLnRpdGVjaC5hYy5qcD4NClRvOiAiUGF1bCBWaXhpZSIgPHZpeGll QGlzYy5vcmc+DQpDYzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5 LCBBdWd1c3QgMzEsIDIwMTAgODoxNiBBTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIHJlZ3VsYXRv cnkgcHJvYmxlbSBzdGF0ZW1lbnQgKHdhcyBSZTogLi4uIGFzICJ0aGUgc2FtZSIpDQoNCg0KPiBQ YXVsIFZpeGllIHdyb3RlOg0KPiANCj4+IElDQU5OJ3MgcmVndWxhdG9yeSByZWdpbWUgKHN1Y2gg YXMgaXQgaXMpIG1ha2VzIGFkZGluZyAibmV3IHRsZCdzIiBkaWZmaWN1bHQuDQo+PiBpdCBpcyB2 ZXJ5IGhhcmQgdG8gY3JlYXRlIGEgbmV3IElETiBUTEQgd2hpY2ggaXNuJ3Qgc3luY2hyb25pemVk IHRvIGEgY3VycmVudA0KPj4gb25lIHNpbmNlIHRoaXMgd291bGQgcnVuIGFmb3VsIG9mIGNvbXBl dGl0aXZlIGlzc3VlcyAoIndoeSBkb2VzIENOTklDIGdldCBzbw0KPj4gbWFueSBUTEQncyBhbmQg bXkgbmF0aW9uYWwgbmFtZSByZWdpc3RyeSBnZXQgc28gZmV3PyIpIGFuZCBhbHNvIGNvbW1lcmNp YWwNCj4+IGlzc3VlcyAoInlvdSdyZSBjYWxsaW5nIHRoYXQgYW4gSUROIFRMRCBidXQgaXQgaXMg YmFzaWNhbGx5IGFub3RoZXIgLkNPTSBmb3INCj4+IGEgc3BlY2lmaWMgbGFuZ3VhZ2UgYW5kIGhh cyBubyByZWxhdGlvbiB0byBhbnkgSVNPMzE2NiBUTEQncyBuYW1lc3BhY2UuIikNCj4gDQo+IFdo YXQncyB3cm9uZyB3aXRoDQo+IA0KPiBDTi4gTlMgLi4uDQo+IENOMC4gRE5BTUUgQ04uDQo+IENO MS4gRE5BTUUgQ04uDQo+IENOMi4gRE5BTUUgQ04uDQo+IENOMy4gRE5BTUUgQ04uDQo+ICAgLg0K PiAgIC4NCj4gICAuDQo+IA0KPiBpbiB0aGUgcm9vdCB6b25lPw0KPiANCg0KDQppdCBkb2VzIG5v dCB3cm9uZywgYnV0IGhhcyBzb21lIHByb2JsZW1zLg0KDQp0aGUgcHJvcG9zZWQgc29sdXRpb24g c2hvdWxkIHdvcmsgZm9yIGRpZmZlcmVudCBsZXZlbCBkb21haW4gbmFtZXMuDQoNCnRoaXMgaXNz dWUgaGFzIGJlZW4gZGljdXNzZWQgaW4gdGhpcyBsaXN0IG9yIGRuc29wIGxpc3QgbWFueSB0aW1l cy4NCg0KeW91IG1heSB0YWtlIGEgbG9vayBhdCB0aGUgbWVzc2FnZSBmcm9tIC5nciBmcmllbmQg Og0KDQpodHRwOi8vd3d3Lm9wcy5pZXRmLm9yZy9saXN0cy9uYW1lZHJvcHBlcnMvbmFtZWRyb3Bw ZXJzLjIwMTAvbXNnMDEzMDYuaHRtbCANCg0KDQpKaWFua2FuZyBZYW8NCg0KDQo+DQo+IElmIHlv dSBhbHNvIG5lZWQgIkNOPyIgaGF2ZSBSUnMgb3RoZXIgdGhhbiBETkFNRSwgbGV0IElDQU5OIGFy cmFuZ2UNCj4gc28uIFNhbWUgUlJzIGluIGRpZmZlcmVudCAiQ04/InMgY2FuIGJlIHNhbWUgb3Ig ZGlmZmVyZW50IGFjY29yZGluZw0KPiB0byB0aGUgcG9saWN5IG9mIElDQU5OLg0KPiANCj4gTWFz YXRha2EgT2h0YQ0KPiANCj4gUFMNCj4gDQo+IEknbSB0aXJlZCBvZiB0aGUgYm9yaW5nIGF0dGVt cHQgdG8gbW9kaWZ5IEROUyBwcm90b2NvbCBvbmx5IHRvIGNvbWJpbmUNCj4gdXNlbGVzcyBETlNT RUMgYW5kIHVzZWxlc3MgSUROLg0KPg== From owner-namedroppers@ops.ietf.org Mon Aug 30 22:50: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 9EA953A690A; Mon, 30 Aug 2010 22:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.919 X-Spam-Level: X-Spam-Status: No, score=-9.919 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bSkZ9jv9EgA; Mon, 30 Aug 2010 22:50:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9BE163A690D; Mon, 30 Aug 2010 22:50:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqJgB-000Btw-Mv for namedroppers-data0@psg.com; Tue, 31 Aug 2010 05:46:43 +0000 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqJg5-000Btc-Bx for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 05:46:37 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADI0fExAZnwN/2dsb2JhbACganGiLJtzhTcEigk X-IronPort-AV: E=Sophos;i="4.56,296,1280707200"; d="scan'208";a="153724992" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 31 Aug 2010 05:46:36 +0000 Received: from [192.165.72.14] (ams3-vpn-dhcp7691.cisco.com [10.61.94.10]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7V5kY3n008188; Tue, 31 Aug 2010 05:46:35 GMT Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <06D5B425-2292-4809-9A03-EBDC7C16682A@virtualized.org> Date: Tue, 31 Aug 2010 07:46:33 +0200 Cc: Andrew Sullivan , namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9D49C094-A9BF-4BFD-9402-45555020CDF4@cisco.com> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <20100830224251.GF24538@shinkuro.com> <06D5B425-2292-4809-9A03-EBDC7C16682A@virtualized.org> To: David Conrad X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 31 aug 2010, at 05.49, David Conrad wrote: > Andrew, >=20 > On Aug 30, 2010, at 3:42 PM, Andrew Sullivan wrote: >> Where exactly is ICANN's problem statement? As one of the chairs who = needs to agree to herd this work through the IETF, I'd like to see it. >=20 > An understandable request. While not "ICANN's problem statement", I = gather you do not believe = http://tools.ietf.org/html/draft-yao-dnsext-identical-resolution-00 is = sufficient? I think that is a good start, but it doesn't talk for example on = requirements regarding assignment of delegation to registries, i.e. = requirements on delegations. Something I think ICANN should have a = strong view on as that definitely have impact on regulative situation in = for example many TLDs (i.e. competition regulation). Note: I have not seen ICANN discuss that at all...so I do not think = there are any requirements for such important matters. See the .POST = discussions on how messy things are. Patrik From owner-namedroppers@ops.ietf.org Tue Aug 31 00:13: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 BBE023A690A; Tue, 31 Aug 2010 00:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[AWL=1.459, 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 JEOikMfPKjca; Tue, 31 Aug 2010 00:13:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B92403A68A3; Tue, 31 Aug 2010 00:13:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqKxm-000Nz0-P2 for namedroppers-data0@psg.com; Tue, 31 Aug 2010 07:08:58 +0000 Received: from mail.avalus.com ([89.16.176.221]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqKxf-000NyR-UU for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 07:08:52 +0000 Received: from [195.173.23.106] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id D03BCC56957; Tue, 31 Aug 2010 08:08:48 +0100 (BST) Date: Tue, 31 Aug 2010 08:08:51 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jiankang YAO , Masataka Ohta , Paul Vixie cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Message-ID: <28E42BC4A46898BB40B6474E@nimrod.local> In-Reply-To: <483232005.15063@cnnic.cn> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <483215030.00496@cnnic.cn> <483232005.15063@cnnic.cn> 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 31 August 2010 13:20:11 +0800 Jiankang YAO wrote: > > [DNAME] > > it does not wrong, but has some problems. > > the proposed solution should work for different level domain names. Why? If the problem space is the ICANN non-technically driven one itself, DNAME works fine so long as there are no other records at the zone apex, doesn't it? I'm excluding here for the sake of argument problems arising from the fact a large body of resolvers don't understand DNAME, because an even larger body (100%) don't currently understand XNAME. -- Alex Bligh From owner-namedroppers@ops.ietf.org Tue Aug 31 00:26: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 3E1BB3A68A3; Tue, 31 Aug 2010 00:26:59 -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: -99.151 X-Spam-Level: X-Spam-Status: No, score=-99.151 tagged_above=-999 required=5 tests=[AWL=0.851, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 Uqi08fL1rzSo; Tue, 31 Aug 2010 00:26:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 077333A67CF; Tue, 31 Aug 2010 00:26:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqLBN-0000Gn-Oo for namedroppers-data0@psg.com; Tue, 31 Aug 2010 07:23:01 +0000 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqLBG-0000G4-N5 for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 07:22:55 +0000 Received: (eyou send program); Tue, 31 Aug 2010 15:22:51 +0800 Message-ID: <483239371.31268@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, 31 Aug 2010 15:22:51 +0800 Message-ID: <9739FDDFCEAE4CDA8C702069513FD1D4@LENOVO47E041CF> From: "Jiankang YAO" To: "Alex Bligh" , "Masataka Ohta" , "Paul Vixie" Cc: , "Alex Bligh" References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <483215030.00496@cnnic.cn> <483232005.15063@cnnic.cn> <483238532.02872@cnnic.cn> Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Date: Tue, 31 Aug 2010 15:22:58 +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.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsZXggQmxpZ2giIDxhbGV4 QGFsZXgub3JnLnVrPg0KVG86ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj47ICJNYXNh dGFrYSBPaHRhIiA8bW9odGFAbmVjb204MzAuaHBjbC50aXRlY2guYWMuanA+OyAiUGF1bCBWaXhp ZSIgPHZpeGllQGlzYy5vcmc+DQpDYzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+OyAiQWxl eCBCbGlnaCIgPGFsZXhAYWxleC5vcmcudWs+DQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMzEsIDIw MTAgMzowOCBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIHJlZ3VsYXRvcnkgcHJvYmxlbSBzdGF0 ZW1lbnQgKHdhcyBSZTogLi4uIGFzICJ0aGUgc2FtZSIpDQoNCg0KPiANCj4gDQo+IC0tT24gMzEg QXVndXN0IDIwMTAgMTM6MjA6MTEgKzA4MDAgSmlhbmthbmcgWUFPIDx5YW9qa0Bjbm5pYy5jbj4g d3JvdGU6DQo+IA0KPj4gPiBbRE5BTUVdDQo+Pg0KPj4gaXQgZG9lcyBub3Qgd3JvbmcsIGJ1dCBo YXMgc29tZSBwcm9ibGVtcy4NCj4+DQo+PiB0aGUgcHJvcG9zZWQgc29sdXRpb24gc2hvdWxkIHdv cmsgZm9yIGRpZmZlcmVudCBsZXZlbCBkb21haW4gbmFtZXMuDQo+IA0KPiBXaHk/IElmIHRoZSBw cm9ibGVtIHNwYWNlIGlzIHRoZSBJQ0FOTiBub24tdGVjaG5pY2FsbHkgZHJpdmVuIG9uZSBpdHNl bGYsDQo+IEROQU1FIHdvcmtzIGZpbmUgc28gbG9uZyBhcyB0aGVyZSBhcmUgbm8gb3RoZXIgcmVj b3JkcyBhdCB0aGUgem9uZSBhcGV4LA0KPiBkb2Vzbid0IGl0Pw0KPg0KaWNhbm4gaGFzIGRpc2N1 c3NlZCB0aGUgZG5hbWUgZm9yIG1hbnkgeWVhcnMuDQppZiBpdCBpcyBnb29kLCBpdCB3b3VsZCBo YXZlIGJlZW4gdXNlZCBmb3IgdGhlIGlkbiB0bGQgb3Igc2Vjb25kIGxldmVsIGlkbi4NCg0KeW91 IG1heSBhbHNvIHRha2UgYSBsb29rIGF0IGRpc2N1c3Npb24gaGVyZToNCg0KDQpodHRwOi8vd3d3 Lm9wcy5pZXRmLm9yZy9saXN0cy9uYW1lZHJvcHBlcnMvbmFtZWRyb3BwZXJzLjIwMDkvbXNnMDMw MTYuaHRtbA0KDQoNCkppYW5rYW5nIFlhbw0KDQo+DQo+IEknbSBleGNsdWRpbmcgaGVyZSBmb3Ig dGhlIHNha2Ugb2YgYXJndW1lbnQgcHJvYmxlbXMgYXJpc2luZw0KPiBmcm9tIHRoZSBmYWN0IGEg bGFyZ2UgYm9keSBvZiByZXNvbHZlcnMgZG9uJ3QgdW5kZXJzdGFuZCBETkFNRSwgYmVjYXVzZQ0K PiBhbiBldmVuIGxhcmdlciBib2R5ICgxMDAlKSBkb24ndCBjdXJyZW50bHkgdW5kZXJzdGFuZCBY TkFNRS4NCj4gPg0KPiAtLSANCj4gQWxleCBCbGlnaA== From owner-namedroppers@ops.ietf.org Tue Aug 31 00:30: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 72A103A67B7; Tue, 31 Aug 2010 00:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 qTMrajwEwOOu; Tue, 31 Aug 2010 00:30:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 48D703A68A3; Tue, 31 Aug 2010 00:30:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqLFA-0000vG-F5 for namedroppers-data0@psg.com; Tue, 31 Aug 2010 07:26:56 +0000 Received: from mail-ww0-f48.google.com ([74.125.82.48]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqLF3-0000uY-UL for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 07:26:50 +0000 Received: by wwd20 with SMTP id 20so3295249wwd.17 for ; Tue, 31 Aug 2010 00:26:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.138.77 with SMTP id z13mr5733202wbt.109.1283239607767; Tue, 31 Aug 2010 00:26:47 -0700 (PDT) Received: by 10.227.133.8 with HTTP; Tue, 31 Aug 2010 00:26:47 -0700 (PDT) In-Reply-To: <4217F5EE-3F03-4935-8CA3-F59A568C46E6@hopcount.ca> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <4C7C49FB.1050605@necom830.hpcl.titech.ac.jp> <4217F5EE-3F03-4935-8CA3-F59A568C46E6@hopcount.ca> Date: Tue, 31 Aug 2010 00:26:47 -0700 Message-ID: Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Joe Abley Cc: Masataka Ohta , 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 Mon, Aug 30, 2010 at 9:23 PM, Joe Abley wrote: > I think a survey of existing mechanisms which could provide equivalence-t= ype functionality (e.g. for registry operators and for end users) together = with a clear description of the pros and cons of each would be really quite= useful to guide policymakers. While we're at it, a clear indication that w= e might need to wait decades before certain classes of solution are ready t= o use might also come in handy (e.g. approaches that require changes to res= olver behaviour). You never know, the result might be policy that is actual= ly implementable. +1 It's also worth noting that there is a clear bias in the discussion towards some solution that is expressible on the wire (with signaling of some kind) and in zone-files. This might be a case of "if you have a hammer ..". Given that even the most complicated of the use-cases we've seen so far could be performed as a query-time rewrite in a handful of CPU ops over microseconds in time - it would seem that making domain-equivalence a simple configured feature of authoritative name-servers could be a promising real-world solution. Isn't this the purpose of the "@" label representation? So that single text representations of zones could be used for multiple names? Maybe all that's neccessary is a BCP pointing that out. Placing the solution on the authoritative servers aligns the economic incentives with the interested parties .. and could work without the need for global resolver upgrades. --=20 Colm From owner-namedroppers@ops.ietf.org Tue Aug 31 00:41: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 EB4533A691D; Tue, 31 Aug 2010 00:41:52 -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: -99.162 X-Spam-Level: X-Spam-Status: No, score=-99.162 tagged_above=-999 required=5 tests=[AWL=0.840, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 t6OrgXp6u684; Tue, 31 Aug 2010 00:41:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 59E523A67B7; Tue, 31 Aug 2010 00:41:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqLPu-0002li-Lv for namedroppers-data0@psg.com; Tue, 31 Aug 2010 07:38:02 +0000 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqLPo-0002lJ-0L for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 07:37:56 +0000 Received: (eyou send program); Tue, 31 Aug 2010 15:37:55 +0800 Message-ID: <483240275.02127@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, 31 Aug 2010 15:37:55 +0800 Message-ID: <3111EA5669F54971B2243DB5C89D1173@LENOVO47E041CF> From: "Jiankang YAO" To: "Jiankang YAO" , "Alex Bligh" , "Masataka Ohta" , "Paul Vixie" Cc: , "Alex Bligh" References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <483215030.00496@cnnic.cn> <483232005.15063@cnnic.cn> <483238532.02872@cnnic.cn> <483239371.31268@cnnic.cn> Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Date: Tue, 31 Aug 2010 15:38:01 +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.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkppYW5rYW5nIFlBTyIgPHlh b2prQGNubmljLmNuPg0KVG86ICJBbGV4IEJsaWdoIiA8YWxleEBhbGV4Lm9yZy51az47ICJNYXNh dGFrYSBPaHRhIiA8bW9odGFAbmVjb204MzAuaHBjbC50aXRlY2guYWMuanA+OyAiUGF1bCBWaXhp ZSIgPHZpeGllQGlzYy5vcmc+DQpDYzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+OyAiQWxl eCBCbGlnaCIgPGFsZXhAYWxleC5vcmcudWs+DQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMzEsIDIw MTAgMzoyMiBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIHJlZ3VsYXRvcnkgcHJvYmxlbSBzdGF0 ZW1lbnQgKHdhcyBSZTogLi4uIGFzICJ0aGUgc2FtZSIpDQoNCg0KPiANCj4gLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLSANCj4gRnJvbTogIkFsZXggQmxpZ2giIDxhbGV4QGFsZXgub3JnLnVr Pg0KPiBUbzogIkppYW5rYW5nIFlBTyIgPHlhb2prQGNubmljLmNuPjsgIk1hc2F0YWthIE9odGEi IDxtb2h0YUBuZWNvbTgzMC5ocGNsLnRpdGVjaC5hYy5qcD47ICJQYXVsIFZpeGllIiA8dml4aWVA aXNjLm9yZz4NCj4gQ2M6IDxuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnPjsgIkFsZXggQmxpZ2gi IDxhbGV4QGFsZXgub3JnLnVrPg0KPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMzEsIDIwMTAgMzow OCBQTQ0KPiBTdWJqZWN0OiBSZTogW2Ruc2V4dF0gcmVndWxhdG9yeSBwcm9ibGVtIHN0YXRlbWVu dCAod2FzIFJlOiAuLi4gYXMgInRoZSBzYW1lIikNCj4gDQo+IA0KPj4gDQo+PiANCj4+IC0tT24g MzEgQXVndXN0IDIwMTAgMTM6MjA6MTEgKzA4MDAgSmlhbmthbmcgWUFPIDx5YW9qa0Bjbm5pYy5j bj4gd3JvdGU6DQo+PiANCj4+PiA+IFtETkFNRV0NCj4+Pg0KPj4+IGl0IGRvZXMgbm90IHdyb25n LCBidXQgaGFzIHNvbWUgcHJvYmxlbXMuDQo+Pj4NCj4+PiB0aGUgcHJvcG9zZWQgc29sdXRpb24g c2hvdWxkIHdvcmsgZm9yIGRpZmZlcmVudCBsZXZlbCBkb21haW4gbmFtZXMuDQo+PiANCj4+IFdo eT8gSWYgdGhlIHByb2JsZW0gc3BhY2UgaXMgdGhlIElDQU5OIG5vbi10ZWNobmljYWxseSBkcml2 ZW4gb25lIGl0c2VsZiwNCj4+IEROQU1FIHdvcmtzIGZpbmUgc28gbG9uZyBhcyB0aGVyZSBhcmUg bm8gb3RoZXIgcmVjb3JkcyBhdCB0aGUgem9uZSBhcGV4LA0KPj4gZG9lc24ndCBpdD8NCj4+DQo+ IGljYW5uIGhhcyBkaXNjdXNzZWQgdGhlIGRuYW1lIGZvciBtYW55IHllYXJzLg0KPiBpZiBpdCBp cyBnb29kLCBpdCB3b3VsZCBoYXZlIGJlZW4gdXNlZCBmb3IgdGhlIGlkbiB0bGQgb3Igc2Vjb25k IGxldmVsIGlkbi4NCj4gDQo+IHlvdSBtYXkgYWxzbyB0YWtlIGEgbG9vayBhdCBkaXNjdXNzaW9u IGhlcmU6DQo+IA0KPiANCj4gaHR0cDovL3d3dy5vcHMuaWV0Zi5vcmcvbGlzdHMvbmFtZWRyb3Bw ZXJzL25hbWVkcm9wcGVycy4yMDA5L21zZzAzMDE2Lmh0bWwNCj4NCg0KdGhlcmUgYXJlIGFsc28g c29tZSBkaXNjdXNzaW9ucyBoZXJlLg0KDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvZG5zb3AvY3VycmVudC9tc2cwNzcwMC5odG1sDQoNCiANCj4gDQo+IEppYW5rYW5nIFlh bw0KDQoNCj4gDQo+Pg0KPj4gSSdtIGV4Y2x1ZGluZyBoZXJlIGZvciB0aGUgc2FrZSBvZiBhcmd1 bWVudCBwcm9ibGVtcyBhcmlzaW5nDQo+PiBmcm9tIHRoZSBmYWN0IGEgbGFyZ2UgYm9keSBvZiBy ZXNvbHZlcnMgZG9uJ3QgdW5kZXJzdGFuZCBETkFNRSwgYmVjYXVzZQ0KPj4gYW4gZXZlbiBsYXJn ZXIgYm9keSAoMTAwJSkgZG9uJ3QgY3VycmVudGx5IHVuZGVyc3RhbmQgWE5BTUUuDQo+PiA+DQo+ PiAtLSANCj4+IEFsZXggQmxpZ2g= From owner-namedroppers@ops.ietf.org Tue Aug 31 01:18: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 68C613A6944; Tue, 31 Aug 2010 01:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=1.418, 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 Vb0XqtrJZNqd; Tue, 31 Aug 2010 01:18:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4889F3A6783; Tue, 31 Aug 2010 01:18:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqLyO-0008Qd-La for namedroppers-data0@psg.com; Tue, 31 Aug 2010 08:13:40 +0000 Received: from mail.avalus.com ([89.16.176.221]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqLyH-0008QG-Rf for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 08:13:34 +0000 Received: from [195.173.23.106] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 37EE1C5693C; Tue, 31 Aug 2010 09:13:31 +0100 (BST) Date: Tue, 31 Aug 2010 09:13:33 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jiankang YAO , Masataka Ohta , Paul Vixie cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Message-ID: <010F93E860EA28C56F2FA98D@nimrod.local> In-Reply-To: <483239371.31268@cnnic.cn> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <483215030.00496@cnnic.cn> <483232005.15063@cnnic.cn> <483238532.02872@cnnic.cn> <483239371.31268@cnnic.cn> 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 31 August 2010 15:22:58 +0800 Jiankang YAO wrote: >>> the proposed solution should work for different level domain names. >> >> Why? If the problem space is the ICANN non-technically driven one itself, >> DNAME works fine so long as there are no other records at the zone apex, >> doesn't it? >> > icann has discussed the dname for many years. > if it is good, it would have been used for the idn tld or second level > idn. With respect, saying "ICANN have talked about it for many years and nothing happened" doesn't mean anything, and is certainly not an answer to my question. As is the way of large multistakeholder organisations, ICANN talks about lots of things for long periods of time, sometimes goes down rat holes, and sometimes produces an answer. See, for example, IDN TLDs. > you may also take a look at discussion here: > > > http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg03016.html This is one person saying "may be new RRs get introduced more quickly than you think". I believe the latest significant RR was NSEC3. How long did that take? -- Alex Bligh From owner-namedroppers@ops.ietf.org Tue Aug 31 01:58: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 5ABE43A6A29; Tue, 31 Aug 2010 01:58:22 -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: -99.172 X-Spam-Level: X-Spam-Status: No, score=-99.172 tagged_above=-999 required=5 tests=[AWL=0.830, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 NL83evzjExhy; Tue, 31 Aug 2010 01:58:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CBC763A6A30; Tue, 31 Aug 2010 01:58:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqMba-000FLL-5e for namedroppers-data0@psg.com; Tue, 31 Aug 2010 08:54:10 +0000 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqMbT-000FKo-35 for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 08:54:03 +0000 Received: (eyou send program); Tue, 31 Aug 2010 16:53:59 +0800 Message-ID: <483244839.17603@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, 31 Aug 2010 16:53:59 +0800 Message-ID: <5C953B7ADCDE4C74AB0D9FEA80A8991D@LENOVO47E041CF> From: "Jiankang YAO" To: "Alex Bligh" , "Masataka Ohta" , "Paul Vixie" Cc: , "Alex Bligh" References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <483215030.00496@cnnic.cn> <483232005.15063@cnnic.cn> <483238532.02872@cnnic.cn> <483239371.31268@cnnic.cn> <483243606.46917@cnnic.cn> Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Date: Tue, 31 Aug 2010 16:54:06 +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.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsZXggQmxpZ2giIDxhbGV4 QGFsZXgub3JnLnVrPg0KVG86ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj47ICJNYXNh dGFrYSBPaHRhIiA8bW9odGFAbmVjb204MzAuaHBjbC50aXRlY2guYWMuanA+OyAiUGF1bCBWaXhp ZSIgPHZpeGllQGlzYy5vcmc+DQpDYzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+OyAiQWxl eCBCbGlnaCIgPGFsZXhAYWxleC5vcmcudWs+DQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMzEsIDIw MTAgNDoxMyBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIHJlZ3VsYXRvcnkgcHJvYmxlbSBzdGF0 ZW1lbnQgKHdhcyBSZTogLi4uIGFzICJ0aGUgc2FtZSIpDQoNCg0KPiANCj4gDQo+IC0tT24gMzEg QXVndXN0IDIwMTAgMTU6MjI6NTggKzA4MDAgSmlhbmthbmcgWUFPIDx5YW9qa0Bjbm5pYy5jbj4g d3JvdGU6DQo+IA0KPj4+PiB0aGUgcHJvcG9zZWQgc29sdXRpb24gc2hvdWxkIHdvcmsgZm9yIGRp ZmZlcmVudCBsZXZlbCBkb21haW4gbmFtZXMuDQo+Pj4NCj4+PiBXaHk/IElmIHRoZSBwcm9ibGVt IHNwYWNlIGlzIHRoZSBJQ0FOTiBub24tdGVjaG5pY2FsbHkgZHJpdmVuIG9uZSBpdHNlbGYsDQo+ Pj4gRE5BTUUgd29ya3MgZmluZSBzbyBsb25nIGFzIHRoZXJlIGFyZSBubyBvdGhlciByZWNvcmRz IGF0IHRoZSB6b25lIGFwZXgsDQo+Pj4gZG9lc24ndCBpdD8NCj4+Pg0KPj4gaWNhbm4gaGFzIGRp c2N1c3NlZCB0aGUgZG5hbWUgZm9yIG1hbnkgeWVhcnMuDQo+PiBpZiBpdCBpcyBnb29kLCBpdCB3 b3VsZCBoYXZlIGJlZW4gdXNlZCBmb3IgdGhlIGlkbiB0bGQgb3Igc2Vjb25kIGxldmVsDQo+PiBp ZG4uDQo+IA0KPiBXaXRoIHJlc3BlY3QsIHNheWluZyAiSUNBTk4gaGF2ZSB0YWxrZWQgYWJvdXQg aXQgZm9yIG1hbnkgeWVhcnMgYW5kIG5vdGhpbmcNCj4gaGFwcGVuZWQiIGRvZXNuJ3QgbWVhbiBh bnl0aGluZywgYW5kIGlzIGNlcnRhaW5seSBub3QgYW4gYW5zd2VyIHRvDQo+IG15IHF1ZXN0aW9u LiBBcyBpcyB0aGUgd2F5IG9mIGxhcmdlIG11bHRpc3Rha2Vob2xkZXINCj4gb3JnYW5pc2F0aW9u cywgSUNBTk4gdGFsa3MgYWJvdXQgbG90cyBvZiB0aGluZ3MgZm9yIGxvbmcgcGVyaW9kcyBvZiB0 aW1lLA0KPiBzb21ldGltZXMgZ29lcyBkb3duIHJhdCBob2xlcywgYW5kIHNvbWV0aW1lcyBwcm9k dWNlcyBhbiBhbnN3ZXIuIFNlZSwNCj4gZm9yIGV4YW1wbGUsIElETiBUTERzLg0KPg0KDQp0cnVl LiAiIHRhbGtlZCBhYm91dCBpdCBmb3IgbWFueSB5ZWFycyBhbmQgbm90aGluZw0KIGhhcHBlbmVk IiBtaWdodCBub3QgbWVhbiBhbnl0aGluZyINCmJ1dA0KInRoZXJlIGlzIGEgc29sdXRpb24sIGFu ZCBpY2FubiBkbyBub3QgdXNlIGl0IiBpcyBkaWZmZXJlbnQgd2l0aCAidGhlIHByb3Bvc2VkIHNv bHV0aW9uIGlzIG5vdCBnb29kLCBhbmQgaWNhbm4gZG9lcyBub3QgZGVjaWRlIGl0ICINCg0KbW9z dCBwYXJ0aWNpcGFudHMgb2YgZG5hbWUgZGljdXNzaW9uIGluIElDQU5OIGhhcyB0aGUgdGVjaG5p YyBiYWNrZ3JvdW5kLiB0aGV5IHRoaW5rIHRoYXQgdGhlcmUgbWF5IGhhdmUgc29tZSBwcm9ibGVt cyBpZiB3ZSB1c2UgZG5hbWUgZm9yIGlkbiB0bGQgb3IgaWRuLg0KSUNBTk4gZGVwZW5kcyBvbiB0 aGVzZSBwZW9wbGUgZm9yIGRlY2lzaW9uLiBpdCBsYXN0cyBmb3Igc28gbWFueSB5ZWFycyBiZWNh dXNlIHRoZSB0ZWNobmljYWwgcGVvcGxlIGluIGljYW5uIG9yIGlldGYgY2FuIG5vdCByZWNvbW1l bmQgYSBnb29kIHNvbHV0aW9uLCBub3QgYmVjYXVzZSB0aGF0IGljYW5uIGRvZXMgbm90IHdhbnQg dG8gZ2l2ZSBhIGNvbmNsdXNpb24uDQoNCmlmIHlvdSBsaWtlIHRvIHNlZSBtb3JlIHRlY2huaWNh bCBkaXNjdXNzaW9uIGFib3V0IGRuYW1lLA0KeW91IG1heSBsb29rIGhlcmU6DQoNCmh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kbnNvcC9jdXJyZW50L21zZzA3NzAwLmh0bWwN Cg0KDQp0aGFua3MuDQoNCg0KSmlhbmthbmcgWWFvDQoNCg0KDQoNCj4NCj4gDQo+PiB5b3UgbWF5 IGFsc28gdGFrZSBhIGxvb2sgYXQgZGlzY3Vzc2lvbiBoZXJlOg0KPj4NCj4+DQo+PiBodHRwOi8v d3d3Lm9wcy5pZXRmLm9yZy9saXN0cy9uYW1lZHJvcHBlcnMvbmFtZWRyb3BwZXJzLjIwMDkvbXNn MDMwMTYuaHRtbA0KPiANCj4gVGhpcyBpcyBvbmUgcGVyc29uIHNheWluZyAibWF5IGJlIG5ldyBS UnMgZ2V0IGludHJvZHVjZWQgbW9yZSBxdWlja2x5DQo+IHRoYW4geW91IHRoaW5rIi4gSSBiZWxp ZXZlIHRoZSBsYXRlc3Qgc2lnbmlmaWNhbnQgUlIgd2FzIE5TRUMzLiBIb3cNCj4gbG9uZyBkaWQg dGhhdCB0YWtlPw0KPiANCj4gLS0gDQo+IEFsZXggQmxpZ2gNCj4= From owner-namedroppers@ops.ietf.org Tue Aug 31 02:16: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 E480E3A6970; Tue, 31 Aug 2010 02:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[AWL=1.380, 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 63vvOm6JMGGq; Tue, 31 Aug 2010 02:16:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8192A3A6974; Tue, 31 Aug 2010 02:16:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqMta-000ITm-BK for namedroppers-data0@psg.com; Tue, 31 Aug 2010 09:12:46 +0000 Received: from mail.avalus.com ([89.16.176.221]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqMtT-000IT6-Jj for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 09:12:40 +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 51BF1C5695A; Tue, 31 Aug 2010 10:12:36 +0100 (BST) Date: Tue, 31 Aug 2010 10:12:36 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jiankang YAO , Masataka Ohta , Paul Vixie cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Message-ID: <745E3AA810B1E3C029F09A05@Ximines.local> In-Reply-To: <483244839.17603@cnnic.cn> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <483215030.00496@cnnic.cn> <483232005.15063@cnnic.cn> <483238532.02872@cnnic.cn> <483239371.31268@cnnic.cn> <483243606.46917@cnnic.cn> <483244839.17603@cnnic.cn> 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 31 August 2010 16:54:06 +0800 Jiankang YAO wrote: > most participants of dname dicussion in ICANN has the technic background. > they think that there may have some problems if we use dname for idn tld > or idn. But what *are* the problems? Any more than those in the message listed below? > ICANN depends on these people for decision. it lasts for so many > years because the technical people in icann or ietf can not recommend a > good solution, not because that icann does not want to give a conclusion. > > if you like to see more technical discussion about dname, > you may look here: > > http://www.ietf.org/mail-archive/web/dnsop/current/msg07700.html So, this sets out the following perceived problems: * For D0. and D1. to be equivalent using DNAME, the authoritative registries below the D0. and D1. zone cuts need to be DNAME aware. To the extent that is accurate (is that really true of the DNAME target?), it would seem to apply to XNAME too. * The root zone is very important (no arguments here), so ought to be running "stable technology" (ditto). XNAME is, however, newer than DNAME, in that it doesn't yet even exist. * Growth of the root zone file. To which I'd argue we have a plenty of collective experience running zones with several thousand entries. But, if the requirement is for "strong binding" (i.e. ICANN don't trust contractual solutions) then the equivalence data *MUST* be put in the root zone, not in a delegated zone. This is exactly why it is being argued that the provisioning method does not satisfy ICANN's requirements. Perhaps I have missed some. Can I verify that this list of DNAME problems is your own interpretation of them (and, to be clear, there is nothing wrong with that) rather than a problem statement from ICANN? -- Alex Bligh From owner-namedroppers@ops.ietf.org Tue Aug 31 02:39: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 AAE563A68EF; Tue, 31 Aug 2010 02:39: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: -98.883 X-Spam-Level: X-Spam-Status: No, score=-98.883 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 T7RNOjsTfn63; Tue, 31 Aug 2010 02:39:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F1FAB3A6A25; Tue, 31 Aug 2010 02:39:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqNEy-000MLo-SQ for namedroppers-data0@psg.com; Tue, 31 Aug 2010 09:34:52 +0000 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqNEr-000MKd-Jr for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 09:34:46 +0000 Received: (eyou send program); Tue, 31 Aug 2010 17:34:43 +0800 Message-ID: <483247283.23709@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, 31 Aug 2010 17:34:43 +0800 Message-ID: From: "Jiankang YAO" To: "Alex Bligh" , "Masataka Ohta" , "Paul Vixie" Cc: , "Alex Bligh" References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <483215030.00496@cnnic.cn> <483232005.15063@cnnic.cn> <483238532.02872@cnnic.cn> <483239371.31268@cnnic.cn> <483243606.46917@cnnic.cn> <483244839.17603@cnnic.cn> <483245961.16957@cnnic.cn> Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Date: Tue, 31 Aug 2010 17:34:50 +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.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsZXggQmxpZ2giIDxhbGV4 QGFsZXgub3JnLnVrPg0KVG86ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj47ICJNYXNh dGFrYSBPaHRhIiA8bW9odGFAbmVjb204MzAuaHBjbC50aXRlY2guYWMuanA+OyAiUGF1bCBWaXhp ZSIgPHZpeGllQGlzYy5vcmc+DQpDYzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+OyAiQWxl eCBCbGlnaCIgPGFsZXhAYWxleC5vcmcudWs+DQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMzEsIDIw MTAgNToxMiBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIHJlZ3VsYXRvcnkgcHJvYmxlbSBzdGF0 ZW1lbnQgKHdhcyBSZTogLi4uIGFzICJ0aGUgc2FtZSIpDQoNCg0KPiANCj4gDQo+IC0tT24gMzEg QXVndXN0IDIwMTAgMTY6NTQ6MDYgKzA4MDAgSmlhbmthbmcgWUFPIDx5YW9qa0Bjbm5pYy5jbj4g d3JvdGU6DQo+IA0KPj4gbW9zdCBwYXJ0aWNpcGFudHMgb2YgZG5hbWUgZGljdXNzaW9uIGluIElD QU5OIGhhcyB0aGUgdGVjaG5pYyBiYWNrZ3JvdW5kLg0KPj4gdGhleSB0aGluayB0aGF0IHRoZXJl IG1heSBoYXZlIHNvbWUgcHJvYmxlbXMgaWYgd2UgdXNlIGRuYW1lIGZvciBpZG4gdGxkDQo+PiBv ciBpZG4uDQo+IA0KPiBCdXQgd2hhdCAqYXJlKiB0aGUgcHJvYmxlbXM/IEFueSBtb3JlIHRoYW4g dGhvc2UgaW4gdGhlIG1lc3NhZ2UgbGlzdGVkDQo+IGJlbG93Pw0KPg0KDQppIHRoaW5rIHRoYXQg aWNhbm4gbmVlZHMgdGhlIHNvbHV0aW9uIGZvciBJRE4gVExEIGFuZCBJRE4uDQpJZiBpY2FubiBy ZWNvbW1lbmQgRE5BTUUgZm9yIGlkbiB0bGQsIHNvbWVvbmUgbWF5IGFsc28gdXNlIGl0IGZvciBp ZG4gdG9vLg0KDQpzaW5jZSBkbmFtZSBpcyBtYXBwaW5nIGl0cyBjaGlsZHJlbiBvbmx5LCAgaXQg Y2FuIG5vdCBiZSB1c2VkIGZvciBhbGlhcy5nciBhbmQgYWxpYXMxLmdyLg0KDQp0aGVyZSBhbHNv IHNvbWUgcG9pbnRzIGhlcmU6DQoNCmh0dHA6Ly93d3cuYWx2ZXN0cmFuZC5uby9waXBlcm1haWwv aWRuYS11cGRhdGUvMjAwOC1KYW51YXJ5LzAwMDk4My5odG1sDQoNCg0KPg0KPiANCj4+IElDQU5O IGRlcGVuZHMgb24gdGhlc2UgcGVvcGxlIGZvciBkZWNpc2lvbi4gaXQgbGFzdHMgZm9yIHNvIG1h bnkNCj4+IHllYXJzIGJlY2F1c2UgdGhlIHRlY2huaWNhbCBwZW9wbGUgaW4gaWNhbm4gb3IgaWV0 ZiBjYW4gbm90IHJlY29tbWVuZCBhDQo+PiBnb29kIHNvbHV0aW9uLCBub3QgYmVjYXVzZSB0aGF0 IGljYW5uIGRvZXMgbm90IHdhbnQgdG8gZ2l2ZSBhIGNvbmNsdXNpb24uDQo+Pg0KPj4gaWYgeW91 IGxpa2UgdG8gc2VlIG1vcmUgdGVjaG5pY2FsIGRpc2N1c3Npb24gYWJvdXQgZG5hbWUsDQo+PiB5 b3UgbWF5IGxvb2sgaGVyZToNCj4+DQo+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvZG5zb3AvY3VycmVudC9tc2cwNzcwMC5odG1sDQo+IA0KPiBTbywgdGhpcyBzZXRzIG91 dCB0aGUgZm9sbG93aW5nIHBlcmNlaXZlZCBwcm9ibGVtczoNCj4gDQo+ICogRm9yIEQwLiBhbmQg RDEuIHRvIGJlIGVxdWl2YWxlbnQgdXNpbmcgRE5BTUUsIHRoZSBhdXRob3JpdGF0aXZlDQo+ICBy ZWdpc3RyaWVzIGJlbG93IHRoZSBEMC4gYW5kIEQxLiB6b25lIGN1dHMgbmVlZCB0byBiZSBETkFN RSBhd2FyZS4NCj4gIFRvIHRoZSBleHRlbnQgdGhhdCBpcyBhY2N1cmF0ZSAoaXMgdGhhdCByZWFs bHkgdHJ1ZSBvZiB0aGUgRE5BTUUNCj4gIHRhcmdldD8pLCBpdCB3b3VsZCBzZWVtIHRvIGFwcGx5 IHRvIFhOQU1FIHRvby4NCj4gDQo+ICogVGhlIHJvb3Qgem9uZSBpcyB2ZXJ5IGltcG9ydGFudCAo bm8gYXJndW1lbnRzIGhlcmUpLCBzbyBvdWdodCB0bw0KPiAgYmUgcnVubmluZyAic3RhYmxlIHRl Y2hub2xvZ3kiIChkaXR0bykuIFhOQU1FIGlzLCBob3dldmVyLCBuZXdlcg0KPiAgdGhhbiBETkFN RSwgaW4gdGhhdCBpdCBkb2Vzbid0IHlldCBldmVuIGV4aXN0Lg0KPiANCj4gKiBHcm93dGggb2Yg dGhlIHJvb3Qgem9uZSBmaWxlLiBUbyB3aGljaCBJJ2QgYXJndWUgd2UgaGF2ZSBhIHBsZW50eQ0K PiAgb2YgY29sbGVjdGl2ZSBleHBlcmllbmNlIHJ1bm5pbmcgem9uZXMgd2l0aCBzZXZlcmFsIHRo b3VzYW5kDQo+ICBlbnRyaWVzLiBCdXQsIGlmIHRoZSByZXF1aXJlbWVudCBpcyBmb3IgInN0cm9u ZyBiaW5kaW5nIiAoaS5lLg0KPiAgSUNBTk4gZG9uJ3QgdHJ1c3QgY29udHJhY3R1YWwgc29sdXRp b25zKSB0aGVuIHRoZSBlcXVpdmFsZW5jZQ0KPiAgZGF0YSAqTVVTVCogYmUgcHV0IGluIHRoZSBy b290IHpvbmUsIG5vdCBpbiBhIGRlbGVnYXRlZCB6b25lLg0KPiAgVGhpcyBpcyBleGFjdGx5IHdo eSBpdCBpcyBiZWluZyBhcmd1ZWQgdGhhdCB0aGUgcHJvdmlzaW9uaW5nDQo+ICBtZXRob2QgZG9l cyBub3Qgc2F0aXNmeSBJQ0FOTidzIHJlcXVpcmVtZW50cy4NCj4gDQo+IFBlcmhhcHMgSSBoYXZl IG1pc3NlZCBzb21lLg0KPiANCj4gQ2FuIEkgdmVyaWZ5IHRoYXQgdGhpcyBsaXN0IG9mIEROQU1F IHByb2JsZW1zIGlzIHlvdXIgb3duDQo+IGludGVycHJldGF0aW9uIG9mIHRoZW0gKGFuZCwgdG8g YmUgY2xlYXIsIHRoZXJlIGlzIG5vdGhpbmcNCj4gd3Jvbmcgd2l0aCB0aGF0KSByYXRoZXIgdGhh biBhIHByb2JsZW0gc3RhdGVtZW50IGZyb20gSUNBTk4/DQo+DQoNCnRoaXMgaXMgdGhlIGRpc2N1 c3Npb24gbWF0ZXJpYWwgZnJvbSBtZSwgbm90IElDQU5OJ3MuDQoNCg0KPg0KPiANCj4gLS0gDQo+ IEFsZXggQmxpZ2g= From owner-namedroppers@ops.ietf.org Tue Aug 31 02: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 A17EE3A6927; Tue, 31 Aug 2010 02:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.955 X-Spam-Level: X-Spam-Status: No, score=-0.955 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, J_CHICKENPOX_52=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 zh510ixd5Wml; Tue, 31 Aug 2010 02:55:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 900783A63D3; Tue, 31 Aug 2010 02:55:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqNVv-000PTZ-Lk for namedroppers-data0@psg.com; Tue, 31 Aug 2010 09:52:23 +0000 Received: from mail.avalus.com ([89.16.176.221]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqNVo-000PSy-Rt for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 09:52:17 +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 A40B4C5694C; Tue, 31 Aug 2010 10:52:14 +0100 (BST) Date: Tue, 31 Aug 2010 10:52:13 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jiankang YAO , Masataka Ohta , Paul Vixie cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Message-ID: <108FFF5CEB365B5476F0022C@Ximines.local> In-Reply-To: <483247283.23709@cnnic.cn> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <483215030.00496@cnnic.cn> <483232005.15063@cnnic.cn> <483238532.02872@cnnic.cn> <483239371.31268@cnnic.cn> <483243606.46917@cnnic.cn> <483244839.17603@cnnic.cn> <483245961.16957@cnnic.cn> <483247283.23709@cnnic.cn> 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: > i think that icann needs the solution for IDN TLD and IDN. > If icann recommend DNAME for idn tld, someone may also use it for idn too. > > since dname is mapping its children only, it can not be used for > alias.gr and alias1.gr. But if the problem space is ICANN TLDs themselves, how many TLDs have records at their apex? If you mean within the TLDs, then ICANN has no /technical/ control of whether the registry make alias.gr and alais1.gr equivalent, so the provisioning hack is the best you can get. Indeed it gives ICANN *better* guarantees of equivalence than an XNAME solution where XNAME is beyond the zone cut (i.e. in alias1.gr) as that is up to the registrant rather than the registry. > there also some points here: > > http://www.alvestrand.no/pipermail/idna-update/2008-January/000983.html It's difficult to jump into threads, but John appears to be arguing for DNAME use (see last paras). -- Alex Bligh From owner-namedroppers@ops.ietf.org Tue Aug 31 02:56: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 7915E3A69F5; Tue, 31 Aug 2010 02:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.17 X-Spam-Level: X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQP9n4YqfQtV; Tue, 31 Aug 2010 02:56:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A7FA53A6942; Tue, 31 Aug 2010 02:56:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqNXM-000Pgk-9S for namedroppers-data0@psg.com; Tue, 31 Aug 2010 09:53:52 +0000 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqNXE-000Pg6-Sw for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 09:53:46 +0000 Received: (qmail 88472 invoked from network); 31 Aug 2010 10:04:37 -0000 Received: from softbank219001188004.bbtec.net (HELO ?192.168.1.22?) (219.1.188.4) by necom830.hpcl.titech.ac.jp with SMTP; 31 Aug 2010 10:04:37 -0000 Message-ID: <4C7CD0ED.2040605@necom830.hpcl.titech.ac.jp> Date: Tue, 31 Aug 2010 18:52:45 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alex Bligh CC: Jiankang YAO , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <483215030.00496@cnnic.cn> <483232005.15063@cnnic.cn> <483238532.02872@cnnic.cn> <483239371.31268@cnnic.cn> <483243606.46917@cnnic.cn> <483244839.17603@cnnic.cn> <745E3AA810B1E3C029F09A05@Ximines.local> In-Reply-To: <745E3AA810B1E3C029F09A05@Ximines.local> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Alex Bligh wrote: > But what *are* the problems? The problem is that the concept of IDN is broken from the beginning. Let DNAME, another broken concept introduced from broken activities of broken IPv6, take care of it. So great regulatory power of ICANN should be able to force people use IDN and DNAME widely. Masataka Ohta From owner-namedroppers@ops.ietf.org Tue Aug 31 03:05: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 2C91D3A6A35; Tue, 31 Aug 2010 03:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.336 X-Spam-Level: X-Spam-Status: No, score=-102.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 gN07bcpDCXAg; Tue, 31 Aug 2010 03:05:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 12F283A6947; Tue, 31 Aug 2010 03:05:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqNfX-0001GB-9x for namedroppers-data0@psg.com; Tue, 31 Aug 2010 10:02:19 +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.72 (FreeBSD)) (envelope-from ) id 1OqNfP-00010e-Bo for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 10:02: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 o7V9pfDY018463; Tue, 31 Aug 2010 09:51:41 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o7V9pVlk018462; Tue, 31 Aug 2010 09:51:31 GMT Date: Tue, 31 Aug 2010 09:51:31 +0000 From: bmanning@vacation.karoshi.com To: Joe Abley Cc: Masataka Ohta , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Message-ID: <20100831095131.GB18086@vacation.karoshi.com.> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <4C7C49FB.1050605@necom830.hpcl.titech.ac.jp> <4217F5EE-3F03-4935-8CA3-F59A568C46E6@hopcount.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4217F5EE-3F03-4935-8CA3-F59A568C46E6@hopcount.ca> 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 Tue, Aug 31, 2010 at 12:23:23AM -0400, Joe Abley wrote: > > On 2010-08-30, at 20:16, Masataka Ohta wrote: > > > What's wrong with > > > > CN. NS ... > > CN0. DNAME CN. > > CN1. DNAME CN. > > CN2. DNAME CN. > > CN3. DNAME CN. > > . > > . > > . > > > > in the root zone? > > Good question. > > Part of the reason this thread continues to spiral around the plughole is that I don't believe anybody has taken the time to ask that question and others like it of non-technical policy people in a form they could understand. sigh... one can never be sure that non-technical policy people will understand. eight years ago(2001/2002), JPRS and CNNIC both tested that construct in the RS.NET testbed. we know it works for some form of "equivalence". > I think a survey of existing mechanisms which could provide equivalence-type functionality (e.g. for registry operators and for end users) together with a clear description of the pros and cons of each would be really quite useful to guide policymakers. While we're at it, a clear indication that we might need to wait decades before certain classes of solution are ready to use might also come in handy (e.g. approaches that require changes to resolver behaviour). You never know, the result might be policy that is actually implementable. i beleive the dnsext wg is producing such a survey. which is kind of odd, if the target audience is policy makers... "...behold the Internet Policy Task Force (IPTF)..." > I have a suspicion that to date the policy that is driving the noise we are hearing assumes that the technical problem space is unconstrained, which I think we believe (if we speak with one voice about anything) not to be true. > > > Joe From owner-namedroppers@ops.ietf.org Tue Aug 31 08:39: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 7BFDD3A6804; Tue, 31 Aug 2010 08:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.359 X-Spam-Level: X-Spam-Status: No, score=-101.359 tagged_above=-999 required=5 tests=[AWL=1.240, 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 LMhhTaK2NZhy; Tue, 31 Aug 2010 08:39:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 56DDF3A6846; Tue, 31 Aug 2010 08:39:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqSpI-000829-4l for namedroppers-data0@psg.com; Tue, 31 Aug 2010 15:32:44 +0000 Received: from hoffman.proper.com ([207.182.41.81]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqSpA-00081M-G4 for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 15:32:36 +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 o7VFWWD9067197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2010 08:32:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <483224586.22087@cnnic.cn> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <5831A1FCBAF9396EF92D3914@nimrod.local> <49228.1283199781@nsa.vix.com> <232890023F1F44341FAD59F5@nimrod.local> <60220.1283211506@nsa.vix.com> <483213682.08432@cnnic.cn> <483224586.22087@cnnic.cn> Date: Tue, 31 Aug 2010 08:32:30 -0700 To: "Jiankang YAO" From: Paul Hoffman Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") 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 11:16 AM +0800 8/31/10, Jiankang YAO wrote: >----- Original Message ----- >From: "Paul Hoffman" >To: "Paul Vixie" ; >Sent: Tuesday, August 31, 2010 8:04 AM >Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") > > >> At 11:38 PM +0000 8/30/10, Paul Vixie wrote: >>>i think ICANN has been pretty clear about why it wants this stuff. >> >> why it wants != requirements >> >> If you think ICANN has been pretty clear about its requirements, a URL would be handy. An ICANN staffer speaking up would be even more useful. >> > >Tina from ICANN has a report in Brussels meeting. this may help us to understand it. > >https://brussels38.icann.org/meetings/brussels2010/presentation-idns-dam-23jun10-en.pdf With all due respect, I do not see anything in here that could be called "pretty clear" about requirements. Sending links to presentations that discuss possible solutions but do not discuss the problems is not helpful to this discussion. >also some idn seessions: >https://brussels38.icann.org/node/12683 And the same here. I see presentations on well-known IDN issues, not clear statements of requirements for equivalence. >https://brussels38.icann.org/full-schedule And that's just insulting. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Tue Aug 31 09:36: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 AFDA13A69B3; Tue, 31 Aug 2010 09:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.759 X-Spam-Level: X-Spam-Status: No, score=-0.759 tagged_above=-999 required=5 tests=[AWL=1.841, 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 XcntQFwLD6ij; Tue, 31 Aug 2010 09:36:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0CCA03A69E5; Tue, 31 Aug 2010 09:36:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqTlf-000Jsq-MT for namedroppers-data0@psg.com; Tue, 31 Aug 2010 16:33:03 +0000 Received: from abenaki.wabanaki.net ([65.99.1.133]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqTlZ-000JsG-Sw for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 16:32:58 +0000 Received: from limpet.local (cpe-67-255-5-237.twcny.res.rr.com [67.255.5.237]) by abenaki.wabanaki.net (8.14.4/8.14.4) with ESMTP id o7VFRh2f039120; Tue, 31 Aug 2010 11:27:44 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4C7D2EB1.9060408@abenaki.wabanaki.net> Date: Tue, 31 Aug 2010 12:32:49 -0400 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: David Conrad CC: Paul Hoffman , namedroppers WG Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <5831A1FCBAF9396EF92D3914@nimrod.local> <49228.1283199781@nsa.vix.com> <091622CE-4DBE-4707-A274-2F9F2A46FF32@virtualized.org> In-Reply-To: <091622CE-4DBE-4707-A274-2F9F2A46FF32@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: > That is, folks in [...] Greece (to my knowledge) have ... Good point David, the tonos issue is unlike the Arabic Script variants and unlike the SC/TC equivalences. Eric From owner-namedroppers@ops.ietf.org Tue Aug 31 09: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 62B3B3A688F; Tue, 31 Aug 2010 09:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.128 X-Spam-Level: X-Spam-Status: No, score=-101.128 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, SARE_LWSHORTT=1.24, 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 Je9bPebP0yka; Tue, 31 Aug 2010 09:51:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A1CAD3A69BC; Tue, 31 Aug 2010 09:51:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqTym-000MPn-Gh for namedroppers-data0@psg.com; Tue, 31 Aug 2010 16:46:36 +0000 Received: from mail.yitter.info ([208.86.224.201]) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqTyf-000MPF-0z for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 16:46:29 +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 9DAC71ECB408 for ; Tue, 31 Aug 2010 16:46:26 +0000 (UTC) Date: Tue, 31 Aug 2010 12:46:25 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: A next step? (was: [dnsext] Re: DNSEXT charter and treating DNS names as "thesame") Message-ID: <20100831164624.GO24538@shinkuro.com> References: <483158956.02282@cnnic.cn> <328DCC4D8C7C45A1A31B5759A3C9442C@LENOVO47E041CF> <20100830224638.GG24538@shinkuro.com> <535EA9D909F740B6A2EF59E77AA12441@LENOVO47E041CF> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <535EA9D909F740B6A2EF59E77AA12441@LENOVO47E041CF> 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: Hi, This is still sent with the baffled-chair-trying-to-get-problem-statement hat on. On Tue, Aug 31, 2010 at 11:41:11AM +0800, Jiankang YAO wrote: > > they do not say that we must change the dns. they feel that the provision is just a short term sloution, not an ideal solution. > Right. But this WG isn't about the ideal solution. The ideal solution involves replacing DNS with a completely new protocol that is internationalized from the ground up. I have previously suggested that people who want to do that should start work on it, perhaps with a bar BOF or something. I don't predict success, but I wish such an effort well. > you may take a look at the following link: > > Tina from ICANN has a report in Brussels meeting. this may help us to understand it. > > https://brussels38.icann.org/meetings/brussels2010/presentation-idns-dam-23jun10-en.pdf I had a look at that. I also listened to the audiocast when Tina made that presentation. It still doesn't tell me much. Here are the relevant bits: Slide 8 outlines the different ways that people use the term "variant". It also explicitly notes that "translation" is not "variant", so the people who want ".org in another language", whatever that would mean, are not asking for variants. Slide 11 says that a dialogue is needed, that the requirements haven't been communicated, and that there are a coupld possible ideas kicking around one of which is long specified but not well tested, and another of which isn't even specified yet. That's it. That's all the outline of the issues that directly impinges on the DNS in the entire slide deck. The rest of the discussion is about what might get registered and what the rules maybe ought to be. But "name available somewhere" can be done with provosioning, and so we still don't know why that's inadequate. Now, you have argued more than once that what is needed is a protocol rule that enforces the sameness across a delegation boundary (that's what BNAME is for). What this really amounts to is a claim that we need in-protocol support to ensure compliance with a particular policy decision. That's a defensible claim in principle, but it comes with the obligation to explain why the rest of the DNS users need to pay the cost of this additional feature (new features always entail a cost, if only of development and testing) and why alternatives aren't just as good. Those arguments haven't so far been clear enough, I think, to make the case. My current, personal thinking is along the lines Joe Abley posted up-thread. We need to get a complete picture of all the things that can in fact be done right now, and all the things that people want to be able to do, as near as we can put that together; we combine with those a list of all the known side-effects of these strategies. We point the people who we think have issues here, and try to find out whether they understand the message. Only after that work is showing some effects do we undertake changes to the protocol. Does that approach make sense? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Aug 31 11:40: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 E9D933A6A69; Tue, 31 Aug 2010 11:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=0.893, 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 yDFqgNMQYNGH; Tue, 31 Aug 2010 11:40:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C84AE3A69C5; Tue, 31 Aug 2010 11:40:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqVfZ-000IL5-JO for namedroppers-data0@psg.com; Tue, 31 Aug 2010 18:34:53 +0000 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqVfT-000IHP-5O for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 18:34:47 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=BqOPtLShJ/sbEzerUi4y7yHAtM1b6NZth5ID7YExHEOsi4WLXyn8O13i4QFrRjcl; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.37] (helo=elwamui-karabash.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OqVfE-0002QI-Ps; Tue, 31 Aug 2010 14:34:32 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Tue, 31 Aug 2010 14:34:31 -0400 Message-ID: <17499385.1283279672747.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Date: Tue, 31 Aug 2010 13:34:31 -0500 (GMT-05:00) From: "Jeffrey A. Williams" Reply-To: "Jeffrey A. Williams" To: David Conrad , Andrew Sullivan Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Cc: namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688b74a9c30282e070559fd8be945ccb454350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.37 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: dave and all, -----Original Message----- >From: David Conrad >Sent: Aug 30, 2010 10:49 PM >To: Andrew Sullivan >Cc: namedroppers@ops.ietf.org >Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") > >Andrew, > >On Aug 30, 2010, at 3:42 PM, Andrew Sullivan wrote: >> Where exactly is ICANN's problem statement? As one of the chairs who needs to agree to herd this work through the IETF, I'd like to see it. > >An understandable request. While not "ICANN's problem statement", I gather you do not believe http://tools.ietf.org/html/draft-yao-dnsext-identical-resolution-00 is sufficient? > >> The only actual evidence we have from ICANN is that they _can_ do what they thought the synchronization stuff would achieve with provisioning, because in fact they already have. > >I believe the concern is that this is analogous to the person who fell off the Empire State building being heard to say "So far, so good" as he passed each floor on the way down... ROFLMAO! My father used to make this same analogy in some situations for years before his death! The problem with it is that even when the person reaches that sudden stop at the bottom, he/she doesn't know if the situation is still good because his/her death is immediate. > >Regards, >-drc > > Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From owner-namedroppers@ops.ietf.org Tue Aug 31 13:19: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 63CFD3A6AA8; Tue, 31 Aug 2010 13:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 Oi5Nv8UdVlYc; Tue, 31 Aug 2010 13:19:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3FA1A3A6883; Tue, 31 Aug 2010 13:19:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqXFB-000B0Q-Cw for namedroppers-data0@psg.com; Tue, 31 Aug 2010 20:15:45 +0000 Received: from trantor.virtualized.org ([204.152.189.190] helo=virtualized.org) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqXF5-000Azf-5Q for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 20:15:39 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 36497DFB85B; Tue, 31 Aug 2010 13:15:37 -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 gZp0-K1Vx7wh; Tue, 31 Aug 2010 13:15:35 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 7B2B8DFB850; Tue, 31 Aug 2010 13:15:35 -0700 (PDT) Subject: Re: A next step? (was: [dnsext] Re: DNSEXT charter and treating DNS names as "thesame") Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20100831164624.GO24538@shinkuro.com> Date: Tue, 31 Aug 2010 13:15:34 -0700 Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2AAE9293-618E-4B40-94E9-E86C8C119A42@virtualized.org> References: <483158956.02282@cnnic.cn> <328DCC4D8C7C45A1A31B5759A3C9442C@LENOVO47E041CF> <20100830224638.GG24538@shinkuro.com> <535EA9D909F740B6A2EF59E77AA12441@LENOVO47E041CF> <20100831164624.GO24538@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 Aug 31, 2010, at 9:46 AM, Andrew Sullivan wrote: > What this really amounts to is a claim that we > need in-protocol support to ensure compliance with a particular policy > decision. That's a defensible claim in principle, but it comes with > the obligation to explain why the rest of the DNS users need to pay > the cost of this additional feature (new features always entail a > cost, if only of development and testing) and why alternatives aren't > just as good. Those arguments haven't so far been clear enough, I > think, to make the case. I'd agree that it'd be interesting to compare the one-time cost of = development/testing/deployment of a new feature to the ongoing = operational cost of synchronization. I suspect coming up with = reasonable estimates for both would be challenging. > We need to get a complete picture of all the things that > can in fact be done right now, and all the things that people want to > be able to do, as near as we can put that together; we combine with > those a list of all the known side-effects of these strategies. We > point the people who we think have issues here, and try to find out > whether they understand the message. Sounds reasonable to me. Regards, -drc From owner-namedroppers@ops.ietf.org Tue Aug 31 15:28: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 49A8E3A686C; Tue, 31 Aug 2010 15:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 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 HgrH-nkbOHbl; Tue, 31 Aug 2010 15:28:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0FBBA3A6839; Tue, 31 Aug 2010 15:28:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqZFp-0008Xy-MQ for namedroppers-data0@psg.com; Tue, 31 Aug 2010 22:24: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.72 (FreeBSD)) (envelope-from ) id 1OqZFj-0008XL-En for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 22:24:27 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 71A45A1028 for ; Tue, 31 Aug 2010 22:24:26 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: A next step? (was: [dnsext] Re: DNSEXT charter and treating DNS names as "thesame") In-Reply-To: Your message of "Tue, 31 Aug 2010 13:15:34 MST." <2AAE9293-618E-4B40-94E9-E86C8C119A42@virtualized.org> References: <483158956.02282@cnnic.cn> <328DCC4D8C7C45A1A31B5759A3C9442C@LENOVO47E041CF> <20100830224638.GG24538@shinkuro.com> <535EA9D909F740B6A2EF59E77AA12441@LENOVO47E041CF> <20100831164624.GO24538@shinkuro.com> <2AAE9293-618E-4B40-94E9-E86C8C119A42@virtualized.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Tue, 31 Aug 2010 22:24:26 +0000 Message-ID: <40895.1283293466@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: On Aug 31, 2010, at 9:46 AM, Andrew Sullivan wrote: > What this really amounts to is a claim that we need in-protocol support > to ensure compliance with a particular policy decision. That's a > defensible claim in principle, but it comes with the obligation to > explain why the rest of the DNS users need to pay the cost of this > additional feature (new features always entail a cost, if only of > development and testing) and why alternatives aren't just as good. Those > arguments haven't so far been clear enough, I think, to make the case. nor were they for RFC 5011 or RFC 5155, yet somehow we (eventually) did the right thing, which was to enable maximal deployment at reasonable shared cost. From owner-namedroppers@ops.ietf.org Tue Aug 31 15:57: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 3C5A23A6876; Tue, 31 Aug 2010 15:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.863 X-Spam-Level: X-Spam-Status: No, score=-6.863 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifjbBkmokChf; Tue, 31 Aug 2010 15:57:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E37E3A6839; Tue, 31 Aug 2010 15:57:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqZir-000E3l-Nb for namedroppers-data0@psg.com; Tue, 31 Aug 2010 22:54:33 +0000 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqZil-000E1m-TI for namedroppers@ops.ietf.org; Tue, 31 Aug 2010 22:54:28 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAGAKskfUyrR7Hu/2dsb2JhbACgD0gCcaM1nBiFNwSKEYJ7hD8 X-IronPort-AV: E=Sophos;i="4.56,300,1280707200"; d="scan'208";a="179603367" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 31 Aug 2010 22:54:26 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7VMsPiB026155; Tue, 31 Aug 2010 22:54:26 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Sep 2010 00:54:24 +0200 Received: from 128.107.191.87 ([128.107.191.87]) by XMB-AMS-106.cisco.com ([144.254.74.81]) with Microsoft Exchange Server HTTP-DAV ; Tue, 31 Aug 2010 22:54:23 +0000 Subject: Re: A next step? (was: [dnsext] Re: DNSEXT charter and treating DNSnames as "thesame") References: <483158956.02282@cnnic.cn> <328DCC4D8C7C45A1A31B5759A3C9442C@LENOVO47E041CF> <20100830224638.GG24538@shinkuro.com> <535EA9D909F740B6A2EF59E77AA12441@LENOVO47E041CF> <20100831164624.GO24538@shinkuro.com> Content-Transfer-Encoding: quoted-printable Thread-Topic: A next step? (was: [dnsext] Re: DNSEXT charter and treating DNSnames as "thesame") Thread-Index: ActJX3SSGf12W7D+TqOgK9DiLDSvuw== From: "Patrik Faltstrom (pfaltstr)" Content-Type: text/plain; charset="us-ascii" In-Reply-To: <20100831164624.GO24538@shinkuro.com> Message-ID: <2DD184AB-9EC7-433F-961E-9B9DA5B6220C@cisco.com> Date: Wed, 1 Sep 2010 00:54:24 +0200 To: "Andrew Sullivan" Cc: MIME-Version: 1.0 (iPhone Mail 8A400) X-OriginalArrivalTime: 31 Aug 2010 22:54:24.0941 (UTC) FILETIME=[7554E5D0:01CB495F] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 31 aug 2010, at 18:48, Andrew Sullivan wrote: > and all the things that people want to > be able to do And, to repeat myself, I want resolution of A and B to result in "the same t= hing" from an applications point of view *without* doing multiple delegation= s as multiple delegations have implications on competition legislation etc. If the application can know what the canonical name is, that is a bonus as i= t make http, tls etc negotiations easier. Patrik From owner-namedroppers@ops.ietf.org Tue Aug 31 18:24: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 7E0863A68BB; Tue, 31 Aug 2010 18:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, 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 UWniQkOTfPSy; Tue, 31 Aug 2010 18:24:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6FDAC3A68B5; Tue, 31 Aug 2010 18:24:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqbyA-000DlP-3L for namedroppers-data0@psg.com; Wed, 01 Sep 2010 01:18:30 +0000 Received: from mx.pao1.isc.org ([2001:4f8:0:2::2b]) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oqby4-000Dkq-4e for namedroppers@ops.ietf.org; Wed, 01 Sep 2010 01:18:24 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id BCA7FC941E; Wed, 1 Sep 2010 01:18:21 +0000 (UTC) (envelope-from woolf@isc.org) Received: by farside.isc.org (Postfix, from userid 10265) id 52E50E6056; Wed, 1 Sep 2010 01:18:21 +0000 (UTC) Date: Wed, 1 Sep 2010 01:18:21 +0000 From: Suzanne Woolf To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: A next step? (was: [dnsext] Re: DNSEXT charter and treating DNS names as "thesame") Message-ID: <20100901011821.GA81487@farside.isc.org> References: <483158956.02282@cnnic.cn> <328DCC4D8C7C45A1A31B5759A3C9442C@LENOVO47E041CF> <20100830224638.GG24538@shinkuro.com> <535EA9D909F740B6A2EF59E77AA12441@LENOVO47E041CF> <20100831164624.GO24538@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100831164624.GO24538@shinkuro.com> 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 Tue, Aug 31, 2010 at 12:46:25PM -0400, Andrew Sullivan wrote: > My current, personal thinking is along the lines Joe Abley posted > up-thread. We need to get a complete picture of all the things that > can in fact be done right now, and all the things that people want to > be able to do, as near as we can put that together; we combine with > those a list of all the known side-effects of these strategies. We > point the people who we think have issues here, and try to find out > whether they understand the message. > > Only after that work is showing some effects do we undertake changes > to the protocol. > > Does that approach make sense? I think this is more or less what I said in the charter discussion in Maastricht. Even if it's not, the answer to your question is "Yes," with only the caution that analysis of what *could* reasonably be done to the protocol has already begun and will, to some extent, proceed in parallel with the discovery procss you're proposing of what *should* be done. Suzanne (hat in hand) From owner-namedroppers@ops.ietf.org Tue Aug 31 18:27: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 5B0C13A68BF; Tue, 31 Aug 2010 18:27:04 -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: -99.189 X-Spam-Level: X-Spam-Status: No, score=-99.189 tagged_above=-999 required=5 tests=[AWL=0.813, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 EF2zT7LZEbhv; Tue, 31 Aug 2010 18:27:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F132C3A68D1; Tue, 31 Aug 2010 18:27:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oqc39-000Efk-Fi for namedroppers-data0@psg.com; Wed, 01 Sep 2010 01:23:39 +0000 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oqc31-000EYd-Qs for namedroppers@ops.ietf.org; Wed, 01 Sep 2010 01:23:33 +0000 Received: (eyou send program); Wed, 01 Sep 2010 09:23:29 +0800 Message-ID: <483304209.23695@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, 01 Sep 2010 09:23:29 +0800 Message-ID: <6947E0493D674B25A1FDB55746DDD436@LENOVO47E041CF> From: "Jiankang YAO" To: "Paul Hoffman" Cc: References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <5831A1FCBAF9396EF92D3914@nimrod.local> <49228.1283199781@nsa.vix.com> <232890023F1F44341FAD59F5@nimrod.local> <60220.1283211506@nsa.vix.com> <483213682.08432@cnnic.cn> <483224586.22087@cnnic.cn> <483268756.23705@cnnic.cn> Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Date: Wed, 1 Sep 2010 09:23:36 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBhdWwgSG9mZm1hbiIgPHBh dWwuaG9mZm1hbkB2cG5jLm9yZz4NClRvOiAiSmlhbmthbmcgWUFPIiA8eWFvamtAY25uaWMuY24+ DQpDYzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBBdWd1c3Qg MzEsIDIwMTAgMTE6MzIgUE0NClN1YmplY3Q6IFJlOiBbZG5zZXh0XSByZWd1bGF0b3J5IHByb2Js ZW0gc3RhdGVtZW50ICh3YXMgUmU6IC4uLiBhcyAidGhlIHNhbWUiKQ0KDQoNCj4gQXQgMTE6MTYg QU0gKzA4MDAgOC8zMS8xMCwgSmlhbmthbmcgWUFPIHdyb3RlOg0KPj4tLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tDQo+PkZyb206ICJQYXVsIEhvZmZtYW4iIDxwYXVsLmhvZmZtYW5AdnBuYy5v cmc+DQo+PlRvOiAiUGF1bCBWaXhpZSIgPHZpeGllQGlzYy5vcmc+OyA8bmFtZWRyb3BwZXJzQG9w cy5pZXRmLm9yZz4NCj4+U2VudDogVHVlc2RheSwgQXVndXN0IDMxLCAyMDEwIDg6MDQgQU0NCj4+ U3ViamVjdDogUmU6IFtkbnNleHRdIHJlZ3VsYXRvcnkgcHJvYmxlbSBzdGF0ZW1lbnQgKHdhcyBS ZTogLi4uIGFzICJ0aGUgc2FtZSIpDQo+Pg0KPj4NCj4+PiBBdCAxMTozOCBQTSArMDAwMCA4LzMw LzEwLCBQYXVsIFZpeGllIHdyb3RlOg0KPj4+PmkgdGhpbmsgSUNBTk4gaGFzIGJlZW4gcHJldHR5 IGNsZWFyIGFib3V0IHdoeSBpdCB3YW50cyB0aGlzIHN0dWZmLg0KPj4+DQo+Pj4gd2h5IGl0IHdh bnRzICE9IHJlcXVpcmVtZW50cw0KPj4+DQo+Pj4gSWYgeW91IHRoaW5rIElDQU5OIGhhcyBiZWVu IHByZXR0eSBjbGVhciBhYm91dCBpdHMgcmVxdWlyZW1lbnRzLCBhIFVSTCB3b3VsZCBiZSBoYW5k eS4gQW4gSUNBTk4gc3RhZmZlciBzcGVha2luZyB1cCB3b3VsZCBiZSBldmVuIG1vcmUgdXNlZnVs Lg0KPj4+DQo+Pg0KPj5UaW5hIGZyb20gSUNBTk4gaGFzIGEgcmVwb3J0IGluIEJydXNzZWxzIG1l ZXRpbmcuIHRoaXMgbWF5IGhlbHAgdXMgdG8gdW5kZXJzdGFuZCBpdC4NCj4+DQo+Pmh0dHBzOi8v YnJ1c3NlbHMzOC5pY2Fubi5vcmcvbWVldGluZ3MvYnJ1c3NlbHMyMDEwL3ByZXNlbnRhdGlvbi1p ZG5zLWRhbS0yM2p1bjEwLWVuLnBkZg0KPiANCj4gV2l0aCBhbGwgZHVlIHJlc3BlY3QsIEkgZG8g bm90IHNlZSBhbnl0aGluZyBpbiBoZXJlIHRoYXQgY291bGQgYmUgY2FsbGVkICJwcmV0dHkgY2xl YXIiIGFib3V0IHJlcXVpcmVtZW50cy4gU2VuZGluZyBsaW5rcyB0byBwcmVzZW50YXRpb25zIHRo YXQgZGlzY3VzcyBwb3NzaWJsZSBzb2x1dGlvbnMgYnV0IGRvIG5vdCBkaXNjdXNzIHRoZSBwcm9i bGVtcyBpcyBub3QgaGVscGZ1bCB0byB0aGlzIGRpc2N1c3Npb24uDQo+IA0KPg0KDQppZiB0aGUg aW50ZXJuZXQgdXNlcnMgdGhpbmsgdGhhdCBuYW1lIEEgYW5kIEIgYXJlIHZhcmlhbnRzIG9yIGFs aWFzLA0KdGhlIHByb2JsZW0gaXMgdGhhdCAibmFtZSBBIGFuZCBCIG5lZWRzIHRvICBnZXQgdGhl IHNhbWUgRE5TIHJlc29sdXRpb24gcmVzdWx0Ii4NCg0KVGhlIHF1ZXN0aW9uIGlzIG5vdCB3aGV0 aGVyIEEgYW5kIEIgYXJlIHRoZSBzYW1lLiAgaWYgeW91IHRoaW5rIHRoYXQgdGhlIHByb2JsZW0g aXMgdGhhdCAiVGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgQSBhbmQgQiBhcmUgdGhlIHNhbWUuICIs DQoNCnRoYXQgbWF5IG5vdCBiZSBjbGVhci4gYnV0IGRlZmluaW5nIG9mIHdoZXRoZXIgb3Igd2h5 IEEgYW5kIEIgYXJlIHRoZSBzYW1lIGlzIG91dCBvZiBvdXIgd2cuDQoNCm91ciBqb2IgaXMgdG8g bWFrZSBuYW1lIEEgYW5kIEIgIGdldCB0aGUgc2FtZSBETlMgcmVzb2x1dGlvbiByZXN1bHQgaWYg dGhlIHVzZXJzIG5lZWQgdG8gZG8gc28uDQoNCg0KPg0KPg0KPj5hbHNvIHNvbWUgaWRuIHNlZXNz aW9uczoNCj4+aHR0cHM6Ly9icnVzc2VsczM4LmljYW5uLm9yZy9ub2RlLzEyNjgzDQo+IA0KPiBB bmQgdGhlIHNhbWUgaGVyZS4gSSBzZWUgcHJlc2VudGF0aW9ucyBvbiB3ZWxsLWtub3duIElETiBp c3N1ZXMsIG5vdCBjbGVhciBzdGF0ZW1lbnRzIG9mIHJlcXVpcmVtZW50cyBmb3IgZXF1aXZhbGVu Y2UuDQo+IA0KDQp0aGlzIHdpbGwgaGVscCBzb21lb25lIHRvIHVuZGVyc3RhbmQgdGhlIElETiBp c3N1ZXMgcmVsYXRlZCB0byB0aGlzIHByb2JsZW0uDQoNCj4NCj4+aHR0cHM6Ly9icnVzc2VsczM4 LmljYW5uLm9yZy9mdWxsLXNjaGVkdWxlDQo+IA0KPiBBbmQgdGhhdCdzIGp1c3QgaW5zdWx0aW5n Lg0KPiANCg0Kc29tZW9uZSBtYXkgcmVxdWlyZSBtb3JlIGlkbiBiYWNrZ3JvdW5kIG9yIGNvbnRl eHQsIHRoZXkgY2FuIGxvb2sgZm9yIG1vcmUgSUROIHNlc3Npb25zIGluIHRoaXMgbGluay4NCg0K aWYgeW91IHRoaW5rIHRoYXQgaXQgaXMgaW5zdWx0aW5nLCBJIGFtIHNvcnJ5IGFib3V0IGl0Lg0K DQpKSWFua2FuZyBZYW8NCg0KPiAtLVBhdWwgSG9mZm1hbiwgRGlyZWN0b3INCj4gLS1WUE4gQ29u c29ydGl1bQ== From owner-namedroppers@ops.ietf.org Tue Aug 31 19:08: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 4B81A3A6A0F; Tue, 31 Aug 2010 19:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=1.227, 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 eVYgygii5oqh; Tue, 31 Aug 2010 19:08:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 426763A6A14; Tue, 31 Aug 2010 19:08:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oqcgw-000Lhm-L2 for namedroppers-data0@psg.com; Wed, 01 Sep 2010 02:04:46 +0000 Received: from abenaki.wabanaki.net ([65.99.1.133]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oqcgq-000LfI-5U for namedroppers@ops.ietf.org; Wed, 01 Sep 2010 02:04:40 +0000 Received: from limpet.local (cpe-67-255-5-237.twcny.res.rr.com [67.255.5.237]) by abenaki.wabanaki.net (8.14.4/8.14.4) with ESMTP id o810xJ1n042622; Tue, 31 Aug 2010 20:59:19 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4C7DB4AE.4030703@abenaki.wabanaki.net> Date: Tue, 31 Aug 2010 22:04:30 -0400 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Patrik Faltstrom (pfaltstr)" CC: Andrew Sullivan , namedroppers@ops.ietf.org Subject: [dnsext] Re: A next step? References: <483158956.02282@cnnic.cn> <328DCC4D8C7C45A1A31B5759A3C9442C@LENOVO47E041CF> <20100830224638.GG24538@shinkuro.com> <535EA9D909F740B6A2EF59E77AA12441@LENOVO47E041CF> <20100831164624.GO24538@shinkuro.com> <2DD184AB-9EC7-433F-961E-9B9DA5B6220C@cisco.com> In-Reply-To: <2DD184AB-9EC7-433F-961E-9B9DA5B6220C@cisco.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: > ... I want resolution of A and B to result in ... i think i'll cease offering what little i think i bring here, but i'll settle for being able to make useful assertions about the temporal properties of the difference of resolution. From owner-namedroppers@ops.ietf.org Tue Aug 31 20:16: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 BCB1B3A6836; Tue, 31 Aug 2010 20:16:42 -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: -97.349 X-Spam-Level: X-Spam-Status: No, score=-97.349 tagged_above=-999 required=5 tests=[AWL=-1.046, BAYES_20=-0.74, J_CHICKENPOX_37=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, SARE_LWSHORTT=1.24, 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 Wy6wP2bXhso1; Tue, 31 Aug 2010 20:16:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E4DEB3A6358; Tue, 31 Aug 2010 20:16:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oqdj7-0006ea-PZ for namedroppers-data0@psg.com; Wed, 01 Sep 2010 03:11:05 +0000 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oqdiz-0006dp-D7 for namedroppers@ops.ietf.org; Wed, 01 Sep 2010 03:10:58 +0000 Received: (eyou send program); Wed, 01 Sep 2010 11:10:55 +0800 Message-ID: <483310655.02540@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, 01 Sep 2010 11:10:55 +0800 Message-ID: <9FDE76C01C544527BACF096C7CC2856E@LENOVO47E041CF> From: "Jiankang YAO" To: "Andrew Sullivan" , References: <483158956.02282@cnnic.cn> <328DCC4D8C7C45A1A31B5759A3C9442C@LENOVO47E041CF> <20100830224638.GG24538@shinkuro.com> <535EA9D909F740B6A2EF59E77AA12441@LENOVO47E041CF> <20100831164624.GO24538@shinkuro.com> Subject: Re: A next step? (was: [dnsext] Re: DNSEXT charter and treating DNSnames as "thesame") Date: Wed, 1 Sep 2010 11:11:03 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a 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 OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwMSwgMjAxMCAxMjo0NiBBTQ0KU3ViamVjdDogQSBuZXh0 IHN0ZXA/ICh3YXM6IFtkbnNleHRdIFJlOiBETlNFWFQgY2hhcnRlciBhbmQgdHJlYXRpbmcgRE5T bmFtZXMgYXMgInRoZXNhbWUiKQ0KDQoNCj4gSGksDQo+IA0KPiBUaGlzIGlzIHN0aWxsIHNlbnQg d2l0aCB0aGUNCj4gYmFmZmxlZC1jaGFpci10cnlpbmctdG8tZ2V0LXByb2JsZW0tc3RhdGVtZW50 IGhhdCBvbi4NCj4gDQo+IE9uIFR1ZSwgQXVnIDMxLCAyMDEwIGF0IDExOjQxOjExQU0gKzA4MDAs IEppYW5rYW5nIFlBTyB3cm90ZToNCj4+IA0KPj4gdGhleSBkbyBub3Qgc2F5IHRoYXQgd2UgbXVz dCBjaGFuZ2UgdGhlIGRucy4gdGhleSBmZWVsIHRoYXQgdGhlIHByb3Zpc2lvbiBpcyBqdXN0IGEg c2hvcnQgdGVybSBzbG91dGlvbiwgbm90IGFuIGlkZWFsIHNvbHV0aW9uLg0KPj4gDQo+IA0KPiBS aWdodC4gIEJ1dCB0aGlzIFdHIGlzbid0IGFib3V0IHRoZSBpZGVhbCBzb2x1dGlvbi4gIFRoZSBp ZGVhbA0KPiBzb2x1dGlvbiBpbnZvbHZlcyByZXBsYWNpbmcgRE5TIHdpdGggYSBjb21wbGV0ZWx5 IG5ldyBwcm90b2NvbCB0aGF0IGlzDQo+IGludGVybmF0aW9uYWxpemVkIGZyb20gdGhlIGdyb3Vu ZCB1cC4gIEkgaGF2ZSBwcmV2aW91c2x5IHN1Z2dlc3RlZA0KPiB0aGF0IHBlb3BsZSB3aG8gd2Fu dCB0byBkbyB0aGF0IHNob3VsZCBzdGFydCB3b3JrIG9uIGl0LCBwZXJoYXBzIHdpdGgNCj4gYSBi YXIgQk9GIG9yIHNvbWV0aGluZy4gIEkgZG9uJ3QgcHJlZGljdCBzdWNjZXNzLCBidXQgSSB3aXNo IHN1Y2ggYW4NCj4gZWZmb3J0IHdlbGwuDQo+IA0KDQppZiB3ZSBkb24ndCB1c2UgZG5zLCBpY2Fu biBtYXkgZGlzYXBwZWFyLg0KDQp0aGUgZWZmb3J0cyB3aXRob3V0IGRucyBzaG91bGQgYmFzZSBv biB0aGUgbmV4dCBnZW5lcmF0aW9uIG9mIGludGVybmV0Lg0KDQpjdXJyZW50IG5hbWUgcmVzb2x1 dGlvbiBpcyBiYXNlZCBvbiBkbnMuIHNvIHdlIGhhdmUgdG8gZG8gc29tZXRoaW5nIGJhc2VkIG9u IGRucy4NCg0KaWYgd2UgdHJ5IHRvICBzaGllZCBhd2F5IGZyb20gdGhpcyBxdWVzdGlvbiwgIGl0 IGlzICBmYWlsaW5nIGluIG91ciBkdXR5IHRvIG1ha2UgZG5zIHdvcmsgZm9yIGFsbCB0aGUgaW50 ZXJuZXQgdXNlcnMuIA0KDQo+DQo+PiB5b3UgbWF5IHRha2UgYSBsb29rIGF0IHRoZSBmb2xsb3dp bmcgbGluazoNCj4+IA0KPj4gVGluYSBmcm9tIElDQU5OIGhhcyBhIHJlcG9ydCBpbiBCcnVzc2Vs cyBtZWV0aW5nLiB0aGlzIG1heSBoZWxwIHVzIHRvIHVuZGVyc3RhbmQgaXQuDQo+PiANCj4+IGh0 dHBzOi8vYnJ1c3NlbHMzOC5pY2Fubi5vcmcvbWVldGluZ3MvYnJ1c3NlbHMyMDEwL3ByZXNlbnRh dGlvbi1pZG5zLWRhbS0yM2p1bjEwLWVuLnBkZg0KPiANCj4gSSBoYWQgYSBsb29rIGF0IHRoYXQu ICBJIGFsc28gbGlzdGVuZWQgdG8gdGhlIGF1ZGlvY2FzdCB3aGVuIFRpbmEgbWFkZQ0KPiB0aGF0 IHByZXNlbnRhdGlvbi4gIEl0IHN0aWxsIGRvZXNuJ3QgdGVsbCBtZSBtdWNoLiANCj4gDQo+IEhl cmUgYXJlIHRoZSByZWxldmFudCBiaXRzOg0KPiANCj4gU2xpZGUgOCBvdXRsaW5lcyB0aGUgZGlm ZmVyZW50IHdheXMgdGhhdCBwZW9wbGUgdXNlIHRoZSB0ZXJtDQo+ICJ2YXJpYW50Ii4gIEl0IGFs c28gZXhwbGljaXRseSBub3RlcyB0aGF0ICJ0cmFuc2xhdGlvbiIgaXMgbm90DQo+ICJ2YXJpYW50 Iiwgc28gdGhlIHBlb3BsZSB3aG8gd2FudCAiLm9yZyBpbiBhbm90aGVyIGxhbmd1YWdlIiwgd2hh dGV2ZXINCj4gdGhhdCB3b3VsZCBtZWFuLCBhcmUgbm90IGFza2luZyBmb3IgdmFyaWFudHMuDQo+ IA0KPiBTbGlkZSAxMSBzYXlzIHRoYXQgYSBkaWFsb2d1ZSBpcyBuZWVkZWQsIHRoYXQgdGhlIHJl cXVpcmVtZW50cyBoYXZlbid0DQo+IGJlZW4gY29tbXVuaWNhdGVkLCBhbmQgdGhhdCB0aGVyZSBh cmUgYSBjb3VwbGQgcG9zc2libGUgaWRlYXMga2lja2luZw0KPiBhcm91bmQgb25lIG9mIHdoaWNo IGlzIGxvbmcgc3BlY2lmaWVkIGJ1dCBub3Qgd2VsbCB0ZXN0ZWQsIGFuZCBhbm90aGVyDQo+IG9m IHdoaWNoIGlzbid0IGV2ZW4gc3BlY2lmaWVkIHlldC4NCj4gDQo+IFRoYXQncyBpdC4gIFRoYXQn cyBhbGwgdGhlIG91dGxpbmUgb2YgdGhlIGlzc3VlcyB0aGF0IGRpcmVjdGx5DQo+IGltcGluZ2Vz IG9uIHRoZSBETlMgaW4gdGhlIGVudGlyZSBzbGlkZSBkZWNrLiAgVGhlIHJlc3Qgb2YgdGhlDQo+ IGRpc2N1c3Npb24gaXMgYWJvdXQgd2hhdCBtaWdodCBnZXQgcmVnaXN0ZXJlZCBhbmQgd2hhdCB0 aGUgcnVsZXMgbWF5YmUNCj4gb3VnaHQgdG8gYmUuICBCdXQgIm5hbWUgYXZhaWxhYmxlIHNvbWV3 aGVyZSIgY2FuIGJlIGRvbmUgd2l0aA0KPiBwcm92b3Npb25pbmcsIGFuZCBzbyB3ZSBzdGlsbCBk b24ndCBrbm93IHdoeSB0aGF0J3MgaW5hZGVxdWF0ZS4NCj4NCg0KdGhhbmtzIGNoYWlyIGZvciB5 b3VyIGhhcmR3b3JraW5nIC4NCiANCj4NCj4NCj4gTm93LCB5b3UgaGF2ZSBhcmd1ZWQgbW9yZSB0 aGFuIG9uY2UgdGhhdCB3aGF0IGlzIG5lZWRlZCBpcyBhIHByb3RvY29sDQo+IHJ1bGUgdGhhdCBl bmZvcmNlcyB0aGUgc2FtZW5lc3MgYWNyb3NzIGEgZGVsZWdhdGlvbiBib3VuZGFyeSAodGhhdCdz DQo+IHdoYXQgQk5BTUUgaXMgZm9yKS4gIFdoYXQgdGhpcyByZWFsbHkgYW1vdW50cyB0byBpcyBh IGNsYWltIHRoYXQgd2UNCj4gbmVlZCBpbi1wcm90b2NvbCBzdXBwb3J0IHRvIGVuc3VyZSBjb21w bGlhbmNlIHdpdGggYSBwYXJ0aWN1bGFyIHBvbGljeQ0KPiBkZWNpc2lvbi4gIFRoYXQncyBhIGRl ZmVuc2libGUgY2xhaW0gaW4gcHJpbmNpcGxlLCBidXQgaXQgY29tZXMgd2l0aA0KPiB0aGUgb2Js aWdhdGlvbiB0byBleHBsYWluIHdoeSB0aGUgcmVzdCBvZiB0aGUgRE5TIHVzZXJzIG5lZWQgdG8g cGF5DQo+IHRoZSBjb3N0IG9mIHRoaXMgYWRkaXRpb25hbCBmZWF0dXJlIChuZXcgZmVhdHVyZXMg YWx3YXlzIGVudGFpbCBhDQo+IGNvc3QsIGlmIG9ubHkgb2YgZGV2ZWxvcG1lbnQgYW5kIHRlc3Rp bmcpIGFuZCB3aHkgYWx0ZXJuYXRpdmVzIGFyZW4ndA0KPiBqdXN0IGFzIGdvb2QuICBUaG9zZSBh cmd1bWVudHMgaGF2ZW4ndCBzbyBmYXIgYmVlbiBjbGVhciBlbm91Z2gsIEkNCj4gdGhpbmssIHRv IG1ha2UgdGhlIGNhc2UuDQo+DQoNCjEuIHRoZXJlIGhhcyBiaWxsaW9ucyBvZiBpbnRlcm5ldCB1 c2VycyB3aG8gdXNlIElETiBpbnN0ZWFkIG9mIG1pbGxpb25zLg0KMi4gY3VycmVudCBJRE4gVExE IG9yIElETiBuZWVkIGl0Lg0KMy4gUHJvdmlzaW9uIG1heSB3b3JrIGluIHRoZSBvbmUtbGV2ZWwg ZG9tYWluIG5hbWVzIG9yIG9uIG9uZSB6b25lLiBpdCBjYW4gbm90IHdvcmsgZm9yIGFsbCBsZXZl bHMgZG9tYWluIG5hbWVzIGlmIHRoZXJlIGFyZSBkZWxlZ2F0aW9ucyBvZiB0aGUgY2hpbGRyZW4g bmFtZXMgb2YgZGlmZmVyZW50IGxldmVscy4NCjQuIGJlZm9yZSBJRE4gYXBwZWFycywgd2UgbWF5 IGFzayB0aGUgc2FtZSBxdWVzdGlvbiAiQUJDLmV4YW1wbGUgaXMgb2ssIHdoeSB0aGVyZSBzaG91 bGQgaGF2ZSBJRE4uZXhhbXBsZT8iDQo1LiBuYW1lIGVxdWl2YWxlbmNlIGluIHRoZSBzZW5zZSBv ZiBpZGVudGljYWwgcmVzb2x1dGlvbiBpcyBhIGdlbmVyYWwtcHVycG9zZSBmdW5jdGlvbiBvZiBE TlMuIElETiBpcyBhIGp1c3QgZ29vZCB1c2VyIGNhc2Ugb2YgaXQuIG91ciBwcm9wb3NlZCBzb2x1 dGlvbiBpcyBhIGdlbmVyYWwgc29sdXRpb24gZm9yIGFsbCBuYW1lcy4NCjYuIE5ldyB0ZWNobm9s b2dpZXMsIHRvb2xzIG9yIHByb2R1Y3RzIGFyZSBub3QgYWx3YXlzIGludGVyZXN0ZWQgYXQgdGhl IGJlZ2lubmluZywgdXNlcnMgYXJlIGVubGlnaHRlbmVkIGFuZCBndWlkZWQgdG8gZ2V0IG1vcmUg YW5kIG1vcmUgaW52b2x2ZWQuDQo3LiAgU29tZSByZXF1aXJlbWVubXRzIG1pZ2h0IGJlIG9ubHkg b3Igbm90IGVhc2lseSBvYnNlcnZlZCBieSBzb21lIG9mIHVzLCBidXQgdGhlcmUgaGFzIGEgcmVx dWlyZW1lbnQuIElmIHdlIG9ubHkgZG8gdGhpbmdzIHdoaWNoIGFyZSB1cmdlbnRseSBuZWVkZWQg d2hlbiB0aGUgcmVxdWlyZW1lbm10cyBjb3VsZCBiZSBvYnNlcnZlZCBieSBhbGwsIGkgZ3Vlc3Mg bWF5YmUsIHdlIG5vdyBoYWQgYSB0b3RhbGx5IGRpZmZlcmVudCB3b3JsZC4NCjguIFNpbmNlIGlk ZW50aWNhbCByZXNvbHV0aW9uIGlzIG5lZWRlZCBkZWZpbml0ZWx5IGJ5IHRoZSBJRE4gdXNlcnMg Tk9XIGFuZCwgbW9yZSBvciBsZXNzIG5lZWRlZCBieSBvdGhlcnMgaW4gdGhlIGZ1dHVyZS4NCg0K DQpKaWFua2FuZyBZYW8NCg0KDQoNCj4NCj4gDQo+IE15IGN1cnJlbnQsIHBlcnNvbmFsIHRoaW5r aW5nIGlzIGFsb25nIHRoZSBsaW5lcyBKb2UgQWJsZXkgcG9zdGVkDQo+IHVwLXRocmVhZC4gIFdl IG5lZWQgdG8gZ2V0IGEgY29tcGxldGUgcGljdHVyZSBvZiBhbGwgdGhlIHRoaW5ncyB0aGF0DQo+ IGNhbiBpbiBmYWN0IGJlIGRvbmUgcmlnaHQgbm93LCBhbmQgYWxsIHRoZSB0aGluZ3MgdGhhdCBw ZW9wbGUgd2FudCB0bw0KPiBiZSBhYmxlIHRvIGRvLCBhcyBuZWFyIGFzIHdlIGNhbiBwdXQgdGhh dCB0b2dldGhlcjsgd2UgY29tYmluZSB3aXRoDQo+IHRob3NlIGEgbGlzdCBvZiBhbGwgdGhlIGtu b3duIHNpZGUtZWZmZWN0cyBvZiB0aGVzZSBzdHJhdGVnaWVzLiAgV2UNCj4gcG9pbnQgdGhlIHBl b3BsZSB3aG8gd2UgdGhpbmsgaGF2ZSBpc3N1ZXMgaGVyZSwgYW5kIHRyeSB0byBmaW5kIG91dA0K PiB3aGV0aGVyIHRoZXkgdW5kZXJzdGFuZCB0aGUgbWVzc2FnZS4NCj4gDQo+IE9ubHkgYWZ0ZXIg dGhhdCB3b3JrIGlzIHNob3dpbmcgc29tZSBlZmZlY3RzIGRvIHdlIHVuZGVydGFrZSBjaGFuZ2Vz DQo+IHRvIHRoZSBwcm90b2NvbC4NCj4gDQo+IERvZXMgdGhhdCBhcHByb2FjaCBtYWtlIHNlbnNl Pw0KPiANCj4gQQ0KPiANCj4gLS0gDQo+IEFuZHJldyBTdWxsaXZhbg0KPiBhanNAc2hpbmt1cm8u Y29tDQo+IFNoaW5rdXJvLCBJbmMuDQo+ From owner-namedroppers@ops.ietf.org Tue Aug 31 20:38: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 4DDEF3A6836; Tue, 31 Aug 2010 20:38: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: 0.618 X-Spam-Level: X-Spam-Status: No, score=0.618 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ax9A5VrivTUC; Tue, 31 Aug 2010 20:38:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A06033A68C4; Tue, 31 Aug 2010 20:38:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oqe6e-000Aqe-Ng for namedroppers-data0@psg.com; Wed, 01 Sep 2010 03:35:24 +0000 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Oqe6X-000Aq1-RZ for namedroppers@ops.ietf.org; Wed, 01 Sep 2010 03:35:18 +0000 Received: (eyou send program); Wed, 01 Sep 2010 11:35:15 +0800 Message-ID: <483312115.01005@cnnic.cn> X-EYOUMAIL-SMTPAUTH: wangxin@cnnic.cn Received: from unknown (HELO cindy) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 01 Sep 2010 11:35:15 +0800 Date: Wed, 1 Sep 2010 11:33:40 +0800 From: "Cindy Wang" To: "Jiankang YAO" , "Andrew Sullivan" , "namedroppers@ops.ietf.org" References: , , <483158956.02282@cnnic.cn>, <328DCC4D8C7C45A1A31B5759A3C9442C@LENOVO47E041CF>, <20100830224638.GG24538@shinkuro.com>, <535EA9D909F740B6A2EF59E77AA12441@LENOVO47E041CF>, <20100831164624.GO24538@shinkuro.com>, <483311512.04100@cnnic.cn> Subject: Re: Re: A next step? (was: [dnsext] Re: DNSEXT charter and treating DNSnames as "thesame") Message-ID: <201009011133370933199@cnnic.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] 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: 8. Since identical resolution is needed definitely by the IDN users NOW and, more or less needed by others in the future. And, identical resolution should happen at both the nodes and their sub-trees, which couldn't be achieved by provision anyway. Am i right? Cindy Wang CNNIC From owner-namedroppers@ops.ietf.org Tue Aug 31 23:41: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 395653A6908; Tue, 31 Aug 2010 23:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.282 X-Spam-Level: X-Spam-Status: No, score=-1.282 tagged_above=-999 required=5 tests=[AWL=1.317, 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 IpRyNYBXxNgV; Tue, 31 Aug 2010 23:41:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5567B3A68EA; Tue, 31 Aug 2010 23:41:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqguH-000Gqs-D5 for namedroppers-data0@psg.com; Wed, 01 Sep 2010 06:34:49 +0000 Received: from mail.avalus.com ([89.16.176.221]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqguA-000GjU-Qh for namedroppers@ops.ietf.org; Wed, 01 Sep 2010 06:34:43 +0000 Received: from [195.173.23.106] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id D9C18C5695C; Wed, 1 Sep 2010 07:34:37 +0100 (BST) Date: Wed, 01 Sep 2010 07:34:40 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jiankang YAO , Paul Hoffman cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Message-ID: <3FB09F27DA1352CBED9F9E0B@nimrod.local> In-Reply-To: <483304209.23695@cnnic.cn> References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <5831A1FCBAF9396EF92D3914@nimrod.local> <49228.1283199781@nsa.vix.com> <232890023F1F44341FAD59F5@nimrod.local> <60220.1283211506@nsa.vix.com> <483213682.08432@cnnic.cn> <483224586.22087@cnnic.cn> <483268756.23705@cnnic.cn> <483304209.23695@cnnic.cn> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 1 September 2010 09:23:36 +0800 Jiankang YAO wrote: > if the internet users think that name A and B are variants or alias, > the problem is that "name A and B needs to get the same DNS resolution > result". > > The question is not whether A and B are the same. if you think that the > problem is that "The question is whether A and B are the same. ", > > that may not be clear. but defining of whether or why A and B are the > same is out of our wg. > > our job is to make name A and B get the same DNS resolution result if > the users need to do so. Disagree. This begs the question. At the very least at the investigation stage we need to determine whether want the same DNS result or applications to perform the same, as these two diverge. -- Alex Bligh From owner-namedroppers@ops.ietf.org Tue Aug 31 23:57: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 35E5D3A6AAB; Tue, 31 Aug 2010 23:57:31 -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: -99.186 X-Spam-Level: X-Spam-Status: No, score=-99.186 tagged_above=-999 required=5 tests=[AWL=0.816, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, 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 CWOze7Nj4Zix; Tue, 31 Aug 2010 23:57:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C9923A6AFE; Tue, 31 Aug 2010 23:57:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqhCk-000K5I-AI for namedroppers-data0@psg.com; Wed, 01 Sep 2010 06:53:54 +0000 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OqhCd-000K4k-K8 for namedroppers@ops.ietf.org; Wed, 01 Sep 2010 06:53:48 +0000 Received: (eyou send program); Wed, 01 Sep 2010 14:53:42 +0800 Message-ID: <483324022.02547@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, 01 Sep 2010 14:53:42 +0800 Message-ID: <0C726E96311B409EBC75282D84EF3920@LENOVO47E041CF> From: "Jiankang YAO" To: "Alex Bligh" , "Paul Hoffman" Cc: , "Alex Bligh" References: <20100830084434.GA20399@nic.fr> <34484.1283184615@nsa.vix.com> <5831A1FCBAF9396EF92D3914@nimrod.local> <49228.1283199781@nsa.vix.com> <232890023F1F44341FAD59F5@nimrod.local> <60220.1283211506@nsa.vix.com> <483213682.08432@cnnic.cn> <483224586.22087@cnnic.cn> <483268756.23705@cnnic.cn> <483304209.23695@cnnic.cn> <483322881.01002@cnnic.cn> Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same") Date: Wed, 1 Sep 2010 14:53:50 +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.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsZXggQmxpZ2giIDxhbGV4 QGFsZXgub3JnLnVrPg0KVG86ICJKaWFua2FuZyBZQU8iIDx5YW9qa0Bjbm5pYy5jbj47ICJQYXVs IEhvZmZtYW4iIDxwYXVsLmhvZmZtYW5AdnBuYy5vcmc+DQpDYzogPG5hbWVkcm9wcGVyc0BvcHMu aWV0Zi5vcmc+OyAiQWxleCBCbGlnaCIgPGFsZXhAYWxleC5vcmcudWs+DQpTZW50OiBXZWRuZXNk YXksIFNlcHRlbWJlciAwMSwgMjAxMCAyOjM0IFBNDQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gcmVn dWxhdG9yeSBwcm9ibGVtIHN0YXRlbWVudCAod2FzIFJlOiAuLi4gYXMgInRoZSBzYW1lIikNCg0K DQo+IA0KPiANCj4gLS1PbiAxIFNlcHRlbWJlciAyMDEwIDA5OjIzOjM2ICswODAwIEppYW5rYW5n IFlBTyA8eWFvamtAY25uaWMuY24+IHdyb3RlOg0KPiANCj4+IGlmIHRoZSBpbnRlcm5ldCB1c2Vy cyB0aGluayB0aGF0IG5hbWUgQSBhbmQgQiBhcmUgdmFyaWFudHMgb3IgYWxpYXMsDQo+PiB0aGUg cHJvYmxlbSBpcyB0aGF0ICJuYW1lIEEgYW5kIEIgbmVlZHMgdG8gIGdldCB0aGUgc2FtZSBETlMg cmVzb2x1dGlvbg0KPj4gcmVzdWx0Ii4NCj4+DQo+PiBUaGUgcXVlc3Rpb24gaXMgbm90IHdoZXRo ZXIgQSBhbmQgQiBhcmUgdGhlIHNhbWUuICBpZiB5b3UgdGhpbmsgdGhhdCB0aGUNCj4+IHByb2Js ZW0gaXMgdGhhdCAiVGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgQSBhbmQgQiBhcmUgdGhlIHNhbWUu ICIsDQo+Pg0KPj4gdGhhdCBtYXkgbm90IGJlIGNsZWFyLiBidXQgZGVmaW5pbmcgb2Ygd2hldGhl ciBvciB3aHkgQSBhbmQgQiBhcmUgdGhlDQo+PiBzYW1lIGlzIG91dCBvZiBvdXIgd2cuDQo+Pg0K Pj4gb3VyIGpvYiBpcyB0byBtYWtlIG5hbWUgQSBhbmQgQiAgZ2V0IHRoZSBzYW1lIEROUyByZXNv bHV0aW9uIHJlc3VsdCBpZg0KPj4gdGhlIHVzZXJzIG5lZWQgdG8gZG8gc28uDQo+IA0KPiBEaXNh Z3JlZS4gVGhpcyBiZWdzIHRoZSBxdWVzdGlvbi4gQXQgdGhlIHZlcnkgbGVhc3QgYXQgdGhlIGlu dmVzdGlnYXRpb24NCj4gc3RhZ2Ugd2UgbmVlZCB0byBkZXRlcm1pbmUgd2hldGhlciB3YW50IHRo ZSBzYW1lIEROUyByZXN1bHQgb3IgYXBwbGljYXRpb25zDQo+IHRvIHBlcmZvcm0gdGhlIHNhbWUs IGFzIHRoZXNlIHR3byBkaXZlcmdlLg0KPiANCg0KIndhbnQgdGhlIHNhbWUgRE5TIHJlc3VsdCAi ICBmYWxsIGluIHRoZSBzY29wZSBvZiB0aGlzIHdnLg0KDQogZG9lcyAiYXBwbGljYXRpb25zIHRv IHBlcmZvcm0gdGhlIHNhbWUiIGZhbGwgaW4gdGhpcyB3Zz8NCg0KSmlhbmthbmcgWWFvIA0KDQo+ IC0tIA0KPiBBbGV4IEJsaWdo