From owner-namedroppers@ops.ietf.org Mon Jun 1 01:47:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44033A6C87; Mon, 1 Jun 2009 01:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYtu21lsN60b; Mon, 1 Jun 2009 01:47:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CAC183A6C0D; Mon, 1 Jun 2009 01:47:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB33K-00021v-1o for namedroppers-data0@psg.com; Mon, 01 Jun 2009 08:39:30 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB338-00020j-So for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 08:39:24 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MB333-0004tC-B7; Mon, 01 Jun 2009 10:39:13 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MB332-0002eP-Ux; Mon, 01 Jun 2009 10:39:12 +0200 From: Florian Weimer To: Francis Dupont Cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT chair , namedroppers@ops.ietf.org Subject: Re: [dnsext] Draft DNSEXT charter References: <200905312152.n4VLqAi5055385@givry.fdupont.fr> Date: Mon, 01 Jun 2009 10:39:12 +0200 In-Reply-To: <200905312152.n4VLqAi5055385@givry.fdupont.fr> (Francis Dupont's message of "Sun, 31 May 2009 23:52:10 +0200") Message-ID: <87ab4spcun.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Francis Dupont: > In your previous mail you wrote: > > * Francis Dupont: > > > PS: I am sure you know it is critical to get this published and > > implemented before 2010. > > This time frame is impossible to achieve due to the dependency on > NSEC3. > > => can you detail? Do you mean it is impossible to get it published > in time? implemented? Or the issue is begin/end of 2010 Wide deployment is two to three years away. The NSEC3 upgrade is too large to put in a point release. Adding a new cryptographic algorithm might have been possible. I don't think this is a technical problem. (It may be a compliance issue.) It just sugests that DNSSEC doesn't offer that much algorithm agility. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 07:26:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F093A71C7; Mon, 1 Jun 2009 07:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.925 X-Spam-Level: X-Spam-Status: No, score=-102.925 tagged_above=-999 required=5 tests=[AWL=3.675, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDL905rajkK8; Mon, 1 Jun 2009 07:26:13 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id AA86E3A717F; Mon, 1 Jun 2009 07:24:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB8KF-00048h-RU for namedroppers-data0@psg.com; Mon, 01 Jun 2009 14:17:19 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB8Jw-000471-UE for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 14:17:06 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n51EGxi7002414 for ; Mon, 1 Jun 2009 10:16:59 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n51EGxHX002413 for namedroppers@ops.ietf.org; Mon, 1 Jun 2009 10:16:59 -0400 (EDT) (envelope-from namedroppers) Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAgOM-000684-RT for namedroppers@ops.ietf.org; Sun, 31 May 2009 08:27:48 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MAgOI-0007Ez-5B; Sun, 31 May 2009 10:27:38 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MAgOH-0002Ca-L3; Sun, 31 May 2009 10:27:37 +0200 From: Florian Weimer To: Matthew Dempsky Cc: Paul Hoffman , Federico Lucifredi , "namedroppers\@ops.ietf.org" Subject: Re: [dnsext] DNSCURVE References: <3efd34cc0905151502u2df6284eid71f8da14fb77ce1@mail.gmail.com> <20090516000313.GA19843@vacation.karoshi.com.> <4A0E307D.3060208@acm.org> <4A0EEC5A.2020708@post.harvard.edu> Date: Sun, 31 May 2009 10:27:37 +0200 In-Reply-To: (Matthew Dempsky's message of "Sat, 16 May 2009 12:03:56 -0700") Message-ID: <878wkd65ja.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Matthew Dempsky: > If you have questions about DNSCurve that are not adequately answered > by the dnscurve.org web site, then I'll be happy to try to answer them > here. How is the cryptographic box created? I can't find information on that on the web pages, only the key agreement protocol is described. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 07:26:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21FD3A71CC; Mon, 1 Jun 2009 07:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=-1.215, 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 GdtrMLFYWCku; Mon, 1 Jun 2009 07:26:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1CE6F3A6863; Mon, 1 Jun 2009 07:24:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB8K4-00047h-0H for namedroppers-data0@psg.com; Mon, 01 Jun 2009 14:17:08 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB8Jo-00046b-6V for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 14:17:02 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n51EGnHN002408 for ; Mon, 1 Jun 2009 10:16:49 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n51EGnj6002407 for namedroppers@ops.ietf.org; Mon, 1 Jun 2009 10:16:49 -0400 (EDT) (envelope-from namedroppers) Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAgB1-0005PK-41 for namedroppers@ops.ietf.org; Sun, 31 May 2009 08:14:03 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MAgAi-0006na-9J; Sun, 31 May 2009 10:13:36 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MAgAh-00029y-Ly; Sun, 31 May 2009 10:13:35 +0200 From: Florian Weimer To: Alex Bligh Cc: Paul Hoffman , Nicholas Weaver , Matthew Dempsky , Stephane Bortzmeyer , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: DNSCURVE References: <4A0E307D.3060208@acm.org> <4A0EEC5A.2020708@post.harvard.edu> <20090518081043.GC936@nic.fr> Date: Sun, 31 May 2009 10:13:35 +0200 In-Reply-To: (Alex Bligh's message of "Mon, 18 May 2009 19:44:08 +0100") Message-ID: <87k53x666o.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Alex Bligh: > But, if I understand it, only one particular ECC scheme > is specified in DNSCurve (i.e. there is no algorithm agility) and > we don't have an IPR statement on it (or at least not in the IETF > required manner). There is algorithm agility in DNSCurve: You just use a different name (or label) prefix for a different algorithm. There's a limit on the number of bits you can transmit (probably around 600 per name server), but there's still plenty of room for extensions. Compare this to DNSSEC, where it takes at least three years to standardize (not even implement and deploy) a non-controversial hash function replacement. And there is some sentiment (perhaps not consensus) in the WG that having more than one signature algorithm in wide production use is undesirable (or maybe not even technically feasible). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 07:26:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148A33A6C26; Mon, 1 Jun 2009 07:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7FD7xccLxFw; Mon, 1 Jun 2009 07:26:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B66FD3A7180; Mon, 1 Jun 2009 07:24:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB8Jg-00045u-Cw for namedroppers-data0@psg.com; Mon, 01 Jun 2009 14:16:44 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB8JS-00043m-KT for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 14:16:38 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n51EGRVI002400 for ; Mon, 1 Jun 2009 10:16:27 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n51EGRfQ002399 for namedroppers@ops.ietf.org; Mon, 1 Jun 2009 10:16:27 -0400 (EDT) (envelope-from namedroppers) Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAW30-000K8o-Am for namedroppers@ops.ietf.org; Sat, 30 May 2009 21:25:03 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id EDC18A3DAD; Sat, 30 May 2009 21:24:57 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: =?us-ascii?Q?=3D=3Fiso-8859-1=3FQ=3F=3DD3lafur=3F=3D_=3D=3Fiso-8859-1?= =?us-ascii?Q?=3FQ=3F=5FGu=3DF0mundsson=3F=3D?= /DNSEXT chair cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Draft DNSEXT charter In-Reply-To: Your message of "Fri\, 29 May 2009 11\:56\:59 -0400." <200905291557.n4TFv4ek030806@stora.ogud.com> References: <200905291557.n4TFv4ek030806@stora.ogud.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sat, 30 May 2009 21:24:57 +0000 Message-ID: <74782.1243718697@nsa.vix.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Fri, 29 May 2009 11:56:59 -0400 > From: =D3lafur Gu=F0mundsson /DNSEXT=20 > chair >=20 > Milestones are preliminary and will be updated based on WG discussion. >=20 > Comments please, > ... > Milestones: > Jun 2009 TSIG/MD5 Obsoleting to IESG. > Jul 2009 AXFR Clarify to IESG > Sep 2009 EDNS0 Ping Option advanced to IESG > Oct 2009 Resolver side Forgery Resilience advanced to IESG > Oct 2009 DNSSEC Errata document to IESG > Nov 2009 GOST DNSKEY and DS support advanced to IESG > Dec 2009 ENDS0-bis update advanced to IESG IMHO, EDNS0 Ping would not add any actual security. can this be changed to say something like "Sep 2009 - forgery resilience protocol advanced to IESG" so that we're open to defining an SCTP transport profile, and we're open to defining an TKEY-DH + TSIG use profile, and still hit the objective? btw, i'm looking for co-authors for an DNS over SCTP transport profile doc, and a TKEY-DH + TSIG use profile doc. i'll want to get both done in the first three weeks of july (before blackhat/defcon). help? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 07:27:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808753A6BD8; Mon, 1 Jun 2009 07:27:07 -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 G45pp78HDk7G; Mon, 1 Jun 2009 07:27:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 25B4D3A719B; Mon, 1 Jun 2009 07:26:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB8Ls-0004IE-8i for namedroppers-data0@psg.com; Mon, 01 Jun 2009 14:19:00 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB8Kg-0004AS-P1 for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 14:17:58 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n51EHjOq002437 for ; Mon, 1 Jun 2009 10:17:45 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n51EHjGJ002436 for namedroppers@ops.ietf.org; Mon, 1 Jun 2009 10:17:45 -0400 (EDT) (envelope-from namedroppers) Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAvqX-000MQX-MH for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 00:57:55 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id CDB8FE601C for ; Mon, 1 Jun 2009 00:57:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n510vkFC090344 for ; Mon, 1 Jun 2009 10:57:46 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906010057.n510vkFC090344@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Support for EDSN0 PING In-reply-to: Your message of "Mon, 01 Jun 2009 00:24:23 GMT." <44462.1243815863@nsa.vix.com> Date: Mon, 01 Jun 2009 10:57:46 +1000 X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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. ] In message <44462.1243815863@nsa.vix.com>, Paul Vixie writes: > > From: Mark Andrews > > Date: Mon, 01 Jun 2009 10:04:24 +1000 > > > > > > * extended RCODEs (but I'm not sure about that) > > > > extended RCODEs were badly done. We should have had a basic > > rcode which indicated that there was a extended rcode in the > > OPT record. Concatentating the bits was a bad idea. > > agreed, but i don't think we'll see a change to this in EDNS1 (or ever.) > > > > > What does not work: > > > > > > > > * the official fallback algorithm (section 5.3) > > > > It actually works quite well 99.999% of the time. It doesn't > > work when you talk to non RFC 1034 compliant servers or you > > have firewalls that interfere with DNS UDP messages. > > > > To work around non-compliant servers and firewalls a second > > fallback algorithm is needed to take into account timeouts. > > maybe a BCP on this would be of general interest to the community? Perhaps. There is still a open question of whether to fall all the way back to plain DNS or not. Fallling back from EDNS@UDP/4096 to EDNS@UDP/512 is relatively uncontroversial and lets EDNS (and DNSSEC) work with firewalls which block IP fragments or DNS UDP messages > 512 bytes. There is still a open question of whether to fall back to plain DNS or not on timeout as it breaks DNSSEC validation. If you don't fallback to plain DNS you break comunication through firewalls that block all EDNS and you block communication to servers that fail to respond to EDNS queries which I believe is non RFC 1034 compliant behaviour. > > > > * large responses (interoperability problems, DoS amplification) > > > > Moving to SCTP won't get rid of the DoS amplification problem > > as we can never stop servicing UDP/53 queries. BCP 38 > > deployment is the best way to stop DoS amplifications. > > BCP38 is even less likely than universal switchover from UDP/53 to SCTP, > so let's take a fresh look. SCTP isn't spoofable in the way UDP/53 is, > so the thing you can get DoS-amp'd with is SCTP setup packets, which are > small and which could potentially be handled by a hardware front end far > upstream of protection-worthy servers. > > in other words SCTP is my hope for making secure robust reliable DNS > connectivity possible for cooperating on-the-ball up-to-date operators, > because otherwise we've just got UDP/53 (with or without EDNS) and > TCP/53, neither of which can be made robust or reliable (ever, period). I'm not objecting to SCTP. Just the arguement that it will stop DoS amplification. It would require a deadline to be published and enforced for when to cease using UDP for iterative queries. I'm assuming that DoS due to recursive queries can be mostly mitigated via acls, tsig or other methods as I don't believe it is feasible to replace all the stub resolvers in the next 20 years. By 2038 we may be able to do it if we can link the replacement with Y2038 compliance. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 07:27:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B4133A7189; Mon, 1 Jun 2009 07:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=-0.701, 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+TRUziOd3el; Mon, 1 Jun 2009 07:27:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 606FD3A7171; Mon, 1 Jun 2009 07:27:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB8Lh-0004HK-Ad for namedroppers-data0@psg.com; Mon, 01 Jun 2009 14:18:49 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB8KM-000493-IR for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 14:17:47 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n51EHOoI002427 for ; Mon, 1 Jun 2009 10:17:24 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n51EHOso002426 for namedroppers@ops.ietf.org; Mon, 1 Jun 2009 10:17:24 -0400 (EDT) (envelope-from namedroppers) Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAv0u-000IPL-Dg for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 00:04:34 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 44088E601C; Mon, 1 Jun 2009 00:04:27 +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 n5104OI9059004; Mon, 1 Jun 2009 10:04:24 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906010004.n5104OI9059004@drugs.dv.isc.org> To: Paul Vixie Cc: Florian Weimer , "Bart Smit" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Support for EDSN0 PING In-reply-to: Your message of "Sun, 31 May 2009 16:03:29 GMT." <21190.1243785809@nsa.vix.com> Date: Mon, 01 Jun 2009 10:04:24 +1000 X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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. ] In message <21190.1243785809@nsa.vix.com>, Paul Vixie writes: > > From: Florian Weimer > > Date: Sun, 31 May 2009 10:44:33 +0200 > > > > * Paul Vixie: > > > > > it's controversial because it only works when it works, and when it > > > fails, there's no distinction between an attack and a failure. we were > > > not idiots back in the old days when EDNS was being crafted. we knew > > > we needed a larger QID. we tried hard to include it. there's no way > > > to do it and still properly negotiate EDNS. > > > > But this is not the fault of any extended query ID proposal, it's the > > fault of EDNS. > > right. > > > DNSCurve shows a fully backwards-compatible way to signal protocol > > version information to recursive resolvers. > > > > I mean, let's look at what elements of EDNS0 actually work: > > > > * extended RCODEs (but I'm not sure about that) extended RCODEs were badly done. We should have had a basic rcode which indicated that there was a extended rcode in the OPT record. Concatentating the bits was a bad idea. > > * extended query flags (the DO bit seems pretty interoperable, even > > though it's overused, but this is not EDNS0's fault) > > > > What does not work: > > > > * the official fallback algorithm (section 5.3) It actually works quite well 99.999% of the time. It doesn't work when you talk to non RFC 1034 compliant servers or you have firewalls that interfere with DNS UDP messages. To work around non-compliant servers and firewalls a second fallback algorithm is needed to take into account timeouts. > > * large responses (interoperability problems, DoS amplification) Moving to SCTP won't get rid of the DoS amplification problem as we can never stop servicing UDP/53 queries. BCP 38 deployment is the best way to stop DoS amplifications. > > * extended label types (already officially dead) > > > > * options (a FORMERR/SERVFAIL does not tell you which option caused > > the error, making fallback impossible; there is also a significant > > non-interoperating server base) > > > > I wonder if there should be an actually working EDNS0 replacement > > which could then be used to implement extended query IDs. > > you forgot "fragmentation is bad". (dnscurve avoids this with small crypto.) DNSCurve still requires fragmentation. Support for 4K UDP buffers messages is implied with DNSCurve. > TCP/53 is unusable for queries for a variety of reasons of its own. > > that's why i'm pounding the table for SCTP/53, on which EDNS wouldn't be > optional, therefore avoiding the fallback problems. EDNS PING isn't needed > in SCTP due to SCTP's own transport protection, but if needed it would work, > since EDNS would not be optional (no fallback problem.) > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 07:47:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BB9C3A6F34; Mon, 1 Jun 2009 07:47:57 -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 HBz1APKL2N6F; Mon, 1 Jun 2009 07:47:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 80E0D3A69B2; Mon, 1 Jun 2009 07:47:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB8jW-0006qQ-FS for namedroppers-data0@psg.com; Mon, 01 Jun 2009 14:43:26 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB8jL-0006ov-DI for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 14:43:21 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n51Eh7Uu002896; Mon, 1 Jun 2009 10:43:08 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906011443.n51Eh7Uu002896@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 01 Jun 2009 10:22:54 -0400 To: Paul Vixie From: Olafur Gudmundsson Subject: Re: [dnsext] Draft DNSEXT charter Cc: namedroppers@ops.ietf.org In-Reply-To: <74782.1243718697@nsa.vix.com> References: <200905291557.n4TFv4ek030806@stora.ogud.com> <74782.1243718697@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 17:24 30/05/2009, Paul Vixie wrote: > > Date: Fri, 29 May 2009 11:56:59 -0400 > > From: =D3lafur Gu=F0mundsson /DNSEXT > > chair > > > > Milestones are preliminary and will be updated based on WG discussion. > > > > Comments please, > > ... > > Milestones: > > Jun 2009 TSIG/MD5 Obsoleting to IESG. > > Jul 2009 AXFR Clarify to IESG > > Sep 2009 EDNS0 Ping Option advanced to IESG > > Oct 2009 Resolver side Forgery Resilience advanced to IESG > > Oct 2009 DNSSEC Errata document to IESG > > Nov 2009 GOST DNSKEY and DS support advanced to IESG > > Dec 2009 ENDS0-bis update advanced to IESG > >IMHO, EDNS0 Ping would not add any actual security. can this be changed to >say something like "Sep 2009 - forgery resilience protocol advanced to= IESG" >so that we're open to defining an SCTP transport profile, and we're open to >defining an TKEY-DH + TSIG use profile, and still hit the objective? This is a good suggestion, but if we open up the space to new transports I will move this milestone a little back how about: Dec 2009 Hardening against on-the-wire Forgery advanced to IESG Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 07:56:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23B093A6FAC; Mon, 1 Jun 2009 07:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+z+6La08G6K; Mon, 1 Jun 2009 07:56:04 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 5FCA728C20C; Mon, 1 Jun 2009 07:54:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB8rI-0007mo-9a for namedroppers-data0@psg.com; Mon, 01 Jun 2009 14:51:28 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB8r6-0007lS-U8 for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 14:51:22 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 20BE22FE9636 for ; Mon, 1 Jun 2009 14:51:14 +0000 (UTC) Date: Mon, 1 Jun 2009 10:51:12 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Draft DNSEXT charter Message-ID: <20090601145108.GA14798@shinkuro.com> References: <200905291557.n4TFv4ek030806@stora.ogud.com> <20090529231146.GA13071@vacation.karoshi.com.> <20090530012258.GA13757@shinkuro.com> <20090530042851.GA15364@vacation.karoshi.com.> <20090530162831.GA19893@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090530162831.GA19893@vacation.karoshi.com.> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, May 30, 2009 at 04:28:31PM +0000, bmanning@vacation.karoshi.com wrote: > > >On Fri, May 29, 2009 at 09:22:58PM -0400, Andrew Sullivan wrote: > > > > Is there something about the correctness of implementation that is > > >> different from "clarifications" to the protocol? > thats updating a spec, not doing implementation conformance. So you seem to be sort of answering the question I asked by saying that any time one checks implementations, finds that they are all conforming and yet different in behaviour, and issues a clarification to pick one behaviour, one changes the specification. You seem to think this is ok, and that it is within the purview of the WG. Correct? > two different implementations of RFC 1034 can follow that spec > correctly and yet not be interoperable. Do you think that such a case is something we want to fix -- to disambiguate, thereby decreeing which interpretation of the apparently-ambiguous RFC is to be the one to use? If so, do you think it is work this WG should have under its chartered responsibilities, or do you think that work should go elsewhere? Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 08:17:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52293A6D8E; Mon, 1 Jun 2009 08:17:48 -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 uWN-LOz7qv5x; Mon, 1 Jun 2009 08:17:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C00A33A6A19; Mon, 1 Jun 2009 08:17:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB9Cj-0009oa-Jv for namedroppers-data0@psg.com; Mon, 01 Jun 2009 15:13:37 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB9CY-0009nR-C9 for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 15:13:31 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 08B84A4078; Mon, 1 Jun 2009 15:13:26 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Mark Andrews cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Support for EDSN0 PING In-Reply-To: Your message of "Mon, 01 Jun 2009 10:57:46 +1000." <200906010057.n510vkFC090344@drugs.dv.isc.org> References: <200906010057.n510vkFC090344@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 01 Jun 2009 15:13:26 +0000 Message-ID: <80122.1243869206@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Mark Andrews > Date: Mon, 01 Jun 2009 10:57:46 +1000 > ... > > maybe a BCP on this would be of general interest to the community? > > Perhaps. There is still a open question of whether to fall all the way > back to plain DNS or not. > > Fallling back from EDNS@UDP/4096 to EDNS@UDP/512 is relatively > uncontroversial and lets EDNS (and DNSSEC) work with firewalls which > block IP fragments or DNS UDP messages > 512 bytes. > > There is still a open question of whether to fall back to plain DNS or > not on timeout as it breaks DNSSEC validation. If you don't fallback to > plain DNS you break comunication through firewalls that block all EDNS > and you block communication to servers that fail to respond to EDNS > queries which I believe is non RFC 1034 compliant behaviour. it is now long past time to address, dare i say close, these open questions, and move on. we need more deployment, and we need all of the deployers to have all of the protocol intelligence that exists, and so let's see the knowledge of the early/present deployers shared. RFC2671bis is on the docket, let's add a whole section about fallback experiences and recommendations, peer reviewed by this working group so as to keep out whacky or creative or new ideas, and focus only on what's been shown/known to work well. > > in other words SCTP is my hope for making secure robust reliable DNS > > connectivity possible for cooperating on-the-ball up-to-date operators, > > because otherwise we've just got UDP/53 (with or without EDNS) and > > TCP/53, neither of which can be made robust or reliable (ever, period). > > I'm not objecting to SCTP. Just the arguement that it will stop DoS > amplification. It would require a deadline to be published and enforced > for when to cease using UDP for iterative queries. I'm assuming that DoS > due to recursive queries can be mostly mitigated via acls, tsig or other > methods as I don't believe it is feasible to replace all the stub > resolvers in the next 20 years. By 2038 we may be able to do it if we > can link the replacement with Y2038 compliance. what i expect will happen is that hardware-assisted forwarding boxes far upstream of the nameservers will do UDP/53 ingress traffic shaping, like "no more than 10K QPS per destination IP if it's UDP/53" and that a DoS against this path will absolutely wipe out UDP/53 just as it does today; however, cooperating up-to-date operators who have deployed SCTP will be able to continue exchanging traffic with others who have done so. SCTP can still be DoS'd, because internet links can still be DoS'd, and there is no fix for a flood so strong it fills up the only links you've got between you and everybody else. but SCTP itself is less fragile than UDP, and it ought to require a completely swamped link to keep it from working, unlike UDP/53 or TCP/53 for which a perfectly effective DoS flow can be created with far less than full link bandwidth. so i'm not arguing that SCTP will stop DoS amplification, only that it will raise the costs for attackers and provide more control points for defenders, and that neither UDP/53 nor TCP/53 can offer anything similar to it, no matter how we alter or improve EDNS. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From deprecatescb@katonahscentral.com Mon Jun 1 09:41:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1E83A6E5B; Mon, 1 Jun 2009 09:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.783 X-Spam-Level: X-Spam-Status: No, score=-33.783 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, HS_INDEX_PARAM=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGqZmL6+vpmZ; Mon, 1 Jun 2009 09:40:59 -0700 (PDT) Received: from mail.faubionassoc.com (mail.faubionassoc.com [74.212.188.18]) by core3.amsl.com (Postfix) with ESMTP id 8B21728C1AB; Mon, 1 Jun 2009 09:40:40 -0700 (PDT) Received: from 74.212.188.18 by inbound.katonahscentral.com.netsolmail.net; Mon, 1 Jun 2009 11:40:35 -0600 Date: Mon, 1 Jun 2009 11:40:35 -0600 From: calsch-archive@lists.ietf.org X-Mailer: The Bat! (v3.62.14) Professional Reply-To: deprecatescb@katonahscentral.com X-Priority: 3 (Normal) Message-ID: <549345164.15460639291888@katonahscentral.com> To: calsch-archive@lists.ietf.org Subject: Get Thin Easily with Acai Berry MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Acai berry will allow you to lose your undesired wieght. Step To Visit http://www.vopiske.com/?woxswxvflmonh best regards Lawrence Long From owner-namedroppers@ops.ietf.org Mon Jun 1 10:05:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3053A6ADE; Mon, 1 Jun 2009 10:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A783KvZaUYMa; Mon, 1 Jun 2009 10:05:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 94CF13A68AC; Mon, 1 Jun 2009 10:05:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBAqk-000JZ5-MG for namedroppers-data0@psg.com; Mon, 01 Jun 2009 16:59:02 +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.69 (FreeBSD)) (envelope-from ) id 1MBAqY-000JYK-QL for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 16:58:56 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n51GwjFi060547; Mon, 1 Jun 2009 18:58:45 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200906011658.n51GwjFi060547@givry.fdupont.fr> From: Francis Dupont To: Florian Weimer cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT chair , namedroppers@ops.ietf.org Subject: Re: [dnsext] Draft DNSEXT charter In-reply-to: Your message of Mon, 01 Jun 2009 10:39:12 +0200. <87ab4spcun.fsf@mid.deneb.enyo.de> Date: Mon, 01 Jun 2009 18:58:45 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: > In your previous mail you wrote: > > * Francis Dupont: > > > PS: I am sure you know it is critical to get this published and > > implemented before 2010. > > This time frame is impossible to achieve due to the dependency on > NSEC3. > > => can you detail? Do you mean it is impossible to get it published > in time? implemented? Or the issue is begin/end of 2010 Wide deployment is two to three years away. => I took care to use "published" and "implemented", not "deployed". The NSEC3 upgrade is too large to put in a point release. => I can't see the point: NSEC3 is already published (March 2008) and implemented (it is even deployed in .gov). I agree NSEC3 doesn't make things simpler (:-) but it is orthogonal to RSA-SHA256 for implementations which already support it. Adding a new cryptographic algorithm might have been possible. => I can't see the point (and BTW the term "cryptographic algorithm" is ambiguous because it has a special meaning in the crypto community). I don't think this is a technical problem. (It may be a compliance issue.) It just sugests that DNSSEC doesn't offer that much algorithm agility. => DNSSEC has to prove it provides enough algorithm agility but there is no a priori reason it can't... Regards Francis.Dupont@fdupont.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 10:37:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4133A6EC2; Mon, 1 Jun 2009 10:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1zNG+uAw+aX; Mon, 1 Jun 2009 10:36:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 255063A6CE0; Mon, 1 Jun 2009 10:36:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBBNP-000MeD-Lz for namedroppers-data0@psg.com; Mon, 01 Jun 2009 17:32:47 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBBNC-000McE-Je for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 17:32:40 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A2F0F2FE9637 for ; Mon, 1 Jun 2009 17:32:32 +0000 (UTC) Date: Mon, 1 Jun 2009 13:32:29 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Ping fallbacks Message-ID: <20090601173229.GK14798@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [no hat] On Sun, May 31, 2009 at 06:16:40PM +0100, George Barwood wrote: > This is true for a naive use of EDNS Ping, but it does not mean EDNS > Ping is not useful. I think you're framing the question in the wrong terms, there. It seems to me that several of the critics of EDNS0 Ping are not outright saying, "It can't be useful," but instead, "The gains are not worth the additional cost." Some of the critics are arguing that the gains amount to nothing, in that it is possible for an attacker to force a downgrade. In response, you offer that EDNS0 Ping could be part of a set of heuristics that allow for intelligent reaction in the absence of DNSSEC. So, for instance, > (3) Adopt more complex fallbacks, such as comparing multiple > responses to infer a safe result, or a restrictive ( but less > efficient ) cache policy. > > Clients may also maintain state information to minimise the number > of extra packets required. At this point, it seems to me, you have to make a pretty compelling argument that EDNS0 Ping will in fact help, since what you are arguing is that we deploy several different complementary strategies in an attempt to detect badness. It will be necessary, of course, not only to specify all these technologies, but also to specify which interactions are an indication of badness, and so on. The time it might take to come to consensus on how these things might work and how the interactions are strong evidence of badness (as opposed to broken implementations, &c.) is not obviously smaller than the time to deploy DNSSEC to the point where it might be practically useful. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 12:25:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2BB28C24F; Mon, 1 Jun 2009 12:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtiKYzRqpZ7R; Mon, 1 Jun 2009 12:25:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 577D928C0EC; Mon, 1 Jun 2009 12:25:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBD1v-0007Rj-Lz for namedroppers-data0@psg.com; Mon, 01 Jun 2009 19:18:43 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBD1j-0007QP-Nt for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 19:18:37 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n51JISu6023094; Mon, 1 Jun 2009 12:18:29 -0700 (PDT) From: Nicholas Weaver To: "George Barwood" In-Reply-To: <8FA88E5DED3E4E16A214AEAAB4AC755C@localhost> Subject: Re: [dnsext] IP fragmentation security X-Priority: 3 References: <8FA88E5DED3E4E16A214AEAAB4AC755C@localhost> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 1 Jun 2009 12:18:28 -0700 Cc: Nicholas Weaver , X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 1, 2009, at 10:58 AM, George Barwood wrote: > Are there any DNS security concerns regarding fragmented IP packets? > > Would it be possible for a blind attacker to spoof a fragment of a > response, which might allow modification of a packet without needing > to guess the DNS ID? > > For example > > dig example.se @ns.iana.org +dnssec > > generates a response of more than 512 bytes. The (unsigned) > additional section might therefore be modified by a blind attacker, > without needing to guess the ID, opening up cheap denial of service > attacks (and probably other nastiness) against DNSSEC. > > [ I don't know if this attack works, as I'm not very familiar with > IP fragmentation, but I don't at first sight see why it doesn't work ] If the legit response was not fragmented, this can't work. If the legit response WILL be fragmented, at a point the attacker knows, the attacker can overwrite the value POST fragmentation-point with some reasonably high probability if the attacker knows the authority's IPID chosen, esp if the defragmenter keeps unrestored fragments around for a long time, with just a single packet, depending on how the resolver does reassembly. This might actually be really useful in some narrow cases: Suppose authority A can generate large records. And recursive resolver B is being targeted, and will request packets using EDNS0 and a request size large enough to cause fragmentation (eg, Bind). The attacker does a query on B which is sent to A, and sends a fragment as well which overwrites the Authority or Additional field in the response, where the fragment is actually sent before the legit packet from A is received. Basically, the packets sent (assume the fragmentation occurs at 1000 bytes and the ID that A will use is X: Attacker -> B: DNS request B->A: DNS query Attacker -> B: Spoofed response: A->B, ID X, off 1000 A->B: A->B, ID X, fragment A->B, ID X, off 1000 which B reassembles as the first 1000 bytes being A's response, and the rest being the attacker's response (overwriting glue fields) The requirements: 1) A must have a predictible (or collidable) IPID 2) B must enable EDNS and request > MSS packets 3) The response from A must not have DF set, and must be fragmented. 4) Attacker can cause B to generate a request to A where the response from A is sufficiently large that it will be fragmented 5) The Auth/additional field data which the attacker overwrites must be accepted by B without further validation (eg, independent glue fetch, DNSSEC). 6) B must hold the "out of order" fragment from the attacker and use that to reassemble once the first piece from the legit server is received, rather than discarding that small fragment immediately. Big open question, and probably target specific. So the constraints are pretty tight, but there may definitely be usable, eg, targeting www.se: dig +norecurse +dnssec ANY www.se @ns2.nic.se (run 3 times): The TCPdump output is: 12:14:57.996240 IP (tos 0x0, ttl 64, id 15775, offset 0, flags [none], proto UDP (17), length 63) 192.150.186.168.53968 > 194.17.45.54.53: 57977 [1au] ANY? www.se. (35) 12:14:58.175309 IP (tos 0x0, ttl 41, id 5452, offset 0, flags [+], proto UDP (17), length 1500) 194.17.45.54.53 > 192.150.186.168.53968: 57977*- 19/0/11 www.se. SOA[|domain] 12:14:58.175463 IP (tos 0x0, ttl 41, id 5452, offset 1480, flags [+], proto UDP (17), length 1500) 194.17.45.54 > 192.150.186.168: udp 12:14:58.175466 IP (tos 0x0, ttl 41, id 5452, offset 2960, flags [none], proto UDP (17), length 271) 194.17.45.54 > 192.150.186.168: udp 12:14:58.587969 IP (tos 0x0, ttl 64, id 64915, offset 0, flags [none], proto UDP (17), length 63) 192.150.186.168.53969 > 194.17.45.54.53: 64664 [1au] ANY? www.se. (35) 12:14:58.767143 IP (tos 0x0, ttl 41, id 5453, offset 0, flags [+], proto UDP (17), length 1500) 194.17.45.54.53 > 192.150.186.168.53969: 64664*- 19/0/11 www.se. SOA[|domain] 12:14:58.767287 IP (tos 0x0, ttl 41, id 5453, offset 1480, flags [+], proto UDP (17), length 1500) 194.17.45.54 > 192.150.186.168: udp 12:14:58.767289 IP (tos 0x0, ttl 41, id 5453, offset 2960, flags [none], proto UDP (17), length 271) 194.17.45.54 > 192.150.186.168: udp 12:14:59.099446 IP (tos 0x0, ttl 64, id 6650, offset 0, flags [none], proto UDP (17), length 63) 192.150.186.168.53970 > 194.17.45.54.53: 53097 [1au] ANY? www.se. (35) 12:14:59.278499 IP (tos 0x0, ttl 41, id 5454, offset 0, flags [+], proto UDP (17), length 1500) 194.17.45.54.53 > 192.150.186.168.53970: 53097*- 19/0/11 www.se. SOA[|domain] 12:14:59.278637 IP (tos 0x0, ttl 41, id 5454, offset 1480, flags [+], proto UDP (17), length 1500) 194.17.45.54 > 192.150.186.168: udp 12:14:59.278640 IP (tos 0x0, ttl 41, id 5454, offset 2960, flags [none], proto UDP (17), length 271) 194.17.45.54 > 192.150.186.168: udp So you can clearly see that IPID is predictable, you can generate responses that WILL fragment, and there is such lovely goop in the additional section that, if not validated, will allow you to reassign the notion of what nameservers are responsible for www.se The only question is, how does the authority's IP reassembler chose which fragments to use. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 12:50:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA073A7143; Mon, 1 Jun 2009 12:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wzy4qjwa64Yc; Mon, 1 Jun 2009 12:50:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4644E3A6914; Mon, 1 Jun 2009 12:50:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBDSV-0009Zu-D3 for namedroppers-data0@psg.com; Mon, 01 Jun 2009 19:46:11 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBDSJ-0009YD-MK for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 19:46:05 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n51Jjvi0027462; Mon, 1 Jun 2009 12:45:57 -0700 (PDT) From: Nicholas Weaver To: Nicholas Weaver In-Reply-To: Subject: Re: [dnsext] IP fragmentation security X-Priority: 3 References: <8FA88E5DED3E4E16A214AEAAB4AC755C@localhost> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 1 Jun 2009 12:45:56 -0700 Cc: "George Barwood" , X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: One other comment: Conservative glue policies (eg, Unbound's, etc, the "no race until win" policies) would be immune to this attack if it works. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 13:20:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562EA3A6D59; Mon, 1 Jun 2009 13:20:27 -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 OdaOrzZhFWWL; Mon, 1 Jun 2009 13:20:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 794C23A67D1; Mon, 1 Jun 2009 13:20:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBDvO-000Ctm-NU for namedroppers-data0@psg.com; Mon, 01 Jun 2009 20:16:02 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBDvD-000Cso-QG for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 20:15:57 +0000 Received: from [192.168.100.67] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id C85C2C2DA3; Mon, 1 Jun 2009 21:15:48 +0100 (BST) Date: Mon, 01 Jun 2009 21:15:49 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Nicholas Weaver , George Barwood cc: Nicholas Weaver , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] IP fragmentation security Message-ID: <602E9048329CF7F05435FAB7@nimrod.local> In-Reply-To: References: <8FA88E5DED3E4E16A214AEAAB4AC755C@localhost> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 1 June 2009 12:18:28 -0700 Nicholas Weaver wrote: > Attacker -> B: DNS request > B->A: DNS query > Attacker -> B: Spoofed response: A->B, ID X, off 1000 > A->B: A->B, ID X, fragment > A->B, ID X, off 1000 This attack can be enhanced by supplying many spoofed responses with different IPIDs. Combined with low cache times (so B->A query is made frequently) this would seem to have a high chance of success. Last time I looked at an IP stack (which was admittedly ten years ago): * Fragments arriving out of order didn't matter (so it doesn't matter if the spoofed fragment arrives before the first real fragment) * The first real fragment "won", and (at least in a two fragment case) the reassembled UDP packet would hit the application before the real second fragment appeared. This would appear to give it some mileage for a non-DNSSEC attack. But I am not sure it is of much more use for a DNSSEC attack than flooding the resolving nameserver with spoofed SERVFAIL responses (i.e. it's "just" a DoS). Or am I missing something? -- Alex Bligh -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 13:29:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C473C3A6774; Mon, 1 Jun 2009 13:29:32 -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 I19h3CSaRUOD; Mon, 1 Jun 2009 13:29:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B8E63A6E48; Mon, 1 Jun 2009 13:28:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBE3z-000Dga-PV for namedroppers-data0@psg.com; Mon, 01 Jun 2009 20:24:55 +0000 Received: from [209.85.221.178] (helo=mail-qy0-f178.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBE3f-000DcW-4N for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 20:24:42 +0000 Received: by qyk8 with SMTP id 8so16188014qyk.5 for ; Mon, 01 Jun 2009 13:24:32 -0700 (PDT) Received: by 10.224.37.134 with SMTP id x6mr6086228qad.154.1243887872578; Mon, 01 Jun 2009 13:24:32 -0700 (PDT) Received: from ?10.119.87.250? ([32.139.163.199]) by mx.google.com with ESMTPS id 2sm77337qwi.13.2009.06.01.13.24.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Jun 2009 13:24:32 -0700 (PDT) References: <8FA88E5DED3E4E16A214AEAAB4AC755C@localhost> Message-Id: From: Matthew Dempsky To: Nicholas Weaver In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (5H11) Mime-Version: 1.0 (iPhone Mail 5H11) Subject: Re: [dnsext] IP fragmentation security Date: Mon, 1 Jun 2009 15:24:17 -0500 Cc: Nicholas Weaver , George Barwood , "" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Another comment: the attacker also has to forge the UDP checksum, which includes the source port and txid, but is itself only 16 bits. On the other hand, the attacker doesn't have to bother repeating the query name, so it opens the possibility for a birthday attack. Does anyone know any DNSSEC enabled zones containing wildcard names with large recordsets? On Jun 1, 2009, at 2:45 PM, Nicholas Weaver wrote: > > One other comment: Conservative glue policies (eg, Unbound's, etc, > the "no race until win" policies) would be immune to this attack if > it works. > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org > with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 13:29:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4141A3A68AC; Mon, 1 Jun 2009 13:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHYJ8IEyHMSO; Mon, 1 Jun 2009 13:29:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B65A3A67E9; Mon, 1 Jun 2009 13:29:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBE5h-000DrK-4h for namedroppers-data0@psg.com; Mon, 01 Jun 2009 20:26:41 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBE5V-000Dpd-N3 for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 20:26:35 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n51KQM25005032; Mon, 1 Jun 2009 13:26:22 -0700 (PDT) Cc: Nicholas Weaver , George Barwood , "" Message-Id: <375691A7-70D9-47A9-BAC4-440D82702442@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] IP fragmentation security Date: Mon, 1 Jun 2009 13:26:21 -0700 References: <8FA88E5DED3E4E16A214AEAAB4AC755C@localhost> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 1, 2009, at 1:24 PM, Matthew Dempsky wrote: > Another comment: the attacker also has to forge the UDP checksum, > which includes the source port and txid, but is itself only 16 bits. > On the other hand, the attacker doesn't have to bother repeating the > query name, so it opens the possibility for a birthday attack. > > Does anyone know any DNSSEC enabled zones containing wildcard names > with large recordsets? OH, good point. Forgot about the UDP checksum. So you're right, this will fail because the checksum includes the exisiting entropy sources. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 13:45:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C09728C0CF; Mon, 1 Jun 2009 13:45: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 5al2+CSA1NMi; Mon, 1 Jun 2009 13:45:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A8703A6FBF; Mon, 1 Jun 2009 13:44:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBEGA-000FIZ-Gw for namedroppers-data0@psg.com; Mon, 01 Jun 2009 20:37:30 +0000 Received: from [209.85.221.178] (helo=mail-qy0-f178.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBEFz-000FGU-Kw for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 20:37:24 +0000 Received: by qyk8 with SMTP id 8so16205371qyk.5 for ; Mon, 01 Jun 2009 13:37:18 -0700 (PDT) Received: by 10.224.29.21 with SMTP id o21mr6136452qac.50.1243888637500; Mon, 01 Jun 2009 13:37:17 -0700 (PDT) Received: from ?10.123.167.177? ([32.141.196.228]) by mx.google.com with ESMTPS id 6sm83047qwd.32.2009.06.01.13.37.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Jun 2009 13:37:16 -0700 (PDT) References: <8FA88E5DED3E4E16A214AEAAB4AC755C@localhost> <375691A7-70D9-47A9-BAC4-440D82702442@ICSI.Berkeley.EDU> Message-Id: From: Matthew Dempsky To: Nicholas Weaver In-Reply-To: <375691A7-70D9-47A9-BAC4-440D82702442@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (5H11) Mime-Version: 1.0 (iPhone Mail 5H11) Subject: Re: [dnsext] IP fragmentation security Date: Mon, 1 Jun 2009 15:37:04 -0500 Cc: Nicholas Weaver , George Barwood , "" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Actually, the checksum is a simple 16-bit ones-complement checksum and fragments are required to be 8-byte aligned. If you can guess what should have been in the fragment (presumably much lower entropy for most queries) couldn't you forge the checksum with reasonable probability? On Jun 1, 2009, at 3:26 PM, Nicholas Weaver wrote: > > On Jun 1, 2009, at 1:24 PM, Matthew Dempsky wrote: > >> Another comment: the attacker also has to forge the UDP checksum, >> which includes the source port and txid, but is itself only 16 >> bits. On the other hand, the attacker doesn't have to bother >> repeating the query name, so it opens the possibility for a >> birthday attack. >> >> Does anyone know any DNSSEC enabled zones containing wildcard names >> with large recordsets? > > OH, good point. Forgot about the UDP checksum. > > So you're right, this will fail because the checksum includes the > exisiting entropy sources. > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 13:56:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23AB3A688C; Mon, 1 Jun 2009 13:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzqL355h1bQL; Mon, 1 Jun 2009 13:56:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C73B53A6B1C; Mon, 1 Jun 2009 13:56:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBEUa-000H3R-HC for namedroppers-data0@psg.com; Mon, 01 Jun 2009 20:52:24 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBEUP-000H2S-4Q for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 20:52:18 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n51Kq4nv009029; Mon, 1 Jun 2009 13:52:04 -0700 (PDT) Cc: Matthew Dempsky , George Barwood , "" Message-Id: <4B0687DD-C979-4FC6-A32F-48ABC411B9D9@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Nicholas Weaver In-Reply-To: <375691A7-70D9-47A9-BAC4-440D82702442@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] IP fragmentation security Date: Mon, 1 Jun 2009 13:52:03 -0700 References: <8FA88E5DED3E4E16A214AEAAB4AC755C@localhost> <375691A7-70D9-47A9-BAC4-440D82702442@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 1, 2009, at 1:26 PM, Nicholas Weaver wrote: > > On Jun 1, 2009, at 1:24 PM, Matthew Dempsky wrote: > >> Another comment: the attacker also has to forge the UDP checksum, >> which includes the source port and txid, but is itself only 16 >> bits. On the other hand, the attacker doesn't have to bother >> repeating the query name, so it opens the possibility for a >> birthday attack. >> >> Does anyone know any DNSSEC enabled zones containing wildcard names >> with large recordsets? > > OH, good point. Forgot about the UDP checksum. > > So you're right, this will fail because the checksum includes the > exisiting entropy sources. Oh wait: here's the math: Its 2^16 regardless of the entropy sources (port, 0x20, ID, etc): The checksum is a 2^16 value. The attacker must match: a) The IPID (predictable or 1 in 2^16, but assume predictible) b) The checksum (1 in 2^16, matched by basically having a random 16b value somewhere in the attacker's fragment, as this checksum includes both port and TXID and 0x20, and if the attacker knew those, he could respond directly)) However, the attacker gets only one try per query, since the first packet which matches IPID is used to be in the checksum (a checksum failure will mean a dropped UDP packet, not a "retry assembly" I'm assuming). So its not kaminski-level even when it under conditions that work (authority sends a large, fragmented response with a predictable IPID), because although its a glue race-until-win style attack, you can only generate only one attack packet per query, which means ~2^16 queries to generate a successful attack, and you need to be effectively sequential to keep the IPID predictable. The same glue policy countermeasures against Kaminski attacks also works here, BTW. Apologies for my stupidities. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 1 14:09:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63FC43A68AF; Mon, 1 Jun 2009 14:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3HIYEvitQzv; Mon, 1 Jun 2009 14:09:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 88B553A6843; Mon, 1 Jun 2009 14:09:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBEgw-000IBd-RD for namedroppers-data0@psg.com; Mon, 01 Jun 2009 21:05:10 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBEgm-000IAy-05 for namedroppers@ops.ietf.org; Mon, 01 Jun 2009 21:05:05 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n51L4omo010910; Mon, 1 Jun 2009 14:04:50 -0700 (PDT) Cc: Nicholas Weaver , George Barwood , "" Message-Id: From: Nicholas Weaver To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] IP fragmentation security Date: Mon, 1 Jun 2009 14:04:50 -0700 References: <8FA88E5DED3E4E16A214AEAAB4AC755C@localhost> <375691A7-70D9-47A9-BAC4-440D82702442@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 1, 2009, at 1:37 PM, Matthew Dempsky wrote: > Actually, the checksum is a simple 16-bit ones-complement checksum > and fragments are required to be 8-byte aligned. If you can guess > what should have been in the fragment (presumably much lower entropy > for most queries) couldn't you forge the checksum with reasonable > probability? Oh wait, YEAH! You're right. So the requirements are: a) The attacker must be able to cause the target resolver to generate a suitably large query b) The query response needs: a) Predictable or guessable IPID b) Predictable or guessable fragment to be overwritten. The attacker just ensures that his fragment he overwrites maintains the same checksum (probably easy, the lower 16b of the TTL field and other fields would be good candidates, or name munging, or...) or randomly permutes say, the lower 16b of the TTL field (randomizes the checksum to give a 1 in 2^16 match) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 2 17:56:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 268EE3A6823; Tue, 2 Jun 2009 17:56:53 -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 s07yvaSX0t+p; Tue, 2 Jun 2009 17:56:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 453A23A659B; Tue, 2 Jun 2009 17:56:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBeex-0000s7-37 for namedroppers-data0@psg.com; Wed, 03 Jun 2009 00:48:51 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBeel-0000r2-Ft for namedroppers@ops.ietf.org; Wed, 03 Jun 2009 00:48:45 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n530mbxB009216 for ; Tue, 2 Jun 2009 20:48:37 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n530mbcU009215 for namedroppers@ops.ietf.org; Tue, 2 Jun 2009 20:48:37 -0400 (EDT) (envelope-from namedroppers) Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBHza-0009QM-W4 for namedroppers@ops.ietf.org; Tue, 02 Jun 2009 00:36:44 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id EE2ADE606E; Tue, 2 Jun 2009 00:36:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n520aV7I062968; Tue, 2 Jun 2009 10:36:32 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906020036.n520aV7I062968@drugs.dv.isc.org> To: Francis Dupont Cc: Florian Weimer , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= /DNSEXT chair , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Draft DNSEXT charter In-reply-to: Your message of "Mon, 01 Jun 2009 18:58:45 +0200." <200906011658.n51GwjFi060547@givry.fdupont.fr> Date: Tue, 02 Jun 2009 10:36:31 +1000 X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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. ] In message <200906011658.n51GwjFi060547@givry.fdupont.fr>, Francis Dupont write s: > In your previous mail you wrote: > > > In your previous mail you wrote: > > > > * Francis Dupont: > > > > > PS: I am sure you know it is critical to get this published and > > > implemented before 2010. > > > > This time frame is impossible to achieve due to the dependency on > > NSEC3. > > > > => can you detail? Do you mean it is impossible to get it published > > in time? implemented? Or the issue is begin/end of 2010 > > Wide deployment is two to three years away. > > => I took care to use "published" and "implemented", not "deployed". > > The NSEC3 upgrade is too large to put in a point release. > > => I can't see the point: NSEC3 is already published (March 2008) and > implemented (it is even deployed in .gov). I agree NSEC3 doesn't make > things simpler (:-) but it is orthogonal to RSA-SHA256 for implementations > which already support it. > > Adding a new cryptographic algorithm might have been possible. > > => I can't see the point (and BTW the term "cryptographic algorithm" > is ambiguous because it has a special meaning in the crypto community). > > I don't think this is a technical problem. (It may be a compliance > issue.) It just sugests that DNSSEC doesn't offer that much algorithm > agility. You really can't use RSA-SHA256 as a example of lack of algorithm agility. We could have choosen to allocate pairs of code points one which was not NSEC3 aware and one which was. RSA-SHA256 deployment would then have been a simple change. Instead it was decided to link NSEC3 support and RSA-SHA256. > => DNSSEC has to prove it provides enough algorithm agility but > there is no a priori reason it can't... > > Regards > > Francis.Dupont@fdupont.fr > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 2 21:36:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D925128C0FD; Tue, 2 Jun 2009 21:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.451 X-Spam-Level: X-Spam-Status: No, score=-5.451 tagged_above=-999 required=5 tests=[AWL=-1.014, 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 GwSDOJcVmU3c; Tue, 2 Jun 2009 21:36:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0FE4228C0E2; Tue, 2 Jun 2009 21:36:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBi7v-000GNG-Ap for namedroppers-data0@psg.com; Wed, 03 Jun 2009 04:30:59 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBi7k-000GLn-BJ for namedroppers@ops.ietf.org; Wed, 03 Jun 2009 04:30:53 +0000 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 8CE90A94439; Wed, 3 Jun 2009 04:30:47 +0000 (UTC) Cc: Nicholas Weaver , George Barwood , "" Message-Id: From: Douglas Otis To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] IP fragmentation security Date: Tue, 2 Jun 2009 21:30:46 -0700 References: <8FA88E5DED3E4E16A214AEAAB4AC755C@localhost> <375691A7-70D9-47A9-BAC4-440D82702442@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 1, 2009, at 1:37 PM, Matthew Dempsky wrote: > Actually, the checksum is a simple 16-bit ones-complement checksum > and fragments are required to be 8-byte aligned. If you can guess > what should have been in the fragment (presumably much lower entropy > for most queries) couldn't you forge the checksum with reasonable > probability? Set it to zero. Although RFC 1122 section 4.1.3.4 indicates UDP Checksums should default enabled, a number of DNS packets do not use UDP checksums. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From beefsteakq@leeauto.com Wed Jun 3 06:42:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8C93A6CD2; Wed, 3 Jun 2009 06:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.801 X-Spam-Level: X-Spam-Status: No, score=-26.801 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_FAKE_RCVD_LINE_B=5.777, FS_WEIGHT_LOSS=2.134, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HS_INDEX_PARAM=0.001, HTML_FONT_SIZE_HUGE=0.057, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1LseMBrPUFJ; Wed, 3 Jun 2009 06:42:09 -0700 (PDT) Received: from ttxa112.ttx-net.sk (ttxa112.ttx-net.sk [193.110.186.112]) by core3.amsl.com (Postfix) with ESMTP id 2B8C93A6C65; Wed, 3 Jun 2009 06:42:08 -0700 (PDT) Received: from 193.110.186.112 by dmail.cobaltgroup.com; Wed, 3 Jun 2009 06:41:18 -0800 Date: Wed, 3 Jun 2009 06:41:18 -0800 From: crisp-request@ietf.org X-Mailer: The Bat! (v3.71.01) Educational X-Priority: 3 (Normal) Message-ID: <574055478.24173147353483@leeauto.com> To: crisp-request@ietf.org Subject: Everyone noticed some weight loss only after 2 weeks and energy levels increased after 5 days See How MIME-Version: 1.0 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit
If you have trouble viewing this e-mail, please click here.

Everyone
Will Want
Your New Secret

ACAI BERRY

Discover the secret today!
Hurry to enter

To review our Privacy Policy, please click here.

To ensure the delivery of your informative updates from Dr. Lark and the Daily Balance
Team, please add crisp-request@ietf.org to your email address book.

************TO UNSUBSCRIBE************
You are receiving this e-mail at crisp-request@ietf.org because you
indicated an interest in receiving special updates and offers from Dr. Lark.
We hope that you find these updates helpful, but if you would rather not
receive them, you can unsubscribe by clicking here. You will be
immediately unsubscribed from our database. Remember, your personal information
will only be used by Healthy Directions, LLC, for editorial and marketing purposes.
Thank you.

Daily Balance
938 Indian Springs Drive
Lancaster, PA 54099

From owner-namedroppers@ops.ietf.org Wed Jun 3 10:52:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0969A3A6AC2; Wed, 3 Jun 2009 10:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.177 X-Spam-Level: X-Spam-Status: No, score=-5.177 tagged_above=-999 required=5 tests=[AWL=-0.129, 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 8NveKVQKKuB1; Wed, 3 Jun 2009 10:52:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2059F3A6AB9; Wed, 3 Jun 2009 10:52:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBuYe-000JRH-NX for namedroppers-data0@psg.com; Wed, 03 Jun 2009 17:47:24 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBuYT-000JPS-4X for namedroppers@ops.ietf.org; Wed, 03 Jun 2009 17:47:18 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n53HkhaJ007413; Wed, 3 Jun 2009 10:46:43 -0700 (PDT) Cc: Nicholas Weaver , Douglas Otis , George Barwood , "" Message-Id: From: Nicholas Weaver To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] IP fragmentation security Date: Wed, 3 Jun 2009 10:46:43 -0700 References: <8FA88E5DED3E4E16A214AEAAB4AC755C@localhost> <375691A7-70D9-47A9-BAC4-440D82702442@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 3, 2009, at 10:44 AM, Matthew Dempsky wrote: > On Tue, Jun 2, 2009 at 9:30 PM, Douglas Otis > wrote: >> Set it to zero. > > The UDP checksum will be in the same fragment as the UDP ports and the > DNS transaction id. The potential benefit from attacking fragments > other than the first is that you don't have to blindly guess the > primary source of entropy in the packet, you just have to forge a > fragment that checksums the same as the legitimate fragment. Which means you only need to know what the legitimate fragment looks like, because its a 1-complement checksum (so fully associative and communative), so the inserted fragment's checksum needs to match the legitimate fragment's checksum. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 3 10:52:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF2D63A6CBB; Wed, 3 Jun 2009 10:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV7K9naJLg1M; Wed, 3 Jun 2009 10:52:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F27DC3A6AB9; Wed, 3 Jun 2009 10:52:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBuWA-000J99-Ej for namedroppers-data0@psg.com; Wed, 03 Jun 2009 17:44:50 +0000 Received: from [74.125.46.31] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBuVw-000J7D-ML for namedroppers@ops.ietf.org; Wed, 03 Jun 2009 17:44:45 +0000 Received: by yw-out-2324.google.com with SMTP id 3so64850ywj.71 for ; Wed, 03 Jun 2009 10:44:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.74.7 with SMTP id w7mr997035aga.116.1244051075080; Wed, 03 Jun 2009 10:44:35 -0700 (PDT) In-Reply-To: References: <8FA88E5DED3E4E16A214AEAAB4AC755C@localhost> <375691A7-70D9-47A9-BAC4-440D82702442@ICSI.Berkeley.EDU> Date: Wed, 3 Jun 2009 10:44:34 -0700 Message-ID: Subject: Re: [dnsext] IP fragmentation security From: Matthew Dempsky To: Douglas Otis Cc: Nicholas Weaver , George Barwood , "" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jun 2, 2009 at 9:30 PM, Douglas Otis wrote: > Set it to zero. The UDP checksum will be in the same fragment as the UDP ports and the DNS transaction id. The potential benefit from attacking fragments other than the first is that you don't have to blindly guess the primary source of entropy in the packet, you just have to forge a fragment that checksums the same as the legitimate fragment. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 3 12:36:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E031C3A6F78; Wed, 3 Jun 2009 12:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.365 X-Spam-Level: X-Spam-Status: No, score=-5.365 tagged_above=-999 required=5 tests=[AWL=-0.928, 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 UKPaJulccxBy; Wed, 3 Jun 2009 12:36:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D247A3A6C05; Wed, 3 Jun 2009 12:36:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBwBf-0004WF-Q2 for namedroppers-data0@psg.com; Wed, 03 Jun 2009 19:31:47 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBwBU-0004Uw-HG for namedroppers@ops.ietf.org; Wed, 03 Jun 2009 19:31:42 +0000 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id C6331A9443C; Wed, 3 Jun 2009 19:31:35 +0000 (UTC) Cc: Matthew Dempsky , George Barwood , "" Message-Id: <539398C9-213F-4017-B81E-CD5CA27EEBD9@mail-abuse.org> From: Douglas Otis To: Nicholas Weaver In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] IP fragmentation security Date: Wed, 3 Jun 2009 12:31:34 -0700 References: <8FA88E5DED3E4E16A214AEAAB4AC755C@localhost> <375691A7-70D9-47A9-BAC4-440D82702442@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 3, 2009, at 10:46 AM, Nicholas Weaver wrote: > > On Jun 3, 2009, at 10:44 AM, Matthew Dempsky wrote: > >> On Tue, Jun 2, 2009 at 9:30 PM, Douglas Otis >> wrote: >>> Set it to zero. >> >> The UDP checksum will be in the same fragment as the UDP ports and >> the DNS transaction id. The potential benefit from attacking >> fragments other than the first is that you don't have to blindly >> guess the primary source of entropy in the packet, you just have to >> forge a fragment that checksums the same as the legitimate fragment. Agreed. In addition, whenever UDP checksums become disabled by the query sum, this might be cause for concern as well. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 3 14:42:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D113A693E; Wed, 3 Jun 2009 14:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fANjduRaJlG2; Wed, 3 Jun 2009 14:42:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1CF073A6A11; Wed, 3 Jun 2009 14:42:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBy7v-000FoN-5E for namedroppers-data0@psg.com; Wed, 03 Jun 2009 21:36:03 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBy7k-000Fne-7z for namedroppers@ops.ietf.org; Wed, 03 Jun 2009 21:35:57 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n53LZnAT020828 for ; Wed, 3 Jun 2009 17:35:49 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906032135.n53LZnAT020828@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 03 Jun 2009 17:35:37 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [speaking as RFC3226 editor with encouragement from RFC3225 editor] Strictly speaking based on RFC3225 and RFC3226 this is a protocol violation. Unfortunately there is no explicit statement on how to treat this mis-behavior. People claim this is somewhat common in the wild, these implementations/configurations will get hurt when DNSSEC is deployed at the root and they ask for ". NS" or now when asking for "org. DNSKEY" In most cases this is caused by people configuring DNS implementations to use small buffers, mis-guided firewall, etc. Can we make these misbehaviors suffer sooner by changing/configuring implementations to return "REFUSED" to any query that has OPT record with DO bit set and buffer size less than 1024 or 1220. In addition I propose to write an update to RFC3226 to include a error handling section: ----- When DNS responder sees a DNS message with the DO bit set and buffer size < 1220 the responder SHOULD return a message with the RCODE = Refused, and include in the OPT record a new option REASON that contains following string "DO requires EDNS buffer size > 1220" ---- The REASON EDNS0 Option will be defined in the same document. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 3 19:55:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AD073A6D95; Wed, 3 Jun 2009 19:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCQazdX0onYB; Wed, 3 Jun 2009 19:55:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 695223A6BCC; Wed, 3 Jun 2009 19:55:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MC30B-000FdY-NH for namedroppers-data0@psg.com; Thu, 04 Jun 2009 02:48:23 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MC300-000FcF-HN for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 02:48:18 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 9F699E60A0; Thu, 4 Jun 2009 02:48:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5418wGA010441; Thu, 4 Jun 2009 11:08:59 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906040108.n5418wGA010441@drugs.dv.isc.org> To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 In-reply-to: Your message of "Wed, 03 Jun 2009 17:35:37 -0400." <200906032135.n53LZnAT020828@stora.ogud.com> Date: Thu, 04 Jun 2009 11:08:58 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <200906032135.n53LZnAT020828@stora.ogud.com>, Olafur Gudmundsson wri tes: > [speaking as RFC3226 editor with encouragement from RFC3225 editor] > > Strictly speaking based on RFC3225 and RFC3226 this is a protocol > violation. Unfortunately there is no explicit statement on how to > treat this mis-behavior. > > People claim this is somewhat common in the wild, these > implementations/configurations will get hurt when DNSSEC is deployed at > the root and they ask for ". NS" or now when asking for "org. DNSKEY" I believe this is just excesive worry. EDNS referrals from the root servers to COM and NET already exceed 512 bytes. If this was going to be a real problem it would already have happened. > In most cases this is caused by people configuring DNS implementations > to use small buffers, mis-guided firewall, etc. Or broken routers in the middle of the net. Not all of the sources of problems are under the control of client. Some of the problems may actually be the authoritative servers, or more correctly their host OS's, which set DF on outgoing UDP responses. BIND now turns DF off on a per socket basis when the OS supports it and we have discovered the OS specific magic to do it. > Can we make these misbehaviors suffer sooner by changing/configuring > implementations to return "REFUSED" to any query that has OPT record > with DO bit set and buffer size less than 1024 or 1220. Please NO. Falling back to EDNS@512 keeps DNSSEC working and in many cases just trims off some additional records which are causing the response to be dropped. I've worried about this issue for years. BIND's gone from silently fixing the issue to being noisy when it has to fallback. Excessively noisy initially. Mark > In addition I propose to write an update to RFC3226 to include a > error handling section: > ----- > When DNS responder sees a DNS message with the DO bit set and > buffer size < 1220 the responder SHOULD return a message with the > RCODE = Refused, and include in the OPT record a new option > REASON that contains following string "DO requires EDNS buffer size > 1220" > ---- > > The REASON EDNS0 Option will be defined in the same document. > > Olafur -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 3 20:11:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C723A7044; Wed, 3 Jun 2009 20:11:44 -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 4+bZP1wb4829; Wed, 3 Jun 2009 20:11:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2F2773A6F6F; Wed, 3 Jun 2009 20:11:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MC3IM-000H6b-I0 for namedroppers-data0@psg.com; Thu, 04 Jun 2009 03:07:10 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MC3IB-000H60-Ji for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 03:07:04 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 09773A4571; Thu, 4 Jun 2009 03:06:59 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Mark Andrews cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 In-Reply-To: Your message of "Thu, 04 Jun 2009 11:08:58 +1000." <200906040108.n5418wGA010441@drugs.dv.isc.org> References: <200906040108.n5418wGA010441@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 04 Jun 2009 03:06:59 +0000 Message-ID: <37978.1244084819@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Mark Andrews > Date: Thu, 04 Jun 2009 11:08:58 +1000 > ... > ... BIND now turns DF off on a per socket basis when the OS > supports it and we have discovered the OS specific magic to do it. > ... > I've worried about this issue for years. BIND's gone from silently > fixing the issue to being noisy when it has to fallback. > Excessively noisy initially. can you ensure that 2671bis (about to go into production) covers our implementation experience and makes recommendations about how fallback ought to work? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 05:37:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6E313A6B42; Thu, 4 Jun 2009 05:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.285 X-Spam-Level: ** X-Spam-Status: No, score=2.285 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_LH_HOME=3.714, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VhcK8auuXkU; Thu, 4 Jun 2009 05:37:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 14DDC3A69C0; Thu, 4 Jun 2009 05:37:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCC4f-000MLt-75 for namedroppers-data0@psg.com; Thu, 04 Jun 2009 12:29:37 +0000 Received: from [2001:4f8:3:bb:2e0:81ff:fe52:9971] (helo=mail2.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCC4M-000MJr-Ib for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 12:29:23 +0000 Received: from firewall.antoniuk.lan (mail.antoniuk.md [65.86.158.146]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.ntp.org (Postfix) with ESMTP id 6BAA1398CD; Thu, 4 Jun 2009 12:29:17 +0000 (UTC) (envelope-from mayer@gis.net) Received: from [198.22.153.6] (helo=[10.60.103.66]) by firewall.antoniuk.lan with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MCC4G-0004Nh-43; Thu, 04 Jun 2009 08:29:12 -0400 Message-ID: <4A27BE18.3070305@gis.net> Date: Thu, 04 Jun 2009 08:29:12 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT_chair?= Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNSEXT to meet at IETF-75/Stockholm References: <200905271833.n4RIXK3C005019@stora.ogud.com> In-Reply-To: <200905271833.n4RIXK3C005019@stora.ogud.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-kostecke.net-MailScanner: Found to be clean X-kostecke.net-MailScanner-From: mayer@gis.net Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ólafur Guðmundsson /DNSEXT chair wrote: > > The chairs have determined that there is sufficient reason to have the > meeting. We have started the process of updating the WG charter to reflect > the additions to our work items: > - ENDS0-bis > - GOST algorithm additions > - Forgery Resilience (stay tuned for details) > > Send in agenda items, so far we have > GOST Algorithm document > Forgery Resilience work (or not) > New charter > ENDS0 Option hurdle, go to template like for RR types I assume that you mean EDNS0 and not ENDS0 here. Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 06:20:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2381C3A6EAB; Thu, 4 Jun 2009 06:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=0.238, 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 5ppbXvyBo8+5; Thu, 4 Jun 2009 06:20:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A3723A6DE8; Thu, 4 Jun 2009 06:20:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCCmr-0003aj-PS for namedroppers-data0@psg.com; Thu, 04 Jun 2009 13:15:17 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCCmf-0003Xo-DX for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 13:15:11 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id AEEEE3A6EAB; Thu, 4 Jun 2009 06:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-rsasha256-14.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090604131501.AEEEE3A6EAB@core3.amsl.com> Date: Thu, 4 Jun 2009 06:15:01 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC Author(s) : J. Jansen Filename : draft-ietf-dnsext-dnssec-rsasha256-14.txt Pages : 10 Date : 2009-06-04 This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-14.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-rsasha256-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-04060539.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From murderouslyv96@nreob.com Thu Jun 4 08:01:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05FFD3A692C; Thu, 4 Jun 2009 08:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.521 X-Spam-Level: X-Spam-Status: No, score=-21.521 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=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, FS_START_LOSE=1.493, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HS_INDEX_PARAM=0.001, HTML_FONT_SIZE_HUGE=0.057, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_DIET=1.466, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27IH0nUOnbZJ; Thu, 4 Jun 2009 08:01:53 -0700 (PDT) Received: from dslb-088-065-142-107.pools.arcor-ip.net (dslb-088-065-142-107.pools.arcor-ip.net [88.65.142.107]) by core3.amsl.com (Postfix) with ESMTP id 7571D3A6C72; Thu, 4 Jun 2009 08:01:52 -0700 (PDT) Message-ID: <000d01c9e525$64560740$6400a8c0@murderouslyv96> From: crisp-request@ietf.org To: Subject: Lose weight without starving yourself Acai Berry, get your trial Now. Date: Thu, 4 Jun 2009 17:01:51 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9E525.64560740" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9E525.64560740 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 If you have trouble viewing this e-mail, please click here. =20 =20 =20 =20 =20 Everyone Will Want=20 Your New Secret =20 ACAI BERRY Discover the secret today! Rush to enter =20 =20 =20 =20 =20 To review our Privacy Policy, please click here. To ensure the delivery of your informative updates = from Dr. Lark and the Daily Balance Team, please add crisp-request@ietf.org = =20 to your email address book. =20 ************TO UNSUBSCRIBE************ You are receiving this e-mail at crisp-request@ietf.org because you= =20 indicated an interest in receiving special updates and offers from Dr. Lark. We hope that you find these updates helpful, but if you would rather not receive them, you can unsubscribe by clicking here. You will be immediately unsubscribed from our database. Remember, your personal= information=20 will only be used by Healthy Directions, LLC, for editorial and mar= keting purposes.=20 Thank you.=20 Daily Balance 482 Indian Springs Drive Lancaster, PA 16147 ------=_NextPart_000_0007_01C9E525.64560740 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
click here.

Everyone
Will Want
You= r New Secret

ACAI BERRY

Discover the secret today!
Rush to enter<= /font>

To review our Privacy Policy, please click here.

To ensure the delivery of your informative updates = from Dr. Lark and the Daily Balance
Team, please add c= risp-request@ietf.org to your email address book.

************TO UNSUBSCRIBE************
You are receiving this e-mail at crisp-request@ietf.org because you=
indicated an interest in receiving special updates and offers from Dr. Lark.
We hope that you find these updates helpful, but if you would rather not
receive them, you can unsubscribe by clicking here. You will be
immediately unsubscribed from our database. Remember, your personal= information
will only be used by Healthy Directions, LLC, for editorial and mar= keting purposes.
Thank you.

Daily Balance
482 Indian Springs Drive
Lancaster, PA 16147

------=_NextPart_000_0007_01C9E525.64560740-- From owner-namedroppers@ops.ietf.org Thu Jun 4 08:14:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8886E3A68B1; Thu, 4 Jun 2009 08:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.356 X-Spam-Level: X-Spam-Status: No, score=-1.356 tagged_above=-999 required=5 tests=[AWL=-0.861, 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 OYgR8AyoW3Bt; Thu, 4 Jun 2009 08:14:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9934B3A6863; Thu, 4 Jun 2009 08:14:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCEZk-000IsN-T2 for namedroppers-data0@psg.com; Thu, 04 Jun 2009 15:09:52 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCEZR-000IpI-AY for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 15:09:38 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n54EiF2e005370 for ; Thu, 4 Jun 2009 10:44:15 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906041444.n54EiF2e005370@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 X-Priority: 2 (High) Date: Thu, 04 Jun 2009 10:43:45 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated In-Reply-To: <200905201528.n4KFSsI3055828@stora.ogud.com> References: <200905081453.n48ErDH3055593@stora.ogud.com> <200905201528.n4KFSsI3055828@stora.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Please someone take few minutes to say you have read the document, and your impression of it document !! I'm extending the LC until June 10'th, IF we do not have 5 reviews by then the document will be killed!!!!! Olafur At 12:31 20/05/2009, =D3lafur Gu=F0mundsson /DNSEXT wrote: >Reminder >we still need more reviews. > >In particular none of the people that supported adoption has >submitted one. > > Olafur > >Ps: in case you forgot if you supported the document (and agreed to review) >Roy Arends, Mark Andrews, Olaf Kolkman, Patrik F=E4ltstr=F6m, Joe Abley, >Brian Dickson, Edward Lewis, Mike StJohns > >At 18:19 08/05/2009, =D3lafur Gu=F0mundsson /DNSEXT wrote: > >>This note starts a Working Group Last Call for this Standards Track= document >>ending on midnight May 24'th UTZ 2009. >> >>URL for the document and its history: >>http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-tsig-md5-deprecated/ >> >>This document is on the Standards Track, The=20 >>document updates standards track >>documents and redefines an IANA registry. >> >>Please read the document carefully, and send=20 >>your comments to the mailing list. >> >>The document process rules in this working group, require that at least >>5 members of the working to state that they have reviewed the document >>and there is consensus of support to publish it as a Standards Track RFC. >> >> Olafur (for the chairs) >> >> >> >>-- >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 08:34:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 908DE3A6A22; Thu, 4 Jun 2009 08:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ea0N5RrxXVm0; Thu, 4 Jun 2009 08:34:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 758313A6B82; Thu, 4 Jun 2009 08:34:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCEt2-000LBP-7B for namedroppers-data0@psg.com; Thu, 04 Jun 2009 15:29:48 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCEpo-000KlH-RE for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 15:27:02 +0000 X-Files: PGP.sig : 186 X-IronPort-AV: E=Sophos;i="4.41,306,1241395200"; d="sig'?scan'208";a="46210678" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 04 Jun 2009 15:26:27 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n54FQRKG026185; Thu, 4 Jun 2009 11:26:27 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n54FQRYQ028780; Thu, 4 Jun 2009 15:26:27 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jun 2009 11:26:27 -0400 Received: from [192.168.207.109] ([10.82.213.239]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 11:26:26 -0400 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Olafur Gudmundsson In-Reply-To: <200906041444.n54EiF2e005370@stora.ogud.com> Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated X-Priority: 2 (High) References: <200905081453.n48ErDH3055593@stora.ogud.com> <200905201528.n4KFSsI3055828@stora.ogud.com> <200906041444.n54EiF2e005370@stora.ogud.com> Message-Id: <19844D27-2F50-45BA-AE8B-EAA664025E07@cisco.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-144--465987296" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 4 Jun 2009 17:26:24 +0200 Cc: namedroppers@ops.ietf.org X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 04 Jun 2009 15:26:27.0159 (UTC) FILETIME=[D3CC1670:01C9E528] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3037; t=1244129187; x=1244993187; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20

|Subject:=20Re=3A=20[dnsext]=20WGLC=20TSIG=20MD5=20Deprecat ed=20 |Sender:=20 |To:=20Olafur=20Gudmundsson=20; bh=FvnIlfMyHeqFnVXY7rJeRpz0lPUGWKM509KSW9f6R5E=; b=bngR8liivWVN8rbqOhlZjlcV3Fi8mMps3BB4bHavjmEO7aHe/q40Kg7wpV RQH+ucbCCERc5WRfh0iJTzOkjN27TKVY9UUrZa2rMfPRbzXSFYiHFyhezsA0 Eu/I/NQTLS; Authentication-Results: rtp-dkim-2; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-144--465987296 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable I have read the document, and I support it. Patrik On 4 jun 2009, at 16.43, Olafur Gudmundsson wrote: > > Please someone take few minutes to say you have read the document, > and your impression of it document !! > > I'm extending the LC until June 10'th, > IF we do not have 5 reviews by then the document will be killed!!!!! > > Olafur > > > At 12:31 20/05/2009, =D3lafur Gu=F0mundsson /DNSEXT wrote: >> Reminder >> we still need more reviews. >> >> In particular none of the people that supported adoption has >> submitted one. >> >> Olafur >> >> Ps: in case you forgot if you supported the document (and agreed to =20= >> review) >> Roy Arends, Mark Andrews, Olaf Kolkman, Patrik F=E4ltstr=F6m, Joe = Abley, >> Brian Dickson, Edward Lewis, Mike StJohns >> >> At 18:19 08/05/2009, =D3lafur Gu=F0mundsson /DNSEXT wrote: >> >>> This note starts a Working Group Last Call for this Standards =20 >>> Track document >>> ending on midnight May 24'th UTZ 2009. >>> >>> URL for the document and its history: >>> = http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-tsig-md5-deprecated/ >>> >>> This document is on the Standards Track, The document updates =20 >>> standards track >>> documents and redefines an IANA registry. >>> >>> Please read the document carefully, and send your comments to the =20= >>> mailing list. >>> >>> The document process rules in this working group, require that at =20= >>> least >>> 5 members of the working to state that they have reviewed the =20 >>> document >>> and there is consensus of support to publish it as a Standards =20 >>> Track RFC. >>> >>> Olafur (for the chairs) >>> >>> >>> >>> -- >>> to unsubscribe send a message to namedroppers-request@ops.ietf.org =20= >>> with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >> >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org =20= >> with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org =20 > with > the word 'unsubscribe' in a single line as the message text body. > archive: --Apple-Mail-144--465987296 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) iD8DBQFKJ+egvHlR2X0luNwRAmCNAJ46xMpd5CTK54L8WaBG/lc2D9lq1ACbBNyC eh9s9xYCFwzSIUC5fkjKcBg= =FqxT -----END PGP SIGNATURE----- --Apple-Mail-144--465987296-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 08:59:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCFA3A690B; Thu, 4 Jun 2009 08:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7wgj4BgTQX0; Thu, 4 Jun 2009 08:59:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3244A3A6B8D; Thu, 4 Jun 2009 08:58:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFHM-000O8E-PU for namedroppers-data0@psg.com; Thu, 04 Jun 2009 15:54:56 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFHB-000O6f-TW for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 15:54:51 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 0D42D6059D2; Thu, 4 Jun 2009 08:54:43 -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 vHkK3WO2meKk; Thu, 4 Jun 2009 08:54:29 -0700 (PDT) Received: from wlan39-215.mdr.icann.org (wlan39-215.mdr.icann.org [192.0.39.215]) by virtualized.org (Postfix) with ESMTP id 0A3D76059C4; Thu, 4 Jun 2009 08:54:28 -0700 (PDT) Cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Message-Id: <336CF82C-4930-41B0-ABFB-765A37007FF1@virtualized.org> From: David Conrad To: Mark Andrews In-Reply-To: <200906040108.n5418wGA010441@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 Date: Thu, 4 Jun 2009 08:54:26 -0700 References: <200906040108.n5418wGA010441@drugs.dv.isc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark, On Jun 3, 2009, at 6:08 PM, Mark Andrews wrote: > EDNS referrals from the root servers to COM and NET already > exceed 512 bytes. Indeed they do. > If this was going to be a real problem it would already have happened. What percentage of queries to the root result in NXDOMAIN? How big are signed NXDOMAIN responses? How many of those signed NXDOMAIN responses are going to come back with TC set? Is that number going to go up or down over time? > Please NO. Falling back to EDNS@512 keeps DNSSEC working > and in many cases just trims off some additional records > which are causing the response to be dropped. There is a reason the minimum buffer size for DNSSEC signed responses was chosen to be 1220. If you do not believe those reasons were justified, then you should provide revisions to 3226. Simply ignoring 3226 is just wrong. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 09:00:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE8B43A6BDD; Thu, 4 Jun 2009 09:00:39 -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 fkzXVdsXsQR7; Thu, 4 Jun 2009 09:00:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE8323A690B; Thu, 4 Jun 2009 09:00:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFKF-000OVa-0C for namedroppers-data0@psg.com; Thu, 04 Jun 2009 15:57:55 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFJn-000OSE-GI for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 15:57:40 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (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 825F0E602F for ; Thu, 4 Jun 2009 15:57:26 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated From: Shane Kerr To: namedroppers In-Reply-To: <19844D27-2F50-45BA-AE8B-EAA664025E07@cisco.com> References: <200905081453.n48ErDH3055593@stora.ogud.com> <200905201528.n4KFSsI3055828@stora.ogud.com> <200906041444.n54EiF2e005370@stora.ogud.com> <19844D27-2F50-45BA-AE8B-EAA664025E07@cisco.com> Content-Type: text/plain; charset="UTF-8" Organization: ISC Date: Thu, 04 Jun 2009 17:57:24 +0200 Message-Id: <1244131044.4151.268.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Me too. -- Shane On Thu, 2009-06-04 at 17:26 +0200, Patrik Fältström wrote: > I have read the document, and I support it. > > Patrik > > On 4 jun 2009, at 16.43, Olafur Gudmundsson wrote: > > > > > Please someone take few minutes to say you have read the document, > > and your impression of it document !! > > > > I'm extending the LC until June 10'th, > > IF we do not have 5 reviews by then the document will be killed!!!!! > > > > Olafur > > > > > > At 12:31 20/05/2009, Ólafur Guðmundsson /DNSEXT wrote: > >> Reminder > >> we still need more reviews. > >> > >> In particular none of the people that supported adoption has > >> submitted one. > >> > >> Olafur > >> > >> Ps: in case you forgot if you supported the document (and agreed to > >> review) > >> Roy Arends, Mark Andrews, Olaf Kolkman, Patrik Fältström, Joe Abley, > >> Brian Dickson, Edward Lewis, Mike StJohns > >> > >> At 18:19 08/05/2009, Ólafur Guðmundsson /DNSEXT wrote: > >> > >>> This note starts a Working Group Last Call for this Standards > >>> Track document > >>> ending on midnight May 24'th UTZ 2009. > >>> > >>> URL for the document and its history: > >>> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-tsig-md5-deprecated/ > >>> > >>> This document is on the Standards Track, The document updates > >>> standards track > >>> documents and redefines an IANA registry. > >>> > >>> Please read the document carefully, and send your comments to the > >>> mailing list. > >>> > >>> The document process rules in this working group, require that at > >>> least > >>> 5 members of the working to state that they have reviewed the > >>> document > >>> and there is consensus of support to publish it as a Standards > >>> Track RFC. > >>> > >>> Olafur (for the chairs) > >>> > >>> > >>> > >>> -- > >>> to unsubscribe send a message to namedroppers-request@ops.ietf.org > >>> with > >>> the word 'unsubscribe' in a single line as the message text body. > >>> archive: > >> > >> > >> -- > >> to unsubscribe send a message to namedroppers-request@ops.ietf.org > >> with > >> the word 'unsubscribe' in a single line as the message text body. > >> archive: > > > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org > > with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 09:07:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88FCE3A6F17; Thu, 4 Jun 2009 09:07:00 -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 kbX7HdVsf0aQ; Thu, 4 Jun 2009 09:06:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A39CA3A6EED; Thu, 4 Jun 2009 09:06:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFPa-000PEZ-Mp for namedroppers-data0@psg.com; Thu, 04 Jun 2009 16:03:26 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFPG-000P6q-SR for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 16:03:18 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n54G34VX059612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Jun 2009 09:03:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200906041444.n54EiF2e005370@stora.ogud.com> References: <200905081453.n48ErDH3055593@stora.ogud.com> <200905201528.n4KFSsI3055828@stora.ogud.com> <200906041444.n54EiF2e005370@stora.ogud.com> X-Priority: 2 (High) Date: Thu, 4 Jun 2009 09:03:03 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I have read this document and I do *not* support its adoption. There is no security justification for deprecating the use of HMAC-MD5 in any case, and I do not believe there is security justification for deprecating the use of MD5 between trusted peers (as is the case in TKEY). Deprecating things that still work fine adds complexity to the protocol, particularly given that the protocol already has options for parties who don't want to use HMAC-MD5 and MD5. If, in the future, there is some actual security justification for the deprecation, we can take this up then. Note that I'm not one of the five people who volunteered to be reviewers; I have no idea how my active non-support affects the calculation. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 09:16:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2AE3A6EED; Thu, 4 Jun 2009 09:16:09 -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 kX0RW-Q+URp4; Thu, 4 Jun 2009 09:16:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D82903A6EAB; Thu, 4 Jun 2009 09:16:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFX8-0000nC-VA for namedroppers-data0@psg.com; Thu, 04 Jun 2009 16:11:14 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFWu-0000jd-OJ for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 16:11:08 +0000 Received: from [IPv6:2001:7b8:206:1:21b:63ff:feb8:a9eb] ([IPv6:2001:7b8:206:1:21b:63ff:feb8:a9eb]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n54GAvtp009138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Jun 2009 18:10:57 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) From: Olaf Kolkman To: Olafur Gudmundsson In-Reply-To: <200906041444.n54EiF2e005370@stora.ogud.com> Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated X-Priority: 2 (High) References: <200905081453.n48ErDH3055593@stora.ogud.com> <200905201528.n4KFSsI3055828@stora.ogud.com> <200906041444.n54EiF2e005370@stora.ogud.com> Message-Id: <586D8C19-F943-4573-A6CB-705DD46FF169@NLnetLabs.nl> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-29--463315349" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 4 Jun 2009 18:10:56 +0200 Cc: namedroppers@ops.ietf.org X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 04 Jun 2009 18:10:57 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-29--463315349 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 4 jun 2009, at 16:43, Olafur Gudmundsson wrote: > > Please someone take few minutes to say you have read the document, > and your impression of it document !! > > I'm extending the LC until June 10'th, > IF we do not have 5 reviews by then the document will be killed!!!!! Thanks for the poke. I support the document. And all the comments below are to be taken in the light that if you ask for close review you will get somebody who will try to say something that indicates they actually read the document :-). ---- In the introduction: The secret key transaction authentication for DNS I would start with: The protocol described in "The Secret Key Transaction Authentication for DNS (TSIG)"[RFC2845] was defined with ----- Also in the introduction Context: security came to be considered lower than expected Question: Is there a stable and recognized reference for that claim? ---- Section 2 last sentence OLD (i.e., algorithms at a "not Mandatory" requirement level) NEW (i.e., requirements that are not at a "Mandatory" requirement level) ALTERNATIVE (i.e., requirements that are at a "Optional" requirement level) Reason: "not Mandatory" is not a requirement level that is used in the paragraph. ----- IANA considerations s!located at http://.*/tsig-algorithm-names!! Reason: I don't think it is common to refer to an IANA registry through its URL, its name should be unique. Probably wise to check with the RFC Editor on what is common. ---- Section 5. If there is a stable and recognized reference about the claim for SHA1 that might be useful ---- --Olaf --Apple-Mail-29--463315349 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.9 (Darwin) Comment: This message is locally signed. iEYEARECAAYFAkon8hAACgkQtN/ca3YJIod8lgCfYOKJ0kp5V1wcE9FveUU0kfUz vqoAnA8Mf9k2cAZ7wCx/S6z6+VXR8loM =Q+eF -----END PGP SIGNATURE----- --Apple-Mail-29--463315349-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 09:26:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F2B3A6EF7; Thu, 4 Jun 2009 09:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_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 DqeYIP4P1Z9K; Thu, 4 Jun 2009 09:26:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B7893A6D78; Thu, 4 Jun 2009 09:26:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFj1-0002za-QE for namedroppers-data0@psg.com; Thu, 04 Jun 2009 16:23:31 +0000 Received: from [64.39.31.27] (helo=server1.dns.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFiq-0002wq-El for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 16:23:26 +0000 Received: from localhost (localhost [[UNIX: localhost]]) by server1.dns.net (8.11.7/8.11.6) id n54GN4432620; Thu, 4 Jun 2009 16:23:04 GMT Date: Thu, 4 Jun 2009 17:24:05 +0100 From: Andras Salamon To: namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated Message-ID: <20090604162405.GA11614@gaon.net> References: <200905081453.n48ErDH3055593@stora.ogud.com> <200905201528.n4KFSsI3055828@stora.ogud.com> <200906041444.n54EiF2e005370@stora.ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906041444.n54EiF2e005370@stora.ogud.com> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 04, 2009 at 10:43:45AM -0400, Olafur Gudmundsson wrote: > I'm extending the LC until June 10'th, > IF we do not have 5 reviews by then the document will be killed!!!!! I support advancing draft-ietf-dnsext-tsig-md5-deprecated-03. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 09:26:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4773A6D84; Thu, 4 Jun 2009 09:26:45 -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 iPx5ILArFjGx; Thu, 4 Jun 2009 09:26:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 02EC63A6EAB; Thu, 4 Jun 2009 09:26:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFib-0002wx-MK for namedroppers-data0@psg.com; Thu, 04 Jun 2009 16:23:05 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFiN-0002vA-TK for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 16:23:00 +0000 Received: from [IPv6:2001:7b8:206:1:21b:63ff:feb8:a9eb] ([IPv6:2001:7b8:206:1:21b:63ff:feb8:a9eb]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n54GMn39009985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Jun 2009 18:22:49 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) From: Olaf Kolkman To: Paul Hoffman In-Reply-To: Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated X-Priority: 2 (High) References: <200905081453.n48ErDH3055593@stora.ogud.com> <200905201528.n4KFSsI3055828@stora.ogud.com> <200906041444.n54EiF2e005370@stora.ogud.com> Message-Id: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-30--462602974" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 4 Jun 2009 18:22:49 +0200 Cc: namedroppers@ops.ietf.org X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 04 Jun 2009 18:22:49 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-30--462602974 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 4 jun 2009, at 18:03, Paul Hoffman wrote: > I have read this document and I do *not* support its adoption. There > is no security justification for deprecating the use of HMAC-MD5 in > any case, and I do not believe there is security justification for > deprecating the use of MD5 between trusted peers (as is the case in > TKEY). > > Deprecating things that still work fine adds complexity to the > protocol, particularly given that the protocol already has options > for parties who don't want to use HMAC-MD5 and MD5. If, in the > future, there is some actual security justification for the > deprecation, we can take this up then. Your review crossed mine. In my review I asked for references because I thought those were readily available and I therefore considered my remark an editorial nit. From what you just mailed I have the impression that the issue is not merely editorial. Would you be willing to lecture me on the difference security properties of the different sorts of use? (a reference is fine). For what its worth, if the deprecation of MD5 is needed for TKEY I would think that deprecation in (all) other places in a code base actually decreases complexity. If SHA256 is mandatory for TKEY and MD5 is deprecated than it may be that I still have to link MD5 code because TSIG needs it; it would be easier to get rid of MD5 altogether. So from that perspective I would still be supporting the document. --Olaf --Apple-Mail-30--462602974 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.9 (Darwin) Comment: This message is locally signed. iEYEARECAAYFAkon9NkACgkQtN/ca3YJIodEQgCeILHib8mR0uMKJMcQTPafekLM Y7wAn1y4bk3yJLqOLf7jeswHchNoBomA =249I -----END PGP SIGNATURE----- --Apple-Mail-30--462602974-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 09:29:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416B03A6DAA; Thu, 4 Jun 2009 09:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmwmyfY8gSVx; Thu, 4 Jun 2009 09:29:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DE3223A6F49; Thu, 4 Jun 2009 09:28:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFlQ-0003GG-Ho for namedroppers-data0@psg.com; Thu, 04 Jun 2009 16:26:00 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFlA-0003EU-HN for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 16:25:52 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n54GOHv3000637; Thu, 4 Jun 2009 16:24:19 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n54GOHT3000636; Thu, 4 Jun 2009 16:24:17 GMT Date: Thu, 4 Jun 2009 16:24:17 +0000 From: bmanning@vacation.karoshi.com To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated Message-ID: <20090604162417.GA572@vacation.karoshi.com.> References: <200905081453.n48ErDH3055593@stora.ogud.com> <200905201528.n4KFSsI3055828@stora.ogud.com> <200906041444.n54EiF2e005370@stora.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906041444.n54EiF2e005370@stora.ogud.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 04, 2009 at 10:43:45AM -0400, Olafur Gudmundsson wrote: > > Please someone take few minutes to say you have read the document, > and your impression of it document !! > > I'm extending the LC until June 10'th, > IF we do not have 5 reviews by then the document will be killed!!!!! read the doc. does what we want it to... move it on. --bill > > Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 09:34:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5B53A6A59; Thu, 4 Jun 2009 09:34:03 -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 bhbjiOxNP0CI; Thu, 4 Jun 2009 09:34:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D9B633A6FAF; Thu, 4 Jun 2009 09:33:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFoK-000495-U5 for namedroppers-data0@psg.com; Thu, 04 Jun 2009 16:29:00 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCFnx-00042v-Li for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 16:28:50 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (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 7ECCAE6070; Thu, 4 Jun 2009 16:28:36 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated From: Shane Kerr To: Paul Hoffman Cc: namedroppers@ops.ietf.org In-Reply-To: References: <200905081453.n48ErDH3055593@stora.ogud.com> <200905201528.n4KFSsI3055828@stora.ogud.com> <200906041444.n54EiF2e005370@stora.ogud.com> Content-Type: text/plain Organization: ISC Date: Thu, 04 Jun 2009 18:28:33 +0200 Message-Id: <1244132913.4151.350.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul, On Thu, 2009-06-04 at 09:03 -0700, Paul Hoffman wrote: > I have read this document and I do *not* support its adoption. There is no security justification for deprecating the use of HMAC-MD5 in any case, and I do not believe there is security justification for deprecating the use of MD5 between trusted peers (as is the case in TKEY). The document changes the mandatory support for MD5 to optional. Peers can continue to use it as long as they want, if they have software that supports it. Having fewer mandatory algorithms should make implementations simpler, not more complex, at least in this case where it is between co-operating peers. -- Shane -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 10:04:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA6B3A6AA8; Thu, 4 Jun 2009 10:04:23 -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 1hlS9IqJRaeE; Thu, 4 Jun 2009 10:04:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D56143A6A7A; Thu, 4 Jun 2009 10:04:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCGFh-00088p-2t for namedroppers-data0@psg.com; Thu, 04 Jun 2009 16:57:17 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCGFS-00086O-NN for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 16:57:11 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n54Gu6Sq063629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jun 2009 09:56:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200905081453.n48ErDH3055593@stora.ogud.com> <200905201528.n4KFSsI3055828@stora.ogud.com> <200906041444.n54EiF2e005370@stora.ogud.com> X-Priority: 2 (High) Date: Thu, 4 Jun 2009 09:56:05 -0700 To: Olaf Kolkman From: Paul Hoffman Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 6:22 PM +0200 6/4/09, Olaf Kolkman wrote: >In my review I asked for references because I thought those were readily available and I therefore considered my remark an editorial nit. For a protocol assumption like this, that is a reasonable assumption. I believe it is, in this case, misguided. >From what you just mailed I have the impression that the issue is not merely editorial. Would you be willing to lecture me on the difference security properties of the different sorts of use? (a reference is fine). The security properties of HMAC-MD5 are described fairly well in and the earlier paper that it cites. I know of no more recent work that contradicts this paper. The security properties of MD5 in TSIG are, I believe, reliant on the preimage strength of MD5. To date, there has been no indication of any reduction in the preimage strength of MD5. Even if there is such indication, it would have to be a significant reduction (from 128 bits to, say, 96 bits) before there should be any concern about its use in the DNS. >For what its worth, if the deprecation of MD5 is needed for TKEY I would think that deprecation in (all) other places in a code base actually decreases complexity. If such deprecation was needed, it would decrease code complexity, but it would greatly increase operational complexity because every system would need to have a policy about when to accept MD5 from an otherwise-trusted peer. Given that many peers are still using MD5, making such decisions usually becomes an ill-informed and possibly random choice. (I guess this is more an argument for the DNSOP WG, but I would hope people here would have some mercy on folks who actually deploy our specs.) >If SHA256 is mandatory for TKEY and MD5 is deprecated than it may be that I still have to link MD5 code because TSIG needs it; it would be easier to get rid of MD5 altogether. So from that perspective I would still be supporting the document. If we could make current conformant systems all change at once (flag day, cough cough), that would be fine. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 10:05:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31BA53A6ED7; Thu, 4 Jun 2009 10:05:06 -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 DX92-hoYFFmC; Thu, 4 Jun 2009 10:05:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2284F3A6E7B; Thu, 4 Jun 2009 10:05:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCGKQ-0008qC-RV for namedroppers-data0@psg.com; Thu, 04 Jun 2009 17:02:10 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCGK1-0008n3-0x for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 17:01:57 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n54H1euN064080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jun 2009 10:01:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1244132913.4151.350.camel@shane-asus-laptop> References: <200905081453.n48ErDH3055593@stora.ogud.com> <200905201528.n4KFSsI3055828@stora.ogud.com> <200906041444.n54EiF2e005370@stora.ogud.com> <1244132913.4151.350.camel@shane-asus-laptop> Date: Thu, 4 Jun 2009 10:01:38 -0700 To: Shane Kerr From: Paul Hoffman Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 6:28 PM +0200 6/4/09, Shane Kerr wrote: >The document changes the mandatory support for MD5 to optional. ...and also to SHOULD NOT: The use of MD5 and HMAC-MD5 is NOT RECOMMENDED. >Peers >can continue to use it as long as they want, if they have software that >supports it. For an optional algorithm to work, both sides must be able to process it. This document is recommending that implementations should not use it, so it is likely that some implementations will drop it. >Having fewer mandatory algorithms should make implementations simpler, >not more complex, at least in this case where it is between co-operating >peers. Fully agree, but only at the starting point. Downgrading a mandatory algorithm to "SHOULD NOT" causes greater complexity for the people who have to set the security policy for their organizations. Downgrading therefore should only be done when necessary, and it is not necessary here. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 12:02:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA5A3A70C3; Thu, 4 Jun 2009 12:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_QP_LONG_LINE=1.396, 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 fjPQr2d7oK0X; Thu, 4 Jun 2009 12:02:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4DB083A70AD; Thu, 4 Jun 2009 12:02:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCI40-000MW8-Sf for namedroppers-data0@psg.com; Thu, 04 Jun 2009 18:53:20 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCHwR-000LGl-Od for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 18:46:50 +0000 Received: from postmark.nist.gov (emailha2.nist.gov [129.6.16.198]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n54IjOkS025017 for ; Thu, 4 Jun 2009 14:45:24 -0400 Received: from [129.6.222.108] (h222108.nist.gov [129.6.222.108]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id n54IjAqP030339 for ; Thu, 4 Jun 2009 14:45:13 -0400 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 04 Jun 2009 14:45:09 -0400 Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated From: Scott Rose To: Message-ID: Thread-Topic: [dnsext] WGLC TSIG MD5 Deprecated Thread-Index: AcnlRJXEuCjmRuR1J0mwknmzT8A+vg== In-Reply-To: <200906041444.n54EiF2e005370@stora.ogud.com> X-Priority: 2 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I have read the document and support it. (Sent this before, but not sure if it was counted). Scott On 6/4/09 10:43 AM, "Olafur Gud" wrote: >=20 > Please someone take few minutes to say you have read the document, > and your impression of it document !! >=20 > I'm extending the LC until June 10'th, > IF we do not have 5 reviews by then the document will be killed!!!!! >=20 > Olafur >=20 >=20 > At 12:31 20/05/2009, =C3=93lafur Gu=C3=B0mundsson /DNSEXT wrote: >> Reminder >> we still need more reviews. >>=20 >> In particular none of the people that supported adoption has >> submitted one. >>=20 >> Olafur >>=20 >> Ps: in case you forgot if you supported the document (and agreed to revi= ew) >> Roy Arends, Mark Andrews, Olaf Kolkman, Patrik F=C3=A4ltstr=C3=B6m, Joe Abley, >> Brian Dickson, Edward Lewis, Mike StJohns >>=20 >> At 18:19 08/05/2009, =C3=93lafur Gu=C3=B0mundsson /DNSEXT wrote: >>=20 >>> This note starts a Working Group Last Call for this Standards Track doc= ument >>> ending on midnight May 24'th UTZ 2009. >>>=20 >>> URL for the document and its history: >>> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-tsig-md5-deprecated/ >>>=20 >>> This document is on the Standards Track, The >>> document updates standards track >>> documents and redefines an IANA registry. >>>=20 >>> Please read the document carefully, and send >>> your comments to the mailing list. >>>=20 >>> The document process rules in this working group, require that at least >>> 5 members of the working to state that they have reviewed the document >>> and there is consensus of support to publish it as a Standards Track RF= C. >>>=20 >>> Olafur (for the chairs) >>>=20 >>>=20 >>>=20 >>> -- >>> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >>=20 >>=20 >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >=20 >=20 > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scottr@nist.gov ph: +1 301-975-8439 http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 13:04:33 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F8228C1F2; Thu, 4 Jun 2009 13:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[AWL=-1.625, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jePpznWDhRwn; Thu, 4 Jun 2009 13:04:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 521BA28C1F0; Thu, 4 Jun 2009 13:04:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCJ5h-0002dM-10 for namedroppers-data0@psg.com; Thu, 04 Jun 2009 19:59:09 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCJ5V-0002cU-SR for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 19:59:03 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 68FE72FE965B for ; Thu, 4 Jun 2009 19:58:56 +0000 (UTC) Date: Thu, 4 Jun 2009 15:58:54 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Status of TLSFP RRTYPE Request Message-ID: <20090604195854.GA19852@shinkuro.com> References: <20090413200002.GB24286@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090413200002.GB24286@shinkuro.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, On Mon, Apr 13, 2009 at 04:00:02PM -0400, Andrew Sullivan wrote: > Please provide any comments you have on the proposal by 17:00 EDT on > 2009-05-04. I may not be able to consider comments received after > that time. My apologies that this is nearly a month later than I said it would be. I was waiting for confirmation that there was additional work to do. The request has accordingly been withdrawn, and no assignment will happen for the time being. I encourage the submitter to resubmit the template after that additional work has been done. There is no barrier to doing so -- the process is intended to allow multiple iterations of these steps. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From overextends@sfs.schutter.com.br Thu Jun 4 15:10:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17EBD3A68AC; Thu, 4 Jun 2009 15:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -41.494 X-Spam-Level: X-Spam-Status: No, score=-41.494 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_CHARTER=2.175, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_CHARTER=1.295, HOST_EQ_DHCP=1.295, HS_INDEX_PARAM=0.001, HTML_FONT_SIZE_HUGE=0.057, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 btHYWeipkov0; Thu, 4 Jun 2009 15:10:28 -0700 (PDT) Received: from 24-107-20-64.dhcp.stls.mo.charter.com (24-107-20-64.dhcp.stls.mo.charter.com [24.107.20.64]) by core3.amsl.com (Postfix) with ESMTP id E9B303A67DD; Thu, 4 Jun 2009 15:10:27 -0700 (PDT) Message-ID: <000d01c9e561$3e1cc0f0$6400a8c0@overextends> From: crisp-request@ietf.org To: Subject: Enhance your sexual desires and your performance with Acai diet. Date: Thu, 4 Jun 2009 17:10:17 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9E561.3E1CC0F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9E561.3E1CC0F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 If you have trouble viewing this e-mail, please click here. =20 =20 =20 =20 =20 Everyone Will Want=20 Your New Secret =20 ACAI POWER SLIM Discover the secret today! Longing for your click =20 =20 =20 =20 =20 To review our Privacy Policy, please click here. To ensure the delivery of your informative updates = from Dr. Lark and the Daily Balance Team, please add crisp-request@ietf.org = =20 to your email address book. =20 ************TO UNSUBSCRIBE************ You are receiving this e-mail at crisp-request@ietf.org because you= =20 indicated an interest in receiving special updates and offers from Dr. Lark. We hope that you find these updates helpful, but if you would rather not receive them, you can unsubscribe by clicking here. You will be immediately unsubscribed from our database. Remember, your personal= information=20 will only be used by Healthy Directions, LLC, for editorial and mar= keting purposes.=20 Thank you.=20 Daily Balance 269 Corine Webster 45867 ------=_NextPart_000_0007_01C9E561.3E1CC0F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

click here.

Everyone
Will Want
Your = New Secret

ACAI POWER SLIM

Discover the secret today!
Longing for your cli= ck

To review our Privacy Policy, please click here.

To ensure the delivery of your informative updates = from Dr. Lark and the Daily Balance
Team, please add c= risp-request@ietf.org to your email address book.

************TO UNSUBSCRIBE************
You are receiving this e-mail at crisp-request@ietf.org because you=
indicated an interest in receiving special updates and offers from Dr. Lark.
We hope that you find these updates helpful, but if you would rather not
receive them, you can unsubscribe by clicking here. You will be
immediately unsubscribed from our database. Remember, your personal= information
will only be used by Healthy Directions, LLC, for editorial and mar= keting purposes.
Thank you.

Daily Balance
269 Corine
Webster 45867

------=_NextPart_000_0007_01C9E561.3E1CC0F0-- From owner-namedroppers@ops.ietf.org Thu Jun 4 15:51:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8534D3A6821; Thu, 4 Jun 2009 15:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWqvPDjqb-fW; Thu, 4 Jun 2009 15:51:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 877CB3A681C; Thu, 4 Jun 2009 15:51:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCLgn-000DXP-Ny for namedroppers-data0@psg.com; Thu, 04 Jun 2009 22:45:37 +0000 Received: from [64.22.125.99] (helo=mail.kahlerlarson.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCLgc-000DWd-DO for namedroppers@ops.ietf.org; Thu, 04 Jun 2009 22:45:31 +0000 Received: from sirocco.local (pool-71-178-183-153.washdc.fios.verizon.net [71.178.183.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kahlerlarson.org (Postfix) with ESMTP id BACF337CEC for ; Thu, 4 Jun 2009 18:45:24 -0400 (EDT) Date: Thu, 4 Jun 2009 18:45:24 -0400 From: Matt Larson To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 Message-ID: <20090604224523.GD676@sirocco.local> References: <200906040108.n5418wGA010441@drugs.dv.isc.org> <336CF82C-4930-41B0-ABFB-765A37007FF1@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <336CF82C-4930-41B0-ABFB-765A37007FF1@virtualized.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, 04 Jun 2009, David Conrad wrote: > On Jun 3, 2009, at 6:08 PM, Mark Andrews wrote: >> Please NO. Falling back to EDNS@512 keeps DNSSEC working >> and in many cases just trims off some additional records >> which are causing the response to be dropped. > > There is a reason the minimum buffer size for DNSSEC signed responses > was chosen to be 1220. If you do not believe those reasons were > justified, then you should provide revisions to 3226. Simply ignoring > 3226 is just wrong. I'm in total agreement with David. BIND should not be setting DO if it's also advertising a maximum buffer size of 512. Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 17:42:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C5533A6919; Thu, 4 Jun 2009 17:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 Eqm5k8OjYUDN; Thu, 4 Jun 2009 17:42:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D9843A6905; Thu, 4 Jun 2009 17:42:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCNQg-000K1y-Fm for namedroppers-data0@psg.com; Fri, 05 Jun 2009 00:37:06 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCNQO-000K1E-Jl for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 00:37:00 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id ACED0E606E; Fri, 5 Jun 2009 00:36:47 +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 n550aiHO013571; Fri, 5 Jun 2009 10:36:45 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906050036.n550aiHO013571@drugs.dv.isc.org> To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated In-reply-to: Your message of "Thu, 04 Jun 2009 10:43:45 -0400." <200906041444.n54EiF2e005370@stora.ogud.com> Date: Fri, 05 Jun 2009 10:36:44 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <200906041444.n54EiF2e005370@stora.ogud.com>, Olafur Gudmundsson wri tes: > > Please someone take few minutes to say you have read the document, > and your impression of it document !! > > I'm extending the LC until June 10'th, > IF we do not have 5 reviews by then the document will be killed!!!!! > > Olafur I'm happy with most of it. I've yet to test if a MD5 TKEY client can interoperate with a SHA256 TKEY server and the reverse. > At 12:31 20/05/2009, =D3lafur Gu=F0mundsson /DNSEXT wrote: > >Reminder > >we still need more reviews. > > > >In particular none of the people that supported adoption has > >submitted one. > > > > Olafur > > > >Ps: in case you forgot if you supported the document (and agreed to review) > >Roy Arends, Mark Andrews, Olaf Kolkman, Patrik F=E4ltstr=F6m, Joe Abley, > >Brian Dickson, Edward Lewis, Mike StJohns > > > >At 18:19 08/05/2009, =D3lafur Gu=F0mundsson /DNSEXT wrote: > > > >>This note starts a Working Group Last Call for this Standards Track= > document > >>ending on midnight May 24'th UTZ 2009. > >> > >>URL for the document and its history: > >>http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-tsig-md5-deprecated/ > >> > >>This document is on the Standards Track, The=20 > >>document updates standards track > >>documents and redefines an IANA registry. > >> > >>Please read the document carefully, and send=20 > >>your comments to the mailing list. > >> > >>The document process rules in this working group, require that at least > >>5 members of the working to state that they have reviewed the document > >>and there is consensus of support to publish it as a Standards Track RFC. > >> > >> Olafur (for the chairs) > >> > >> > >> > >>-- > >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >>the word 'unsubscribe' in a single line as the message text body. > >>archive: > > > > > >-- > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 4 19:11:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E195F3A6813; Thu, 4 Jun 2009 19:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 sqEgXYEkn3PZ; Thu, 4 Jun 2009 19:11:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A03683A681E; Thu, 4 Jun 2009 19:11:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCOoe-000O9e-OG for namedroppers-data0@psg.com; Fri, 05 Jun 2009 02:05:56 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCOoS-000O96-R8 for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 02:05:50 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id B5C13E601C; Fri, 5 Jun 2009 02:05:43 +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 n5525TNM014056; Fri, 5 Jun 2009 12:05:37 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906050205.n5525TNM014056@drugs.dv.isc.org> To: David Conrad Cc: Mark Andrews , Olafur Gudmundsson , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 In-reply-to: Your message of "Thu, 04 Jun 2009 08:54:26 MST." <336CF82C-4930-41B0-ABFB-765A37007FF1@virtualized.org> Date: Fri, 05 Jun 2009 12:05:29 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <336CF82C-4930-41B0-ABFB-765A37007FF1@virtualized.org>, David Conrad writes: > Mark, > > On Jun 3, 2009, at 6:08 PM, Mark Andrews wrote: > > EDNS referrals from the root servers to COM and NET already > > exceed 512 bytes. > > Indeed they do. > > > If this was going to be a real problem it would already have happened. > > What percentage of queries to the root result in NXDOMAIN? > > How big are signed NXDOMAIN responses? What sized ZSK's are you going to be using? Are you going to double sign or just replace when re-signing? > How many of those signed NXDOMAIN responses are going to come back > with TC set? To EDNS@512 queries, most. To EDNS@1024 queries, most. To EDNS@1200 at the root almost none, for other zones a higher percentage as the NSEC records are bigger. To EDNS@1460 queries, almost none. How many of those NXDOMAIN queries should not need to be generated in the first place? > Is that number going to go up or down over time? When DNSSEC is enabled there will be a jump. The long term trend depends on a lot of things. Default firewall setting. We should encourage firewall vendors to SERVFAIL EDNS queries if they are not going to to allow large replies back in. Work with the protocol rather than just stuff the protocol up. Better still they should recognise EDNS queries and allow adjust their filters to accept EDNS responses. Allowing non-standard queries to go out and not accepting the replies is bad firewall design. Encouraging ISP's to be stealth secondary of the root would stop a great percentage of these bogus queries reaching the root servers. Have people recognise that single label hostnames are not supposed to work in the global namespace would stop a large percentage as we could kill these in the stub resolver. There was a reason we went to .ARPA when heirachial names were introduced. Do all the root server fragment packets so that the smallest fragment contains the initial segment so that the probability of out of order fragement is reduced? This helps firewalls and NAT's that only process fragmented responses correctly when the initial fragment arrives first. > > Please NO. Falling back to EDNS@512 keeps DNSSEC working > > and in many cases just trims off some additional records > > which are causing the response to be dropped. > > There is a reason the minimum buffer size for DNSSEC signed responses > was chosen to be 1220. If you do not believe those reasons were > justified, then you should provide revisions to 3226. Simply ignoring > 3226 is just wrong. And there are also reasons to fallback to a smaller number when the initial setting fails. Unfortunately 512 it the obvious choise when falling back as it passes through almost all devices. 1220/1460 as a fallback only handles fragmentation problems. Do we have any published stats on the number of queries, which result in a referral that would exceed 512 bytes if records no record are dropped from the additional section, that the have a EDNS UDP size set to 512 compared to those we have a size >= 1200? That should give you a percentage figure on how many queries will be affected. This thread started with a unsupported supposition that there are lots of queries that will cause problems. I've seen no figures to back that up. I know that there will be some queries come in with EDNS UDP size set to 512. Mark > Regards, > -drc > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 00:19:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003193A6947; Fri, 5 Jun 2009 00:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.866 X-Spam-Level: ** X-Spam-Status: No, score=2.866 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, MIME_ASCII0=1.5, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXnbvj0mq9xE; Fri, 5 Jun 2009 00:19:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C4A13A6910; Fri, 5 Jun 2009 00:19:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCTat-000DWn-HC for namedroppers-data0@psg.com; Fri, 05 Jun 2009 07:12:03 +0000 Received: from [62.237.208.212] (helo=smtp11.tdc.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCTai-000DW8-DX for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 07:11:57 +0000 Received: from fi-hel2ex01.nordiclan.net (unknown [194.100.219.27]) by smtp11.tdc.fi (Postfix) with ESMTP id 4D571C27F0 for ; Fri, 5 Jun 2009 10:11:48 +0300 (EEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: [dnsext] Signing a zone and record Date: Fri, 5 Jun 2009 10:04:18 +0300 Message-ID: <86048CA3B4B17E459FFD4F3F383AD88F147DDFA2@fi-hel2ex01.nordiclan.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Signing a zone and record Thread-Index: Acnlq9gf9Tb5sfV3RdyFMdvbrlWRZw== From: "Aki Tuomi" To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: V2hpY2ggUkZDIC8gZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBhY3Rpb25zIHJlcXVpcmVkIHRvIHBy b2R1Y2UgdmFsaWQgc2lnbmF0dXJlIGZvciB6b25lIGFuZCByZWNvcmQgZGF0YSwgYXMgcHJvZHVj ZWQgYnkgZG5zc2VjLXNpZ256b25lPyANCg0KLS0tDQpBa2kgVHVvbWkNClN5c3RlbXMgU3BlY2lh bGlzdA0KVERDIE95DQorMzU4IDMwIDk5NCAyMzQ4DQorMzU4IDUwIDk5NCAyMzQ4DQoNCg0KDQoN Cg== -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 03:07:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43A33A6812; Fri, 5 Jun 2009 03:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3p8djNPdmnB; Fri, 5 Jun 2009 03:07:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 49C0A3A672F; Fri, 5 Jun 2009 03:07:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCWFG-000PN7-59 for namedroppers-data0@psg.com; Fri, 05 Jun 2009 10:01:54 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCWF4-000PLz-Ge for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 10:01:48 +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 1MCWFq-0002cV-5O; Fri, 05 Jun 2009 12:02:30 +0200 Received: from fweimer by bfk.de with local id 1MCWEu-0003Nb-TW; Fri, 05 Jun 2009 12:01:32 +0200 To: Mark Andrews Cc: David Conrad , Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 References: <200906050205.n5525TNM014056@drugs.dv.isc.org> From: Florian Weimer Date: Fri, 05 Jun 2009 12:01:32 +0200 In-Reply-To: <200906050205.n5525TNM014056@drugs.dv.isc.org> (Mark Andrews's message of "Fri\, 05 Jun 2009 12\:05\:29 +1000") Message-ID: <824ouvvw1v.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: * Mark Andrews: > Do all the root server fragment packets so that the smallest > fragment contains the initial segment so that the probability > of out of order fragement is reduced? This helps firewalls > and NAT's that only process fragmented responses correctly > when the initial fragment arrives first. Last time I checked, the roots (except one) did not perform PMTUD, so fragmentation is not under their control. Many DNS servers send the final fragment first anyway. This is not very likely to change. Anyway, I doubt you'll find serious stateful packet filters which do not reassemble all packets traversing the device (and fragment again, if needed). Stateless filters are a different story, of course, but to them, the order of fragments doesn't matter, either. To be honest, I have serious doubts if it makes sense to worry about this. Chances are that DNS traffic moves to IPv6 faster than we can reach consensus. 8-/ --=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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 03:19:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569023A6940; Fri, 5 Jun 2009 03:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3P0Avtye7uHL; Fri, 5 Jun 2009 03:19:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 144743A6B64; Fri, 5 Jun 2009 03:18:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCWRZ-0000LD-8w for namedroppers-data0@psg.com; Fri, 05 Jun 2009 10:14:37 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCWRE-0000JG-LD for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 10:14:23 +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 1MCWS3-0004K4-7X; Fri, 05 Jun 2009 12:15:07 +0200 Received: from fweimer by bfk.de with local id 1MCWR6-0003E6-Tb; Fri, 05 Jun 2009 12:14:08 +0200 To: Alex Bligh Cc: Paul Hoffman , namedroppers@ops.ietf.org Subject: Re: [dnsext] Increasing hash collision resilience References: <82eiumzw0c.fsf@mid.bfk.de> <82eiumh8md.fsf@mid.bfk.de> <657C3F2AEF32EF82F184504D@Ximines.local> From: Florian Weimer Date: Fri, 05 Jun 2009 12:14:08 +0200 Message-ID: <82skifugwf.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: * Alex Bligh: > --On 18 May 2009 07:05:02 -0700 Paul Hoffman wrot= e: > >> I do *not* support the use of randomized hashing for DNSSEC; the use of >> already-defined better hash algorithms (SHA-256) is a much better option. > > Assuming that Florian's suggestion was not to mandate use of a nonce > now, Certainly not. The idea was to make sure that it is interoperable (both in a technical and a social sense), but leave it up to zone signers whether they want to include it or not. --=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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 03:21:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C5523A69E0; Fri, 5 Jun 2009 03:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RZ9ejSWyaXa; Fri, 5 Jun 2009 03:21:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8787A3A6940; Fri, 5 Jun 2009 03:21:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCWVG-0000bx-8i for namedroppers-data0@psg.com; Fri, 05 Jun 2009 10:18:26 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCWV4-0000ap-Pu for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 10:18: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 1MCWVy-00051Y-4h; Fri, 05 Jun 2009 12:19:10 +0200 Received: from fweimer by bfk.de with local id 1MCWV2-0005oH-Ts; Fri, 05 Jun 2009 12:18:12 +0200 To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Increasing hash collision resilience References: <82eiumzw0c.fsf@mid.bfk.de> <82eiumh8md.fsf@mid.bfk.de> <200905181642.n4IGg5tw027927@stora.ogud.com> <823ab1ed6t.fsf@mid.bfk.de> <200905191225.n4JCP8S3040806@stora.ogud.com> From: Florian Weimer Date: Fri, 05 Jun 2009 12:18:12 +0200 Message-ID: <82ljo7ugpn.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: * Olafur Gudmundsson: > Once a target DS signature is generated the attacker has only the > "effective" life signature to play with, trying to > create a collision signature. If parent is using predictable timing > values the attacker still has to submit the "attack DS set" during a > one second window to have a good chance to get the right signature values. This was true for the certificate validity period in Lenstra's attack. > The attack you are describing is available against all RR types (DS > is just most attractive one). Thus if a fix is needed that should > protect all types not just one. In many cases, the attack can be avoided by introducing delegation. > A better solution is to recommend that when signing records the > timer values be randomly picked from a range for example: > sig init [curr time-256..curr_time] > sig expire [lifetime-3600..curr_time+3600] > TTL [standard_TTL-1024..standard_TTL+1024] > > This has no protocol implications. This should work, too. Hopefully, it give interested parties enough bits. Thanks for the suggestion. --=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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 04:25:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C83D3A6873; Fri, 5 Jun 2009 04:25:40 -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 E9dz6RrOiQDt; Fri, 5 Jun 2009 04:25:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27EEC3A6885; Fri, 5 Jun 2009 04:25:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCXTE-0005Ea-9M for namedroppers-data0@psg.com; Fri, 05 Jun 2009 11:20:24 +0000 Received: from [2001:12ff:0:2::4] (helo=clone.registro.br) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCXSy-0005CD-RS for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 11:20:17 +0000 Received: by clone.registro.br (Postfix, from userid 1042) id B4C2C9587B; Fri, 5 Jun 2009 08:20:07 -0300 (BRT) Date: Fri, 5 Jun 2009 08:20:07 -0300 From: Rafael Dantas Justo To: Aki Tuomi Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Signing a zone and record Message-ID: <20090605112007.GB97057@registro.br> References: <86048CA3B4B17E459FFD4F3F383AD88F147DDFA2@fi-hel2ex01.nordiclan.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86048CA3B4B17E459FFD4F3F383AD88F147DDFA2@fi-hel2ex01.nordiclan.net> User-Agent: Mutt/1.4.2.2i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Aki, You will find in RFC 4034 - section 3.1.8. Regards, Rafael Justo On Fri, Jun 05, 2009 at 10:04:18AM +0300, Aki Tuomi wrote: > Which RFC / document specifies the actions required to produce valid signature for zone and record data, as produced by dnssec-signzone? > > --- > Aki Tuomi > Systems Specialist > TDC Oy > +358 30 994 2348 > +358 50 994 2348 > > > > -- -- Atenciosamente, Rafael Justo Engenheiro de Software rafael@registro.br Registro .BR - Engenharia Tel.: +55(11)55093508 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 05:54:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1FAC3A6BB7; Fri, 5 Jun 2009 05:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjr2nqSzDNAP; Fri, 5 Jun 2009 05:54:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B40F03A69D7; Fri, 5 Jun 2009 05:54:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCYrs-000Ca0-8k for namedroppers-data0@psg.com; Fri, 05 Jun 2009 12:49:56 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCYre-000CYY-OM for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 12:49:50 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n55Cne0N002817 for ; Fri, 5 Jun 2009 08:49:40 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n55CneO8002816 for namedroppers@ops.ietf.org; Fri, 5 Jun 2009 08:49:40 -0400 (EDT) (envelope-from namedroppers) Received: from [69.17.117.4] (helo=mail2.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCPIz-000Pc0-2e for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 02:37:23 +0000 Received: (qmail 27562 invoked from network); 5 Jun 2009 02:37:15 -0000 Received: from dsl092-066-189.bos1.dsl.speakeasy.net (HELO spaceman.local) (federico@[66.92.66.189]) (envelope-sender ) by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 5 Jun 2009 02:37:14 -0000 Message-ID: <4A2884D9.8020408@acm.org> Date: Thu, 04 Jun 2009 22:37:13 -0400 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Olafur Gudmundsson CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated References: <200905081453.n48ErDH3055593@stora.ogud.com> <200905201528.n4KFSsI3055828@stora.ogud.com> <200906041444.n54EiF2e005370@stora.ogud.com> In-Reply-To: <200906041444.n54EiF2e005370@stora.ogud.com> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://keyserver.linux.it/pks/lookup?op=get&search=0xAEEBEC184A73884C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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. ] The document looks good overall, and I support it to go forward in the adoption process. The only relevant bit that stands out is the absence of "why" from the doc. It may have some political reason, but it simply is bad practice in my view. Point 1 states: " When the MD5 [RFC1321] security came to be considered lower than expected, [RFC4635] standardized new TSIG algorithms based on SHA [RFC3174][RFC3874][RFC4634] digests. But [RFC4635] did not deprecate the HMAC-MD5 algorithm." So, there is implicitly a reason to now go back and degrade MD5's status to optional. I know the papers, you know the papers. Something should be said here to explain why we are doing this -- or, if there is no reason, we should not be doing it. Just so that it is clear, I _do_ support the change. I think we should explain why, however, with something along the thought line of "as research is progressively weakening MD5's cryptographic strength, it is now time to allocate mandatory status to algorithms not as of yet so compromised". I do not like (6), which goes in the opposite direction. We are doing this because we believe there is a reason to, are we? : "6. Security Considerations This document does not assume anything about the cryptographic security of different hash algorithms. Its purpose is a better availability of some security mechanisms in a predictable time frame." The second statement is good, the first not so much. Again, we are trying to allocate mandatory status to algorithms that are not as far down the process of being compromised... there may be nicer way to put it, but someone reading the doc should be able to understand why this is done without outside knowledge of MD5's progressive weakening. This is my only correction, but I feel pretty strongly that the doc should explain /why/ it is doing /what/ it is doing. Best -F Olafur Gudmundsson wrote: > > Please someone take few minutes to say you have read the document, > and your impression of it document !! > > I'm extending the LC until June 10'th, > IF we do not have 5 reviews by then the document will be killed!!!!! > > Olafur > > > At 12:31 20/05/2009, Ólafur Guðmundsson /DNSEXT wrote: >> Reminder >> we still need more reviews. >> >> In particular none of the people that supported adoption has >> submitted one. >> >> Olafur >> >> Ps: in case you forgot if you supported the document (and agreed to >> review) >> Roy Arends, Mark Andrews, Olaf Kolkman, Patrik Fältström, Joe Abley, >> Brian Dickson, Edward Lewis, Mike StJohns >> >> At 18:19 08/05/2009, Ólafur Guðmundsson /DNSEXT wrote: >> >>> This note starts a Working Group Last Call for this Standards Track >>> document >>> ending on midnight May 24'th UTZ 2009. >>> >>> URL for the document and its history: >>> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-tsig-md5-deprecated/ >>> >>> This document is on the Standards Track, The document updates >>> standards track >>> documents and redefines an IANA registry. >>> >>> Please read the document carefully, and send your comments to the >>> mailing list. >>> >>> The document process rules in this working group, require that at least >>> 5 members of the working to state that they have reviewed the document >>> and there is consensus of support to publish it as a Standards Track >>> RFC. >>> >>> Olafur (for the chairs) >>> >>> >>> >>> -- >>> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >> >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - flucifredi@acm.org - GnuPG 0x4A73884C -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 07:32:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363C83A6D79; Fri, 5 Jun 2009 07:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.957 X-Spam-Level: X-Spam-Status: No, score=-0.957 tagged_above=-999 required=5 tests=[AWL=-1.357, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mfp+w2OMf0W3; Fri, 5 Jun 2009 07:32:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 52B733A6D73; Fri, 5 Jun 2009 07:32:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCaIu-000K1N-Ao for namedroppers-data0@psg.com; Fri, 05 Jun 2009 14:21:56 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCaIi-000K0H-IO for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 14:21:50 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B55C62FE9638 for ; Fri, 5 Jun 2009 14:21:42 +0000 (UTC) Date: Fri, 5 Jun 2009 10:21:40 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] WGLC: draft-ietf-dnsext-dnssec-rsasha256-14.txt Message-ID: <20090605142139.GE20690@shinkuro.com> References: <20090604131501.AEEEE3A6EAB@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090604131501.AEEEE3A6EAB@core3.amsl.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, On Thu, Jun 04, 2009 at 06:15:01AM -0700, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DNS Extensions Working Group of the IETF. > > > Title : Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC > Author(s) : J. Jansen > Filename : draft-ietf-dnsext-dnssec-rsasha256-14.txt > Pages : 10 > Date : 2009-06-04 You may recall that we had what was originally apparently a successful WGLC on this document, but that after it was sent to the IESG some new objections surfaced. The Editor has, we believe, addressed the concerns that were raised after WGLC last time. This message starts a nine-day WGLC on the revised document. The WGLC will close on 2009-06-15 at 09:00 EDT. Please note that, because we had adequate review last time and decided to send the document to the IESG, we do not require the usual five expressions of positive review in order to send the document along. It would be very helpful, however, if those who objected last time stated explicitly whether their objections were addressed. Nevertheless, I will interpret silence as consent. The document will proceed to the IESG as it stands in the absence of objections. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 08:14:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5012C3A6965; Fri, 5 Jun 2009 08:14:08 -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 xR878LeEbIlt; Fri, 5 Jun 2009 08:14:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 51A6A3A68E5; Fri, 5 Jun 2009 08:14:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCb1y-000NXv-74 for namedroppers-data0@psg.com; Fri, 05 Jun 2009 15:08:30 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCb1m-000NX9-TK for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 15:08:24 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n55F7oQg035739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2009 08:07:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A2884D9.8020408@acm.org> References: <200905081453.n48ErDH3055593@stora.ogud.com> <200905201528.n4KFSsI3055828@stora.ogud.com> <200906041444.n54EiF2e005370@stora.ogud.com> <4A2884D9.8020408@acm.org> Date: Fri, 5 Jun 2009 08:07:30 -0700 To: Federico Lucifredi , Olafur Gudmundsson From: Paul Hoffman Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 10:37 PM -0400 6/4/09, Federico Lucifredi wrote: >The document looks good overall, and I support it to go forward in the >adoption process. > >The only relevant bit that stands out is the absence of "why" from the >doc. It may have some political reason, but it simply is bad practice in >my view. Point 1 states: > >" When the MD5 [RFC1321] security came to be considered lower than > expected, [RFC4635] standardized new TSIG algorithms based on SHA > [RFC3174][RFC3874][RFC4634] digests. > > But [RFC4635] did not deprecate the HMAC-MD5 algorithm." > >So, there is implicitly a reason to now go back and degrade MD5's status >to optional. I know the papers, you know the papers. Something should be >said here to explain why we are doing this -- or, if there is no reason, > we should not be doing it. Exactly. So, if you "know the papers", please point out in any paper why it is justified that we deprecate MD5 in the uses covered in this draft. I can find none, but I might be missing something. >Just so that it is clear, I _do_ support the change. I think we should >explain why, however, with something along the thought line of "as >research is progressively weakening MD5's cryptographic strength, it is >now time to allocate mandatory status to algorithms not as of yet so >compromised". To the best of my knowledge, there is no research weakening MD5's cryptographic strength in preimage attack. Again, I'm happy if you can point out research that I have missed, or show how the now-obvious weakening of MD5's collision resistance affects the use of HMAC-MD5 or MD5 used between trusted parties in TSIG. >I do not like (6), which goes in the opposite direction. At least it is honest. >We are doing >this because we believe there is a reason to, are we? So far, no. >: > >"6. Security Considerations > > > This document does not assume anything about the cryptographic > security of different hash algorithms. Its purpose is a better > availability of some security mechanisms in a predictable time frame." > > >The second statement is good, the first not so much. Again, we are >trying to allocate mandatory status to algorithms that are not as far >down the process of being compromised... there may be nicer way to put >it, but someone reading the doc should be able to understand why this is >done without outside knowledge of MD5's progressive weakening. > > > This is my only correction, but I feel pretty strongly that the doc >should explain /why/ it is doing /what/ it is doing. Do you feel that way even if the answer is "there is no cryptographic indication that we should be doing this, but people are afraid of the name 'MD5' so we are deprecating it for that reason"? --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 08:36:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA253A6B5F; Fri, 5 Jun 2009 08:36:17 -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 GEwh4Q9zpltD; Fri, 5 Jun 2009 08:36:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3988E3A6808; Fri, 5 Jun 2009 08:36:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCbN7-000P86-5E for namedroppers-data0@psg.com; Fri, 05 Jun 2009 15:30:21 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCbMt-000P6D-Tx for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 15:30:15 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n55FU619036977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2009 08:30:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090605142139.GE20690@shinkuro.com> References: <20090604131501.AEEEE3A6EAB@core3.amsl.com> <20090605142139.GE20690@shinkuro.com> Date: Fri, 5 Jun 2009 08:30:04 -0700 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-rsasha256-14.txt Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 10:21 AM -0400 6/5/09, Andrew Sullivan wrote: >You may recall that we had what was originally apparently a successful >WGLC on this document, but that after it was sent to the IESG some new >objections surfaced. > >The Editor has, we believe, addressed the concerns that were raised >after WGLC last time. > >This message starts a nine-day WGLC on the revised document. The WGLC >will close on 2009-06-15 at 09:00 EDT. The diffs at seem fine. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 09:54:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23AC63A69AF; Fri, 5 Jun 2009 09:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpPz9Z5cleQt; Fri, 5 Jun 2009 09:54:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 85D563A6AEB; Fri, 5 Jun 2009 09:53:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCcbl-0005Hp-O9 for namedroppers-data0@psg.com; Fri, 05 Jun 2009 16:49:33 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCcba-0005H2-AW for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 16:49:27 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id A36AA609C60; Fri, 5 Jun 2009 09:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpWeuD9oFI79; Fri, 5 Jun 2009 09:49:20 -0700 (PDT) Received: from wlan39-215.mdr.icann.org (wlan39-215.mdr.icann.org [192.0.39.215]) by virtualized.org (Postfix) with ESMTP id D083E609C51; Fri, 5 Jun 2009 09:49:19 -0700 (PDT) Cc: Mark Andrews , Olafur Gudmundsson , namedroppers@ops.ietf.org Message-Id: From: David Conrad To: Florian Weimer In-Reply-To: <824ouvvw1v.fsf@mid.bfk.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 Date: Fri, 5 Jun 2009 09:49:18 -0700 References: <200906050205.n5525TNM014056@drugs.dv.isc.org> <824ouvvw1v.fsf@mid.bfk.de> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Florian, On Jun 5, 2009, at 3:01 AM, Florian Weimer wrote: > To be honest, I have serious doubts if it makes sense to worry about > this. How many TCP sessions are the root servers prepared to handle? > Chances are that DNS traffic moves to IPv6 faster than we can > reach consensus. 8-/ We reached consensus. See RFC 3226. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 09:55:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B893A6A62; Fri, 5 Jun 2009 09:55:06 -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 zmgS6aHl2yKE; Fri, 5 Jun 2009 09:55:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B8BC53A68D2; Fri, 5 Jun 2009 09:55:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCceL-0005WX-0b for namedroppers-data0@psg.com; Fri, 05 Jun 2009 16:52:13 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCce9-0005VX-Rp for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 16:52:07 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 7EBF5A485A for ; Fri, 5 Jun 2009 16:52:01 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated In-Reply-To: Your message of "Thu, 04 Jun 2009 18:28:33 +0200." <1244132913.4151.350.camel@shane-asus-laptop> References: <200905081453.n48ErDH3055593@stora.ogud.com> <200905201528.n4KFSsI3055828@stora.ogud.com> <200906041444.n54EiF2e005370@stora.ogud.com> <1244132913.4151.350.camel@shane-asus-laptop> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 05 Jun 2009 16:52:01 +0000 Message-ID: <31631.1244220721@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Shane Kerr > Date: Thu, 04 Jun 2009 18:28:33 +0200 > > The document changes the mandatory support for MD5 to optional. Peers can > continue to use it as long as they want, if they have software that > supports it. so it's not being deprecated, and the name of the draft is wrong, and the title of the draft is wrong? i'd like the word "deprecated" stripped from the text in that case. if we're just relaxing the "mandatoriness" then we ought to say that, to avoid confusing operators and future implementors. i would be in support of this draft with that clarification. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 10:06:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA31D3A6DB8; Fri, 5 Jun 2009 10:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdjr-J2Vla+7; Fri, 5 Jun 2009 10:06:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DAFDC3A6D9B; Fri, 5 Jun 2009 10:06:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCcoa-0006ZS-PH for namedroppers-data0@psg.com; Fri, 05 Jun 2009 17:02:48 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCcoA-0006WO-Pm for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 17:02:32 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 2FC67609D42; Fri, 5 Jun 2009 10:02:22 -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 IrW1SSFjjUQh; Fri, 5 Jun 2009 10:02:19 -0700 (PDT) Received: from wlan39-215.mdr.icann.org (wlan39-215.mdr.icann.org [192.0.39.215]) by virtualized.org (Postfix) with ESMTP id 4D14D609D2D; Fri, 5 Jun 2009 10:02:19 -0700 (PDT) Cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Message-Id: From: David Conrad To: Mark Andrews In-Reply-To: <200906050205.n5525TNM014056@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 Date: Fri, 5 Jun 2009 10:02:11 -0700 References: <200906050205.n5525TNM014056@drugs.dv.isc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark, On Jun 4, 2009, at 7:05 PM, Mark Andrews wrote: >> How big are signed NXDOMAIN responses? > > What sized ZSK's are you going to be using? Are you going > to double sign or just replace when re-signing? Final decision on this hasn't been made (at least to my knowledge) and I'm the wrong person to ask. However, an example using what I believe are best common practices can be found at ns.iana.org. > How many of those NXDOMAIN queries should not need to be > generated in the first place? Not sure how this is relevant unless you've created a tool that makes people stop miconfiguring stuff/ being stupid. > When DNSSEC is enabled there will be a jump. The long term > trend depends on a lot of things. [bunch of changes of how things are deleted] I'd suggest we discuss the Internet as it is and will likely continue to be the day after the root is signed, not as we might like it to be. > And there are also reasons to fallback to a smaller number > when the initial setting fails. Unfortunately 512 it the > obvious choise when falling back as it passes through almost > all devices. Lovely. Turn off DO if you fall back to a buffer size less than 1220. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 10:12:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4122E3A6C20; Fri, 5 Jun 2009 10:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKcaL+jpJfi4; Fri, 5 Jun 2009 10:12:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5789B3A6B29; Fri, 5 Jun 2009 10:12:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCcv0-0007FF-Hi for namedroppers-data0@psg.com; Fri, 05 Jun 2009 17:09:26 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCcun-0007Di-MB for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 17:09:21 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n55H6Gtj007475; Fri, 5 Jun 2009 17:06:17 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n55H6GvR007474; Fri, 5 Jun 2009 17:06:16 GMT Date: Fri, 5 Jun 2009 17:06:16 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Cc: Florian Weimer , Mark Andrews , Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 Message-ID: <20090605170616.GA7209@vacation.karoshi.com.> References: <200906050205.n5525TNM014056@drugs.dv.isc.org> <824ouvvw1v.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: On Fri, Jun 05, 2009 at 09:49:18AM -0700, David Conrad wrote: > Florian, > > On Jun 5, 2009, at 3:01 AM, Florian Weimer wrote: > >To be honest, I have serious doubts if it makes sense to worry about > >this. > > How many TCP sessions are the root servers prepared to handle? to be fair, your should likely recast this as: how many concurrent TCP sessions are DNS servers prepared to handle? > Regards, > -drc --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 10:14:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF0823A6BAC; Fri, 5 Jun 2009 10:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[AWL=-0.842, 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 bGB23kgenlgp; Fri, 5 Jun 2009 10:14:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B77E3A69AF; Fri, 5 Jun 2009 10:14:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCcxR-0007Tt-8I for namedroppers-data0@psg.com; Fri, 05 Jun 2009 17:11:57 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCcxD-0007Qa-6h for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 17:11:51 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n55HBOKg006030; Fri, 5 Jun 2009 13:11:25 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906051711.n55HBOKg006030@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 05 Jun 2009 13:11:14 -0400 To: bmanning@vacation.karoshi.com From: Olafur Gudmundsson Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 Cc: namedroppers@ops.ietf.org In-Reply-To: <20090605170616.GA7209@vacation.karoshi.com> References: <200906050205.n5525TNM014056@drugs.dv.isc.org> <824ouvvw1v.fsf@mid.bfk.de> <20090605170616.GA7209@vacation.karoshi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 13:06 05/06/2009, bmanning@vacation.karoshi.com wrote: >On Fri, Jun 05, 2009 at 09:49:18AM -0700, David Conrad wrote: > > Florian, > > > > On Jun 5, 2009, at 3:01 AM, Florian Weimer wrote: > > >To be honest, I have serious doubts if it makes sense to worry about > > >this. > > > > How many TCP sessions are the root servers prepared to handle? > > to be fair, your should likely recast this as: > > how many concurrent TCP sessions are DNS servers prepared to handle? Bill, you are a root server operator, what order of magnitude of concurrent TCP sessions are YOUR DNS servers prepared to handle? 10^x x = ? Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 10:34:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 020E73A6B30; Fri, 5 Jun 2009 10:34:29 -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 jzuzwIDkfDu2; Fri, 5 Jun 2009 10:34:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 223A63A68D2; Fri, 5 Jun 2009 10:34:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCdEq-00098b-DI for namedroppers-data0@psg.com; Fri, 05 Jun 2009 17:29:56 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCdEW-00096M-4e for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 17:29:41 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id B2923A4882; Fri, 5 Jun 2009 17:29:35 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: David Conrad cc: Florian Weimer , Mark Andrews , Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 In-Reply-To: Your message of "Fri, 05 Jun 2009 09:49:18 MST." References: <200906050205.n5525TNM014056@drugs.dv.isc.org> <824ouvvw1v.fsf@mid.bfk.de> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 05 Jun 2009 17:29:35 +0000 Message-ID: <33607.1244222975@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: David Conrad > Date: Fri, 5 Jun 2009 09:49:18 -0700 > > How many TCP sessions are the root servers prepared to handle? very few. a fraction of a fraction of a fraction of current udp volume. this is not a fault in the root server design or provisioning, but in the dns protocol itself. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 10:34:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA4013A68D2; Fri, 5 Jun 2009 10:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxSKJJaBh5YZ; Fri, 5 Jun 2009 10:34:28 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 53CC93A69E3; Fri, 5 Jun 2009 10:34:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCdFs-0009G1-Ft for namedroppers-data0@psg.com; Fri, 05 Jun 2009 17:31:00 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCdFf-0009EM-7Q for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 17:30:54 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id E4B76A4894; Fri, 5 Jun 2009 17:30:46 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: David Conrad cc: Mark Andrews , Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 In-Reply-To: Your message of "Fri, 05 Jun 2009 10:02:11 MST." References: <200906050205.n5525TNM014056@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 05 Jun 2009 17:30:46 +0000 Message-ID: <33672.1244223046@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: David Conrad > Date: Fri, 5 Jun 2009 10:02:11 -0700 > ... > Lovely. Turn off DO if you fall back to a buffer size less than 1220. without intending this as instructions to marka, i have to say, i agree. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 10:34:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98EB83A6B30; Fri, 5 Jun 2009 10:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 igwa-+FOQ9dL; Fri, 5 Jun 2009 10:34:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B24EF3A69E3; Fri, 5 Jun 2009 10:34:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCdF6-0009Av-E8 for namedroppers-data0@psg.com; Fri, 05 Jun 2009 17:30:12 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCdEv-00098x-D1 for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 17:30:06 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 18A22A4895; Fri, 5 Jun 2009 17:30:01 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: bmanning@vacation.karoshi.com cc: David Conrad , Florian Weimer , Mark Andrews , Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 In-Reply-To: Your message of "Fri, 05 Jun 2009 17:06:16 GMT." <20090605170616.GA7209@vacation.karoshi.com.> References: <200906050205.n5525TNM014056@drugs.dv.isc.org> <824ouvvw1v.fsf@mid.bfk.de> <20090605170616.GA7209@vacation.karoshi.com.> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 05 Jun 2009 17:30:01 +0000 Message-ID: <33659.1244223001@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Fri, 5 Jun 2009 17:06:16 +0000 > From: bmanning@vacation.karoshi.com > > > How many TCP sessions are the root servers prepared to handle? > > to be fair, your should likely recast this as: > > how many concurrent TCP sessions are DNS servers prepared to handle? very, very, few. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 10:54:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C9C3A69E3; Fri, 5 Jun 2009 10:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE22f1gJ6qC3; Fri, 5 Jun 2009 10:54:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 78E733A68D2; Fri, 5 Jun 2009 10:54:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCdY0-000BCn-Ah for namedroppers-data0@psg.com; Fri, 05 Jun 2009 17:49:44 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCdXp-000BBl-1y for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 17:49:38 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n55Hm0tj007697; Fri, 5 Jun 2009 17:48:00 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n55HlxDr007696; Fri, 5 Jun 2009 17:47:59 GMT Date: Fri, 5 Jun 2009 17:47:59 +0000 From: bmanning@vacation.karoshi.com To: Olafur Gudmundsson Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 Message-ID: <20090605174759.GA7676@vacation.karoshi.com.> References: <200906050205.n5525TNM014056@drugs.dv.isc.org> <824ouvvw1v.fsf@mid.bfk.de> <20090605170616.GA7209@vacation.karoshi.com> <200906051711.n55HBOKg006030@stora.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906051711.n55HBOKg006030@stora.ogud.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 05, 2009 at 01:11:14PM -0400, Olafur Gudmundsson wrote: > At 13:06 05/06/2009, bmanning@vacation.karoshi.com wrote: > >On Fri, Jun 05, 2009 at 09:49:18AM -0700, David Conrad wrote: > >> Florian, > >> > >> On Jun 5, 2009, at 3:01 AM, Florian Weimer wrote: > >> >To be honest, I have serious doubts if it makes sense to worry about > >> >this. > >> > >> How many TCP sessions are the root servers prepared to handle? > > > > to be fair, your should likely recast this as: > > > > how many concurrent TCP sessions are DNS servers prepared to > > handle? > > Bill, > you are a root server operator, > what order of magnitude of concurrent TCP sessions are YOUR DNS servers > prepared to handle? > 10^x x = ? > > Olafur before or after we tune the OS and the DNS server software? defaults are quite small, since the expectation is UDP... --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 10:55:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707BB3A68D2; Fri, 5 Jun 2009 10:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.925 X-Spam-Level: X-Spam-Status: No, score=-102.925 tagged_above=-999 required=5 tests=[AWL=3.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Phz7e0dvaVWZ; Fri, 5 Jun 2009 10:55:54 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 88FB03A67FD; Fri, 5 Jun 2009 10:55:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCdbb-000Bbh-QG for namedroppers-data0@psg.com; Fri, 05 Jun 2009 17:53:27 +0000 Received: from [74.125.46.30] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCdbQ-000BZs-J9 for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 17:53:22 +0000 Received: by yw-out-2324.google.com with SMTP id 3so900359ywj.71 for ; Fri, 05 Jun 2009 10:53:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.83.2 with SMTP id g2mr3113677agb.38.1244224395395; Fri, 05 Jun 2009 10:53:15 -0700 (PDT) Date: Fri, 5 Jun 2009 10:53:15 -0700 Message-ID: Subject: [dnsext] Distributing the root zone out of band From: Matthew Dempsky To: Olafur Gudmundsson Cc: bmanning@vacation.karoshi.com, 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: On Fri, Jun 5, 2009 at 10:11 AM, Olafur Gudmundsson wrote: > Bill, > you are a root server operator, > what order of magnitude of concurrent TCP sessions are YOUR DNS servers > prepared to handle? > =A0 =A0 =A0 =A0 10^x =A0x =3D ? If we're worried about overloading the root servers, why not advocate more caches download the root zone out of band? E.g., it's already possible to download a zlib compressed root zone file from http://www.internic.net/domain/ along with a PGP signature (signed by the same people that will hold the root zone's DNSSEC keys), verify it, and configure your DNS cache to use it. This can be easily automated by a monthly cron job. Large TLD operators can then stop worrying about making sure their delegation records fit into a single 512 byte packet. It's also possible to distribute the root zone file and signature using mechanisms like BitTorrent to further distribute load. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 12:07:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151083A689C; Fri, 5 Jun 2009 12:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.284 X-Spam-Level: X-Spam-Status: No, score=-1.284 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2Q7X6RTlpkG; Fri, 5 Jun 2009 12:07:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 47A853A687C; Fri, 5 Jun 2009 12:07:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCefj-000IFb-3C for namedroppers-data0@psg.com; Fri, 05 Jun 2009 19:01:47 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCefW-000IDX-8U for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 19:01:41 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n55J1AVT007582; Fri, 5 Jun 2009 15:01:11 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906051901.n55J1AVT007582@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 05 Jun 2009 15:00:59 -0400 To: Paul Vixie , David Conrad From: Olafur Gudmundsson Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 Cc: Mark Andrews , Olafur Gudmundsson , namedroppers@ops.ietf.org In-Reply-To: <33672.1244223046@nsa.vix.com> References: <200906050205.n5525TNM014056@drugs.dv.isc.org> <33672.1244223046@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 13:30 05/06/2009, Paul Vixie wrote: > > From: David Conrad > > Date: Fri, 5 Jun 2009 10:02:11 -0700 > > ... > > Lovely. Turn off DO if you fall back to a buffer size less than 1220. > >without intending this as instructions to marka, i have to say, i agree. This is not just Bind at least: drill, unbound, Net::DNS, and dnsjava have the same issue. I can see that tools like drill that are used for testing can overwrite the RFC3226 recommendation, but recursive resolvers should by default not do that. At the same time if the recommendation in RFC3226 is out-of-date then we should update it. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 14:44:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F453A676A; Fri, 5 Jun 2009 14:44:28 -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 xb8PLVHimKQW; Fri, 5 Jun 2009 14:44:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 293633A6886; Fri, 5 Jun 2009 14:44:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCh7c-00069K-Hy for namedroppers-data0@psg.com; Fri, 05 Jun 2009 21:38: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.69 (FreeBSD)) (envelope-from ) id 1MCh7P-000689-FW for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 21:38:39 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 10289A48DC for ; Fri, 5 Jun 2009 21:38:31 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 In-Reply-To: Your message of "Fri, 05 Jun 2009 17:47:59 GMT." <20090605174759.GA7676@vacation.karoshi.com.> References: <200906050205.n5525TNM014056@drugs.dv.isc.org> <824ouvvw1v.fsf@mid.bfk.de> <20090605170616.GA7209@vacation.karoshi.com> <200906051711.n55HBOKg006030@stora.ogud.com> <20090605174759.GA7676@vacation.karoshi.com.> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 05 Jun 2009 21:38:31 +0000 Message-ID: <47702.1244237911@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Fri, 5 Jun 2009 17:47:59 +0000 > From: bmanning@vacation.karoshi.com > > 10^x x = ? > > before or after we tune the OS and the DNS server software? > defaults are quite small, since the expectation is UDP... the speed of light being a constant, but with the number of connected endsystems and networks increasing, and with the density of interconnects gradually declining... tuning does not matter. it's those darn round trips. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 14:44:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7971B3A6994; Fri, 5 Jun 2009 14:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Zj5okuk+kiYx; Fri, 5 Jun 2009 14:44:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 95A483A676A; Fri, 5 Jun 2009 14:44:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MChAn-0006RO-NY for namedroppers-data0@psg.com; Fri, 05 Jun 2009 21:42:01 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MChAW-0006PT-Bq for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 21:41:55 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0E872A48CD; Fri, 5 Jun 2009 21:41:44 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Matthew Dempsky cc: Olafur Gudmundsson , bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: [dnsext] Distributing the root zone out of band In-Reply-To: Your message of "Fri, 05 Jun 2009 10:53:15 MST." References: X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 05 Jun 2009 21:41:44 +0000 Message-ID: <47784.1244238104@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Fri, 5 Jun 2009 10:53:15 -0700 > From: Matthew Dempsky > > If we're worried about overloading the root servers, we're not. it's any authoritative server. the root servers are being used as a narrow example but the com, com.br, co.uk, cn, and other zones are going to have the same issue. > why not advocate more caches download the root zone out of band? because it goes stale, and gets deliberately amended, leading to chaos. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 14:55:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CCFC3A685B; Fri, 5 Jun 2009 14:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIe3wUMj3I85; Fri, 5 Jun 2009 14:55:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 869073A6994; Fri, 5 Jun 2009 14:55:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MChJ5-0007Ef-JI for namedroppers-data0@psg.com; Fri, 05 Jun 2009 21:50:35 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MChIo-0007CE-L5 for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 21:50:29 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n55Llrtj008891; Fri, 5 Jun 2009 21:47:53 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n55Llr4A008890; Fri, 5 Jun 2009 21:47:53 GMT Date: Fri, 5 Jun 2009 21:47:53 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: Matthew Dempsky , Olafur Gudmundsson , bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: [dnsext] Distributing the root zone out of band Message-ID: <20090605214753.GC8807@vacation.karoshi.com.> References: <47784.1244238104@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47784.1244238104@nsa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 05, 2009 at 09:41:44PM +0000, Paul Vixie wrote: > > Date: Fri, 5 Jun 2009 10:53:15 -0700 > > From: Matthew Dempsky > > > > If we're worried about overloading the root servers, > > we're not. it's any authoritative server. the root servers are being > used as a narrow example but the com, com.br, co.uk, cn, and other zones > are going to have the same issue. hence the ammended query... "concurrent TCP sessions to nameservers" > > why not advocate more caches download the root zone out of band? > > because it goes stale, and gets deliberately amended, leading to chaos. there are plans to significantly change the dynamic on/in the root zone. designing a stratagy that presumes a fairly small, static root zone might be short sighted. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 14:58:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179A33A685B; Fri, 5 Jun 2009 14:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2wuEOy89o-s; Fri, 5 Jun 2009 14:58:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B4583A6894; Fri, 5 Jun 2009 14:58:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MChNS-0007eL-AM for namedroppers-data0@psg.com; Fri, 05 Jun 2009 21:55:06 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MChNG-0007dU-VA for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 21:55:00 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n55Lqptj008946; Fri, 5 Jun 2009 21:52:51 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n55LqpP1008945; Fri, 5 Jun 2009 21:52:51 GMT Date: Fri, 5 Jun 2009 21:52:51 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 Message-ID: <20090605215251.GA8933@vacation.karoshi.com.> References: <200906050205.n5525TNM014056@drugs.dv.isc.org> <824ouvvw1v.fsf@mid.bfk.de> <20090605170616.GA7209@vacation.karoshi.com> <200906051711.n55HBOKg006030@stora.ogud.com> <20090605174759.GA7676@vacation.karoshi.com.> <47702.1244237911@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47702.1244237911@nsa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 05, 2009 at 09:38:31PM +0000, Paul Vixie wrote: > > Date: Fri, 5 Jun 2009 17:47:59 +0000 > > From: bmanning@vacation.karoshi.com > > > 10^x x = ? > > > > before or after we tune the OS and the DNS server software? > > defaults are quite small, since the expectation is UDP... > > the speed of light being a constant, but with the number of connected > endsystems and networks increasing, and with the density of interconnects > gradually declining... tuning does not matter. it's those darn round trips. well that and the half-open problems... but thats not what Olafur asked about... he asked how many... and I can't answer him w/o knowing if he wants the defaults or the tuned numbers. I'm not going to give him both --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 15:26:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ECBB3A6A83; Fri, 5 Jun 2009 15:26:23 -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 2oUvrmPSRwlH; Fri, 5 Jun 2009 15:26:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 170733A6A3A; Fri, 5 Jun 2009 15:26:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MChob-000A1n-Rx for namedroppers-data0@psg.com; Fri, 05 Jun 2009 22:23:09 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MChoQ-0009z3-VF for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 22:23:04 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A03ABA48DD; Fri, 5 Jun 2009 22:22:58 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: bmanning@vacation.karoshi.com cc: Matthew Dempsky , Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] Distributing the root zone out of band In-Reply-To: Your message of "Fri, 05 Jun 2009 21:47:53 GMT." <20090605214753.GC8807@vacation.karoshi.com.> References: <47784.1244238104@nsa.vix.com> <20090605214753.GC8807@vacation.karoshi.com.> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 05 Jun 2009 22:22:58 +0000 Message-ID: <49795.1244240578@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Fri, 5 Jun 2009 21:47:53 +0000 > From: bmanning@vacation.karoshi.com > > hence the ammended query... "concurrent TCP sessions to nameservers" whether talking merely about concurrency or not, tcp/53 doesn't scale to within four orders of magnitude of the QPS of udp/53. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 16:01:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373C53A67ED; Fri, 5 Jun 2009 16:01: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 2n-GeoHx69aa; Fri, 5 Jun 2009 16:01:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 589543A67E2; Fri, 5 Jun 2009 16:01:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCiL2-000CiS-Jn for namedroppers-data0@psg.com; Fri, 05 Jun 2009 22:56:40 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCiKq-000ChT-Ry for namedroppers@psg.com; Fri, 05 Jun 2009 22:56:34 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n55MuQ2K059728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Jun 2009 15:56:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 5 Jun 2009 15:56:25 -0700 To: namedroppers@psg.com From: Paul Hoffman Subject: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Greetings again. Appendix A.1 in RFC 4034 has the initial list of algorithm types for DNSSEC. To add to that table, one needs a standards-track RFC. This means that an signature algorithm that cannot be embodied in a standards-track RFC, such as because it is not completely in English, cannot be used interoperably in DNSSEC. For example, this might prevent the GOST work the WG has taken on from being used if the eventual RFC is Informational instead of Standards Track. This seems unnecessarily limiting. I am not aware of any other WG that requires a standards track RFC for allocating an identifier for a cryptographic specification. *Many* cryptographic specifications are described in Informational RFCs, and this has not been a problem for anyone. Therefore, I propose that the WG take on a short revision to RFC 4034 that makes the one change of making assignments into the IANA registry for DNSSEC Algorithm Types be "RFC Published". In addition, it would allow IANA to pre-assign values based on requests from an Area Director. This would allow Internet Drafts that are proposing new signature algorithms to contain valid examples of records using the proposed algorithms. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 16:14:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD893A6CD1; Fri, 5 Jun 2009 16:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwLrQOL+IUxW; Fri, 5 Jun 2009 16:14:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8E1833A6CC6; Fri, 5 Jun 2009 16:14:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCiYb-000DqA-97 for namedroppers-data0@psg.com; Fri, 05 Jun 2009 23:10:41 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCiYP-000DpD-HV for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 23:10:35 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n55N85tj009239; Fri, 5 Jun 2009 23:08:05 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n55N82XU009238; Fri, 5 Jun 2009 23:08:02 GMT Date: Fri, 5 Jun 2009 23:08:02 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: bmanning@vacation.karoshi.com, Paul Vixie , Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] Distributing the root zone out of band Message-ID: <20090605230802.GA9219@vacation.karoshi.com.> References: <47784.1244238104@nsa.vix.com> <20090605214753.GC8807@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 05, 2009 at 02:57:42PM -0700, Matthew Dempsky wrote: > On Fri, Jun 5, 2009 at 2:47 PM, wrote: > > there are plans to significantly change the dynamic on/in > > the root zone. designing a stratagy that presumes a fairly > > small, static root zone might be short sighted. > > Plans to significantly change the size and/or dynamic nature of the > root zone might be short sighted if the future requires a small, > [slowly changing] root zone. yes. but it seems clear that the POB have a very different view on what the future requirement might be. if you have thoughts on this... http://www.icann.org/en/public-comment/public-comment-200907.html#root-scaling --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 16:15:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25BB23A6AAA; Fri, 5 Jun 2009 16:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVZsC8CM3Vdn; Fri, 5 Jun 2009 16:15:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 43E473A68F7; Fri, 5 Jun 2009 16:15:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCiam-000E0h-9c for namedroppers-data0@psg.com; Fri, 05 Jun 2009 23:12:56 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCiaM-000Dyd-Gh for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 23:12:47 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n55N9wtj009254; Fri, 5 Jun 2009 23:10:03 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n55N9rnv009251; Fri, 5 Jun 2009 23:09:53 GMT Date: Fri, 5 Jun 2009 23:09:53 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: bmanning@vacation.karoshi.com, Matthew Dempsky , Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] Distributing the root zone out of band Message-ID: <20090605230953.GB9219@vacation.karoshi.com.> References: <47784.1244238104@nsa.vix.com> <20090605214753.GC8807@vacation.karoshi.com.> <49795.1244240578@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49795.1244240578@nsa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 05, 2009 at 10:22:58PM +0000, Paul Vixie wrote: > > Date: Fri, 5 Jun 2009 21:47:53 +0000 > > From: bmanning@vacation.karoshi.com > > > > hence the ammended query... "concurrent TCP sessions to nameservers" > > whether talking merely about concurrency or not, tcp/53 doesn't scale to > within four orders of magnitude of the QPS of udp/53. sure. and??? Olafurs question still stands. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 16:30:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65893A69F2; Fri, 5 Jun 2009 16:30:05 -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 BNKFwqzTkKFE; Fri, 5 Jun 2009 16:30:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B33713A68D3; Fri, 5 Jun 2009 16:30:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCiob-000FFY-7q for namedroppers-data0@psg.com; Fri, 05 Jun 2009 23:27:13 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCioQ-000FDb-04 for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 23:27:07 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 9FCAEA4908; Fri, 5 Jun 2009 23:27:01 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: bmanning@vacation.karoshi.com cc: Matthew Dempsky , Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] Distributing the root zone out of band In-Reply-To: Your message of "Fri, 05 Jun 2009 23:09:53 GMT." <20090605230953.GB9219@vacation.karoshi.com.> References: <47784.1244238104@nsa.vix.com> <20090605214753.GC8807@vacation.karoshi.com.> <49795.1244240578@nsa.vix.com> <20090605230953.GB9219@vacation.karoshi.com.> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 05 Jun 2009 23:27:01 +0000 Message-ID: <52494.1244244421@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Fri, 5 Jun 2009 23:09:53 +0000 > From: bmanning@vacation.karoshi.com ... > > > hence the ammended query... "concurrent TCP sessions to nameservers" > > > > whether talking merely about concurrency or not, tcp/53 doesn't scale to > > within four orders of magnitude of the QPS of udp/53. > > sure. and??? Olafurs question still stands. the answer is, the number is so low as to not be worth measuring precisely. any solution that ends in "or else we'll fall back to tcp/53" is quite doomed. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 16:52:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE493A6A73; Fri, 5 Jun 2009 16:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN8koQ86rKES; Fri, 5 Jun 2009 16:52:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AEFF13A69F2; Fri, 5 Jun 2009 16:52:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCj9d-000H14-TF for namedroppers-data0@psg.com; Fri, 05 Jun 2009 23:48:57 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCj9S-000H0P-Pb for namedroppers@ops.ietf.org; Fri, 05 Jun 2009 23:48:52 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 372A860B156; Fri, 5 Jun 2009 16:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0bEYrggVmnw; Fri, 5 Jun 2009 16:48:37 -0700 (PDT) Received: from wlan39-215.mdr.icann.org (wlan39-215.mdr.icann.org [192.0.39.215]) by virtualized.org (Postfix) with ESMTP id 02DCF60B148; Fri, 5 Jun 2009 16:48:36 -0700 (PDT) Cc: Matthew Dempsky , namedroppers@ops.ietf.org Message-Id: <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> From: David Conrad To: Paul Vixie In-Reply-To: <47784.1244238104@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Distributing the root zone out of band Date: Fri, 5 Jun 2009 16:48:36 -0700 References: <47784.1244238104@nsa.vix.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 5, 2009, at 2:41 PM, Paul Vixie wrote: > From: Matthew Dempsky >> why not advocate more caches download the root zone out of band? Great idea! > because it goes stale, and gets deliberately amended, leading to > chaos. Not if the root zone is slaved off a (set of) masters. Like, oh say, root.iana.org... Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 17:54:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0613F3A687A; Fri, 5 Jun 2009 17:54:08 -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 Nd+c+v+lvH4M; Fri, 5 Jun 2009 17:54:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B1DC3A6828; Fri, 5 Jun 2009 17:54:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCk5B-000Mjx-Jv for namedroppers-data0@psg.com; Sat, 06 Jun 2009 00:48: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.69 (FreeBSD)) (envelope-from ) id 1MCk50-000MjO-9a for namedroppers@ops.ietf.org; Sat, 06 Jun 2009 00:48:19 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id B3556A4924; Sat, 6 Jun 2009 00:48:13 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: David Conrad cc: Matthew Dempsky , namedroppers@ops.ietf.org Subject: Re: [dnsext] Distributing the root zone out of band In-Reply-To: Your message of "Fri, 05 Jun 2009 16:48:36 MST." <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sat, 06 Jun 2009 00:48:13 +0000 Message-ID: <55897.1244249293@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: David Conrad > Date: Fri, 5 Jun 2009 16:48:36 -0700 > > > because it goes stale, and gets deliberately amended, leading to chaos. > > Not if the root zone is slaved off a (set of) masters. Like, oh say, > root.iana.org... does iana want the rootops to start pulling the root zone from that server? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 18:27:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7583A687A; Fri, 5 Jun 2009 18:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-1.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRqDm2f-JoR6; Fri, 5 Jun 2009 18:27:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5DE893A6802; Fri, 5 Jun 2009 18:27:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCkdL-000P0V-EA for namedroppers-data0@psg.com; Sat, 06 Jun 2009 01:23:43 +0000 Received: from [74.125.46.29] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCkdA-000P07-9S for namedroppers@ops.ietf.org; Sat, 06 Jun 2009 01:23:37 +0000 Received: by yw-out-2324.google.com with SMTP id 3so1033746ywj.71 for ; Fri, 05 Jun 2009 18:23:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.89.8 with SMTP id m8mr3437117agb.23.1244251410922; Fri, 05 Jun 2009 18:23:30 -0700 (PDT) In-Reply-To: <55897.1244249293@nsa.vix.com> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <55897.1244249293@nsa.vix.com> Date: Fri, 5 Jun 2009 18:23:30 -0700 Message-ID: Subject: Re: [dnsext] Distributing the root zone out of band From: Matthew Dempsky To: Paul Vixie Cc: David Conrad , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 5, 2009 at 5:48 PM, Paul Vixie wrote: > does iana want the rootops to start pulling the root zone from that server? No. Open source software distributors have figured out how to efficiently mirror files much, much larger than the root zone. The root zone operators should follow their model. Example: According to [1], the Ubuntu Linux distribution has 300 mirrors with total bandwidth exceeding 250 Gbps available over HTTP, FTP, and RSYNC. According to [2], mirroring a single Ubuntu release requires at least 30GB, and a full mirror takes at least 200GB. I think the Internet has the resources to mirror the dozen or so files at http://www.internic.net/domain/. :) [1] https://launchpad.net/ubuntu/+archivemirrors [2] http://www.ubuntu.com/getubuntu/mirror/2 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 19:04:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55743A6A8F; Fri, 5 Jun 2009 19:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc+fYO3+9xdJ; Fri, 5 Jun 2009 19:04:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F216F3A68DE; Fri, 5 Jun 2009 19:04:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MClCR-0001PR-Fo for namedroppers-data0@psg.com; Sat, 06 Jun 2009 01:59:59 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MClCG-0001Op-4m for namedroppers@ops.ietf.org; Sat, 06 Jun 2009 01:59:54 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n561wGtj009878; Sat, 6 Jun 2009 01:58:21 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n561wDIQ009877; Sat, 6 Jun 2009 01:58:13 GMT Date: Sat, 6 Jun 2009 01:58:13 +0000 From: bmanning@vacation.karoshi.com To: ogud@ogud.com Cc: bmanning@vacation.karoshi.com, Matthew Dempsky , Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] Distributing the root zone out of band Message-ID: <20090606015813.GA9339@vacation.karoshi.com.> References: <47784.1244238104@nsa.vix.com> <20090605214753.GC8807@vacation.karoshi.com.> <49795.1244240578@nsa.vix.com> <20090605230953.GB9219@vacation.karoshi.com.> <52494.1244244421@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52494.1244244421@nsa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 05, 2009 at 11:27:01PM +0000, Paul Vixie wrote: > > Date: Fri, 5 Jun 2009 23:09:53 +0000 > > From: bmanning@vacation.karoshi.com > ... > > > > hence the ammended query... "concurrent TCP sessions to nameservers" > > > > > > whether talking merely about concurrency or not, tcp/53 doesn't scale to > > > within four orders of magnitude of the QPS of udp/53. > > > > sure. and??? Olafurs question still stands. > > the answer is, the number is so low as to not be worth measuring precisely. > any solution that ends in "or else we'll fall back to tcp/53" is quite doomed. there you go Olafur, Paul has answered your question for me. :) --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 19:13:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0091E3A6A8F; Fri, 5 Jun 2009 19:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvqF2Vr89jqB; Fri, 5 Jun 2009 19:13:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF9F43A6802; Fri, 5 Jun 2009 19:13:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MClMA-00025E-K6 for namedroppers-data0@psg.com; Sat, 06 Jun 2009 02:10:02 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MClLs-00024K-2a for namedroppers@ops.ietf.org; Sat, 06 Jun 2009 02:09:56 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id ADA2FA493D; Sat, 6 Jun 2009 02:09:43 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Matthew Dempsky cc: David Conrad , namedroppers@ops.ietf.org Subject: Re: [dnsext] Distributing the root zone out of band In-Reply-To: Your message of "Fri, 05 Jun 2009 18:23:30 MST." References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <55897.1244249293@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sat, 06 Jun 2009 02:09:43 +0000 Message-ID: <59158.1244254183@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Fri, 5 Jun 2009 18:23:30 -0700 > From: Matthew Dempsky > > On Fri, Jun 5, 2009 at 5:48 PM, Paul Vixie wrote: > > does iana want the rootops to start pulling the root zone from that server? > > No. are you the iana? > Open source software distributors have figured out how to efficiently > mirror files much, much larger than the root zone. The root zone > operators should follow their model. since i was doing this at gatekeeper.dec.com in 1989 and my boss was doing it at ftp.uu.net even earlier, and since my day job now hosts or operates mirrors for just about every f/l/oss project, i am amused by your lecture. > Example: According to [1], the Ubuntu Linux distribution has 300 > mirrors with total bandwidth exceeding 250 Gbps available over HTTP, > FTP, and RSYNC. According to [2], mirroring a single Ubuntu release > requires at least 30GB, and a full mirror takes at least 200GB. > > I think the Internet has the resources to mirror the dozen or so files > at http://www.internic.net/domain/. :) changing them every day, plus more often in emergencies, and avoiding the ever present tendancy to let them get out of date or concatenate local TLDs into each host's mix, are the problems. not the bits. but we are far afield. the root zone isn't the interesting part. nor the other files on www.internic.net. it's all authority zones, everywhere, and i don't think we want to rsync those to every endsystem. (we abandoned the old HOSTS.TXT file for several reasons, of which "scale" was one.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 5 19:24:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DCD03A6892; Fri, 5 Jun 2009 19:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, 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 QpN7BsZsYn-G; Fri, 5 Jun 2009 19:24:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0BD903A6802; Fri, 5 Jun 2009 19:24:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MClVj-0002m1-So for namedroppers-data0@psg.com; Sat, 06 Jun 2009 02:19:55 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MClVY-0002lP-FU for namedroppers@ops.ietf.org; Sat, 06 Jun 2009 02:19:50 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id DA98960B86F; Fri, 5 Jun 2009 19:19:43 -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 B5OiAa3S-nka; Fri, 5 Jun 2009 19:19:41 -0700 (PDT) Received: from 216.98.224.10.in-addr.arpa (m190436d0.tmodns.net [208.54.4.25]) by virtualized.org (Postfix) with ESMTP id 3BD1C60B864; Fri, 5 Jun 2009 19:19:41 -0700 (PDT) Cc: Matthew Dempsky , namedroppers@ops.ietf.org Message-Id: <00FB1403-1863-41F5-824B-119E9A90C24D@virtualized.org> From: David Conrad To: Paul Vixie In-Reply-To: <55897.1244249293@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Distributing the root zone out of band Date: Fri, 5 Jun 2009 19:19:40 -0700 References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <55897.1244249293@nsa.vix.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 5, 2009, at 5:48 PM, Paul Vixie wrote: >> Not if the root zone is slaved off a (set of) masters. Like, oh say, >> root.iana.org... > does iana want the rootops to start pulling the root zone from that > server? Well, I'm told IANA doesn't exist, so it would be difficult for it to want anything. I'm also told the root servers were independent and thus, even if IANA were to exist, the root servers operators would do what they thought best for the communities they believe they serve regardless of what anyone else wants. :-) (if anyone actually needed this) More seriously, root.iana.org is part of a two testbeds (the other being ns.iana.org) ICANN set up for folks to test a DNSSEC-signed root. I expect they'll both be discontinued when the root gets signed. However, this is somewhat orthogonal to what Matthew was proposing. The point is that your concern about staleness of the 'cached' root zone would not be an issue if people slave off a (set of) servers set up to respond to root zone transfer requests. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From magagnoc@akzonobel.com Fri Jun 5 19:45:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D61B3A6B69 for ; Fri, 5 Jun 2009 19:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.982 X-Spam-Level: X-Spam-Status: No, score=-26.982 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 F9zeneLMcVV0 for ; Fri, 5 Jun 2009 19:45:49 -0700 (PDT) Received: from ali-albazzaz.com (unknown [200.115.232.227]) by core3.amsl.com (Postfix) with SMTP id 44A0E3A6768 for ; Fri, 5 Jun 2009 19:45:42 -0700 (PDT) To: " Date: Fri, 5 Jun 2009 19:45:42 -0700 (PDT)
Tell a friend · Download latest version See this email as a webpage

Hello!

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

Ottho Heldringstraat 8, 25523 AZ Amsterdam, The Netherlands
From owner-namedroppers@ops.ietf.org Fri Jun 5 23:14:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAE4A3A6827; Fri, 5 Jun 2009 23:14:23 -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 wBNp87die7go; Fri, 5 Jun 2009 23:14:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DF3D23A67F2; Fri, 5 Jun 2009 23:14:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCp4V-000Lt7-5d for namedroppers-data0@psg.com; Sat, 06 Jun 2009 06:08:03 +0000 Received: from [195.54.233.69] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCp4I-000Lnz-Ln for namedroppers@ops.ietf.org; Sat, 06 Jun 2009 06:07:56 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gromit.rfc1035.com (Postfix) with ESMTP id 070574A6F18; Sat, 6 Jun 2009 07:07:48 +0100 (BST) Cc: Paul Vixie , Matthew Dempsky , namedroppers@ops.ietf.org Message-Id: <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> From: Jim Reid To: David Conrad In-Reply-To: <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] TCP queries to the root servers Date: Sat, 6 Jun 2009 07:07:48 +0100 References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 6 Jun 2009, at 00:48, David Conrad wrote: >> because it goes stale, and gets deliberately amended, leading to >> chaos. > > Not if the root zone is slaved off a (set of) masters. Like, oh > say, root.iana.org... How many TCP queries can this set of masters handle? :-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 6 00:05:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC92A3A69F9; Sat, 6 Jun 2009 00:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.682 X-Spam-Level: X-Spam-Status: No, score=-0.682 tagged_above=-999 required=5 tests=[AWL=-1.432, 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 ZViuOSP4-hib; Sat, 6 Jun 2009 00:05:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E98E53A6827; Sat, 6 Jun 2009 00:05:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCpuG-0003I0-NH for namedroppers-data0@psg.com; Sat, 06 Jun 2009 07:01:32 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCpu5-0003HH-LO for namedroppers@ops.ietf.org; Sat, 06 Jun 2009 07:01:27 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MCptu-00046V-OB; Sat, 06 Jun 2009 09:01:10 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MCptu-0003ha-EV; Sat, 06 Jun 2009 09:01:10 +0200 From: Florian Weimer To: Paul Vixie Cc: Matthew Dempsky , David Conrad , namedroppers@ops.ietf.org Subject: Re: [dnsext] Distributing the root zone out of band References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <55897.1244249293@nsa.vix.com> <59158.1244254183@nsa.vix.com> Date: Sat, 06 Jun 2009 09:01:10 +0200 In-Reply-To: <59158.1244254183@nsa.vix.com> (Paul Vixie's message of "Sat, 06 Jun 2009 02:09:43 +0000") Message-ID: <874out26dl.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Paul Vixie: > changing them every day, plus more often in emergencies, and avoiding the > ever present tendancy to let them get out of date or concatenate local TLDs > into each host's mix, are the problems. not the bits. We need this for the trust anchor(s) anyway (including non-DNS fallback for the download). Once we've got that, it's not a significant challenge to ship more than just DNSKEYs---except that the root is already fragmented and we don't know what contents our users see or want, so this is unlikely to work on a global scale. (I don't know what this means for the trust anchors, but I think we'll know the answer in a couple of months.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 6 08:14:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD8903A6911; Sat, 6 Jun 2009 08:14:47 -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 w3BcwoNIcfZB; Sat, 6 Jun 2009 08:14:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A58B03A67E5; Sat, 6 Jun 2009 08:14:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCxUi-000MnI-Uj for namedroppers-data0@psg.com; Sat, 06 Jun 2009 15:07:40 +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.69 (FreeBSD)) (envelope-from ) id 1MCxUM-000Mlk-U4 for namedroppers@ops.ietf.org; Sat, 06 Jun 2009 15:07:29 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n56F67eh099916; Sat, 6 Jun 2009 17:06:07 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200906061506.n56F67eh099916@givry.fdupont.fr> From: Francis Dupont To: Olaf Kolkman cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated In-reply-to: Your message of Thu, 04 Jun 2009 18:10:56 +0200. <586D8C19-F943-4573-A6CB-705DD46FF169@NLnetLabs.nl> Date: Sat, 06 Jun 2009 17:06:07 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: Also in the introduction Context: security came to be considered lower than expected Question: Is there a stable and recognized reference for that claim? => it is the RFC4635 itself but if you'd like a stable and recognized reference about HMAC-MD5 itself there is none. If there is a stable and recognized reference about the claim for SHA1 that might be useful => again there is no claim about HMAC-SHA1 but annoncements about both weaknesses in SHA-1 (you can get a lot in crypto conferences, BTW if a significant progress is done the situation could become not so funny :-) and which is more related to the document about some usages (which don't include HMAC) of SHA-1 in http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html If you prefer RFCs or I-Ds draft-ietf-dnsext-dnssec-rsasha256-14.txt or RFC 4509 should be fine and are in the domain... Thanks Francis.Dupont@fdupont.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 01:48:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D233A6953; Sun, 7 Jun 2009 01:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Ko-vqSYEcwdS; Sun, 7 Jun 2009 01:48:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5AB053A67A4; Sun, 7 Jun 2009 01:48:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDDwk-000OyJ-PS for namedroppers-data0@psg.com; Sun, 07 Jun 2009 08:41:42 +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.69 (FreeBSD)) (envelope-from ) id 1MDDwZ-000OxH-KQ for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 08:41:37 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n578fNvd006794; Sun, 7 Jun 2009 10:41:23 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200906070841.n578fNvd006794@givry.fdupont.fr> From: Francis Dupont To: Federico Lucifredi cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated In-reply-to: Your message of Thu, 04 Jun 2009 22:37:13 EDT. <4A2884D9.8020408@acm.org> Date: Sun, 07 Jun 2009 10:41:23 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: I do not like (6), which goes in the opposite direction. => the reason is in (5) and BTW is not a security reason... Francis.Dupont@fdupont.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 02:15:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87EAC3A6B54; Sun, 7 Jun 2009 02:15:17 -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 O+DWFzoARCZj; Sun, 7 Jun 2009 02:15:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 97C033A6879; Sun, 7 Jun 2009 02:15:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDEPO-0001p2-DG for namedroppers-data0@psg.com; Sun, 07 Jun 2009 09:11:18 +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.69 (FreeBSD)) (envelope-from ) id 1MDEPD-0001o7-8W for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 09:11:12 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n579AxP4006969; Sun, 7 Jun 2009 11:11:00 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200906070911.n579AxP4006969@givry.fdupont.fr> From: Francis Dupont To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated In-reply-to: Your message of Fri, 05 Jun 2009 16:52:01 -0000. <31631.1244220721@nsa.vix.com> Date: Sun, 07 Jun 2009 11:10:59 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: so it's not being deprecated, and the name of the draft is wrong, and the title of the draft is wrong? i'd like the word "deprecated" stripped from the text in that case. if we're just relaxing the "mandatoriness" then we ought to say that, to avoid confusing operators and future implementors. => I agree the term deprecate is a bit too strong... but obsolete is not really better, what do you propose? Thanks Francis.Dupont@fdupont.fr PS: the two remaining issues are the wording for HMAC-MD5 use (I suggest to go to lower cases) and the interoperability of TKEY. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 08:14:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39B33A68E8; Sun, 7 Jun 2009 08:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFb6ihTVtByq; Sun, 7 Jun 2009 08:13:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 298773A6948; Sun, 7 Jun 2009 08:13:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDJxg-0006af-VS for namedroppers-data0@psg.com; Sun, 07 Jun 2009 15:07:04 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDJxV-0006Xe-57 for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 15:06:59 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=YxQimGKonB4rSOHQxTMqKu81R3xy5oX1x96J+fl6v45WkKBb9tQKJz41fgv5BEApl8t9e8o/Rge3hp12s5WO8deCzqwbCSVGrLeB2tjos808ogqLtwkGm5u/ikITZi9S; Received: from [199.212.90.28] (helo=dh28.r1.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDJwE-0006LO-V1; Sun, 07 Jun 2009 15:05:35 +0000 Cc: Paul Vixie , namedroppers@ops.ietf.org Message-Id: <20A36925-CBA9-4087-9A13-B35EAB6D9FBE@hopcount.ca> From: Joe Abley To: Francis Dupont In-Reply-To: <200906070911.n579AxP4006969@givry.fdupont.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated Date: Sun, 7 Jun 2009 11:05:34 -0400 References: <200906070911.n579AxP4006969@givry.fdupont.fr> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 7-Jun-2009, at 05:10, Francis Dupont wrote: > In your previous mail you wrote: > > so it's not being deprecated, and the name of the draft is wrong, > and the > title of the draft is wrong? i'd like the word "deprecated" > stripped from > the text in that case. if we're just relaxing the "mandatoriness" > then we > ought to say that, to avoid confusing operators and future > implementors. > > => I agree the term deprecate is a bit too strong... but obsolete > is not really better, what do you propose? "no longer recommended"? Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 11:05:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9513D3A6D11; Sun, 7 Jun 2009 11:05:29 -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 kdBFeYzPojuG; Sun, 7 Jun 2009 11:05:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C7CEC3A6C51; Sun, 7 Jun 2009 11:05:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDMeJ-000MsJ-JX for namedroppers-data0@psg.com; Sun, 07 Jun 2009 17:59:15 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDMe8-000MrL-PT for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 17:59:10 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5FD66A4C57; Sun, 7 Jun 2009 17:59:04 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Francis Dupont cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated In-Reply-To: Your message of "Sun, 07 Jun 2009 11:10:59 +0200." <200906070911.n579AxP4006969@givry.fdupont.fr> References: <200906070911.n579AxP4006969@givry.fdupont.fr> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sun, 07 Jun 2009 17:59:04 +0000 Message-ID: <51998.1244397544@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Francis Dupont > Date: Sun, 07 Jun 2009 11:10:59 +0200 > > => I agree the term deprecate is a bit too strong... but obsolete > is not really better, what do you propose? something like "relax". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 11:05:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1DE33A6CF7; Sun, 7 Jun 2009 11:05:41 -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 GHo1wMRc4Iud; Sun, 7 Jun 2009 11:05:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 17E6C3A6D16; Sun, 7 Jun 2009 11:05:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDMgC-000NJs-EZ for namedroppers-data0@psg.com; Sun, 07 Jun 2009 18:01:12 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDMfz-000NHs-Ub for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 18:01:06 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 96C97A4C5C; Sun, 7 Jun 2009 18:00:59 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Joe Abley cc: Francis Dupont , namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated In-Reply-To: Your message of "Sun, 07 Jun 2009 11:05:34 -0400." <20A36925-CBA9-4087-9A13-B35EAB6D9FBE@hopcount.ca> References: <200906070911.n579AxP4006969@givry.fdupont.fr> <20A36925-CBA9-4087-9A13-B35EAB6D9FBE@hopcount.ca> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sun, 07 Jun 2009 18:00:59 +0000 Message-ID: <52224.1244397659@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Joe Abley > Date: Sun, 7 Jun 2009 11:05:34 -0400 > > > => I agree the term deprecate is a bit too strong... but obsolete > > is not really better, what do you propose? > > "no longer recommended"? that's too strong. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 11:55:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D55D3A6ADE; Sun, 7 Jun 2009 11:55:41 -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 RQvzKnWPPUqK; Sun, 7 Jun 2009 11:55:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D74F3A697E; Sun, 7 Jun 2009 11:55:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDNS6-0002D4-R5 for namedroppers-data0@psg.com; Sun, 07 Jun 2009 18:50:42 +0000 Received: from [209.85.219.222] (helo=mail-ew0-f222.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDNRt-0002BG-Sl for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 18:50:37 +0000 Received: by ewy22 with SMTP id 22so424232ewy.41 for ; Sun, 07 Jun 2009 11:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TPFAUCxxxzzvxZEHG8CiC5pn/s5EigszzVZ7GO6/EnY=; b=t+W27F/L7BtbF3pc8AiASv65A/yIaKaGs7YkHfxywqrKmyFjo0qg4ttIhLdz/p+yrQ MHRu321X9k7a3x00+cjp/Tj84uOoiwnjwWe8ByC05lT19IEybdmF7bZGvnYOgzOR/bAU 1T56UvbdKITpWBZKtExYCQwTt/AbefQ4ApDlU= 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=eGS/nTL8LbEC7lAguS2kO3Hc4pSagKf8d5zZN/nGLEsiGG0DoZSm3Ha6Ok4m1xOQrP rrKF89VJyfpceKbE3wqF1FzvqBp/L4rMX9vqOVqFTNzJ4KRL0yq+mtf8+mAqjS+UuZ17 JyEKJ3ygrhjcuYHbTBGu5+cBv332EBy57hDO0= MIME-Version: 1.0 Received: by 10.216.10.208 with SMTP id 58mr2094111wev.82.1244400627408; Sun, 07 Jun 2009 11:50:27 -0700 (PDT) In-Reply-To: <52224.1244397659@nsa.vix.com> References: <200906070911.n579AxP4006969@givry.fdupont.fr> <20A36925-CBA9-4087-9A13-B35EAB6D9FBE@hopcount.ca> <52224.1244397659@nsa.vix.com> Date: Sun, 7 Jun 2009 14:50:27 -0400 Message-ID: <1028365c0906071150u4efbd6ebu402df4ceedcaae7a@mail.gmail.com> Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated From: Donald Eastlake To: Paul Vixie Cc: Joe Abley , Francis Dupont , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: "No longer mandatory"? ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com On Sun, Jun 7, 2009 at 2:00 PM, Paul Vixie wrote: >> From: Joe Abley >> Date: Sun, 7 Jun 2009 11:05:34 -0400 >> >> > => I agree the term deprecate is a bit too strong... but obsolete >> > is not really better, what do you propose? >> >> "no longer recommended"? > > that's too strong. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 12:03:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0626B3A6A32; Sun, 7 Jun 2009 12:03:34 -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 zI3-zxYy14eY; Sun, 7 Jun 2009 12:03:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 433053A69FC; Sun, 7 Jun 2009 12:03:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDNat-00033f-Sz for namedroppers-data0@psg.com; Sun, 07 Jun 2009 18:59:47 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDNaa-000322-Ch for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 18:59:38 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0786EA4C67; Sun, 7 Jun 2009 18:59:28 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Donald Eastlake cc: Joe Abley , Francis Dupont , namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated In-Reply-To: Your message of "Sun, 07 Jun 2009 14:50:27 -0400." <1028365c0906071150u4efbd6ebu402df4ceedcaae7a@mail.gmail.com> References: <200906070911.n579AxP4006969@givry.fdupont.fr> <20A36925-CBA9-4087-9A13-B35EAB6D9FBE@hopcount.ca> <52224.1244397659@nsa.vix.com> <1028365c0906071150u4efbd6ebu402df4ceedcaae7a@mail.gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sun, 07 Jun 2009 18:59:28 +0000 Message-ID: <54369.1244401168@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > "No longer mandatory"? right strength, wrong timeliness. we need a timeless phrase. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 12:06:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C783A6C6D; Sun, 7 Jun 2009 12:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXH881FLy81a; Sun, 7 Jun 2009 12:06:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 149733A6C26; Sun, 7 Jun 2009 12:06:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDNdV-0003Lb-Vk for namedroppers-data0@psg.com; Sun, 07 Jun 2009 19:02:30 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDNdI-0003Kg-Ca for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 19:02:24 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=nf7zWS/L4Y859FUD6amX4060q/79TkARmyuBYz32VGNtgMNwvcf+7pCtRfxNb6zGcj+wfdQgSy2EbxkZBzMlcw5OzMH0R77RwlS0pJKI5mJMPlIJb2TL8lX/zL56vhVY; Received: from [69.156.211.34] (helo=[10.255.1.149]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDNbs-0008R6-Ho; Sun, 07 Jun 2009 19:00:54 +0000 Cc: Donald Eastlake , Francis Dupont , namedroppers@ops.ietf.org Message-Id: From: Joe Abley To: Paul Vixie In-Reply-To: <54369.1244401168@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated Date: Sun, 7 Jun 2009 15:00:42 -0400 References: <200906070911.n579AxP4006969@givry.fdupont.fr> <20A36925-CBA9-4087-9A13-B35EAB6D9FBE@hopcount.ca> <52224.1244397659@nsa.vix.com> <1028365c0906071150u4efbd6ebu402df4ceedcaae7a@mail.gmail.com> <54369.1244401168@nsa.vix.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 7-Jun-2009, at 14:59, Paul Vixie wrote: >> "No longer mandatory"? > > right strength, wrong timeliness. we need a timeless phrase. "not mandatory"? :-) Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 12:22:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3636F3A6D28; Sun, 7 Jun 2009 12:22:56 -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 AjgLC7WNfCSA; Sun, 7 Jun 2009 12:22:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 472573A6D09; Sun, 7 Jun 2009 12:22:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDNtC-0004xx-CI for namedroppers-data0@psg.com; Sun, 07 Jun 2009 19:18: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.69 (FreeBSD)) (envelope-from ) id 1MDNt1-0004ww-Fv for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 19:18:36 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 12236A4C6A; Sun, 7 Jun 2009 19:18:31 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Joe Abley cc: Donald Eastlake , Francis Dupont , namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated In-Reply-To: Your message of "Sun, 07 Jun 2009 15:00:42 -0400." References: <200906070911.n579AxP4006969@givry.fdupont.fr> <20A36925-CBA9-4087-9A13-B35EAB6D9FBE@hopcount.ca> <52224.1244397659@nsa.vix.com> <1028365c0906071150u4efbd6ebu402df4ceedcaae7a@mail.gmail.com> <54369.1244401168@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sun, 07 Jun 2009 19:18:30 +0000 Message-ID: <55174.1244402310@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > "not mandatory"? :-) "is henceforth not required" -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 12:29:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAC23A6D63; Sun, 7 Jun 2009 12:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rN+ijCUkusl; Sun, 7 Jun 2009 12:29:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 603783A6D54; Sun, 7 Jun 2009 12:29:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDO0O-0005hm-Ly for namedroppers-data0@psg.com; Sun, 07 Jun 2009 19:26:08 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDO07-0005ef-P6 for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 19:26:02 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=dEgTu75mGVasqoF9X5EciG6aP3rX0Q3A8qaQRF2ldo7ESMtJk/KKGmeteoiB+lwOHEEmSS5xQNbZV69lx0SIN0yUmB+N4N+WxXsNQR87KUQcsc/HHjmGLocNrFtSTpal; Received: from [69.156.211.34] (helo=[10.255.1.149]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDO03-0008ca-LD; Sun, 07 Jun 2009 19:25:48 +0000 Cc: Donald Eastlake , Francis Dupont , namedroppers@ops.ietf.org Message-Id: <630EAB55-B179-497F-8F0A-1F86D06C9EB1@hopcount.ca> From: Joe Abley To: Paul Vixie In-Reply-To: <55174.1244402310@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated Date: Sun, 7 Jun 2009 15:25:50 -0400 References: <200906070911.n579AxP4006969@givry.fdupont.fr> <20A36925-CBA9-4087-9A13-B35EAB6D9FBE@hopcount.ca> <52224.1244397659@nsa.vix.com> <1028365c0906071150u4efbd6ebu402df4ceedcaae7a@mail.gmail.com> <54369.1244401168@nsa.vix.com> <55174.1244402310@nsa.vix.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 7-Jun-2009, at 15:18, Paul Vixie wrote: >> "not mandatory"? :-) > > "is henceforth not required" Since it's Sunday, I'll enlarge this thread by one more message and observe that "is henceforth not required" seems directly equivalent to "is no longer mandatory" in meaning, strength and timelessness, to me. Given a choice between the two the latter seems kinder to non-native speakers since it avoids the use of the archaic word "henceforth". We could simplify further and re-cast in a positive sense as "is optional". Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 13:58:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890193A6951; Sun, 7 Jun 2009 13:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 eEdROpZxgEr0; Sun, 7 Jun 2009 13:57:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4DD83A6D9C; Sun, 7 Jun 2009 13:57:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDPM4-000DhD-Ko for namedroppers-data0@psg.com; Sun, 07 Jun 2009 20:52:36 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDPLs-000DgR-A4 for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 20:52:29 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n57KqI39060944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Jun 2009 13:52:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200906070911.n579AxP4006969@givry.fdupont.fr> References: <200906070911.n579AxP4006969@givry.fdupont.fr> Date: Sun, 7 Jun 2009 13:52:17 -0700 To: Francis Dupont From: Paul Hoffman Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 11:10 AM +0200 6/7/09, Francis Dupont wrote: > In your previous mail you wrote: > > so it's not being deprecated, and the name of the draft is wrong, and the > title of the draft is wrong? i'd like the word "deprecated" stripped from > the text in that case. if we're just relaxing the "mandatoriness" then we > ought to say that, to avoid confusing operators and future implementors. > >=> I agree the term deprecate is a bit too strong... but obsolete >is not really better, what do you propose? As I said earlier, I propose that we do not move this document forward because it is unneeded and will lead to lack of interop for no good reason. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 14:06:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2B828C10B; Sun, 7 Jun 2009 14:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGaFl5hWIR7N; Sun, 7 Jun 2009 14:06:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE8EB28C106; Sun, 7 Jun 2009 14:06:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDPWO-000EgV-C1 for namedroppers-data0@psg.com; Sun, 07 Jun 2009 21:03:16 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDPWD-000Efe-4d for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 21:03:10 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n57L33FS007366 for ; Sun, 7 Jun 2009 17:03:03 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n57L33Jr007365 for namedroppers@ops.ietf.org; Sun, 7 Jun 2009 17:03:03 -0400 (EDT) (envelope-from namedroppers) Received: from [69.17.117.5] (helo=mail3.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDAiB-0007K0-RM for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 05:14:33 +0000 Received: (qmail 3932 invoked from network); 7 Jun 2009 05:14:25 -0000 Received: from dsl092-066-189.bos1.dsl.speakeasy.net (HELO spaceman.local) (federico@[66.92.66.189]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 7 Jun 2009 05:14:25 -0000 Message-ID: <4A2B4CAF.8070307@acm.org> Date: Sun, 07 Jun 2009 01:14:23 -0400 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Paul Hoffman CC: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated References: <200905081453.n48ErDH3055593@stora.ogud.com> <200905201528.n4KFSsI3055828@stora.ogud.com> <200906041444.n54EiF2e005370@stora.ogud.com> <4A2884D9.8020408@acm.org> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: url=http://keyserver.linux.it/pks/lookup?op=get&search=0xAEEBEC184A73884C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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. ] Paul Hoffman wrote: > At 10:37 PM -0400 6/4/09, Federico Lucifredi wrote: [...] >> So, there is implicitly a reason to now go back and degrade MD5's status >> to optional. I know the papers, you know the papers. Something should be >> said here to explain why we are doing this -- or, if there is no reason, >> we should not be doing it. > > Exactly. So, if you "know the papers", please point out in any paper why it is justified that we deprecate MD5 in the uses covered in this draft. I can find none, but I might be missing something. > I looked around as well, and from what I can understand the algorithm is quite crippled in terms of collisions (even more than I recalled), but it seems that I cannot dig up a weakness impacting Keyed Hash applications. It may be still good to obsolete SHA-1 and MD5, but, I would still like to be able to list an objective reason rather than an unmentioned general feeling of uneasiness with research in an apparently somewhat unrelated weakness. >> Just so that it is clear, I _do_ support the change. I think we should >> explain why, however, with something along the thought line of "as >> research is progressively weakening MD5's cryptographic strength, it is >> now time to allocate mandatory status to algorithms not as of yet so >> compromised". > > To the best of my knowledge, there is no research weakening MD5's cryptographic strength in preimage attack. Again, I'm happy if you can point out research that I have missed, or show how the now-obvious weakening of MD5's collision resistance affects the use of HMAC-MD5 or MD5 used between trusted parties in TSIG. > I can't find any. >> I do not like (6), which goes in the opposite direction. > > At least it is honest. > >> We are doing >> this because we believe there is a reason to, are we? > > So far, no. Definitely looks that way. Best -F -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - flucifredi@acm.org - GnuPG 0x4A73884C -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 14:28:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 056CB28C104; Sun, 7 Jun 2009 14:28:56 -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 vzRWJhyDPEN0; Sun, 7 Jun 2009 14:28:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D934D3A6B83; Sun, 7 Jun 2009 14:28:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDPrm-000GtV-5K for namedroppers-data0@psg.com; Sun, 07 Jun 2009 21:25:22 +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.69 (FreeBSD)) (envelope-from ) id 1MDPrZ-000GpZ-Oq for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 21:25:16 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n57LP7Bf010548 for ; Sun, 7 Jun 2009 23:25:08 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200906072125.n57LP7Bf010548@givry.fdupont.fr> From: Francis Dupont To: namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated Date: Sun, 07 Jun 2009 23:25:07 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Hoffman asked me to make this public: [Me] I agree there is no crypto justification (even I talked two days ago with some cryptographers who said things have changed since the beginning of the year) but the operational justification still applies: IMHO it is a real problem for a compliant implementation (which have to support the mandatory HMAC-MD5) to not be allowed to use a certified (FIPS 140-2 for instance) crypto module for all crypto operations... [Paul] Could you send this message to the whole list? I believe that many people think there is a crypto justification, and it would be good for them to hear this from the document's author directly. Regards Francis.Dupont@fdupont.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 14:41:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953A33A6B83; Sun, 7 Jun 2009 14:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAzTgVrg180a; Sun, 7 Jun 2009 14:41:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BBF363A68AD; Sun, 7 Jun 2009 14:41:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDQ4a-000IHR-T9 for namedroppers-data0@psg.com; Sun, 07 Jun 2009 21:38:36 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDQ4O-000IGp-4P for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 21:38:31 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 44D26611257; Sun, 7 Jun 2009 14:38:22 -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 EFDgvXy4xzms; Sun, 7 Jun 2009 14:38:08 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 53C9361124C; Sun, 7 Jun 2009 14:38:08 -0700 (PDT) Cc: Paul Vixie , Matthew Dempsky , namedroppers@ops.ietf.org Message-Id: From: David Conrad To: Jim Reid In-Reply-To: <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] Re: TCP queries to the root servers Date: Sun, 7 Jun 2009 14:38:07 -0700 References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > On 6 Jun 2009, at 00:48, David Conrad wrote: >>> because it goes stale, and gets deliberately amended, leading to >>> chaos. >> Not if the root zone is slaved off a (set of) masters. Like, oh >> say, root.iana.org... > How many TCP queries can this set of masters handle? :-) Given the data is relatively stable (and thus could be replicated in an Akamai-like scheme) and the response requirements for zone transfer aren't anything like what they are for normal TCP queries, I'm not worried that the machines behind something like root.iana.org wouldn't be able to handle pretty much any load thrown at them. Also, since the data is signed, it wouldn't really matter where/how you get it... Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 15:58:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12E073A690D; Sun, 7 Jun 2009 15:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-1.081, 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 Y6mLKt6rn4z2; Sun, 7 Jun 2009 15:58:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E0F413A6869; Sun, 7 Jun 2009 15:58:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDREM-000PxD-N3 for namedroppers-data0@psg.com; Sun, 07 Jun 2009 22:52:46 +0000 Received: from [209.86.89.70] (helo=elasmtp-banded.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDRE7-000Pw7-BK for namedroppers@ops.ietf.org; Sun, 07 Jun 2009 22:52:37 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=CsIy+z52ISIU/KoEQE3d9kkLDUOOHypodR5ymKIyHtHttpCxJNeGFdyddIZXSl2n; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.96.210] (helo=ix.netcom.com) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MDRDw-0006lu-N1; Sun, 07 Jun 2009 18:52:21 -0400 Message-ID: <4A2C4497.A953457D@ix.netcom.com> Date: Sun, 07 Jun 2009 15:52:07 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman CC: Francis Dupont , namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated References: <200906070911.n579AxP4006969@givry.fdupont.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606880565f82d0975fe112c2739f9501265ee350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.96.210 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul and all, Reluctantly I agree with Paul on this issue. Paul Hoffman wrote: > At 11:10 AM +0200 6/7/09, Francis Dupont wrote: > > In your previous mail you wrote: > > > > so it's not being deprecated, and the name of the draft is wrong, and the > > title of the draft is wrong? i'd like the word "deprecated" stripped from > > the text in that case. if we're just relaxing the "mandatoriness" then we > > ought to say that, to avoid confusing operators and future implementors. > > > >=> I agree the term deprecate is a bit too strong... but obsolete > >is not really better, what do you propose? > > As I said earlier, I propose that we do not move this document forward because it is unneeded and will lead to lack of interop for no good reason. > > --Paul Hoffman, Director > --VPN Consortium > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 18:36:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997613A6863; Sun, 7 Jun 2009 18:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWwBS0JO+ujj; Sun, 7 Jun 2009 18:36:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE3373A6853; Sun, 7 Jun 2009 18:36:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDTgd-000G15-O8 for namedroppers-data0@psg.com; Mon, 08 Jun 2009 01:30:07 +0000 Received: from [69.17.117.8] (helo=mail6.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDTgG-000FwO-De for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 01:29:54 +0000 Received: (qmail 19690 invoked from network); 8 Jun 2009 01:29:44 -0000 Received: from dsl092-066-189.bos1.dsl.speakeasy.net (HELO spaceman.local) (federico@[66.92.66.189]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 8 Jun 2009 01:29:43 -0000 Message-ID: <4A2C6986.3000702@post.harvard.edu> Date: Sun, 07 Jun 2009 21:29:42 -0400 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Francis Dupont CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated References: <200906072125.n57LP7Bf010548@givry.fdupont.fr> In-Reply-To: <200906072125.n57LP7Bf010548@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Thanks, this clarifies it for me. Best -F Francis Dupont wrote: > Paul Hoffman asked me to make this public: > > [Me] I agree there is no crypto justification (even I talked two days ago > with some cryptographers who said things have changed since the > beginning of the year) but the operational justification still > applies: IMHO it is a real problem for a compliant implementation > (which have to support the mandatory HMAC-MD5) to not be allowed > to use a certified (FIPS 140-2 for instance) crypto module for > all crypto operations... > > [Paul] Could you send this message to the whole list? I believe that > many people think there is a crypto justification, and it would be > good for them to hear this from the document's author directly. > > Regards > > Francis.Dupont@fdupont.fr > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - lucifred@post.harvard.edu - GnuPG 0x4A73884C -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 18:40:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7103A683B; Sun, 7 Jun 2009 18:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUoyKmqw66rF; Sun, 7 Jun 2009 18:40:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9FE463A6834; Sun, 7 Jun 2009 18:40:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDTnz-000GmE-Mv for namedroppers-data0@psg.com; Mon, 08 Jun 2009 01:37:43 +0000 Received: from [69.17.117.9] (helo=mail7.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDTnm-000GlQ-3X for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 01:37:38 +0000 Received: (qmail 16400 invoked from network); 8 Jun 2009 01:37:28 -0000 Received: from dsl092-066-189.bos1.dsl.speakeasy.net (HELO spaceman.local) (federico@[66.92.66.189]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 8 Jun 2009 01:37:28 -0000 Message-ID: <4A2C6B57.20802@post.harvard.edu> Date: Sun, 07 Jun 2009 21:37:27 -0400 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Francis Dupont CC: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated References: <200906070841.n578fNvd006794@givry.fdupont.fr> In-Reply-To: <200906070841.n578fNvd006794@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Understood. The other mail forwarded to the thread makes the operational rationale clear. Perhaps a pointer in the Abstract, or in section (5) that the primary reason is operational would help clarify first-time reading. It looks like the initial assumption that there is some security problem is quite common. Best-F Francis Dupont wrote: > In your previous mail you wrote: > > I do not like (6), which goes in the opposite direction. > > => the reason is in (5) and BTW is not a security reason... > > Francis.Dupont@fdupont.fr -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - lucifred@post.harvard.edu - GnuPG 0x4A73884C -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 18:41:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26BD3A683B; Sun, 7 Jun 2009 18:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gsf2MEF6jRqp; Sun, 7 Jun 2009 18:41:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C33503A6834; Sun, 7 Jun 2009 18:41:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDTnh-000GlA-6X for namedroppers-data0@psg.com; Mon, 08 Jun 2009 01:37:25 +0000 Received: from [69.17.117.4] (helo=mail2.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDTnW-000GkZ-9g for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 01:37:19 +0000 Received: (qmail 10712 invoked from network); 8 Jun 2009 01:37:14 -0000 Received: from dsl092-066-189.bos1.dsl.speakeasy.net (HELO spaceman.local) (federico@[66.92.66.189]) (envelope-sender ) by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 8 Jun 2009 01:37:13 -0000 Message-ID: <4A2C6B48.3090205@post.harvard.edu> Date: Sun, 07 Jun 2009 21:37:12 -0400 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Francis Dupont CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated References: <200906072125.n57LP7Bf010548@givry.fdupont.fr> In-Reply-To: <200906072125.n57LP7Bf010548@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Thanks, this clarifies it for me. Best -F Francis Dupont wrote: > Paul Hoffman asked me to make this public: > > [Me] I agree there is no crypto justification (even I talked two days ago > with some cryptographers who said things have changed since the > beginning of the year) but the operational justification still > applies: IMHO it is a real problem for a compliant implementation > (which have to support the mandatory HMAC-MD5) to not be allowed > to use a certified (FIPS 140-2 for instance) crypto module for > all crypto operations... > > [Paul] Could you send this message to the whole list? I believe that > many people think there is a crypto justification, and it would be > good for them to hear this from the document's author directly. > > Regards > > Francis.Dupont@fdupont.fr > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - lucifred@post.harvard.edu - GnuPG 0x4A73884C -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 7 23:28:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37DE73A6BB1; Sun, 7 Jun 2009 23:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.324 X-Spam-Level: X-Spam-Status: No, score=-0.324 tagged_above=-999 required=5 tests=[AWL=-1.074, 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 J9kXfA4m7E2G; Sun, 7 Jun 2009 23:28:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A2FB3A6979; Sun, 7 Jun 2009 23:28:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDYFk-000KdO-Ng for namedroppers-data0@psg.com; Mon, 08 Jun 2009 06:22:40 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDYFN-000KcG-OL for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 06:22:29 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MDYFB-0004td-P0; Mon, 08 Jun 2009 08:22:05 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MDYFB-0001o5-3T; Mon, 08 Jun 2009 08:22:05 +0200 From: Florian Weimer To: David Conrad Cc: Jim Reid , Paul Vixie , Matthew Dempsky , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: TCP queries to the root servers References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> Date: Mon, 08 Jun 2009 08:22:05 +0200 In-Reply-To: (David Conrad's message of "Sun, 7 Jun 2009 14:38:07 -0700") Message-ID: <8763f7fdo2.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * David Conrad: > Given the data is relatively stable (and thus could be replicated in > an Akamai-like scheme) and the response requirements for zone transfer > aren't anything like what they are for normal TCP queries, I'm not > worried that the machines behind something like root.iana.org wouldn't > be able to handle pretty much any load thrown at them. Also, since > the data is signed, it wouldn't really matter where/how you get it... And if it's a zone transfer, you don't even leak traffic data to strangers if you get it from the wrong place. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 02:36:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F7F3A6DB8; Mon, 8 Jun 2009 02:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, 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 MY8y8Laa7AnR; Mon, 8 Jun 2009 02:36:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 13CDF3A68CD; Mon, 8 Jun 2009 02:36:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDbC5-000FcV-RK for namedroppers-data0@psg.com; Mon, 08 Jun 2009 09:31:05 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDbBs-000FYG-0U for namedroppers@psg.com; Mon, 08 Jun 2009 09:30:59 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (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 80AB9E6072; Mon, 8 Jun 2009 09:30:50 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" From: Shane Kerr To: Paul Hoffman Cc: namedroppers@psg.com In-Reply-To: References: Content-Type: text/plain Organization: ISC Date: Mon, 08 Jun 2009 11:30:47 +0200 Message-Id: <1244453447.4151.11966.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul, On Fri, 2009-06-05 at 15:56 -0700, Paul Hoffman wrote: > Therefore, I propose that the WG take on a short revision to RFC 4034 that makes the one change of making assignments into the IANA registry for DNSSEC Algorithm Types be "RFC Published". In addition, it would allow IANA to pre-assign values based on requests from an Area Director. This would allow Internet Drafts that are proposing new signature algorithms to contain valid examples of records using the proposed algorithms. This makes sense to me. -- Shane -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 02:59:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8FA03A6922; Mon, 8 Jun 2009 02:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yN6+lHQX3BWe; Mon, 8 Jun 2009 02:59:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AD80C3A68BB; Mon, 8 Jun 2009 02:59:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDbah-000IUY-81 for namedroppers-data0@psg.com; Mon, 08 Jun 2009 09:56:31 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDbaQ-000ITF-Qo for namedroppers@psg.com; Mon, 08 Jun 2009 09:56:25 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n589tCtj031479; Mon, 8 Jun 2009 09:55:14 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n589tCwt031478; Mon, 8 Jun 2009 09:55:12 GMT Date: Mon, 8 Jun 2009 09:55:12 +0000 From: bmanning@vacation.karoshi.com To: Paul Hoffman Cc: namedroppers@psg.com Subject: Re: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" Message-ID: <20090608095512.GA31450@vacation.karoshi.com.> References: 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: On Fri, Jun 05, 2009 at 03:56:25PM -0700, Paul Hoffman wrote: > Greetings again. Appendix A.1 in RFC 4034 has the initial list of algorithm types for DNSSEC. To add to that table, one needs a standards-track RFC. This means that an signature algorithm that cannot be embodied in a standards-track RFC, such as because it is not completely in English, cannot be used interoperably in DNSSEC. For example, this might prevent the GOST work the WG has taken on from being used if the eventual RFC is Informational instead of Standards Track. > > This seems unnecessarily limiting. I am not aware of any other WG that requires a standards track RFC for allocating an identifier for a cryptographic specification. *Many* cryptographic specifications are described in Informational RFCs, and this has not been a problem for anyone. > > Therefore, I propose that the WG take on a short revision to RFC 4034 that makes the one change of making assignments into the IANA registry for DNSSEC Algorithm Types be "RFC Published". In addition, it would allow IANA to pre-assign values based on requests from an Area Director. This would allow Internet Drafts that are proposing new signature algorithms to contain valid examples of records using the proposed algorithms. > > --Paul Hoffman, Director I'm pretty sure that the structure as outlined in Appendix A is fundamentally wrong. And i'm not sure I'm happy with the proposed relaxation. Historically, the IETF has been comfortable incorporating other work by reference, without the intial hurdle that the work be structured/introduced/adopted as an IETF work. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 02:59:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EF633A6922; Mon, 8 Jun 2009 02:59:30 -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 wpbu406O8Yba; Mon, 8 Jun 2009 02:59:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6288A3A68BB; Mon, 8 Jun 2009 02:59:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDbZv-000INr-Jp for namedroppers-data0@psg.com; Mon, 08 Jun 2009 09:55:43 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDbZk-000IN2-Ai for namedroppers@psg.com; Mon, 08 Jun 2009 09:55:38 +0000 Received: from [IPv6:2001:7b8:206:1:223:54ff:fe09:d688] ([IPv6:2001:7b8:206:1:223:54ff:fe09:d688]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n589tSFm033830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 11:55:29 +0200 (CEST) (envelope-from jelte@NLnetLabs.nl) Message-ID: <4A2CE010.6090901@NLnetLabs.nl> Date: Mon, 08 Jun 2009 11:55:28 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Paul Hoffman CC: namedroppers@psg.com Subject: Re: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 08 Jun 2009 11:55:29 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Hoffman wrote: > In addition, it would allow IANA to pre-assign values based on requests from an Area Director. This would allow Internet Drafts that are proposing new signature algorithms to contain valid examples of records using the proposed algorithms. > I don't disagree on the std vs inf. track change, but i'd rather see drafts use a specific algorithm identifier (i.e. 254 or 255) for their examples until the very very last moment when it is absolutely certain what numbers are assigned and that those won't change anymore. (Yes i know, this is not what I myself have done last week. Do as I say, not as I do :p) Jelte -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 04:18:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D053A6DFF; Mon, 8 Jun 2009 04:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.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_51=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 mbvs+6LPvOgd; Mon, 8 Jun 2009 04:18:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F2213A6DFA; Mon, 8 Jun 2009 04:18:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDcmZ-0000a5-4s for namedroppers-data0@psg.com; Mon, 08 Jun 2009 11:12:51 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDcmJ-0000ZJ-Pp for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 11:12: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 n58BAJtj031916; Mon, 8 Jun 2009 11:10:19 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n58BAEjO031915; Mon, 8 Jun 2009 11:10:14 GMT Date: Mon, 8 Jun 2009 11:10:14 +0000 From: bmanning@vacation.karoshi.com To: Florian Weimer Cc: David Conrad , Jim Reid , Paul Vixie , Matthew Dempsky , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: TCP queries to the root servers Message-ID: <20090608111014.GA31833@vacation.karoshi.com.> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8763f7fdo2.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 08, 2009 at 08:22:05AM +0200, Florian Weimer wrote: > * David Conrad: > > > Given the data is relatively stable (and thus could be replicated in > > an Akamai-like scheme) and the response requirements for zone transfer > > aren't anything like what they are for normal TCP queries, I'm not > > worried that the machines behind something like root.iana.org wouldn't > > be able to handle pretty much any load thrown at them. Also, since > > the data is signed, it wouldn't really matter where/how you get it... > > And if it's a zone transfer, you don't even leak traffic data to > strangers if you get it from the wrong place. er.. TCP has its own warts. I'm intriged by the implcit challange tossed by David. "... not worried that the machines behind something like root.iana.org wouldn't be able to handle pretty much any load thrown at them." - drc this harks back to Olafurs question to me that was ably answered by Paul retorts that TCP is "epic fail" as the prefered transport for DNS queries. the brief thought experiment. 10,000 QPS, each done over TCP. Thats the three-way handshake. assume the normal 5% drop of the handshake due to transient link failure and a 2 minute timeout before the host drops the halfopen TCP connect. root.iana.org will need to sustain that 10,000 TCP connects per second and keep track of the sustained 60,000 half-opens ... I'd -love- to look at that stack'o'hardware. --bill (who is going to get reamed for his swag arithmatic) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 05:26:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5803A6BCA; Mon, 8 Jun 2009 05:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6HXt42Y0aJR; Mon, 8 Jun 2009 05:26:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA7323A6B16; Mon, 8 Jun 2009 05:26:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDdre-0008S8-1I for namedroppers-data0@psg.com; Mon, 08 Jun 2009 12:22:10 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDdrS-0008R8-AT for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 12:22:03 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n58CLtRs015149 for ; Mon, 8 Jun 2009 08:21:55 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n58CLtrs015148 for namedroppers@ops.ietf.org; Mon, 8 Jun 2009 08:21:55 -0400 (EDT) (envelope-from namedroppers) Received: from [69.17.117.10] (helo=mail8.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDTcZ-000FZQ-HI for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 01:26:02 +0000 Received: (qmail 7032 invoked from network); 8 Jun 2009 01:25:52 -0000 Received: from dsl092-066-189.bos1.dsl.speakeasy.net (HELO spaceman.local) (federico@[66.92.66.189]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 8 Jun 2009 01:25:52 -0000 Message-ID: <4A2C689F.3010309@acm.org> Date: Sun, 07 Jun 2009 21:25:51 -0400 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Francis Dupont CC: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated References: <200906070841.n578fNvd006794@givry.fdupont.fr> In-Reply-To: <200906070841.n578fNvd006794@givry.fdupont.fr> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://keyserver.linux.it/pks/lookup?op=get&search=0xAEEBEC184A73884C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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. ] Understood. The other mail forwarded to the thread makes the operational rationale clear. Perhaps a pointer in the Abstract, or in section (5) that the primary reason is operational would help clarify first-time reading. It looks like the initial assumption that there is some security problem is quite common. Best-F Francis Dupont wrote: > In your previous mail you wrote: > > I do not like (6), which goes in the opposite direction. > > => the reason is in (5) and BTW is not a security reason... > > Francis.Dupont@fdupont.fr -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - flucifredi@acm.org - GnuPG 0x4A73884C -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 05:26:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4DBE3A6BA8; Mon, 8 Jun 2009 05:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIEolrDtF95H; Mon, 8 Jun 2009 05:26:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8062B3A69B7; Mon, 8 Jun 2009 05:26:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDds0-0008Ta-Du for namedroppers-data0@psg.com; Mon, 08 Jun 2009 12:22:32 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDdro-0008Sg-CE for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 12:22:26 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n58CMJRq015172 for ; Mon, 8 Jun 2009 08:22:19 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n58CMJ6M015171 for namedroppers@ops.ietf.org; Mon, 8 Jun 2009 08:22:19 -0400 (EDT) (envelope-from namedroppers) Received: from [69.17.117.8] (helo=mail6.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDTdz-000Fg8-57 for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 01:27:31 +0000 Received: (qmail 2766 invoked from network); 8 Jun 2009 01:27:22 -0000 Received: from dsl092-066-189.bos1.dsl.speakeasy.net (HELO spaceman.local) (federico@[66.92.66.189]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 8 Jun 2009 01:27:22 -0000 Message-ID: <4A2C68F9.2020705@acm.org> Date: Sun, 07 Jun 2009 21:27:21 -0400 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Francis Dupont CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated References: <200906072125.n57LP7Bf010548@givry.fdupont.fr> In-Reply-To: <200906072125.n57LP7Bf010548@givry.fdupont.fr> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://keyserver.linux.it/pks/lookup?op=get&search=0xAEEBEC184A73884C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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, this clarifies it for me. Best -F Francis Dupont wrote: > Paul Hoffman asked me to make this public: > > [Me] I agree there is no crypto justification (even I talked two days ago > with some cryptographers who said things have changed since the > beginning of the year) but the operational justification still > applies: IMHO it is a real problem for a compliant implementation > (which have to support the mandatory HMAC-MD5) to not be allowed > to use a certified (FIPS 140-2 for instance) crypto module for > all crypto operations... > > [Paul] Could you send this message to the whole list? I believe that > many people think there is a crypto justification, and it would be > good for them to hear this from the document's author directly. > > Regards > > Francis.Dupont@fdupont.fr > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - flucifredi@acm.org - GnuPG 0x4A73884C -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 05:34:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DB533A6C7D; Mon, 8 Jun 2009 05:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.282 X-Spam-Level: X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_51=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 uEfKbu80ASwx; Mon, 8 Jun 2009 05:34:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA9E33A68B5; Mon, 8 Jun 2009 05:34:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDe0f-0009XP-0x for namedroppers-data0@psg.com; Mon, 08 Jun 2009 12:31:29 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDe0O-0009WB-Sp for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 12:31:23 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (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 5EB8BE6070; Mon, 8 Jun 2009 12:31:11 +0000 (UTC) (envelope-from shane@isc.org) Subject: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers From: Shane Kerr To: bmanning@vacation.karoshi.com Cc: namedroppers@ops.ietf.org In-Reply-To: <20090608111014.GA31833@vacation.karoshi.com.> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> Content-Type: text/plain Organization: ISC Date: Mon, 08 Jun 2009 14:31:08 +0200 Message-Id: <1244464268.4151.12474.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Bill, On Mon, 2009-06-08 at 11:10 +0000, bmanning@vacation.karoshi.com wrote: > the brief thought experiment. > > 10,000 QPS, each done over TCP. Thats the three-way handshake. > assume the normal 5% drop of the handshake due to transient link > failure and a 2 minute timeout before the host drops the halfopen TCP > connect. > > root.iana.org will need to sustain that 10,000 TCP connects per second > and keep track of the sustained 60,000 half-opens ... I'd -love- > to look at that stack'o'hardware. > > --bill (who is going to get reamed for his swag arithmatic) Indeed you are. Existing web servers can handle more than twice that load today: http://www.litespeedtech.com/web-server-performance-comparison-litespeed-2.1-vs.html Heck, *Apache* can handle 10,000 queries/second on a single box. While this is probably 25% of what BIND 9 could do on a similar box, and maybe 15-20% of what NSD could do, it's not too shabby. This test was in a clean environment, so it is possible that your concerns about packet drop are a real problem, but you'd want at least 2 boxes in a cluster in any real-world setup, so unless you performance was dropped in half you'd still meet your (arbitrary) metrics. Of course, in DNS the client closes the TCP connection, which is suckful, and makes life miserable in general. I suppose it is too late to change the protocol, but if we do add a SCTP transport then this is something to consider. -- Shane -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 06:09:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A00A3A6866; Mon, 8 Jun 2009 06:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.165 X-Spam-Level: X-Spam-Status: No, score=-4.165 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_51=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 oJHaEnT8BZOs; Mon, 8 Jun 2009 06:09:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1CF143A6D4D; Mon, 8 Jun 2009 06:09:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDeX0-000Dmm-AC for namedroppers-data0@psg.com; Mon, 08 Jun 2009 13:04:54 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDeWn-000DiM-2b for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 13:04: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 n58D2Ztj032644; Mon, 8 Jun 2009 13:02:35 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n58D2ZGj032643; Mon, 8 Jun 2009 13:02:35 GMT Date: Mon, 8 Jun 2009 13:02:35 +0000 From: bmanning@vacation.karoshi.com To: Shane Kerr Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers Message-ID: <20090608130235.GB32556@vacation.karoshi.com.> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1244464268.4151.12474.camel@shane-asus-laptop> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 08, 2009 at 02:31:08PM +0200, Shane Kerr wrote: > Bill, > > On Mon, 2009-06-08 at 11:10 +0000, bmanning@vacation.karoshi.com wrote: > > the brief thought experiment. > > > > 10,000 QPS, each done over TCP. Thats the three-way handshake. > > assume the normal 5% drop of the handshake due to transient link > > failure and a 2 minute timeout before the host drops the halfopen TCP > > connect. > > > > root.iana.org will need to sustain that 10,000 TCP connects per second > > and keep track of the sustained 60,000 half-opens ... I'd -love- > > to look at that stack'o'hardware. > > > > --bill (who is going to get reamed for his swag arithmatic) > > Indeed you are. > > Existing web servers can handle more than twice that load today: > > http://www.litespeedtech.com/web-server-performance-comparison-litespeed-2.1-vs.html > > Heck, *Apache* can handle 10,000 queries/second on a single box. > > While this is probably 25% of what BIND 9 could do on a similar box, and > maybe 15-20% of what NSD could do, it's not too shabby. er... http queries over what transport Shane? http://www.litespeedtech.com/docs/webserver/config/tuning/?hilite=tcp,performance, sez: Max Connections Go to top Description: Specifies the maximum concurrent connections that the server can accept. It includes both plain TCP connections and SSL connections. It should not exceed the hard limit set by the server: 300 for Standard Edition. Once this limit is reached, the server will close Keep-Alive connections when they complete active requests. ... that 300 number sticks out like a sore thumb. just a tad shy of the swag target of 10,000 TCP setups per second adn the ongoing tracking for the 60,000 halfopen (keep-alives) projected. what am i missing here? > Of course, in DNS the client closes the TCP connection, which is > suckful, and makes life miserable in general. I suppose it is too late > to change the protocol, but if we do add a SCTP transport then this is > something to consider. > > -- > Shane -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 06:29:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B573A6866; Mon, 8 Jun 2009 06:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, 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 055SbR5JiDH5; Mon, 8 Jun 2009 06:29:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 30EDC3A6864; Mon, 8 Jun 2009 06:29:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDeq6-000G2e-Co for namedroppers-data0@psg.com; Mon, 08 Jun 2009 13:24:38 +0000 Received: from [209.85.219.207] (helo=mail-ew0-f207.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDepu-000G1m-B8 for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 13:24:32 +0000 Received: by ewy3 with SMTP id 3so137050ewy.41 for ; Mon, 08 Jun 2009 06:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=VTEDr8VAe2Aka3LgQyibDAVB5P5hy7Rr9QVE+L0KRmM=; b=MvTgCrR2X4NgRZHYmMMs3n/96nbc7pUt3fjz5qhLb187xMVHYsHoS66z2edBA/uFMn 7VU512SbJPl/DQG9ra4mPB/h3L2yoGEBgKpCwVNiMomn+7Xvfdc7oveZWsHIte7ltRdY MlG1XBgbMd9nXKEaMYgO/08mI9S83BDWYvMY8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=O6kbNw8SoWSKhZBhjIoQaTdPmyiNJwSuczHZPaygThwCe9/QCVI6egArBubpBz4lkx ES7qd5jVCNJCFm2Ael6HCl/fENoKmMfY26PUrDtyBTkSlWuL4cxW5JOMvkxzPfJbgFXT YXjuExg52BrmrGL7AWtdf0PyuJzVGslNMyfQE= MIME-Version: 1.0 Received: by 10.210.102.12 with SMTP id z12mr4367361ebb.20.1244467464131; Mon, 08 Jun 2009 06:24:24 -0700 (PDT) In-Reply-To: <20090608130235.GB32556@vacation.karoshi.com.> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> From: bert hubert Date: Mon, 8 Jun 2009 15:24:04 +0200 Message-ID: <3efd34cc0906080624p6ed49a74y45f7c2605296eeea@mail.gmail.com> Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers To: bmanning@vacation.karoshi.com Cc: Shane Kerr , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 8, 2009 at 3:02 PM, wrote: > that 300 number sticks out like a sore thumb. just a tad shy of the swag target of 10,000 > TCP setups per second adn the ongoing tracking for the 60,000 halfopen (keep-alives) projected. > > what am i missing here? The main thing that is the issue with DNS over TCP is that 1035 says you 'should' keep the connection open as a server for at least two minutes. This quickly translates into hundreds of thousands of open connections under even moderate load. FWIW, SCTP appears to exhibit this same behaviour automatically even when using the API in datagram mode (keeping the 'association' alive). It is unclear to me if SCTP indeed has a lower server-level footprint than TCP. FWIW2, PowerDNS has been closing TCP sessions after 2 seconds of idle for the past 10 years and no one has complained so far. But if you want to be up to the letter compliant, two minutes is what you 'should' do. Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 06:43:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CD9A3A6848; Mon, 8 Jun 2009 06:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.91 X-Spam-Level: * X-Spam-Status: No, score=1.91 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RCVD_IN_NJABL_PROXY=1.643, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IuO5suFPdKM; Mon, 8 Jun 2009 06:43:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB3763A6407; Mon, 8 Jun 2009 06:43:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDf41-000HsY-Eh for namedroppers-data0@psg.com; Mon, 08 Jun 2009 13:39:01 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDf3q-000HoE-0B for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 13:38:55 +0000 Received: (qmail 54926 invoked from network); 8 Jun 2009 15:11:09 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 8 Jun 2009 15:11:09 -0000 Message-ID: <4A2D144A.10802@necom830.hpcl.titech.ac.jp> Date: Mon, 08 Jun 2009 22:38:18 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Shane Kerr , namedroppers@ops.ietf.org Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> In-Reply-To: <20090608130235.GB32556@vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bmanning@vacation.karoshi.com wrote: >>> 10,000 QPS, each done over TCP. Thats the three-way handshake. >>> assume the normal 5% drop of the handshake due to transient link >>> failure and a 2 minute timeout before the host drops the halfopen TCP >>> connect. > that 300 number sticks out like a sore thumb. just a tad shy of the swag target of 10,000 > TCP setups per second adn the ongoing tracking for the 60,000 halfopen (keep-alives) projected. > what am i missing here? *ANYCAST*, of course. FYI, a server with multiple CPU chips or cores may distribute load by distributing requests over chips or cores based on hash values computed from source addresses, which is, in a sense, anycast. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 06:51:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CDFD3A69C6; Mon, 8 Jun 2009 06:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 R9G6+NEpSPh8; Mon, 8 Jun 2009 06:51:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 797D93A69BF; Mon, 8 Jun 2009 06:51:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfDF-000J8y-Gl for namedroppers-data0@psg.com; Mon, 08 Jun 2009 13:48:33 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfD3-000J7T-Br for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 13:48:28 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n58DmJno016144 for ; Mon, 8 Jun 2009 09:48:19 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n58DmJCl016143 for namedroppers@ops.ietf.org; Mon, 8 Jun 2009 09:48:19 -0400 (EDT) (envelope-from namedroppers) Received: from [209.85.219.207] (helo=mail-ew0-f207.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDenT-000FlE-6S for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 13:22:00 +0000 Received: by ewy3 with SMTP id 3so132929ewy.41 for ; Mon, 08 Jun 2009 06:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=SmXKeH0nT0ej1WGw6faoZuluy/Y1NwmU1xJDh/m77P4=; b=eZZI7sC+WooTuWP6ZcMgvu8IwDD0uV+uRWIVBfhLSjZQ5Ju7HrUJd0AdHP9ZY1r1cf Oo67KxeqHKlqerEW1zNhZdDTVJGCWQPhX1gKRvwWQ3xXSQ/CNVf3oumX3QM9Bi1TN6U/ F72XQ4Flb5CWdlAHvcK8MraPYOcA6RwZXf8Yo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=G4SCcj/2gPuUTk9yfA6wY0QJ/9WRAkePNQ1AEwsCkRZrEUa7ITLmAhPx9sbMDTGkaQ ssZiIL6ScoS5HCnR3fNx2MKXQV6taYzsqaqsy9tRrirGlfPanLC6u+YBtAnnIYyqemmE xSWRgk37FGxhBdY6KPXUD2y0OaEtBphDFHVSw= MIME-Version: 1.0 Received: by 10.211.178.8 with SMTP id f8mr1270760ebp.34.1244467313136; Mon, 08 Jun 2009 06:21:53 -0700 (PDT) In-Reply-To: <20090608130235.GB32556@vacation.karoshi.com.> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> From: bert hubert Date: Mon, 8 Jun 2009 15:21:33 +0200 X-Google-Sender-Auth: cc694a058f9099ba Message-ID: <3efd34cc0906080621r6f96333ev2686d7417ff72788@mail.gmail.com> Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers To: bmanning@vacation.karoshi.com Cc: Shane Kerr , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 8, 2009 at 3:02 PM, wrote: > that 300 number sticks out like a sore thumb. =A0just a tad shy of the sw= ag target of 10,000 > TCP setups per second adn the ongoing tracking for the 60,000 halfopen (k= eep-alives) projected. > > what am i missing here? The main thing that is the issue with DNS over TCP is that 1035 says you 'should' keep the connection open as a server for at least two minutes. This quickly translates into hundreds of thousands of open connections under even moderate load. FWIW, SCTP appears to exhibit this same behaviour automatically even when using the API in datagram mode (keeping the 'association' alive). It is unclear to me if SCTP indeed has a lower server-level footprint than TCP. FWIW2, PowerDNS has been closing TCP sessions after 2 seconds of idle for the past 10 years and no one has complained so far. But if you want to be up to the letter compliant, two minutes is what you 'should' do. Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 06:53:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0F2D3A69BF; Mon, 8 Jun 2009 06:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[AWL=-0.760, 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 wMBbXqUNMBcG; Mon, 8 Jun 2009 06:53:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD6F73A6B83; Mon, 8 Jun 2009 06:53:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfFF-000JRV-R1 for namedroppers-data0@psg.com; Mon, 08 Jun 2009 13:50:37 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfF4-000JQ2-RZ for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 13:50:32 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n58DoKi7016181; Mon, 8 Jun 2009 09:50:21 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906081350.n58DoKi7016181@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Jun 2009 09:49:58 -0400 To: Paul Hoffman , Francis Dupont From: Olafur Gudmundsson Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated Cc: namedroppers@ops.ietf.org In-Reply-To: References: <200906070911.n579AxP4006969@givry.fdupont.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 16:52 07/06/2009, Paul Hoffman wrote: >At 11:10 AM +0200 6/7/09, Francis Dupont wrote: > > In your previous mail you wrote: > > > > so it's not being deprecated, and the name of the draft is wrong, and the > > title of the draft is wrong? i'd like the word "deprecated" > stripped from > > the text in that case. if we're just relaxing the > "mandatoriness" then we > > ought to say that, to avoid confusing operators and future implementors. > > > >=> I agree the term deprecate is a bit too strong... but obsolete > >is not really better, what do you propose? > >As I said earlier, I propose that we do not move this document >forward because it is unneeded and will lead to lack of interop for >no good reason. Paul, The reason we are putting this document forward is because it takes more than a decade to flush in/out new algorithms. Thus the horizon we need to look at is 2020 not 2010. Will anyone guarantee that the use of HMAC/MD5 will not be broken by 2020? As for interoperabilty we have alternatives, we are promoting the alternatives by changing the requirement level. Unlike DNSSEC DNSKEY algorithms, TSIG is either between "consenting adults" or has a handshake (TKEY) thus a algorithm negotiation can take place. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 06:54:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16073A6B4B; Mon, 8 Jun 2009 06:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqNqYcgChRLI; Mon, 8 Jun 2009 06:54:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B2B343A6AF9; Mon, 8 Jun 2009 06:54:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfEP-000JIN-Hn for namedroppers-data0@psg.com; Mon, 08 Jun 2009 13:49:45 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfEB-000JGX-7E for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 13:49: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 1MDfFE-00059s-85; Mon, 08 Jun 2009 15:50:36 +0200 Received: from fweimer by bfk.de with local id 1MDfE4-0007rN-Kb; Mon, 08 Jun 2009 15:49:24 +0200 To: bmanning@vacation.karoshi.com Cc: Shane Kerr , namedroppers@ops.ietf.org Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> From: Florian Weimer Date: Mon, 08 Jun 2009 15:49:24 +0200 In-Reply-To: <20090608130235.GB32556@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Mon\, 8 Jun 2009 13\:02\:35 +0000") Message-ID: <82vdn6kf8b.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: > that 300 number sticks out like a sore thumb. It's probably some restricted version of the server code. > just a tad shy of the swag target of 10,000 TCP setups per second > adn the ongoing tracking for the 60,000 halfopen (keep-alives) > projected. Tens of thousands of pending connection attempts per process haven't been a problem for a while. Keeping those TCP send buffers can be a challenge, but hacks such as TransmitFile/sendfile are certainly possible. I wouldn't be surprised if there were some large systems which can serve more DNS transactions over TCP than over UDP because the UDP path has a global lock in it. TCP tends to be way more optimized than UDP (or SCTP). On the other hand, UDP is such as a low overhead that this does not matter on UP or small SMP machines. --=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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 06:58:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1FC3A6A09; Mon, 8 Jun 2009 06:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.14 X-Spam-Level: X-Spam-Status: No, score=-5.14 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_81=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 vHLOYoe8Kcv3; Mon, 8 Jun 2009 06:58:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 721D23A6848; Mon, 8 Jun 2009 06:58:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfKO-000KE8-0A for namedroppers-data0@psg.com; Mon, 08 Jun 2009 13:55:56 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfKD-000K9b-1q for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 13:55:50 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n58DrRtj000569; Mon, 8 Jun 2009 13:53:27 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n58DrRt0000568; Mon, 8 Jun 2009 13:53:27 GMT Date: Mon, 8 Jun 2009 13:53:27 +0000 From: bmanning@vacation.karoshi.com To: bert hubert Cc: bmanning@vacation.karoshi.com, Shane Kerr , namedroppers@ops.ietf.org Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers Message-ID: <20090608135327.GA547@vacation.karoshi.com.> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> <3efd34cc0906080621r6f96333ev2686d7417ff72788@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3efd34cc0906080621r6f96333ev2686d7417ff72788@mail.gmail.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 08, 2009 at 03:21:33PM +0200, bert hubert wrote: > On Mon, Jun 8, 2009 at 3:02 PM, wrote: > > that 300 number sticks out like a sore thumb. just a tad shy of the swag target of 10,000 > > TCP setups per second adn the ongoing tracking for the 60,000 halfopen (keep-alives) projected. > > > > what am i missing here? > > The main thing that is the issue with DNS over TCP is that 1035 says > you 'should' keep the connection open as a server for at least two > minutes. > > This quickly translates into hundreds of thousands of open connections > under even moderate load. i was presuming 10,000 qps w/ a 5% drop == a sustained 60,000 halfopen connections plus the other 9,500 serviced connections - per second. the 60,000 is the 5% over the 2 minute interval.... not hundreds of thousands but enough... :) > FWIW, SCTP appears to exhibit this same behaviour automatically even > when using the API in datagram mode (keeping the 'association' alive). > It is unclear to me if SCTP indeed has a lower server-level footprint > than TCP. the ns simulator seems to indicate that STCP has a somewhat higher foot print.. > FWIW2, PowerDNS has been closing TCP sessions after 2 seconds of idle > for the past 10 years and no one has complained so far. But if you > want to be up to the letter compliant, two minutes is what you > 'should' do. thats still a boatload'o'open TCP to keep track of. > Bert --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 07:04:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E76A3A6A71; Mon, 8 Jun 2009 07:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.503 X-Spam-Level: X-Spam-Status: No, score=-4.503 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdXU8lV7hzmz; Mon, 8 Jun 2009 07:04:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D5783A6ADC; Mon, 8 Jun 2009 07:04:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfPl-000L28-Pj for namedroppers-data0@psg.com; Mon, 08 Jun 2009 14:01:29 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfPQ-000L0I-Eq for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 14:01:16 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n58Dwxtj000638; Mon, 8 Jun 2009 13:58:59 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n58DwxBj000637; Mon, 8 Jun 2009 13:58:59 GMT Date: Mon, 8 Jun 2009 13:58:59 +0000 From: bmanning@vacation.karoshi.com To: Florian Weimer Cc: bmanning@vacation.karoshi.com, Shane Kerr , namedroppers@ops.ietf.org Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers Message-ID: <20090608135859.GC547@vacation.karoshi.com.> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> <82vdn6kf8b.fsf@mid.bfk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <82vdn6kf8b.fsf@mid.bfk.de> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 08, 2009 at 03:49:24PM +0200, Florian Weimer wrote: > > that 300 number sticks out like a sore thumb. > > It's probably some restricted version of the server code. yeah ... its what they call the "standard release" > > just a tad shy of the swag target of 10,000 TCP setups per second > > adn the ongoing tracking for the 60,000 halfopen (keep-alives) > > projected. > > Tens of thousands of pending connection attempts per process haven't > been a problem for a while. > > Keeping those TCP send buffers can be a challenge, but hacks such as > TransmitFile/sendfile are certainly possible. indeed - but now we step into the wonderful world of OS and stack tuning. > I wouldn't be surprised if there were some large systems which can > serve more DNS transactions over TCP than over UDP because the UDP > path has a global lock in it. TCP tends to be way more optimized than > UDP (or SCTP). On the other hand, UDP is such as a low overhead that > this does not matter on UP or small SMP machines. i would be (pleasently) surprised. > > -- > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra_e 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 07:04:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472663A6B37; Mon, 8 Jun 2009 07:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.503 X-Spam-Level: X-Spam-Status: No, score=-4.503 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Egra5zzNGPwx; Mon, 8 Jun 2009 07:04:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 714353A6ADC; Mon, 8 Jun 2009 07:04:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfPb-000L1S-Ul for namedroppers-data0@psg.com; Mon, 08 Jun 2009 14:01:19 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfPQ-000L0L-Lw for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 14:01: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 n58Ductj000616; Mon, 8 Jun 2009 13:56:38 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n58DucKV000615; Mon, 8 Jun 2009 13:56:38 GMT Date: Mon, 8 Jun 2009 13:56:38 +0000 From: bmanning@vacation.karoshi.com To: Masataka Ohta Cc: bmanning@vacation.karoshi.com, Shane Kerr , namedroppers@ops.ietf.org Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers Message-ID: <20090608135638.GB547@vacation.karoshi.com.> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> <4A2D144A.10802@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A2D144A.10802@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 08, 2009 at 10:38:18PM +0900, Masataka Ohta wrote: > bmanning@vacation.karoshi.com wrote: > > >>> 10,000 QPS, each done over TCP. Thats the three-way handshake. > >>> assume the normal 5% drop of the handshake due to transient link > >>> failure and a 2 minute timeout before the host drops the halfopen TCP > >>> connect. > > > that 300 number sticks out like a sore thumb. just a tad shy of the swag target of 10,000 > > TCP setups per second adn the ongoing tracking for the 60,000 halfopen (keep-alives) projected. > > > what am i missing here? > > *ANYCAST*, of course. > > FYI, a server with multiple CPU chips or cores may distribute load > by distributing requests over chips or cores based on hash values > computed from source addresses, which is, in a sense, anycast. > > Masataka Ohta > ok... presume 300 (per lightspeed) and my swag of ~70,000 TCP connections to track per sec. lets anycast the solution and we get... about 240 machines just to handle the current load that a single machine can do over UDP. we'll avoid doign the power/cooling cost multiple for now. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 07:06:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6195C3A6848; Mon, 8 Jun 2009 07:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.502 X-Spam-Level: X-Spam-Status: No, score=-4.502 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C9Cn3GQUQ0n; Mon, 8 Jun 2009 07:06:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 924503A6ADC; Mon, 8 Jun 2009 07:06:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfS9-000LP7-ED for namedroppers-data0@psg.com; Mon, 08 Jun 2009 14:03:57 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfRy-000LKO-Ku for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 14:03:52 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n58E2Utj000674; Mon, 8 Jun 2009 14:02:30 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n58E2UgH000673; Mon, 8 Jun 2009 14:02:30 GMT Date: Mon, 8 Jun 2009 14:02:30 +0000 From: bmanning@vacation.karoshi.com To: Olafur Gudmundsson Cc: Paul Hoffman , Francis Dupont , namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated Message-ID: <20090608140230.GA657@vacation.karoshi.com.> References: <200906070911.n579AxP4006969@givry.fdupont.fr> <200906081350.n58DoKi7016181@stora.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906081350.n58DoKi7016181@stora.ogud.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 08, 2009 at 09:49:58AM -0400, Olafur Gudmundsson wrote: > Will anyone guarantee that the use of HMAC/MD5 will not be broken by > 2020? are you a betting man? I'm sure I can get someone to take that bet. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 07:11:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6B03A6848; Mon, 8 Jun 2009 07:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 hqDOLzezYCpj; Mon, 8 Jun 2009 07:11:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A0DE3A67F4; Mon, 8 Jun 2009 07:11:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfW8-000Lz2-9g for namedroppers-data0@psg.com; Mon, 08 Jun 2009 14:08:04 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfVx-000Ly1-9w for namedroppers@psg.com; Mon, 08 Jun 2009 14:07:58 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58E7n2I003011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 07:07:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090608095512.GA31450@vacation.karoshi.com.> References: <20090608095512.GA31450@vacation.karoshi.com.> Date: Mon, 8 Jun 2009 07:07:48 -0700 To: bmanning@vacation.karoshi.com From: Paul Hoffman Subject: Re: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" Cc: namedroppers@psg.com Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 9:55 AM +0000 6/8/09, bmanning@vacation.karoshi.com wrote: > I'm pretty sure that the structure as outlined in Appendix A is fundamentally wrong. > And i'm not sure I'm happy with the proposed relaxation. Historically, the IETF > has been comfortable incorporating other work by reference, without the intial hurdle > that the work be structured/introduced/adopted as an IETF work. I think the examples of where such incorporation has happened *in standards track RFCs* are few and far between. The most common method for doing that are Informational RFCs, some of which come from WGs, some from individual submissions, some from independent submissions directly to the RFC Editor. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 07:17:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03DAE3A69D7; Mon, 8 Jun 2009 07:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6YfOPCH7Gg4; Mon, 8 Jun 2009 07:17:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 38B283A6857; Mon, 8 Jun 2009 07:17:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfc5-000Mt4-DX for namedroppers-data0@psg.com; Mon, 08 Jun 2009 14:14:13 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfbt-000MsE-4l for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 14:14:07 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id EFC6661BA56; Mon, 8 Jun 2009 07:14:00 -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 kVmaFX6JY8Zj; Mon, 8 Jun 2009 07:13:58 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 53D4461BA44; Mon, 8 Jun 2009 07:13:58 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> From: David Conrad To: bmanning@vacation.karoshi.com In-Reply-To: <20090608111014.GA31833@vacation.karoshi.com.> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Re: TCP queries to the root servers Date: Mon, 8 Jun 2009 07:13:58 -0700 References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: BIll, On Jun 8, 2009, at 4:10 AM, bmanning@vacation.karoshi.com wrote: > 10,000 QPS, each done over TCP. How frequently does the root zone need to be refreshed? Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 07:32:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D07128C12C; Mon, 8 Jun 2009 07:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQ2cu+nkCGBS; Mon, 8 Jun 2009 07:32:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CFF128C12A; Mon, 8 Jun 2009 07:32:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfpJ-000OqJ-8w for namedroppers-data0@psg.com; Mon, 08 Jun 2009 14:27:53 +0000 Received: from [65.201.175.9] (helo=cliffie.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfp2-000OmU-W7 for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 14:27:46 +0000 Received: from monsoon.verisignlabs.com (scooter.bo.labs.vrsn.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id 069A21366CB for ; Mon, 8 Jun 2009 10:27:36 -0400 (EDT) Received: from dul1mcmlarson-l1.labs.vrsn.com (dul1mcmlarson-l1.labs.vrsn.com [10.131.244.205]) by monsoon.verisignlabs.com (Postfix) with ESMTP id E7C712422EF for ; Mon, 8 Jun 2009 10:27:35 -0400 (EDT) Date: Mon, 8 Jun 2009 10:27:35 -0400 From: Matt Larson To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: TCP queries to the root servers Message-ID: <20090608142735.GC1500@dul1mcmlarson-l1.labs.vrsn.com> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.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: On Sun, 07 Jun 2009, David Conrad wrote: > Also, since the data is signed, it wouldn't really matter where/how > you get it... Please recall that the delegation NS RRSets and glue aren't signed and these compose most of the root zone's contents. So while we all know that this doesn't prevent successful validation if a child zone is signed, it does mean that the entire contents of the root zone cannot be validated even after being DNSSEC-signed. Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 07:40:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93DCA3A6932; Mon, 8 Jun 2009 07:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYAHx2HxVbyC; Mon, 8 Jun 2009 07:40:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE6A23A682B; Mon, 8 Jun 2009 07:40:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfx4-000Pwj-K1 for namedroppers-data0@psg.com; Mon, 08 Jun 2009 14:35:54 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDfwt-000Ps6-SD for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 14:35:49 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0KKX00201CAKF900@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 15:35:42 +0100 (IST) Received: from [193.1.143.69] by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTPA id <0KKX00KWJCJHWMC0@cali.ucd.ie>; Mon, 08 Jun 2009 15:35:42 +0100 (IST) Date: Mon, 08 Jun 2009 15:35:41 +0100 From: Niall O'Reilly Subject: Re: [dnsext] Re: TCP queries to the root servers In-reply-to: <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> To: David Conrad Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org, Niall.oReilly@ucd.ie Message-id: <4A2D21BD.4060700@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> User-Agent: Thunderbird 2.0.0.21 (X11/20090318) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: David Conrad wrote: > BIll, > > On Jun 8, 2009, at 4:10 AM, bmanning@vacation.karoshi.com wrote: >> 10,000 QPS, each done over TCP. > > How frequently does the root zone need to be refreshed? Currently, or in a future where new TLDs are added very frequently? Niall O'Reilly University College Dublin IT Services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 07:50:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66083A6D3C; Mon, 8 Jun 2009 07:50:28 -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 N5N1nGNjEmLV; Mon, 8 Jun 2009 07:50:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 17F443A6CB7; Mon, 8 Jun 2009 07:50:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDg7Z-0001L7-85 for namedroppers-data0@psg.com; Mon, 08 Jun 2009 14:46:45 +0000 Received: from [195.54.233.69] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDg7N-0001KD-SQ for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 14:46:39 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gromit.rfc1035.com (Postfix) with ESMTP id 2395F4B3011; Mon, 8 Jun 2009 15:46:31 +0100 (BST) Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Message-Id: <949544B7-9A1C-4669-91F2-8DA5513FB5C8@rfc1035.com> From: Jim Reid To: David Conrad In-Reply-To: <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Re: TCP queries to the root servers Date: Mon, 8 Jun 2009 15:46:30 +0100 References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 8 Jun 2009, at 15:13, David Conrad wrote: > How frequently does the root zone need to be refreshed? How many new TLDs is ICANN going to allow? If each TLD changes its delegation once a year -- a reasonable estimate -- we're already looking at a new zone file for . every day or theresabouts with the current root. If the number of TLDs go up, the frequency of updates (and root zone file versions?) will go up proportionately. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 07:52:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D2F3A6D3C; Mon, 8 Jun 2009 07:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cqA0ULVKMeR; Mon, 8 Jun 2009 07:52:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3426E3A682B; Mon, 8 Jun 2009 07:52:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgAl-0001p2-Bq for namedroppers-data0@psg.com; Mon, 08 Jun 2009 14:50:03 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgAT-0001jB-6f for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 14:49:57 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 0311461BD90; Mon, 8 Jun 2009 07:49:45 -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 M+G4I8XRUysl; Mon, 8 Jun 2009 07:49:43 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 48CAF61BD81; Mon, 8 Jun 2009 07:49:43 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: From: David Conrad To: bmanning@vacation.karoshi.com In-Reply-To: <20090608135638.GB547@vacation.karoshi.com.> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers Date: Mon, 8 Jun 2009 07:49:42 -0700 References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> <4A2D144A.10802@necom830.hpcl.titech.ac.jp> <20090608135638.GB547@vacation.karoshi.com.> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 8, 2009, at 6:56 AM, bmanning@vacation.karoshi.com wrote: > ok... presume 300 (per lightspeed) and my swag of ~70,000 TCP > connections > to track per sec. Um. This has all been quite amusing, but I don't recall anyone actually suggesting something like root.iana.org handling all DNS queries over TCP. The suggestion was that caching servers have a copy of the root zone. Paul expressed worry that if this were to occur, the zone would get out of sync. I countered by suggesting that could be addressed by slaving off a facility like root.iana.org (whether using {A,I}XFR is, of course, irrelevant). Now, with that in mind, where do you get your "swag of ~70,000 TCP connections to track per sec"? A different thought experiment: According to http://dns.measurement-factory.com/surveys/200810.html, they estimate there are 12 million authDNS servers and were able to detect 4 million open resolvers. Just for fun, lets combine (I know auth won't care, but this is a thought experiment) and round up and for the sake of argument say there are 20 million name servers that would need to fetch the zone and they will all do this via AXFR. Now, the root zone is (generally) updated twice a day. So, 20,000,000 / ( 12 * 60 * 60 ) = 462 zone transfers per second. Another point to note: the data is not particularly dynamic, thus it could be trivially replicated via existing content delivery networks. Are you worried that smart folks can't come up with an infrastructure that would support ~500 'file transfers' per second? Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 07:55:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 994D03A6ABA; Mon, 8 Jun 2009 07:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSg1eagmLEpk; Mon, 8 Jun 2009 07:55:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B7AE3A6872; Mon, 8 Jun 2009 07:55:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgCt-00027i-KE for namedroppers-data0@psg.com; Mon, 08 Jun 2009 14:52:15 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgCi-000236-Jr for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 14:52:09 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 6F8B561BDEE; Mon, 8 Jun 2009 07:52:04 -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 ll28j+NzyNq2; Mon, 8 Jun 2009 07:52:03 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 8304461BDE3; Mon, 8 Jun 2009 07:52:03 -0700 (PDT) Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Message-Id: <9F55FD20-CBB3-427A-9DEF-A409980B9EEE@virtualized.org> From: David Conrad To: Niall O'Reilly In-Reply-To: <4A2D21BD.4060700@ucd.ie> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Re: TCP queries to the root servers Date: Mon, 8 Jun 2009 07:52:03 -0700 References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <4A2D21BD.4060700@ucd.ie> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 8, 2009, at 7:35 AM, Niall O'Reilly wrote: > David Conrad wrote: >> BIll, >> On Jun 8, 2009, at 4:10 AM, bmanning@vacation.karoshi.com wrote: >>> 10,000 QPS, each done over TCP. >> How frequently does the root zone need to be refreshed? > > Currently, > or in a future where new TLDs are added very frequently? New root zone entries do not change the schedule of when a new root zone is generated. I would be surprised if this policy changed with the addition of new TLDs. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 07:56:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1E73A6872; Mon, 8 Jun 2009 07:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzD8wSmw-lNN; Mon, 8 Jun 2009 07:56:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB13D3A682B; Mon, 8 Jun 2009 07:56:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgEt-0002Pp-9V for namedroppers-data0@psg.com; Mon, 08 Jun 2009 14:54:19 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgEi-0002OT-HA for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 14:54:13 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 5890161BE45; Mon, 8 Jun 2009 07:54:08 -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 ZkfEP1YcV4Ri; Mon, 8 Jun 2009 07:54:07 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 4FFA261BE3A; Mon, 8 Jun 2009 07:54:07 -0700 (PDT) Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Message-Id: <4C8DF86E-D914-4453-AB7A-69E348538655@virtualized.org> From: David Conrad To: Jim Reid In-Reply-To: <949544B7-9A1C-4669-91F2-8DA5513FB5C8@rfc1035.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Re: TCP queries to the root servers Date: Mon, 8 Jun 2009 07:54:07 -0700 References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <949544B7-9A1C-4669-91F2-8DA5513FB5C8@rfc1035.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 8, 2009, at 7:46 AM, Jim Reid wrote: > On 8 Jun 2009, at 15:13, David Conrad wrote: >> How frequently does the root zone need to be refreshed? > How many new TLDs is ICANN going to allow? Irrelevant to the question asked. > If each TLD changes its delegation once a year -- a reasonable > estimate -- we're already looking at a new zone file for . every day > or theresabouts with the current root. Currently, the root zone gets regenerated 2 times per day regardless of whether there are any changes. I don't suspect this will change. > If the number of TLDs go up, the frequency of updates (and root > zone file versions?) will go up proportionately. Nope. It means the number of changes in the root zone per generation goes up. It doesn't change the frequency of generation. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 08:04:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1873A6DDF; Mon, 8 Jun 2009 08:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-1.650, 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 OLYDy8u1f31Q; Mon, 8 Jun 2009 08:04:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E52293A6D34; Mon, 8 Jun 2009 08:04:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgLj-0003SL-D0 for namedroppers-data0@psg.com; Mon, 08 Jun 2009 15:01:23 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgLQ-0003QK-T4; Mon, 08 Jun 2009 15:01:13 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=3tpPNstRAcQoHxadYXPCMSITTT8kNsd/xCpYDhlzE1CzGsnXAC7Dnb5J PEY/UDNxDbf5IUCR9HWOnu7VN+g1GN0Dir1HXb1amcLso7+/51KGyjZIB qrDYpDKTl90mC61; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1244473264; x=1276009264; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20TCP =20performance,=20was=20Re:=20[dnsext]=20Re:=20TCP=20quer ies=20to=20the=20root=20servers|Date:=20Mon,=208=20Jun=20 2009=2016:01:01=20+0100|Message-ID:=20 |To:=20David=20Conrad=20|Cc:=20bmann ing@vacation.karoshi.com,=0D=0A=09namedroppers@ops.ietf.o rg,=0D=0A=09owner-namedroppers@ops.ietf.org|MIME-Version: =201.0|In-Reply-To:=20|References:=20=20<47784.124423810 4@nsa.vix.com>=20<40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@vi rtualized.org>=20<60257A6B-C35B-4477-8183-01C4499C08FB@rf c1035.com>=20=20<8763f7fdo2.fsf@mid.deneb.enyo.de>=20<200906 08111014.GA31833@vacation.karoshi.com.>=20<1244464268.415 1.12474.camel@shane-asus-laptop>=20<20090608130235.GB3255 6@vacation.karoshi.com.>=20<4A2D144A.10802@necom830.hpcl. titech.ac.jp>=20<20090608135638.GB547@vacation.karoshi.co m.>=20; bh=sE+gI58tUUbZzlUKt55V9+FyWoGhJdCcJq4Xn6uiHAU=; b=TI3wfeKdBq8JjcSAr29JQfOSVztSGB3BborRxsQgdy6lkyXvv3eDBJx3 mL2rdGIXrIXYAKRZmGPPBa7eTYI/bxjbUopiRQ0aSdrRhBFhSj9ieiCsE yNKox9fzWGf/QWt; X-IronPort-AV: E=Sophos;i="4.41,325,1241391600"; d="scan'208";a="14584761" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 08 Jun 2009 16:01:03 +0100 In-Reply-To: References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> <4A2D144A.10802@necom830.hpcl.titech.ac.jp> <20090608135638.GB547@vacation.karoshi.com.> To: David Conrad Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Mon, 8 Jun 2009 16:01:01 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 08/06/2009 04:01:03 PM, Serialize complete at 08/06/2009 04:01:03 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > According to http://dns.measurement-factory.com/surveys/200810.html, > they estimate there are 12 million authDNS servers and were able to > detect 4 million open resolvers. Just for fun, lets combine (I know > auth won't care, but this is a thought experiment) and round up and > for the sake of argument say there are 20 million name servers that > would need to fetch the zone and they will all do this via AXFR. Now, > the root zone is (generally) updated twice a day. So, 20,000,000 / > ( 12 * 60 * 60 ) = 462 zone transfers per second. Another point to > note: the data is not particularly dynamic, thus it could be trivially > replicated via existing content delivery networks. AuthDNS servers don't need the root zone - indeed many argue that authoritative servers *shouldn't* have the root zone at all. Recursive DNS servers need it. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 08:05:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F12F23A6DDF; Mon, 8 Jun 2009 08:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.502 X-Spam-Level: X-Spam-Status: No, score=-4.502 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvRYz+nd6w7y; Mon, 8 Jun 2009 08:05:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27EB33A6DB4; Mon, 8 Jun 2009 08:05:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgNP-0003mN-Lw for namedroppers-data0@psg.com; Mon, 08 Jun 2009 15:03:07 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgND-0003lD-MD for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 15:03:02 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n58F1rtj001175; Mon, 8 Jun 2009 15:01:53 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n58F1rOZ001174; Mon, 8 Jun 2009 15:01:53 GMT Date: Mon, 8 Jun 2009 15:01:53 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: TCP queries to the root servers Message-ID: <20090608150153.GA975@vacation.karoshi.com.> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 08, 2009 at 07:13:58AM -0700, David Conrad wrote: > BIll, > > On Jun 8, 2009, at 4:10 AM, bmanning@vacation.karoshi.com wrote: > > 10,000 QPS, each done over TCP. > > How frequently does the root zone need to be refreshed? what do the ICANN SO's think? --bill > > Regards, > -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 08:17:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E6223A6B83; Mon, 8 Jun 2009 08:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, 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 Cq2UDxoysX89; Mon, 8 Jun 2009 08:17:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 16A3C3A6946; Mon, 8 Jun 2009 08:17:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgXk-0005GX-1b for namedroppers-data0@psg.com; Mon, 08 Jun 2009 15:13:48 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgXZ-0005Fp-0I for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 15:13:42 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (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 AEAD1E6071; Mon, 8 Jun 2009 15:13:35 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: [dnsext] Re: TCP queries to the root servers From: Shane Kerr To: David Conrad Cc: namedroppers@ops.ietf.org In-Reply-To: <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> Content-Type: text/plain Organization: ISC Date: Mon, 08 Jun 2009 17:13:31 +0200 Message-Id: <1244474011.4151.13009.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, 2009-06-08 at 07:13 -0700, David Conrad wrote: > BIll, > > On Jun 8, 2009, at 4:10 AM, bmanning@vacation.karoshi.com wrote: > > 10,000 QPS, each done over TCP. > > How frequently does the root zone need to be refreshed? I had the same question. At 10,000/second, every human on the planet can download a new personal copy weekly. -- Shane -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 08:38:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B2B3A6E0B; Mon, 8 Jun 2009 08:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.195 X-Spam-Level: X-Spam-Status: No, score=-8.195 tagged_above=-999 required=5 tests=[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 igf4tTr43PCL; Mon, 8 Jun 2009 08:38:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E54893A6DFF; Mon, 8 Jun 2009 08:38:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgqA-0007ni-Uf for namedroppers-data0@psg.com; Mon, 08 Jun 2009 15:32:50 +0000 Received: from [207.171.7.208] (helo=x8.develooper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgpw-0007lQ-0O for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 15:32:45 +0000 Received: (qmail 2383 invoked from network); 8 Jun 2009 15:32:34 -0000 Received: from gw.develooper.com (HELO embla.bn.dev) (ask@mail.dev@64.81.84.140) by smtp.develooper.com with ESMTPA; 8 Jun 2009 15:32:34 -0000 Cc: Masataka Ohta , Shane Kerr , namedroppers@ops.ietf.org Message-Id: From: =?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= To: bmanning@vacation.karoshi.com In-Reply-To: <20090608135638.GB547@vacation.karoshi.com.> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers Date: Mon, 8 Jun 2009 08:32:33 -0700 References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> <4A2D144A.10802@necom830.hpcl.titech.ac.jp> <20090608135638.GB547@vacation.karoshi.com.> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 8, 2009, at 6:56, bmanning@vacation.karoshi.com wrote: > ok... presume 300 (per lightspeed) and my swag of ~70,000 TCP > connections > to track per sec. lets anycast the solution and we get... > about 240 machines just to handle the current load that a single > machine can > do over UDP. we'll avoid doign the power/cooling cost multiple > for now. I don't know what lightspeed is, but for modern http servers (nginx, varnish, ...) 30k requests per second is well within reasonable. HAProxy which doesn't serve files but parse the requests and pass it on to another service can do more. They have a test that only sets up the tcp session and they got > 100k/sec: http://haproxy.1wt.eu/10g.html - ask -- http://develooper.com/ - http://askask.com/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 08:41:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27D33A6BB9; Mon, 8 Jun 2009 08:41:22 -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 Uzciw5l8h6kJ; Mon, 8 Jun 2009 08:41:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B4AB3A6878; Mon, 8 Jun 2009 08:41:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgvU-0008O5-Ve for namedroppers-data0@psg.com; Mon, 08 Jun 2009 15:38:20 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDgvH-0008Mc-Ga for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 15:38:15 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 223B2A4E01; Mon, 8 Jun 2009 15:38:07 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Shane Kerr cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers In-Reply-To: Your message of "Mon, 08 Jun 2009 14:31:08 +0200." <1244464268.4151.12474.camel@shane-asus-laptop> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 08 Jun 2009 15:38:07 +0000 Message-ID: <3510.1244475487@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Shane Kerr > Date: Mon, 08 Jun 2009 14:31:08 +0200 > ... > Of course, in DNS the client closes the TCP connection, which is suckful, > and makes life miserable in general. I suppose it is too late to change > the protocol, but if we do add a SCTP transport then this is something to > consider. yes, in an sctp transport, either end should be able to end an association. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 08:47:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80AC428C159; Mon, 8 Jun 2009 08:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[AWL=0.000, 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 VoUDZJPiesGv; Mon, 8 Jun 2009 08:47:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 93BBE28C151; Mon, 8 Jun 2009 08:47:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDh1R-0009Kj-Cc for namedroppers-data0@psg.com; Mon, 08 Jun 2009 15:44:29 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDh1G-0009Jy-1R for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 15:44:23 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 4B41361C259; Mon, 8 Jun 2009 08:44:17 -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 JuXiny3wsajk; Mon, 8 Jun 2009 08:44:16 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 0BD4A61C24A; Mon, 8 Jun 2009 08:44:16 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: <3F2367D3-15C4-4F6B-A403-EBA973FBDFCF@virtualized.org> From: David Conrad To: Ray.Bellis@nominet.org.uk In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers Date: Mon, 8 Jun 2009 08:44:15 -0700 References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> <4A2D144A.10802@necom830.hpcl.titech.ac.jp> <20090608135638.GB547@vacation.karoshi.com.> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ray, On Jun 8, 2009, at 8:01 AM, Ray.Bellis@nominet.org.uk wrote: > AuthDNS servers don't need the root zone - indeed many argue that > authoritative servers *shouldn't* have the root zone at all. > > Recursive DNS servers need it. I know. As I said: "Just for fun, lets combine (I know auth won't care, but this is a thought experiment) and round up ..." Alternative suggestions for more accurate numbers more than welcome. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 08:54:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF3E228C15B; Mon, 8 Jun 2009 08:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0BQARhtpfVL; Mon, 8 Jun 2009 08:54:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A3C873A6A7E; Mon, 8 Jun 2009 08:54:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDh8A-000AJB-5R for namedroppers-data0@psg.com; Mon, 08 Jun 2009 15:51:26 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDh7z-000AIQ-Bz for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 15:51:20 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 3C57061C2E6; Mon, 8 Jun 2009 08:51:15 -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 PhTJXCuXVUNa; Mon, 8 Jun 2009 08:51:14 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 027D761C2DA; Mon, 8 Jun 2009 08:51:13 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: <63F031A5-44DE-4110-A700-66F441DCCA06@virtualized.org> From: David Conrad To: bmanning@vacation.karoshi.com In-Reply-To: <20090608150153.GA975@vacation.karoshi.com.> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Re: TCP queries to the root servers Date: Mon, 8 Jun 2009 08:51:13 -0700 References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <20090608150153.GA975@vacation.karoshi.com.> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 8, 2009, at 8:01 AM, bmanning@vacation.karoshi.com wrote: > On Mon, Jun 08, 2009 at 07:13:58AM -0700, David Conrad wrote: >> BIll, >> On Jun 8, 2009, at 4:10 AM, bmanning@vacation.karoshi.com wrote: >>> 10,000 QPS, each done over TCP. >> How frequently does the root zone need to be refreshed? > what do the ICANN SO's think? My guess is that they don't, at least about something like that. As far as I'm aware, folks are happy with 2 x day. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 09:04:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECDB628C0E7; Mon, 8 Jun 2009 09:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07YJ5zArcEMT; Mon, 8 Jun 2009 09:04:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 901A03A6DDF; Mon, 8 Jun 2009 09:04:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDhHX-000Bdj-UR for namedroppers-data0@psg.com; Mon, 08 Jun 2009 16:01:07 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDhHJ-000BcV-Ho for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 16:01:02 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n58Fxqtj001562; Mon, 8 Jun 2009 15:59:52 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n58FxqwW001561; Mon, 8 Jun 2009 15:59:52 GMT Date: Mon, 8 Jun 2009 15:59:52 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers Message-ID: <20090608155952.GB975@vacation.karoshi.com.> References: <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> <4A2D144A.10802@necom830.hpcl.titech.ac.jp> <20090608135638.GB547@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: On Mon, Jun 08, 2009 at 07:49:42AM -0700, David Conrad wrote: > On Jun 8, 2009, at 6:56 AM, bmanning@vacation.karoshi.com wrote: > > ok... presume 300 (per lightspeed) and my swag of ~70,000 TCP > >connections > > to track per sec. > > Um. This has all been quite amusing, but I don't recall anyone > actually suggesting something like root.iana.org handling all DNS > queries over TCP. sorry, I suspect that I mis-read the following email: Cc: Paul Vixie , Matthew Dempsky , namedroppers@ops.ietf.org From: David Conrad To: Jim Reid In-Reply-To: <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> Subject: [dnsext] Re: TCP queries to the root servers Date: Sun, 7 Jun 2009 14:38:07 -0700 X-Mailer: Apple Mail (2.935.3) Precedence: bulk List-ID: >>On 6 Jun 2009, at 00:48, David Conrad wrote: > Jim Reid wrote: >>say, root.iana.org... >How many TCP queries can this set of masters handle? :-) "...I'm not worried that the machines behind something like root.iana.org wouldn't be able to handle pretty much any load thrown at them." Regards, -drc ----------------------------------------------- > > The suggestion was that caching servers have a copy of the root zone. > Paul expressed worry that if this were to occur, the zone would get > out of sync. I countered by suggesting that could be addressed by > slaving off a facility like root.iana.org (whether using {A,I}XFR is, > of course, irrelevant). > > Now, with that in mind, where do you get your "swag of ~70,000 TCP > connections to track per sec"? 10,000 qps over UDP is the rough number reported by the four RSOs I've talked with this week. empirical evidence points to about 5% of the TCP attempts are left "half-open" - likely due to transport churn. RFC 1034 says the TCP timeout to close those half-open connections is two minutes. so... moving the 10,000 qps to TCP, with 5% being left open -every second- will give me, after the first two minutes, a sustained "load" of 60,000 half-open TCP connections to manage ... and every second, I pick up another 500 and close 500. leaving about 9,500 active TCP sessions per second to manage in addition to those other 60,000. so to a first approximation, to do -todays- load over TCP, you'll need to handle about 70,000 TCP sessions per second. was that helpful? > > A different thought experiment: > > According to http://dns.measurement-factory.com/surveys/200810.html, > they estimate there are 12 million authDNS servers and were able to > detect 4 million open resolvers. Just for fun, lets combine (I know > auth won't care, but this is a thought experiment) and round up and > for the sake of argument say there are 20 million name servers that > would need to fetch the zone and they will all do this via AXFR. Now, > the root zone is (generally) updated twice a day. So, 20,000,000 / > ( 12 * 60 * 60 ) = 462 zone transfers per second. Another point to > note: the data is not particularly dynamic, thus it could be trivially > replicated via existing content delivery networks. ah... we see that you have stayed with the "AXFR" track, while Jim, myself, and others, have trotted down the track of move all DNS queries to TCP, not just AXFRs. > Are you worried that smart folks can't come up with an infrastructure > that would support ~500 'file transfers' per second? no, not worried abt that, even dumb folks like me can do that. > > Regards, > -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 09:13:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331AF28C102; Mon, 8 Jun 2009 09:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyomhO4HgDlK; Mon, 8 Jun 2009 09:13:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4721B3A6DFF; Mon, 8 Jun 2009 09:13:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDhPY-000CoU-O0 for namedroppers-data0@psg.com; Mon, 08 Jun 2009 16:09:24 +0000 Received: from [69.17.117.4] (helo=mail2.sea5.speakeasy.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDhPN-000CnZ-Oj for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 16:09:19 +0000 Received: (qmail 13608 invoked from network); 8 Jun 2009 16:09:13 -0000 Received: from dsl092-066-189.bos1.dsl.speakeasy.net (HELO spaceman.local) (federico@[66.92.66.189]) (envelope-sender ) by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 8 Jun 2009 16:09:13 -0000 Message-ID: <4A2D37A7.7030608@post.harvard.edu> Date: Mon, 08 Jun 2009 12:09:11 -0400 From: Federico Lucifredi User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Olafur Gudmundsson CC: Paul Hoffman , Francis Dupont , namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated References: <200906070911.n579AxP4006969@givry.fdupont.fr> <200906081350.n58DoKi7016181@stora.ogud.com> In-Reply-To: <200906081350.n58DoKi7016181@stora.ogud.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Olafur Gudmundsson wrote: [...] > Paul, > The reason we are putting this document forward is because it takes more > than a decade to flush in/out new algorithms. > Thus the horizon we need to look at is 2020 not 2010. > Will anyone guarantee that the use of HMAC/MD5 will not be broken by > 2020? > >From one side, breaking a Keyed Hash is harder than finding collisions, so that may be a more open statement than it sounds. On the other side, betting on a crypto algorithm to remain inviolate for a full solar cycle may be rather gutsy. The reality is that we cannot guarantee any cryptographic algorithm will remain inviolate, much less for an "endecade". So, I remain satisfied with the operational assertion - provided it is made clearer to readers, as many come in assuming some of MD5's vulnerabilities got it demoted, not its phaseout from libraries (which, of course, indirectly comes from its vulnerabilities, but not one affecting HMAC). Otherwise, it may easily look to a reader as if the IETF is practicing "security through obscurity" here: we understand MD5 more, and even tho keyed hashing is not broken, we understand SHA-256 less, so we feel more comfy with it. Not a label I wish to attach :) Best -F -- _________________________________________ -- "'Problem' is a bleak word for challenge" - Richard Fish (Federico L. Lucifredi) - lucifred@post.harvard.edu - GnuPG 0x4A73884C -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 09:16:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1852728C13E; Mon, 8 Jun 2009 09:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBzE4csq1mXy; Mon, 8 Jun 2009 09:16:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 671DF28C139; Mon, 8 Jun 2009 09:16:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDhTU-000DOc-Cd for namedroppers-data0@psg.com; Mon, 08 Jun 2009 16:13:28 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDhTD-000DMw-FD for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 16:13:22 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 12EA361C538; Mon, 8 Jun 2009 09:13:11 -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 4L7P15FXFKWa; Mon, 8 Jun 2009 09:13:05 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 1F4A461C52A; Mon, 8 Jun 2009 09:13:05 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: <2C27064F-54E7-42C0-B904-ABF414E0F08C@virtualized.org> From: David Conrad To: bmanning@vacation.karoshi.com In-Reply-To: <20090608155952.GB975@vacation.karoshi.com.> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers Date: Mon, 8 Jun 2009 09:13:04 -0700 References: <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> <4A2D144A.10802@necom830.hpcl.titech.ac.jp> <20090608135638.GB547@vacation.karoshi.com.> <20090608155952.GB975@vacation.karoshi.com.> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 8, 2009, at 8:59 AM, bmanning@vacation.karoshi.com wrote: >> Um. This has all been quite amusing, but I don't recall anyone >> actually suggesting something like root.iana.org handling all DNS >> queries over TCP. > > sorry, I suspect that I mis-read the following email: My apologies -- I suspect my use of the term 'queries' led to the confusion. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 09:27:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611F03A68E5; Mon, 8 Jun 2009 09:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.351 X-Spam-Level: X-Spam-Status: No, score=-4.351 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fACygM7+LqH3; Mon, 8 Jun 2009 09:27:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A81A13A68ED; Mon, 8 Jun 2009 09:27:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDhbl-000EhF-6R for namedroppers-data0@psg.com; Mon, 08 Jun 2009 16:22:01 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDhbZ-000EbX-P6 for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 16:21:55 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n58GFatj001679; Mon, 8 Jun 2009 16:15:36 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n58GFaOT001678; Mon, 8 Jun 2009 16:15:36 GMT Date: Mon, 8 Jun 2009 16:15:36 +0000 From: bmanning@vacation.karoshi.com To: Ask =?iso-8859-1?Q?Bj=F8rn?= Hansen Cc: bmanning@vacation.karoshi.com, Masataka Ohta , Shane Kerr , namedroppers@ops.ietf.org Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers Message-ID: <20090608161536.GD975@vacation.karoshi.com.> References: <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> <4A2D144A.10802@necom830.hpcl.titech.ac.jp> <20090608135638.GB547@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 08, 2009 at 08:32:33AM -0700, Ask Bjxrn Hansen wrote: > > On Jun 8, 2009, at 6:56, bmanning@vacation.karoshi.com wrote: > > > ok... presume 300 (per lightspeed) and my swag of ~70,000 TCP > >connections > > to track per sec. lets anycast the solution and we get... > > about 240 machines just to handle the current load that a single > >machine can > > do over UDP. we'll avoid doign the power/cooling cost multiple > >for now. > > I don't know what lightspeed is, but for modern http servers (nginx, > varnish, ...) 30k requests per second is well within reasonable. lightspeed wa a site quoted by Shane and then me. I have no idea who they are either. > HAProxy which doesn't serve files but parse the requests and pass it > on to another service can do more. They have a test that only sets > up the tcp session and they got > 100k/sec: http://haproxy.1wt.eu/10g.html nifty thing.. using specialized HW(nics), tuned kernels, and even then, the test methodology claims: "...The request generator continuously connects to HAProxy to fetch the selected object from the server in loops for 1 minute, with 500 to 1000 concurrent connections." er... thats 1000 per minute or 17 concurrent TCP connections per second. buzt. lets try again. I don't care about raw data throughput, i care about the number of concurrent TCP connections. --bill > > > - ask > > -- > http://develooper.com/ - http://askask.com/ > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 10:02:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40A873A68B8; Mon, 8 Jun 2009 10:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysfnjhacOE+J; Mon, 8 Jun 2009 10:02:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C2223A6B51; Mon, 8 Jun 2009 10:02:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDiAN-000Jrl-Og for namedroppers-data0@psg.com; Mon, 08 Jun 2009 16:57:47 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDiA0-000JqN-Hq for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 16:57:29 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id EF079A4E27; Mon, 8 Jun 2009 16:57:23 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Olafur Gudmundsson cc: Paul Hoffman , Francis Dupont , namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated In-Reply-To: Your message of "Mon, 08 Jun 2009 09:49:58 -0400." <200906081350.n58DoKi7016181@stora.ogud.com> References: <200906070911.n579AxP4006969@givry.fdupont.fr> <200906081350.n58DoKi7016181@stora.ogud.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 08 Jun 2009 16:57:23 +0000 Message-ID: <6647.1244480243@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Mon, 08 Jun 2009 09:49:58 -0400 > From: Olafur Gudmundsson > > Paul, > > The reason we are putting this document forward is because it takes more > than a decade to flush in/out new algorithms. Thus the horizon we need > to look at is 2020 not 2010. Will anyone guarantee that the use of > HMAC/MD5 will not be broken by 2020? i don't think there's anyone around who will guarantee the use of any crypto in that time frame. (we're going to have quantum computers at some point.) until there is a known reason to "deprecate" all we can legitly do is "relax". > As for interoperabilty we have alternatives, we are promoting the > alternatives by changing the requirement level. Unlike DNSSEC DNSKEY > algorithms, TSIG is either between "consenting adults" or has a handshake > (TKEY) thus a algorithm negotiation can take place. i'm fine with promoting the alternatives. but not with deprecating something that is not broken. let's just relax the requirement for HMAC-MD5 so that operators, and future implementors, have the guideance they need. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 10:04:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7033A697B; Mon, 8 Jun 2009 10:04:16 -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 RnNw9egTDs1G; Mon, 8 Jun 2009 10:04:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 552033A687B; Mon, 8 Jun 2009 10:04:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDiE0-000KKO-8K for namedroppers-data0@psg.com; Mon, 08 Jun 2009 17:01: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.69 (FreeBSD)) (envelope-from ) id 1MDiDo-000KGQ-Ry for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 17:01:26 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 84E51A4E29 for ; Mon, 8 Jun 2009 17:01:20 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: TCP queries to the root servers In-Reply-To: Your message of "Mon, 08 Jun 2009 17:13:31 +0200." <1244474011.4151.13009.camel@shane-asus-laptop> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 08 Jun 2009 17:01:20 +0000 Message-ID: <6923.1244480480@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: why are we talking about this in the exclusive context of the root zone? the underlying protocol problems are shared by every authority zone, and unless we're planning to mirror every authority zone in every recursive server, we need to keep the protocol working without such mirroring. re: > Subject: Re: [dnsext] Re: TCP queries to the root servers > From: Shane Kerr > To: David Conrad > Cc: namedroppers@ops.ietf.org > Organization: ISC > Date: Mon, 08 Jun 2009 17:13:31 +0200 > X-Mailer: Evolution 2.26.1 > Sender: owner-namedroppers@ops.ietf.org > > On Mon, 2009-06-08 at 07:13 -0700, David Conrad wrote: > > BIll, > > > > On Jun 8, 2009, at 4:10 AM, bmanning@vacation.karoshi.com wrote: > > > 10,000 QPS, each done over TCP. > > > > How frequently does the root zone need to be refreshed? > > I had the same question. At 10,000/second, every human on the planet can > download a new personal copy weekly. > > -- > Shane > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 10:29:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388B43A68C9; Mon, 8 Jun 2009 10:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.195 X-Spam-Level: X-Spam-Status: No, score=-8.195 tagged_above=-999 required=5 tests=[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 G3e4H2lrfNER; Mon, 8 Jun 2009 10:29:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 176B83A68BF; Mon, 8 Jun 2009 10:29:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDiaz-000NmY-J1 for namedroppers-data0@psg.com; Mon, 08 Jun 2009 17:25:17 +0000 Received: from [207.171.7.208] (helo=x8.develooper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDiam-000Nkt-PJ for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 17:25:12 +0000 Received: (qmail 15928 invoked from network); 8 Jun 2009 17:25:03 -0000 Received: from gw.develooper.com (HELO embla.bn.dev) (ask@mail.dev@64.81.84.140) by smtp.develooper.com with ESMTPA; 8 Jun 2009 17:25:03 -0000 Cc: Masataka Ohta , Shane Kerr , namedroppers@ops.ietf.org Message-Id: <768E396D-A107-4B15-BDFC-5673443ECD7B@develooper.com> From: =?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= To: bmanning@vacation.karoshi.com In-Reply-To: <20090608161536.GD975@vacation.karoshi.com.> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers Date: Mon, 8 Jun 2009 10:25:03 -0700 References: <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> <4A2D144A.10802@necom830.hpcl.titech.ac.jp> <20090608135638.GB547@vacation.karoshi.com.> <20090608161536.GD975@vacation.karoshi.com.> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 8, 2009, at 9:15, bmanning@vacation.karoshi.com wrote: > "...The request generator continuously connects to HAProxy to fetch > the selected object from the server in loops for 1 minute, with > 500 to 1000 concurrent connections." > > er... thats 1000 per minute or 17 concurrent TCP connections per > second. > buzt. lets try again. No, that's not what it says -- but we're getting way off-topic. All I wanted to point out is that the state of the art of TCP based servers (for HTTP) supports request rates high enough to the vast majority of DNS servers. Keep using anycast[1] and the numbers really aren't that crazy. - ask [1] http://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 10:46:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2DA03A69D7; Mon, 8 Jun 2009 10:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik0E-+r4Ld2b; Mon, 8 Jun 2009 10:46:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF7013A68BF; Mon, 8 Jun 2009 10:46:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDirv-0000BZ-VU for namedroppers-data0@psg.com; Mon, 08 Jun 2009 17:42:47 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDirg-0000Ag-PJ for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 17:42:38 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 6722DA4E37; Mon, 8 Jun 2009 17:42:32 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: David Conrad cc: Niall O'Reilly , bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: TCP queries to the root servers In-Reply-To: Your message of "Mon, 08 Jun 2009 07:52:03 MST." <9F55FD20-CBB3-427A-9DEF-A409980B9EEE@virtualized.org> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <4A2D21BD.4060700@ucd.ie> <9F55FD20-CBB3-427A-9DEF-A409980B9EEE@virtualized.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 08 Jun 2009 17:42:32 +0000 Message-ID: <8700.1244482952@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: David Conrad > Date: Mon, 8 Jun 2009 07:52:03 -0700 > > New root zone entries do not change the schedule of when a new root zone > is generated. I would be surprised if this policy changed with the > addition of new TLDs. under some proposals we'd see millions of top level names, and in that case i'd expect the rate of urgent NS or DS changes to be several-times-daily. so it would not surprise me if the policy had to change in that case. in the more likely case of a few dozen new top level names per year, i agree that the root zone publication schedule would not have to change at all. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 10:51:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 852753A6DD9; Mon, 8 Jun 2009 10:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.242 X-Spam-Level: X-Spam-Status: No, score=-5.242 tagged_above=-999 required=5 tests=[AWL=-0.194, 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 NSmnPGapH4T7; Mon, 8 Jun 2009 10:51:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 754913A6DCA; Mon, 8 Jun 2009 10:51:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDixT-00014q-Vt for namedroppers-data0@psg.com; Mon, 08 Jun 2009 17:48:31 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDixH-00013f-Gr for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 17:48:25 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n58HmE8S012167; Mon, 8 Jun 2009 10:48:14 -0700 (PDT) Message-Id: From: Nicholas Weaver To: " namedroppers@ops.ietf.org" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] The ICSI Netalyzr Date: Mon, 8 Jun 2009 10:48:14 -0700 Cc: Nicholas Weaver X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The public beta of the ICSI Netalyzr is now live at http://netalyzr.icsi.berkeley.edu This Java applet is designed to allow users to probe and discover various properties about their network connection. The many tests include latency, bandwidth, and buffer size measurements. Other, more subtle tests detect port filtering and hidden proxies, the correct operation of in-network HTTP caches, and the general health and behavior of the DNS resolver. In particular, the DNS tests are probably of interest to the working group. This includes probes for glue policy, EDNS and DNSSEC support, timing, lookups of important names, whether the system can make direct DNS requests, and whether fragmented large DNS replies are correctly processed. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 11:02:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693BD3A6C5F; Mon, 8 Jun 2009 11:02:49 -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=-0.720, 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 OaJfrDCg1XUH; Mon, 8 Jun 2009 11:02:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 897DC3A67F8; Mon, 8 Jun 2009 11:02:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDj6w-0002bk-EH for namedroppers-data0@psg.com; Mon, 08 Jun 2009 17:58:18 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDj6l-0002av-G9 for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 17:58:12 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n58Hw3rI019078; Mon, 8 Jun 2009 13:58:03 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906081758.n58Hw3rI019078@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Jun 2009 13:57:54 -0400 To: Ray.Bellis@nominet.org.uk From: Olafur Gudmundsson Subject: Re: [dnsext] Draft DNSEXT charter Cc: namedroppers@ops.ietf.org In-Reply-To: References: <200905291557.n4TFv4ek030806@stora.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 14:13 29/05/2009, Ray.Bellis@nominet.org.uk wrote: > > Attached is our first draft of an updated charter that allows us > > to add the items pending adoption. (GOST DNSSEC algorithms, Forgery > > Resilience) > > > > Instead of having to re charter every time a new draft is deemed worthy >of > > the working groups effort we have created narrow categories > > that allow us to perform "protocol maintenance" as needed. > > > > Milestones are preliminary and will be updated based on WG discussion. > > > > Comments please, > >I would like to see the charter allow for work items that advise on >correct _implementation_ (as opposed to _operation_) of the DNS protocols, >such as my DNS Proxy BCP draft. > >I'm unable to find a suitable place to drop this into the current text, >though. > >Ray Next version will contain in list of topics new documents can have: Hardening DNS protocol and providing guidance to implementors Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 11:11:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF2263A6A90; Mon, 8 Jun 2009 11:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 uLh7aGWSvDON; Mon, 8 Jun 2009 11:10:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1CA813A67F8; Mon, 8 Jun 2009 11:10:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDjFa-0004FD-Gr for namedroppers-data0@psg.com; Mon, 08 Jun 2009 18:07: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.69 (FreeBSD)) (envelope-from ) id 1MDjFO-0004EZ-Lr for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 18:07:08 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 55416A4E32 for ; Mon, 8 Jun 2009 18:07:02 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers In-Reply-To: Your message of "Mon, 08 Jun 2009 15:49:24 +0200." <82vdn6kf8b.fsf@mid.bfk.de> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> <82vdn6kf8b.fsf@mid.bfk.de> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 08 Jun 2009 18:07:02 +0000 Message-ID: <9639.1244484422@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: i'm limiting this reply to just the issues related to tcp/53. i've already asked, several times, that we not treat the root zone as special, so we must be prepared to do anything for COM and CO.UK that we would do to fix problems we see in accessing the root zone. (which rules out mirroring in my view.) > From: Florian Weimer > Date: Mon, 08 Jun 2009 15:49:24 +0200 > > Tens of thousands of pending connection attempts per process haven't > been a problem for a while. > > Keeping those TCP send buffers can be a challenge, but hacks such as > TransmitFile/sendfile are certainly possible. whatever number of simultaneous open tcp sockets you allow, even if millions, can be exceeded due to attacks, failures, or flash crowds. if the target initiated close after every response then i could imagine being able to manage the state load, but as soon as one allows any kind of timeout window, whether 30 seconds as in RFC 1035 or 2 seconds as in powerdns, then you're painting a target on your back. for SCTP i'd recommend that associations be left open and that it be explicitly recommended and expected that responses be reordered. that way an initiator could dump all kinds of queries into the queue and the target could answer them in any order; this would avoid any perceived need to open several associations in parallel. (i am guessing that TCP/53 initiators open sessions in parallel in this case and/or expect/demand responses to be in request order though the RFC's say otherwise, and that responders will generally respond in request order. an implementation survey should probably be done to find out.) > I wouldn't be surprised if there were some large systems which can serve > more DNS transactions over TCP than over UDP because the UDP path has a > global lock in it. TCP tends to be way more optimized than UDP (or > SCTP). On the other hand, UDP is such as a low overhead that this does > not matter on UP or small SMP machines. the state load of half-open connections is manageable due to syn flood concerns first expressed a decade or more ago. but the pool of fully open connections is a fat target, even if one does not follow RFC 1035's recommendation for server side connection management. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 11:24:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02003A67F8; Mon, 8 Jun 2009 11:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.179 X-Spam-Level: X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[AWL=-0.684, 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 Q2xVAi6LSHKS; Mon, 8 Jun 2009 11:24:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DDEE53A6E02; Mon, 8 Jun 2009 11:24:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDjSE-0006HR-F5 for namedroppers-data0@psg.com; Mon, 08 Jun 2009 18:20:18 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDjS2-0006G4-S6 for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 18:20:12 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n58IK0lw019311; Mon, 8 Jun 2009 14:20:01 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906081820.n58IK0lw019311@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Jun 2009 14:15:30 -0400 To: Paul Vixie From: Olafur Gudmundsson Subject: Re: [dnsext] Draft DNSEXT charter Cc: namedroppers@ops.ietf.org In-Reply-To: <74782.1243718697@nsa.vix.com> References: <200905291557.n4TFv4ek030806@stora.ogud.com> <74782.1243718697@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 17:24 30/05/2009, Paul Vixie wrote: > > Date: Fri, 29 May 2009 11:56:59 -0400 > > From: =D3lafur Gu=F0mundsson /DNSEXT > > chair > > > > Milestones are preliminary and will be updated based on WG discussion. > > > > Comments please, > > ... > > Milestones: > > Jun 2009 TSIG/MD5 Obsoleting to IESG. > > Jul 2009 AXFR Clarify to IESG > > Sep 2009 EDNS0 Ping Option advanced to IESG > > Oct 2009 Resolver side Forgery Resilience advanced to IESG > > Oct 2009 DNSSEC Errata document to IESG > > Nov 2009 GOST DNSKEY and DS support advanced to IESG > > Dec 2009 ENDS0-bis update advanced to IESG > >IMHO, EDNS0 Ping would not add any actual security. can this be changed to >say something like "Sep 2009 - forgery resilience protocol advanced to= IESG" >so that we're open to defining an SCTP transport profile, and we're open to >defining an TKEY-DH + TSIG use profile, and still hit the objective? > >btw, i'm looking for co-authors for an DNS over SCTP transport profile doc, >and a TKEY-DH + TSIG use profile doc. i'll want to get both done in the >first three weeks of july (before blackhat/defcon). help? First on the EDNS0 Ping option: we have enough=20 people supporting that undertaking to adopt the document, at the same time number of people arguing strongly against the document. The chairs feeling is we=20 should have a round of discussion once the document is updated to reflect comments received, then dispose of= it. On Transport issues: last week the dns-proxy=20 document was discussed by the IESG, one of the main issues raised was on various transport related wording in= the document. There seems to be a need to specify how DNS implementations use= the two transports available to them. In addition there seems to be interest in examining and specifying how to= use an additional transport protocol. The next version of the charter will contain these work items and milestones for two documents. The chairs are looking for=20 editors for "DNS transport clarify" document. Uses of TKEY/TSIG can to prevent spoofing can fall under "hardening DNS"= clause in our charter. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 11:28:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE13E3A6801; Mon, 8 Jun 2009 11:28:37 -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 i9XwyJRGZylu; Mon, 8 Jun 2009 11:28:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD0903A68D2; Mon, 8 Jun 2009 11:28:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDjXS-00075u-6G for namedroppers-data0@psg.com; Mon, 08 Jun 2009 18:25:42 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDjXF-00074N-E6 for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 18:25:35 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58IP2HD015166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 11:25:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200906081350.n58DoKi7016181@stora.ogud.com> References: <200906070911.n579AxP4006969@givry.fdupont.fr> <200906081350.n58DoKi7016181@stora.ogud.com> Date: Mon, 8 Jun 2009 11:24:59 -0700 To: Olafur Gudmundsson From: Paul Hoffman Subject: Re: [dnsext] WGLC TSIG MD5 Deprecated Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 9:49 AM -0400 6/8/09, Olafur Gudmundsson wrote: >The reason we are putting this document forward is because it takes more >than a decade to flush in/out new algorithms. I do not see the word "flush" in the current document. We are currently discussing what the document is trying to say, and you are the first to propose that. >Thus the horizon we need to look at is 2020 not 2010. Fully disagree. We need to look at the horizon of "when are vulnerabilites that affect the protocol seen". >Will anyone guarantee that the use of HMAC/MD5 will not be broken by >2020? That's an interesting question. Given the current crypto literature, if HMAC-MD5 is broken in 2020, so will HMAC-SHA1 and HMAC-SHA256. I doubt that you are suggesting that we expand the current document to remove all HMACs from use in the DNS. >As for interoperabilty we have alternatives, we are promoting the >alternatives by changing the requirement level. Unlike DNSSEC DNSKEY >algorithms, TSIG is either between "consenting adults" or has a >handshake (TKEY) thus a algorithm negotiation can take place. Exactly right. So, there is no use to deprecating the algorithms until there is a known problem. At that time, all pairs of DNS folks can decide whether or not they still want to use MD5 or HMAC-MD5. We should probably change the protocol requirements at that time. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 11:31:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36AE23A6A00; Mon, 8 Jun 2009 11:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[AWL=-0.651, 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 5zwp4kVQ7MEZ; Mon, 8 Jun 2009 11:31:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 027843A69DD; Mon, 8 Jun 2009 11:31:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDjaX-0007iQ-7W for namedroppers-data0@psg.com; Mon, 08 Jun 2009 18:28:53 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDjaL-0007cF-BJ for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 18:28:47 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n58ISdRI019464 for ; Mon, 8 Jun 2009 14:28:39 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906081828.n58ISdRI019464@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Jun 2009 14:28:30 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Draft Charter v2. Re: [dnsext] Draft DNSEXT charter In-Reply-To: <200905291557.n4TFv4ek030806@stora.ogud.com> References: <200905291557.n4TFv4ek030806@stora.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 13:03 29/05/2009, =D3lafur Gu=F0mundsson /DNSEXT wrote: >Dear colleagues, > >Attached is our first draft of an updated charter that allows us >to add the items pending adoption. (GOST DNSSEC algorithms, Forgery >Resilience) Here is an updated version based on feedback from the working group. Diffs from prior version below. Olafur and Andrew The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT WG group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols "on the wire" or the internal processing of DNS data. DNS operations are out of scope for the WG. The WG will limit itself to review of proposals for new extensions and clarification to the DNS protocol, including DNSSEC. Adoption of new work targeted for standards track will require changes to this charter. The working group can nevertheless undertake work in following subjects without a charter change: DNSSEC and TSIG/TKEY algorithm maintenance Hardening DNS protocol and providing guidance to implementors Examining transport protocols possibly adding new ones. Advancing existing Proposed Standard RFCs to Draft/Full Standard Obsoleting RFCs. Before formal adoption of any such items at least 5 working group participants must publicly state that the item is within charter and is worthwhile item for further study. The DNSEXT WG will conduct the specified RFC5395 review of RR templates as they are posted, and EDNS0 Option templates if EDNS0-bis updates registration requirements. The WG does not intend to hold face to face meetings, though may do so if deemed necessary for resolution of a specific issue at hand. Milestones: Jun 2009 TSIG/MD5 Obsoleting to IESG. Jul 2009 RSA/SHA256 to IESG. Jul 2009 AXFR Clarify to IESG. Sep 2009 EDNS0 Ping Option advanced to IESG Oct 2009 Resolver side Forgery Resilience advanced to IESG Oct 2009 DNSSEC Errata document to IESG Nov 2009 GOST DNSKEY and DS support advanced to IESG Dec 2009 EDNS0-bis update advanced to IESG Feb 2010 DNS existing transport protocol=20 recommendations/clarifications to IESG Jun 2010 DNS transport protocol specification ---------- diffs------------- --- charter-20090527.txt 2009-05-29 11:56:40.839081600 -0400 +++ charter-20090608.txt 2009-06-08 14:24:11.974524800 -0400 @@ -1,4 +1,4 @@ - + The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT WG group will actively advance DNS @@ -15,17 +15,18 @@ The working group can nevertheless undertake work in following subjects without a charter change: - DNSSEC and TSIG/TKEY algorithm maintenance, - Hardening DNS protocol against forgery attempts, - Advancing existing Proposed standard RFC's to Draft/Full standard - Obsoleting RFC's. + DNSSEC and TSIG/TKEY algorithm maintenance + Hardening DNS protocol and providing guidance to implementors + Examining transport protocols possibly adding new ones. + Advancing existing Proposed Standard RFCs to Draft/Full Standard + Obsoleting RFCs. Before formal adoption of any such items at least 5 working group -participants must publicly state that the items is within charter and is +participants must publicly state that the item is within charter and is worthwhile item for further study. The DNSEXT WG will conduct the specified RFC5395 review of RR -templates as they are posted, and ENDS0 Option templates if ENDS0-bis +templates as they are posted, and EDNS0 Option templates if EDNS0-bis updates registration requirements. The WG does not intend to hold face to face meetings, though @@ -35,11 +36,13 @@ Milestones: Jun 2009 TSIG/MD5 Obsoleting to IESG. -Jul 2009 AXFR Clarify to IESG +Jul 2009 RSA/SHA256 to IESG. +Jul 2009 AXFR Clarify to IESG. Sep 2009 EDNS0 Ping Option advanced to IESG Oct 2009 Resolver side Forgery Resilience advanced to IESG Oct 2009 DNSSEC Errata document to IESG Nov 2009 GOST DNSKEY and DS support advanced to IESG -Dec 2009 ENDS0-bis update advanced to IESG - +Dec 2009 EDNS0-bis update advanced to IESG +Feb 2010 DNS existing transport protocol=20 recommendations/clarifications to IESG +Jun 2010 DNS transport protocol specification -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 14:35:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80CD93A67E7; Mon, 8 Jun 2009 14:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWuXge3f6WEk; Mon, 8 Jun 2009 14:35:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5F54C3A682D; Mon, 8 Jun 2009 14:35:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDmPR-0008tl-6g for namedroppers-data0@psg.com; Mon, 08 Jun 2009 21:29:37 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDmPE-0008sv-RY for namedroppers@ops.ietf.org; Mon, 08 Jun 2009 21:29:30 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 3DD9B61D988; Mon, 8 Jun 2009 14:29:24 -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 EvAUaqxsiFaK; Mon, 8 Jun 2009 14:29:23 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id F175261D97D; Mon, 8 Jun 2009 14:29:22 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: From: David Conrad To: Paul Vixie In-Reply-To: <6923.1244480480@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Re: TCP queries to the root servers Date: Mon, 8 Jun 2009 14:29:20 -0700 References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul, On Jun 8, 2009, at 10:01 AM, Paul Vixie wrote: > why are we talking about this in the exclusive context of the root > zone? Because the root of the DNS is special (quantitatively if not qualitatively)? > the underlying protocol problems are shared by every authority zone, > and > unless we're planning to mirror every authority zone in every > recursive > server, we need to keep the protocol working without such mirroring. Everybody cares about the root. If you screw up the root zone, it has a bit more impact than if you screw up (say) dv.isc.org. If the authority for dv.isc.org is DDoS'd out of existence, it has a bit less impact than if the root were DDoS'd, etc. I'm told a number of larger ISPs already mirror the root zone. All I'm suggesting is to make this easier/more formalized for folks who want to do it. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 15:51:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74533A6980; Mon, 8 Jun 2009 15:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 ErelJ3Ei5dGt; Mon, 8 Jun 2009 15:51:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A67E73A69D4; Mon, 8 Jun 2009 15:51:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDnc2-000JaQ-5M for namedroppers-data0@psg.com; Mon, 08 Jun 2009 22:46:42 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDnbq-000JZr-CS for namedroppers@psg.com; Mon, 08 Jun 2009 22:46:35 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58MkR4c027306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 15:46:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 8 Jun 2009 15:46:26 -0700 To: Samuel Weiler From: Paul Hoffman Subject: Re: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" Cc: namedroppers@psg.com Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 6:00 PM -0400 6/8/09, Samuel Weiler wrote: >On Fri, 5 Jun 2009, Paul Hoffman wrote: > >>This means that an signature algorithm that cannot be embodied in a standards-track RFC, ... not completely in English, cannot be used interoperably in DNSSEC. > >RFC4034 and its ancestors reserved two values (253 and 254) for "private" algorithms and specified ways to use multiple private algorithms without bad interactions. While I doubt the code to do that is well-tested, presumably the code to use GOST in DNSSEC isn't well-tested, either. Perhaps both could be debugged together. I'm having a hard time parsing your statement. It sounds like "if GOST cannot be on standards track, people who want to use GOST can only identify it as 253 or 254". I certainly hope I am misinterpreting you... >>This seems unnecessarily limiting. I am not aware of any other WG that requires a standards track RFC for allocating an identifier for a cryptographic specification. *Many* cryptographic specifications are described in Informational RFCs, and this has not been a problem for anyone. > >Some registries are Standards Action precisely because of the cost shifted to implementors when registrations are unchecked. As an example, see the URI registry, RFC4395. And that particular registry doesn't suffer from the eight-bit limit that we face here. That's a bad analogy. I was an (unfortunately active) part of that decision, and the reason we made those labels require standards action is precisely because they were labels, not limited to a numberspace. There was competition for easily-identified URI scheme names ('tv', 'channel', and so on). No one competes for yet-another-number. >Furthermore, this WG has been eating (slowly) into that eight-bit space for signaling the use of a Standards Track DNSSEC option and, given how well that signaling mechanism works, might do so again. The expired draft-ietf-dnsext-dnssec-trans-06 discusses the decision from the first time this was done. I categorically reject the notion that there could be more than a hundred new signature mechanisms introduced in the next few decades. If we ever get beyond 150 (!), we will have plenty of time to come up with another scheme for sub-defining new algorithms. Data point: even in crypto protocols where the signature algorithm identifiers are handed out like candy, there are fewer than 50 to date, and that includes many that have already been discarded. Can you show any evidence that we could possibly use four times that many, given that we would have a much higher bar (RFC required)? We might want to take the "how many RFC-required signature algorithms" discussion to SAAG; they would have a better idea than the DNSSEC WG. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 17:32:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C998028C176; Mon, 8 Jun 2009 17:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 btP5eNy56YSG; Mon, 8 Jun 2009 17:32:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8356028C171; Mon, 8 Jun 2009 17:32:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDpBO-0008D7-DI for namedroppers-data0@psg.com; Tue, 09 Jun 2009 00:27:18 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDpBB-0008Bj-GM for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 00:27:11 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 7D576E6071; Tue, 9 Jun 2009 00:27:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n590Qxuv064919; Tue, 9 Jun 2009 10:27:00 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906090027.n590Qxuv064919@drugs.dv.isc.org> To: Florian Weimer Cc: Mark Andrews , David Conrad , Olafur Gudmundsson , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 In-reply-to: Your message of "Fri, 05 Jun 2009 12:01:32 +0200." <824ouvvw1v.fsf@mid.bfk.de> Date: Tue, 09 Jun 2009 10:26:59 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <824ouvvw1v.fsf@mid.bfk.de>, Florian Weimer writes: > * Mark Andrews: > > > Do all the root server fragment packets so that the smallest > > fragment contains the initial segment so that the probability > > of out of order fragement is reduced? This helps firewalls > > and NAT's that only process fragmented responses correctly > > when the initial fragment arrives first. > > Last time I checked, the roots (except one) did not perform PMTUD, so > fragmentation is not under their control. Many DNS servers send the > final fragment first anyway. This is not very likely to change. I beg to differ. 8 of the roots are performing PMTU discovery over IPv4/UDP. Whether the operators are aware of this or not is another matter. This can usually be disabled at the the application layer. 09:57:54.387361 198.41.0.4.53 > 211.30.172.21.64982: 24664*- 1/13/11 SOA (497) (DF) 09:58:19.419990 192.228.79.201.53 > 211.30.172.21.54074: 11917*- 1/13/13 SOA (493) (DF) 09:58:56.196852 192.112.36.4.53 > 211.30.172.21.63951: 55465*- 1/13/13 SOA (493) (DF) 09:59:17.432535 128.63.2.53.53 > 211.30.172.21.51513: 47857*- 1/13/13 SOA (493) (DF) 09:59:30.359185 192.36.148.17.53 > 211.30.172.21.60259: 52319*- 1/13/11 SOA (497) (DF) 09:59:42.443443 192.58.128.30.53 > 211.30.172.21.54445: 20147*- 1/13/11 SOA (497) (DF) 10:00:33.782430 193.0.14.129.53 > 211.30.172.21.61326: 48813*- 1/13/13 SOA (493) (DF) 10:00:47.262075 199.7.83.42.53 > 211.30.172.21.51447: 37089*- 1/13/13 SOA (493) (DF) Also the root servers will almost certainly do the initial fragmentation of the DNS responses, whether it is IPv4 or IPv6. 99.9% of the time no further fragmentation will occur. How the roots choose to fragement is important to minimising problems caused by misimplementations in other network elements. How the roots choose to fragment also dictates the probability of additional fragmentation occuring. > Anyway, I doubt you'll find serious stateful packet filters which do > not reassemble all packets traversing the device (and fragment again, > if needed). Stateless filters are a different story, of course, but > to them, the order of fragments doesn't matter, either. I'm aware of PNAT's which fail to handle fragmented responses where the initial fragement doesn't arrive first. > To be honest, I have serious doubts if it makes sense to worry about > this. Chances are that DNS traffic moves to IPv6 faster than we can > reach consensus. 8-/ The issues are applicable to IPv6 as they are to IPv4. IPv6 has the advantage of a API to control fragmention in the sender. > --=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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 20:12:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457373A69C6; Mon, 8 Jun 2009 20:12:12 -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 of4CGy-BfhNr; Mon, 8 Jun 2009 20:12:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 689FA3A63CB; Mon, 8 Jun 2009 20:12:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDrey-0004XZ-S8 for namedroppers-data0@psg.com; Tue, 09 Jun 2009 03:06:00 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDrel-0004Rb-Ra for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 03:05:54 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id F0797E602F; Tue, 9 Jun 2009 03:05:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5935KJh068497; Tue, 9 Jun 2009 13:05:35 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906090305.n5935KJh068497@drugs.dv.isc.org> To: Paul Hoffman Cc: Andrew Sullivan , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-rsasha256-14.txt In-reply-to: Your message of "Fri, 05 Jun 2009 08:30:04 MST." Date: Tue, 09 Jun 2009 13:05:20 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: A DNSSSEC validator needs to understand both NSEC and NSEC3 for positive answers as well and negative answers, see wildard answers. A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate negative answers in the form of both NSEC and NSEC3 with hash algorithm 1, as defined in [RFC5155]. An authoritative server that does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 with NSEC denial of existence. A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate denial of existance proofs in both NSEC and NSEC3 (with hash algorithm 1, as defined in [RFC5155]) forms. An authoritative server that does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 with NSEC denial of existence. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 8 20:15:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E4493A69C6; Mon, 8 Jun 2009 20:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 cWZCjzlv-UbU; Mon, 8 Jun 2009 20:15:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9FC9E3A682E; Mon, 8 Jun 2009 20:15:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDrki-0005O2-RD for namedroppers-data0@psg.com; Tue, 09 Jun 2009 03:11:56 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDrkX-0005I2-UF for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 03:11:51 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 9626CA4EEA; Tue, 9 Jun 2009 03:11:45 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: David Conrad cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: TCP queries to the root servers In-Reply-To: Your message of "Mon, 08 Jun 2009 14:29:20 MST." References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 09 Jun 2009 03:11:45 +0000 Message-ID: <31786.1244517105@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: David Conrad > Date: Mon, 8 Jun 2009 14:29:20 -0700 > > I'm told a number of larger ISPs already mirror the root zone. All I'm > suggesting is to make this easier/more formalized for folks who want to > do it. i'm told a number of the ISP's who mirror the root zone also amend it. i will become more comfortable with this after the real one has been signed so that such amendments can be filtered out. in my hotel in beijing last week, all traffic toward any root name server address was answered inside chinanet by chinanet's own servers. not a comfortable environment in which to consider wide scale root zone mirroring. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 04:35:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9953A6B42; Tue, 9 Jun 2009 04:35:42 -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 E3c16+EGGSJr; Tue, 9 Jun 2009 04:35:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4ED7D3A6A6F; Tue, 9 Jun 2009 04:35:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDzWa-000O4U-Ch for namedroppers-data0@psg.com; Tue, 09 Jun 2009 11:29:52 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDzWH-000NvV-00 for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 11:29:38 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n59BTGq0028175 for ; Tue, 9 Jun 2009 07:29:16 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n59BTGmj028174 for namedroppers@ops.ietf.org; Tue, 9 Jun 2009 07:29:16 -0400 (EDT) (envelope-from namedroppers) Received: from [65.122.17.41] (helo=fledge.watson.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDpBy-0008Lf-KM for namedroppers@psg.com; Tue, 09 Jun 2009 00:28:00 +0000 Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n590Rrhp073526; Mon, 8 Jun 2009 20:27:53 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n590RqN4073522; Mon, 8 Jun 2009 20:27:53 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 8 Jun 2009 20:27:52 -0400 (EDT) From: Samuel Weiler To: Paul Hoffman cc: namedroppers@psg.com Subject: Re: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Tue, 09 Jun 2009 01:27:53 +0100 (BST) X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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 Mon, 8 Jun 2009, Paul Hoffman wrote: >> RFC4034 and its ancestors reserved two values (253 and 254) for >> "private" algorithms and specified ways to use multiple private >> algorithms without bad interactions. While I doubt the code to do >> that is well-tested, presumably the code to use GOST in DNSSEC >> isn't well-tested, either. Perhaps both could be debugged >> together. > > I'm having a hard time parsing your statement. It sounds like "if > GOST cannot be on standards track, people who want to use GOST can > only identify it as 253 or 254". I certainly hope I am > misinterpreting you... RFC4034 section A.1.1 describes how the private algorithm types work, which includes embedding longer algorithm identifiers in the DNSKEY and RRSIG data. So one might say "if an algorithm does not have a unique algorithm number assigned, its use can be identified by the algorithm number 253 and the unique domain name X". -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 04:35:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471FB3A6B42; Tue, 9 Jun 2009 04:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmggNqM+G0iv; Tue, 9 Jun 2009 04:35:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 682DC3A6781; Tue, 9 Jun 2009 04:35:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDzX5-000O89-L8 for namedroppers-data0@psg.com; Tue, 09 Jun 2009 11:30:23 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDzWi-000Ny8-J7 for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 11:30:16 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n59BThS8028187 for ; Tue, 9 Jun 2009 07:29:43 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n59BTh2B028186 for namedroppers@ops.ietf.org; Tue, 9 Jun 2009 07:29:43 -0400 (EDT) (envelope-from namedroppers) Received: from [209.85.219.207] (helo=mail-ew0-f207.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDw3p-000GSU-A0 for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 07:48:02 +0000 Received: by ewy3 with SMTP id 3so990099ewy.41 for ; Tue, 09 Jun 2009 00:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=5P4XPPzhi1zEsUt1+lJMqkph5+d9Yo29jawYiXPyEt4=; b=NVDXKyTnbLsVPvOwcZu7Lko184PmfX1KpD66OZk3Dl3Bb9JJXarxpBVLbd5mJTNStL DWyzoSp+3Kzg3714u7qcKwXSbIzT848gF2YdSVS5OQ2SdyVA+gbJAXXLHJES4mSihPMC M8Nnrlw4paLG5/ZtydWyNiaR2r6qlP06Mv+a0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=TDnw6FBJkBs4uOHo5KOOXD5tA0aGzs9rUVHckQ0NhH7oUuNTL2YYtLG7PaFoxIj5+d DHvWSM6Wd1BdA2iyvBWY/95LSROR4EmnACE7TEMtcDd4VhFB25+rDBdOxkTntdedvHdK ee3K2jDl8Db7gl0F5tvcKSXZJD/FsponxuZno= MIME-Version: 1.0 Received: by 10.210.29.9 with SMTP id c9mr1838021ebc.44.1244533674074; Tue, 09 Jun 2009 00:47:54 -0700 (PDT) In-Reply-To: <31786.1244517105@nsa.vix.com> References: <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> From: bert hubert Date: Tue, 9 Jun 2009 09:47:34 +0200 X-Google-Sender-Auth: d025fd16b33c0722 Message-ID: <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> Subject: Re: [dnsext] Re: TCP queries to the root servers To: Paul Vixie Cc: David Conrad , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On Tue, Jun 9, 2009 at 5:11 AM, Paul Vixie wrote: > in my hotel in beijing last week, all traffic toward any root name server > address was answered inside chinanet by chinanet's own servers. =A0not a > comfortable environment in which to consider wide scale root zone mirrori= ng. With a hostile service provider, all bets are off. The best thing one can do in that case is make sure you don't get *any* answers. So it does not make a lot of sense to ponder this situation for protocol design, or even operational guidelines. Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 04:38:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A4628C184; Tue, 9 Jun 2009 04:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8iLjmz7yKjO; Tue, 9 Jun 2009 04:38:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E8D9D3A6E2C; Tue, 9 Jun 2009 04:38:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDzW6-000Nvt-Cp for namedroppers-data0@psg.com; Tue, 09 Jun 2009 11:29:22 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDzVu-000Nph-GS for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 11:29:16 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n59BSrEv028164 for ; Tue, 9 Jun 2009 07:28:53 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n59BSrD1028163 for namedroppers@ops.ietf.org; Tue, 9 Jun 2009 07:28:53 -0400 (EDT) (envelope-from namedroppers) Received: from [65.122.17.41] (helo=fledge.watson.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MDmth-000DMC-2w for namedroppers@psg.com; Mon, 08 Jun 2009 22:00:58 +0000 Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n58M0pqa044395; Mon, 8 Jun 2009 18:00:51 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n58M0oGQ044391; Mon, 8 Jun 2009 18:00:51 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 8 Jun 2009 18:00:50 -0400 (EDT) From: Samuel Weiler To: Paul Hoffman cc: namedroppers@psg.com Subject: Re: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Mon, 08 Jun 2009 23:00:51 +0100 (BST) X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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 Fri, 5 Jun 2009, Paul Hoffman wrote: > This means that an signature algorithm that cannot be embodied in a > standards-track RFC, ... not completely in English, cannot be used > interoperably in DNSSEC. RFC4034 and its ancestors reserved two values (253 and 254) for "private" algorithms and specified ways to use multiple private algorithms without bad interactions. While I doubt the code to do that is well-tested, presumably the code to use GOST in DNSSEC isn't well-tested, either. Perhaps both could be debugged together. > This seems unnecessarily limiting. I am not aware of any other WG > that requires a standards track RFC for allocating an identifier for > a cryptographic specification. *Many* cryptographic specifications > are described in Informational RFCs, and this has not been a problem > for anyone. Some registries are Standards Action precisely because of the cost shifted to implementors when registrations are unchecked. As an example, see the URI registry, RFC4395. And that particular registry doesn't suffer from the eight-bit limit that we face here. Furthermore, this WG has been eating (slowly) into that eight-bit space for signaling the use of a Standards Track DNSSEC option and, given how well that signaling mechanism works, might do so again. The expired draft-ietf-dnsext-dnssec-trans-06 discusses the decision from the first time this was done. > Therefore, I propose that the WG take on a short revision to RFC > 4034 that makes the one change of making assignments into the IANA > registry for DNSSEC Algorithm Types be "RFC Published". Given the limited code point space and the availability of alternatives (the private algorithm option), I oppose such a change. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 08:18:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F73D28C188; Tue, 9 Jun 2009 08:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[AWL=-1.222, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sl8tHSeULoWq; Tue, 9 Jun 2009 08:18:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 59F1028C167; Tue, 9 Jun 2009 08:18:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME2zc-00092v-LL for namedroppers-data0@psg.com; Tue, 09 Jun 2009 15:12:05 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME2zQ-0008vH-RO for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 15:11:58 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 215222FE965D; Tue, 9 Jun 2009 15:11:33 +0000 (UTC) Date: Tue, 9 Jun 2009 11:11:31 -0400 From: Andrew Sullivan To: Mark Andrews Cc: Paul Hoffman , namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-rsasha256-14.txt Message-ID: <20090609151129.GB25651@shinkuro.com> References: <200906090305.n5935KJh068497@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200906090305.n5935KJh068497@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Your message doesn't provide enough context. I _think_ what you mean is this: On Tue, Jun 09, 2009 at 01:05:20PM +1000, Mark Andrews wrote: > A DNSSSEC validator needs to understand both NSEC and NSEC3 for > positive answers as well and negative answers, see wildard answers. That is a background remark. > A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate > negative answers in the form of both NSEC and NSEC3 with hash > algorithm 1, as defined in [RFC5155]. An authoritative server that > does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 > with NSEC denial of existence. That is a context paragraph taken directly from §5.2 of the -14 draft. > A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate > denial of existance proofs in both NSEC and NSEC3 (with hash algorithm > 1, as defined in [RFC5155]) forms. An authoritative server that > does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 > with NSEC denial of existence. That is additional text you want added at the end of §5.2. Right? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 08:20:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946763A6ACB; Tue, 9 Jun 2009 08:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=-0.622, 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 dIRpTHSyKLks; Tue, 9 Jun 2009 08:20:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4E313A68E0; Tue, 9 Jun 2009 08:20:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME34Y-0009sZ-21 for namedroppers-data0@psg.com; Tue, 09 Jun 2009 15:17:10 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME34J-0009kq-7n for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 15:17:04 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n59FGWmU030205; Tue, 9 Jun 2009 11:16:34 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906091516.n59FGWmU030205@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Jun 2009 10:49:49 -0400 To: Paul Vixie , David Conrad From: Olafur Gudmundsson Subject: Re: [dnsext] Re: TCP queries to the root servers Cc: namedroppers@ops.ietf.org In-Reply-To: <31786.1244517105@nsa.vix.com> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 23:11 08/06/2009, Paul Vixie wrote: > > From: David Conrad > > Date: Mon, 8 Jun 2009 14:29:20 -0700 > > > > I'm told a number of larger ISPs already mirror the root zone. All I'm > > suggesting is to make this easier/more formalized for folks who want to > > do it. > >i'm told a number of the ISP's who mirror the root zone also amend it. i >will become more comfortable with this after the real one has been signed >so that such amendments can be filtered out. > >in my hotel in beijing last week, all traffic toward any root name server >address was answered inside chinanet by chinanet's own servers. not a >comfortable environment in which to consider wide scale root zone mirroring. I take this as an endorsement that the root zone be signed using NSEC to make any such changes transparent. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 08:20:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67C9E3A68F8; Tue, 9 Jun 2009 08:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 lvoWHgv-IP6i; Tue, 9 Jun 2009 08:20:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 791223A68E0; Tue, 9 Jun 2009 08:20:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME35R-000A1q-7i for namedroppers-data0@psg.com; Tue, 09 Jun 2009 15:18:05 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME353-0009uV-IF for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 15:17:59 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0B0D8A4FD7 for ; Tue, 9 Jun 2009 15:17:41 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: TCP queries to the root servers In-Reply-To: Your message of "Tue, 09 Jun 2009 09:47:34 +0200." <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> References: <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 09 Jun 2009 15:17:41 +0000 Message-ID: <60184.1244560661@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: bert hubert > Date: Tue, 9 Jun 2009 09:47:34 +0200 > > With a hostile service provider, all bets are off. The best thing one > can do in that case is make sure you don't get *any* answers. So it > does not make a lot of sense to ponder this situation for protocol > design, or even operational guidelines. of course. however, making local root name service universal, is going to engender a lot more opportunistic hostility along these lines. since there's no operational problem being solved by it, and since the failure modes include "becoming out of date" in a dozen ways, and since there is almost nothing one can say the root zone needs that many 2LD's and some 3LD's also need, this whole thread is "twilight zone" territory. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 09:13:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6503A687A; Tue, 9 Jun 2009 09:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.199 X-Spam-Level: X-Spam-Status: No, score=-104.199 tagged_above=-999 required=5 tests=[AWL=2.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGy0oIwzcsmh; Tue, 9 Jun 2009 09:13:01 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id C59993A6923; Tue, 9 Jun 2009 09:13:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME3t8-000IfK-2M for namedroppers-data0@psg.com; Tue, 09 Jun 2009 16:09:26 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME3sx-000Ido-AE for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 16:09:20 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CA8F32FE965D for ; Tue, 9 Jun 2009 16:08:56 +0000 (UTC) Date: Tue, 9 Jun 2009 12:08:54 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: TCP queries to the root servers Message-ID: <20090609160854.GC25651@shinkuro.com> References: <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60184.1244560661@nsa.vix.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: No hat. On Tue, Jun 09, 2009 at 03:17:41PM +0000, Paul Vixie wrote: > to engender a lot more opportunistic hostility along these lines. since > there's no operational problem being solved by it, and since the failure > modes include "becoming out of date" in a dozen ways, and since there > is almost nothing one can say the root zone needs that many 2LD's and > some 3LD's also need I have to agree with Paul that the discussion of distributing the root zone widely doesn't seem to be solving the basic problems that we started the thread with. As near as I can tell, the start of this topic was that things would be better if we switched to TCP, which was immediately rejected as entailing too much state on the authority servers. That argument led us to the possibility of mirroring the root zone more widely. Since, as Paul points out, the problem is at least as bad for the authority servers for large TLDs as it is for the root, we have either established that the solution doesn't fit the problem, or else that we need to distribute many zones so widely. In the absence of a proposal to ensure such wide mirroring that is not subject to all of the problems that the HOSTS file had, I think we can conclude that the proposal is not an answer to the problem of TCP state on authority servers. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 09:13:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6EBB3A687A; Tue, 9 Jun 2009 09:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCLSkw+ohkiw; Tue, 9 Jun 2009 09:13:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E43503A69D1; Tue, 9 Jun 2009 09:13:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME3sS-000IYf-GG for namedroppers-data0@psg.com; Tue, 09 Jun 2009 16:08:44 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME3sH-000IWL-Kx for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 16:08:39 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 7220B620831; Tue, 9 Jun 2009 09:08:33 -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 Bg1LC2mofH7K; Tue, 9 Jun 2009 09:08:32 -0700 (PDT) Received: from wlan39-215.mdr.icann.org (wlan39-215.mdr.icann.org [192.0.39.215]) by virtualized.org (Postfix) with ESMTP id CBC65620820; Tue, 9 Jun 2009 09:08:31 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: From: David Conrad To: Paul Vixie In-Reply-To: <60184.1244560661@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: RFC 3226 violations (was Re: [dnsext] Re: TCP queries to the root servers) Date: Tue, 9 Jun 2009 09:08:31 -0700 References: <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 9, 2009, at 8:17 AM, Paul Vixie wrote: > this whole thread is "twilight zone" territory. I agree, but for different reasons that I won't bother going into. Back to the original point/question that started this thread: Certain name servers are setting DO=1 but advertising a buffer size of less than 1220 as part of a heuristic to try to get around broken firewalls/NATs/etc. handling of EDNS0. My reading of RFC 3226 would indicate this is a violation of the RFC. The implication of this particular violation is that it is highly likely the root servers will see increased TCP fallback as name servers will set TC on the DNSSEC-related RR filled response immediately after the root is signed. I believe there are two options to deal with this: 1) fix the name server implementations so they do not violate RFC 3226 by not advertising a buffer less than 1220 when DO=1 2) revise RFC 3226 to remove/revise the buffer size restriction. Does anyone other than Mark Andrews think we should choose option 2? Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 10:03:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B300D3A6C55; Tue, 9 Jun 2009 10:03:04 -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 oFUIlXlp8HeJ; Tue, 9 Jun 2009 10:03:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B89FF3A6C2D; Tue, 9 Jun 2009 10:03:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME4eH-0001Au-93 for namedroppers-data0@psg.com; Tue, 09 Jun 2009 16:58:09 +0000 Received: from [195.54.233.69] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME4dK-0000so-9H for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 16:57:35 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gromit.rfc1035.com (Postfix) with ESMTP id 3FD9A4B6BB4; Tue, 9 Jun 2009 17:56:54 +0100 (BST) Cc: Paul Vixie , namedroppers@ops.ietf.org Message-Id: From: Jim Reid To: David Conrad In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] Re: RFC 3226 violations Date: Tue, 9 Jun 2009 17:56:53 +0100 References: <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 9 Jun 2009, at 17:08, David Conrad wrote: > Certain name servers are setting DO=1 but advertising a buffer size > of less than 1220 as part of a heuristic to try to get around broken > firewalls/NATs/etc. handling of EDNS0. My reading of RFC 3226 would > indicate this is a violation of the RFC. > > The implication of this particular violation is that it is highly > likely the root servers will see increased TCP fallback as name > servers will set TC on the DNSSEC-related RR filled response > immediately after the root is signed. I believe there are two > options to deal with this: > > 1) fix the name server implementations so they do not violate RFC > 3226 by not advertising a buffer less than 1220 when DO=1 > > 2) revise RFC 3226 to remove/revise the buffer size restriction. > > Does anyone other than Mark Andrews think we should choose option 2? I vote for both. Sort of. 3226 needs to be updated anyway because it talks about legacy stuff like RFC2525 compliant servers and resolvers. And A6 records. Though if 3226 does get revisited, I see no reason to change what it says about the minimum buffer size. Maybe if 2761bis is revived this would be a better home for defining appropriate minimum buffer sizes when the DO bit is set? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 10:23:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DACBD3A69AE; Tue, 9 Jun 2009 10:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 ap34N+WhABs5; Tue, 9 Jun 2009 10:23:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E9D5D3A6BA4; Tue, 9 Jun 2009 10:23:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME4xx-0004nk-8L for namedroppers-data0@psg.com; Tue, 09 Jun 2009 17:18:29 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME4xm-0004mv-95 for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 17:18:23 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id DEDC2A500D; Tue, 9 Jun 2009 17:18:17 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: David Conrad cc: namedroppers@ops.ietf.org Subject: Re: RFC 3226 violations (was Re: [dnsext] Re: TCP queries to the root servers) In-Reply-To: Your message of "Tue, 09 Jun 2009 09:08:31 MST." References: <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 09 Jun 2009 17:18:17 +0000 Message-ID: <65223.1244567897@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: David Conrad > Date: Tue, 9 Jun 2009 09:08:31 -0700 > > Certain name servers are setting DO=1 but advertising a buffer size of > less than 1220 as part of a heuristic to try to get around broken > firewalls/NATs/etc. handling of EDNS0. My reading of RFC 3226 would > indicate this is a violation of the RFC. my reading gives the same result. > The implication of this particular violation is that it is highly likely > the root servers will see increased TCP fallback as name servers will set > TC on the DNSSEC-related RR filled response immediately after the root is > signed. I believe there are two options to deal with this: > > 1) fix the name server implementations so they do not violate RFC 3226 by > not advertising a buffer less than 1220 when DO=1 > > 2) revise RFC 3226 to remove/revise the buffer size restriction. > > Does anyone other than Mark Andrews think we should choose option 2? not i. however, if we're going to choose option 2, then i'll suggest an additional action, which is an RFC stating that DO=1 should be ignored if the buffer size is less than 1220. in fact, RFC 3226 can be read that way. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 10:37:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575CC28C1A3; Tue, 9 Jun 2009 10:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.544 X-Spam-Level: X-Spam-Status: No, score=-105.544 tagged_above=-999 required=5 tests=[AWL=1.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BhTV6GvRYK6; Tue, 9 Jun 2009 10:37:21 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9B27528C10D; Tue, 9 Jun 2009 10:37:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME5Cu-0007em-GI for namedroppers-data0@psg.com; Tue, 09 Jun 2009 17:33:56 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME5Ci-0007Zo-Vc for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 17:33:51 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n59HVbtj010378; Tue, 9 Jun 2009 17:31:37 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n59HVbJH010377; Tue, 9 Jun 2009 17:31:37 GMT Date: Tue, 9 Jun 2009 17:31:37 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: RFC 3226 violations (was Re: [dnsext] Re: TCP queries to the root servers) Message-ID: <20090609173137.GA10312@vacation.karoshi.com.> References: <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jun 09, 2009 at 09:08:31AM -0700, David Conrad wrote: > Back to the original point/question that started this thread: > > 1) fix the name server implementations so they do not violate RFC 3226 > by not advertising a buffer less than 1220 when DO=1 > > 2) revise RFC 3226 to remove/revise the buffer size restriction. > > Does anyone other than Mark Andrews think we should choose option 2? > > Regards, > -drc so the choice is: pick 1, and trigger hardware/firmware upgrades near the edges of the Internet and residual, persistent edge failure in the DNS for decades to come. pick 2, and kowtow to shortsighted hardware/firmware vendors and force a protracted decade-long migration in the changes to DNS transport protocols. I pick #1. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 10:37:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76A528C10D; Tue, 9 Jun 2009 10:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 AtqlXKqscktx; Tue, 9 Jun 2009 10:37:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F213F28C1A2; Tue, 9 Jun 2009 10:37:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME5CI-0007VT-4V for namedroppers-data0@psg.com; Tue, 09 Jun 2009 17:33:18 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME5C7-0007Uh-2R for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 17:33:12 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C4733A5012; Tue, 9 Jun 2009 17:33:06 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Olafur Gudmundsson cc: David Conrad , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: TCP queries to the root servers In-Reply-To: Your message of "Tue, 09 Jun 2009 10:49:49 -0400." <200906091516.n59FGWmU030205@stora.ogud.com> References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <200906091516.n59FGWmU030205@stora.ogud.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 09 Jun 2009 17:33:06 +0000 Message-ID: <65970.1244568786@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Tue, 09 Jun 2009 10:49:49 -0400 > From: Olafur Gudmundsson > > I take this as an endorsement that the root zone be signed using NSEC to > make any such changes transparent. yes, please. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 10:58:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782CA28C0E7; Tue, 9 Jun 2009 10:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 xp1DhOAgn1ug; Tue, 9 Jun 2009 10:58:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A1F13A6C70; Tue, 9 Jun 2009 10:58:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME5Wb-000BGn-CO for namedroppers-data0@psg.com; Tue, 09 Jun 2009 17:54:17 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME5WP-000BFi-T2 for namedroppers@psg.com; Tue, 09 Jun 2009 17:54:11 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59Hs1Pb083945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 10:54:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 9 Jun 2009 10:54:00 -0700 To: Samuel Weiler From: Paul Hoffman Subject: Re: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" Cc: namedroppers@psg.com Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 8:27 PM -0400 6/8/09, Samuel Weiler wrote: >[ Moderators note: Post was moderated, either because it was posted by > a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] > >On Mon, 8 Jun 2009, Paul Hoffman wrote: > >>>RFC4034 and its ancestors reserved two values (253 and 254) for "private" algorithms and specified ways to use multiple private algorithms without bad interactions. While I doubt the code to do that is well-tested, presumably the code to use GOST in DNSSEC isn't well-tested, either. Perhaps both could be debugged together. >> >>I'm having a hard time parsing your statement. It sounds like "if GOST cannot be on standards track, people who want to use GOST can only identify it as 253 or 254". I certainly hope I am misinterpreting you... > >RFC4034 section A.1.1 describes how the private algorithm types work, which includes embedding longer algorithm identifiers in the DNSKEY and RRSIG data. So one might say "if an algorithm does not have a unique algorithm number assigned, its use can be identified by the algorithm number 253 and the unique domain name X". Again, I hope I'm misinterpreting you. It sounds like you are saying "algorithms with standards track RFCs are uniquely identified by a single octet; algorithms with an informational RFC must waste octets in every signature by including a domain name". Is that the tradeoff you want for your concern of us having 250 standards-track signature mechanisms (even though no other crypto protocol in the IETF has that many)? --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 11:26:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A9E3A6D3D; Tue, 9 Jun 2009 11:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.365 X-Spam-Level: X-Spam-Status: No, score=-5.365 tagged_above=-999 required=5 tests=[AWL=-0.928, 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 Oe6YiacPpBsZ; Tue, 9 Jun 2009 11:26:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F27BD3A681A; Tue, 9 Jun 2009 11:26:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME5vq-000GFX-Rr for namedroppers-data0@psg.com; Tue, 09 Jun 2009 18:20:22 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME5vb-000GDs-Su for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 18:20:17 +0000 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 4AAC4A94439; Tue, 9 Jun 2009 18:20:07 +0000 (UTC) Cc: namedroppers@ops.ietf.org Message-Id: From: Douglas Otis To: Andrew Sullivan In-Reply-To: <20090609160854.GC25651@shinkuro.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Re: TCP queries to the root servers Date: Tue, 9 Jun 2009 11:20:04 -0700 References: <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> <20090609160854.GC25651@shinkuro.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 9, 2009, at 9:08 AM, Andrew Sullivan wrote: > As near as I can tell, the start of this topic was that things would > be better if we switched to TCP, which was immediately rejected as > entailing too much state on the authority servers. That argument > led us to the possibility of mirroring the root zone more widely. > > Since, as Paul points out, the problem is at least as bad for the > authority servers for large TLDs as it is for the root, we have > either established that the solution doesn't fit the problem, or > else that we need to distribute many zones so widely. In the > absence of a proposal to ensure such wide mirroring that is not > subject to all of the problems that the HOSTS file had, I think we > can conclude that the proposal is not an answer to the problem of > TCP state on authority servers. Agreed. Is there interest in creating a draft that describes how SCTP fallback for DNS might be implemented? From our company's perspective, defending TCP services through massive distribution represents a sizable portion of overall corporate expenditures. In the long view, it would be remiss not to explore more robust solutions that avoid critical infrastructure being replicated by orders of magnitude. While SCTP is likely to require greater resources than what is required for UDP, SCTP offers faster connection setup than TCP. For DNS, when compared to TCP, this represents an opportunity to offer data ahead of requests. This additional information might enable distribution strategies, for example. SCTP can permit DNS message alignment within packets, where individual messages can be acknowledged separately. Header alignment eliminates message buffering and head of queue blocking that occurs with TCP. Once an association is established, SCTP operates in a manner that closely approximates UDP. Unlike TCP, SCTP does not commit resources until a cookie is returned. This property enables important defensive strategies. Source identification offers immunity from flood attacks by allowing abusive sources to be properly handled without an inadvertent denial of services. Source spoofing is a costly problem for either UDP and TCP, that SCTP resolves effectively within the protocol. Estimating resources required by SCTP should consider optimized handling of SCTP associations. There is no reason to assume DNS will only use SCTP in a generic manner. Of course, SCTP offers better transaction security and would prevent Kaminsky related attacks with or without DNSSEC. As a minor note, SCTP error detection offers support for jumbo frames and provides better data integrity for unsigned portions of DNS messages. The ability of either UDP or TCP checksums to detect common bus related errors is astonishing poor. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 11:31:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4C13A681A; Tue, 9 Jun 2009 11:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[AWL=-1.318, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL4SmJAgEiYd; Tue, 9 Jun 2009 11:31:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB9313A67DF; Tue, 9 Jun 2009 11:31:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME63U-000Hga-Ed for namedroppers-data0@psg.com; Tue, 09 Jun 2009 18:28:16 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME63J-000Hfh-I4 for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 18:28:11 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 289B92FE960A; Tue, 9 Jun 2009 18:28:04 +0000 (UTC) Date: Tue, 9 Jun 2009 14:28:01 -0400 From: Andrew Sullivan To: Douglas Otis Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: TCP queries to the root servers Message-ID: <20090609182801.GB32546@shinkuro.com> References: <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> <20090609160854.GC25651@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: On Tue, Jun 09, 2009 at 11:20:04AM -0700, Douglas Otis wrote: > Agreed. Is there interest in creating a draft that describes how SCTP > fallback for DNS might be implemented? I believe Paul Vixie already expressed interest in doing this. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 12:21:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9A728C1B5; Tue, 9 Jun 2009 12:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYZ-WutVhuUL; Tue, 9 Jun 2009 12:21:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F3A323A695B; Tue, 9 Jun 2009 12:21:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME6o4-00003W-1L for namedroppers-data0@psg.com; Tue, 09 Jun 2009 19:16:24 +0000 Received: from [209.85.219.207] (helo=mail-ew0-f207.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME6ns-000022-MM for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 19:16:18 +0000 Received: by ewy3 with SMTP id 3so237040ewy.41 for ; Tue, 09 Jun 2009 12:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=G0q5zKhC4c+E5+PZqEiSYs/yHj3+J6u4lhtSwXtjx8c=; b=QVDPuawSFehzqAJRDHOI8ZxKhzDDYEv+oQ2bU5PDsh7XJGm1datC/+pnTPnQfA/Sa2 apPEiu+dufrM92eSaKTd3vytSbrUe/awIO9H6PprpJCXm60cEJ1BVQhuNxf08NSmqOu4 EwOk4upeq9jnRX3Dgiq0BnJttk9pFgG0ey1nk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=YxPIR6GDuPbH+fzZCgv34DGSlQiDBaldFbBvL36jW4wT6TbDBAELsgE3KZo1/tEq+j vGq2Bk/INuOck9Hmp3jkkIPgIUeNzO2lZd8X7i9woQaJUElcpM9uyv3yd6X2O0h3AM5g qT0fRv+OkqZLV1YiF6DZm+7/DGW5YdRvqtVi0= MIME-Version: 1.0 Received: by 10.210.92.8 with SMTP id p8mr3056532ebb.62.1244574971201; Tue, 09 Jun 2009 12:16:11 -0700 (PDT) In-Reply-To: <20090609182801.GB32546@shinkuro.com> References: <20090608111014.GA31833@vacation.karoshi.com.> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> <20090609160854.GC25651@shinkuro.com> <20090609182801.GB32546@shinkuro.com> From: bert hubert Date: Tue, 9 Jun 2009 21:15:51 +0200 Message-ID: <3efd34cc0906091215t419a6bc3k369067783fdc6266@mail.gmail.com> Subject: Re: [dnsext] Re: TCP queries to the root servers To: Andrew Sullivan Cc: Douglas Otis , 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: On Tue, Jun 9, 2009 at 8:28 PM, Andrew Sullivan wrote: > On Tue, Jun 09, 2009 at 11:20:04AM -0700, Douglas Otis wrote: > >> Agreed. =A0Is there interest in creating a draft that describes how SCTP >> fallback for DNS might be implemented? > > I believe Paul Vixie already expressed interest in doing this. I did some tests, and added SCTP serving support to the PowerDNS Recursor, and to our regression testing query tool ('sdig'). I have to admit to not being an SCTP expert, the last paragraph of this message contains some open questions. To keep it brief, the summary is that SCTP uses at least twice as many packets as UDP, and far more if the association is not kept open for a long time. Furthermore, an open association consumes server resources, and probably not less than TCP (even while sharing a file descriptor between queries). The initial cookie does not mitigate this - every association carries state that has to be carried around. >From this, my tentative conclusion is that SCTP transport per-se does not buy us anything over TCP - even though it offers a 'datagram-like' coding experience. The whole story: Interestingly enough, from a coding perspective, setting up the connection is almost entirely TCP like, whereas responding to actual queries runs 100% correctly using the unmodified UDP codepath (recvfrom, sendto). This is with the SCTP API in 'one-to-many' mode. In my measurements, I've seen that at least when used out of the box, SCTP uses 4 packets for each query/response exchange when an association has already been setup (query, response, query-sack, response-sack). Association setup is 4 packets, teardown is 3. Two packets of the setup can carry both the 'cookie' and the initial request, plus the cookie ack and the first data ack, saving 2 packets. This reduces the initial setup costs in terms of packets to 2. This makes for a grand total of 9 packets (!) for one DNS query carried by SCTP that is not quickly followed by another. Two queries in quick succession run to 13 packets, 3 queries squeeze into 17 packets. In my testing, I often encountered so called 'heartbeat' packets, which further increase the packet count. An open question is if all these 'SACK' packets can be turned off, or if SCTP could offer the equivalent of 'NOLINGER' so we could save another two packets (RST). But as stated above, even if both answers are yes, we are looking at very elevated packet counts, at no less cost than TCP (to the operating system). Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 13:29:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3668C3A6DB2; Tue, 9 Jun 2009 13:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4Rhj9aghlVu; Tue, 9 Jun 2009 13:29:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 626D53A69E5; Tue, 9 Jun 2009 13:29:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME7qx-000BJY-0J for namedroppers-data0@psg.com; Tue, 09 Jun 2009 20:23:27 +0000 Received: from [209.85.217.220] (helo=mail-gx0-f220.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME7ql-000BI9-6u for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 20:23:20 +0000 Received: by gxk20 with SMTP id 20so409688gxk.17 for ; Tue, 09 Jun 2009 13:23:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.89.8 with SMTP id m8mr403147agb.23.1244578993505; Tue, 09 Jun 2009 13:23:13 -0700 (PDT) In-Reply-To: <3efd34cc0906091215t419a6bc3k369067783fdc6266@mail.gmail.com> References: <20090608111014.GA31833@vacation.karoshi.com.> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> <20090609160854.GC25651@shinkuro.com> <20090609182801.GB32546@shinkuro.com> <3efd34cc0906091215t419a6bc3k369067783fdc6266@mail.gmail.com> Date: Tue, 9 Jun 2009 13:23:13 -0700 Message-ID: Subject: Re: [dnsext] Re: TCP queries to the root servers From: Matthew Dempsky To: bert hubert Cc: Andrew Sullivan , Douglas Otis , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jun 9, 2009 at 12:15 PM, bert hubert wrote: > To keep it brief, the summary is that SCTP uses at least twice as many > packets as UDP, and far more if the association is not kept open for a > long time. Furthermore, an open association consumes server resources, > and probably not less than TCP (even while sharing a file descriptor > between queries). The initial cookie does not mitigate this - every > association carries state that has to be carried around. I don't have any SCTP experience, but these results seem discouraging for DNS-over-SCTP adoption. I'd be interested in knowing if these results contradict any DNS-over-SCTP proponents' experiences/expectations. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 13:53:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67F333A6DD2; Tue, 9 Jun 2009 13:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[AWL=-0.595, 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 rliLoGjKrzB2; Tue, 9 Jun 2009 13:53:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E74D3A6CBE; Tue, 9 Jun 2009 13:53:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME8Fx-000FUZ-ID for namedroppers-data0@psg.com; Tue, 09 Jun 2009 20:49:17 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME8Fl-000FTZ-TF for namedroppers@psg.com; Tue, 09 Jun 2009 20:49:11 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n59Kn2eq034140; Tue, 9 Jun 2009 16:49:03 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906092049.n59Kn2eq034140@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Jun 2009 16:48:47 -0400 To: Paul Hoffman , namedroppers@psg.com From: Olafur Gudmundsson Subject: Re: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: After reading this reply over before sending it, I'm not sure I'm able to keep apart my personal opinions, the opinion of the WG chair role I have or the role of DNSSEC historian. Thus please read this as my personal opinion not associated with my role as DNSEXT chair. At 18:56 05/06/2009, Paul Hoffman wrote: >Greetings again. Appendix A.1 in RFC 4034 has the initial list of >algorithm types for DNSSEC. To add to that table, one needs a >standards-track RFC. This means that an signature algorithm that >cannot be embodied in a standards-track RFC, such as because it is >not completely in English, cannot be used interoperably in DNSSEC. >For example, this might prevent the GOST work the WG has taken on >from being used if the eventual RFC is Informational instead of >Standards Track. > >This seems unnecessarily limiting. I am not aware of any other WG >that requires a standards track RFC for allocating an identifier for >a cryptographic specification. *Many* cryptographic specifications >are described in Informational RFCs, and this has not been a problem >for anyone. This message is about adding new algorithms in general to DNSSEC. DNS is an important infrastructure protocol, if it stops working other things fail. For that reason until something in shown to be HARMLESS we have standards action controlling admission. Good example is the RRtype admission criteria used to be standards action, RFC2929 changed that to "IETF Consensus" and "Specification Required" , RFC5395 relaxed it to "Expert Review". In DNS there is no handshake between "client" and "original server" to negotiate the algorithm to use, either the client understands the "broadcast" RRSIG or it does not. For this reason keeping the list of algorithms that "clients" need to understand small is an interoperabilty advantage. It takes much longer to upgrade installed software base than the glacial phase of draft progressing through the working group + IESG, thus the speed of allocation argument is not a compelling one. If someone wants to experiment the private name spaces alg=253 and 254 are available. The private spaces IMHO are not suitable for production use. We do not want to encourage "Vanity" algorithms, there should be a good reason for adopting new algorithms. Having said that I think the next algorithm we adopt (after RSA/SHA256) ought to be an Elliptic Curve algorithm. Followed by the phasing out of DSA. Due to the transport used by DNS we do not want to encourage/require zones to use multiple DNSKEY algorithms to sign their zone. In general only during transition from one algorithm to another should zone be signed by multiple algorithms. The more algorithms used ==> more signatures on each RRset ==> larger answers. In the history of systems with "finite" number spaces we have a history of running out of the space no matter how large the early adopters thought the space was. Remember IPv4 addresses, DHCP option space, AS numbers, original Icelandic tax id numbers [1], etc. etc. The moral is be conservative in allocations OR before allocations are opened up have a reuse plan in place. >Therefore, I propose that the WG take on a short revision to RFC >4034 that makes the one change of making assignments into the IANA >registry for DNSSEC Algorithm Types be "RFC Published". In addition, >it would allow IANA to pre-assign values based on requests from an >Area Director. This would allow Internet Drafts that are proposing >new signature algorithms to contain valid examples of records using >the proposed algorithms. I will strongly advocate against relaxing the allocation rule until someone convinces me that relaxing it is harmless. Same goes for new NSEC3 obfuscation algorithms. Olafur [1] The number (8 digits actually 7 the last one was a check digit) reflected the name of the person. For each name there was a finite number space that based on the following assumptions: - List of names was fixed as the government maintained a list of names that were acceptable - distribution of names was going to be the same as it was just before the system was put in place. - Population would keep growing slowly - Life expectancy would not change - Number would only be used for tax identification Guess what all of the assumptions were wrong, the situation got so bad that numbers were reused in the same tax year. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 14:19:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 945403A698F; Tue, 9 Jun 2009 14:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwouSGSyS6TB; Tue, 9 Jun 2009 14:19:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62F4A3A6847; Tue, 9 Jun 2009 14:19:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME8az-000J3E-84 for namedroppers-data0@psg.com; Tue, 09 Jun 2009 21:11:01 +0000 Received: from [209.85.210.185] (helo=mail-yx0-f185.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME8aj-000Ixu-4C for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 21:10:55 +0000 Received: by yxe15 with SMTP id 15so43205yxe.5 for ; Tue, 09 Jun 2009 14:10:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.106.3 with SMTP id e3mr425275agc.54.1244581843634; Tue, 09 Jun 2009 14:10:43 -0700 (PDT) Date: Tue, 9 Jun 2009 14:10:43 -0700 Message-ID: Subject: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Currently, the root servers provide IPv6 glue (AAAA records) to clients that have queried them over IPv4. They even do this in preference to providing all of the IPv4 glue; e.g., "dig www.example.com @a.root-servers.net" returns IPv6 glue for {a,b}.gtld-servers.net, but no IPv4 glue for m.gtld-servers.net. This is seems to be due to omitting records to fit into the 512 byte boundary: "dig x.com @a.root-servers.net" returns all IPv4 glue. dnscache from djbdns tries to find A records for all listed NS records before contacting any of them, which results in an extra root zone query for m.gtld-servers.net in the above situation. (This causes a small slow down and additional network traffic, but is not otherwise a significant problem.) Is there any reason why servers shouldn't prefer *for IPv4 clients* to give all IPv4 glue records and then try to add as many IPv6 glue records as possible? (Similarly, for IPv6 clients to give all IPv6 glue records and then try to add as many IPv4 glue records as possible.) A records are always potentially useful for clients contacting a server over IPv4, and AAAA records are always potentially useful for clients contacting a server over IPv6, but A records are not useful to IPv6-only clients and AAAA records are not useful to IPv4-only clients. One corner case that comes to mind is if an authoritative server is on an IPv4 only network, but has a gateway that can proxy IPv6 traffic to IPv4. However, this seems easy enough to work around (e.g., either upgrade the internal network to support native IPv6, or configure the DNS server to treat traffic from the IPv6-to-IPv4 gateway as IPv6 traffic). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 14:29:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492513A6BDA; Tue, 9 Jun 2009 14:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.859 X-Spam-Level: * X-Spam-Status: No, score=1.859 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RCVD_IN_NJABL_PROXY=1.643, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcf9cfd8R4lC; Tue, 9 Jun 2009 14:29:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5557C3A6DF1; Tue, 9 Jun 2009 14:29:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME8nb-000L7k-6S for namedroppers-data0@psg.com; Tue, 09 Jun 2009 21:24:03 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME8nP-000L6l-KB for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 21:23:57 +0000 Received: (qmail 88214 invoked from network); 9 Jun 2009 22:56:25 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 9 Jun 2009 22:56:25 -0000 Message-ID: <4A2ED2BF.7000202@necom830.hpcl.titech.ac.jp> Date: Wed, 10 Jun 2009 06:23:11 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Shane Kerr , namedroppers@ops.ietf.org Subject: Re: TCP performance, was Re: [dnsext] Re: TCP queries to the root servers References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <1244464268.4151.12474.camel@shane-asus-laptop> <20090608130235.GB32556@vacation.karoshi.com.> In-Reply-To: <20090608130235.GB32556@vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bmanning@vacation.karoshi.com wrote: > Max Connections Go to top > Description: Specifies the maximum concurrent connections that > the server can accept. It includes both plain TCP connections > and SSL connections. It should not exceed the hard limit set > by the server: 300 for Standard Edition. > that 300 number sticks out like a sore thumb. just a tad shy of the swag target of 10,000 > TCP setups per second adn the ongoing tracking for the 60,000 halfopen (keep-alives) projected. > > what am i missing here? I reconsidered the problem and noticed that the figure of 300 should comes from SSL computation and disk access to retrieve various HTML files, none of which are applicable to root servers just returning the same data stored in memory in plain text. Keeping 60,000 connections halfopen for 120 seconds is not a problem because, in average, only 500 of them needs timeout processing and others are resting in memory. Given that a pcb is 176B long, the amount of memory to keep 60,000 pcbs is about 10MB. These days, even secondary cache can hold it. It is inappropriate to mix figures from a though experiment by Shane and from real world HTTP servers by Bill. Masataka Ohta PS As I briefly checked, to have 240 cores, you only need 3 small (6U) blade servers, each of which has 10 blades, each of which have 8 cores. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 14:35:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793073A6A12; Tue, 9 Jun 2009 14:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.858 X-Spam-Level: * X-Spam-Status: No, score=1.858 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RCVD_IN_NJABL_PROXY=1.643, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQkJ6PxLD-65; Tue, 9 Jun 2009 14:35:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B8593A698C; Tue, 9 Jun 2009 14:35:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME8ur-000MMT-3N for namedroppers-data0@psg.com; Tue, 09 Jun 2009 21:31:33 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME8uf-000MLZ-Ud for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 21:31:27 +0000 Received: (qmail 88533 invoked from network); 9 Jun 2009 23:04:08 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 9 Jun 2009 23:04:08 -0000 Message-ID: <4A2ED48F.7040807@necom830.hpcl.titech.ac.jp> Date: Wed, 10 Jun 2009 06:30:55 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Olafur Gudmundsson CC: Paul Vixie , David Conrad , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: TCP queries to the root servers References: <47784.1244238104@nsa.vix.com> <40AE90B2-AE0D-47F3-A0B9-6960C7F535CF@virtualized.org> <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <200906091516.n59FGWmU030205@stora.ogud.com> In-Reply-To: <200906091516.n59FGWmU030205@stora.ogud.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Olafur Gudmundsson wrote: >> in my hotel in beijing last week, all traffic toward any root name server >> address was answered inside chinanet by chinanet's own servers. not a >> comfortable environment in which to consider wide scale root zone >> mirroring. > I take this as an endorsement that the root zone be signed using NSEC > to make any such changes transparent. An obvious solution is to solve the problem end to end by using a resolver at your home (or home ISP). I actually did so several times when resolvers of ISPs local to my laptop were malfunctioning. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 14:49:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A952D3A68B0; Tue, 9 Jun 2009 14:49:03 -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 la3Eu5nIynvI; Tue, 9 Jun 2009 14:49:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 71EE33A6874; Tue, 9 Jun 2009 14:49:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME97p-000Og0-Gv for namedroppers-data0@psg.com; Tue, 09 Jun 2009 21:44:57 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME97d-000OaX-9e for namedroppers@psg.com; Tue, 09 Jun 2009 21:44:52 +0000 Received: from [10.31.200.162] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n59Liejw034811; Tue, 9 Jun 2009 17:44:40 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200906092049.n59Kn2eq034140@stora.ogud.com> References: <200906092049.n59Kn2eq034140@stora.ogud.com> Date: Tue, 9 Jun 2009 17:43:27 -0400 To: Olafur Gudmundsson From: Edward Lewis Subject: Re: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" Cc: Paul Hoffman , namedroppers@psg.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 16:48 -0400 6/9/09, Olafur Gudmundsson wrote: >We do not want to encourage "Vanity" algorithms, there should be a good >reason for adopting new algorithms. Having said that I think the next >algorithm we adopt (after RSA/SHA256) ought to be an Elliptic Curve >algorithm. Followed by the phasing out of DSA. I disagree with the previous paragraph. For one, what is a "vanity" algorithm? And what is a "good reason" to adopt? I think the flaw in the logic above it that the choice of cryptographic system is not strictly a technical decision. There are other factors involved, whether the factors run counter to an engineer's sensibilities or not. One could argue that DSA is a "vanity" algorithm as very few zones use it and not one of the TLDs in the iTAR uses DSA. I don't know of any zone that uses DSA - I bet there are some. According to http://secspider.cs.ucla.edu/, there are 10 RSA/MD5 keys, 20 DSA/SHA-1, and about 20,000 RSA/SHA-1. I don't think it is up to the DNS Extensions WG to dictate policy regarding the use of cryptography. >Due to the transport used by DNS we do not want to encourage/require >zones to use multiple DNSKEY algorithms to sign their zone. In >general only during transition from one algorithm to another should zone >be signed by multiple algorithms. >The more algorithms used ==> more signatures on each RRset ==> larger answers. This is a red herring. If it is the size of response that is a concern, then a zone should stick to one algorithm at a time - it doesn't matter which algorithm is used so long as the resolvers understand a range of algorithms. There's a fear that resolver's won't be updated? Maybe so, but it is in the interests of the resolver to keep up to date on this. At the NIST Key Management Symposium, it was stated that cryptographic algorithms, like keys, wear out their welcome. >The moral is be conservative in allocations OR >before allocations are opened up have a reuse plan in place. My take on the moral - especially with regards to IPv4 run out - is to build in a transition plan (to a larger name space). The hang up with IPv4 and IPv6 is not that we are out of IPv4 addresses but that no one thought to include in IPv6 a transition mechanism. The transition from 2-byte to 4-byte Autonomous System numbers hasn't been a major problem because, fortunately, the transition plan was able to fall into place. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 14:56:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3533A6DD0; Tue, 9 Jun 2009 14:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZyT3kUwUhfh; Tue, 9 Jun 2009 14:56:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8DE043A698C; Tue, 9 Jun 2009 14:56:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME9FW-00001v-VU for namedroppers-data0@psg.com; Tue, 09 Jun 2009 21:52:54 +0000 Received: from [209.85.217.220] (helo=mail-gx0-f220.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME9FH-000PtC-DB for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 21:52:49 +0000 Received: by gxk20 with SMTP id 20so518153gxk.17 for ; Tue, 09 Jun 2009 14:52:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.89.8 with SMTP id m8mr469595agb.15.1244584357657; Tue, 09 Jun 2009 14:52:37 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Jun 2009 14:52:37 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Yes. It's a dumb idea to tamper with the contents of a DNS response based on > the underlying network protocol that gets used for the query/reply. It's a dumb idea to omit glue records too, but that's the solution the root servers have chosen for dealing with their large delegation record sets. > There's > usually a resolving server between the edge client (stub resolver) making > the query and the authoritative server. That authoritative server doesn't > see the stub resolver. So it has no way of knowing if that client prefers A > or AAAA records. It shouldn't (need to) care about the client's preferences > or network protocol choices anyway. Huh? The glue data doesn't go to the stub resolver anyway. The stub resolver encodes what data it wants in the questions section by explicitly asking for either A or AAAA records. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 15:28:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E8E3A698B; Tue, 9 Jun 2009 15:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 yWJvUahYNUUm; Tue, 9 Jun 2009 15:28:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4CDFC3A6887; Tue, 9 Jun 2009 15:28:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME9iw-00053j-EZ for namedroppers-data0@psg.com; Tue, 09 Jun 2009 22:23:18 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME9ig-00052Y-B9 for namedroppers@psg.com; Tue, 09 Jun 2009 22:23:12 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n59MMaqo098372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 15:22:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200906092049.n59Kn2eq034140@stora.ogud.com> References: <200906092049.n59Kn2eq034140@stora.ogud.com> Date: Tue, 9 Jun 2009 15:20:59 -0700 To: Olafur Gudmundsson , namedroppers@psg.com From: Paul Hoffman Subject: Re: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 4:48 PM -0400 6/9/09, Olafur Gudmundsson wrote: >DNS is an important infrastructure protocol, if it stops working >other things fail. For that reason until something in shown to be >HARMLESS we have standards action controlling admission. Does this means that you are against the current SHA-256 document, which cannot be shown to be harmless? You have supported it in the recent past. We *know* that SHA-256 will get worse over time, and will need to have a transition away from it. Why the contradiction? >In DNS there is no handshake between "client" and "original server" to negotiate >the algorithm to use, either the client understands the "broadcast" >RRSIG or it does not. For this reason keeping the list of algorithms that >"clients" need to understand small is an interoperabilty advantage. We fully agree. But that statement is irrelevant to whether or not an algorithm needs to be on standards track. No system needs to implement all standards track documents, as we all know. >It takes much longer to upgrade installed software base than the >glacial phase of draft progressing through the working group + IESG, >thus the speed of allocation argument is not a compelling one. >If someone wants to experiment the private name spaces alg=253 and 254 >are available. The private spaces IMHO are not suitable for production use. Section A.1.1 of RFC 4034 makes it quite clear that they are intended for production use. >We do not want to encourage "Vanity" algorithms, there should be a good >reason for adopting new algorithms. Fully agree. >Due to the transport used by DNS we do not want to encourage/require >zones to use multiple DNSKEY algorithms to sign their zone. In >general only during transition from one algorithm to another should zone >be signed by multiple algorithms. >The more algorithms used ==> more signatures on each RRset ==> larger answers. Quite right. However, that is also irrelevant to whether or not something needs to be on standards track. >In the history of systems with "finite" number spaces we have a history of >running out of the space no matter how large the early adopters thought the space >was. Remember IPv4 addresses, DHCP option space, AS numbers, original Icelandic >tax id numbers [1], etc. etc. The moral is be conservative in allocations OR >before allocations are opened up have a reuse plan in place. As Sam Weiler pointed out, we already have one: Section A.1.1 of RFC 4034. You might change your view on whether or not that is suitable for production use (if we ever get there). --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 15:44:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF813A6887; Tue, 9 Jun 2009 15:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id by3ZYUKcs+YK; Tue, 9 Jun 2009 15:44:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 613A33A6781; Tue, 9 Jun 2009 15:44:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME9yw-0007ne-Vd for namedroppers-data0@psg.com; Tue, 09 Jun 2009 22:39:50 +0000 Received: from [195.54.233.69] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ME9yk-0007fs-S0 for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 22:39:45 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gromit.rfc1035.com (Postfix) with ESMTP id 075554B774B; Tue, 9 Jun 2009 23:39:38 +0100 (BST) Cc: namedroppers@ops.ietf.org Message-Id: <4D291F23-2937-4A13-A01D-9BD7630E7F32@rfc1035.com> From: Jim Reid To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Date: Tue, 9 Jun 2009 23:39:37 +0100 References: X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 9 Jun 2009, at 22:52, Matthew Dempsky wrote: > It's a dumb idea to omit glue records too, No it isn't. There is a limit on the size of a DNS response. So dropping stuff from the Additional Section is preferable to sending a truncated response and TCP retries. As long as the reponse contains *some* glue -- assuming we're talking about the real definition of glue -- that's good enough. In the case you mentioned, who cares if the referral for example.com from a.root-servers.net does not have an address record for m.gtld- servers.net? It's got A and AAAA records for the other .com servers. That response BTW is 501 bytes, so there's not enough room left to squeeze in an address record for m.gtld-servers.net. If the querying server *really* needs that info, it can just do a lookup to resolve that name. Oh and NONE of the address records in that referral response are glue.Their names don't live under the domain that's being queried (example.com). They live under gtld-servers.net. So strictly speaking there's no reason for a.root-servers.net to return those address records at all. It was just doing that to be nice. >> There's >> usually a resolving server between the edge client (stub resolver) >> making >> the query and the authoritative server. That authoritative server >> doesn't >> see the stub resolver. So it has no way of knowing if that client >> prefers A >> or AAAA records. It shouldn't (need to) care about the client's >> preferences >> or network protocol choices anyway. > > Huh? The glue data doesn't go to the stub resolver anyway. That's irrelevant to your question about making DNS responses conditional on the network protocol used for making queries. I just used the simple example of a conventional lookup to show why. > The stub resolver encodes what data it wants in the questions > section by > explicitly asking for either A or AAAA records. Not always. It may be asking for other stuff: MX or CNAME records and so on. In which case any address records returned in the Additional Section of the response are a bonus. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 16:07:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086B13A67F1; Tue, 9 Jun 2009 16:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY69nMCmzsjW; Tue, 9 Jun 2009 16:07:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0DB3A3A6781; Tue, 9 Jun 2009 16:07:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEALa-000BdH-8b for namedroppers-data0@psg.com; Tue, 09 Jun 2009 23:03:14 +0000 Received: from [74.125.46.28] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEALO-000Bcc-P9 for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 23:03:08 +0000 Received: by yw-out-2324.google.com with SMTP id 9so162338ywe.71 for ; Tue, 09 Jun 2009 16:03:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.231.4 with SMTP id d4mr736605anh.24.1244588582023; Tue, 09 Jun 2009 16:03:02 -0700 (PDT) In-Reply-To: <4D291F23-2937-4A13-A01D-9BD7630E7F32@rfc1035.com> References: <4D291F23-2937-4A13-A01D-9BD7630E7F32@rfc1035.com> Date: Tue, 9 Jun 2009 16:03:02 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: Jim Reid 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: On Tue, Jun 9, 2009 at 3:39 PM, Jim Reid wrote: > No it isn't. Sorry, you're right, slowing down DNS resolution time and adding additional load to the root servers is a great solution. > So dropping > stuff from the Additional Section is preferable to sending a truncated > response and TCP retries. Fine, but if you're going to drop glue data, then drop the less useful glue data. > In the case you mentioned, who cares if the referral for example.com from > a.root-servers.net does not have an address record for m.gtld-servers.net= ? I gave an example of a widely used DNS server in my first email that cares. > It's got A and AAAA records for the other .com servers. That response BTW= is > 501 bytes, so there's not enough room left to squeeze in an address recor= d > for m.gtld-servers.net. If the querying server *really* needs that info, = it > can just =A0do a lookup to resolve that name. The client asked a root server over IPv4, not over IPv6. It obviously prefers to talk to servers over IPv4 instead of over IPv6, so there's no reason that glue AAAA records provided for names listed in NS records should have priority over glue A records provided for names listed in NS records. > Oh and NONE of the address records in that referral response are glue.The= ir > names don't live under the domain that's being queried (example.com). The= y > live under gtld-servers.net. So strictly speaking there's no reason for > a.root-servers.net to return those address records at all. It was just do= ing > that to be nice. Fine, substitute "www.example.com" with "www.example.net". >> Huh? =A0The glue data doesn't go to the stub resolver anyway. > > That's irrelevant to your question about making DNS responses conditional= on > the network protocol used for making queries. It's relevant to your argument that what glue records are included in delegation responses have anything to do with what IPv4/IPv6 connectivity a stub resolver has. >> The stub resolver encodes what data it wants in the questions section by >> explicitly asking for either A or AAAA records. > > Not always. It may be asking for other stuff: MX or CNAME records and so = on. > In which case any address records returned in the Additional Section of t= he > response are a bonus. They're a bonus for MX records, but they're necessary for NS records pointing to in-bailiwick names. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 16:15:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A733A67F1; Tue, 9 Jun 2009 16:15:27 -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 YnDx0EyY16tA; Tue, 9 Jun 2009 16:15:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 80AE63A67B5; Tue, 9 Jun 2009 16:15:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEATr-000DDN-Tc for namedroppers-data0@psg.com; Tue, 09 Jun 2009 23:11:47 +0000 Received: from [195.54.233.69] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEATg-000D64-Nr for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 23:11:42 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gromit.rfc1035.com (Postfix) with ESMTP id 178984B7A9C; Wed, 10 Jun 2009 00:11:36 +0100 (BST) Cc: namedroppers@ops.ietf.org Message-Id: <55D99BB7-1075-4A9C-90CE-BB5F4FD1805D@rfc1035.com> From: Jim Reid To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Date: Wed, 10 Jun 2009 00:11:35 +0100 References: <4D291F23-2937-4A13-A01D-9BD7630E7F32@rfc1035.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 10 Jun 2009, at 00:03, Matthew Dempsky wrote: > I gave an example of a widely used DNS server in my first email that > cares. No you didn't. You gave an example of a broken implementation with a small percentage of the installed base. It's so broken it doesn't even support EDNS0. Enough said. I have tried to apply clue. You have resisted those efforts. This discussion is over. Welcome to my kill file and goodbye. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 16:20:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16BDE3A67DF; Tue, 9 Jun 2009 16:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 nvCLkQD1RNcy; Tue, 9 Jun 2009 16:20:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A10F3A67B5; Tue, 9 Jun 2009 16:20:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEAZ0-000E4Z-D0 for namedroppers-data0@psg.com; Tue, 09 Jun 2009 23:17:06 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEAYp-000E3z-H0 for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 23:17:00 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 4F5D1A5061; Tue, 9 Jun 2009 23:16:54 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Douglas Otis cc: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: TCP queries to the root servers In-Reply-To: Your message of "Tue, 09 Jun 2009 11:20:04 MST." References: <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> <20090609160854.GC25651@shinkuro.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 09 Jun 2009 23:16:54 +0000 Message-ID: <80028.1244589414@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Douglas Otis > Date: Tue, 9 Jun 2009 11:20:04 -0700 > > Agreed. Is there interest in creating a draft that describes how SCTP > fallback for DNS might be implemented? i've taken a strong interest in this, but not as a fallback. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 16:27:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C77A3A694D; Tue, 9 Jun 2009 16:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t3rnkHERQsn; Tue, 9 Jun 2009 16:27:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F071F3A6841; Tue, 9 Jun 2009 16:27:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEAfp-000FGr-2F for namedroppers-data0@psg.com; Tue, 09 Jun 2009 23:24:09 +0000 Received: from [74.125.46.28] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEAfe-000FFt-9p for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 23:24:03 +0000 Received: by yw-out-2324.google.com with SMTP id 9so169105ywe.71 for ; Tue, 09 Jun 2009 16:23:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.68.12 with SMTP id q12mr538168aga.8.1244589815075; Tue, 09 Jun 2009 16:23:35 -0700 (PDT) In-Reply-To: <55D99BB7-1075-4A9C-90CE-BB5F4FD1805D@rfc1035.com> References: <4D291F23-2937-4A13-A01D-9BD7630E7F32@rfc1035.com> <55D99BB7-1075-4A9C-90CE-BB5F4FD1805D@rfc1035.com> Date: Tue, 9 Jun 2009 16:23:34 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: Jim Reid Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jun 9, 2009 at 4:11 PM, Jim Reid wrote: > No you didn't. You gave an example of a broken implementation with a small > percentage of the installed base. Guess what: the Internet is big! A "small percentage" is still a lot of installations. I'm sorry if you think the Internet should only be used by BIND. > It's so broken it doesn't even support EDNS0. Since when is not sending DNS queries with EDNS0 considered "broken"? Why do the root servers bother responding to caches that don't use EDNS0? If you want to weed out "broken" software, why not encourage the root and .com servers to stop responding to queries without EDNS0? :P > Enough said. I have tried to apply clue. You have resisted those > efforts. This discussion is over. > > Welcome to my kill file and goodbye. ohnoz! -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 16:40:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0483F3A6A48; Tue, 9 Jun 2009 16:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP5nImv3abrC; Tue, 9 Jun 2009 16:40:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E072E3A6930; Tue, 9 Jun 2009 16:40:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEArs-000HNB-2f for namedroppers-data0@psg.com; Tue, 09 Jun 2009 23:36:36 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEArg-000HMA-Fi for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 23:36:30 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 23937A508E; Tue, 9 Jun 2009 23:36:23 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Matthew Dempsky cc: bert hubert , Andrew Sullivan , Douglas Otis , namedroppers@ops.ietf.org Subject: SCTP (Re: [dnsext] Re: TCP queries to the root servers ) In-Reply-To: Your message of "Tue, 09 Jun 2009 13:23:13 MST." References: <20090608111014.GA31833@vacation.karoshi.com.> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> <20090609160854.GC25651@shinkuro.com> <20090609182801.GB32546@shinkuro.com> <3efd34cc0906091215t419a6bc3k369067783fdc6266@mail.gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 09 Jun 2009 23:36:23 +0000 Message-ID: <80879.1244590583@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Tue, 9 Jun 2009 13:23:13 -0700 > From: Matthew Dempsky > > I don't have any SCTP experience, but these results seem discouraging for > DNS-over-SCTP adoption. I'd be interested in knowing if these results > contradict any DNS-over-SCTP proponents' experiences/expectations. in SCTP it takes three packets to set up an association (which is like a TCP session only lightweight and spoofproof.) it takes four packets to shut down an association. so, setup and shutdown are expensive compared to UDP or TCP, and it only makes sense to use SCTP if you're able to keep the association open and use it for multiple transactions. it takes two packets to carry a request and a response, and if they are the last request and response in the queue then each of these will be followed by an ACK packet. so, a slow 1TPS flow would take four packets per transaction, whereas a faster flow would take two packets per transaction. the extra ACK-only packets don't delay the DNS result, but they do appear on the wire. by lightweight i mean that a root or TLD or 2LD/3LD server could have many hundredthousands or even millions of associations open, all on a single socket and therefore a single file descriptor, so it's not a burden on the DNS server's system call interface (think of a select() mask here, or a poll() filedes array.) the two-byte length field from TCP/53 need not be carried in SCTP, since the transport will tell the receiver the length of each incoming message. messages can be quite long, say 64KByte. the transport is reliable, so if some segment (packet) is dropped in transit it will be retransmitted and the receiver won't hear about it until the full message has landed. there is no IP fragmentation (any more than there is in TCP, and for the same reason). SCTP associations are spoofproof in a way that lets us go back to just setting DNS TID to 0 at the start of each association, and incrementing it by one each time we send a new transaction. there's no need for PING and neither a reason nor a method for randomizing source port numbers. most importantly, there's no trivial way to force a downgrade, so if an initiator tries SCTP first and only uses UDP when SCTP fails, then it will only use UDP if SCTP has in fact failed, rather than because an attacker wants it to look like it has failed. (short of a congestion attack that would also make UDP fail unless one could control the timing of the end of the attack down to the millisecond, which seems like a high enough bar.) so at the moment i think SCTP will be possible. interestingly, the same set of middleboxes and firewalls and NATs and PBRs that will prevent SCTP from working are also preventing EDNS from working right now. so while we can legitimately worry that SCTP will be hard to deploy, it turns out that we have already bitten off a similar challenge. SCTP has an advantage over EDNS/UDP in that no middlebox currently knows to look for DNS SCTP messages and rewrite them. if we do our job well and quickly, there never will be. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 17:00:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7663A696A; Tue, 9 Jun 2009 17:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.316 X-Spam-Level: X-Spam-Status: No, score=-5.316 tagged_above=-999 required=5 tests=[AWL=-0.879, 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 Mj76IBb3JxDn; Tue, 9 Jun 2009 17:00:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EA5CF3A6841; Tue, 9 Jun 2009 17:00:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEBAC-000Kcw-7g for namedroppers-data0@psg.com; Tue, 09 Jun 2009 23:55:32 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEBA1-000KcJ-6r for namedroppers@ops.ietf.org; Tue, 09 Jun 2009 23:55:26 +0000 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 9F41BA94439; Tue, 9 Jun 2009 23:55:20 +0000 (UTC) Cc: bert hubert , Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: <2F19E5E4-9907-475C-94A6-91A6AC54A007@mail-abuse.org> From: Douglas Otis To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] Comparing SCTP to TCP or UDP Date: Tue, 9 Jun 2009 16:55:20 -0700 References: <20090608111014.GA31833@vacation.karoshi.com.> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> <20090609160854.GC25651@shinkuro.com> <20090609182801.GB32546@shinkuro.com> <3efd34cc0906091215t419a6bc3k369067783fdc6266@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 9, 2009, at 1:23 PM, Matthew Dempsky wrote: > On Tue, Jun 9, 2009 at 12:15 PM, bert hubert > wrote: >> To keep it brief, the summary is that SCTP uses at least twice as >> many packets as UDP, and far more if the association is not kept >> open for a long time. Furthermore, an open association consumes >> server resources, and probably not less than TCP (even while >> sharing a file descriptor between queries). The initial cookie does >> not mitigate this - every association carries state that has to be >> carried around. > > I don't have any SCTP experience, but these results seem > discouraging for DNS-over-SCTP adoption. I'd be interested in > knowing if these results contradict any DNS-over-SCTP proponents' > experiences/expectations. Without question, SCTP requires more resources than UDP in the ideal case. However, the ideal case is _not_ where SCTP offers benefit. Don't compare SCTP in terms of UDP packets used under ideal conditions. Compare SCTP in terms of deterministic defenses against both brute and spoofed source attacks, and the number of servers required to withstand them. Defending against even a moderate attack requires substantial resources. In the case of UDP, these resources can be directed toward other victims. In the case of TCP, resources might be consumed rapidly by spoofed sources. With DNS over UDP, there is no way for DNS to prioritize responses or to determine with certainty which queries have spoofed source IP addresses or which are truly abusive. In the case of SCTP, a spoofed victim should be able to ignore, as a minor nuisance, unrequested SCTP cookies. With SCTP, DNS servers should also be able to dynamically exclude excessive queries without unfairly affecting service to those not involved. In the case of DNS over UDP, only BCP38 mitigates most traffic to spoofed victims. Unfortunately, BCP38 is not complete and is not a filter instantiated by victims to protect themselves. Unlike SCTP cookies or TCP SYN-ACKs, the overall size of a response to spoofed DNS over UDP can create sizable amplifications that grow even larger with EDNS/DNSSEC. In addition, spoofed UDP DNS queries will not respond to network congestion. Brute force reflected attacks using EDNS also introduce a potential for induced packet fragmentation. Fragmentation further increases the impact of an attack vector. With DNS over TCP, a transmission control block (TCB) is consumed by every SYN received and is retained until it times out. The rate of TCB consumption is not regulated by source IP addresses since these address are not confirmed prior to TCBs being committed. For targeted attacks, specific TCB associations having 20 second timeouts might be rapidly consumed by a single T1 link. Whether brute force, reflected, or source spoofed, the use of cookies by SCTP provides a method to construct fair and automated defenses that are otherwise impractical. As the speed of the Internet increases, many seem unaware of the looming problems ahead. Many continue to publish wildcard TXT SPF records that carry cached macros. Some now advocate the use of MX 0 . records to refute outbound email. Some have suggested packet cryptography offers protection from spoofed or brute force attacks. At least SCTP limits attack mitigation to the validation of one's own cookie. Don't just consider the ideal case, consider those cases that represent an existence within today's Internet -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 18:12:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A87C3A6B76; Tue, 9 Jun 2009 18:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 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 GDPX7iqiDxIt; Tue, 9 Jun 2009 18:12:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F1C03A6927; Tue, 9 Jun 2009 18:12:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MECGT-0007Jn-MP for namedroppers-data0@psg.com; Wed, 10 Jun 2009 01:06:05 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MECGH-0007IL-Jm for namedroppers@psg.com; Wed, 10 Jun 2009 01:05:59 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 79633E602F; Wed, 10 Jun 2009 01:05:52 +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 n5A15XtJ010644; Wed, 10 Jun 2009 11:05:45 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906100105.n5A15XtJ010644@drugs.dv.isc.org> To: Samuel Weiler Cc: Paul Hoffman , namedroppers@psg.com From: Mark Andrews Subject: Re: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" In-reply-to: Your message of "Mon, 08 Jun 2009 18:00:50 -0400." Date: Wed, 10 Jun 2009 11:05:33 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Samuel Weil er writes: > [ 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 Fri, 5 Jun 2009, Paul Hoffman wrote: > > > This means that an signature algorithm that cannot be embodied in a > > standards-track RFC, ... not completely in English, cannot be used > > interoperably in DNSSEC. > > RFC4034 and its ancestors reserved two values (253 and 254) for > "private" algorithms and specified ways to use multiple private > algorithms without bad interactions. While I doubt the code to do > that is well-tested, presumably the code to use GOST in DNSSEC isn't > well-tested, either. Perhaps both could be debugged together. Well tested? It's not even written and won't be until there is a need to write it. At the moment we treat all "private" algorithms as unknown. Unless you need to print the algorithm's name in a comment or you are trying to verify completeness in signing there is no need to examine it until you support crypto algorithms which use it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 18:15:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8C6D3A67B5; Tue, 9 Jun 2009 18:15:44 -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 VtzssIUONIWC; Tue, 9 Jun 2009 18:15:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C97853A6359; Tue, 9 Jun 2009 18:15:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MECMh-0008Ny-K4 for namedroppers-data0@psg.com; Wed, 10 Jun 2009 01:12:31 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MECMW-0008N3-9D for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 01:12:25 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 85600E6071; Wed, 10 Jun 2009 01:12:19 +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 n5A1C6ka010870; Wed, 10 Jun 2009 11:12:07 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906100112.n5A1C6ka010870@drugs.dv.isc.org> To: Andrew Sullivan Cc: Mark Andrews , Paul Hoffman , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-rsasha256-14.txt In-reply-to: Your message of "Tue, 09 Jun 2009 11:11:31 -0400." <20090609151129.GB25651@shinkuro.com> Date: Wed, 10 Jun 2009 11:12:06 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <20090609151129.GB25651@shinkuro.com>, Andrew Sullivan writes: > Your message doesn't provide enough context. I _think_ what you mean > is this: > > On Tue, Jun 09, 2009 at 01:05:20PM +1000, Mark Andrews wrote: > > > A DNSSSEC validator needs to understand both NSEC and NSEC3 for > > positive answers as well and negative answers, see wildard answers. > > That is a background remark. Yes. > > A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate > > > negative answers in the form of both NSEC and NSEC3 with hash > > algorithm 1, as defined in [RFC5155]. An authoritative server that > > does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 > > with NSEC denial of existence. > > That is a context paragraph taken directly from §5.2 of the -14 draft. > > > A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate > > denial of existance proofs in both NSEC and NSEC3 (with hash algorithm > > 1, as defined in [RFC5155]) forms. An authoritative server that > > does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 > > with NSEC denial of existence. > > That is additional text you want added at the end of §5.2. Possible replacement text. > Right? > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 19:59:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70DD43A6C29; Tue, 9 Jun 2009 19:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 mseQqplEMG1g; Tue, 9 Jun 2009 19:59:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D8813A699C; Tue, 9 Jun 2009 19:59:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEDxa-000028-BE for namedroppers-data0@psg.com; Wed, 10 Jun 2009 02:54:42 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEDxK-000Pw3-Eh for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 02:54:36 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 671ADE606E; Wed, 10 Jun 2009 02:54:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5A2s8cN012954; Wed, 10 Jun 2009 12:54:21 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906100254.n5A2s8cN012954@drugs.dv.isc.org> To: Matthew Dempsky Cc: Jim Reid , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients In-reply-to: Your message of "Tue, 09 Jun 2009 16:23:34 MST." Date: Wed, 10 Jun 2009 12:54:08 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Matth ew Dempsky writes: > On Tue, Jun 9, 2009 at 4:11 PM, Jim Reid wrote: > > No you didn't. You gave an example of a broken implementation with a small > > percentage of the installed base. > > Guess what: the Internet is big! A "small percentage" is still a lot > of installations. > > I'm sorry if you think the Internet should only be used by BIND. > > > It's so broken it doesn't even support EDNS0. > > Since when is not sending DNS queries with EDNS0 considered "broken"? > Why do the root servers bother responding to caches that don't use > EDNS0? To not break legacy (no IPv6 transport support) software. Dropping additional records should not cause iterative nameservers to break. If it does the software was not compliant in the first place. Note: Some of the roots *are* configured to preference A records in the additional section. This should not be needed for queries over IPv6 as EDNS support is manditory. See IPv6 node requirements. > If you want to weed out "broken" software, why not encourage > the root and .com servers to stop responding to queries without EDNS0? > :P > > > Enough said. I have tried to apply clue. You have resisted those > > efforts. This discussion is over. > > > > Welcome to my kill file and goodbye. > > ohnoz! > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 20:19:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F53A3A67D2; Tue, 9 Jun 2009 20:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.483 X-Spam-Level: X-Spam-Status: No, score=-0.483 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yszR1K+U1Ogt; Tue, 9 Jun 2009 20:19:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 11EBA3A6BC4; Tue, 9 Jun 2009 20:19:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEEHF-0003V3-NQ for namedroppers-data0@psg.com; Wed, 10 Jun 2009 03:15:01 +0000 Received: from [74.125.46.30] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEEH1-0003U1-4O for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 03:14:55 +0000 Received: by yw-out-2324.google.com with SMTP id 9so239182ywe.71 for ; Tue, 09 Jun 2009 20:14:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.49.3 with SMTP id w3mr689488agw.46.1244603685383; Tue, 09 Jun 2009 20:14:45 -0700 (PDT) In-Reply-To: <200906100254.n5A2s8cN012954@drugs.dv.isc.org> References: <200906100254.n5A2s8cN012954@drugs.dv.isc.org> Date: Tue, 9 Jun 2009 20:14:45 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: Mark Andrews 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: On Tue, Jun 9, 2009 at 7:54 PM, Mark Andrews wrote: >> Why do the root servers bother responding to caches that don't use >> EDNS0? > > =A0 =A0 =A0 =A0To not break legacy (no IPv6 transport support) software. Sorry, that was a rhetorical question in response to Jim Reid's absurd claim that software that doesn't support EDNS0 is "broken". > =A0 =A0 =A0 =A0Dropping additional records should not cause iterative > =A0 =A0 =A0 =A0nameservers to break. =A0If it does the software was not > =A0 =A0 =A0 =A0compliant in the first place. It doesn't cause dnscache to break, but it does cause it to do additional work and to add additional load on the root servers. Serving all A glue in preference to any AAAA records for IPv4 clients is a perfectly backwards compatible solution that solves this problem with no apparent disadvantages. > =A0 =A0 =A0 =A0Note: Some of the roots *are* configured to preference A > =A0 =A0 =A0 =A0records in the additional section. Ah, you're right. It's only {a,c,e,i,j}.root-servers.net that give AAAA records in preference to A records. Great, then there's only 5 left to fix. :) > This should not be > =A0 =A0 =A0 =A0needed for queries over IPv6 as EDNS support is manditory. > =A0 =A0 =A0 =A0See IPv6 node requirements. RFC 4294 (IPv6 Node Requirements) only says "All [IPv6] nodes [...] SHOULD implement stub-resolver [RFC-1034] functionality [...] with support for [...] EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 octets." Is there another RFC that says EDNS support is mandatory for IPv6 nodes? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 20:55:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033AC3A67D2; Tue, 9 Jun 2009 20:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 d+5LWYtbXRVF; Tue, 9 Jun 2009 20:55:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D85253A679C; Tue, 9 Jun 2009 20:54:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEEnB-00094v-VL for namedroppers-data0@psg.com; Wed, 10 Jun 2009 03:48:01 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEEmt-000932-Rx for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 03:47:54 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id EFA99E606F; Wed, 10 Jun 2009 03:47:42 +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 n5A3lUXh013734; Wed, 10 Jun 2009 13:47:40 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> To: Matthew Dempsky Cc: Mark Andrews , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients In-reply-to: Your message of "Tue, 09 Jun 2009 20:14:45 MST." Date: Wed, 10 Jun 2009 13:47:30 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Matth ew Dempsky writes: > On Tue, Jun 9, 2009 at 7:54 PM, Mark Andrews wrote: > >> Why do the root servers bother responding to caches that don't use > >> EDNS0? > > > > =A0 =A0 =A0 =A0To not break legacy (no IPv6 transport support) software. > > Sorry, that was a rhetorical question in response to Jim Reid's absurd > claim that software that doesn't support EDNS0 is "broken". > > > =A0 =A0 =A0 =A0Dropping additional records should not cause iterative > > =A0 =A0 =A0 =A0nameservers to break. =A0If it does the software was not > > =A0 =A0 =A0 =A0compliant in the first place. > > It doesn't cause dnscache to break, but it does cause it to do > additional work and to add additional load on the root servers. Well fix dnscache. The need for bigger UDP packets has been obvious for over 10 years now. If it slow stop complaining and get with the program. > Serving all A glue in preference to any AAAA records for IPv4 clients > is a perfectly backwards compatible solution that solves this problem > with no apparent disadvantages. > > > =A0 =A0 =A0 =A0Note: Some of the roots *are* configured to preference A > > =A0 =A0 =A0 =A0records in the additional section. > > Ah, you're right. It's only {a,c,e,i,j}.root-servers.net that give > AAAA records in preference to A records. > > Great, then there's only 5 left to fix. :) > > > This should not be > > =A0 =A0 =A0 =A0needed for queries over IPv6 as EDNS support is manditory. > > =A0 =A0 =A0 =A0See IPv6 node requirements. > > RFC 4294 (IPv6 Node Requirements) only says "All [IPv6] nodes [...] > SHOULD implement stub-resolver [RFC-1034] functionality [...] with > support for [...] EDNS0 [RFC-2671] to allow for DNS packet sizes > larger than 512 octets." Is there another RFC that says EDNS support > is mandatory for IPv6 nodes? If you choose to implement a iterative resolver instead of a stub resolver the need for EDNS doesn't change. A recursive nameserver is just a shared iterative resolver. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 21:08:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1273A67D2; Tue, 9 Jun 2009 21:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.382 X-Spam-Level: X-Spam-Status: No, score=-0.382 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOCkqrXwkufB; Tue, 9 Jun 2009 21:08:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F05703A67AD; Tue, 9 Jun 2009 21:08:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEEzE-000Azp-4h for namedroppers-data0@psg.com; Wed, 10 Jun 2009 04:00:28 +0000 Received: from [74.125.46.31] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEEz3-000Ax6-4e for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 04:00:22 +0000 Received: by yw-out-2324.google.com with SMTP id 9so251896ywe.71 for ; Tue, 09 Jun 2009 21:00:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.83.2 with SMTP id g2mr698859agb.114.1244606415332; Tue, 09 Jun 2009 21:00:15 -0700 (PDT) In-Reply-To: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> Date: Tue, 9 Jun 2009 21:00:15 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: Mark Andrews 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: On Tue, Jun 9, 2009 at 8:47 PM, Mark Andrews wrote: > =A0 =A0 =A0 =A0Well fix dnscache. Make up your mind: is it "broken" for a DNS cache to not use EDNS0? If so, then why not change the root servers to stop answering queries that don't use EDNS0? That will certainly encourage "broken" DNS cache administrators to fix their installations! :P If not, then why not change the 5 root servers in question to behave the same as the other 8? Give me a valid argument why the AAAA records should be preferred to the A records for an IPv4 client and I'll drop the issue. > =A0 =A0 =A0 =A0If you choose to implement a iterative resolver instead of > =A0 =A0 =A0 =A0a stub resolver the need for EDNS doesn't change. What "need"? The text I quoted is the only mention of "EDNS" in RFC 4294. What are you talking about? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 9 21:30:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC80D3A6B77; Tue, 9 Jun 2009 21:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-0.540, 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 sKAiEDmKOWTv; Tue, 9 Jun 2009 21:30:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB2F93A6A48; Tue, 9 Jun 2009 21:30:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEFNK-000FHX-Ni for namedroppers-data0@psg.com; Wed, 10 Jun 2009 04:25:22 +0000 Received: from [209.86.89.64] (helo=elasmtp-curtail.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEFN0-000FFf-P8 for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 04:25:15 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=EIVX21MkzcPjUBGoQ0MttIfnKt5P7JhSvrM0RQJrY5aWftUQq16p2jXzAtiIZBbO; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.103.18] (helo=ix.netcom.com) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MEFMx-0000gK-5j; Wed, 10 Jun 2009 00:25:00 -0400 Message-ID: <4A2F358A.B04A843D@ix.netcom.com> Date: Tue, 09 Jun 2009 21:24:42 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dempsky CC: Jim Reid , namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients References: <4D291F23-2937-4A13-A01D-9BD7630E7F32@rfc1035.com> <55D99BB7-1075-4A9C-90CE-BB5F4FD1805D@rfc1035.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688e88f502b9706a154c119bb5fa07978cb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.103.18 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Matt and all, Don't feel bad Matt, I am also in Jim's "Kill file". Such is life, ho hum... Me thinks that Jim although a smart fellow has an ego larger than his intelect. Matthew Dempsky wrote: > On Tue, Jun 9, 2009 at 4:11 PM, Jim Reid wrote: > > No you didn't. You gave an example of a broken implementation with a small > > percentage of the installed base. > > Guess what: the Internet is big! A "small percentage" is still a lot > of installations. > > I'm sorry if you think the Internet should only be used by BIND. > > > It's so broken it doesn't even support EDNS0. > > Since when is not sending DNS queries with EDNS0 considered "broken"? > Why do the root servers bother responding to caches that don't use > EDNS0? If you want to weed out "broken" software, why not encourage > the root and .com servers to stop responding to queries without EDNS0? > :P > > > Enough said. I have tried to apply clue. You have resisted those > > efforts. This discussion is over. > > > > Welcome to my kill file and goodbye. > > ohnoz! > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 02:58:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AEF63A6E21; Wed, 10 Jun 2009 02:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.548 X-Spam-Level: X-Spam-Status: No, score=-4.548 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzzglNk12ePS; Wed, 10 Jun 2009 02:58:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE2863A6DD8; Wed, 10 Jun 2009 02:58:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEKST-000KPQ-J1 for namedroppers-data0@psg.com; Wed, 10 Jun 2009 09:51:01 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEKSI-000KOW-RR for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 09:50:56 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5A9nitj016386; Wed, 10 Jun 2009 09:49:44 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5A9nhDP016385; Wed, 10 Jun 2009 09:49:43 GMT Date: Wed, 10 Jun 2009 09:49:43 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: Jim Reid , namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Message-ID: <20090610094943.GB15847@vacation.karoshi.com.> References: <4D291F23-2937-4A13-A01D-9BD7630E7F32@rfc1035.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: On Tue, Jun 09, 2009 at 04:03:02PM -0700, Matthew Dempsky wrote: > > So dropping > > stuff from the Additional Section is preferable to sending a truncated > > response and TCP retries. > > Fine, but if you're going to drop glue data, then drop the less useful > glue data. > er... "useful" - i'd be interested in learning how auth servers are supposed to be prescentient in "knowing" what the IMR is going to do with said glue. the one thing that we have done is to look at the transport that the query arrived on and shuffle glue for that transport to the head of the line... not ideal, but an attempt to "know" what is useful or not. Its not foolproof (fools being so clever) but it was a crack at not treating one transport as preferable over an other. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 03:01:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51333A6D77; Wed, 10 Jun 2009 03:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.545 X-Spam-Level: X-Spam-Status: No, score=-4.545 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nFJBEQD3o5U; Wed, 10 Jun 2009 03:01:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D9CA03A6B8F; Wed, 10 Jun 2009 03:01:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEKZL-000LnV-SK for namedroppers-data0@psg.com; Wed, 10 Jun 2009 09:58:07 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEKZB-000Lme-6o for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 09:58:02 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5A9totj016417; Wed, 10 Jun 2009 09:55:50 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5A9tohS016416; Wed, 10 Jun 2009 09:55:50 GMT Date: Wed, 10 Jun 2009 09:55:50 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Message-ID: <20090610095550.GC15847@vacation.karoshi.com.> References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> 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: On Tue, Jun 09, 2009 at 09:00:15PM -0700, Matthew Dempsky wrote: > If not, then why not change the 5 root servers in question to behave > the same as the other 8? Give me a valid argument why the AAAA > records should be preferred to the A records for an IPv4 client and > I'll drop the issue. the transport used by the IMR is not equivalent to the type of data being asked for - some of the time. if the IMR only has a v4 path to the auth server - and the IMR clients have v6 paths to the IMR, should not the IMR get some IPv6 data back from the auth server for its clients who need that data, even though the IMR only has a v4 transit path to the auth server? --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 05:38:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15193A6833; Wed, 10 Jun 2009 05:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTOJ32V01jeY; Wed, 10 Jun 2009 05:38:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE6733A67FB; Wed, 10 Jun 2009 05:38:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEMzc-000MlT-Ju for namedroppers-data0@psg.com; Wed, 10 Jun 2009 12:33:24 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEMzQ-000Mha-5V for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 12:33:18 +0000 Received: from guava.gson.org (nblzone-227-105.nblnetworks.fi [83.145.227.105]) by gurgel.gson.org (Postfix) with ESMTP id 37F617C91C; Wed, 10 Jun 2009 12:33:08 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 7D66C75F38; Wed, 10 Jun 2009 15:33:07 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18991.43011.153595.454259@guava.gson.org> Date: Wed, 10 Jun 2009 15:33:07 +0300 To: bmanning@vacation.karoshi.com Cc: Matthew Dempsky , Mark Andrews , namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients In-Reply-To: <20090610095550.GC15847@vacation.karoshi.com.> References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Andreas Gustafsson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bmanning@vacation.karoshi.com wrote: > On Tue, Jun 09, 2009 at 09:00:15PM -0700, Matthew Dempsky wrote: > > If not, then why not change the 5 root servers in question to behave > > the same as the other 8? Give me a valid argument why the AAAA > > records should be preferred to the A records for an IPv4 client and > > I'll drop the issue. > > the transport used by the IMR is not equivalent to the > type of data being asked for - some of the time. True, but irrelevant - we are talking about glue, which is not the data being asked for, but meta-data which is used only by the IMR itself. -- Andreas Gustafsson, gson@araneus.fi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 07:54:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8503A6C99; Wed, 10 Jun 2009 07:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=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 VSjZbzR16F3o; Wed, 10 Jun 2009 07:54:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E7C03A694E; Wed, 10 Jun 2009 07:54:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEP4F-000Las-Sp for namedroppers-data0@psg.com; Wed, 10 Jun 2009 14:46:19 +0000 Received: from [94.142.245.109] (helo=mx.pipe.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEP44-000LY8-Gd for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 14:46:14 +0000 Received: (qmail 16815 invoked by uid 80); 10 Jun 2009 14:45:51 -0000 Received: from 94.142.245.110 (SquirrelMail authenticated user bit@pipe.nl) by mx.pipe.nl with HTTP; Wed, 10 Jun 2009 16:45:51 +0200 (CEST) Message-ID: In-Reply-To: <200906081828.n58ISdRI019464@stora.ogud.com> References: <200905291557.n4TFv4ek030806@stora.ogud.com> <200906081828.n58ISdRI019464@stora.ogud.com> Date: Wed, 10 Jun 2009 16:45:51 +0200 (CEST) Subject: Re: Draft Charter v2. Re: [dnsext] Draft DNSEXT charter From: "Bart Smit" To: namedroppers@ops.ietf.org User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: (already sent to Olafur; forgot to cc the list) Olafur Gudmundsson wrote: > Milestones: > Jun 2009 TSIG/MD5 Obsoleting to IESG. > Jul 2009 RSA/SHA256 to IESG. > Jul 2009 AXFR Clarify to IESG. > Sep 2009 EDNS0 Ping Option advanced to IESG > Oct 2009 Resolver side Forgery Resilience advanced to IESG > Oct 2009 DNSSEC Errata document to IESG > Nov 2009 GOST DNSKEY and DS support advanced to IESG > Dec 2009 EDNS0-bis update advanced to IESG > Feb 2010 DNS existing transport protocol > recommendations/clarifications to IESG > Jun 2010 DNS transport protocol specification Does putting EDNS0 Ping on the list of milestones imply that draft-hubert-ulevitch-edns-ping will be adopted as a wg doc? If not, what's holding back adoption? Also, do we have any indication that Bert is still willing to author it, despite having withdrawn his request? Bart -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 08:25:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031133A694E; Wed, 10 Jun 2009 08:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.195 X-Spam-Level: X-Spam-Status: No, score=-8.195 tagged_above=-999 required=5 tests=[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 kbV6LvFlzvc5; Wed, 10 Jun 2009 08:25:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E4A13A68D9; Wed, 10 Jun 2009 08:25:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEPbE-0000Zl-0g for namedroppers-data0@psg.com; Wed, 10 Jun 2009 15:20:24 +0000 Received: from [207.171.7.208] (helo=x8.develooper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEPb2-0000Xm-Vd for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 15:20:18 +0000 Received: (qmail 23177 invoked from network); 10 Jun 2009 15:20:10 -0000 Received: from gw.develooper.com (HELO embla.bn.dev) (ask@mail.dev@64.81.84.140) by smtp.develooper.com with ESMTPA; 10 Jun 2009 15:20:10 -0000 Cc: Matthew Dempsky , Jim Reid , namedroppers@ops.ietf.org Message-Id: <9E10E125-4953-4095-89FD-D68B357D1CAD@develooper.com> From: =?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= To: bmanning@vacation.karoshi.com In-Reply-To: <20090610094943.GB15847@vacation.karoshi.com.> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Date: Wed, 10 Jun 2009 08:20:09 -0700 References: <4D291F23-2937-4A13-A01D-9BD7630E7F32@rfc1035.com> <20090610094943.GB15847@vacation.karoshi.com.> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 10, 2009, at 2:49, bmanning@vacation.karoshi.com wrote: > er... "useful" - i'd be interested in learning how auth servers > are supposed to be prescentient in "knowing" what the IMR is going > to do with said glue. If I understand it right then Matthew is saying that IPv6 IMR's will use EDNS0 anyway, so pretty much by definition the A records are going to be the useful ones to non-EDNS0 requestors. - ask -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 08:28:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF69828C1C0; Wed, 10 Jun 2009 08:28:54 -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=-1.208, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnrGCQ3Et3u2; Wed, 10 Jun 2009 08:28:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 30FB13A694E; Wed, 10 Jun 2009 08:28:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEPfd-0001JF-F6 for namedroppers-data0@psg.com; Wed, 10 Jun 2009 15:24:57 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEPfS-0001E8-9p for namedroppers@psg.com; Wed, 10 Jun 2009 15:24:51 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D47EB2FE9622 for ; Wed, 10 Jun 2009 15:24:29 +0000 (UTC) Date: Wed, 10 Jun 2009 11:24:27 -0400 From: Andrew Sullivan To: namedroppers@psg.com Subject: Re: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" Message-ID: <20090610152427.GB33231@shinkuro.com> References: <200906092049.n59Kn2eq034140@stora.ogud.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: [Chair hat on] Dear colleagues, I am hanging my message on the interchange between two participants, but this is an instance of metonymy. I am not encouranging that we divide into "camps", but trying to illustrate a spectrum of options. On Tue, Jun 09, 2009 at 05:43:27PM -0400, Edward Lewis wrote: > At 16:48 -0400 6/9/09, Olafur Gudmundsson wrote: > >> We do not want to encourage "Vanity" algorithms, there should be a good >> reason for adopting new algorithms. Having said that I think the next >> algorithm we adopt (after RSA/SHA256) ought to be an Elliptic Curve >> algorithm. Followed by the phasing out of DSA. > > I disagree with the previous paragraph. For one, what is a "vanity" > algorithm? And what is a "good reason" to adopt? I think the flaw in > the logic above it that the choice of cryptographic system is not > strictly a technical decision. There are other factors involved, > whether the factors run counter to an engineer's sensibilities or not. […] > I don't think it is up to the DNS Extensions WG to dictate policy > regarding the use of cryptography. I wish to draw the WG's attention to the above difference of opinion, and encourage participants to come to some workable compromise about the issue, assuming the WG decides to go ahead with the proposed new charter (or something like it). If we are going to take on maintenance work for DNSSEC algorithms, then we might like to have some principles (I am reluctant to establish "rules" this early in the process) upon which we will base the decision to take a given maintenance action. At one end of a spectrum of principles is something like the one Olafur outlines (and with which, I suspect, Sam is in agreement): no action unless there's some compelling reason, with a high barrier to algorithm ID assignment. The other end of the spectrum is something like the one Ed (and, I think, Paul Hoffman) suggests: it's none of our business what people want to do with this stuff, and unless there's a compelling reason _not_ to hand out an assignment, we ought to allow them to go ahead. There are some related issues, but I'd like to focus on the above dichotomy for a moment. If we work under a charter that makes us responsible for the algorithm number assignments, then we do two things: 1. We undertake to look after "the interests" of the DNSSEC algorithm space under the DNSSEC parts of the DNS protocol. 2. We undertake to look after "the interests" of the wider Internet community with respect to DNSSEC and algorithm number assignments. It is plain that these two undertakings are not automatically in harmony (although one can of course construct an argument about how they converge in the long run). Therefore, I think it would be beneficial if we thought hard about the tension between those two tasks, and try to expose the ways in which they can be broadly reconciled. An alternative, of course, is to refuse to change the charter specifically to include DNSSEC algorithm maintenance. It isn't clear to me what the effect of that would be, however, since the existing charter in any case makes us responsible for DNS maintenance in general, and DNSSEC algorithms would seem to fall under that category. If you have an opinion on where on the spectrum of principles the WG ought to fall, I think it would be good to hear about it. These expressions might also be helpful to the rest of the IETF in evaluating our proposed new charter. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 08:50:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7B83A6C31; Wed, 10 Jun 2009 08:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuWaX0fCBieJ; Wed, 10 Jun 2009 08:50:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E26BA3A6831; Wed, 10 Jun 2009 08:50:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEPzN-0004IG-28 for namedroppers-data0@psg.com; Wed, 10 Jun 2009 15:45:21 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEPz9-0004DD-0t for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 15:45:12 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E2E792FE9622 for ; Wed, 10 Jun 2009 15:44:50 +0000 (UTC) Date: Wed, 10 Jun 2009 11:44:49 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Message-ID: <20090610154448.GE33231@shinkuro.com> References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> 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: [no hat] On Tue, Jun 09, 2009 at 09:00:15PM -0700, Matthew Dempsky wrote: > If not, then why not change the 5 root servers in question to behave > the same as the other 8? Give me a valid argument why the AAAA > records should be preferred to the A records for an IPv4 client and > I'll drop the issue. You have the burden of proof the wrong way. One would need a valid argument (and not incidentally, true conclusion -- they're not the same thing) that a DNS server should prefer A records to AAAA records in the additional section when talking over IPv4 transit. As Bill Manning points out, there is no strong link between the network from which one is querying and the network that one ultimately wants to use. Second, there is reason to suppose that different behaviour on the part of different servers might be desirable, since this could be the result of different implementations or different code paths in the same implementation. Third, given the v4-v6 interoperation work currently being undertaken in other working groups (such as BEHAVE), I think there is considerable reason to be sceptical that tying the things in the additional section to the network whence the query arrived is a good idea. For all we know, it might be that someone is somewhere using the existence of AAAA records in the additional section as a clue that the v6 network might be worth trying. If so, I don't want to discourage such people. Best regards, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From emittingauy746@oceandrive.com Wed Jun 10 08:57:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90ADA28C130; Wed, 10 Jun 2009 08:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.503 X-Spam-Level: X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=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, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uMB20-b472U; Wed, 10 Jun 2009 08:57:02 -0700 (PDT) Received: from r190-135-178-110.dialup.adsl.anteldata.net.uy (r190-135-178-110.dialup.adsl.anteldata.net.uy [190.135.178.110]) by core3.amsl.com (Postfix) with ESMTP id 137B13A6BA6; Wed, 10 Jun 2009 08:57:01 -0700 (PDT) Message-ID: <000d01c9e9e3$fc19b140$6400a8c0@emittingauy746> From: dnsext-archive@lists.ietf.org To: Subject: Your Acai Berry free trial is waiting for you. Date: Wed, 10 Jun 2009 17:56:15 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9E9E3.FC19B140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9E9E3.FC19B140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable View online version here: here =20 =20 =20 =20 =20 =20 June=20 10, 2009 =20 =20 =20 =20 Sign up Forward Archive Advertise =20 =20 =20 =20 Lose weight faster and easier than ever Acai Berry.=20 visit our store =20  This=20 Newsletter was created for dnsext-archive@lists.ietf.org =20 =20 =20 =20 =20 =20 =20 Subscriber=20 Tools =20 Update=A0account=A0information=A0|=20 Change=A0e-mail=A0address=A0| Unsubscribe=A0| Print=A0fri= endly=A0format=A0| Web=A0version=A0 =20 ¿=20 1999-2009 Qsofo, Inc.=AE=A0Legal=20 Information =A0 ------=_NextPart_000_0007_01C9E9E3.FC19B140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable View online version here: here

June=20 10, 2009 Sign up Forward Archive Advertise
Lose weight faster and easie= r than ever Acai Berry.
visit our store=
 This=20 Newsletter was created for dnsext-archive@lists.ietf.org Subscriber=20 Tools
¿=20 1999-2009 Qsofo, Inc.=AE=A0Legal=20 Information
Update=A0account=A0information=A0|=20 Change=A0e-mail=A0address=A0| Unsubscribe=A0| Print=A0friendly=A0format=A0| Web=A0version=A0
=A0
------=_NextPart_000_0007_01C9E9E3.FC19B140-- From owner-namedroppers@ops.ietf.org Wed Jun 10 08:57:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8743A6BA6; Wed, 10 Jun 2009 08:57:50 -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 yeSlWwp0Vq93; Wed, 10 Jun 2009 08:57:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7647F3A6A02; Wed, 10 Jun 2009 08:57:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEQ7X-0005X5-5J for namedroppers-data0@psg.com; Wed, 10 Jun 2009 15:53:47 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEQ7L-0005UU-UU for namedroppers@psg.com; Wed, 10 Jun 2009 15:53:41 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id E7A92C2DA3; Wed, 10 Jun 2009 16:53:17 +0100 (BST) Date: Wed, 10 Jun 2009 16:52:22 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Andrew Sullivan , namedroppers@psg.com cc: Alex Bligh Subject: Re: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" Message-ID: <5C1555AAE6CD361555B428F9@Ximines.local> In-Reply-To: <20090610152427.GB33231@shinkuro.com> References: <200906092049.n59Kn2eq034140@stora.ogud.com> <20090610152427.GB33231@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: --On 10 June 2009 11:24:27 -0400 Andrew Sullivan wrote: > An alternative, of course, is to refuse to change the charter > specifically to include DNSSEC algorithm maintenance. It isn't clear > to me what the effect of that would be, however, since the existing > charter in any case makes us responsible for DNS maintenance in > general, and DNSSEC algorithms would seem to fall under that category. Apologies if I have missed this and it has been said before, but I think there is a qualitative difference between: a) maintaining algorithm registries used in an environment where support of those algorithms is optional and can be negotiated between sender and receiver; and b) maintaining algorithm registries where it makes support of an algorithm is in effect compulsory (i.e. if they are not supported by one party, there will be interoperability problems e.g. because of lack of algorithm negotiation). For algorithm registries falling into camp (a), provided the use is by some measure sensible, and subject to Bill's (I think) comments about every registry we think is inexhaustible actually coming close to exhaustion after a few years, I think there should in general be an open minded approach to handing out entries. For algorithm registries falling into camp (b), the hurdle must be set higher. It is not simply a technical evaluation of the merits of one algorithm in isolation. We also need to be concerned about implementation bloat (as in effect every implementation needs to support every algorithm), and far more careful about IPR burdened algorithms, for instance. There may also be shades of grey in between. This is not a statement about the GOST application, but a general statement. -- Alex Bligh -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 09:07:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439603A6C67; Wed, 10 Jun 2009 09:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[AWL=-0.570, 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 ABZqSpZmSTQW; Wed, 10 Jun 2009 09:07:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EAEA03A6C31; Wed, 10 Jun 2009 09:07:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEQHA-00075I-Oi for namedroppers-data0@psg.com; Wed, 10 Jun 2009 16:03:44 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEQGy-00070n-55 for namedroppers@psg.com; Wed, 10 Jun 2009 16:03:38 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5AG3FrY045719; Wed, 10 Jun 2009 12:03:15 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906101603.n5AG3FrY045719@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 10 Jun 2009 12:02:36 -0400 To: Paul Hoffman , namedroppers@psg.com From: Olafur Gudmundsson Subject: Re: [dnsext] Proposal to make DNSSEC Algorithm Types be "RFC required" In-Reply-To: References: <200906092049.n59Kn2eq034140@stora.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 18:20 09/06/2009, Paul Hoffman wrote: >At 4:48 PM -0400 6/9/09, Olafur Gudmundsson wrote: > >DNS is an important infrastructure protocol, if it stops working > >other things fail. For that reason until something in shown to be > >HARMLESS we have standards action controlling admission. > >Does this means that you are against the current SHA-256 document, >which cannot be shown to be harmless? You have supported it in the >recent past. We *know* that SHA-256 will get worse over time, and >will need to have a transition away from it. Why the contradiction? If I had not been chair of the WG I would have argued against it and told people to wait until the new generation of digest algorithms is available. WG can still kill it if knowledgeable people make arguments that it is not needed or is harmful. IESG may reject it as well if they do not like it. > >In DNS there is no handshake between "client" and "original > server" to negotiate > >the algorithm to use, either the client understands the "broadcast" > >RRSIG or it does not. For this reason keeping the list of algorithms that > >"clients" need to understand small is an interoperabilty advantage. > >We fully agree. But that statement is irrelevant to whether or not >an algorithm needs to be on standards track. No system needs to >implement all standards track documents, as we all know. While your last statement is in theory true. In reality it is not, implementations either have policies like "We implement all DNS RFC's" (this is the case of Nominum, ISC and NLnetLabs). If they did not there are still going to be customers that say "I need algorithm X implement it" and if that is a paying customer it is hard to say no. > >It takes much longer to upgrade installed software base than the > >glacial phase of draft progressing through the working group + IESG, > >thus the speed of allocation argument is not a compelling one. > >If someone wants to experiment the private name spaces alg=253 and 254 > >are available. The private spaces IMHO are not suitable for production use. > >Section A.1.1 of RFC 4034 makes it quite clear that they are >intended for production use. I think we need to define what production means, you can use a Private algorithm in your in house network and that is "in production", what I meant was in "full Internet use". I do not read A.1.1 to mean full Internet use nor does it say "experiment only". All it does say is "if you understand this number then the next field is going to be an identifier of this type, If you support that identifier you know how to parse the key" > >We do not want to encourage "Vanity" algorithms, there should be a good > >reason for adopting new algorithms. > >Fully agree. (glad there is something we agree on :-) ) > >Due to the transport used by DNS we do not want to encourage/require > >zones to use multiple DNSKEY algorithms to sign their zone. In > >general only during transition from one algorithm to another should zone > >be signed by multiple algorithms. > >The more algorithms used ==> more signatures on each RRset ==> > larger answers. > >Quite right. However, that is also irrelevant to whether or not >something needs to be on standards track. Please give me any other reasons than "ease of registration" or "number space is large no need to worry" for relaxing the requirement. > >In the history of systems with "finite" number spaces we have a history of > >running out of the space no matter how large the early adopters > thought the space > >was. Remember IPv4 addresses, DHCP option space, AS numbers, > original Icelandic > >tax id numbers [1], etc. etc. The moral is be conservative in allocations OR > >before allocations are opened up have a reuse plan in place. > >As Sam Weiler pointed out, we already have one: Section A.1.1 of RFC >4034. You might change your view on whether or not that is suitable >for production use (if we ever get there). Actually it is A.1 that contains the possible escape hatch (algorithm 0 or 255) I hope that DNS is obsoleted before we need to worry about using the escape hatch. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 09:16:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525913A6C67; Wed, 10 Jun 2009 09:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dk5uYaQVYav5; Wed, 10 Jun 2009 09:16:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6ACD13A6A02; Wed, 10 Jun 2009 09:16:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEQQ4-0008ig-62 for namedroppers-data0@psg.com; Wed, 10 Jun 2009 16:12:56 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEQPI-0008XR-I6 for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 16:12:36 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5AGBq9X045831; Wed, 10 Jun 2009 12:11:52 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906101611.n5AGBq9X045831@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 10 Jun 2009 12:11:13 -0400 To: "Bart Smit" , namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: Draft Charter v2. Re: [dnsext] Draft DNSEXT charter In-Reply-To: References: <200905291557.n4TFv4ek030806@stora.ogud.com> <200906081828.n58ISdRI019464@stora.ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 10:45 10/06/2009, Bart Smit wrote: >(already sent to Olafur; forgot to cc the list) > >Olafur Gudmundsson wrote: > > > Milestones: > > Jun 2009 TSIG/MD5 Obsoleting to IESG. > > Jul 2009 RSA/SHA256 to IESG. > > Jul 2009 AXFR Clarify to IESG. > > Sep 2009 EDNS0 Ping Option advanced to IESG > > Oct 2009 Resolver side Forgery Resilience advanced to IESG > > Oct 2009 DNSSEC Errata document to IESG > > Nov 2009 GOST DNSKEY and DS support advanced to IESG > > Dec 2009 EDNS0-bis update advanced to IESG > > Feb 2010 DNS existing transport protocol > > recommendations/clarifications to IESG > > Jun 2010 DNS transport protocol specification > >Does putting EDNS0 Ping on the list of milestones imply that >draft-hubert-ulevitch-edns-ping will be adopted as a wg doc? If not, >what's holding back adoption? Also, do we have any indication that Bert is >still willing to author it, despite having withdrawn his request? > >Bart As I have said before. There is enough support in the WG to adopt the work, there is disagreement on if this is useful or not. ==> WG will adopt the document after it is updated have one more round of discussion and then dispose of the document (as someone asked dispose == advance or kill). David Ulevitch has agreed to hold the editing token. As Bert does not hold any IPR on this idea, the form of his participation is immaterial, what matters is the idea not the people proposing it. Once a document is formally adopted the editor of the document is supposed to reflect the will of the working group, also editors serve at the "pleasure" of the chairs. The milestone is there to remind chairs to get the documents done. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 10:04:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF5D428C239; Wed, 10 Jun 2009 10:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.627 X-Spam-Level: * X-Spam-Status: No, score=1.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, J_CHICKENPOX_45=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 A2gwDIOshoPp; Wed, 10 Jun 2009 10:04:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8FFB43A6B86; Wed, 10 Jun 2009 10:04:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MER91-000GRz-4m for namedroppers-data0@psg.com; Wed, 10 Jun 2009 16:59:23 +0000 Received: from [209.85.220.205] (helo=mail-fx0-f205.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MER7x-000G2c-Mc for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 16:58:51 +0000 Received: by fxm1 with SMTP id 1so1000377fxm.41 for ; Wed, 10 Jun 2009 09:58:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.126.69 with SMTP id b5mr1424337fas.54.1244653080055; Wed, 10 Jun 2009 09:58:00 -0700 (PDT) In-Reply-To: <18991.43011.153595.454259@guava.gson.org> References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Date: Wed, 10 Jun 2009 18:57:37 +0200 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients To: Andreas Gustafsson Cc: bmanning@vacation.karoshi.com, Matthew Dempsky , Mark Andrews , 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: On Wed, Jun 10, 2009 at 2:33 PM, Andreas Gustafsson wrote: > bmanning@vacation.karoshi.com wrote: >> On Tue, Jun 09, 2009 at 09:00:15PM -0700, Matthew Dempsky wrote: >> > If not, then why not change the 5 root servers in question to behave >> > the same as the other 8? =C2=A0Give me a valid argument why the AAAA >> > records should be preferred to the A records for an IPv4 client and >> > I'll drop the issue. >> >> =C2=A0 =C2=A0 =C2=A0 the transport used by the IMR is not equivalent to = the >> =C2=A0 =C2=A0 =C2=A0 type of data being asked for - some of the time. > > True, but irrelevant - we are talking about glue, which is not the > data being asked for, but meta-data which is used only by the IMR > itself. Asking over IPv4 doesn't imply you are not IPv6 capable. It could just be outdate root.hints file. Also the asking side could have different strategies which IP protocols to use first when dual stacked. So Bill is right. Ondrej --=20 Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 10:26:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55F143A6B45; Wed, 10 Jun 2009 10:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.277 X-Spam-Level: X-Spam-Status: No, score=0.277 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVkBhiq0c4db; Wed, 10 Jun 2009 10:26:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 58BA53A6A24; Wed, 10 Jun 2009 10:26:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MERUG-000Jru-BI for namedroppers-data0@psg.com; Wed, 10 Jun 2009 17:21:20 +0000 Received: from [209.85.132.242] (helo=an-out-0708.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MERU5-000Jpr-Dm for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 17:21:14 +0000 Received: by an-out-0708.google.com with SMTP id d14so461716and.26 for ; Wed, 10 Jun 2009 10:20:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.144.14 with SMTP id r14mr1601897and.65.1244654453526; Wed, 10 Jun 2009 10:20:53 -0700 (PDT) In-Reply-To: References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> Date: Wed, 10 Jun 2009 10:20:53 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= Cc: Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , 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: On Wed, Jun 10, 2009 at 9:57 AM, Ond=F8ej Sur=FD wrote: > Asking over IPv4 doesn't imply you are not IPv6 capable. There are two sets of resolvers that will contact the root servers over IPv4: IPv4-only resolvers and dual-stack IPv4/IPv6 resolvers. A records are useful to both sets of resolvers, whereas AAAA records are only useful to the second set. Mark Andrews has already pointed out that IPv6 nodes SHOULD* support EDNS0, so these resolvers will be able to get all A and AAAA glue by advertising a larger buffer size. Serving A records in preference to AAAA records for queries over IPv4 avoids causing legacy resolvers to have to send additional queries to the root servers. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 10:30:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758A23A6B44; Wed, 10 Jun 2009 10:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.314 X-Spam-Level: X-Spam-Status: No, score=0.314 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bor4J1EcxRn; Wed, 10 Jun 2009 10:30:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 76B793A68A7; Wed, 10 Jun 2009 10:30:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MERZY-000Km9-MZ for namedroppers-data0@psg.com; Wed, 10 Jun 2009 17:26:48 +0000 Received: from [209.85.217.220] (helo=mail-gx0-f220.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MERZN-000Kh5-VZ for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 17:26:43 +0000 Received: by gxk20 with SMTP id 20so1375867gxk.17 for ; Wed, 10 Jun 2009 10:26:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.25.7 with SMTP id 7mr1308467agy.21.1244654781060; Wed, 10 Jun 2009 10:26:21 -0700 (PDT) In-Reply-To: References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> Date: Wed, 10 Jun 2009 10:26:21 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= Cc: Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: 2009/6/10 Matthew Dempsky : > Mark Andrews has already pointed out that IPv6 nodes SHOULD* support > EDNS0, * Mark actually claimed EDNS support is "mandatory" for IPv6 nodes, but the IPv6 Node Requirements RFC only states IPv6 nodes SHOULD support EDNS0. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 10:53:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214023A6C0D; Wed, 10 Jun 2009 10:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIc+9YC9neHf; Wed, 10 Jun 2009 10:53:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 31A673A67EB; Wed, 10 Jun 2009 10:53:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MERuF-000O4O-VW for namedroppers-data0@psg.com; Wed, 10 Jun 2009 17:48:11 +0000 Received: from [74.125.46.30] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MERu4-000O3d-TZ for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 17:48:06 +0000 Received: by yw-out-2324.google.com with SMTP id 9so475169ywe.71 for ; Wed, 10 Jun 2009 10:48:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.205.15 with SMTP id c15mr1689636ang.5.1244656079885; Wed, 10 Jun 2009 10:47:59 -0700 (PDT) In-Reply-To: <20090610154448.GE33231@shinkuro.com> References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610154448.GE33231@shinkuro.com> Date: Wed, 10 Jun 2009 10:47:59 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky 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: On Wed, Jun 10, 2009 at 8:44 AM, Andrew Sullivan wrote: > You have the burden of proof the wrong way. I already gave a concrete example of existing software that is adversely affected by the behavior of these five root servers, resulting in increased load on all of them. As of yet, no one has given a good justification to why AAAA glue records over A glue records in response to queries not using EDNS0 and sent over IPv4. >=A0As Bill > Manning points out, there is no strong link between the network from > which one is querying and the network that one ultimately wants to > use. According to RFC 4294, an IPv6 node SHOULD support EDNS0. In this case, the larger buffer size will be able to handle the complete set of A and AAAA records, and choose however it wants among all of the record types. In the event that an IPv6 node does not support EDNS0 and contacts one of the IPv4 root servers instead of one of the IPv6 root servers, it seems reasonable to give it A records instead of AAAA records. > Second, there is reason to suppose that different behaviour on the > part of different servers might be desirable, since this could be the > result of different implementations or different code paths in the > same implementation. I don't follow how that makes it "desirable". > Third, given the v4-v6 interoperation work currently being undertaken > in other working groups (such as BEHAVE), I think there is > considerable reason to be sceptical that tying the things in the > additional section to the network whence the query arrived is a good > idea. =A0For all we know, it might be that someone is somewhere using > the existence of AAAA records in the additional section as a clue that > the v6 network might be worth trying. =A0If so, I don't want to > discourage such people. Can you elaborate on this point? I don't follow what problem the client is trying to solve. Do you have a concrete example of software that does this? If not, is there a reason you want the root servers to favor a hypothetical IPv6 node that doesn't support EDNS0 and has some peculiar non-standard behavior in preference to existing software that is standards conforming? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 10:53:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3FD23A67EB; Wed, 10 Jun 2009 10:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.281 X-Spam-Level: X-Spam-Status: No, score=-5.281 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 FzL8dY6pNzDz; Wed, 10 Jun 2009 10:53:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D0093A6BE1; Wed, 10 Jun 2009 10:53:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MERvb-000OJZ-3c for namedroppers-data0@psg.com; Wed, 10 Jun 2009 17:49:35 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MERvQ-000OG1-6u for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 17:49:29 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5AHmhaw015137; Wed, 10 Jun 2009 10:48:43 -0700 (PDT) Cc: Nicholas Weaver , =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= , Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , namedroppers@ops.ietf.org Message-Id: <0AF3DC17-3EB7-4493-B96F-7F87E474EF02@icsi.berkeley.edu> From: Nicholas Weaver To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Date: Wed, 10 Jun 2009 10:48:42 -0700 References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 10, 2009, at 10:20 AM, Matthew Dempsky wrote: > On Wed, Jun 10, 2009 at 9:57 AM, Ond=F8ej Sur=FD =20= > wrote: >> Asking over IPv4 doesn't imply you are not IPv6 capable. > > There are two sets of resolvers that will contact the root servers > over IPv4: IPv4-only resolvers and dual-stack IPv4/IPv6 resolvers. A > records are useful to both sets of resolvers, whereas AAAA records are > only useful to the second set. > > Mark Andrews has already pointed out that IPv6 nodes SHOULD* support > EDNS0, so these resolvers will be able to get all A and AAAA glue by > advertising a larger buffer size. Serving A records in preference to > AAAA records for queries over IPv4 avoids causing legacy resolvers to > have to send additional queries to the root servers. Stupid question: So what? IT only affects a trivial fraction of resolvers, and its getting items =20= that have very long TTLs, so I don't see why the additional queries =20 really matter at all? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 11:01:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF4CE3A6A3C; Wed, 10 Jun 2009 11:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.187 X-Spam-Level: X-Spam-Status: No, score=0.187 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HC1NsTVrvo4n; Wed, 10 Jun 2009 11:01:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 327623A6B3D; Wed, 10 Jun 2009 11:01:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MES1j-000P6j-QX for namedroppers-data0@psg.com; Wed, 10 Jun 2009 17:55:55 +0000 Received: from [209.85.217.220] (helo=mail-gx0-f220.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MES1Z-000P3g-2l for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 17:55:50 +0000 Received: by gxk20 with SMTP id 20so1410258gxk.17 for ; Wed, 10 Jun 2009 10:55:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.79.17 with SMTP id c17mr1333543agb.12.1244656527984; Wed, 10 Jun 2009 10:55:27 -0700 (PDT) In-Reply-To: <0AF3DC17-3EB7-4493-B96F-7F87E474EF02@icsi.berkeley.edu> References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> <0AF3DC17-3EB7-4493-B96F-7F87E474EF02@icsi.berkeley.edu> Date: Wed, 10 Jun 2009 10:55:27 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: Nicholas Weaver Cc: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= , Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: 2009/6/10 Nicholas Weaver : > Stupid question: So what? > > IT only affects a trivial fraction of resolvers, and its getting items that > have very long TTLs, so I don't see why the additional queries really matter > at all? Because it's a simple enough problem to fix. If people are going to insist that caches always talk to the root servers rather than using a local copy of the root zone, I think those same people should also be interested in making sure the root servers behave optimally for all caches. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 11:01:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7343A6B3D; Wed, 10 Jun 2009 11:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.177 X-Spam-Level: X-Spam-Status: No, score=0.177 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03ur74f24pXb; Wed, 10 Jun 2009 11:01:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B80043A6A3C; Wed, 10 Jun 2009 11:01:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MES3O-000PHD-3p for namedroppers-data0@psg.com; Wed, 10 Jun 2009 17:57:38 +0000 Received: from [209.85.210.185] (helo=mail-yx0-f185.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MES37-000PDY-Bq for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 17:57:29 +0000 Received: by yxe15 with SMTP id 15so184652yxe.5 for ; Wed, 10 Jun 2009 10:57:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.90.4 with SMTP id n4mr761654agb.69.1244656625311; Wed, 10 Jun 2009 10:57:05 -0700 (PDT) In-Reply-To: <20090610094943.GB15847@vacation.karoshi.com.> References: <4D291F23-2937-4A13-A01D-9BD7630E7F32@rfc1035.com> <20090610094943.GB15847@vacation.karoshi.com.> Date: Wed, 10 Jun 2009 10:57:05 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: bmanning@vacation.karoshi.com Cc: Jim Reid , 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: On Wed, Jun 10, 2009 at 2:49 AM, wrote: > =A0 =A0 =A0 =A0er... =A0"useful" - i'd be interested in learning how auth= servers > =A0 =A0 =A0 =A0are supposed to be prescentient in "knowing" what the IMR = is going > =A0 =A0 =A0 =A0to do with said glue. It's a pretty reasonable guess that if I send a "A? www.example.net" query to a root server and it responds with a delegation to the .net servers, that I'm going to repeat my query to them. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 11:06:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79C63A6BE1; Wed, 10 Jun 2009 11:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.26 X-Spam-Level: X-Spam-Status: No, score=-5.26 tagged_above=-999 required=5 tests=[AWL=-0.212, 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 TEm3b5tVLgKD; Wed, 10 Jun 2009 11:06:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 028473A6AFE; Wed, 10 Jun 2009 11:06:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MES6m-0000DN-2e for namedroppers-data0@psg.com; Wed, 10 Jun 2009 18:01:08 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MES6b-0000Bu-2W for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 18:01:02 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5AI0iHl017223; Wed, 10 Jun 2009 11:00:44 -0700 (PDT) Cc: Nicholas Weaver , =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= , Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Date: Wed, 10 Jun 2009 11:00:44 -0700 References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> <0AF3DC17-3EB7-4493-B96F-7F87E474EF02@icsi.berkeley.edu> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 10, 2009, at 10:55 AM, Matthew Dempsky wrote: > 2009/6/10 Nicholas Weaver : >> Stupid question: So what? >> >> IT only affects a trivial fraction of resolvers, and its getting >> items that >> have very long TTLs, so I don't see why the additional queries >> really matter >> at all? > > Because it's a simple enough problem to fix. If people are going to > insist that caches always talk to the root servers rather than using a > local copy of the root zone, I think those same people should also be > interested in making sure the root servers behave optimally for all > caches. Again, why? A few arguably broken resolvers (why fetch ALL the A records for everything always before proceeding?) have one extra name lookup to the root one in a while? Why should the root servers be changed to accomadate such broken behavior? The amount of impact on the root servers themselves is trivial, and the impact on even the arguably broken resolvers is trivial (one extra RTT for looking up a TLD not yet in the cache?). Why change working code? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 11:06:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14763A683A; Wed, 10 Jun 2009 11:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 DTV4dX9qYj4L; Wed, 10 Jun 2009 11:06:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C895F3A67EB; Wed, 10 Jun 2009 11:06:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MES96-0000eZ-Ph for namedroppers-data0@psg.com; Wed, 10 Jun 2009 18:03:32 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MES8v-0000Zt-P0 for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 18:03:27 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5AI3Iag058481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2009 11:03:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> Date: Wed, 10 Jun 2009 11:03:15 -0700 To: Matthew Dempsky From: Paul Hoffman Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 10:20 AM -0700 6/10/09, Matthew Dempsky wrote: >On Wed, Jun 10, 2009 at 9:57 AM, OndÞej Sur˜ wrote: >> Asking over IPv4 doesn't imply you are not IPv6 capable. > >There are two sets of resolvers that will contact the root servers >over IPv4: IPv4-only resolvers and dual-stack IPv4/IPv6 resolvers. A >records are useful to both sets of resolvers, whereas AAAA records are >only useful to the second set. Say what? I have a V6 host, and I'm using my ISP as my namesever; this is a completely typical set up. The fact that my ISP's box is V4-only is completely unrelated to my queries to it, and its queries to the outside world. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 11:11:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88C73A6B4A; Wed, 10 Jun 2009 11:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.255 X-Spam-Level: X-Spam-Status: No, score=-0.255 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuGGRLFEiudQ; Wed, 10 Jun 2009 11:11:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E831D3A683A; Wed, 10 Jun 2009 11:11:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESCp-0001C4-Mu for namedroppers-data0@psg.com; Wed, 10 Jun 2009 18:07:23 +0000 Received: from [74.125.46.29] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESCe-00019P-Tt for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 18:07:18 +0000 Received: by yw-out-2324.google.com with SMTP id 9so481250ywe.71 for ; Wed, 10 Jun 2009 11:07:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.90.4 with SMTP id n4mr768884agb.69.1244657231548; Wed, 10 Jun 2009 11:07:11 -0700 (PDT) In-Reply-To: References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> <0AF3DC17-3EB7-4493-B96F-7F87E474EF02@icsi.berkeley.edu> Date: Wed, 10 Jun 2009 11:07:10 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: Nicholas Weaver Cc: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= , Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 10, 2009 at 11:00 AM, Nicholas Weaver wrote: > A few arguably broken resolvers Sorry, what RFC says the behavior is broken? > (why fetch ALL the A records for everything > always before proceeding?) How/when else should dnscache find out m.gtld-server.net's A records? Or should it just never contact it then? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 11:12:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E1783A6BFF; Wed, 10 Jun 2009 11:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.212 X-Spam-Level: X-Spam-Status: No, score=-0.212 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKjqqFx7Hoc8; Wed, 10 Jun 2009 11:12:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 34F433A683A; Wed, 10 Jun 2009 11:12:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESEq-0001WF-Ix for namedroppers-data0@psg.com; Wed, 10 Jun 2009 18:09:28 +0000 Received: from [74.125.46.28] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESEf-0001S5-Gu for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 18:09:22 +0000 Received: by yw-out-2324.google.com with SMTP id 9so481918ywe.71 for ; Wed, 10 Jun 2009 11:09:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.96.12 with SMTP id t12mr1713331anb.4.1244657355603; Wed, 10 Jun 2009 11:09:15 -0700 (PDT) In-Reply-To: References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> Date: Wed, 10 Jun 2009 11:09:15 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: Paul Hoffman 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: On Wed, Jun 10, 2009 at 11:03 AM, Paul Hoffman wrote= : > At 10:20 AM -0700 6/10/09, Matthew Dempsky wrote: >>There are two sets of resolvers that will contact the root servers >>over IPv4: IPv4-only resolvers and dual-stack IPv4/IPv6 resolvers. =A0A >>records are useful to both sets of resolvers, whereas AAAA records are >>only useful to the second set. > > Say what? Sorry, by "resolvers" I meant "recursive resolvers". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 11:16:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67BBA3A68A1; Wed, 10 Jun 2009 11:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.242 X-Spam-Level: X-Spam-Status: No, score=-5.242 tagged_above=-999 required=5 tests=[AWL=-0.194, 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 tHJkDntxWs3x; Wed, 10 Jun 2009 11:16:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F0F13A683A; Wed, 10 Jun 2009 11:16:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESIg-0002IU-1e for namedroppers-data0@psg.com; Wed, 10 Jun 2009 18:13:26 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESIS-0002F9-Cr for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 18:13:20 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5AICusx019159; Wed, 10 Jun 2009 11:12:56 -0700 (PDT) Cc: Nicholas Weaver , =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= , Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , namedroppers@ops.ietf.org Message-Id: <30071D28-2717-489F-B693-B6A073BFC143@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Date: Wed, 10 Jun 2009 11:12:56 -0700 References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> <0AF3DC17-3EB7-4493-B96F-7F87E474EF02@icsi.berkeley.edu> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 10, 2009, at 11:07 AM, Matthew Dempsky wrote: > On Wed, Jun 10, 2009 at 11:00 AM, Nicholas > Weaver wrote: >> A few arguably broken resolvers > > Sorry, what RFC says the behavior is broken? > >> (why fetch ALL the A records for everything >> always before proceeding?) > > How/when else should dnscache find out m.gtld-server.net's A records? > Or should it just never contact it then? It should not DELAY the resolving of a name in order to put m.gtld- server.net's A record into the cache. DELAYING resolution to get information which is not necessary for the resolution process is arguably broken behavoir. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 11:32:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A383A6920; Wed, 10 Jun 2009 11:32:25 -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.043, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihUScvhmqVZk; Wed, 10 Jun 2009 11:32:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB1293A6855; Wed, 10 Jun 2009 11:32:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESWf-0004ch-R1 for namedroppers-data0@psg.com; Wed, 10 Jun 2009 18:27:53 +0000 Received: from [209.85.217.220] (helo=mail-gx0-f220.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESWQ-0004Wr-MR for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 18:27:47 +0000 Received: by gxk20 with SMTP id 20so1446485gxk.17 for ; Wed, 10 Jun 2009 11:27:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.90.4 with SMTP id n4mr783288agb.69.1244658441078; Wed, 10 Jun 2009 11:27:21 -0700 (PDT) In-Reply-To: <30071D28-2717-489F-B693-B6A073BFC143@ICSI.Berkeley.EDU> References: <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> <0AF3DC17-3EB7-4493-B96F-7F87E474EF02@icsi.berkeley.edu> <30071D28-2717-489F-B693-B6A073BFC143@ICSI.Berkeley.EDU> Date: Wed, 10 Jun 2009 11:27:20 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: Nicholas Weaver Cc: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= , Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 10, 2009 at 11:12 AM, Nicholas Weaver wrote: > It should not DELAY the resolving of a name in order to put > m.gtld-server.net's A record into the cache. > > DELAYING resolution to get information which is not necessary for the > resolution process is arguably broken behavoir. By design, dnscache limits itself to one active outbound query at a time per active inbound query to mitigate amplification attacks. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 11:32:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D91F03A6920; Wed, 10 Jun 2009 11:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.227 X-Spam-Level: X-Spam-Status: No, score=-5.227 tagged_above=-999 required=5 tests=[AWL=-0.179, 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 8wi-iM4vtyi2; Wed, 10 Jun 2009 11:32:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B04A3A6855; Wed, 10 Jun 2009 11:32:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESYJ-0004r9-5Q for namedroppers-data0@psg.com; Wed, 10 Jun 2009 18:29:35 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESY8-0004pO-Cj for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 18:29:29 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5AIT7JY021765; Wed, 10 Jun 2009 11:29:07 -0700 (PDT) Cc: Nicholas Weaver , =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= , Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , namedroppers@ops.ietf.org Message-Id: <7532B5B4-2F5C-4CB4-82E4-4781FEEA808A@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Date: Wed, 10 Jun 2009 11:29:06 -0700 References: <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> <0AF3DC17-3EB7-4493-B96F-7F87E474EF02@icsi.berkeley.edu> <30071D28-2717-489F-B693-B6A073BFC143@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 10, 2009, at 11:27 AM, Matthew Dempsky wrote: > On Wed, Jun 10, 2009 at 11:12 AM, Nicholas > Weaver wrote: >> It should not DELAY the resolving of a name in order to put >> m.gtld-server.net's A record into the cache. >> >> DELAYING resolution to get information which is not necessary for the >> resolution process is arguably broken behavoir. > > By design, dnscache limits itself to one active outbound query at a > time per active inbound query to mitigate amplification attacks. So? Delay that resolution until AFTER the inbound query is resolved. Blocking resolution to get data you DON'T need to produce a response is broken behavior. That the code is so old that it will never be fixed should not be a reason to change the code on the roots. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 11:34:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF2E3A6C0E; Wed, 10 Jun 2009 11:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUcGw6d55iP7; Wed, 10 Jun 2009 11:34:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 417BE3A6C0A; Wed, 10 Jun 2009 11:34:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESaD-0005Fz-Gp for namedroppers-data0@psg.com; Wed, 10 Jun 2009 18:31:33 +0000 Received: from [209.85.217.220] (helo=mail-gx0-f220.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESa2-000566-7z for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 18:31:27 +0000 Received: by gxk20 with SMTP id 20so1450793gxk.17 for ; Wed, 10 Jun 2009 11:31:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.69.7 with SMTP id r7mr1345374aga.47.1244658665377; Wed, 10 Jun 2009 11:31:05 -0700 (PDT) In-Reply-To: <7532B5B4-2F5C-4CB4-82E4-4781FEEA808A@ICSI.Berkeley.EDU> References: <0AF3DC17-3EB7-4493-B96F-7F87E474EF02@icsi.berkeley.edu> <30071D28-2717-489F-B693-B6A073BFC143@ICSI.Berkeley.EDU> <7532B5B4-2F5C-4CB4-82E4-4781FEEA808A@ICSI.Berkeley.EDU> Date: Wed, 10 Jun 2009 11:31:05 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: Nicholas Weaver Cc: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= , Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , 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: On Wed, Jun 10, 2009 at 11:29 AM, Nicholas Weaver wrote: > So? =A0Delay that resolution until AFTER the inbound query is resolved. That would mean having an active outbound query without a corresponding active inbound query. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 11:40:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FF663A6C4C; Wed, 10 Jun 2009 11:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.214 X-Spam-Level: X-Spam-Status: No, score=-5.214 tagged_above=-999 required=5 tests=[AWL=-0.166, 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 mMPXoHdToXd6; Wed, 10 Jun 2009 11:40:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 53E993A6A7A; Wed, 10 Jun 2009 11:40:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESgB-00064c-Uc for namedroppers-data0@psg.com; Wed, 10 Jun 2009 18:37:43 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESfu-00062i-MS for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 18:37:32 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5AIbHJE023108; Wed, 10 Jun 2009 11:37:17 -0700 (PDT) Cc: Nicholas Weaver , =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= , Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Date: Wed, 10 Jun 2009 11:37:16 -0700 References: <0AF3DC17-3EB7-4493-B96F-7F87E474EF02@icsi.berkeley.edu> <30071D28-2717-489F-B693-B6A073BFC143@ICSI.Berkeley.EDU> <7532B5B4-2F5C-4CB4-82E4-4781FEEA808A@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 10, 2009, at 11:31 AM, Matthew Dempsky wrote: > On Wed, Jun 10, 2009 at 11:29 AM, Nicholas > Weaver wrote: >> So? Delay that resolution until AFTER the inbound query is resolved. > > That would mean having an active outbound query without a > corresponding active inbound query. Hu? Whats the point of waiting then? Its data NOT NEEDED for the resolution process, and yet for some random reason, its not kosher to delay it until after the main resolution is complete or to conduct it in parallel? How is this NOT broken? And I'm all fine and good at changing server behavior to accomidate broken code if: a) The market share for the broken code is nontrivial b) The effect of the broken code would cause things to not work right. But this fails BOTH tests. The only resolver affected is DNSCACHE: code that is old, crufty, unpopular, and unsupported. The only effect is one extra RTT to the root for items which do not cache. And for this you want to change code on THE critical servers for Internet operation? F-that. Just fix the code for DNSCACHE. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 11:47:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47D3B3A6A7B; Wed, 10 Jun 2009 11:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=-1.093, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCSLolj2ghgf; Wed, 10 Jun 2009 11:47:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C9E53A6A5D; Wed, 10 Jun 2009 11:47:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESmJ-0007EI-Eg for namedroppers-data0@psg.com; Wed, 10 Jun 2009 18:44:03 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESl0-0006gD-8P for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 18:43:03 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 833992FE9623 for ; Wed, 10 Jun 2009 18:42:25 +0000 (UTC) Date: Wed, 10 Jun 2009 14:42:23 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Message-ID: <20090610184223.GA34005@shinkuro.com> References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610154448.GE33231@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: On Wed, Jun 10, 2009 at 10:47:59AM -0700, Matthew Dempsky wrote: > I already gave a concrete example of existing software that is > adversely affected by the behavior of these five root servers, > resulting in increased load on all of them. As of yet, no one has > given a good justification to why AAAA glue records over A glue > records in response to queries not using EDNS0 and sent over IPv4. You still have the burden of proof the wrong way. One could just as easily say, for instance, that it is nowhere defined that a resolver ought to get all the A records before doing any work. The software in question happens to work that way, so now you say that others ought to change their behaviour so that software can behave as it is programmed. That's the wrong answer: it's a bad idea to try to change the protocol now to specify exactly how to sort the data in the additional section before truncating. Even if it happens to work for you, it would be a protocol change, and I am opposed to doing it. (That said, with my co-chair hat on, if you want this protocol change, write the I-D that specifies it and see whether you can get enough support in the WG to so change the protocol. Hat off again.) > According to RFC 4294, an IPv6 node SHOULD support EDNS0. In this > case, the larger buffer size will be able to handle the complete set > of A and AAAA records, and choose however it wants among all of the > record types. SHOULD does not mean MUST. There is one obvious case I can think of in which a v6 host is going to have a rough go of that: some broken middlebox in the way that won't allow the buffer size to be different. None of that would matter, except that the work going on in BEHAVE is designed precisely to cope with a lot of these broken pieces of equipment, which means that there won't even be an incentive to get rid of them. > > Second, there is reason to suppose that different behaviour on the > > part of different servers might be desirable, since this could be the > > result of different implementations or different code paths in the > > same implementation. > > I don't follow how that makes it "desirable". It is desirable to have different code paths and different implementations in the DNS server space, particularly at sensitive levels of the tree such as ".", ".org", &c. > Can you elaborate on this point? I don't follow what problem the > client is trying to solve. Do you have a concrete example of software > that does this? If not, is there a reason you want the root servers > to favor a hypothetical IPv6 node that doesn't support EDNS0 and has > some peculiar non-standard behavior in preference to existing software > that is standards conforming? The reason I want them to do as they wish is because there _could_ be such a client. I don't know, and I have zero reason to go looking for one. The mere fact that it is possible leads me to believe that a change in this area is bad. But see above. I should point out one other thing, again with my co-chair hat on: if you desire to change this _as a matter of protocol_ (i.e. this is not just for the root servers, but for all DNS servers everywhere), then you should write the I-D and see if you can find acceptance, as I suggested. In that case, this is the right list and the right audience for the discussion. If you're saying instead that there should be an operational convention governing how the root servers are configured, then this is the wrong WG to chase that problem down. We constrain ourselves to the protocol itself. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 11:49:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97D403A688D; Wed, 10 Jun 2009 11:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.838 X-Spam-Level: X-Spam-Status: No, score=-0.838 tagged_above=-999 required=5 tests=[AWL=-0.658, 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 qgmDI5xZIG1F; Wed, 10 Jun 2009 11:49:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E1473A6824; Wed, 10 Jun 2009 11:49:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESoS-0007oP-5Q for namedroppers-data0@psg.com; Wed, 10 Jun 2009 18:46:16 +0000 Received: from [209.85.219.207] (helo=mail-ew0-f207.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESoE-0007kH-5l for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 18:46:09 +0000 Received: by ewy3 with SMTP id 3so1211237ewy.41 for ; Wed, 10 Jun 2009 11:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=xDAyyzyFZPQYyc1nWa6XRG4XpQJPx5umvuaBQtcEI6g=; b=MTHid5Idy4AJYW2NEBLOQolq4zYTOnNIUTR+K4TJN9K1MHG2pXWoPHf6OZtW8RKzik xslN7TBBxBF078zOdCTznurGOwRTFLLalKdbKaIUBosdp6A8BMUSPbuPH/YekuP9rZLN VITw0QqowE5B258CFA++WIir43MX08krhj+sY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=Eeo2TRIJwhLrKhZK3MYkQkoSWkmlq+1hZ41FRVWQeDEbS0gPgM/vK2RyJdyy/L/wqk X98Z7eW+hYQonf7FkyYXLtP+USQDIQxkOMW3VrQ7nmCKz8sz7JsU4++dM/oIRxY0Nexl ifNzlSuv08WTK4S1JchStffYZm9CNG4DJuWnI= MIME-Version: 1.0 Received: by 10.210.36.8 with SMTP id j8mr4301183ebj.40.1244659560147; Wed, 10 Jun 2009 11:46:00 -0700 (PDT) In-Reply-To: <3efd34cc0906101142s5eca0d7fx79bbd6fad51c769f@mail.gmail.com> References: <20090608111014.GA31833@vacation.karoshi.com.> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> <20090609160854.GC25651@shinkuro.com> <20090609182801.GB32546@shinkuro.com> <3efd34cc0906091215t419a6bc3k369067783fdc6266@mail.gmail.com> <80879.1244590583@nsa.vix.com> <3efd34cc0906101142s5eca0d7fx79bbd6fad51c769f@mail.gmail.com> From: bert hubert Date: Wed, 10 Jun 2009 20:45:40 +0200 Message-ID: <3efd34cc0906101145le478e8dseec44a799f3d7315@mail.gmail.com> Subject: SCTP (Re: [dnsext] Re: TCP queries to the root servers ) To: "namedroppers@ops.ietf.org 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: On Wed, Jun 10, 2009 at 1:36 AM, Paul Vixie wrote: > TCP session only lightweight and spoofproof.) =A0it takes four packets to > shut down an association. =A0so, setup and shutdown are expensive compare= d > to UDP or TCP, and it only makes sense to use SCTP if you're able to keep > the association open and use it for multiple transactions. For it to be useful, we'd need to use it for all our traffic. > it takes two packets to carry a request and a response, and if they are > the last request and response in the queue then each of these will be > followed by an ACK packet. =A0so, a slow 1TPS flow would take four packet= s > per transaction, whereas a faster flow would take two packets per > transaction. =A0the extra ACK-only packets don't delay the DNS result, bu= t > they do appear on the wire. Between a single auth server and a single cache, <1 QPS will probably be quite common. This brings into perspective packet counts that are at least twice as high as UDP, and more likely five times as high (when taking into account the setup and teardown). > by lightweight i mean that a root or TLD or 2LD/3LD server could have man= y > hundredthousands or even millions of associations open, all on a single > socket and therefore a single file descriptor, so it's not a burden on > the DNS server's system call interface (think of a select() mask here, or > a poll() filedes array.) Underneath the hood, the kernel is dealing with the exact same challenge as select() or poll() however. So you just moved the problem. In addition, it appears that except for only using a single fd, there is nothing 'lightweight' about an SCTP association. I measure around 8 kilobytes per association. This would mean your millions of associations mentioned above require tens of gigabytes of ram on a commonly used operating system. SCTP is not remotely like UDP. > the two-byte length field from TCP/53 need not be carried in SCTP, since > the transport will tell the receiver the length of each incoming message. The two bytes won't save us however. > most importantly, there's no trivial way to force a downgrade, so if an > initiator tries SCTP first and only uses UDP when SCTP fails, then it wil= l > only use UDP if SCTP has in fact failed, rather than because an attacker > wants it to look like it has failed. =A0(short of a congestion attack tha= t > would also make UDP fail unless one could control the timing of the end o= f > the attack down to the millisecond, which seems like a high enough bar.) This is exactly how one would use EDNS PING. So please color me unconvinced. SCTP has its merits, but it is not light weight, and uses a lot of packets compared to UDP or even TCP. =A0 =A0 =A0 =A0 =A0Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 11:57:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293BA3A683A; Wed, 10 Jun 2009 11:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.16 X-Spam-Level: X-Spam-Status: No, score=0.16 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsWvX6JVvZQu; Wed, 10 Jun 2009 11:57:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 481BA3A681D; Wed, 10 Jun 2009 11:57:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESve-0009nq-LD for namedroppers-data0@psg.com; Wed, 10 Jun 2009 18:53:42 +0000 Received: from [209.85.217.220] (helo=mail-gx0-f220.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESvS-0009i3-01 for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 18:53:36 +0000 Received: by gxk20 with SMTP id 20so1476901gxk.17 for ; Wed, 10 Jun 2009 11:53:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.89.18 with SMTP id m18mr1359390agb.56.1244659993418; Wed, 10 Jun 2009 11:53:13 -0700 (PDT) In-Reply-To: References: <0AF3DC17-3EB7-4493-B96F-7F87E474EF02@icsi.berkeley.edu> <30071D28-2717-489F-B693-B6A073BFC143@ICSI.Berkeley.EDU> <7532B5B4-2F5C-4CB4-82E4-4781FEEA808A@ICSI.Berkeley.EDU> Date: Wed, 10 Jun 2009 11:53:13 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: Nicholas Weaver Cc: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= , Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , 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: On Wed, Jun 10, 2009 at 11:37 AM, Nicholas Weaver wrote: > Hu? =A0Whats the point of waiting then? =A0Its data NOT NEEDED for the > resolution process, and yet for some random reason, its not kosher to del= ay > it until after the main resolution is complete or to conduct it in parall= el? I already explained that. By design, it limits itself to at most one active outbound query for each active inbound query. Conducting two queries in parallel would violate this, as would conducting a second outbound query after answering the inbound query. Also, the data *is* needed for dnscache to be able to send queries to m.gtld-servers.net. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 12:06:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442513A691A; Wed, 10 Jun 2009 12:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.393 X-Spam-Level: X-Spam-Status: No, score=-4.393 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugm5-2WpAaOf; Wed, 10 Jun 2009 12:06:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5DABD3A68C3; Wed, 10 Jun 2009 12:06:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MET3N-000BJq-Uz for namedroppers-data0@psg.com; Wed, 10 Jun 2009 19:01:41 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MET3B-000BGT-Ic for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 19:01:36 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5AJ0Etj019653; Wed, 10 Jun 2009 19:00:14 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5AJ098P019652; Wed, 10 Jun 2009 19:00:09 GMT Date: Wed, 10 Jun 2009 19:00:09 +0000 From: bmanning@vacation.karoshi.com To: Ask =?iso-8859-1?Q?Bj=F8rn?= Hansen Cc: bmanning@vacation.karoshi.com, Matthew Dempsky , Jim Reid , namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Message-ID: <20090610190009.GB19439@vacation.karoshi.com.> References: <4D291F23-2937-4A13-A01D-9BD7630E7F32@rfc1035.com> <20090610094943.GB15847@vacation.karoshi.com.> <9E10E125-4953-4095-89FD-D68B357D1CAD@develooper.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9E10E125-4953-4095-89FD-D68B357D1CAD@develooper.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 10, 2009 at 08:20:09AM -0700, Ask Bjxrn Hansen wrote: > > On Jun 10, 2009, at 2:49, bmanning@vacation.karoshi.com wrote: > > > er... "useful" - i'd be interested in learning how auth servers > > are supposed to be prescentient in "knowing" what the IMR is going > > to do with said glue. > > If I understand it right then Matthew is saying that IPv6 IMR's will > use EDNS0 anyway, so pretty much by definition the A records are going > to be the useful ones to non-EDNS0 requestors. > > > - ask well... an IMR may in fact be mixed mode, so its not appropriate to call an IMR out by a single transport protocol. even if the IMR is dual stack, one can not be assured of a clean IPv6 path to all authoritative servers. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 12:07:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00B03A68C3; Wed, 10 Jun 2009 12:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=-0.155, 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 LHX3ejewWWGr; Wed, 10 Jun 2009 12:07:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1AAAC3A6855; Wed, 10 Jun 2009 12:07:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MET5L-000BjU-Ve for namedroppers-data0@psg.com; Wed, 10 Jun 2009 19:03:44 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MET59-000Be0-BT for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 19:03:37 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5AJ3LHR027535; Wed, 10 Jun 2009 12:03:21 -0700 (PDT) Cc: Nicholas Weaver , =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= , Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , namedroppers@ops.ietf.org Message-Id: <75CCCDF9-47BE-4285-8A88-1B9EEF443EB1@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Date: Wed, 10 Jun 2009 12:03:20 -0700 References: <0AF3DC17-3EB7-4493-B96F-7F87E474EF02@icsi.berkeley.edu> <30071D28-2717-489F-B693-B6A073BFC143@ICSI.Berkeley.EDU> <7532B5B4-2F5C-4CB4-82E4-4781FEEA808A@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 10, 2009, at 11:53 AM, Matthew Dempsky wrote: > On Wed, Jun 10, 2009 at 11:37 AM, Nicholas > Weaver wrote: >> Hu? Whats the point of waiting then? Its data NOT NEEDED for the >> resolution process, and yet for some random reason, its not kosher >> to delay >> it until after the main resolution is complete or to conduct it in >> parallel? > > I already explained that. By design, it limits itself to at most one > active outbound query for each active inbound query. Conducting two > queries in parallel would violate this, as would conducting a second > outbound query after answering the inbound query. Also, the data *is* > needed for dnscache to be able to send queries to m.gtld-servers.net. The data is NOT needed to resolve the question asked unless during THIS question, it decides randomly that m.gtld-servers.net is its selected item. This is ridiculous. The behavior of dnscache is broken: It is waiting to get data that it doesn't actually need to resolve THIS query, because its data it might randomly use later. The brokenness is trivial: It has a practically nonexistent effect on the roots, and even for what few dnscache users, the effect is almost trivial: one more RTT to the root in the rare case that the TLD's authoritative servers are not already in the cache. The excuses as to why it remains broken are silly: There are two solutions that can be almost trivially added to the code: Do a concurrent fetch or do a delayed lazy fetch. Neither fix increases the number of packets dnscache would generate, just changes the ordering so they don't introduce latency. And, for the trivial benefit of a few users of a piece of broken open source code, you WANT TO CHANGE THE BEHAVIOR OF THE ROOT SERVERS WHEN THE SERVERS ARE ALREADY WORKING PROPERLY!?!? Its like "Because there is a pothole in my private driveway next to the onramp, we need to repave the entire freeway?" -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 12:21:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74D3E3A6B26; Wed, 10 Jun 2009 12:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.629 X-Spam-Level: X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4F+7g-78LMl; Wed, 10 Jun 2009 12:21:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 784FF3A68D4; Wed, 10 Jun 2009 12:21:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1METIz-000ECw-AQ for namedroppers-data0@psg.com; Wed, 10 Jun 2009 19:17:49 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1METIf-000E4a-Ni for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 19:17:37 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A8CB32FE9621 for ; Wed, 10 Jun 2009 19:17:13 +0000 (UTC) Date: Wed, 10 Jun 2009 15:17:11 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Message-ID: <20090610191711.GB34005@shinkuro.com> References: <0AF3DC17-3EB7-4493-B96F-7F87E474EF02@icsi.berkeley.edu> <30071D28-2717-489F-B693-B6A073BFC143@ICSI.Berkeley.EDU> <7532B5B4-2F5C-4CB4-82E4-4781FEEA808A@ICSI.Berkeley.EDU> 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: On Wed, Jun 10, 2009 at 11:53:13AM -0700, Matthew Dempsky wrote: > outbound query after answering the inbound query. Also, the data *is* > needed for dnscache to be able to send queries to m.gtld-servers.net. So don't send queries there. So what? Also, of course, you only need it in the event you got the answer with the AAAA records, and we've already determined that you don't always get that. So you don't even need this to send queries to m as such -- sometimes you will. But m will get fewer queries from dnscache users than other servers, and I don't think that matters. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 12:25:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24BC63A6ADE; Wed, 10 Jun 2009 12:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.157 X-Spam-Level: X-Spam-Status: No, score=0.157 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IYNszsYNMiN; Wed, 10 Jun 2009 12:25:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E1A033A68D4; Wed, 10 Jun 2009 12:25:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1METMa-000EwV-U0 for namedroppers-data0@psg.com; Wed, 10 Jun 2009 19:21:32 +0000 Received: from [209.85.217.220] (helo=mail-gx0-f220.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1METMO-000Ent-Vr for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 19:21:27 +0000 Received: by gxk20 with SMTP id 20so1509877gxk.17 for ; Wed, 10 Jun 2009 12:21:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.88.16 with SMTP id l16mr1357600agb.112.1244661664385; Wed, 10 Jun 2009 12:21:04 -0700 (PDT) In-Reply-To: <75CCCDF9-47BE-4285-8A88-1B9EEF443EB1@ICSI.Berkeley.EDU> References: <30071D28-2717-489F-B693-B6A073BFC143@ICSI.Berkeley.EDU> <7532B5B4-2F5C-4CB4-82E4-4781FEEA808A@ICSI.Berkeley.EDU> <75CCCDF9-47BE-4285-8A88-1B9EEF443EB1@ICSI.Berkeley.EDU> Date: Wed, 10 Jun 2009 12:21:04 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: Nicholas Weaver Cc: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= , Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , 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: On Wed, Jun 10, 2009 at 12:03 PM, Nicholas Weaver wrote: > The behavior of dnscache is broken: =A0It is waiting to get data that it > doesn't actually need to resolve THIS query, because its data it might > randomly use later. It's broken to delay query 1 instead of query X? > The excuses as to why it remains broken are silly: =A0There are two solut= ions > that can be almost trivially added to the code: =A0Do a concurrent fetch = or do > a delayed lazy fetch. =A0 Neither fix increases the number of packets dns= cache > would generate, just changes the ordering so they don't introduce latency= . And I've already pointed out the design decision that rules out both of these solutions: dnscache limits itself to at most one active outbound DNS query for each inbound DNS query. This decision helps to mitigate against amplification attacks. (However, I suppose defending against amplification attacks isn't a big concern for the working group that standardized DNSSEC. ;-)) > And, for the trivial benefit of a few users of a piece of broken open sou= rce > code, you WANT TO CHANGE THE BEHAVIOR OF THE ROOT SERVERS WHEN THE SERVER= S > ARE ALREADY WORKING PROPERLY!?!? If Paul Vixie and others are going to insist that caches should always talk to the root servers rather than contacting a local root zone server, then yes, I think the root servers should serve data in a way that is compatible with all DNS cache software. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 12:32:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54CA3A6855; Wed, 10 Jun 2009 12:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.154 X-Spam-Level: X-Spam-Status: No, score=0.154 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBxqm9IFn5Q6; Wed, 10 Jun 2009 12:31:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 648B23A6B22; Wed, 10 Jun 2009 12:31:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1METTM-000GEf-B7 for namedroppers-data0@psg.com; Wed, 10 Jun 2009 19:28:32 +0000 Received: from [209.85.217.220] (helo=mail-gx0-f220.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1METTB-000G7s-6h for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 19:28:26 +0000 Received: by gxk20 with SMTP id 20so1517989gxk.17 for ; Wed, 10 Jun 2009 12:28:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.49.8 with SMTP id w8mr1366786agw.103.1244662084406; Wed, 10 Jun 2009 12:28:04 -0700 (PDT) In-Reply-To: <20090610190009.GB19439@vacation.karoshi.com.> References: <4D291F23-2937-4A13-A01D-9BD7630E7F32@rfc1035.com> <20090610094943.GB15847@vacation.karoshi.com.> <9E10E125-4953-4095-89FD-D68B357D1CAD@develooper.com> <20090610190009.GB19439@vacation.karoshi.com.> Date: Wed, 10 Jun 2009 12:28:04 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: bmanning@vacation.karoshi.com Cc: =?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= , Jim Reid , 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: On Wed, Jun 10, 2009 at 12:00 PM, wrote: > =A0 =A0 =A0 =A0well... an IMR may in fact be mixed mode, so its > =A0 =A0 =A0 =A0not appropriate to call an IMR out by a single transport > =A0 =A0 =A0 =A0protocol. =A0even if the IMR is dual stack, one can not > =A0 =A0 =A0 =A0be assured of a clean IPv6 path to all authoritative serve= rs. Sorry, can someone clarify what "IMR" stands for? Is the terminology being used here that "resolver" means the stub resolver that sends a query with RD=3D1 to one of a few caching servers and expects a complete answer, and "IMR" means the recursive resolver that sends multiple queries with RD=3D0 to one of many authoritative servers? In that case, I mean the "resolver" doesn't care what glue data the authoritative servers give to the "IMR", and the authoritative server should give glue according to what the "IMR" can best utilize. If the "IMR" contacted it using IPv4, then obviously the "IMR" can make use of A record glue data; it's not guaranteed it can make use of AAAA record glue data. The "resolver"'s IPv4/IPv6 connectivity has no bearing on how the "IMR" should try to answer a query (except for how to send the response packet, of course). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 12:38:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E25123A697E; Wed, 10 Jun 2009 12:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.327 X-Spam-Level: * X-Spam-Status: No, score=1.327 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 LfSMUXJOj8R6; Wed, 10 Jun 2009 12:38:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5637A3A67B2; Wed, 10 Jun 2009 12:38:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1METZW-000HSG-Az for namedroppers-data0@psg.com; Wed, 10 Jun 2009 19:34:54 +0000 Received: from [209.85.218.212] (helo=mail-bw0-f212.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1METZL-000HOh-95 for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 19:34:48 +0000 Received: by bwz8 with SMTP id 8so643134bwz.41 for ; Wed, 10 Jun 2009 12:34:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.108.78 with SMTP id e14mr1626356fap.88.1244662466115; Wed, 10 Jun 2009 12:34:26 -0700 (PDT) In-Reply-To: References: <30071D28-2717-489F-B693-B6A073BFC143@ICSI.Berkeley.EDU> <7532B5B4-2F5C-4CB4-82E4-4781FEEA808A@ICSI.Berkeley.EDU> <75CCCDF9-47BE-4285-8A88-1B9EEF443EB1@ICSI.Berkeley.EDU> From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Date: Wed, 10 Jun 2009 21:34:06 +0200 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients To: Matthew Dempsky Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [...snip everything...] Matthew, it starts to be really boring :( what you seem to not understand that this group doesn't dictate how should root servers behave. This group defines internet standards. And if you want to change the behavior - write an I-D and if it gets enough support it could become standard. That's how this group works. If you want to change behavior without an I-D - you can go to each individual root server operator and ask them to change their software. Ondrej -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 12:47:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18FBB3A6B61; Wed, 10 Jun 2009 12:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.028 X-Spam-Level: X-Spam-Status: No, score=-0.028 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXLBVt19XiYy; Wed, 10 Jun 2009 12:46:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 403EE3A6B47; Wed, 10 Jun 2009 12:46:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1METhL-000Iyc-Ng for namedroppers-data0@psg.com; Wed, 10 Jun 2009 19:42:59 +0000 Received: from [74.125.46.28] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1METgu-000Iul-Hp for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 19:42:43 +0000 Received: by yw-out-2324.google.com with SMTP id 9so511195ywe.71 for ; Wed, 10 Jun 2009 12:42:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.54.6 with SMTP id c6mr1406988aga.29.1244662951602; Wed, 10 Jun 2009 12:42:31 -0700 (PDT) In-Reply-To: References: <30071D28-2717-489F-B693-B6A073BFC143@ICSI.Berkeley.EDU> <7532B5B4-2F5C-4CB4-82E4-4781FEEA808A@ICSI.Berkeley.EDU> <75CCCDF9-47BE-4285-8A88-1B9EEF443EB1@ICSI.Berkeley.EDU> Date: Wed, 10 Jun 2009 12:42:31 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= Cc: 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: On Wed, Jun 10, 2009 at 12:34 PM, Ond=F8ej Sur=FD wrote= : > it starts to be really boring :( Agreed. > what you seem to not understand that this group doesn't dictate how > should root servers behave. This group defines internet standards. And > if you want to change the behavior - write an I-D and if it gets > enough support it could become standard. That's how this group works. Just a short I-D that states DNS servers SHOULD include A record glue data in preference to AAAA record glue data when doing additional section processing for NS records in response to a query sent over IPv4 without an EDNS0 OPT record? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 12:48:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2DA3A6BA5; Wed, 10 Jun 2009 12:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.193 X-Spam-Level: X-Spam-Status: No, score=-5.193 tagged_above=-999 required=5 tests=[AWL=-0.145, 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 2r3uiomfRa7B; Wed, 10 Jun 2009 12:48:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F21833A6B47; Wed, 10 Jun 2009 12:48:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1METjV-000JNn-5p for namedroppers-data0@psg.com; Wed, 10 Jun 2009 19:45:13 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1METjG-000JMC-Ip for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 19:45:07 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5AJihc4002508; Wed, 10 Jun 2009 12:44:43 -0700 (PDT) Cc: Nicholas Weaver , =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= , Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , namedroppers@ops.ietf.org Message-Id: <8F098655-5D30-446B-B317-C8A3F9F3562D@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Date: Wed, 10 Jun 2009 12:44:43 -0700 References: <30071D28-2717-489F-B693-B6A073BFC143@ICSI.Berkeley.EDU> <7532B5B4-2F5C-4CB4-82E4-4781FEEA808A@ICSI.Berkeley.EDU> <75CCCDF9-47BE-4285-8A88-1B9EEF443EB1@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 10, 2009, at 12:21 PM, Matthew Dempsky wrote: > On Wed, Jun 10, 2009 at 12:03 PM, Nicholas > Weaver wrote: >> The behavior of dnscache is broken: It is waiting to get data that >> it >> doesn't actually need to resolve THIS query, because its data it >> might >> randomly use later. > > It's broken to delay query 1 instead of query X? You don't NEED to delay query X. You don't need to increase the number of packets sent. >> The excuses as to why it remains broken are silly: There are two >> solutions >> that can be almost trivially added to the code: Do a concurrent >> fetch or do >> a delayed lazy fetch. Neither fix increases the number of packets >> dnscache >> would generate, just changes the ordering so they don't introduce >> latency. > > And I've already pointed out the design decision that rules out both > of these solutions: dnscache limits itself to at most one active > outbound DNS query for each inbound DNS query. This decision helps to > mitigate against amplification attacks. (However, I suppose defending > against amplification attacks isn't a big concern for the working > group that standardized DNSSEC. ;-)) It is NOT AN AMPLIFICATION ATTACK IF IT DOESN'T INCREASE THE NUMBER OF PACKETS! You are defending a nonsense "design decision" as somehow being invoilate. Both trivial fixes do not increase the number of packets dnscache sends. And the second doesn't even increase the number of active outbound queries per inbound query, it just keeps the outbound query active after the inbound query has been answered. djbdns has been unchanged for 8 years now! It has a significant security vulnerability because it doesn't have birthday-attack supression. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4392 Either fix dnscache yourself (do you want to maintain abandonware open source? Good for you), or stop complaining about a trivial increase in latency of lookups. So why should the roots change NOW to "fix" a trivial slowdown in an 8- year old, unmaintained, vulnerable piece of code? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 13:10:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4246D3A6962; Wed, 10 Jun 2009 13:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYVsdwxZxj0T; Wed, 10 Jun 2009 13:10:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 78A603A67B2; Wed, 10 Jun 2009 13:10:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1METza-000MeU-CJ for namedroppers-data0@psg.com; Wed, 10 Jun 2009 20:01:50 +0000 Received: from [209.85.217.220] (helo=mail-gx0-f220.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1METyC-000MD8-RB for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 20:01:06 +0000 Received: by gxk20 with SMTP id 20so1555222gxk.17 for ; Wed, 10 Jun 2009 13:00:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.88.16 with SMTP id l16mr1385314agb.112.1244664007761; Wed, 10 Jun 2009 13:00:07 -0700 (PDT) In-Reply-To: References: <7532B5B4-2F5C-4CB4-82E4-4781FEEA808A@ICSI.Berkeley.EDU> <75CCCDF9-47BE-4285-8A88-1B9EEF443EB1@ICSI.Berkeley.EDU> Date: Wed, 10 Jun 2009 13:00:05 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Just a short I-D that states DNS servers SHOULD include A record glue > data in preference to AAAA record glue data when doing additional > section processing for NS records in response to a query sent over > IPv4 without an EDNS0 OPT record? Also, before I go to this effort, is there anyone on this mailing list that actually supports such an I-D? So far, the responses seem to be very emotionally against. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 14:11:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A86A33A6AFE; Wed, 10 Jun 2009 14:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.216 X-Spam-Level: X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 AJG58cIRryf8; Wed, 10 Jun 2009 14:11:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F12693A67BD; Wed, 10 Jun 2009 14:11:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEUvg-0006qa-3q for namedroppers-data0@psg.com; Wed, 10 Jun 2009 21:01:52 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEUvU-0006oK-Lc for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 21:01:46 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5AL1NEO049664 for ; Wed, 10 Jun 2009 17:01:23 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n5AL1MX8049663 for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 17:01:22 -0400 (EDT) (envelope-from namedroppers) Received: from [209.85.219.207] (helo=mail-ew0-f207.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MESlP-0006sf-By for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 18:43:38 +0000 Received: by ewy3 with SMTP id 3so1209123ewy.41 for ; Wed, 10 Jun 2009 11:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=LQmvTTr2ygiYwGyE3VWS0jWg+h1yCmvsZPUzGRjVt4M=; b=JEd9eDowaMd7rOBVzKteNrXF56AKLNha3b7psaRKuMGQKehAKsxYdbQw8WOYp1wR2B kbhIC9c6sMfWx57OJ0Z3gLwImlb3q4frIS4FwhrlUfNGtJxSqLNriltTk1PK1GEyNq2l QTKvErySyhJtLXctnxYBpwBrXmSEBs7nf6njM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=HlzBjxWGC0WWF5Q0nUb5d47EJESyStvK5tm+kBI80otUU6AnMXP5EYvBZZHCQbvBpK jDOOQWPbKivNXacMzyoMMkLma5FRor7ZwwPdVXMmPQvlz8iUBbD5TdQUfejzol3YInni JR/jz93mK2VpqWohpSHKcBLYAsya/HUkymuKw= MIME-Version: 1.0 Received: by 10.210.126.18 with SMTP id y18mr4482507ebc.74.1244659386132; Wed, 10 Jun 2009 11:43:06 -0700 (PDT) In-Reply-To: <80879.1244590583@nsa.vix.com> References: <20090608111014.GA31833@vacation.karoshi.com.> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> <20090609160854.GC25651@shinkuro.com> <20090609182801.GB32546@shinkuro.com> <3efd34cc0906091215t419a6bc3k369067783fdc6266@mail.gmail.com> <80879.1244590583@nsa.vix.com> From: bert hubert Date: Wed, 10 Jun 2009 20:42:46 +0200 X-Google-Sender-Auth: 85e6a8ba39fc2d22 Message-ID: <3efd34cc0906101142s5eca0d7fx79bbd6fad51c769f@mail.gmail.com> Subject: Re: SCTP (Re: [dnsext] Re: TCP queries to the root servers ) To: Paul Vixie Cc: Matthew Dempsky , Andrew Sullivan , Douglas Otis , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 10, 2009 at 1:36 AM, Paul Vixie wrote: > TCP session only lightweight and spoofproof.) =A0it takes four packets to > shut down an association. =A0so, setup and shutdown are expensive compare= d > to UDP or TCP, and it only makes sense to use SCTP if you're able to keep > the association open and use it for multiple transactions. For it to be useful, we'd need to use it for all our traffic. > it takes two packets to carry a request and a response, and if they are > the last request and response in the queue then each of these will be > followed by an ACK packet. =A0so, a slow 1TPS flow would take four packet= s > per transaction, whereas a faster flow would take two packets per > transaction. =A0the extra ACK-only packets don't delay the DNS result, bu= t > they do appear on the wire. Between a single auth server and a single cache, <1 QPS will probably be quite common. This brings into perspective packet counts that are at least twice as high as UDP, and more likely five times as high (when taking into account the setup and teardown). > by lightweight i mean that a root or TLD or 2LD/3LD server could have man= y > hundredthousands or even millions of associations open, all on a single > socket and therefore a single file descriptor, so it's not a burden on > the DNS server's system call interface (think of a select() mask here, or > a poll() filedes array.) Underneath the hood, the kernel is dealing with the exact same challenge as select() or poll() however. So you just moved the problem. In addition, it appears that except for only using a single fd, there is nothing 'lightweight' about an SCTP association. I measure around 8 kilobytes per association. This would mean your millions of associations mentioned above require tens of gigabytes of ram on a commonly used operating system. SCTP is not remotely like UDP. > the two-byte length field from TCP/53 need not be carried in SCTP, since > the transport will tell the receiver the length of each incoming message. The two bytes won't save us however. > most importantly, there's no trivial way to force a downgrade, so if an > initiator tries SCTP first and only uses UDP when SCTP fails, then it wil= l > only use UDP if SCTP has in fact failed, rather than because an attacker > wants it to look like it has failed. =A0(short of a congestion attack tha= t > would also make UDP fail unless one could control the timing of the end o= f > the attack down to the millisecond, which seems like a high enough bar.) This is exactly how one would use EDNS PING. So please color me unconvinced. SCTP has its merits, but it is not light weight, and uses a lot of packets compared to UDP or even TCP. Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 15:04:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2D353A6C2E; Wed, 10 Jun 2009 15:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQEhyhVmCVU0; Wed, 10 Jun 2009 15:04:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC5EC3A6AB3; Wed, 10 Jun 2009 15:04:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEVpu-000G8o-7Z for namedroppers-data0@psg.com; Wed, 10 Jun 2009 21:59:58 +0000 Received: from [2001:888:1037:1337::53:53] (helo=burnout.bakker.net) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEVpi-000G7p-Ru for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 21:59:52 +0000 Received: by burnout.bakker.net (Postfix, from userid 910) id 49DABF1839; Wed, 10 Jun 2009 23:59:45 +0200 (CEST) Date: Wed, 10 Jun 2009 23:59:45 +0200 From: niels=ietfops@bakker.net (Niels Bakker) To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Comparing SCTP to TCP or UDP Message-ID: <20090610215945.GJ84365@burnout.tpb.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> <20090609160854.GC25651@shinkuro.com> <20090609182801.GB32546@shinkuro.com> <3efd34cc0906091215t419a6bc3k369067783fdc6266@mail.gmail.com> <2F19E5E4-9907-475C-94A6-91A6AC54A007@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <2F19E5E4-9907-475C-94A6-91A6AC54A007@mail-abuse.org> User-Agent: Mutt/1.5.19 (2009-01-05) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * dotis@mail-abuse.org (Douglas Otis) [Wed 10 Jun 2009, 02:21 CEST]: >> On Tue, Jun 9, 2009 at 12:15 PM, bert hubert >> wrote: >>> To keep it brief, the summary is that SCTP uses at least twice as many >>> packets as UDP, and far more if the association is not kept open for a >>> long time. Furthermore, an open association consumes server resources, >>> and probably not less than TCP (even while sharing a file descriptor >>> between queries). The initial cookie does not mitigate this - every >>> association carries state that has to be carried around. >> >> I don't have any SCTP experience, but these results seem >> discouraging for DNS-over-SCTP adoption. I'd be interested in >> knowing if these results contradict any DNS-over-SCTP proponents' >> experiences/expectations. > > Without question, SCTP requires more resources than UDP in the ideal > case. However, the ideal case is _not_ where SCTP offers benefit. Can you describe your idea of the average case, then? It would be a huge improvement over your current hand-waving In case you disagree with the data bert hubert presented, the answer should be more data >As the speed of the Internet increases, many seem unaware of the >looming problems ahead. Many continue to publish wildcard TXT SPF >records that carry cached macros. Some now advocate the use of MX 0 . >records to refute outbound email. Some have suggested packet >cryptography offers protection from spoofed or brute force attacks. >At least SCTP limits attack mitigation to the validation of one's own >cookie. Don't just consider the ideal case, consider those cases that >represent an existence within today's Internet What does "IN MX 0 ." have to do with what transport is used for sending DNS datagrams across? -- Niels. -- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 10 17:31:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C24D63A6A53; Wed, 10 Jun 2009 17:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.114 X-Spam-Level: X-Spam-Status: No, score=-5.114 tagged_above=-999 required=5 tests=[AWL=-0.992, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDObSI8E7ITD; Wed, 10 Jun 2009 17:31:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B886C3A6A5F; Wed, 10 Jun 2009 17:31:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEY6Z-000EGx-RU for namedroppers-data0@psg.com; Thu, 11 Jun 2009 00:25:19 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEY6M-000EDE-Hb for namedroppers@ops.ietf.org; Thu, 11 Jun 2009 00:25:13 +0000 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id F19B6A94439; Thu, 11 Jun 2009 00:25:05 +0000 (UTC) Cc: namedroppers@ops.ietf.org Message-Id: From: Douglas Otis To: Niels Bakker In-Reply-To: <20090610215945.GJ84365@burnout.tpb.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Comparing SCTP to TCP or UDP Date: Wed, 10 Jun 2009 17:25:05 -0700 References: <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> <20090609160854.GC25651@shinkuro.com> <20090609182801.GB32546@shinkuro.com> <3efd34cc0906091215t419a6bc3k369067783fdc6266@mail.gmail.com> <2F19E5E4-9907-475C-94A6-91A6AC54A007@mail-abuse.org> <20090610215945.GJ84365@burnout.tpb.net> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 10, 2009, at 2:59 PM, Niels Bakker wrote: > * dotis@mail-abuse.org (Douglas Otis) [Wed 10 Jun 2009, 02:21 CEST]: >> >> Without question, SCTP requires more resources than UDP in the >> ideal case. However, the ideal case is _not_ where SCTP offers >> benefit. > > Can you describe your idea of the average case, then? It would be a > huge improvement over your current hand-waving DNS represents an essential service that needs to remain operational during at least moderate levels of attack. Daily bot-net activity revealed over a few trillion DNS transactions in our tiny network show different quantitative results over increased timeframes. The overall sources have been steadily doubling, as if governed by Moore's law. Nefarious activity seen through the straw-like-view from our tiny network appear to emanate from a few million IP addresses within an hour, and grow to hundreds of millions over a few weeks with an asymptote at about two years. While seldom has the activity been aimed at causing DDoS events, in our defense against occasional attacks that appear aimed at enhancing malware spread, large expenditures become required. Unfortunately, management has decided not to make details public. Much of the attack appears to represent re-tasking of the bot-net drones. > In case you disagree with the data bert hubert presented, the answer > should be more data Unfortunately, much of this data will need to be extrapolations of attacks permitted by today's networks. >> As the speed of the Internet increases, many seem unaware of the >> looming problems ahead. Many continue to publish wildcard TXT SPF >> records that carry cached macros. Some now advocate the use of MX >> 0 . records to refute outbound email. Some have suggested packet >> cryptography offers protection from spoofed or brute force >> attacks. At least SCTP limits attack mitigation to the validation >> of one's own cookie. Don't just consider the ideal case, consider >> those cases that represent an existence within today's Internet > > What does "IN MX 0 ." have to do with what transport is used for > sending DNS datagrams across? These records are likely to generate additional junk traffic from millions of otherwise innocent sources that will be targeting roots with fairly short negative caching. The traffic created by this, in conjunction with DNSSEC, IPv6 and EDNS will raise the base level that roots will need to support. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From proved@renzacci.net Thu Jun 11 02:38:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D07F3A69F0; Thu, 11 Jun 2009 02:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.834 X-Spam-Level: **** X-Spam-Status: No, score=4.834 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_OPRAH=2, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HS_INDEX_PARAM=0.001, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, SUBJECT_DIET=1.466, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 1GnwIiEIwHb1; Thu, 11 Jun 2009 02:38:52 -0700 (PDT) Received: from 192.113.204.68.cfl.res.rr.com (192.113.204.68.cfl.res.rr.com [68.204.113.192]) by core3.amsl.com (Postfix) with ESMTP id 0B8923A67A5; Thu, 11 Jun 2009 02:38:50 -0700 (PDT) Date: Thu, 11 Jun 2009 05:38:12 -0500 Message-Id: <6SGVECO608495.O0BEB79@68.204.113.192> From: disman-request@ietf.org To: disman-request@ietf.org Subject: Safely lose weight with Acai Diet , Endorsed by Oprah. Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Are images missing? View the full online version.
Acai Diet PLAN is your answer to healthy weight loss.
If you received this email as a forward, we invite you to subscribe.

This message was sent to disman-request@ietf.org.

Contact Us | Unsubscribe | Update Email Address | Privacy Policy

Copyright 2009 cwz Co., 70 Axdylv Street, Xpxpeuv, US 981452.
All rights reserved.
 
From owner-namedroppers@ops.ietf.org Thu Jun 11 02:53:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FDE03A6D7E; Thu, 11 Jun 2009 02:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 DkK3-w1S09d5; Thu, 11 Jun 2009 02:53:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 98B5D3A6D61; Thu, 11 Jun 2009 02:53:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEgsm-000N3Z-5o for namedroppers-data0@psg.com; Thu, 11 Jun 2009 09:47:40 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEgsS-000N1W-Qs for namedroppers@ops.ietf.org; Thu, 11 Jun 2009 09:47:28 +0000 Received: from [IPv6:2001:610:719:1:224:8cff:fe33:564a] (unknown [IPv6:2001:610:719:1:224:8cff:fe33:564a]) (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 6BEAEE601C; Thu, 11 Jun 2009 09:47:18 +0000 (UTC) (envelope-from shane@isc.org) Subject: Re: SCTP (Re: [dnsext] Re: TCP queries to the root servers ) From: Shane Kerr To: bert hubert Cc: "namedroppers@ops.ietf.org" In-Reply-To: <3efd34cc0906101145le478e8dseec44a799f3d7315@mail.gmail.com> References: <20090608111014.GA31833@vacation.karoshi.com.> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> <20090609160854.GC25651@shinkuro.com> <20090609182801.GB32546@shinkuro.com> <3efd34cc0906091215t419a6bc3k369067783fdc6266@mail.gmail.com> <80879.1244590583@nsa.vix.com> <3efd34cc0906101142s5eca0d7fx79bbd6fad51c769f@mail.gmail.com> <3efd34cc0906101145le478e8dseec44a799f3d7315@mail.gmail.com> Content-Type: text/plain Organization: ISC Date: Thu, 11 Jun 2009 11:47:15 +0200 Message-Id: <1244713635.4151.21601.camel@shane-asus-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Bert, On Wed, 2009-06-10 at 20:45 +0200, bert hubert wrote: > I measure around 8 kilobytes per association. This would mean your > millions of associations mentioned above require tens of gigabytes of > ram on a commonly used operating system. AIUI, SCTP can support reliable, ordered delivery like TCP, or it can run without those features. The protocol stack will require memory to track the state of things if those are enabled, which it will not require if these are not used. So, hopefully those 8 kilobytes per association can be greatly reduced if we only need the UDP guarantees (meaning - "nothing"). :) > So please color me unconvinced. SCTP has its merits, but it is not > light weight, and uses a lot of packets compared to UDP or even TCP. There is one more packet required for the initial handshake than for TCP. Since data can be present in the same packets as control information, the actual sequence for a complete SCTP session might be: Client -> INIT INIT-ACK <- Server Client -> COOKIE-ECHO # put query here COOKIE-ACK <- Server # put response here Client -> SHUTDOWN SHUTDOWN-ACK <- Server Client -> SHUTDOWN-COMPLETION So we've turned a 2-packet transaction UDP transaction, or a 6-packet TCP transaction, into a 7-packet SCTP transaction. The latency from the client point of view is 2 RTT (the time until the COOKIE-ACK comes back with the query response) - not great but not too horrible. I don't know what the relative bandwidth consumption is going to be of the two streams. It will be more, obviously, but not 3.5x since the packets with only control data should be quite small. Also note that the most common DNS query is likely to be A followed by AAAA, or possibly the other way around(*). A smart client will keep the session open, meaning the total packet count would be 4 for UDP, 8 for TCP, and 9 for SCTP. The total latency will be 2 RTT for UDP and 3 RTT for TCP or SCTP. Going further to the case where we are looking at the communication between stub resolvers and recursive resolvers, then if stub resolvers are able to keep the session open without huge cost on the recursive resolver, then the amortized cost will be the same for SCTP as for UDP - 2 packets per lookup. -- Shane (*) Maybe it makes sense to create an EDNS0 option to include additional RTYPEs in a single query? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 11 06:05:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BBEC3A6A7B; Thu, 11 Jun 2009 06:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.185 X-Spam-Level: X-Spam-Status: No, score=-5.185 tagged_above=-999 required=5 tests=[AWL=-0.137, 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 ZbCx5tzsCR2I; Thu, 11 Jun 2009 06:05:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 373C93A68F1; Thu, 11 Jun 2009 06:05:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEjps-0003km-A1 for namedroppers-data0@psg.com; Thu, 11 Jun 2009 12:56:52 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEjph-0003jT-Bb for namedroppers@ops.ietf.org; Thu, 11 Jun 2009 12:56:46 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5BCuavc016961; Thu, 11 Jun 2009 05:56:36 -0700 (PDT) From: Nicholas Weaver To: "George Barwood" In-Reply-To: Subject: Re: [dnsext] Hardening DNS using existing protocol elements X-Priority: 3 References: Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 05:56:35 -0700 Cc: Nicholas Weaver , X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 10, 2009, at 11:33 PM, George Barwood wrote: > It seems to me that there are 3 problems to be solved: > > (1) Out-of-path attacks against the 16 bit DNS ID field. > > Solution: EDNS Ping ( which I would like to see renamed EDNS > Extended ID ). > That is, the client includes an OPT record that the server copies > into it's response. > > (2) Out-of-path attacks against IP fragments. > > Solution: Response is encrypted* in an OPT record, using the > Extended ID as the key, > if response is > 512 bytes and client indicates support ( by means > of an OPT flag ). NO! If we want to go down the road at all, they should have the same mechanism for 1 and 2: If there is an EDNS record saying "paranoid", that value should have a 64b NONCE: The reply should REPLACE the EDNS extended ID with HMAC-SHA256 (truncated to 64b) of the entire message. This is what hashes and HMAC are for. But to my mind, I really don't think its worth bothering. Lets face it, who's picking on even all the lAme non-randomizing DNS resolvers out there? Heck, who's picking on the DNS resolvers that don't do bailywick checking right? > (3) Amplification attacks against authoritative servers. > > Solution: An OPT record sent by the server asking the client to > prove their IP address > is not forged, if server is under attack, the response is large and > the client indicates > support ( by means of an OPT flag ). The client repeats the request, > including a copy > of the OPT record. Clients that do not indicate support may instead > get SERVFAIL > from a server that is under attack, so they have a big incentive to > upgrade. Bah. You can just wash that attack through recursive resolvers which accept external requests, and distribute things so much. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 11 07:16:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51AF3A6907; Thu, 11 Jun 2009 07:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.177 X-Spam-Level: X-Spam-Status: No, score=-5.177 tagged_above=-999 required=5 tests=[AWL=-0.129, 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 P2WvBR-mgX+y; Thu, 11 Jun 2009 07:16:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E12CB3A6407; Thu, 11 Jun 2009 07:16:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEl0T-000HUJ-3T for namedroppers-data0@psg.com; Thu, 11 Jun 2009 14:11:53 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEl0H-000HTC-GY for namedroppers@ops.ietf.org; Thu, 11 Jun 2009 14:11:47 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5BEBdPW027013; Thu, 11 Jun 2009 07:11:39 -0700 (PDT) From: Nicholas Weaver To: "George Barwood" In-Reply-To: Subject: Re: [dnsext] Hardening DNS using existing protocol elements X-Priority: 3 References: Message-Id: <8B13C905-C120-43DE-A81F-2548EF7294A1@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 07:11:38 -0700 Cc: Nicholas Weaver , X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 11, 2009, at 6:56 AM, George Barwood wrote: > > >> Heck, who's picking on the DNS resolvers that don't do bailywick >> checking right? > > What has bailywick checking got to do with it? > We are talking about blind attacks modifying fragmented IP packets > ( very easy to do ). > For a resolver behind a NAT that means a single forged packet. Because there are horribly broken DNS resolvers out there which will happily accept pretty much anything in a glue record. Those you don't need packet injection at ALL to poison. > > >>> (3) Amplification attacks against authoritative servers. >>> >>> Solution: An OPT record sent by the server asking the client to >>> prove their IP address >>> is not forged, if server is under attack, the response is large and >>> the client indicates >>> support ( by means of an OPT flag ). The client repeats the request, >>> including a copy >>> of the OPT record. Clients that do not indicate support may instead >>> get SERVFAIL >>> from a server that is under attack, so they have a big incentive to >>> upgrade. >> >> Bah. You can just wash that attack through recursive resolvers which >> accept external requests, and distribute things so much. > > Don't understand you. > Are you saying that amplification attacks against DNSSEC authorities > are not a problem? > Or that there are other attacks that are worse? That you don't need to target DNSSEC authorities, but can use recursive resolvers, and since there are soooo many of those, rate limiting doesn't really matter or help. > > > George > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 11 07:30:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7483A6BF1; Thu, 11 Jun 2009 07:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.109 X-Spam-Level: X-Spam-Status: No, score=-0.109 tagged_above=-999 required=5 tests=[AWL=-0.859, 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 8EezIalowxdD; Thu, 11 Jun 2009 07:30:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C3F8A3A6BCE; Thu, 11 Jun 2009 07:30:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MElEP-000K37-6g for namedroppers-data0@psg.com; Thu, 11 Jun 2009 14:26:17 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MElEE-000Jzs-0s for namedroppers@ops.ietf.org; Thu, 11 Jun 2009 14:26:11 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MElE9-0000KZ-09; Thu, 11 Jun 2009 16:26:01 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MElE8-00047g-I8; Thu, 11 Jun 2009 16:26:00 +0200 From: Florian Weimer To: "George Barwood" Cc: "Nicholas Weaver" , Subject: Re: [dnsext] Hardening DNS using existing protocol elements References: Date: Thu, 11 Jun 2009 16:26:00 +0200 In-Reply-To: (George Barwood's message of "Thu, 11 Jun 2009 14:56:21 +0100") Message-ID: <87eitq979j.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * George Barwood: >> Heck, who's picking on the DNS resolvers that don't do bailywick >> checking right? > > What has bailywick checking got to do with it? Lack of attacks means that it's difficult to justify work on countermeasures. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 11 08:23:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5AEE3A6D11; Thu, 11 Jun 2009 08:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.963 X-Spam-Level: X-Spam-Status: No, score=-4.963 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_URI_DIGITS4=0.415] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyGFwL8AALmZ; Thu, 11 Jun 2009 08:23:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 67C973A6D1D; Thu, 11 Jun 2009 08:23:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEm3a-0003ge-1q for namedroppers-data0@psg.com; Thu, 11 Jun 2009 15:19:10 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEm3J-0003fH-8K for namedroppers@ops.ietf.org; Thu, 11 Jun 2009 15:19:04 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5BFIonp006856; Thu, 11 Jun 2009 08:18:50 -0700 (PDT) From: Nicholas Weaver To: George Barwood In-Reply-To: <5412CCA713A346C6AE93CBC10394273B@localhost> Subject: Re: [dnsext] Hardening DNS using existing protocol elements X-Priority: 3 References: <8B13C905-C120-43DE-A81F-2548EF7294A1@ICSI.Berkeley.EDU> <5412CCA713A346C6AE93CBC10394273B@localhost> Message-Id: <49FB3842-E23C-4559-A985-3739EFA1545A@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 11 Jun 2009 08:18:50 -0700 Cc: Nicholas Weaver , X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 11, 2009, at 7:32 AM, George Barwood wrote: > > That's from the attackers point of view. > From my point of view, I want a secure cache. > I don't want an out-of-path attacker to be able to easily re-route > or sample > my DNS traffic, for example ( we are not just talking DoS ). If this is your objective, then you want the following, even behind a NAT: Run your OWN recursive resolver, with 0x20 enabled, EDNS DISABLED, and the "No race until win" glue policies. EG, unbound: The 0x20 means that you have about +9-12b of entropy for real world names The paranoid glue policy means that the kaminski attack against 0x20 doesn't work (eg, 1111.com can only work to poison 1111.com's record, not the nameserver record for .com). By not having EDNS, you keep the buffer size small so you don't have fragmentation issues. And by running your own resolver, you are too small a target to bother with. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 11 08:32:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA31D3A6D07; Thu, 11 Jun 2009 08:32:25 -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 G0-thXhjmrY6; Thu, 11 Jun 2009 08:32:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B25903A6960; Thu, 11 Jun 2009 08:32:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEmDD-0005Ue-1o for namedroppers-data0@psg.com; Thu, 11 Jun 2009 15:29:07 +0000 Received: from [2001:748:301::2] (helo=shinjuku.zaphods.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEmD1-0005TP-7A for namedroppers@ops.ietf.org; Thu, 11 Jun 2009 15:29:01 +0000 Received: from zaphodb by shinjuku.zaphods.net with local (Exim 4.69) (envelope-from ) id 1MEmD1-0001jc-3o; Thu, 11 Jun 2009 17:28:55 +0200 Date: Thu, 11 Jun 2009 17:28:55 +0200 From: Stefan Schmidt To: Florian Weimer Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Hardening DNS using existing protocol elements Message-ID: <20090611152854.GB29235@zaphods.net> References: <87eitq979j.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87eitq979j.fsf@mid.deneb.enyo.de> X-Origin-AS: AS5430 X-NCC-nic-hdl: ZAP-RIPE User-Agent: Mutt/1.5.19 (2009-01-05) X-bounce-key: BOUNCE_ID;zaphodb@zaphods.net;1244734136;410f46ff; Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 11, 2009 at 04:26:00PM +0200, Florian Weimer wrote: > >> Heck, who's picking on the DNS resolvers that don't do bailywick > >> checking right? The DNS 'community'. > > What has bailywick checking got to do with it? > > Lack of attacks means that it's difficult to justify work on > countermeasures. IIRC the argument most commonly used in the discussion to speed up DNSSEC 'deployment' is that in its current state DNS is prone to Kaminsky-style attacks. I surely hope you still find justification to work on protecting DNS from this kind of attack because in my world good engineering stands for thinking ahead of these things. Stefan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 11 09:30:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5CC23A69DF; Thu, 11 Jun 2009 09:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.534 X-Spam-Level: X-Spam-Status: No, score=-4.534 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKPzg19DepJo; Thu, 11 Jun 2009 09:30:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 993293A67AA; Thu, 11 Jun 2009 09:30:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEn85-000GLw-E6 for namedroppers-data0@psg.com; Thu, 11 Jun 2009 16:27:53 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEn7l-000GKI-Jz for namedroppers@ops.ietf.org; Thu, 11 Jun 2009 16:27:47 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5BGQJtj027800; Thu, 11 Jun 2009 16:26:19 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5BGQJoL027799; Thu, 11 Jun 2009 16:26:19 GMT Date: Thu, 11 Jun 2009 16:26:19 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: bmanning@vacation.karoshi.com, Ask =?iso-8859-1?Q?Bj=F8rn?= Hansen , Jim Reid , namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Message-ID: <20090611162619.GA27750@vacation.karoshi.com.> References: <4D291F23-2937-4A13-A01D-9BD7630E7F32@rfc1035.com> <20090610094943.GB15847@vacation.karoshi.com.> <9E10E125-4953-4095-89FD-D68B357D1CAD@develooper.com> <20090610190009.GB19439@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 10, 2009 at 12:28:04PM -0700, Matthew Dempsky wrote: > On Wed, Jun 10, 2009 at 12:00 PM, wrote: > > well... an IMR may in fact be mixed mode, so its > > not appropriate to call an IMR out by a single transport > > protocol. even if the IMR is dual stack, one can not > > be assured of a clean IPv6 path to all authoritative servers. > > Sorry, can someone clarify what "IMR" stands for? > > Is the terminology being used here that "resolver" means the stub > resolver that sends a query with RD=1 to one of a few caching servers > and expects a complete answer, and "IMR" means the recursive resolver > that sends multiple queries with RD=0 to one of many authoritative > servers? > > In that case, I mean the "resolver" doesn't care what glue data the > authoritative servers give to the "IMR", and the authoritative server > should give glue according to what the "IMR" can best utilize. If the > "IMR" contacted it using IPv4, then obviously the "IMR" can make use > of A record glue data; it's not guaranteed it can make use of AAAA > record glue data. The "resolver"'s IPv4/IPv6 connectivity has no > bearing on how the "IMR" should try to answer a query (except for how > to send the response packet, of course). http://www.cafax.se/dnssec/maillist/2004-05/msg00046.html Interative Mode Resolver. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 11 09:31:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E3E3A6B8C; Thu, 11 Jun 2009 09:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.713 X-Spam-Level: X-Spam-Status: No, score=-4.713 tagged_above=-999 required=5 tests=[AWL=-1.414, 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 V9-8xwr183U1; Thu, 11 Jun 2009 09:31:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8145D3A67AA; Thu, 11 Jun 2009 09:31:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEn6L-000G1K-2S for namedroppers-data0@psg.com; Thu, 11 Jun 2009 16:26:05 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEn62-000Fzi-1E; Thu, 11 Jun 2009 16:25:58 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=NCrXie7U9xXVIM5Vm4wsn3f6Q1chIcbl6ukaI4AqR4T3DUZWdxcn/jon noWTj+CsqasmGs6SeSGM2YooGojf5MeUw7PEBQB6pHieKG/irG7G5PzGZ tyHUEOugEAr+v0V; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1244737546; x=1276273546; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20Hardening=20DNS=20using=20existing=20protocol=20ele ments|Date:=20Thu,=2011=20Jun=202009=2017:25:42=20+0100 |Message-ID:=20|To:=20"George=20Barwood" =20|Cc:=20namedroppers@o ps.ietf.org,=0D=0A=09"Nicholas=20Weaver"=20,=0D=0A=09owner-namedroppers@ops.ietf.org |MIME-Version:=201.0|In-Reply-To:=20<377332A32D684C678896 4B731480D834@localhost>|References:=20=20=20=20<8B13C905-C120-43DE-A81F-2548EF7294A1 @ICSI.Berkeley.EDU>=20<5412CCA713A346C6AE93CBC10394273B@l ocalhost>=20<49FB3842-E23C-4559-A985-3739EFA1545A@ICSI.Be rkeley.EDU>=20<377332A32D684C6788964B731480D834@localhost >; bh=Fe16tZvkATmqYdTXyGMPlJG4ptTRT9yfXh0z4n6O3Bk=; b=Rj0Dd5tJ8cNCgKo7D5LFmW/kgOYho+kq6MilPbkOpIl+HmKUQ7lq+Lyl lsPoXRmdf+kpbfIPDkdBOnDI1KCXcDtsqB3vDQKCbDY+P2uZZ5onwJsK3 HhAthwrO0bNhv5B; X-IronPort-AV: E=Sophos;i="4.42,203,1243810800"; d="scan'208";a="10770694" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 11 Jun 2009 17:25:42 +0100 In-Reply-To: <377332A32D684C6788964B731480D834@localhost> References: <8B13C905-C120-43DE-A81F-2548EF7294A1@ICSI.Berkeley.EDU> <5412CCA713A346C6AE93CBC10394273B@localhost> <49FB3842-E23C-4559-A985-3739EFA1545A@ICSI.Berkeley.EDU> <377332A32D684C6788964B731480D834@localhost> To: "George Barwood" Cc: namedroppers@ops.ietf.org, "Nicholas Weaver" , owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] Hardening DNS using existing protocol elements MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 11 Jun 2009 17:25:42 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 11/06/2009 05:25:44 PM, Serialize complete at 11/06/2009 05:25:44 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > I'm fully aware I must not enable EDNS. > > But now I want to start deploying DNSSEC. I still want security > against out-of-path attacks for unsigned zones. If your upstream recursive resolver is a recent(ish) version of BIND (or Unbound?) with DNSSEC enabled without EDNS0 then you can get some security by setting AD=1 in your queries. You'll not get any DNSSEC related RRs in your answers so your buffer size problems are no worse than now. You will get AD=1 responses for good zones, AD=0 for insecured zones, and SERVFAIL for bogus zones. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 11 09:56:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8CF3A6C54; Thu, 11 Jun 2009 09:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.162 X-Spam-Level: X-Spam-Status: No, score=0.162 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RTklcv9tHF6; Thu, 11 Jun 2009 09:56:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0988C3A6B23; Thu, 11 Jun 2009 09:56:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEnW4-000L80-RD for namedroppers-data0@psg.com; Thu, 11 Jun 2009 16:52:40 +0000 Received: from [209.85.217.220] (helo=mail-gx0-f220.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEnVo-000L6G-Va for namedroppers@ops.ietf.org; Thu, 11 Jun 2009 16:52:30 +0000 Received: by gxk20 with SMTP id 20so2766346gxk.17 for ; Thu, 11 Jun 2009 09:52:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.70.6 with SMTP id s6mr388369aga.57.1244739141508; Thu, 11 Jun 2009 09:52:21 -0700 (PDT) In-Reply-To: <20090611162619.GA27750@vacation.karoshi.com.> References: <4D291F23-2937-4A13-A01D-9BD7630E7F32@rfc1035.com> <20090610094943.GB15847@vacation.karoshi.com.> <9E10E125-4953-4095-89FD-D68B357D1CAD@develooper.com> <20090610190009.GB19439@vacation.karoshi.com.> <20090611162619.GA27750@vacation.karoshi.com.> Date: Thu, 11 Jun 2009 09:52:21 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: bmanning@vacation.karoshi.com Cc: =?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= , Jim Reid , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 11, 2009 at 9:26 AM, wrote: > On Wed, Jun 10, 2009 at 12:28:04PM -0700, Matthew Dempsky wrote: >> Sorry, can someone clarify what "IMR" stands for? > > http://www.cafax.se/dnssec/maillist/2004-05/msg00046.html > > Interative Mode Resolver. Thanks. :-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 11 11:42:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C5228C20B; Thu, 11 Jun 2009 11:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xF+JbYnzevHN; Thu, 11 Jun 2009 11:42:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9AC2A28C1A4; Thu, 11 Jun 2009 11:42:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEp8F-000Coe-8h for namedroppers-data0@psg.com; Thu, 11 Jun 2009 18:36:11 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEp84-000CnV-54 for namedroppers@ops.ietf.org; Thu, 11 Jun 2009 18:36:05 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5BIYttj028547; Thu, 11 Jun 2009 18:34:55 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5BIYtCH028545; Thu, 11 Jun 2009 18:34:55 GMT Date: Thu, 11 Jun 2009 18:34:55 +0000 From: bmanning@vacation.karoshi.com To: Matthew Dempsky Cc: bmanning@vacation.karoshi.com, Jim Reid , namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients Message-ID: <20090611183455.GC28281@vacation.karoshi.com.> References: <4D291F23-2937-4A13-A01D-9BD7630E7F32@rfc1035.com> <20090610094943.GB15847@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 10, 2009 at 10:57:05AM -0700, Matthew Dempsky wrote: > On Wed, Jun 10, 2009 at 2:49 AM, wrote: > > er... "useful" - i'd be interested in learning how auth servers > > are supposed to be prescentient in "knowing" what the IMR is going > > to do with said glue. > > It's a pretty reasonable guess that if I send a "A? www.example.net" > query to a root server and it responds with a delegation to the .net > servers, that I'm going to repeat my query to them. ok... do you care that the query came in over IPv6 and so I, as the root server make the informed guess that the net servers, which have AAAA records, that maybe I should sort the AAAA RR's for .net in the reply? mind, you want the A rr for www.example.net - so your sending a priming query to the root. and your IMR is going to cache the data sent from the root. the IMR will get both AAAA and A RR's for some/all of the .net servers. Your still going to have a couple more sets of recursive queries. You'll next send a query to the .net servers trying to find the A RR for www.example.net - and lo'n'behol... the example.net servers only talk over IPv6 transport. so the response, whatever it might be, will come over IPv6 transport. if the example.net NS set has both AAAA and A rr's, they might send your reply with the AAAA rr's first. then - tada - you get to ask the example.net servers, again over IPv6 transport for the A RR for www.example.net. and since there are no AAAA for www.example.net, you get back the A. just what you asked for. so... what is your IMR is going to cache both A and AAAA rr's for delegation cuts where such things exist. And if your IMR decides to truncate or to force the auth server to truncate the responses to some historically small value - thereby causeing you a loss of data... that sounds like locally induced pain. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From rollers3@pick34.com Thu Jun 11 13:51:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17C93A68CB; Thu, 11 Jun 2009 13:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.003 X-Spam-Level: X-Spam-Status: No, score=-28.003 tagged_above=-999 required=5 tests=[BAYES_80=2, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, GB_OPRAH=2, HELO_DYNAMIC_IPADDR=2.426, HS_INDEX_PARAM=0.001, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pbWYkeNOKoA; Thu, 11 Jun 2009 13:51:10 -0700 (PDT) Received: from c-66-30-77-99.hsd1.ma.comcast.net (c-66-30-77-99.hsd1.ma.comcast.net [66.30.77.99]) by core3.amsl.com (Postfix) with ESMTP id 1BA9F3A68E8; Thu, 11 Jun 2009 13:51:10 -0700 (PDT) Date: Thu, 11 Jun 2009 16:51:16 -0500 Message-Id: From: dnsext-archive@lists.ietf.org To: dnsext-archive@lists.ietf.org Subject: Get Your Free Acai Berry Trial Now Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0

View online version here: here

June 11, 2009
Sign up Forward Archive Advertise
Oprah Weight loss soloution , Learn about Acai Berry.
 
This Newsletter was created for dnsext-archive@lists.ietf.org
Subscriber Tools
Update account information | Change e-mail address | Unsubscribe | Print friendly format | Web version 

¿ 1999-2009 Qsofo, Inc.® Legal Information
 
From owner-namedroppers@ops.ietf.org Thu Jun 11 14:56:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CAB3A6D29; Thu, 11 Jun 2009 14:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.831 X-Spam-Level: * X-Spam-Status: No, score=1.831 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RCVD_IN_NJABL_PROXY=1.643, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dB-Bq4BChKD; Thu, 11 Jun 2009 14:56:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5FEFD3A693A; Thu, 11 Jun 2009 14:56:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEsAy-000HaH-Cn for namedroppers-data0@psg.com; Thu, 11 Jun 2009 21:51:12 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEsAm-000HZI-QZ for namedroppers@ops.ietf.org; Thu, 11 Jun 2009 21:51:06 +0000 Received: (qmail 31512 invoked from network); 11 Jun 2009 23:24:11 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 11 Jun 2009 23:24:11 -0000 Message-ID: <4A317C1E.6010007@necom830.hpcl.titech.ac.jp> Date: Fri, 12 Jun 2009 06:50:22 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Stefan Schmidt CC: Florian Weimer , namedroppers@ops.ietf.org Subject: Re: [dnsext] Hardening DNS using existing protocol elements References: <87eitq979j.fsf@mid.deneb.enyo.de> <20090611152854.GB29235@zaphods.net> In-Reply-To: <20090611152854.GB29235@zaphods.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Stefan Schmidt wrote: >>>What has bailywick checking got to do with it? >> >>Lack of attacks means that it's difficult to justify work on >>countermeasures. > IIRC the argument most commonly used in the discussion to speed up DNSSEC > 'deployment' is that in its current state DNS is prone to Kaminsky-style > attacks. DNSSEC is also prone to Kaminsky-stype attacks. If you have one time access to signature generation mechanism of a zone, you can get a valid signature over false data. The attack is new to DNSSEC easier than modifying zone content and is hardly noticable. With the signature and the data, attacking of DNSSEC is trivially easy. The solution is not to deploy DNSSEC but to protect cache abandoning the broken concept of bailiwick. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 11 17:03:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F61C3A69D7; Thu, 11 Jun 2009 17:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.08 X-Spam-Level: X-Spam-Status: No, score=-5.08 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gujg-IUSKM6o; Thu, 11 Jun 2009 17:03:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0D2E03A67E3; Thu, 11 Jun 2009 17:03:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEu8P-000AID-62 for namedroppers-data0@psg.com; Thu, 11 Jun 2009 23:56:41 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEu8D-000AHX-I7 for namedroppers@ops.ietf.org; Thu, 11 Jun 2009 23:56:35 +0000 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id E63E5A94439; Thu, 11 Jun 2009 23:56:28 +0000 (UTC) Cc: Paul Vixie , Matthew Dempsky , bert hubert , Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: From: Douglas Otis To: Florian Weimer In-Reply-To: <87prdbi3xv.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: SCTP (Re: [dnsext] Re: TCP queries to the root servers ) Date: Thu, 11 Jun 2009 16:56:28 -0700 References: <20090608111014.GA31833@vacation.karoshi.com.> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> <20090609160854.GC25651@shinkuro.com> <20090609182801.GB32546@shinkuro.com> <3efd34cc0906091215t419a6bc3k369067783fdc6266@mail.gmail.com> <80879.1244590583@nsa.vix.com> <87prdbi3xv.fsf@mid.deneb.enyo.de> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 11, 2009, at 1:13 AM, Florian Weimer wrote: > * Paul Vixie: > >> it takes two packets to carry a request and a response, and if they >> are the last request and response in the queue then each of these >> will be followed by an ACK packet. so, a slow 1TPS flow would take >> four packets per transaction, whereas a faster flow would take two >> packets per transaction. the extra ACK-only packets don't delay >> the DNS result, but they do appear on the wire. > > If you use SCTP's retransmit feature, you need in-kernel data > buffers or delays in user space. A new PR-SCTP service might work > around this problem, but it seems to me that some protocol work is > required. PR-SCTP will mean retries are handled by a layer above the transport, just as they are for UDP. For servers, this might conserve resources. Using SCTP_UNORDERED should minimize head of queue blocking and free buffer space sooner. It would be nice to have various access statistics available to assess various strategies that might be used when employing persistent associations. IIRC, the default number of persistent associations supported by the FreeBSD kernel is 40K. Many of our customers access our DNS through an ISP's resolver, where there is more than a two to one reduction of sources for records having 300s TTLs. For our application, no modification of FreeBSD would appear needed. The duration of an inactive association could be regulated by the number of available associations. >> by lightweight i mean that a root or TLD or 2LD/3LD server could >> have many hundred thousands or even millions of associations open, >> all on a single socket and therefore a single file descriptor, so >> it's not a burden on the DNS server's system call interface (think >> of a select() mask here, or a poll() filedes array.) > > If you keep that many idle associations open, your servers will be > busy processing all the associated heartbeat messages. To prevent resource exhaustion whenever multihoming is used, an initial heartbeat confirms alternate paths. For on-going associations, heartbeat rates can be adjusted or turned off. > The one-to-many style interface also needs in-kernel buffers, and it > will be somewhat difficult to control the amount of resources used > by busy resolver. Furthermore, it is explicitly left open in the > sockets API draft whether one receiver behind a one-to-many socket > can block communications to other receivers (see section 4.4 in > draft-ietf-tsvwg-sctpsocket-19). The API supports moving a one-to-many association to a different one- to-one descriptor and establish independent outbound allocations. There is also an SCTP_AUTOCLOSE that might take care of most association housekeeping. The goal should be to retain the most active associations as persistent to ensure minimal latency and somewhat reduced traffic. SCTP's source validation eliminates concerns related to reflected attack, where any increase in traffic should appear small when compared to everything else now going over the Internet. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 12 02:27:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C1D3A6B81; Fri, 12 Jun 2009 02:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=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 Qj2G0Q+C8g19; Fri, 12 Jun 2009 02:27:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 49AA23A6827; Fri, 12 Jun 2009 02:27:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MF2xT-000KC3-Mv for namedroppers-data0@psg.com; Fri, 12 Jun 2009 09:21:59 +0000 Received: from [94.142.245.109] (helo=mx.pipe.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MF2xI-000KBG-9Z for namedroppers@ops.ietf.org; Fri, 12 Jun 2009 09:21:53 +0000 Received: (qmail 96675 invoked by uid 80); 12 Jun 2009 09:21:45 -0000 Received: from 94.142.245.110 (SquirrelMail authenticated user bit@pipe.nl) by mx.pipe.nl with HTTP; Fri, 12 Jun 2009 11:21:45 +0200 (CEST) Message-ID: <61dc26353717325fefa57f328dacdcb3.squirrel@mx.pipe.nl> In-Reply-To: <200906101611.n5AGBq9X045831@stora.ogud.com> References: <200905291557.n4TFv4ek030806@stora.ogud.com> <200906081828.n58ISdRI019464@stora.ogud.com> <200906101611.n5AGBq9X045831@stora.ogud.com> Date: Fri, 12 Jun 2009 11:21:45 +0200 (CEST) Subject: Re: Draft Charter v2. Re: [dnsext] Draft DNSEXT charter From: "Bart Smit" To: "Olafur Gudmundsson" Cc: namedroppers@ops.ietf.org User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: >>Does putting EDNS0 Ping on the list of milestones imply that >>draft-hubert-ulevitch-edns-ping will be adopted as a wg doc? If not, >>what's holding back adoption? > There is enough support in the WG to adopt the work, there is disagreement > on if this is useful or not. ==> WG will adopt the document after it is > updated Maybe I don't understand the way things work around here, but on the one hand you're saying that there is enough support to adopt and on the other that the draft should be updated first. So are we now in a situation where a draft is awaiting comments before having been adopted, or is the somewhat arbitrarily delimited set of comments received thusfar regarded as an amendment to the draft? I ask because keeping in line with my understanding of this wg's operation, I would be withholding any (hypothetical) comments I might have until the draft has been adopted. I just want to understand the procedures. Bart -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 12 07:12:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDBC73A6E27; Fri, 12 Jun 2009 07:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.625 X-Spam-Level: X-Spam-Status: No, score=-0.625 tagged_above=-999 required=5 tests=[AWL=-1.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxBkCP1NkFe5; Fri, 12 Jun 2009 07:12:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D67573A6A3B; Fri, 12 Jun 2009 07:12:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MF7Nm-000M3K-5g for namedroppers-data0@psg.com; Fri, 12 Jun 2009 14:05:26 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MF7NZ-000M1L-M9 for namedroppers@ops.ietf.org; Fri, 12 Jun 2009 14:05:20 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7D6852FE9623 for ; Fri, 12 Jun 2009 14:05:11 +0000 (UTC) Date: Fri, 12 Jun 2009 10:05:08 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: Draft Charter v2. Re: [dnsext] Draft DNSEXT charter Message-ID: <20090612140508.GB36147@shinkuro.com> References: <200905291557.n4TFv4ek030806@stora.ogud.com> <200906081828.n58ISdRI019464@stora.ogud.com> <200906101611.n5AGBq9X045831@stora.ogud.com> <61dc26353717325fefa57f328dacdcb3.squirrel@mx.pipe.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61dc26353717325fefa57f328dacdcb3.squirrel@mx.pipe.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 12, 2009 at 11:21:45AM +0200, Bart Smit wrote: > I ask because keeping in line with my understanding of this wg's > operation, I would be withholding any (hypothetical) comments I might have > until the draft has been adopted. No need to do this. Comment away, please. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From punsterrb294@taiservices.com Fri Jun 12 17:17:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49BB43A696B; Fri, 12 Jun 2009 17:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=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, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_ADLTSUB2=1.23, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg-LLckan-kW; Fri, 12 Jun 2009 17:17:52 -0700 (PDT) Received: from 189-93-145-154.3g.claro.net.br (189-93-145-154.3g.claro.net.br [189.93.145.154]) by core3.amsl.com (Postfix) with ESMTP id 1DB873A6874; Fri, 12 Jun 2009 17:17:50 -0700 (PDT) Message-ID: <000d01c9ebbc$4df59950$6400a8c0@punsterrb294> From: dnsext-archive@lists.ietf.org To: Subject: Acai Berry Can help you Get that slim tight body you dream. Date: Fri, 12 Jun 2009 21:17:15 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9EBBC.4DF59950" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9EBBC.4DF59950 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable View online version here: here =20 =20 =20 =20 =20 =20 June=20 12, 2009 =20 =20 =20 =20 Sign up Forward Archive Advertise =20 =20 =20 =20 Slow down your aging process , Try Acai Berry.=20 take a look =20  This=20 Newsletter was created for dnsext-archive@lists.ietf.org =20 =20 =20 =20 =20 =20 =20 Subscriber=20 Tools =20 Update=A0account=A0information=A0|=20 Change=A0e-mail=A0address=A0| Unsubscribe=A0| Print=A0fri= endly=A0format=A0| Web=A0version=A0 =20 ¿=20 1999-2009 Qsofo, Inc.=AE=A0Legal=20 Information =A0 ------=_NextPart_000_0007_01C9EBBC.4DF59950 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable View online version here: here

June=20 12, 2009 Sign up Forward Archive Advertise
Slow down your aging process= , Try Acai Berry.
take a look<= /FONT>
 This=20 Newsletter was created for dnsext-archive@lists.ietf.org Subscriber=20 Tools
¿=20 1999-2009 Qsofo, Inc.=AE=A0Legal=20 Information
Update=A0account=A0information=A0|=20 Change=A0e-mail=A0address=A0| Unsubscribe=A0| Print=A0friendly=A0format=A0| Web=A0version=A0
=A0
------=_NextPart_000_0007_01C9EBBC.4DF59950-- From lian@advantech.com.br Sat Jun 13 04:02:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBF033A68A2 for ; Sat, 13 Jun 2009 04:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 AzbMKj+nqVzY for ; Sat, 13 Jun 2009 04:02:45 -0700 (PDT) Received: from 189-31-224-52.ctame706.e.brasiltelecom.net.br (189-31-224-52.ctame706.e.brasiltelecom.net.br [189.31.224.52]) by core3.amsl.com (Postfix) with SMTP id 897603A6A1D for ; Sat, 13 Jun 2009 04:02:43 -0700 (PDT) To: dnsext-archive@ietf.org Subject: change your preferences #17704 From: dnsext-archive@ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090613110243.897603A6A1D@core3.amsl.com> Date: Sat, 13 Jun 2009 04:02:43 -0700 (PDT)
Welcome to our site.

Special Offers by email

Dear our client,

You have registered to receive special offers by email. Your first newsletter will be delivered soon.

You may unsubscribe at any time by clicking unsubscribe in the emails you receive, or by visiting www.a51Hd.yuletangy.com.

You may also change your preferences at any time by visiting www.Y5tsi.salthim.com.

Best regards,

First Online Business Brothers.

From jeremiah@aakontext.de Sat Jun 13 10:13:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256483A6831 for ; Sat, 13 Jun 2009 10:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.08 X-Spam-Level: X-Spam-Status: No, score=-23.08 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 MVZ6fpNQ3tA1 for ; Sat, 13 Jun 2009 10:13:21 -0700 (PDT) Received: from abcleads.com (unknown [59.183.38.189]) by core3.amsl.com (Postfix) with SMTP id 6721C3A6807 for ; Sat, 13 Jun 2009 10:13:18 -0700 (PDT) From: "Gerardo Lyons"@core3.amsl.com, dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: I can't find you MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20090613171319.6721C3A6807@core3.amsl.com> Date: Sat, 13 Jun 2009 10:13:18 -0700 (PDT) This Week

Click here to view this message as a web page.

 

Click here if this picture is blocked

Home  |  Contact Us  |  Privacy Policy  |  Terms of Use | Unsubscribe |
From owner-namedroppers@ops.ietf.org Sat Jun 13 19:31:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AB0A3A68AF; Sat, 13 Jun 2009 19:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.354 X-Spam-Level: X-Spam-Status: No, score=-0.354 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-RK189-rtT4; Sat, 13 Jun 2009 19:31:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 67D723A6805; Sat, 13 Jun 2009 19:31:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFfOf-000E5N-Fl for namedroppers-data0@psg.com; Sun, 14 Jun 2009 02:24:37 +0000 Received: from [208.218.130.12] (helo=gis.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFfOU-000E4X-KX for namedroppers@ops.ietf.org; Sun, 14 Jun 2009 02:24:32 +0000 Received: from [127.0.0.1] ([63.209.233.96]) by mx04.gis.net; Sat, 13 Jun 2009 22:24:14 -0400 Message-ID: <4A345F4D.2010404@gis.net> Date: Sat, 13 Jun 2009 22:24:13 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: TCP queries to the root servers References: <60257A6B-C35B-4477-8183-01C4499C08FB@rfc1035.com> <8763f7fdo2.fsf@mid.deneb.enyo.de> <20090608111014.GA31833@vacation.karoshi.com.> <7062EC09-F98E-4803-B509-B9AE7DE43EF8@virtualized.org> <1244474011.4151.13009.camel@shane-asus-laptop> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> In-Reply-To: <60184.1244560661@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: >> From: bert hubert >> Date: Tue, 9 Jun 2009 09:47:34 +0200 >> >> With a hostile service provider, all bets are off. The best thing one >> can do in that case is make sure you don't get *any* answers. So it >> does not make a lot of sense to ponder this situation for protocol >> design, or even operational guidelines. > > of course. however, making local root name service universal, is going > to engender a lot more opportunistic hostility along these lines. since > there's no operational problem being solved by it, and since the failure > modes include "becoming out of date" in a dozen ways, and since there > is almost nothing one can say the root zone needs that many 2LD's and > some 3LD's also need, this whole thread is "twilight zone" territory. But isn't a signed root zone going to cause problems for such providers? They are presumably changing the contents and therefore the signature will no longer match the contents and you will likely get dnssec failures. After all isn't that the intent of DNSSEC signing of the root zone? If they go ahead with their own resigning will that "fix" the problem or continue to invalidate all the signed zones down the hierarchy? Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 14 11:42:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358673A6A42; Sun, 14 Jun 2009 11:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziQB7lp4kx6k; Sun, 14 Jun 2009 11:42:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B0D73A687F; Sun, 14 Jun 2009 11:42:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFuY2-0003lP-T0 for namedroppers-data0@psg.com; Sun, 14 Jun 2009 18:35:18 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFuXn-0003jZ-93 for namedroppers@psg.com; Sun, 14 Jun 2009 18:35:12 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5EIZ0dD020925 for ; Sun, 14 Jun 2009 14:35:01 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906141835.n5EIZ0dD020925@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 14 Jun 2009 14:33:58 -0400 To: namedroppers@psg.com From: Olafur Gudmundsson Subject: [dnsext] New rules for DO bit Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: To follow up on the discussion from the last two weeks here is a draft to explicitly outlaw setting of DO bit of with buff size < 1220. http://tools.ietf.org/html/draft-gudmundsson-dnsext-setting-ends0-do-bit-00 The draft also has another protocol change related to responders Intended Status: Standard Track O. Gudmundsson Network Working Group Shinkuro, Inc. Internet-Draft June 13, 2009 Updates: 4035 (if approved) Intended status: Standards Track Expires: December 15, 2009 DNSSEC OK buffer minimum size requirment and error handling draft-gudmundsson-dnsext-setting-ends0-do-bit-00 Abstract RFC3226 mandated support for EDNS0 in DNS entities claiming to support either DNS Security Extensions or IPv6 address records. This requirement was motivated because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 14 12:25:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117953A67B1; Sun, 14 Jun 2009 12:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.256 X-Spam-Level: X-Spam-Status: No, score=-0.256 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qLYUIvBobt8; Sun, 14 Jun 2009 12:25:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D006C3A6A89; Sun, 14 Jun 2009 12:25:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFvGJ-0007IP-3i for namedroppers-data0@psg.com; Sun, 14 Jun 2009 19:21:03 +0000 Received: from [209.86.89.64] (helo=elasmtp-curtail.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFvG1-0007Gd-9W for namedroppers@psg.com; Sun, 14 Jun 2009 19:20:57 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=X7vTozwxuI0w9Wnj0Rj78uRaqiBtjC2iuup/P/T7X5CsdJaEj7wqDXVVRQWEUCwo; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.96.18] (helo=ix.netcom.com) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MFvFz-0004sS-3u; Sun, 14 Jun 2009 15:20:43 -0400 Message-ID: <4A354D78.51DB571F@ix.netcom.com> Date: Sun, 14 Jun 2009 12:20:24 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Olafur Gudmundsson CC: namedroppers@psg.com Subject: Re: [dnsext] New rules for DO bit References: <200906141835.n5EIZ0dD020925@stora.ogud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606886a447f32eddb125f491f15f5ac4afc35350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.96.18 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Olafur and all, I didn't know the IETF was a legislative body of any sort. ??? Where is the consensus that 1220 is bad? Olafur Gudmundsson wrote: > To follow up on the discussion from the last two weeks here is a > draft to explicitly outlaw setting of DO bit of with buff size < 1220. > > http://tools.ietf.org/html/draft-gudmundsson-dnsext-setting-ends0-do-bit-00 > > The draft also has another protocol change related to responders > > Intended Status: Standard Track O. Gudmundsson > Network Working Group Shinkuro, Inc. > Internet-Draft June 13, 2009 > Updates: 4035 (if approved) > Intended status: Standards Track > Expires: December 15, 2009 > > DNSSEC OK buffer minimum size requirment and error handling > draft-gudmundsson-dnsext-setting-ends0-do-bit-00 > > Abstract > RFC3226 mandated support for EDNS0 in DNS entities claiming to > support either DNS Security Extensions or IPv6 address records. This > requirement was motivated because these new features increase the > size of DNS messages. If EDNS0 is not supported fall back to TCP > will happen, having a detrimental impact on query latency and DNS > server load. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From remorselesst0@polycom-trade.com Sun Jun 14 12:42:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E753A6A90; Sun, 14 Jun 2009 12:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.019 X-Spam-Level: X-Spam-Status: No, score=-15.019 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_DB=0.888, FS_WEIGHT_LOSS=2.134, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_SE=0.35, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 h9vy4QO3cNNP; Sun, 14 Jun 2009 12:42:34 -0700 (PDT) Received: from 1-1-4-19a.goe.gbg.bostream.se (1-1-4-19a.goe.gbg.bostream.se [82.182.96.215]) by core3.amsl.com (Postfix) with ESMTP id 09D8A3A68F2; Sun, 14 Jun 2009 12:42:32 -0700 (PDT) Message-ID: <000d01c9ed28$47226140$6400a8c0@remorselesst0> From: dnsext-archive@lists.ietf.org To: Subject: Amazing weight loss now you can get it FREE Date: Sun, 14 Jun 2009 21:42:40 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9ED28.47226140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9ED28.47226140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable View online version here: here =20 =20 =20 =20 =20 =20 June=20 14, 2009 =20 =20 =20 =20 Sign up Forward Archive Advertise =20 =20 =20 =20 Acai Berry your solution to losing weight quickly. A smart click =20  This=20 Newsletter was created for dnsext-archive@lists.ietf.org =20 =20 =20 =20 =20 =20 =20 Subscriber=20 Tools =20 Update=A0account=A0information=A0|=20 Change=A0e-mail=A0address=A0| Unsubscribe=A0| Print=A0fri= endly=A0format=A0| Web=A0version=A0 =20 ¿=20 1999-2009 Qsofo, Inc.=AE=A0Legal=20 Information =A0 ------=_NextPart_000_0007_01C9ED28.47226140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable View online version here: here

June=20 14, 2009 Sign up Forward Archive Advertise
Acai Berry your solution to= losing weight quickly.
A smart cl= ick
 This=20 Newsletter was created for dnsext-archive@lists.ietf.org Subscriber=20 Tools
¿=20 1999-2009 Qsofo, Inc.=AE=A0Legal=20 Information
Update=A0account=A0information=A0|=20 Change=A0e-mail=A0address=A0| Unsubscribe=A0| Print=A0friendly=A0format=A0| Web=A0version=A0
=A0
------=_NextPart_000_0007_01C9ED28.47226140-- From owner-namedroppers@ops.ietf.org Sun Jun 14 13:51:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57C093A69D8; Sun, 14 Jun 2009 13:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.246 X-Spam-Level: X-Spam-Status: No, score=0.246 tagged_above=-999 required=5 tests=[AWL=-1.587, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7YD3xQQe9-w; Sun, 14 Jun 2009 13:51:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6FE513A65A6; Sun, 14 Jun 2009 13:51:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFwYY-000E0t-9N for namedroppers-data0@psg.com; Sun, 14 Jun 2009 20:43:58 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MFwYN-000DzQ-9N for namedroppers@psg.com; Sun, 14 Jun 2009 20:43:52 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MFwYK-0000Ii-OI; Sun, 14 Jun 2009 22:43:44 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MFwYK-0007WT-4B; Sun, 14 Jun 2009 22:43:44 +0200 From: Florian Weimer To: Olafur Gudmundsson Cc: namedroppers@psg.com Subject: Re: [dnsext] New rules for DO bit References: <200906141835.n5EIZ0dD020925@stora.ogud.com> Date: Sun, 14 Jun 2009 22:43:44 +0200 In-Reply-To: <200906141835.n5EIZ0dD020925@stora.ogud.com> (Olafur Gudmundsson's message of "Sun, 14 Jun 2009 14:33:58 -0400") Message-ID: <87iqiy5ywv.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Olafur Gudmundsson: > To follow up on the discussion from the last two weeks here is a > draft to explicitly outlaw setting of DO bit of with buff size < 1220. I think the assumption in section 3 is wrong. At least two resolver implementations haven't got a DO/non-DO cache separation and can't provide DNSSEC data to a client if it was not originally put into the cache. From what I've heard, this is difficult to change. The proposed change is risky for popular zones because BIND will requery immediately (at a rate of 1/RTT) when the response lacks DNSSEC records expected as the result of local configuration or a secure delegation. By the way, I'm pretty sure that the reason for the DO flag wasn't packet size, as you suggest, but the desire not to confuse resolvers with additional data at odd places in the response packet. Section 2.2 seems to imply that the root does not support EDNS0, but it actually does: ; <<>> DiG 9.6.0-P1 <<>> @a.root-servers.net . NS +bufsize=4096 +norecurse ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33462 ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 21 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS E.ROOT-SERVERS.NET. [...] M.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:dc3::35 ;; Query time: 171 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Sun Jun 14 22:36:01 2009 ;; MSG SIZE rcvd: 643 So even the priming reply is larger than 512 bytes nowadays. If the traffic increase for a signed root is a concern, it could be served from separate IP addresses (requiring new hints), so that the ramp-up would be a bit more gradual. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 14 18:02:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870DE3A6B08; Sun, 14 Jun 2009 18:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.456 X-Spam-Level: X-Spam-Status: No, score=-4.456 tagged_above=-999 required=5 tests=[AWL=-0.804, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_QP_LONG_LINE=1.396, 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 TThsKadDz2+Z; Sun, 14 Jun 2009 18:02:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A9D63A69B6; Sun, 14 Jun 2009 18:02:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG0Vv-0007CZ-5X for namedroppers-data0@psg.com; Mon, 15 Jun 2009 00:57:31 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG0Vi-0007BH-SU for namedroppers@psg.com; Mon, 15 Jun 2009 00:57:25 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5F0umbw026631; Sun, 14 Jun 2009 17:56:49 -0700 (PDT) From: Nicholas Weaver To: "George Barwood" In-Reply-To: <6B75206D24B84A2BA5703B33183D5203@localhost> Subject: Re: [dnsext] New rules for DO bit X-Priority: 3 References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <6B75206D24B84A2BA5703B33183D5203@localhost> Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 14 Jun 2009 17:56:48 -0700 Cc: Nicholas Weaver , , "Olafur Gudmundsson" X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 14, 2009, at 4:20 PM, George Barwood wrote: > =46rom the draft: > > "What seems to be happening is that resolver implementations have =20 > discovered that ENDS0 > with buffer size of 4096 is sometimes silently dropped and fall =20 > back to < 1220 in an attempt to get messages through." > > Is the reason known for the silent dropping? > > At a guess, it would be due to packets exceeding the internet MTU =20 > size of 1500 bytes. Well, the Ethernet MTU, with is something of a De-facto Internet MTU. What happens is some device won't fragment when they should, some =20 devices won't reassemble properly when they should (*cough* firewalls/=20= nats *cough*), etc. So although a host may advertise EDNS0 support, it can't actually =20 properly receive a large request. (This is one of the things we test for in netalyzr, BTW). Its =20 unfortunatly very common. > > I wonder if some protocol extension could be defined so that large =20 > responses can be sent over UDP > in several packets, to avoid problems with fragmentation. I'm no =20 > expert in IP fragmentation, but is it > the case that normally fragmentation does not occur, so faulty =20 > implementations are likely to have arisen > unnoticed, and therefore relying on it for transporting DNSKEY =20 > rrsets may be unrealistic. > > That said, the limited aim of the draft seems sensible, as a =20 > practical measure. > > ----- Original Message ----- > From: "Olafur Gudmundsson" > To: > Sent: Sunday, June 14, 2009 7:33 PM > Subject: [dnsext] New rules for DO bit > > >> To follow up on the discussion from the last two weeks here is a >> draft to explicitly outlaw setting of DO bit of with buff size < =20 >> 1220. >> >> = http://tools.ietf.org/html/draft-gudmundsson-dnsext-setting-ends0-do-bit-0= 0 >> >> The draft also has another protocol change related to responders >> >> >> Intended Status: Standard Track O. =20 >> Gudmundsson >> Network Working Group Shinkuro, =20= >> Inc. >> Internet-Draft June 13, =20= >> 2009 >> Updates: 4035 (if approved) >> Intended status: Standards Track >> Expires: December 15, 2009 >> >> >> DNSSEC OK buffer minimum size requirment and error handling >> draft-gudmundsson-dnsext-setting-ends0-do-bit-00 >> >> Abstract >> RFC3226 mandated support for EDNS0 in DNS entities claiming to >> support either DNS Security Extensions or IPv6 address records. =20= >> This >> requirement was motivated because these new features increase the >> size of DNS messages. If EDNS0 is not supported fall back to TCP >> will happen, having a detrimental impact on query latency and DNS >> server load. >> >> >> >> >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org =20= >> with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> =C3=BF=C3=BBh=C2=BA{.n=C3=87+=E2=89=88=C2=B7=C2=ACzwZ=CB=99=C3=AB,j=07=E2= =80=93=20 >> =C2=A2v=C5=93y=C3=9A=C3=A8=C5=93=CB=9C=C2=AB=E2=80=9C=C3=BA=EF=AC=81=C2= =AA=C3=A7=C2=AC=C2=B7=C3=BA)=E2=80=9C=C3=B8=C4=B1=C2=B5=C3=BF=C3=A8=C2=AE=0C= "=C2=B6=1Ba{ > +w=C3=BB=C2=A7=E2=80=9D=C3=A6=C3=ACr=C2=B8=CB=9D{=C3=B8=C2=A7j=C3=88=C2=A7= =E2=89=A0W=C2=A5=E2=80=A6w=CB=9A=E2=80=9D=C3=98^=CB=99=C3=AB,j=07=E2=80=93= {=1B[=C2=A1=C3=9C=C3=BFj=C2=B7!=20 > =E2=80=A6=C3=B7=C3=BF=EF=AC=82=1Bm=C2=A7=C3=BF=C3=BF=C2=A2=CB=9D=C3=BF=E2= =89=88=C3=AB_=EF=AC=82=E2=80=A6=C3=A0=EF=AC=82X=C2=AC=C2=B6=C3=8F=C3=A7jg=CB= =87=C2=AE=E2=80=A6iz=C2=BB? > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 14 18:23:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ED3C3A6820; Sun, 14 Jun 2009 18:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[AWL=-0.507, 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 hD6c846+-1J8; Sun, 14 Jun 2009 18:23:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D6163A67E3; Sun, 14 Jun 2009 18:23:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG0rB-0008v9-2B for namedroppers-data0@psg.com; Mon, 15 Jun 2009 01:19:29 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG0r0-0008u5-4S for namedroppers@psg.com; Mon, 15 Jun 2009 01:19:23 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5F1JE6b095216; Sun, 14 Jun 2009 21:19:14 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906150119.n5F1JE6b095216@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 14 Jun 2009 21:18:55 -0400 To: Florian Weimer , Olafur Gudmundsson From: Olafur Gudmundsson Subject: Re: [dnsext] New rules for DO bit Cc: namedroppers@psg.com In-Reply-To: <87iqiy5ywv.fsf@mid.deneb.enyo.de> References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 16:43 14/06/2009, Florian Weimer wrote: >* Olafur Gudmundsson: > > > To follow up on the discussion from the last two weeks here is a > > draft to explicitly outlaw setting of DO bit of with buff size < 1220. > >I think the assumption in section 3 is wrong. At least two resolver >implementations haven't got a DO/non-DO cache separation and can't >provide DNSSEC data to a client if it was not originally put into the >cache. From what I've heard, this is difficult to change. This is exactly the reason why the draft specifies that the DO bit be cleared in response when the server does not fit the DNSSEC answer into the <1220 buffer advertised. >The proposed change is risky for popular zones because BIND will >requery immediately (at a rate of 1/RTT) when the response lacks >DNSSEC records expected as the result of local configuration or a >secure delegation. Bind is the biggest offender of setting DO =1 && buff_size < 1220. >By the way, I'm pretty sure that the reason for the DO flag wasn't >packet size, as you suggest, but the desire not to confuse resolvers >with additional data at odd places in the response packet. It was both. >Section 2.2 seems to imply that the root does not support EDNS0, but >it actually does: Looks like I need to fix the wording in the next version :-) This is the query that has me most worried dig doesnotexistatall.gov. ptr +dnssec ... ;; MSG SIZE rcvd: 1513 it is > 1500 bytes long because they use NSEC3 and Zone Signing keys that is 2048 bits long. (Org's negative answer is only 1007 bytes. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 14 18:50:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A6603A6BEC; Sun, 14 Jun 2009 18:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.116 X-Spam-Level: X-Spam-Status: No, score=-5.116 tagged_above=-999 required=5 tests=[AWL=-0.068, 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 3+gT8J01Xq54; Sun, 14 Jun 2009 18:50:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 610A13A6ADB; Sun, 14 Jun 2009 18:50:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG1GN-000B0k-7G for namedroppers-data0@psg.com; Mon, 15 Jun 2009 01:45:31 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG1G8-000AzN-6C for namedroppers@psg.com; Mon, 15 Jun 2009 01:45:25 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5F1ikOR001756; Sun, 14 Jun 2009 18:44:46 -0700 (PDT) Cc: Nicholas Weaver , George Barwood , namedroppers@psg.com, Olafur Gudmundsson Message-Id: From: Nicholas Weaver To: Michael Graff In-Reply-To: <4A35A177.7020005@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] New rules for DO bit Date: Sun, 14 Jun 2009 18:44:45 -0700 References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <6B75206D24B84A2BA5703B33183D5203@localhost> <4A35A177.7020005@isc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 14, 2009, at 6:18 PM, Michael Graff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Nicholas Weaver wrote: > >> (This is one of the things we test for in netalyzr, BTW). Its >> unfortunatly very common. > > Do you have any data showing that a 1220-byte packet might make it, > where a 4096 one will not? Not yet, but I can add it in. Currently the Netalyzr test is as ~1800B response... I can easily add in a 1200B response to see if that does make it through OK. nweaver% dig +dnssec edns_large.netalyzr.icsi.berkeley.edu @roland.icir.org ; <<>> DiG 9.4.3-P1 <<>> +dnssec edns_large.netalyzr.icsi.berkeley.edu @roland.icir.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39944 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 21 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;edns_large.netalyzr.icsi.berkeley.edu. IN A ;; ANSWER SECTION: edns_large.netalyzr.icsi.berkeley.edu. 1 IN A 192.150.187.31 ;; AUTHORITY SECTION: netalyzr.icsi.berkeley.edu. 10 IN NS roland.icir.org. netalyzr.icsi.berkeley.edu. 100 IN NS return_false.netalyzr.icsi.berkeley.edu. ;; ADDITIONAL SECTION: roland.icir.org. 10 IN A 192.150.187.31 filler0.netalyzr.icsi.berkeley.edu. 100 IN CNAME return_false .this .is .random .filler.ballast.to.make.the.response.big0.netalyzr.icsi.berkeley.edu. filler1.netalyzr.icsi.berkeley.edu. 100 IN CNAME return_false .this .is .random .filler.ballast.to.make.the.response.big1.netalyzr.icsi.berkeley.edu. .... ;; Query time: 29 msec ;; SERVER: 192.150.187.31#53(192.150.187.31) ;; WHEN: Sun Jun 14 18:42:54 2009 ;; MSG SIZE rcvd: 1824 > > - --Michael > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAko1oXYACgkQ+NNi0s9NRJ3iXACfYsfnUzMlIGAnA/ZpC+wL7kp2 > a0kAn3Wz5L5pmtaHzeWZQyU5aqHFuDfL > =/l5T > -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 14 20:27:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DAD23A6ADB; Sun, 14 Jun 2009 20:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 F4s8iIuszEtY; Sun, 14 Jun 2009 20:27:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5512F3A6805; Sun, 14 Jun 2009 20:27:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG2kM-000HgE-4E for namedroppers-data0@psg.com; Mon, 15 Jun 2009 03:20:34 +0000 Received: from [208.218.130.13] (helo=gis.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG2k9-000HfB-RA for namedroppers@ops.ietf.org; Mon, 15 Jun 2009 03:20:28 +0000 Received: from [127.0.0.1] ([63.209.233.96]) by mx05.gis.net; Sun, 14 Jun 2009 23:20:15 -0400 Message-ID: <4A35BDE2.3080507@gis.net> Date: Sun, 14 Jun 2009 23:20:02 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Matthew Dempsky CC: =?ISO-8859-1?Q?Ondr=28ej_Sur=FD?= , Andreas Gustafsson , bmanning@vacation.karoshi.com, Mark Andrews , namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Matthew Dempsky wrote: > On Wed, Jun 10, 2009 at 9:57 AM, Ondøej Surý wrote: >> Asking over IPv4 doesn't imply you are not IPv6 capable. > > There are two sets of resolvers that will contact the root servers > over IPv4: IPv4-only resolvers and dual-stack IPv4/IPv6 resolvers. A > records are useful to both sets of resolvers, whereas AAAA records are > only useful to the second set. > > Mark Andrews has already pointed out that IPv6 nodes SHOULD* support > EDNS0, so these resolvers will be able to get all A and AAAA glue by > advertising a larger buffer size. Serving A records in preference to > AAAA records for queries over IPv4 avoids causing legacy resolvers to > have to send additional queries to the root servers. There is a really bad assumption here: that the resolvers are the consumers of the resulting A and AAAA records. The real consumer is the application initiating the request of the resolver for an address. The application may well be IPv6 capable and/or IPv4 capable but the servers won't know that or have any way of knowing that. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 14 20:32:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4BE23A6A4C; Sun, 14 Jun 2009 20:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.159 X-Spam-Level: X-Spam-Status: No, score=0.159 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIUPssWT-wE5; Sun, 14 Jun 2009 20:32:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 99DEA3A6805; Sun, 14 Jun 2009 20:32:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG2rf-000IP7-7j for namedroppers-data0@psg.com; Mon, 15 Jun 2009 03:28:07 +0000 Received: from [209.85.210.185] (helo=mail-yx0-f185.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG2rR-000IMa-T2 for namedroppers@ops.ietf.org; Mon, 15 Jun 2009 03:28:01 +0000 Received: by yxe15 with SMTP id 15so1692036yxe.5 for ; Sun, 14 Jun 2009 20:27:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.115.17 with SMTP id n17mr5857276agc.36.1245036440851; Sun, 14 Jun 2009 20:27:20 -0700 (PDT) In-Reply-To: <4A35BDE2.3080507@gis.net> References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> <4A35BDE2.3080507@gis.net> Date: Sun, 14 Jun 2009 20:27:20 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: mayer@gis.net Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sun, Jun 14, 2009 at 8:20 PM, Danny Mayer wrote: > There is a really bad assumption here: that the resolvers are the > consumers of the resulting A and AAAA records. For delegation glue records, the resolver is the consumer. > The real consumer is the > application initiating the request of the resolver for an address. When you type "http://www.google.com" into your web browser, your web browser does not care at all what address records the root server gave for a.gtld-servers.net to the resolver; only the resolver cares. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 14 22:35:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0735A3A6C66; Sun, 14 Jun 2009 22:35:50 -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.924, 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 u-WLcR3Kj5JI; Sun, 14 Jun 2009 22:35:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E9E113A6C09; Sun, 14 Jun 2009 22:35:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG4lz-0002eO-5R for namedroppers-data0@psg.com; Mon, 15 Jun 2009 05:30:23 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG4lm-0002cn-TX for namedroppers@ops.ietf.org; Mon, 15 Jun 2009 05:30:17 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MG4li-0003IC-Du; Mon, 15 Jun 2009 07:30:06 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MG4li-0002Ul-42; Mon, 15 Jun 2009 07:30:06 +0200 From: Florian Weimer To: Matthew Dempsky Cc: mayer@gis.net, namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> <4A35BDE2.3080507@gis.net> Date: Mon, 15 Jun 2009 07:30:06 +0200 In-Reply-To: (Matthew Dempsky's message of "Sun, 14 Jun 2009 20:27:20 -0700") Message-ID: <87ws7enjxd.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Matthew Dempsky: > On Sun, Jun 14, 2009 at 8:20 PM, Danny Mayer wrote: >> There is a really bad assumption here: that the resolvers are the >> consumers of the resulting A and AAAA records. > > For delegation glue records, the resolver is the consumer. And those records should never be promoted to an answer section. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 14 23:00:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A093A68EA; Sun, 14 Jun 2009 23:00:03 -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 xgJ4Un6GQTsZ; Sun, 14 Jun 2009 23:00:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5ADCC3A6834; Sun, 14 Jun 2009 23:00:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG58x-0004lp-CC for namedroppers-data0@psg.com; Mon, 15 Jun 2009 05:54:07 +0000 Received: from [2607:f140:ffff:ffff::239] (helo=malcolm.berkeley.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG58W-0004ix-C3 for namedroppers@ops.ietf.org; Mon, 15 Jun 2009 05:54:01 +0000 Received: from new-host.home (pool-173-75-216-194.phlapa.fios.verizon.net [173.75.216.194]) (authenticated bits=0) by malcolm.berkeley.edu (8.14.3/8.13.8m1) with ESMTP id n5F5rW6V038620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jun 2009 22:53:34 -0700 (PDT) (envelope-from michael@rancid.berkeley.edu) Message-ID: <4A35E1D7.3030205@rancid.berkeley.edu> Date: Sun, 14 Jun 2009 22:53:27 -0700 From: Michael Sinatra User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Matthew Dempsky CC: =?windows-1252?Q?Ondr=28ej_Sur=FD?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients References: <7532B5B4-2F5C-4CB4-82E4-4781FEEA808A@ICSI.Berkeley.EDU> <75CCCDF9-47BE-4285-8A88-1B9EEF443EB1@ICSI.Berkeley.EDU> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9466/Sun Jun 14 18:16:34 2009 on malcolm.berkeley.edu X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (malcolm.berkeley.edu [128.32.206.239]); Sun, 14 Jun 2009 22:53:35 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 6/10/09 1:00 PM, Matthew Dempsky wrote: >> Just a short I-D that states DNS servers SHOULD include A record glue >> data in preference to AAAA record glue data when doing additional >> section processing for NS records in response to a query sent over >> IPv4 without an EDNS0 OPT record? > > Also, before I go to this effort, is there anyone on this mailing list > that actually supports such an I-D? So far, the responses seem to be > very emotionally against. As someone with more of an operational background, I do not care to have the protocol (or even the operation of the root nameservers) changed to make life slightly better for one implementation, when there are multiple independent implementations that don't seem to have a problem with A and AAAA glue. The caching resolvers I operate are all dual-stack, so I'd rather not put an additional layer of complexity in the protocol or in the operation of the roots, and making the answers dependent on the transport protocol adds complexity. I think your fix is worse than the problem. I wouldn't support such an I-D, but I am not really the one to ask--I am more of an ops person and this is my first post to this list, after years of lurking. michael -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 02:59:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB4A23A6914; Mon, 15 Jun 2009 02:59:39 -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 t2Deb30N2W8M; Mon, 15 Jun 2009 02:59:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A37933A6C08; Mon, 15 Jun 2009 02:59:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG8sP-000OgH-1Y for namedroppers-data0@psg.com; Mon, 15 Jun 2009 09:53:17 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG8sD-000Oep-8U for namedroppers@psg.com; Mon, 15 Jun 2009 09:53:11 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n5F9qwNd051684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2009 11:52:58 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A3619FA.5090404@nlnetlabs.nl> Date: Mon, 15 Jun 2009 11:52:58 +0200 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Olafur Gudmundsson CC: Florian Weimer , namedroppers@psg.com Subject: Re: [dnsext] New rules for DO bit References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> In-Reply-To: <200906150119.n5F1JE6b095216@stora.ogud.com> X-Enigmail-Version: 0.95.7 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.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 15 Jun 2009 11:52:58 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Olafur, Olafur Gudmundsson wrote: > At 16:43 14/06/2009, Florian Weimer wrote: >> * Olafur Gudmundsson: >> >> > To follow up on the discussion from the last two weeks here is a >> > draft to explicitly outlaw setting of DO bit of with buff size < 1220. The draft is overcomplicated as it stands now. I propose this: All DNSSEC compliant severs MAY treat ENDS0 queries with DO bit set and the buffer size set to less 1220, as error in the query and return FORMERR. This is so close to the current spec, the draft is not really necessary and it can go into dnssec-bis-updates as a clarification. (If this draft becomes standard it'll get implemented for unbound of course). It is also much simpler. The if-statement 'truncation would be caused' complicates way too much, for no real benefit. Also a FORMERR causes the server to be cached as EDNS0-noncompliant in those resolvers. And the resolver can try again later without EDNS0, or have some internal logic to handle non-EDNS0 servers. (for example, if only one server in the NS set has the problem, it gets blacklisted as not DNSSEC aware, and failover to other servers happens, I think both BIND and unbound have such logic. For example the path to one .org server caps at 512, but other paths do not, then this can cause bind to get smart and avoid the 'edns0-noncompliant' .org server). Also I have a question about the security considerations, which states that some implementation is vulnerable to a downgrade, and will go to insecure if signatures are removed. So, this is a broken implementation, I do not think it merits a security consideration. Or state more strongly that this thing is badly broken. This security consideration must not give the impression that such broken behaviour is to be condoned, or should be catered for in the protocol specs. What I would have expected to see in the security considerations is that for both the method in the draft and the FORMERR return, the zone can go completely bogus for resolvers that tried to do EDNS@512 and DNSSEC validation. (say .org anchor loaded into BIND using EDNS0@512). The idea is that such software has to be updated to work. (or possibly such a resolver may have a secondary path to another nameserver that does not have the 512-limit imposed, and falls back to that, then DNSSEC validation works (and better than before) ). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAko2GfkACgkQkDLqNwOhpPjgKQCeMneIsHbpDHGj2+7HvGTsusji yuQAoJrHOwvSFJgeh3/sdOnw0yrsHIif =TSwT -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 03:40:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A0113A6CB9; Mon, 15 Jun 2009 03:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.108 X-Spam-Level: X-Spam-Status: No, score=-0.108 tagged_above=-999 required=5 tests=[AWL=-0.858, 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 ArWl47PsNt5o; Mon, 15 Jun 2009 03:40:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 36E8D3A6BBB; Mon, 15 Jun 2009 03:40:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG9WH-0002RD-Fh for namedroppers-data0@psg.com; Mon, 15 Jun 2009 10:34:29 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG9W6-0002Pp-6Y for namedroppers@psg.com; Mon, 15 Jun 2009 10:34:23 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MG9W1-0008Pe-UX; Mon, 15 Jun 2009 12:34:14 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MG9W1-0003qP-Ik; Mon, 15 Jun 2009 12:34:13 +0200 From: Florian Weimer To: Olafur Gudmundsson Cc: namedroppers@psg.com Subject: Re: [dnsext] New rules for DO bit References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> Date: Mon, 15 Jun 2009 12:34:13 +0200 In-Reply-To: <200906150119.n5F1JE6b095216@stora.ogud.com> (Olafur Gudmundsson's message of "Sun, 14 Jun 2009 21:18:55 -0400") Message-ID: <87fxe1lra2.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Olafur Gudmundsson: > At 16:43 14/06/2009, Florian Weimer wrote: >>* Olafur Gudmundsson: >> >> > To follow up on the discussion from the last two weeks here is a >> > draft to explicitly outlaw setting of DO bit of with buff size < 1220. >> >>I think the assumption in section 3 is wrong. At least two resolver >>implementations haven't got a DO/non-DO cache separation and can't >>provide DNSSEC data to a client if it was not originally put into the >>cache. From what I've heard, this is difficult to change. > > This is exactly the reason why the draft specifies that the DO bit > be cleared in response when the server does not fit the DNSSEC answer > into the <1220 buffer advertised. The DO bit is not signed (even if you don't strip signatures), so such a reply has to more or less disregarded if you expect a secure answer. >>The proposed change is risky for popular zones because BIND will >>requery immediately (at a rate of 1/RTT) when the response lacks >>DNSSEC records expected as the result of local configuration or a >>secure delegation. > > Bind is the biggest offender of setting DO =1 && buff_size < 1220. Sure. I'll try to change our distribution if necessary, but I fear that this dispute will turn into something close to a shouting match between BIND resolvers and authoritative servers which implement the old (and new) behavior. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 04:22:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861533A6C08; Mon, 15 Jun 2009 04:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 5pyhvwxeRCMv; Mon, 15 Jun 2009 04:22:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C12F3A6B1E; Mon, 15 Jun 2009 04:22:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGABf-0007B0-43 for namedroppers-data0@psg.com; Mon, 15 Jun 2009 11:17:15 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGABT-00079s-Pc for namedroppers@psg.com; Mon, 15 Jun 2009 11:17:09 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 6B74BA5A67 for ; Mon, 15 Jun 2009 11:17:03 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@psg.com Subject: Re: [dnsext] New rules for DO bit In-Reply-To: Your message of "Mon, 15 Jun 2009 11:52:58 +0200." <4A3619FA.5090404@nlnetlabs.nl> References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 15 Jun 2009 11:17:03 +0000 Message-ID: <91434.1245064623@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Mon, 15 Jun 2009 11:52:58 +0200 > From: "W.C.A. Wijngaards" > ... > The draft is overcomplicated as it stands now. I propose this: > > All DNSSEC compliant severs MAY treat ENDS0 queries with DO bit set > and the buffer size set to less 1220, as error in the query and > return FORMERR. > > This is so close to the current spec, the draft is not really necessary > and it can go into dnssec-bis-updates as a clarification. (If this > draft becomes standard it'll get implemented for unbound of course). i think ignoring the DO bit is better. it's not a format error and we would not want the initiator to treat this as an EDNS downgrade. there are other benefits to EDNS beyond just helping to carry DNSSEC metadata. > It is also much simpler. The if-statement 'truncation would be caused' > complicates way too much, for no real benefit. Also a FORMERR causes > the server to be cached as EDNS0-noncompliant in those resolvers. And > the resolver can try again later without EDNS0, or have some internal > logic to handle non-EDNS0 servers. it's taken ten years to get EDNS this far. i think we should not burden its very slow deployment curve with a DO-related setback. DO does not mean "DNSSEC is desired" so much as "DNSSEC is understood". it would not stretch the meaning of "understood" at all for a target to say, i see your DO bit but i also see your small buffer size, so i am rejecting your claim that you understand DNSSEC, and thus ignoring DO. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 04:38:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC603A6C32; Mon, 15 Jun 2009 04:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, HELO_LH_HOME=3.714] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxOz-T6vElRW; Mon, 15 Jun 2009 04:38:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 70BB03A6C0D; Mon, 15 Jun 2009 04:38:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGASY-0008vl-1W for namedroppers-data0@psg.com; Mon, 15 Jun 2009 11:34:42 +0000 Received: from [2001:4f8:3:bb:2e0:81ff:fe52:9971] (helo=mail2.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGASI-0008uF-Jx for namedroppers@ops.ietf.org; Mon, 15 Jun 2009 11:34:36 +0000 Received: from firewall.antoniuk.lan (mail.antoniuk.md [65.86.158.146]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.ntp.org (Postfix) with ESMTP id BB61F39913; Mon, 15 Jun 2009 11:34:25 +0000 (UTC) (envelope-from mayer@gis.net) Received: from [198.22.153.32] (helo=[10.60.98.36]) by firewall.antoniuk.lan with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MGAS8-0004IG-Ah; Mon, 15 Jun 2009 07:34:16 -0400 Message-ID: <4A3631B0.9000706@gis.net> Date: Mon, 15 Jun 2009 07:34:08 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Matthew Dempsky Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> <4A35BDE2.3080507@gis.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-kostecke.net-MailScanner: Found to be clean X-kostecke.net-MailScanner-From: mayer@gis.net Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Matthew Dempsky wrote: > On Sun, Jun 14, 2009 at 8:20 PM, Danny Mayer wrote: >> There is a really bad assumption here: that the resolvers are the >> consumers of the resulting A and AAAA records. > > For delegation glue records, the resolver is the consumer. > >> The real consumer is the >> application initiating the request of the resolver for an address. > > When you type "http://www.google.com" into your web browser, your web > browser does not care at all what address records the root server gave > for a.gtld-servers.net to the resolver; only the resolver cares. If I understand this correctly, you want the name servers to behave differently at the root from the rest of the servers. What operator is going to want to have a customized server just for the root? Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 04:43:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01FBA3A6CBD; Mon, 15 Jun 2009 04:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.157 X-Spam-Level: X-Spam-Status: No, score=0.157 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKu515WUZVcU; Mon, 15 Jun 2009 04:43:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2F9563A6BEB; Mon, 15 Jun 2009 04:43:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGAXh-0009XA-2V for namedroppers-data0@psg.com; Mon, 15 Jun 2009 11:40:01 +0000 Received: from [209.85.217.220] (helo=mail-gx0-f220.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGAXW-0009W7-C5 for namedroppers@ops.ietf.org; Mon, 15 Jun 2009 11:39:55 +0000 Received: by gxk20 with SMTP id 20so7132038gxk.17 for ; Mon, 15 Jun 2009 04:39:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.66.10 with SMTP id o10mr6171367aga.90.1245065988568; Mon, 15 Jun 2009 04:39:48 -0700 (PDT) In-Reply-To: <4A3631B0.9000706@gis.net> References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> <4A35BDE2.3080507@gis.net> <4A3631B0.9000706@gis.net> Date: Mon, 15 Jun 2009 04:39:48 -0700 Message-ID: Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients From: Matthew Dempsky To: mayer@gis.net Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 15, 2009 at 4:34 AM, Danny Mayer wrote: > If I understand this correctly, you want the name servers to behave > differently at the root from the rest of the servers. What operator is > going to want to have a customized server just for the root? No, 8 of the 13 root servers already behave the way I suggest, and the other 5 are using the same software as some of those 8 (according to fpdns), so there's no custom software involved. Also, I've never suggested that this is something that should only apply to the root servers, it's just the only concrete example I have. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 04:55:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5505F28C133; Mon, 15 Jun 2009 04:55:23 -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 msJXgVX81kv6; Mon, 15 Jun 2009 04:55:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4803928C127; Mon, 15 Jun 2009 04:55:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGAi9-000Anu-8g for namedroppers-data0@psg.com; Mon, 15 Jun 2009 11:50:49 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGAhx-000Amm-KW for namedroppers@ops.ietf.org; Mon, 15 Jun 2009 11:50:43 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5FBoZF3006687 for ; Mon, 15 Jun 2009 07:50:35 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n5FBoZfc006686 for namedroppers@ops.ietf.org; Mon, 15 Jun 2009 07:50:35 -0400 (EDT) (envelope-from namedroppers) Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MG0qX-0008rN-5B for namedroppers@psg.com; Mon, 15 Jun 2009 01:18:54 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 53A61327A78; Mon, 15 Jun 2009 01:18:48 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id 81018327A76; Mon, 15 Jun 2009 01:18:47 +0000 (UTC) Message-ID: <4A35A177.7020005@isc.org> Date: Sun, 14 Jun 2009 20:18:47 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nicholas Weaver CC: George Barwood , namedroppers@psg.com, Olafur Gudmundsson Subject: Re: [dnsext] New rules for DO bit References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <6B75206D24B84A2BA5703B33183D5203@localhost> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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. ] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicholas Weaver wrote: > (This is one of the things we test for in netalyzr, BTW). Its > unfortunatly very common. Do you have any data showing that a 1220-byte packet might make it, where a 4096 one will not? - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko1oXYACgkQ+NNi0s9NRJ3iXACfYsfnUzMlIGAnA/ZpC+wL7kp2 a0kAn3Wz5L5pmtaHzeWZQyU5aqHFuDfL =/l5T -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 04:56:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CFC23A6CCA; Mon, 15 Jun 2009 04:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-1.194, 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 yUQS0si-SEHV; Mon, 15 Jun 2009 04:56:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A8ED43A68D3; Mon, 15 Jun 2009 04:56:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGAkj-000B9a-D2 for namedroppers-data0@psg.com; Mon, 15 Jun 2009 11:53:29 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGAkX-000B8N-JT for namedroppers@ops.ietf.org; Mon, 15 Jun 2009 11:53:23 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5FBrFR3006732 for ; Mon, 15 Jun 2009 07:53:15 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n5FBrFex006731 for namedroppers@ops.ietf.org; Mon, 15 Jun 2009 07:53:15 -0400 (EDT) (envelope-from namedroppers) Received: from [209.85.222.200] (helo=mail-pz0-f200.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEVVs-000Cv4-Gx for namedroppers@ops.ietf.org; Wed, 10 Jun 2009 21:39:22 +0000 Received: by pzk38 with SMTP id 38so1002417pzk.5 for ; Wed, 10 Jun 2009 14:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=iR1eqrQ48XAh2MTLGonUcR36WuY0taVKGEt67IT4jOY=; b=rcjXrUkZpZD4ou5l5oUXBghHYhh30C+jjAj7hS/kFFV3uKgBRWu/nhKvjOt1bLWg/t XQSsSxbhnPJsKSIEhxzDT0KlTXfQAhbmWasG1LeWzNqxmW64ZND9g9IcjAFnMpooPpgk 3ysH8agQMEvhSRmPv8xr84Jwn8EWgK2osfkV8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=c0Ji2UWW35tRZw2eL3u6F09DjHVDl+jRos1+PvgVVNNC3ZQAHAKWg+KE3sK3uU+Kzv FACVtdpxEHEXzzDkIeKw5kTPpUDkmolz5x84qXKyUXMCDUTZvNfZ6fbdxv2QixGQIVZl u/8ZGsln8oog6EgWtCn6xs/H2SRXLPO4ytYXs= Received: by 10.114.234.13 with SMTP id g13mr2908492wah.52.1244669954799; Wed, 10 Jun 2009 14:39:14 -0700 (PDT) Received: from SJC-Office-NAT-219.mail-abuse.org (SJC-Office-NAT-219.mail-abuse.org [168.61.10.219]) by mx.google.com with ESMTPS id j28sm9941849waf.58.2009.06.10.14.39.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 14:39:12 -0700 (PDT) Cc: Paul Vixie , Matthew Dempsky , Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: <04F1D8C0-1B1B-4BFF-954D-42AE74609165@gmail.com> From: Doug Otis To: bert hubert In-Reply-To: <3efd34cc0906101142s5eca0d7fx79bbd6fad51c769f@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: SCTP (Re: [dnsext] Re: TCP queries to the root servers ) Date: Wed, 10 Jun 2009 14:39:09 -0700 References: <20090608111014.GA31833@vacation.karoshi.com.> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> <20090609160854.GC25651@shinkuro.com> <20090609182801.GB32546@shinkuro.com> <3efd34cc0906091215t419a6bc3k369067783fdc6266@mail.gmail.com> <80879.1244590583@nsa.vix.com> <3efd34cc0906101142s5eca0d7fx79bbd6fad51c769f@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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 Jun 10, 2009, at 11:42 AM, bert hubert wrote: > For it to be useful, we'd need to use it for all our traffic. Persistence of an association can be dictated by availability of resources and frequency of use. > Between a single auth server and a single cache, <1 QPS will > probably be quite common. This brings into perspective packet counts > that are at least twice as high as UDP, and more likely five times > as high (when taking into account the setup and teardown). UDP does not permit any easy mitigation of brute force or spoofed source attacks where packets are larger or fragmented due to EDNS. Any practical defense leaves TCP or SCTP. > Underneath the hood, the kernel is dealing with the exact same > challenge as select() or poll() however. So you just moved the > problem. In addition, it appears that except for only using a single > fd, there is nothing 'lightweight' about an SCTP association. Unlike TCP, resources are not committed prior to confirmation of the source IP addresses needed to mitigate flood attacks. There is nothing lightweight about the alternative. In addition, buffer management is made simpler by specific acknowledgements and out of order delivery, rather than buffering to a fully acknowledge byte position within a common stream. Buffer management is also simplified by transport header alignment with DNS messages that enables UDP like immediate placement upon receipt, despite pending prior packet loss. > I measure around 8 kilobytes per association. This would mean your > millions of associations mentioned above require tens of gigabytes > of ram on a commonly used operating system. This resource can allocated between trusted and high traffic servers. Low traffic sources might be required to establish associations. > SCTP is not remotely like UDP. Independent acknowledgement and out of order handling of SCTP chucks (DNS messages) is much closer to UDP behaviors than TCP would be. > The two bytes won't save us however. AUTH-SCTP can introduce a 32 byte nounce. However, DNSSEC does not depend upon transactional ids once all cache information is being confirmed. > So please color me unconvinced. SCTP has its merits, but it is not > light weight, and uses a lot of packets compared to UDP or even TCP. SCTP offers defensive strategies not practical with TCP. UDP creates different risks that grow with EDNS/DNSSEC. The comparative overhead should include additional servers needed to endure attack. Once that consideration is included, a moderate increase in packet volume during ideal conditions becomes much less pronounced as a concern. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 04:59:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5553F3A6CBF; Mon, 15 Jun 2009 04:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.516 X-Spam-Level: X-Spam-Status: No, score=-0.516 tagged_above=-999 required=5 tests=[AWL=-0.336, 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 oV7HszqW2Ku0; Mon, 15 Jun 2009 04:59:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 654DE3A6CC4; Mon, 15 Jun 2009 04:59:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGAlM-000BEv-Tj for namedroppers-data0@psg.com; Mon, 15 Jun 2009 11:54:08 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGAlA-000BCz-Nj for namedroppers@ops.ietf.org; Mon, 15 Jun 2009 11:54:03 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5FBrt57006755 for ; Mon, 15 Jun 2009 07:53:55 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n5FBrt4K006754 for namedroppers@ops.ietf.org; Mon, 15 Jun 2009 07:53:55 -0400 (EDT) (envelope-from namedroppers) Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MEfPM-00073l-Sh for namedroppers@ops.ietf.org; Thu, 11 Jun 2009 08:13:18 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MEfPB-00046D-I8; Thu, 11 Jun 2009 10:13:01 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MEfPA-0002YR-9x; Thu, 11 Jun 2009 10:13:00 +0200 From: Florian Weimer To: Paul Vixie Cc: Matthew Dempsky , bert hubert , Andrew Sullivan , Douglas Otis , namedroppers@ops.ietf.org Subject: Re: SCTP (Re: [dnsext] Re: TCP queries to the root servers ) References: <20090608111014.GA31833@vacation.karoshi.com.> <6923.1244480480@nsa.vix.com> <31786.1244517105@nsa.vix.com> <3efd34cc0906090047w735ee179r991a8a9e05cf1133@mail.gmail.com> <60184.1244560661@nsa.vix.com> <20090609160854.GC25651@shinkuro.com> <20090609182801.GB32546@shinkuro.com> <3efd34cc0906091215t419a6bc3k369067783fdc6266@mail.gmail.com> <80879.1244590583@nsa.vix.com> Date: Thu, 11 Jun 2009 10:13:00 +0200 In-Reply-To: <80879.1244590583@nsa.vix.com> (Paul Vixie's message of "Tue, 09 Jun 2009 23:36:23 +0000") Message-ID: <87prdbi3xv.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Paul Vixie: > it takes two packets to carry a request and a response, and if they are > the last request and response in the queue then each of these will be > followed by an ACK packet. so, a slow 1TPS flow would take four packets > per transaction, whereas a faster flow would take two packets per > transaction. the extra ACK-only packets don't delay the DNS result, but > they do appear on the wire. If you use SCTP's retransmit feature, you need in-kernel data buffers or delays in user space. A new PR-SCTP service might work around this problem, but it seems to me that some protocol work is required. > by lightweight i mean that a root or TLD or 2LD/3LD server could have many > hundredthousands or even millions of associations open, all on a single > socket and therefore a single file descriptor, so it's not a burden on > the DNS server's system call interface (think of a select() mask here, or > a poll() filedes array.) If you keep that many idle associations open, your servers will be busy processing all the associated heartbeat messages. The one-to-many style interface also needs in-kernel buffers, and it will be somewhat difficult to control the amount of resources used by busy resolver. Furthermore, it is explicitly left open in the sockets API draft whether one receiver behind a one-to-many socket can block communications to other receivers (see section 4.4 in draft-ietf-tsvwg-sctpsocket-19). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 05:33:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB64E28C136; Mon, 15 Jun 2009 05:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 xeG2zWldq6jz; Mon, 15 Jun 2009 05:33:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D9EEF28C132; Mon, 15 Jun 2009 05:33:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGBIo-000F8M-3a for namedroppers-data0@psg.com; Mon, 15 Jun 2009 12:28: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.69 (FreeBSD)) (envelope-from ) id 1MGBId-000F7Q-2r for namedroppers@ops.ietf.org; Mon, 15 Jun 2009 12:28:36 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 99D3FA5AD7; Mon, 15 Jun 2009 12:28:30 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Matthew Dempsky cc: mayer@gis.net, namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients In-Reply-To: Your message of "Mon, 15 Jun 2009 04:39:48 MST." References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> <4A35BDE2.3080507@gis.net> <4A3631B0.9000706@gis.net> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 15 Jun 2009 12:28:30 +0000 Message-ID: <94261.1245068910@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: we've had this debate before. the way it ends is, if your ability to reach a nameserver depends on the order of RRs in the additional data section, then you are doomed, and no ordering policy can save you. hopefully someone will distill the debate from their archives. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 05:48:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78DB73A68FA; Mon, 15 Jun 2009 05:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5850SFKEaL9O; Mon, 15 Jun 2009 05:48:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 816A73A6935; Mon, 15 Jun 2009 05:48:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGBYf-000Grz-56 for namedroppers-data0@psg.com; Mon, 15 Jun 2009 12:45:05 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGBYQ-000Gpv-ES for namedroppers@ops.ietf.org; Mon, 15 Jun 2009 12:44:59 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n5FCiflh011505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Jun 2009 14:44:42 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A364239.1030703@nlnetlabs.nl> Date: Mon, 15 Jun 2009 14:44:41 +0200 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Preferring IPv4 glue over IPv6 glue for IPv4 clients References: <200906100347.n5A3lUXh013734@drugs.dv.isc.org> <20090610095550.GC15847@vacation.karoshi.com.> <18991.43011.153595.454259@guava.gson.org> <4A35BDE2.3080507@gis.net> <4A3631B0.9000706@gis.net> <94261.1245068910@nsa.vix.com> In-Reply-To: <94261.1245068910@nsa.vix.com> X-Enigmail-Version: 0.95.7 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.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 15 Jun 2009 14:44:42 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Vixie wrote: > we've had this debate before. the way it ends is, if your ability > to reach a nameserver depends on the order of RRs in the additional > data section, then you are doomed, and no ordering policy can save > you. hopefully someone will distill the debate from their archives. +1 Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAko2QjkACgkQkDLqNwOhpPjtegCffe71aFMbm1r7l8tYyNCAn9uE pfgAniNkN4SOOI243PDz4iZFmIKVhifo =elu3 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From lopezlopez.yolanda@amschool.edu.sv Mon Jun 15 07:45:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614833A6CCC for ; Mon, 15 Jun 2009 07:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.676 X-Spam-Level: X-Spam-Status: No, score=-8.676 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_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 f+f+T5mIvqEp for ; Mon, 15 Jun 2009 07:45:58 -0700 (PDT) Received: from 19.cn (unknown [85.102.46.171]) by core3.amsl.com (Postfix) with SMTP id 880F73A6883 for ; Mon, 15 Jun 2009 07:45:54 -0700 (PDT) From: "Rosario Cleveland"@core3.amsl.com, dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: Delivery Status Notification (Failure) 3129242004 MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20090615144555.880F73A6883@core3.amsl.com> Date: Mon, 15 Jun 2009 07:45:54 -0700 (PDT) This Week

Click here to view this message as a web page.

 

Click here if this picture is blocked

Home  |  Contact Us  |  Privacy Policy  |  Terms of Use | Unsubscribe |
From owner-namedroppers@ops.ietf.org Mon Jun 15 08:40:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2063A6A4D; Mon, 15 Jun 2009 08:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=-1.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbMlSqgaSxjz; Mon, 15 Jun 2009 08:40:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E4B53A6A21; Mon, 15 Jun 2009 08:40:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGEBU-0009NQ-1l for namedroppers-data0@psg.com; Mon, 15 Jun 2009 15:33:20 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGEBC-0009LW-P7 for namedroppers@psg.com; Mon, 15 Jun 2009 15:33:14 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=4QUL/f0SOTA0B5Mnm6uamNB+aMBX9sDC4rWgnKHjKc6MBlQm+5fcuZQ7 lzRBm5k3P12DPBaL+Nih4y83CAhw1LhUboJan4PHbRWflkmrfPOBHDWTZ nTiTz/Hj9Jz+LCB; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1245079982; x=1276615982; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20New=20rules=20for=20DO=20bit|Date:=20Mon,=2015=20Ju n=202009=2016:33:00=20+0100|Message-ID:=20|To:=20Michael=20Graff=20|Cc:=20George =20Barwood=20,=0D=0A=09n amedroppers@psg.com,=0D=0A=09Nicholas=20Weaver=20,=0D=0A=09Olafur=20Gudmundsson=20,=0D=0A=09owner-namedroppers@ops.ietf.org |MIME-Version:=201.0|In-Reply-To:=20<4A35A177.7020005@isc .org>|References:=20<200906141835.n5EIZ0dD020925@stora.og ud.com>=20<6B75206D24B84A2BA5703B33183D5203@localhost>=20 =20<4A35A177.7020005@isc.org>; bh=ac+lpNkdhEkjO6Ih4GHriqKXAYP1k7zm3Gw2Me/X55o=; b=5zL22kCNP7DKK1z9n10Nf+0BuFQ+QDghsy2Tjm/p/UsxQK0TajJdONfP iOgaf9MNJwMajJ9d9spF83JZXPRRtl9/+0SulIPfe1xrDz5H8YmIb82AC hExsrAHkZQ43kDU; X-IronPort-AV: E=Sophos;i="4.42,223,1243810800"; d="scan'208";a="14837017" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 15 Jun 2009 16:33:01 +0100 In-Reply-To: <4A35A177.7020005@isc.org> References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <6B75206D24B84A2BA5703B33183D5203@localhost> <4A35A177.7020005@isc.org> To: Michael Graff Cc: George Barwood , namedroppers@psg.com, Nicholas Weaver , Olafur Gudmundsson , owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] New rules for DO bit MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Mon, 15 Jun 2009 16:33:00 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 15/06/2009 04:33:00 PM, Serialize complete at 15/06/2009 04:33:00 PM Content-Type: multipart/alternative; boundary="=_alternative 00556B81802575D6_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 00556B81802575D6_= Content-Type: text/plain; charset="US-ASCII" > Do you have any data showing that a 1220-byte packet might make it, > where a 4096 one will not? I have plenty, albeit in the context of SOHO CPE. Lots of DNS proxies in routers will handle ~1464 bytes of payload (i.e. one PPPoE frame) but no larger. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 00556B81802575D6_= Content-Type: text/html; charset="US-ASCII"
> Do you have any data showing that a 1220-byte packet might make it,
> where a 4096 one will not?
I have plenty, albeit in the context of SOHO CPE.

Lots of DNS proxies in routers will handle ~1464 bytes of payload (i.e. one PPPoE frame) but no larger.

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 00556B81802575D6_=-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From mordredg1@nsst.sch.ge.com Mon Jun 15 11:22:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9533A67F9; Mon, 15 Jun 2009 11:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.952 X-Spam-Level: X-Spam-Status: No, score=-23.952 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HS_INDEX_PARAM=0.001, HTML_FONT_FACE_BAD=0.884, 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, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1h66DtHTFdvb; Mon, 15 Jun 2009 11:22:14 -0700 (PDT) Received: from cpe-65-24-208-142.insight.res.rr.com (cpe-65-24-208-142.insight.res.rr.com [65.24.208.142]) by core3.amsl.com (Postfix) with ESMTP id 463D73A69C6; Mon, 15 Jun 2009 11:22:14 -0700 (PDT) Date: Mon, 15 Jun 2009 14:21:28 -0500 Message-Id: <9QWDR48651.TF70KJ3155@65.24.208.142> From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: energize , shed pounds rapidly with Acai Berry. Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
HOME | FITNESS & HEALTH | SUCCESS STORIES | COMMUNITY

 Unsubscribe | Change E-mail Options | Privacy Policy
 
 
               Designed with you in mind , lose weight fast with Acai Berry.
                           Take a step to visit
 
 

You are subscribed as dnsext-archive@ietf.org.


If you have any questions, please visit our comprehensive Help section or contact
Customer Service.

C 2009 Nbhwphvwixjczr International, Inc.
 
From emu-bounces@ietf.org Mon Jun 15 11:22:16 2009 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401E53A69C6 for ; Mon, 15 Jun 2009 11:22:16 -0700 (PDT) Subject: The results of your email commands From: emu-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0912960044==" Message-ID: Date: Mon, 15 Jun 2009 11:22:15 -0700 Precedence: bulk X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 List-Id: "EAP Methods Update \(EMU\)" X-List-Administrivia: yes Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org --===============0912960044== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Done. --===============0912960044== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: emu-request@core3.amsl.com Delivered-To: emu-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9533A67F9; Mon, 15 Jun 2009 11:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.952 X-Spam-Level: X-Spam-Status: No, score=-23.952 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HS_INDEX_PARAM=0.001, HTML_FONT_FACE_BAD=0.884, 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, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1h66DtHTFdvb; Mon, 15 Jun 2009 11:22:14 -0700 (PDT) Received: from cpe-65-24-208-142.insight.res.rr.com (cpe-65-24-208-142.insight.res.rr.com [65.24.208.142]) by core3.amsl.com (Postfix) with ESMTP id 463D73A69C6; Mon, 15 Jun 2009 11:22:14 -0700 (PDT) Date: Mon, 15 Jun 2009 14:21:28 -0500 Message-Id: <9QWDR48651.TF70KJ3155@65.24.208.142> From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: energize , shed pounds rapidly with Acai Berry. Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
HOME | FITNESS & HEALTH | SUCCESS STORIES | COMMUNITY

 Unsubscribe | Change E-mail Options | Privacy Policy
 
 
               Designed with you in mind , lose weight fast with Acai Berry.
                           Take a step to visit
 
 

You are subscribed as dnsext-archive@ietf.org.


If you have any questions, please visit our comprehensive Help section or contact
Customer Service.

C 2009 Nbhwphvwixjczr International, Inc.
 
--===============0912960044==-- From censuredcv8@oceannv.com Mon Jun 15 11:22:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75403A69F6; Mon, 15 Jun 2009 11:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.025 X-Spam-Level: X-Spam-Status: No, score=-19.025 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=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, FS_WEIGHT_LOSS=2.134, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HS_INDEX_PARAM=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDiA8xtBuesB; Mon, 15 Jun 2009 11:22:15 -0700 (PDT) Received: from cpe-65-24-208-142.insight.res.rr.com (cpe-65-24-208-142.insight.res.rr.com [65.24.208.142]) by core3.amsl.com (Postfix) with ESMTP id A0A253A67F9; Mon, 15 Jun 2009 11:22:14 -0700 (PDT) Message-ID: <000d01c9ede6$3b59ed60$6400a8c0@censuredcv8> From: eos-archive@ietf.org To: Subject: AcaI Berry will lead to effective weight loss .Try it now. Date: Mon, 15 Jun 2009 14:22:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9EDE6.3B59ED60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9EDE6.3B59ED60 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 =20 HOME | FITNESS &=20 HEALTH | SUCCESS=20 STORIES | COMMUNITY =20 =20 =20 Unsubscribe | Change E-mail Options=20 | Privacy Policy =20 =20 =20 =20 =A0 =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 Discover Acai Berry numerous weight loss and health benefits.=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=20 Haste to come =A0 =A0 =20 You are subscribed as eos-archive@ietf.org.If you have any questions,= please=20 visit our comprehensive Help section or=20 contactCustomer Service.C 2009=20 Nuzntgrvhnagqt International, Inc. =A0 ------=_NextPart_000_0007_01C9EDE6.3B59ED60 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
HOME | FI= TNESS &=20 HEALTH | SU= CCESS=20 STORIES | COMMUNITY

 Unsubscribe | Change E-mail Options=20 | Privacy Policy
=A0
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 Discover Acai Berry numerous weight loss and he= alth benefits.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=20 Hast= e to come
=A0
=A0

You are subscribed as eos-archive@ietf.org.


If you have any questions, plea= se=20 visit our comprehensive Help section or=20 contact
Custo= mer Service.

C 2009=20 Nuzntgrvhnagqt International, Inc.
=A0
------=_NextPart_000_0007_01C9EDE6.3B59ED60-- From oxusiu97@ups-gruppi-di-continuita.com Mon Jun 15 12:49:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A0D23A6C7E; Mon, 15 Jun 2009 12:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.206 X-Spam-Level: X-Spam-Status: No, score=-26.206 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_OPRAH=2, HELO_DYNAMIC_IPADDR2=4.395, HS_INDEX_PARAM=0.001, 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_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YfLFuEgLr2g; Mon, 15 Jun 2009 12:49:18 -0700 (PDT) Received: from 173-25-187-133.client.mchsi.com (173-25-187-133.client.mchsi.com [173.25.187.133]) by core3.amsl.com (Postfix) with ESMTP id 5F03E3A682A; Mon, 15 Jun 2009 12:49:18 -0700 (PDT) Date: Mon, 15 Jun 2009 12:49:18 -0800 Message-Id: From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: Melt away pounds with Anatrim Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Anatrim -- The newest and most exciting fat loss product available - As seen on Oprah!


Real testimonials:


"I was originally amazed that the first two pills I took of Anatrim, almost immediately took my cravings away. Now 4 weeks later, 3 belt holes later, I have become an advocate for this awesomely powerful, natural supplement!"

Kory Crowley WA


"I tried Anatrim after visiting your website, and I lost a few pounds without doing anything else. I was so amazed I decided to start exercising and getting outside more and I even starting eating better. Now I don't even look like the same man. Friends I haven't seen for more than a year don't even recognize me. The change is that dramatic! Thank you …. Anatrim really works!"

Hortenci Lake, Texas




Read more testimonals here!




From fecframe-bounces@ietf.org Mon Jun 15 12:49:22 2009 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091363A69EB for ; Mon, 15 Jun 2009 12:49:22 -0700 (PDT) Subject: The results of your email commands From: fecframe-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0408187251==" Message-ID: Date: Mon, 15 Jun 2009 12:49:20 -0700 Precedence: bulk X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of FEC Framework X-List-Administrivia: yes Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org --===============0408187251== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Done. --===============0408187251== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: fecframe-request@core3.amsl.com Delivered-To: fecframe-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A0D23A6C7E; Mon, 15 Jun 2009 12:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.206 X-Spam-Level: X-Spam-Status: No, score=-26.206 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_OPRAH=2, HELO_DYNAMIC_IPADDR2=4.395, HS_INDEX_PARAM=0.001, 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_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YfLFuEgLr2g; Mon, 15 Jun 2009 12:49:18 -0700 (PDT) Received: from 173-25-187-133.client.mchsi.com (173-25-187-133.client.mchsi.com [173.25.187.133]) by core3.amsl.com (Postfix) with ESMTP id 5F03E3A682A; Mon, 15 Jun 2009 12:49:18 -0700 (PDT) Date: Mon, 15 Jun 2009 12:49:18 -0800 Message-Id: From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: Melt away pounds with Anatrim Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Anatrim -- The newest and most exciting fat loss product available - As seen on Oprah!


Real testimonials:


"I was originally amazed that the first two pills I took of Anatrim, almost immediately took my cravings away. Now 4 weeks later, 3 belt holes later, I have become an advocate for this awesomely powerful, natural supplement!"

Kory Crowley WA


"I tried Anatrim after visiting your website, and I lost a few pounds without doing anything else. I was so amazed I decided to start exercising and getting outside more and I even starting eating better. Now I don't even look like the same man. Friends I haven't seen for more than a year don't even recognize me. The change is that dramatic! Thank you …. Anatrim really works!"

Hortenci Lake, Texas




Read more testimonals here!




--===============0408187251==-- From owner-namedroppers@ops.ietf.org Mon Jun 15 13:16:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F663A6D0E; Mon, 15 Jun 2009 13:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3hJjRUae5gT; Mon, 15 Jun 2009 13:16:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B44583A6D0D; Mon, 15 Jun 2009 13:16:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGIUl-000Amq-WA for namedroppers-data0@psg.com; Mon, 15 Jun 2009 20:09:32 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGIUT-000AkJ-8F for namedroppers@psg.com; Mon, 15 Jun 2009 20:09:23 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=TTHEN99JON+8PXgwFfPfPq0Kavd2vdNXmD1bd113liVKM528K00A0C8sfcDWtqL8rWRKAHP2r7fsiL/0Tkx4V5vroIitKae4tBD1prnuPnGEr4KV4urSuQPegNOc0R6B; Received: from [199.212.90.19] (helo=dh19.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGITD-000IVi-O6; Mon, 15 Jun 2009 20:07:56 +0000 Cc: namedroppers@psg.com Message-Id: <2ACDD4C9-399A-4119-97FD-AE48BBD38F8D@hopcount.ca> From: Joe Abley To: Paul Vixie In-Reply-To: <91434.1245064623@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] New rules for DO bit Date: Mon, 15 Jun 2009 16:07:55 -0400 References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <91434.1245064623@nsa.vix.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 15-Jun-2009, at 07:17, Paul Vixie wrote: > DO does not mean "DNSSEC is desired" so much as "DNSSEC is > understood". > it would not stretch the meaning of "understood" at all for a target > to > say, i see your DO bit but i also see your small buffer size, so i am > rejecting your claim that you understand DNSSEC, and thus ignoring DO. I think it would be great if this observation could find a home in Olafur's draft, somewhere. I find the text above concise and easy to understand, and I think it would make the choice of "ignore DO" vs. FORMERR (or something else) much easier to understand. Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 14:21:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E12653A6826; Mon, 15 Jun 2009 14:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.75 X-Spam-Level: X-Spam-Status: No, score=-4.75 tagged_above=-999 required=5 tests=[AWL=-1.499, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 W6uggsxNCnl1; Mon, 15 Jun 2009 14:21:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 68C743A6827; Mon, 15 Jun 2009 14:21:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGJX7-000H6o-5Q for namedroppers-data0@psg.com; Mon, 15 Jun 2009 21:16:01 +0000 Received: from [81.91.160.182] (helo=office.denic.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGJWs-000H57-SF for namedroppers@ops.ietf.org; Mon, 15 Jun 2009 21:15:53 +0000 Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1MGJWq-0002CR-OI; Mon, 15 Jun 2009 23:15:44 +0200 Received: from localhost by x27.adm.denic.de with local id 1MGJTB-0005Jq-93; Mon, 15 Jun 2009 23:11:57 +0200 Date: Mon, 15 Jun 2009 23:11:57 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: Re: [dnsext] New rules for DO bit Message-ID: <20090615211157.GD9397@x27.adm.denic.de> References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A3619FA.5090404@nlnetlabs.nl> User-Agent: Mutt/1.4.2.3i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 15, 2009 at 11:52:58AM +0200, W.C.A. Wijngaards wrote: > >> > To follow up on the discussion from the last two weeks here is a > >> > draft to explicitly outlaw setting of DO bit of with buff size < 1220. > > The draft is overcomplicated as it stands now. I propose this: that was my reaction, too. I believe the draft doesn't state anything dramatically new, just reinforces a statement made in RFC 3226 and later in RFC 4035, Section 3. > All DNSSEC compliant severs MAY treat ENDS0 queries with DO bit set > and the buffer size set to less 1220, as error in the query and > return FORMERR. As a protocol purist, I'd support this, but as an operator I'd rather avoid such a draconian reaction. Ignoring the DO bit should be less problematic. Also, it is in the spirit of "be conservative in what you send" (and note that "liberal in what you accept" therefore doesn't include obeying DO at <1220 octets). > This is so close to the current spec, the draft is not really necessary > and it can go into dnssec-bis-updates as a clarification. (If this > draft becomes standard it'll get implemented for unbound of course). Seconded, either way the dnssec-bis-updates document is the right place to make this statement. It's hard to unilaterally standardize the reaction to a non-compliant query, anyway. > It is also much simpler. The if-statement 'truncation would be caused' > complicates way too much, for no real benefit. Also a FORMERR causes Agreed. It would also lead to unnecessary protocal lawyering since the client, albeit in violation of the spec, could argue that the server would be obliged to engage in that extra calculation if it was to ignore DO=1 only after it found that the response would have TC=1. Thenew text should encourage the authoritative server to defend itself against non compliant clients, rather than to restrict this ability. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 16:58:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645CB3A69D0; Mon, 15 Jun 2009 16:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.53 X-Spam-Level: X-Spam-Status: No, score=-4.53 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-t9DiZuCs7p; Mon, 15 Jun 2009 16:58:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6DF7F3A69C5; Mon, 15 Jun 2009 16:58:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGLxV-0005Xl-Lx for namedroppers-data0@psg.com; Mon, 15 Jun 2009 23:51:25 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGLxE-0005Vk-OQ for namedroppers@psg.com; Mon, 15 Jun 2009 23:51:19 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5FNj1tj005953; Mon, 15 Jun 2009 23:45:03 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5FNiuAx005952; Mon, 15 Jun 2009 23:44:56 GMT Date: Mon, 15 Jun 2009 23:44:56 +0000 From: bmanning@vacation.karoshi.com To: "W.C.A. Wijngaards" Cc: Olafur Gudmundsson , Florian Weimer , namedroppers@psg.com Subject: Re: [dnsext] New rules for DO bit Message-ID: <20090615234456.GD5507@vacation.karoshi.com.> References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A3619FA.5090404@nlnetlabs.nl> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Jun 15, 2009 at 11:52:58AM +0200, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Olafur, > > Olafur Gudmundsson wrote: > > At 16:43 14/06/2009, Florian Weimer wrote: > >> * Olafur Gudmundsson: > >> > >> > To follow up on the discussion from the last two weeks here is a > >> > draft to explicitly outlaw setting of DO bit of with buff size < 1220. > > The draft is overcomplicated as it stands now. I propose this: > > All DNSSEC compliant severs MAY treat ENDS0 queries with DO bit set > and the buffer size set to less 1220, as error in the query and > return FORMERR. > > This is so close to the current spec, the draft is not really necessary > and it can go into dnssec-bis-updates as a clarification. (If this > draft becomes standard it'll get implemented for unbound of course). > as long as we are plus-oneing - i like this wording and the results. --bill (DNSSEC - expect collateral damage) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 17:30:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611453A69BC; Mon, 15 Jun 2009 17:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMgUWka6J94I; Mon, 15 Jun 2009 17:30:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4EBDF3A696B; Mon, 15 Jun 2009 17:30:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGMUf-0008ue-IH for namedroppers-data0@psg.com; Tue, 16 Jun 2009 00:25:41 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGMUP-0008sm-0L for namedroppers@psg.com; Tue, 16 Jun 2009 00:25:35 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id D44B6E601C; Tue, 16 Jun 2009 00:25:23 +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 n5G0PHct010390; Tue, 16 Jun 2009 10:25:19 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906160025.n5G0PHct010390@drugs.dv.isc.org> To: Ray.Bellis@nominet.org.uk Cc: Michael Graff , George Barwood , namedroppers@psg.com, Nicholas Weaver , Olafur Gudmundsson , owner-namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] New rules for DO bit In-reply-to: Your message of "Mon, 15 Jun 2009 16:33:00 +0100." Date: Tue, 16 Jun 2009 10:25:17 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Ray.Bellis@nominet.org.uk writes: > > Do you have any data showing that a 1220-byte packet might make it, > > where a 4096 one will not? > > I have plenty, albeit in the context of SOHO CPE. > > Lots of DNS proxies in routers will handle ~1464 bytes of payload (i.e. > one PPPoE frame) but no larger. > > Ray Which would be a issue between the stub server and the ultimate recursive server. It normally doesn't affect traffic to and from iterative servers behind the SOHO CPE because they don't go through the proxy code. For end user zones 512 is often quite reasonable. It really is only the root that has a problem because it returns lots of NXDOMAIN responses which are large with DNSSEC. Iterative resolvers talk to the root. Stub resolvers don't normally. The response below has lots more that could be thrown away if needed. ; <<>> DiG 9.3.6-P1 <<>> +dnssec +bufsize=512 www.isc.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27551 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.isc.org. IN A ;; ANSWER SECTION: www.isc.org. 589 IN A 149.20.64.42 www.isc.org. 589 IN RRSIG A 5 3 600 20090715025015 20090615025015 27624 isc.org. l7d+erEfXgcixSMvMNj6+/TmP7VqojAcgojPpb4pNtnBMgr7++I559rK k/fwBSMXHjkE8kUfgW8vCOLxdaFRsysd/6znbItLiBFVtBqiy0vpMtA7 JIg62JZP2oDHLP5+qRK5gVqMdOcd+9KmMC9UQh9Gk4lck5Tnuwtktpsm e2M= ;; AUTHORITY SECTION: isc.org. 4275 IN NS sfba.sns-pb.isc.org. isc.org. 4275 IN NS ams.sns-pb.isc.org. isc.org. 4275 IN NS ns-ext.nrt1.isc.org. isc.org. 4275 IN NS ord.sns-pb.isc.org. isc.org. 4275 IN RRSIG NS 5 2 43200 20090715025015 20090615025015 27624 isc.org. RIvdvpRZXH6qVSII4KAOCPsWzQobJAehL+HqXDb75IEc5NyQ62d1yoTv IwQ0XS6apM9DSQimu2W7aoQV2rWco/q/Sb9RJ265sHBxmG5XAwDiXyDy c6R1R1jYp7EEgiju6nSBIem6cHqleG4qYAbgDD6V5vx2DLwlxXoY+f1P +ac= ;; ADDITIONAL SECTION: ams.sns-pb.isc.org. 4275 IN A 199.6.1.30 ord.sns-pb.isc.org. 4275 IN A 199.6.0.30 ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jun 16 10:13:00 2009 ;; MSG SIZE rcvd: 510 Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 18:06:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECAAE3A69E6; Mon, 15 Jun 2009 18:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.113 X-Spam-Level: X-Spam-Status: No, score=-5.113 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 iIY3xh5DRAx8; Mon, 15 Jun 2009 18:06:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 97A723A6781; Mon, 15 Jun 2009 18:06:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGN2L-000Bh6-RE for namedroppers-data0@psg.com; Tue, 16 Jun 2009 01:00:29 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGN22-000Beh-AE; Tue, 16 Jun 2009 01:00:23 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5G0xwAv006980; Mon, 15 Jun 2009 17:59:58 -0700 (PDT) Cc: Nicholas Weaver , Ray.Bellis@nominet.org.uk, Michael Graff , George Barwood , namedroppers@psg.com, Olafur Gudmundsson , owner-namedroppers@ops.ietf.org Message-Id: <1F3AD245-CBFB-425F-AC4F-2C0CE5D5B5E9@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Mark Andrews In-Reply-To: <200906160025.n5G0PHct010390@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] New rules for DO bit Date: Mon, 15 Jun 2009 17:59:58 -0700 References: <200906160025.n5G0PHct010390@drugs.dv.isc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 15, 2009, at 5:25 PM, Mark Andrews wrote: > > In message rg.uk>, Ray.Bellis@nominet.org.uk writes: >>> Do you have any data showing that a 1220-byte packet might make it, >>> where a 4096 one will not? >> >> I have plenty, albeit in the context of SOHO CPE. >> >> Lots of DNS proxies in routers will handle ~1464 bytes of payload >> (i.e. >> one PPPoE frame) but no larger. >> >> Ray > > Which would be a issue between the stub server and the > ultimate recursive server. It normally doesn't affect > traffic to and from iterative servers behind the SOHO CPE > because they don't go through the proxy code. Similar issues however crop up between the recursive server and the rest of the net, due to firewall issues, where the firewall code for handling DNS does not do proper reassembly. dig edns_large.netalyzr.icsi.berkeley.edu on a nameserver which supports EDNS (or even if it doesn't). It returns enough random CNAME junk that it will require fragmentation on an ethernet network. Its suprising how many recursive resolvers will fail to resolve that name. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 19:06:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2C63A6D30; Mon, 15 Jun 2009 19:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.847 X-Spam-Level: X-Spam-Status: No, score=-8.847 tagged_above=-999 required=5 tests=[AWL=-0.652, 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 YHMIyVzOy6iJ; Mon, 15 Jun 2009 19:06:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A3A03A68F5; Mon, 15 Jun 2009 19:06:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGNz8-000GKd-2z for namedroppers-data0@psg.com; Tue, 16 Jun 2009 02:01:14 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGNyv-000GJh-Nh for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 02:01:08 +0000 X-Files: PGP.sig : 186 X-IronPort-AV: E=Sophos;i="4.42,225,1243814400"; d="sig'?scan'208";a="42867979" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2009 02:00:59 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5G20xoR002434; Tue, 16 Jun 2009 04:00:59 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5G20xvQ018341; Tue, 16 Jun 2009 02:00:59 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 04:00:59 +0200 Received: from [192.168.1.186] ([10.61.103.176]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 04:00:58 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "George Barwood" In-Reply-To: Subject: Re: [dnsext] EDNS Page Option to handle large responses X-Priority: 3 References: Message-Id: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-148-522484549" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 04:00:56 +0200 Cc: X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 16 Jun 2009 02:00:58.0572 (UTC) FILETIME=[4AABF0C0:01C9EE26] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4084; t=1245117659; x=1245981659; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20

|Subject:=20Re=3A=20[dnsext]=20EDNS=20Page=20Option=20to=20 handle=20large=20responses |Sender:=20; bh=LFkK0EVS6twZUWAnFQtUaKG7hSYgrItJuOOj6OTsnMk=; b=e6/6pbIGwl1Ud2AYhPHUNlC+7d87Zy/RdHxbppFYNxHhrhEdgpkIEIbm8f OoxVokTxKusgSIL1sPU8tqyPbgz+/+6PfosZEbpJbrVCRvotWMTwsy3cKu+1 mnAKOMG4qY; Authentication-Results: ams-dkim-2; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-148-522484549 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 16 jun 2009, at 00.47, George Barwood wrote: > EDNS responses larger than ~1500 bytes currently suffer from 2 > problems due to IP fragmentation : > (1) They may fail to arrive due to IP implementation or equipment > configuration issues. I must say that implementing application layer "features" to solve a problem when IP layer is not behaving properly (can not handle fragmentation) is a layering violation in the architecture. If we do have problems with fragmented packets not being reassembled, then I think we have other problems as well in our networks. Patrik > (2) They are vulnerable to spoofing. > > (1) means that practical resolvers are likely to be forced to > implement a means of disabling > DNSSEC, which is a security issue. There is also the issue of > amplification attacks. > > It seems that large responses are definitely needed, typically for > fetching the dnskey rrset, for example > dig dnskey se @a.ns.se +dnssec > currently has a response size of 3958 bytes. > > I therefore propose an EDNS Page option that allows large responses > to be sent in smaller IP packets. > > Requirements: > (a) Should allow client to re-request specific packets that are lost. > (b) Should allow server to limit size of response to a single query > ( to limit amplification attacks ). > (c) Should be stateless. > > General idea: > The response is divided into pages of equal size. Pages are numbered > 0,1,2,3.... The client request has a Page option to > indicate support. If the response would otherwise be truncated > (including truncation of the additional section), the server > responds with a copy of the question and a single OPT record > containing a Page option, and possibly other options ( e.g. Ping ). > > Client request option data: > Page size (16 bits). Page number (16 bits - zero for initial > request). > > Server response option data: > Page size (16 bits). Page number (16 bits). Total response size (16 > bits). Version number (32 bits). Page Data (variable length). > > Description: > The page size is negotiated. The client initially indicates a > maximum page size (typically 1400 bytes, no less than 200 bytes). > The server responds with either the requested page size, or a > smaller page size (no less than 200 bytes), and the data for the first > page. The client then allocates a buffer for the whole response, and > sends a seperate request for each subsequent page, using the > negotiated page size. The client will need to keep track of > outstanding requests, and repeat any requests that receive no response > after a timeout period. The Version number sent by the server may > either be the Zone version (as in the SOA record), or a number > more specific to the query. If the response Version number or Page > size changes on subsequent pages, the client restarts the whole > process, in order to obtain a consistent set of pages. When the > assembly process is complete, the client processes the complete > assembled response in the normal way. > > If there is any indication of support, I am willing to submit this > as an ID. > > George Barwood > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org > with > the word 'unsubscribe' in a single line as the message text body. > archive: > --Apple-Mail-148-522484549 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) iD8DBQFKNvzYvHlR2X0luNwRAmE8AJwIJYGCka2JjxLaJOu7rGeetx3H7wCfed3t k6zr2dLCs+4y+fF3BLdH+Gs= =/4fS -----END PGP SIGNATURE----- --Apple-Mail-148-522484549-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 19:38:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 874623A6A56; Mon, 15 Jun 2009 19:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 3qqhlPjdYfB6; Mon, 15 Jun 2009 19:38:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF0523A6957; Mon, 15 Jun 2009 19:38:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGOTC-000Iiq-GX for namedroppers-data0@psg.com; Tue, 16 Jun 2009 02:32:18 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGOT0-000Ii2-DD for namedroppers@psg.com; Tue, 16 Jun 2009 02:32:12 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 53B25E602F; Tue, 16 Jun 2009 02:32:05 +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 n5G2Vw4x012711; Tue, 16 Jun 2009 12:31:59 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906160231.n5G2Vw4x012711@drugs.dv.isc.org> To: Nicholas Weaver Cc: Mark Andrews , Ray.Bellis@nominet.org.uk, Michael Graff , George Barwood , namedroppers@psg.com, Olafur Gudmundsson , owner-namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] New rules for DO bit In-reply-to: Your message of "Mon, 15 Jun 2009 17:59:58 MST." <1F3AD245-CBFB-425F-AC4F-2C0CE5D5B5E9@ICSI.Berkeley.EDU> Date: Tue, 16 Jun 2009 12:31:58 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I worry about this because you get validators sitting behind all sorts of crappy boxes which are *not* under the control of the validator owner and we are telling the validator owner that's tough @#$$!@# you can't validate despite there being a path which can allow the answers through. Also is there any demonstratable damage being caused by having the TCP queries? As far as I can see only sites behind the mis-configured firewalls will be impacted if TCP connections fail which is self correcting. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 20:03:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5863A6921; Mon, 15 Jun 2009 20:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-0.228, 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 zkYC8+zSCFzB; Mon, 15 Jun 2009 20:03:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D0743A6910; Mon, 15 Jun 2009 20:03:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGOsc-000Kah-6u for namedroppers-data0@psg.com; Tue, 16 Jun 2009 02:58:34 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGOsQ-000KZP-ES for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 02:58:28 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 8F82EE6072; Tue, 16 Jun 2009 02:58:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5G2wJWU013084; Tue, 16 Jun 2009 12:58:19 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906160258.n5G2wJWU013084@drugs.dv.isc.org> To: "George Barwood" Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] EDNS Page Option to handle large responses In-reply-to: Your message of "Mon, 15 Jun 2009 23:47:22 +0100." Date: Tue, 16 Jun 2009 12:58:19 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , "George Barwood" write s: > EDNS responses larger than ~1500 bytes currently suffer from 2 > problems due to IP fragmentation : (1) They may fail to arrive due > to IP implementation or equipment configuration issues. (2) They > are vulnerable to spoofing. > > (1) means that practical resolvers are likely to be forced to > implement a means of disabling DNSSEC, which is a security issue. > There is also the issue of amplification attacks. > > It seems that large responses are definitely needed, typically for > fetching the dnskey rrset, for example > dig dnskey se @a.ns.se +dnssec > currently has a response size of 3958 bytes. Which is easily reduced to 1769 bytes and could be reduced further with different key management / signing policies. e.g. I don't see the need to 3 ZSKs. ; <<>> DiG 9.6.1 <<>> dnskey se +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16083 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;se. IN DNSKEY ;; ANSWER SECTION: se. 3110 IN DNSKEY 256 3 5 AwEAAcZN0OVaokJAtEiVGan/g3J3gOeYx7BCLTX1RuaWPHmPKROR7nfU a2Hc7Glpdtofk/uk5Aeiq9BKAAavke7Abr35cPXxOIdxdX65K4se1Iqe YpX+oW66xsn87WV89t1yPS67/nqFP5tcHnRnqA3lXGDlcfkjEsMQwY/M flQSVIkl se. 3110 IN DNSKEY 256 3 5 AwEAAc9B2MqxtXW/bQUYBV5zHf1z8e8MRSVWleDlQ3XZaOMlki4g4qdX hJ2rHN69ZzmvMj2DjTvLd8lMTN54NiHntofBIg0ZJ9pi0pcDemeeVQ7B h7T1OYzaM2rnId7xfSaoXBdX+6tMhkB/3CXM/cgqgar33emkhzdPUDdS 8FYNBGuL se. 3110 IN DNSKEY 257 3 5 AwEAAdKc1sGsbv5jjeJ141IxNSTdR+nbtFn+JKQpvFZETaY5iMutoyWH a+jCp0TBBAzB2trGHzdi7E55FFzbeG0r+G6SJbJ4DXYSpiiELPiu0i+j Pp3C3kNwiqpPpQHWaYDS9MTQMu/QZHR/sFPbUnsK30fuQbKKkKgnADms 0aXalYUuCgDyVMjdxRLz5yzLoaSO9m5ii5cI0dQNCjexvj9M4ec6woi6 +N8v1pOmQAQ9at5Fd8A6tAxZI8tdlEUnXYgNwb8eVZEWsgXtBhoyAru7 Tzw+F6ToYq6hmKhfsT+fIhFXsYso7L4nYUqTnM4VOZgNhcTv+qVQkHfO OeJKUkNB8Qc= se. 3110 IN DNSKEY 257 3 5 AwEAAeeGE5unuosN3c8tBcj1/q4TQEwzfNY0GK6kxMVZ1wcTkypSExLC BPMS0wWkrA1n7t5hcM86VD94L8oEd9jnHdjxreguOZYEBWkckajU0tBW wEPMoEwepknpB14la1wy3xR95PMt9zWceiqaYOLEujFAqe6F3tQ14lP6 FdFL9wyCflV06K1ww+gQxYRDo6h+Wejguvpeg33KRzFtlwvbF3AapH2G XCi4Ok2+PO2ckzfKoikIe9ZOXfrCbG9ml2iQrRNSM4q3zGhuly4NrF/t 9s9jakbWzd4PM1Q551XIEphRGyqcbA2JTU3/mcUVKfgrH7nxaPz5DoUB 7TKYyQgsTlc= se. 3110 IN DNSKEY 256 3 5 AwEAAa03g6eUym7QeFGEt0wx88nUcQmqnRRoUos95ICScmAgXimeiIhA pAOTWUrrybMyCOVgeFH8oovLoR8UR3YmScloECOU/EZQ4gLXGtL74HlO X8hw0HhlkOXNfSlxWZBTOOQn2Rf9yS3xWZ+ciLTqgj9SFxKr4n0AT6sy rWYFt4jJ se. 3110 IN RRSIG DNSKEY 5 1 3600 20090620150322 20090613161805 19200 se. UhSsGzYoKJK+8slaT9Dml89T5wi5t0gpVJzumrbzEep1lmEt4zl18g2V Mqez0r7wUenNzyAh9H14fC+mCEDPT6sxJ98BE9fukDgsYr6XrQUJCUrR 7Ep4QwqGMlEyLo/YXew6mmckJ9PzCTMv/IAFg+S5zjYlXyzKZxljLNBl SSA= se. 3110 IN RRSIG DNSKEY 5 1 3600 20090714000000 20090603082815 8779 se. I27BwrRsb8C35yXXk/flZGWdPTiVP5ROxoW2oQI/refXunge+hfrdsd+ y/1CyyaUxYgCDvCXGh684I9QZyczUET1gSAfuPxwR+6v1PzxNarNz25z YKfc+erRiSQMNb5flaFSdytpotnLaWfKkYfvTxgt+HSLfrsi2RmMhyDT 4PdqCrcHvYgIrYyUBfKkrQvE1WGBlhLHu3mgWUwEEaJC2n7W5IF7bk4Z c0JIV3F4/1f0fE4zbS/gW35Bf+cLQTH/jQgfhR7QI1Z+FlpC60PHEUBf 9jKovhOUxa5pV9xdLDbB8r28LFlbr2XW0oxc4ohHuhRI7npKEFH/oFvQ U+f29A== se. 3110 IN RRSIG DNSKEY 5 1 3600 20090714000000 20090603082815 49678 se. WdATLxWZ7rBa13It4lH/v6vlL2UrdoMStxg4TC4x8e+otRQRBaaAHsmI DWh1cei9m2pAesgCqxYvsKmNvXw7WifBOamr8IV/82jJC593BAwVAQkD T05FhnfQ+i1LQZFUAz5s15dC7fee133qym0mjWNPEJStqE35cToCnl/R 2mGp8+juXcqE4Wm3DtYxqDIDaUqFmfXqvhL6w4nWw3tuBL8oC5kIjZ9k 4/ztzGjs27HwHofFAbJ4t6rglDaz0rpc+bcCWe1gvXExJ1rUWQBCxdYX FC3qfgWAw1ZRyIgTNL2yeHXofGmNmNtZ5HE8c2PCeq88KIJxTX8mFKUR mq6GXw== ;; Query time: 10 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jun 16 12:54:45 2009 ;; MSG SIZE rcvd: 1769 > I therefore propose an EDNS Page option that allows large responses > to be sent in smaller IP packets. > > Requirements: (a) Should allow client to re-request specific packets > that are lost. (b) Should allow server to limit size of response > to a single query ( to limit amplification attacks ). (c) Should > be stateless. > > General idea: The response is divided into pages of equal size. > Pages are numbered 0,1,2,3.... The client request has a Page option > to indicate support. If the response would otherwise be truncated > (including truncation of the additional section), the server responds > with a copy of the question and a single OPT record containing a > Page option, and possibly other options ( e.g. Ping ). > > Client request option data: Page size (16 bits). Page number (16 > bits - zero for initial request). > > Server response option data: Page size (16 bits). Page number (16 > bits). Total response size (16 bits). Version number (32 bits). > Page Data (variable length). > > Description: The page size is negotiated. The client initially > indicates a maximum page size (typically 1400 bytes, no less than > 200 bytes). The server responds with either the requested page > size, or a smaller page size (no less than 200 bytes), and the data > for the first page. The client then allocates a buffer for the whole > response, and sends a seperate request for each subsequent page, > using the negotiated page size. The client will need to keep track > of outstanding requests, and repeat any requests that receive no > response after a timeout period. The Version number sent by the > server may either be the Zone version (as in the SOA record), or > a number more specific to the query. If the response Version number > or Page size changes on subsequent pages, the client restarts the > whole process, in order to obtain a consistent set of pages. When > the assembly process is complete, the client processes the complete > assembled response in the normal way. > > If there is any indication of support, I am willing to submit this > as an ID. > > George Barwood -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 21:15:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D823A6784; Mon, 15 Jun 2009 21:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgIouFvsv5Gy; Mon, 15 Jun 2009 21:15:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5FE613A6900; Mon, 15 Jun 2009 21:15:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGPyl-000PUs-3a for namedroppers-data0@psg.com; Tue, 16 Jun 2009 04:08:59 +0000 Received: from [64.18.2.210] (helo=exprod7og127.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGPyX-000PTJ-AU for namedroppers@psg.com; Tue, 16 Jun 2009 04:08:53 +0000 Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKSjcaw3IvmIJ8PRkp5/GXIExW+kQKFKqJ@postini.com; Mon, 15 Jun 2009 21:08:45 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 206221BD69D; Mon, 15 Jun 2009 21:08:45 -0700 (PDT) Received: from [10.0.0.200] (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Mon, 15 Jun 2009 21:08:31 -0700 Subject: Re: [dnsext] New rules for DO bit MIME-Version: 1.0 (Apple Message framework v1067.4) Content-Type: text/plain; charset="us-ascii"; format=flowed From: Ted Lemon In-Reply-To: <200906160231.n5G2Vw4x012711@drugs.dv.isc.org> Date: Mon, 15 Jun 2009 21:08:29 -0700 CC: Nicholas Weaver , "Ray.Bellis@nominet.org.uk" , Michael Graff , George Barwood , "namedroppers@psg.com" , Olafur Gudmundsson , "owner-namedroppers@ops.ietf.org" Content-Transfer-Encoding: 7bit Message-ID: References: <200906160231.n5G2Vw4x012711@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1067.4) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 15, 2009, at 7:31 PM, Mark Andrews wrote: > I worry about this because you get validators sitting behind > all sorts of crappy boxes which are *not* under the control > of the validator owner and we are telling the validator > owner that's tough @#$$!@# you can't validate despite there > being a path which can allow the answers through. s/validator owner/upset customer/ This is a *good* thing. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 22:57:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26073A6830; Mon, 15 Jun 2009 22:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 nUgiWitoHATX; Mon, 15 Jun 2009 22:57:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EB8CC3A694D; Mon, 15 Jun 2009 22:57:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGRcC-0009Ra-R7 for namedroppers-data0@psg.com; Tue, 16 Jun 2009 05:53:48 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGRc1-0009OG-DH for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 05:53:42 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 480B0E606E; Tue, 16 Jun 2009 05:53:36 +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 n5G5rWCm015150; Tue, 16 Jun 2009 15:53:34 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906160553.n5G5rWCm015150@drugs.dv.isc.org> To: "George Barwood" Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] EDNS Page Option to handle large responses In-reply-to: Your message of "Tue, 16 Jun 2009 06:11:02 +0100." <2952105F69714941AA49EE6CA6EC1F02@localhost> Date: Tue, 16 Jun 2009 15:53:32 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <2952105F69714941AA49EE6CA6EC1F02@localhost>, "George Barwood" writes: > > ----- Original Message ----- From: "Patrik Fltstrm" > To: "George Barwood" Cc: > Sent: Tuesday, June 16, 2009 3:00 AM > Subject: Re: [dnsext] EDNS Page Option to handle large responses > > > I must say that implementing application layer "features" to solve a > > problem when IP layer is not behaving properly (can not handle > > fragmentation) is a layering violation in the architecture. If we do > > have problems with fragmented packets not being reassembled, then I > > think we have other problems as well in our networks. > > Yes. However doing nothing implies that DNSSEC can never be described > as hardened or secure in my opinion. > > Moving to something other than UDP is the other alternative, but > that usually seems to involve servers retaining state information, > which seems undesirable. > > EDNS is a layering violation in any case, but if we are to have it, > I think we need a layering violation that works :) Why do you think EDNS is a layering violation? All it signals is that you can receive larger responses at the application layer. EDNS works fine between end points that actually talk DNS. It fails when you add firewalls that think they know what the DNS protocol is but are 10 years behind the time or you have firewalls that think fragmentation should not occur or you have devices that pretend to talk DNS but don't actually talk DNS. There are also a few devices which fail to correctly re-assemble packet or fail to correctly translate packets but they are rare. Mark - Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 15 23:50:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD5E3A68F8; Mon, 15 Jun 2009 23:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 fO7NbUvE4Qin; Mon, 15 Jun 2009 23:50:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D6E2728C12A; Mon, 15 Jun 2009 23:50:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGSR1-000F7a-DJ for namedroppers-data0@psg.com; Tue, 16 Jun 2009 06:46:19 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGSQp-000F6l-NW for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 06:46:13 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id D5ACCE606E; Tue, 16 Jun 2009 06:46:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5G6k4DQ015500; Tue, 16 Jun 2009 16:46:04 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906160646.n5G6k4DQ015500@drugs.dv.isc.org> To: "George Barwood" Cc: "Mark Andrews" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] EDNS Page Option to handle large responses In-reply-to: Your message of "Tue, 16 Jun 2009 07:13:48 +0100." Date: Tue, 16 Jun 2009 16:46:04 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , "George Barwood" write s: > ----- Original Message ----- > From: "Mark Andrews" > To: "George Barwood" > Cc: > Sent: Tuesday, June 16, 2009 3:58 AM > Subject: Re: [dnsext] EDNS Page Option to handle large responses > > > In message , "George Barwood" write > > s: > >> EDNS responses larger than ~1500 bytes currently suffer from 2 > >> problems due to IP fragmentation : (1) They may fail to arrive due > >> to IP implementation or equipment configuration issues. (2) They > >> are vulnerable to spoofing. > >> > >> (1) means that practical resolvers are likely to be forced to > >> implement a means of disabling DNSSEC, which is a security issue. > >> There is also the issue of amplification attacks. > >> > >> It seems that large responses are definitely needed, typically for > >> fetching the dnskey rrset, for example > >> dig dnskey se @a.ns.se +dnssec > >> currently has a response size of 3958 bytes. > > > > Which is easily reduced to 1769 bytes and could be reduced > > further with different key management / signing policies. > > e.g. I don't see the need to 3 ZSKs. > > Ok, so we could warn operators that responses of larger than ~1500 bytes > to "normal" queries should be avoided if fallback to TCP is to be avoided. > As Paul Vixie has observed, fallback to TCP is not a realistic solution > for a busy zone ( or even any zone ). TCP fallback is fine for 999.9999% of zones though it will almost never happen for signed end zones even with a 512 byte EDNS buffer. The root and other infrastructure zones have very different query and response profiles to end user zones which make up the vast majority of zones. > I also doubt this is a robust solution. What if more than one algorithm needs > to be supported? Realistically you will only ever need to sign with one algorithm at a time. The use of two algorithms will be rare and transitional (e.g. from NSEC only to NSEC3 capable algorithms, or from SHA1 to sha256 based algorithms). You generally won't make such transitions until the majority of validators support the algorithm you are moving to or you need a feature that is only supported by a particular algorithm. > It feels like placing yourself in a strait-jacket, and I doubt > that thousands of zone administrators can ever be educated to understand the > issues and adopt key management policies to stay witnin such confining limits. 2 KSK's and 2 ZSK's won't result in fragmentation. 99.999% of zones don't need to use RFC 5011 as they will only publish in the parent by the use of DS/DLV records. One will just teach how to do DNSSEC using this maximum number of keys and the world will follow. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 00:31:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D87F3A68F8; Tue, 16 Jun 2009 00:31:37 -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 O2uVJJqk0gr1; Tue, 16 Jun 2009 00:31:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6BD763A6887; Tue, 16 Jun 2009 00:31:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGT4K-000JWZ-8N for namedroppers-data0@psg.com; Tue, 16 Jun 2009 07:26:56 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGT47-000JVB-Sn for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 07:26:49 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n5G7QZIr058555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2009 09:26:38 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A37492B.6040700@nlnetlabs.nl> Date: Tue, 16 Jun 2009 09:26:35 +0200 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Peter Koch CC: IETF DNSEXT WG Subject: Re: [dnsext] New rules for DO bit References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> In-Reply-To: <20090615211157.GD9397@x27.adm.denic.de> X-Enigmail-Version: 0.95.7 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.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 16 Jun 2009 09:26:38 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Peter, Peter Koch wrote: > As a protocol purist, I'd support this, but as an operator I'd rather avoid > such a draconian reaction. Ignoring the DO bit should be less problematic. > Also, it is in the spirit of "be conservative in what you send" (and > note that "liberal in what you accept" therefore doesn't include obeying > DO at <1220 octets). That sounds like one reason to do the draft approach. > Seconded, either way the dnssec-bis-updates document is the right place > to make this statement. It's hard to unilaterally standardize the > reaction to a non-compliant query, anyway. Yes I'd also prefer the draft statement put in dnssec-bis-updates. >> It is also much simpler. The if-statement 'truncation would be caused' >> complicates way too much, for no real benefit. Also a FORMERR causes > > Agreed. It would also lead to unnecessary protocal lawyering since > the client, albeit in violation of the spec, could argue that the > server would be obliged to engage in that extra calculation if it was > to ignore DO=1 only after it found that the response would have TC=1. > Thenew text should encourage the authoritative server to defend itself > against non compliant clients, rather than to restrict this ability. Also if the draft statement is used, I would like the 'truncation would be caused' clause to be removed. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAko3SSoACgkQkDLqNwOhpPjkJQCfUTnOMBzsNVVoA8C0n1Lb/Nkx Kr0AnRb2BMf5/bRrcrg0wfHV3+ExX7dT =JsZe -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 00:53:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126B33A69CC; Tue, 16 Jun 2009 00:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.705 X-Spam-Level: X-Spam-Status: No, score=-7.705 tagged_above=-999 required=5 tests=[AWL=-1.577, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 9yW04WHUpy3B; Tue, 16 Jun 2009 00:53:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 014D53A6405; Tue, 16 Jun 2009 00:53:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGTR0-000MV0-Tt for namedroppers-data0@psg.com; Tue, 16 Jun 2009 07:50:22 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGTQk-000MTi-PS for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 07:50:17 +0000 X-Files: PGP.sig : 186 X-IronPort-AV: E=Sophos;i="4.42,227,1243814400"; d="sig'?scan'208";a="42883421" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2009 07:50:04 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5G7o4VM030572; Tue, 16 Jun 2009 09:50:04 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5G7o4fe016049; Tue, 16 Jun 2009 07:50:04 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 09:50:04 +0200 Received: from 79.138.211.183.bredband.tre.se ([10.61.106.224]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 09:49:59 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "George Barwood" In-Reply-To: <2952105F69714941AA49EE6CA6EC1F02@localhost> Subject: Re: [dnsext] EDNS Page Option to handle large responses X-Priority: 3 References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <2952105F69714941AA49EE6CA6EC1F02@localhost> Message-Id: <30237F48-D593-4061-AC04-C59ED336897B@cisco.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-166-543426356" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 09:49:58 +0200 Cc: X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 16 Jun 2009 07:50:03.0570 (UTC) FILETIME=[0EDD0120:01C9EE57] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1570; t=1245138604; x=1246002604; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20

|Subject:=20Re=3A=20[dnsext]=20EDNS=20Page=20Option=20to=20 handle=20large=20responses |Sender:=20; bh=MAc/52e2K+gNX8gUo6nJiYylEJIKL1tdUdGEojZpiVs=; b=WET27VC81fU4okEgLH/+bvTNMFYorJez/MeDZZSUbwg6jJY+fBYScn/sIk MSTSRxv/xzD7Xe8MStM/qVlTJP/4VLK+OxJUal4nuuz9wc3Q4WiLHze1f8Ra cJUNbRefpc; Authentication-Results: ams-dkim-2; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-166-543426356 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 16 jun 2009, at 07.11, George Barwood wrote: > Yes. However doing nothing implies that DNSSEC can never be described > as hardened or secure in my opinion. Can you expand on this? Because of the fact fragments can be spoofed that you said in a different mail? Or because there are so many nodes deployed on the net that do not handle fragmentation correctly? I.e. I try to understand whether you see this as a generic security problem, or a deployment problem. > EDNS is a layering violation in any case, but if we are to have it, > I think > we need a layering violation that works :) It might have been a layering violation to define that DNS packets should stay below 512 bytes, but given that is part of the DNS standard, there is not much we can do. And, EDNS0 is also, as we all know, a more generic extension mechanism and not only for size negotiations. YMMV. Patrik --Apple-Mail-166-543426356 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) iD8DBQFKN06mvHlR2X0luNwRAixaAKCcUT6HvmqPn4PMQ1uaGpzXf6urZQCdFwUo Dz+s9dyT98g+DTG0AQHPKDY= =48dc -----END PGP SIGNATURE----- --Apple-Mail-166-543426356-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 03:22:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E16A3A6D5C; Tue, 16 Jun 2009 03:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.529 X-Spam-Level: X-Spam-Status: No, score=-4.529 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZmGsxx0qA34; Tue, 16 Jun 2009 03:22:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A83A3A6B01; Tue, 16 Jun 2009 03:22:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGVix-000DPz-Sg for namedroppers-data0@psg.com; Tue, 16 Jun 2009 10:17:03 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGVii-000DP9-Cn for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 10:16:58 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5GAEBtj010168; Tue, 16 Jun 2009 10:14:11 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5GAEB7L010167; Tue, 16 Jun 2009 10:14:11 GMT Date: Tue, 16 Jun 2009 10:14:11 +0000 From: bmanning@vacation.karoshi.com To: Mark Andrews Cc: George Barwood , Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses Message-ID: <20090616101411.GA9934@vacation.karoshi.com.> References: <2952105F69714941AA49EE6CA6EC1F02@localhost> <200906160553.n5G5rWCm015150@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906160553.n5G5rWCm015150@drugs.dv.isc.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > EDNS works fine between end points that actually talk DNS. It fails > when you add firewalls that think they know what the DNS protocol > is but are 10 years behind the time or you have firewalls that think > fragmentation should not occur or you have devices that pretend to > talk DNS but don't actually talk DNS. this is where you have to ask yourself, why do you think it is wise to continue to accomodate such behaviours? > Mark --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 05:19:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDAF93A6B74; Tue, 16 Jun 2009 05:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E-77a53Jn8n; Tue, 16 Jun 2009 05:19:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B91FD3A6B73; Tue, 16 Jun 2009 05:18:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGXXV-00019c-EV for namedroppers-data0@psg.com; Tue, 16 Jun 2009 12:13:21 +0000 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGXXH-00017l-Nz for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 12:13:15 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=monster; d=hopcount.ca; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=rSx4gkqEypmiRpA764VWVqhDaFsdcIXC03yLnkkkq524/DfdbYD/ECERfkifEgtl6QOm72BPi4+TsgGV3b/8oCtDpjjQmTp7l9J7hksal+fd14+HtWddcAjA51zpyMqr; Received: from [199.212.90.19] (helo=dh19.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGXW2-0001ii-Ey; Tue, 16 Jun 2009 12:11:50 +0000 Cc: IETF DNSEXT WG Message-Id: <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> From: Joe Abley To: Peter Koch In-Reply-To: <20090615211157.GD9397@x27.adm.denic.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] New rules for DO bit Date: Tue, 16 Jun 2009 08:11:50 -0400 References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 15-Jun-2009, at 17:11, Peter Koch wrote: > Seconded, either way the dnssec-bis-updates document is the right > place > to make this statement. It's hard to unilaterally standardize the > reaction to a non-compliant query, anyway. It sounds like you are wondering about how a recommendation such as the one Olafur proposed could be deployed. Are we mainly looking for a general solution to a potential general threat (i.e. give implementers and hence authority-only server operators an option if TCP query rates start to cause pain)? Or is this a more tactical measure designed principally for use by operators of infrastructure zones (the root, TLDs, etc)? If the latter, it seems reasonable to imagine that the number of code- bases and the number of operators needed to get blanket deployment are both rather low. If the former, then it doesn't seem important to worry about deployment; either the TCP query load will be a problem, in which case this measure might help, or it won't be a problem, in which case who cares about deployment. Either way it seems like if it's to be of any use consensus needs to be achieved and code written in conjunction with the DNSSEC deployment timeline, and based on the NTIA's desires with respect to the time to a signed root we need this to happen fairly quickly. Perhaps a different document is a good way of achieving targeted consensus and hence speed to implementation. Joe -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 07:25:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035793A6AEC; Tue, 16 Jun 2009 07:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 O2wfyfZr0DPD; Tue, 16 Jun 2009 07:25:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A92613A6D67; Tue, 16 Jun 2009 07:25:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGZXi-000GoZ-FE for namedroppers-data0@psg.com; Tue, 16 Jun 2009 14:21: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.69 (FreeBSD)) (envelope-from ) id 1MGZXX-000GmX-PT for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 14:21:37 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 7DB4DA5D02 for ; Tue, 16 Jun 2009 14:21:31 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses In-Reply-To: Your message of "Tue, 16 Jun 2009 06:11:02 +0100." <2952105F69714941AA49EE6CA6EC1F02@localhost> References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <2952105F69714941AA49EE6CA6EC1F02@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 16 Jun 2009 14:21:31 +0000 Message-ID: <57532.1245162091@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: "George Barwood" > Date: Tue, 16 Jun 2009 06:11:02 +0100 > ... > EDNS is a layering violation in any case, ... please explain further? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 07:26:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 786A93A6BA9; Tue, 16 Jun 2009 07:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.999 X-Spam-Level: X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSrKwOJcU6jX; Tue, 16 Jun 2009 07:26:53 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 6FCBB3A6A7D; Tue, 16 Jun 2009 07:26:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGZWC-000GdO-ES for namedroppers-data0@psg.com; Tue, 16 Jun 2009 14:20: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.69 (FreeBSD)) (envelope-from ) id 1MGZW1-000Gc2-97 for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 14:20:02 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id E115FA5D02 for ; Tue, 16 Jun 2009 14:19:56 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses In-Reply-To: Your message of "Tue\, 16 Jun 2009 04\:00\:56 +0200." <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 14:19:56 +0000 Message-ID: <57324.1245161996@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Patrik F=E4ltstr=F6m > Date: Tue, 16 Jun 2009 04:00:56 +0200 >=20 > On 16 jun 2009, at 00.47, George Barwood wrote: >=20 > > EDNS responses larger than ~1500 bytes currently suffer from 2 problems > > due to IP fragmentation : (1) They may fail to arrive due to IP > > implementation or equipment configuration issues. >=20 > I must say that implementing application layer "features" to solve a > problem when IP layer is not behaving properly (can not handle > fragmentation) is a layering violation in the architecture. If we do have > problems with fragmented packets not being reassembled, then I think we > have other problems as well in our networks. >=20 > Patrik agreed. all forms of multipacket require that state be maintained, and as a matter of architectural principle, multipacket state should be in the network stack and not in the application. (thus my recent interest in SCTP= .) (which is one reason why EDNS's original MD option bit was removed before standardization.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 07:44:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 878B13A69C4; Tue, 16 Jun 2009 07:44:24 -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=-0.508, 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 p7fx81vyKEh3; Tue, 16 Jun 2009 07:44:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6020A3A6915; Tue, 16 Jun 2009 07:44:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGZqU-000JPR-2r for namedroppers-data0@psg.com; Tue, 16 Jun 2009 14:41:06 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGZqI-000JOL-Ot for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 14:41:00 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5GEegfx023035; Tue, 16 Jun 2009 10:40:43 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906161440.n5GEegfx023035@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Jun 2009 10:40:33 -0400 To: Joe Abley , Peter Koch From: Olafur Gudmundsson Subject: Re: [dnsext] New rules for DO bit Cc: IETF DNSEXT WG In-Reply-To: <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Andrew is the sole chair of the working group when it comes to this document. I put the document out to stimulate discussion, the document describes what is needed to allow "Ignore DO bit" and when. (+/- guidance on when to ignore, when needed or always). The current draft does not explicitly say that resolvers need to cache based on the DO bit setting in answer not query. I agree that publishing this in dnssec-bis-updates would be the right place, BUT something is IMHO needed NOW and dnssec-bis-updates is moving slowly. If we need an RFC too beat up vendors then this document is the way to go, if we just need a consensus, next rev can reflect that and then get incorporated into dnssec-bis-updates. Personally I do not care if we specify "Ignore DO" or FORMERR but I prefer the one that will put more pressure on bad boxes. Olafur At 08:11 16/06/2009, Joe Abley wrote: >On 15-Jun-2009, at 17:11, Peter Koch wrote: > >>Seconded, either way the dnssec-bis-updates document is the right >>place >>to make this statement. It's hard to unilaterally standardize the >>reaction to a non-compliant query, anyway. > >It sounds like you are wondering about how a recommendation such as >the one Olafur proposed could be deployed. > >Are we mainly looking for a general solution to a potential general >threat (i.e. give implementers and hence authority-only server >operators an option if TCP query rates start to cause pain)? > >Or is this a more tactical measure designed principally for use by >operators of infrastructure zones (the root, TLDs, etc)? > >If the latter, it seems reasonable to imagine that the number of >code- bases and the number of operators needed to get blanket deployment are >both rather low. > >If the former, then it doesn't seem important to worry about >deployment; either the TCP query load will be a problem, in which case >this measure might help, or it won't be a problem, in which case who >cares about deployment. > >Either way it seems like if it's to be of any use consensus needs to >be achieved and code written in conjunction with the DNSSEC deployment >timeline, and based on the NTIA's desires with respect to the time to >a signed root we need this to happen fairly quickly. Perhaps a >different document is a good way of achieving targeted consensus and >hence speed to implementation. > > >Joe > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 08:21:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F4CF3A6B8F; Tue, 16 Jun 2009 08:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.287 X-Spam-Level: X-Spam-Status: No, score=-4.287 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 FetQ2acxFuQb; Tue, 16 Jun 2009 08:21:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1EE083A6B79; Tue, 16 Jun 2009 08:21:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGaQB-000Ot9-AQ for namedroppers-data0@psg.com; Tue, 16 Jun 2009 15:17:59 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGaPz-000Os1-8C for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 15:17:53 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 0589563D441; Tue, 16 Jun 2009 08:17:47 -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 RPXFaO0OBVuG; Tue, 16 Jun 2009 08:17:44 -0700 (PDT) Received: from wlan39-215.mdr.icann.org (wlan39-215.mdr.icann.org [192.0.39.215]) by virtualized.org (Postfix) with ESMTP id B15A863D432; Tue, 16 Jun 2009 08:17:44 -0700 (PDT) From: David Conrad To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> Subject: Re: [dnsext] EDNS Page Option to handle large responses X-Priority: 3 References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 08:17:35 -0700 Cc: "George Barwood" , X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 15, 2009, at 7:00 PM, Patrik F=E4ltstr=F6m wrote: > On 16 jun 2009, at 00.47, George Barwood wrote: > >> EDNS responses larger than ~1500 bytes currently suffer from 2 =20 >> problems due to IP fragmentation : >> (1) They may fail to arrive due to IP implementation or equipment =20 >> configuration issues. > > I must say that implementing application layer "features" to solve a =20= > problem when IP layer is not behaving properly (can not handle =20 > fragmentation) is a layering violation in the architecture. It just means that you (typically) need to replicate logic found in =20 connection oriented transport protocols. See (original) NFS for an =20 example. I guess you could call it a layering violation, but if so, =20 allowing applications to choose between connection-oriented and =20 connectionless would be the same sort of layering violation. > If we do have problems with fragmented packets not being =20 > reassembled, then I think we have other problems as well in our =20 > networks. ? http://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.37.5308 http://tools.ietf.org/html/draft-heffner-frag-harmful-05 The whole point behind RFC 1191 Etc. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 08:41:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF7E3A6804; Tue, 16 Jun 2009 08:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.412 X-Spam-Level: X-Spam-Status: No, score=-4.412 tagged_above=-999 required=5 tests=[AWL=0.025, 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 vof2a+VfSOSp; Tue, 16 Jun 2009 08:41:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 882F83A6AFF; Tue, 16 Jun 2009 08:41:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGaii-0001GN-1n for namedroppers-data0@psg.com; Tue, 16 Jun 2009 15:37:08 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGaiU-0001Eo-7P for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 15:37:00 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id E995963D5B1; Tue, 16 Jun 2009 08:36:53 -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 A-0u2UThNJnC; Tue, 16 Jun 2009 08:36:52 -0700 (PDT) Received: from wlan39-215.mdr.icann.org (wlan39-215.mdr.icann.org [192.0.39.215]) by virtualized.org (Postfix) with ESMTP id 9CA4E63D5A2; Tue, 16 Jun 2009 08:36:52 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: From: David Conrad To: Paul Vixie In-Reply-To: <57324.1245161996@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS Page Option to handle large responses Date: Tue, 16 Jun 2009 08:36:52 -0700 References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 16, 2009, at 7:19 AM, Paul Vixie wrote: > all forms of multipacket require that state be maintained, and as > a matter of architectural principle, multipacket state should be in > the > network stack and not in the application. If the size of a 'normal' DNS response is going to result in fragmentation, we have four choices: a) hope IP fragmentation works b) fall back to TCP c) implement multipacket state over UDP in the application d) use a new protocol, e.g.: > (thus my recent interest in SCTP.) Historically, (a) has been problematic and is likely to remain so in the future (although maybe PMTUD will help). Option (b) puts the burden on the server which doesn't scale particularly well, but has worked to date. Option (c) properly done would put the burden on the application and would thus scale better, but would require additional complexity in the DNS and redeployment of all DNS servers. Option (d) would probably scale well (depending on the protocol) and wouldn't likely add significant additional complexity to the DNS, but would not only require redeployment of all DNS servers, but also require the deployment of infrastructure capable of supporting the new protocol. I suspect a better option is to not make the 'normal' DNS response require fragmentation. Too bad we're going the opposite direction. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 08:52:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928343A6D7E; Tue, 16 Jun 2009 08:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 fg-xWPem6-iJ; Tue, 16 Jun 2009 08:52:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 931E93A691F; Tue, 16 Jun 2009 08:52:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGaud-0002nc-A6 for namedroppers-data0@psg.com; Tue, 16 Jun 2009 15:49:27 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGauM-0002m8-Ep for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 15:49:20 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5GFn4WX007711; Tue, 16 Jun 2009 08:49:06 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: <80022C3C-A52E-40C9-AA86-68B8E010FD67@icsi.berkeley.edu> From: Nicholas Weaver To: Paul Vixie In-Reply-To: <57324.1245161996@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS Page Option to handle large responses Date: Tue, 16 Jun 2009 08:49:03 -0700 References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 16, 2009, at 7:19 AM, Paul Vixie wrote: >> From: Patrik F=E4ltstr=F6m >> Date: Tue, 16 Jun 2009 04:00:56 +0200 >> >> On 16 jun 2009, at 00.47, George Barwood wrote: >> >>> EDNS responses larger than ~1500 bytes currently suffer from 2 =20 >>> problems >>> due to IP fragmentation : (1) They may fail to arrive due to IP >>> implementation or equipment configuration issues. >> >> I must say that implementing application layer "features" to solve a >> problem when IP layer is not behaving properly (can not handle >> fragmentation) is a layering violation in the architecture. If we =20 >> do have >> problems with fragmented packets not being reassembled, then I =20 >> think we >> have other problems as well in our networks. >> >> Patrik > > agreed. all forms of multipacket require that state be maintained, =20= > and as > a matter of architectural principle, multipacket state should be in =20= > the > network stack and not in the application. (thus my recent interest =20= > in SCTP.) Unfortunately, the Internet is one giant layering violation in this =20 respect. We don't have final numbers (heck, we're still collecting data, let =20 alone analyzing it), but the number of resolvers which can't handle an =20= 1800B DNS response even though they advertise EDNS support is =20 shockingly large, as is the number of end hosts which can't directly =20 request an 1800B DNS response. For the purposes of DNS, you NEED a valid story that takes into =20 account this issue, unless you view not working for a significant =20 percentage of the Internet not a problem. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 09:38:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C30F3A694E; Tue, 16 Jun 2009 09:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.107 X-Spam-Level: X-Spam-Status: No, score=-5.107 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 raSOxStgmfyX; Tue, 16 Jun 2009 09:38:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 11ED63A6A9C; Tue, 16 Jun 2009 09:38:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGbbo-0008YM-Uf for namedroppers-data0@psg.com; Tue, 16 Jun 2009 16:34:04 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGbbb-0008XI-Pn for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 16:33:59 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5GGXfYn014772; Tue, 16 Jun 2009 09:33:41 -0700 (PDT) Cc: Nicholas Weaver , Paul Vixie , namedroppers@ops.ietf.org Message-Id: <05AA9768-3D35-4223-81BF-08D63A9AE4B4@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Michael Graff In-Reply-To: <4A37C388.2080702@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS Page Option to handle large responses Date: Tue, 16 Jun 2009 09:33:41 -0700 References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> <80022C3C-A52E-40C9-AA86-68B8E010FD67@icsi.berkeley.edu> <4A37C388.2080702@isc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 16, 2009, at 9:08 AM, Michael Graff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Nicholas Weaver wrote: > >> We don't have final numbers (heck, we're still collecting data, let >> alone analyzing it), but the number of resolvers which can't handle >> an >> 1800B DNS response even though they advertise EDNS support is >> shockingly >> large, as is the number of end hosts which can't directly request an >> 1800B DNS response. > > Careful there. What specifically cannot handle it? The resolver > itself? Or some device between it and the authority? The test in question: The response generated to edns_large. {anything}.netalyzr.icsi.berkeley.edu is ~1800B, padded by a number of irrelevant CNAMEs in the additional section (the CNAME block is actually located between the A records for the two listed "authorities"). It does not validate EDNS requested size, (but that is captured in another test), so it may exceed the advertised EDNS capacity of the server for this particular test. The response is generated from a standard ethernet interface without jumbo frame enabled, so it is being fragmented by the sender. Since the response padding is garbage, unrelated CNAMEs in the additional section, we would not except most recursive resolvers to include them in a response. For the purposes of testing the user's resolver: The path between ICSI and the user's recursive resolver, or the user's recursive resolver itself, is unable to either properly reassemble the fragmented response when it needs to, interpret the DNS response (but all others worked), or is unable to fragment further if the ethernet 1500B MTU is too large. For the purposes of testing the user's local connection: The path between Amazon EC2 and the user's local connection, or the user's own computer, is unable to either properly reassemble the fragmented response when it needs to, an in-path device was unable to interpret the DNS response when it attempted (but was able to interpret a request for entropy.netalyzr...), or is unable to fragment further if the ethernet 1500 MTU is too large. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 10:06:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FEC03A6D8E; Tue, 16 Jun 2009 10:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.105 X-Spam-Level: X-Spam-Status: No, score=-5.105 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 dxc-+gpeYfm6; Tue, 16 Jun 2009 10:06:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 237F33A6D89; Tue, 16 Jun 2009 10:06:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGc2T-000C5Z-DF for namedroppers-data0@psg.com; Tue, 16 Jun 2009 17:01:37 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGc2I-000C3m-6C for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 17:01:31 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5GH1MtV019122; Tue, 16 Jun 2009 10:01:22 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: <48048A15-C485-40BC-95E3-4931F5D12BE2@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Michael Graff In-Reply-To: <4A37CC42.6060901@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS Page Option to handle large responses Date: Tue, 16 Jun 2009 10:01:22 -0700 References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> <80022C3C-A52E-40C9-AA86-68B8E010FD67@icsi.berkeley.edu> <4A37C388.2080702@isc.org> <05AA9768-3D35-4223-81BF-08D63A9AE4B4@ICSI.Berkeley.EDU> <4A37CC42.6060901@isc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 16, 2009, at 9:45 AM, Michael Graff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Nicholas Weaver wrote: >> >> On Jun 16, 2009, at 9:08 AM, Michael Graff wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Nicholas Weaver wrote: >>> >>>> We don't have final numbers (heck, we're still collecting data, let >>>> alone analyzing it), but the number of resolvers which can't >>>> handle an >>>> 1800B DNS response even though they advertise EDNS support is >>>> shockingly >>>> large, as is the number of end hosts which can't directly request >>>> an >>>> 1800B DNS response. >>> >>> Careful there. What specifically cannot handle it? The resolver >>> itself? Or some device between it and the authority? >> >> >> The test in question: > ... >> It does not validate EDNS requested size, (but that is captured in >> another test), so it may exceed the advertised EDNS capacity of the >> server for this particular test. > > So if someone advertises a 1000 byte packet size you still blast them > with 1800, and are surprised they cannot handle it? > > I was more worried about your comments about the "resolvers cannot > handle" which I found to be inaccurate. Your test as stated means you > are intentionally flooding them with more data and ignoring the EDNS > advertised size, unless I misread what you said. > > Also, saying that the "resolver cannot handle" implies the resolver > code > is broken, when I suspect it is often times a firewall external to the > resolving software. That is, "a resolver does not receive fragmented > packets" is perhaps accurate, but "a resolver cannot handle" is > probably > not. > > I'm not picking on you, just wanting to make clear where the problem > is, > and if your tools can do that awesome. I like what you've done so > far, > and am glad that my home connection as rated as close to perfect as I > can get it! We do a second test where we check and capture what the advertised MTU size is, so we can exclude those cases where our response exceeds the advertised MTU size. ONLY looking at those where we capture the advertised MTU as well (capturing the MTU requires the user to trust the applet), and the advertised MTU is >1900 bytes, the number of cases which fail to resolve this name is high. We do NOT however check whether it does a successful fallback, redoing the request with a lower EDNS MTU and whether that succeeds: the point is to check whether the large ADVERTISED MTU can be used. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 10:18:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03BE43A6BDA; Tue, 16 Jun 2009 10:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 qiq6JTFVX1pK; Tue, 16 Jun 2009 10:18:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 14CF53A6A61; Tue, 16 Jun 2009 10:18:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGcFT-000DqM-OH for namedroppers-data0@psg.com; Tue, 16 Jun 2009 17:15:03 +0000 Received: from [81.91.160.182] (helo=office.denic.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGcFI-000DpF-GK for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 17:14:57 +0000 Received: from unknown.office.denic.de ([10.122.65.182]) by office.denic.de with esmtp id 1MGcFG-000613-CD; Tue, 16 Jun 2009 19:14:50 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 559AC19C8C9; Tue, 16 Jun 2009 19:14:49 +0200 (CEST) Date: Tue, 16 Jun 2009 19:14:49 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: Re: [dnsext] New rules for DO bit Message-ID: <20090616171449.GC1171@unknown.office.denic.de> References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> User-Agent: Mutt/1.4.2.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jun 16, 2009 at 08:11:50AM -0400, Joe Abley wrote: > >to make this statement. It's hard to unilaterally standardize the > >reaction to a non-compliant query, anyway. > > It sounds like you are wondering about how a recommendation such as > the one Olafur proposed could be deployed. there are two aspects to this: 1) When a document is proposed (no pun) for Standards Track, I think one should be able to elevate it there per the rules (even if that never happens), which means the interoperability requirements must be clear. In this case, the server is reacting to a question in violation of the spec and I have difficulties to see how "two independent implementations" could successfully interoperate. 2) By specifying the correct behaviour and limiting the possible reactions one creates a grey area where both sides might be raight and wrong. > threat (i.e. give implementers and hence authority-only server > operators an option if TCP query rates start to cause pain)? Ideally, before that happens. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 10:51:38 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C9B23A6AA6; Tue, 16 Jun 2009 10:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=-0.780, 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 ZUPGA4tM3iyY; Tue, 16 Jun 2009 10:51:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2823A3A68D8; Tue, 16 Jun 2009 10:51:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGclW-000J0g-HV for namedroppers-data0@psg.com; Tue, 16 Jun 2009 17:48:10 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGclJ-000Iz2-Qp for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 17:48:04 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MGcl4-00012Z-6j; Tue, 16 Jun 2009 19:47:42 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MGcl3-0005Dd-MO; Tue, 16 Jun 2009 19:47:41 +0200 From: Florian Weimer To: Olafur Gudmundsson Cc: Joe Abley , Peter Koch , IETF DNSEXT WG Subject: Re: [dnsext] New rules for DO bit References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> Date: Tue, 16 Jun 2009 19:47:41 +0200 In-Reply-To: <200906161440.n5GEegfx023035@stora.ogud.com> (Olafur Gudmundsson's message of "Tue, 16 Jun 2009 10:40:33 -0400") Message-ID: <87ocsohxz6.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Olafur Gudmundsson: > Personally I do not care if we specify "Ignore DO" or FORMERR but I > prefer the one that will put more pressure on bad boxes. Do not answer such broken queries. This will make the issue obvious right now. It mainly punishes the violator, and not both ends (to the degree that is possible if you deliberately prevent a transaction which is mutually beneficial). Ignoring DO or sending FORMERR will not make a difference to the violator if DNSSEC is not involved. Either no fallback is needed at all, or it will happen after one round-trip (which is still not such a huge delay that it is likely to catch operator attention). If DNSSEC is involved and the violator lacks a BAD cache, a self-DoS due to a query storm might be the result, punishing both ends. By the way, it's still not clear to me if this thread is about improving the DNS protocol in an objective sense, or punishing ISC for more or less deliberately misinterpreting an RFC. That is, I don't see the protocol-level harm caused by the BIND behavior. (In the abstract, I can imagine that a dominant vendor is able to cause quite arbitrary damage by ignoring established standards, both to the protocol itself and the standardization process.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 11:28:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7648A3A6D7A; Tue, 16 Jun 2009 11:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.016 X-Spam-Level: X-Spam-Status: No, score=0.016 tagged_above=-999 required=5 tests=[AWL=-0.734, 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 2GAtSTBtgvvg; Tue, 16 Jun 2009 11:28:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D7DF13A6D12; Tue, 16 Jun 2009 11:27:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGdKU-000OPa-5y for namedroppers-data0@psg.com; Tue, 16 Jun 2009 18:24:18 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGdKI-000OOq-U6 for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 18:24:12 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MGdKG-0001Yr-QQ; Tue, 16 Jun 2009 20:24:04 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MGdKF-00064x-Ng; Tue, 16 Jun 2009 20:24:03 +0200 From: Florian Weimer To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> Date: Tue, 16 Jun 2009 20:24:03 +0200 In-Reply-To: <57324.1245161996@nsa.vix.com> (Paul Vixie's message of "Tue, 16 Jun 2009 14:19:56 +0000") Message-ID: <87ab48ghq4.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Paul Vixie: > agreed. all forms of multipacket require that state be maintained, > and as a matter of architectural principle, multipacket state should > be in the network stack and not in the application. (thus my recent > interest in SCTP.) I think this is simply wrong, especially if you strive for resilience against protocol-specific denial-of-service attacks. If you hide state in the stack, you lose control over it, and you end up with resource exhaustion attacks. I think this is the essence of your dislike towards TCP (and admittedly, it's practically impossible to work around that if all you've got is the BSD sockets API). Unfortunately, SCTP is just more of the same. By the way, cryptography enables the server to securely carry state from packet to packet, keeping it in the client or in network buffers (the latter similar to delay line memory). The client only has to pass back blobs it has received from the server. There are probably some web frameworks which use this to carry state. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 12:04:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6164E3A6AC5; Tue, 16 Jun 2009 12:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 3HNphhbA0ecu; Tue, 16 Jun 2009 12:04:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6D2AA3A6A49; Tue, 16 Jun 2009 12:04:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGdtX-0003Hp-Ca for namedroppers-data0@psg.com; Tue, 16 Jun 2009 19:00:31 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGdtI-0003Gp-JI for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 19:00:25 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 055AFA5D61 for ; Tue, 16 Jun 2009 19:00:16 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses In-Reply-To: Your message of "Tue, 16 Jun 2009 08:36:52 MST." References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 16 Jun 2009 19:00:16 +0000 Message-ID: <82866.1245178816@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: David Conrad > Date: Tue, 16 Jun 2009 08:36:52 -0700 > > On Jun 16, 2009, at 7:19 AM, Paul Vixie wrote: > > all forms of multipacket require that state be maintained, and as a > > matter of architectural principle, multipacket state should be in the > > network stack and not in the application. > > If the size of a 'normal' DNS response is going to result in > fragmentation, we have four choices: > > a) hope IP fragmentation works > b) fall back to TCP > c) implement multipacket state over UDP in the application > d) use a new protocol, e.g.: > > > (thus my recent interest in SCTP.) yes. > Historically, (a) has been problematic and is likely to remain so in the > future (although maybe PMTUD will help). Option (b) puts the burden on > the server which doesn't scale particularly well, but has worked to date. > Option (c) properly done would put the burden on the application and > would thus scale better, but would require additional complexity in the > DNS and redeployment of all DNS servers. Option (d) would probably scale > well (depending on the protocol) and wouldn't likely add significant > additional complexity to the DNS, but would not only require redeployment > of all DNS servers, but also require the deployment of infrastructure > capable of supporting the new protocol. my reason for preferring to keep multipacket state in the network stack vs. the application is that i've always been able to do a better job resisting DDoS in the kernel, firewalls, routers, or upstream cleanerboxes, than by delivering all traffic to the server and then context switching in user mode (where capabilities like virtual memory and file systems are irrelevant.) > I suspect a better option is to not make the 'normal' DNS response > require fragmentation. Too bad we're going the opposite direction. that's an argument for using smaller crypto. people who know crypto tell me that the bernstein curve is both good, fast, and cheap. don't let dnscurve's use of nameserver names as public keys and the fact that it protects links in the path rather than the data itself, keep us from considering the elliptic curve as a potentially better crypto algo for dnssec. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 12:04:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6204A3A6A49; Tue, 16 Jun 2009 12:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bRw4ET+Iije; Tue, 16 Jun 2009 12:04:41 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id AAE283A6951; Tue, 16 Jun 2009 12:04:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGdv4-0003WL-Lb for namedroppers-data0@psg.com; Tue, 16 Jun 2009 19:02:06 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGdup-0003V6-PK for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 19:02:00 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 8020AA5D4D for ; Tue, 16 Jun 2009 19:01:51 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses In-Reply-To: Your message of "Tue, 16 Jun 2009 08:49:03 MST." <80022C3C-A52E-40C9-AA86-68B8E010FD67@icsi.berkeley.edu> References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> <80022C3C-A52E-40C9-AA86-68B8E010FD67@icsi.berkeley.edu> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 16 Jun 2009 19:01:51 +0000 Message-ID: <83030.1245178911@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Nicholas Weaver > Date: Tue, 16 Jun 2009 08:49:03 -0700 > ... > For the purposes of DNS, you NEED a valid story that takes into account > this issue, unless you view not working for a significant percentage of > the Internet not a problem. that's an argument for doing all future protocol development over HTTPS. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 12:24:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E916C3A6BC0; Tue, 16 Jun 2009 12:24:59 -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=[AWL=0.012, 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 o14ZWt-f9psY; Tue, 16 Jun 2009 12:24:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0797D3A6BF0; Tue, 16 Jun 2009 12:24:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGeEY-0006Wl-Tc for namedroppers-data0@psg.com; Tue, 16 Jun 2009 19:22: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.69 (FreeBSD)) (envelope-from ) id 1MGeEF-0006Uo-Ty for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 19:22:01 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id A211CA5D28 for ; Tue, 16 Jun 2009 19:21:55 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses In-Reply-To: Your message of "Tue, 16 Jun 2009 18:41:11 +0100." <18F79DCC22DB4FF7A68442D929B04F2A@localhost> References: <200906160646.n5G6k4DQ015500@drugs.dv.isc.org> <57895D72CEEF4452836C35361419B311@localhost> <4A37B5E8.2020309@isc.org> <18F79DCC22DB4FF7A68442D929B04F2A@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 16 Jun 2009 19:21:55 +0000 Message-ID: <83930.1245180115@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: "George Barwood" > Date: Tue, 16 Jun 2009 18:41:11 +0100 > ... > In any sane system, achieving security against out-of-path attacks should > take place in a layer that is precisely specified to achieve this goal, > and is guarunteed to work. > > The IP protocol is unfortunately not up to the job, ... i think you mean "UDP/IP by itself is not up to the job", since every solution we're discussing (including page option and sctp) uses IP. > so to achieve security (that is security from blind out-of-path DoS > attacks) I think you have do some work in an EDNS layer ( or some other > layer on top of basic UDP ). This is what I am proposing. much of the lossage that hurts EDNS today is because of middleboxes that insist on UDP/53 payloads being smaller than 513 octets, or not having additional data sections, or not containing nxdomain. more edns options won't help in those cases. sadly, those middleboxes are now part of the installed base, so our choices are ignore them and be blamed for failures, or to work within their limitations. if we're going to ignore these middleboxes then we can stick to edns as it is, which depends on ip fragmentation, which leads to failures, for which we are being blamed already. or if we're going to ignore these middleboxes then we should ask for what we really want, which looks more and more to me like SCTP. (reasons posted separately, with an actual proposal coming soon.) if we're not going to ignore these boxes, we should just define an HTTPS XML schema for DNS transactions, and hide in encrypted streams that middleboxes are already forced by the fortune 500 to tolerate. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 12:32:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11C513A6BC0; Tue, 16 Jun 2009 12:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.897 X-Spam-Level: X-Spam-Status: No, score=-102.897 tagged_above=-999 required=5 tests=[AWL=3.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JwAW1+UHL3E; Tue, 16 Jun 2009 12:32:27 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 246F53A6B92; Tue, 16 Jun 2009 12:32:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGeKd-0007RW-2Y for namedroppers-data0@psg.com; Tue, 16 Jun 2009 19:28:31 +0000 Received: from [209.85.210.173] (helo=mail-yx0-f173.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGeKR-0007QX-NG for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 19:28:25 +0000 Received: by yxe3 with SMTP id 3so134218yxe.33 for ; Tue, 16 Jun 2009 12:28:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.116.6 with SMTP id o6mr7538958agc.34.1245180498333; Tue, 16 Jun 2009 12:28:18 -0700 (PDT) In-Reply-To: <82866.1245178816@nsa.vix.com> References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> <82866.1245178816@nsa.vix.com> Date: Tue, 16 Jun 2009 12:28:18 -0700 Message-ID: Subject: Re: [dnsext] EDNS Page Option to handle large responses From: Matthew Dempsky 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: On Tue, Jun 16, 2009 at 12:00 PM, Paul Vixie wrote: > that's an argument for using smaller crypto. =A0people who know crypto te= ll me > that the bernstein curve is both good, fast, and cheap. =A0don't let dnsc= urve's > use of nameserver names as public keys and the fact that it protects link= s in > the path rather than the data itself, keep us from considering the ellipt= ic > curve as a potentially better crypto algo for dnssec. There are at least two reasonable approaches DNSSEC could take to reduce packet size: 1. Use Rabin-Williams signatures like Adam Langley's rwb0fuz1024 proposal last fall: Rabin-Williams signatures can be verified faster than RSA, signatures can be compressed to 1/2 size, and public keys can be compressed to 1/3 size. 2. Use elliptic curve signatures: public keys and signatures are smaller still; verification time for a single signature is slower, but batch verification of signatures can help to compensate for this. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 12:37:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E5428C1AE; Tue, 16 Jun 2009 12:37:04 -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=[AWL=0.012, 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 icJtXbmjjBc4; Tue, 16 Jun 2009 12:37:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D999D3A69A6; Tue, 16 Jun 2009 12:37:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGePk-0008Gz-JZ for namedroppers-data0@psg.com; Tue, 16 Jun 2009 19:33:48 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGePY-0008C2-WC for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 19:33:42 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id AD67BA5D6B for ; Tue, 16 Jun 2009 19:33:36 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] New rules for DO bit In-Reply-To: Your message of "Tue, 16 Jun 2009 19:47:41 +0200." <87ocsohxz6.fsf@mid.deneb.enyo.de> References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 16 Jun 2009 19:33:36 +0000 Message-ID: <84444.1245180816@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Florian Weimer > Date: Tue, 16 Jun 2009 19:47:41 +0200 > > * Olafur Gudmundsson: > > Personally I do not care if we specify "Ignore DO" or FORMERR but I > > prefer the one that will put more pressure on bad boxes. > > Do not answer such broken queries. ... the query isn't broken. > By the way, it's still not clear to me if this thread is about improving > the DNS protocol in an objective sense, or punishing ISC for more or less > deliberately misinterpreting an RFC. the authors of the rfc in question have told me that DO means dnssec would not cause the initiator to dump core, not that dnssec records are desired. by that interpretation, bind9's current behaviour is not unreasonable, and it really does fall to the target to decide that the initiator might not be going to dump core, but that with the buffer size being less than 1220, it is not reasonable to assume that dnssec metadata will all fit, and so the fact that it would not make the initiator dump core becomes irrelevant. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 12:41:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBD2B3A6DB0; Tue, 16 Jun 2009 12:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 1DQELoXyTv2B; Tue, 16 Jun 2009 12:41:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DCA163A6B92; Tue, 16 Jun 2009 12:41:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGeUC-00091U-JH for namedroppers-data0@psg.com; Tue, 16 Jun 2009 19:38: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.69 (FreeBSD)) (envelope-from ) id 1MGeU1-00090E-Bo for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 19:38:18 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 080FBA5D4A for ; Tue, 16 Jun 2009 19:38:13 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses In-Reply-To: Your message of "Tue, 16 Jun 2009 19:14:03 +0100." <87F59E476ECB43B2B2E981D255B1E7F4@localhost> References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <2952105F69714941AA49EE6CA6EC1F02@localhost> <57532.1245162091@nsa.vix.com> <87F59E476ECB43B2B2E981D255B1E7F4@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 16 Jun 2009 19:38:12 +0000 Message-ID: <84558.1245181092@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: "George Barwood" > Date: Tue, 16 Jun 2009 19:14:03 +0100 > > >> EDNS is a layering violation in any case, ... > > > > please explain further? > > Ok, from RFC 2671 ... > We are programming a distributed database, and suddenly we are faced with > network/transport layer complications. if that's what you're calling a layering violation, then i refer you to RFC 1035 4.2.1, which is RFC 2671's spiritual father. if either of those is a layering violation, than both are. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 12:45:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA083A6B78; Tue, 16 Jun 2009 12:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 m8kJ6rpuBcBr; Tue, 16 Jun 2009 12:45:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 132083A690C; Tue, 16 Jun 2009 12:45:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGeXw-0009lh-SM for namedroppers-data0@psg.com; Tue, 16 Jun 2009 19:42:16 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGeXm-0009kf-0w for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 19:42:11 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id B9285A5D6E; Tue, 16 Jun 2009 19:42:05 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Florian Weimer cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses In-Reply-To: Your message of "Tue, 16 Jun 2009 20:24:03 +0200." <87ab48ghq4.fsf@mid.deneb.enyo.de> References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> <87ab48ghq4.fsf@mid.deneb.enyo.de> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 16 Jun 2009 19:42:05 +0000 Message-ID: <84829.1245181325@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Florian Weimer > > * Paul Vixie: > > agreed. all forms of multipacket require that state be maintained, > > and as a matter of architectural principle, multipacket state should > > be in the network stack and not in the application. (thus my recent > > interest in SCTP.) > > I think this is simply wrong, especially if you strive for resilience > against protocol-specific denial-of-service attacks. If you hide > state in the stack, you lose control over it, and you end up with > resource exhaustion attacks. as i explained elsewhere on this thread, keeping it in the stack gives me a lot more options on how i handle ddos. > I think this is the essence of your dislike towards TCP ... no. syn flood protection works. i worry about TCP because of the speed of light and the distance between nodes and the number of round trips and the total time that state has to be maintained on both sides and because of the way RFC 1035 specifie sthat connection management be done in the application. > ... Unfortunately, SCTP is just more of the same. sctp has only one of the weaknesses i know of in tcp/53. i'll say more in an actual proposal. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From omabid@amainsure.com Tue Jun 16 13:54:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542953A6824 for ; Tue, 16 Jun 2009 13:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.467 X-Spam-Level: X-Spam-Status: No, score=-13.467 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HELO_EQ_TW=1.335, HELO_MISMATCH_TW=0.994, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 vCph5wuwXT9z for ; Tue, 16 Jun 2009 13:54:17 -0700 (PDT) Received: from 3-3edu.com.tw (unknown [88.250.96.186]) by core3.amsl.com (Postfix) with SMTP id 1210C3A6DB2 for ; Tue, 16 Jun 2009 13:54:15 -0700 (PDT) From: "Erin Corbett"@core3.amsl.com, dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: Delivery Status Notification 6188747669 MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20090616205416.1210C3A6DB2@core3.amsl.com> Date: Tue, 16 Jun 2009 13:54:15 -0700 (PDT) This Week

Click here to view this message as a web page.

 

Click here if this picture is blocked

Home  |  Contact Us  |  Privacy Policy  |  Terms of Use | Unsubscribe |
From owner-namedroppers@ops.ietf.org Tue Jun 16 14:16:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF7A3A6D71; Tue, 16 Jun 2009 14:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGfmXETWvgEH; Tue, 16 Jun 2009 14:16:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6D6E93A6BF0; Tue, 16 Jun 2009 14:16:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGfx4-000NCs-NJ for namedroppers-data0@psg.com; Tue, 16 Jun 2009 21:12:18 +0000 Received: from [65.201.175.9] (helo=cliffie.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGfwp-000NBV-0w for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 21:12:12 +0000 Received: from monsoon.verisignlabs.com (scooter.bo.labs.vrsn.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id 11999136710 for ; Tue, 16 Jun 2009 17:12:02 -0400 (EDT) Received: from dul1mcmlarson-l1.vcorp.ad.vrsn.com (dul1mcmlarson-l1.vcorp.ad.vrsn.com [10.51.30.1]) by monsoon.verisignlabs.com (Postfix) with ESMTP id 184BE2422F0 for ; Tue, 16 Jun 2009 17:12:01 -0400 (EDT) Date: Tue, 16 Jun 2009 17:12:01 -0400 From: Matt Larson To: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses Message-ID: <20090616211201.GD9023@dul1mcmlarson-l1.vcorp.ad.vrsn.com> References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> <80022C3C-A52E-40C9-AA86-68B8E010FD67@icsi.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80022C3C-A52E-40C9-AA86-68B8E010FD67@icsi.berkeley.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, 16 Jun 2009, Nicholas Weaver wrote: > [Discussion of lack of large response size support deleted.] > > For the purposes of DNS, you NEED a valid story that takes into account > this issue, unless you view not working for a significant percentage of > the Internet not a problem. Of all the TLDs signed to date, I would bet that .org is the most popular, where popular is narrowly defined here as having the most iterative resolvers query its name servers. Now that .org is signed, its responses have grown dramatically larger. For example, a query for www..org with +DO yields a 642-byte referral (up from 149 bytes without DO). Likewise, a query for www.nxdomain2.org with +DO generates 1003 bytes in response vs. 109 bytes without DO. The large response size situation with .gov is even worse, considering that zone is using two 2048-bit RSA keys and NSEC3: a +DO NXDOMAIN from .gov almost always tops 1500 bytes. It has been several weeks since .org was signed (and even longer for .gov) and the Internet has not melted. That doesn't mean there aren't pockets with issues, but we have not seen widespread problems resulting from these significantly-larger responses. I therefore maintain that if there were big problems, we would have heard about them by now. This makes me feel better about the root, too: every day that goes by with more TLDs signed and no significant problems makes me that less worried about significant damage when the root is signed. Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 16:28:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACEEC3A6C77; Tue, 16 Jun 2009 16:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 DHG8nWjpTbuj; Tue, 16 Jun 2009 16:28:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D96AE3A6929; Tue, 16 Jun 2009 16:28:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGhzn-000ED2-Lm for namedroppers-data0@psg.com; Tue, 16 Jun 2009 23:23:15 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGhza-000ECL-3I for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 23:23:08 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id C9F59E606E; Tue, 16 Jun 2009 23:22:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5GNMjm3026824; Wed, 17 Jun 2009 09:22:46 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906162322.n5GNMjm3026824@drugs.dv.isc.org> To: "George Barwood" Cc: "Michael Graff" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] EDNS Page Option to handle large responses In-reply-to: Your message of "Tue, 16 Jun 2009 18:26:52 +0100." <02A2F6D0BF4D4DF9A277E1B9604F869D@localhost Date: Wed, 17 Jun 2009 09:22:45 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <02A2F6D0BF4D4DF9A277E1B9604F869D@localhost>, "George Barwood" write s: > > ----- Original Message ----- > From: "Michael Graff" > To: "George Barwood" > Cc: "Mark Andrews" ; > Sent: Tuesday, June 16, 2009 4:10 PM > Subject: Re: [dnsext] EDNS Page Option to handle large responses > > > > George Barwood wrote: > > > >> All Zone administrators still need to be aware that oversize responses > >> are vulnerable to Dos attack ( by fragment and then the TCP fallback ). > > > > How are servers today not vulnerable to a DDoS over TCP? That is, what > > does a large response size actually change for this risk? > > The vulnerability of TCP has not changed, what has changed is the risk of needing to use it. > Ordinary DNS (excluding zone transfers) never needs to fall back to TCP in normal use. There have always been responses that have needed TCP. TCP is a normal part of the DNS and you have to go to extraordinary lengths to stop fallback to TCP occuring. The roots have had to fallback to TCP return referrals over plain DNS on occasions. What we are arguing over is the amount of TCP fallback. When it will occur and how often. If you are sitting behind a firewall that only allow 512 byte packets though and have not configured the nameserver to send 512 byte packets the fallback path is extreemly slow and no one who has a choice will want to continue to operate in that state. Go configure your firewall to only allow through 512 byte UDP/DNS packets and see for yourself. Mark > George > > > - --Michael -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 17:02:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55D53A6C6B; Tue, 16 Jun 2009 17:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 Q8IQVJ7gnhh5; Tue, 16 Jun 2009 17:02:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B42C3A6849; Tue, 16 Jun 2009 17:02:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGiWw-000Ijl-0j for namedroppers-data0@psg.com; Tue, 16 Jun 2009 23:57:30 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGiWi-000Iif-DL for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 23:57:22 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 891BBE606E; Tue, 16 Jun 2009 23:57:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5GNvC8E027535; Wed, 17 Jun 2009 09:57:13 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906162357.n5GNvC8E027535@drugs.dv.isc.org> To: "George Barwood" Cc: "Paul Vixie" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] EDNS Page Option to handle large responses In-reply-to: Your message of "Tue, 16 Jun 2009 19:14:03 +0100." <87F59E476ECB43B2B2E981D255B1E7F4@localhost> Date: Wed, 17 Jun 2009 09:57:12 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <87F59E476ECB43B2B2E981D255B1E7F4@localhost>, "George Barwood" write s: > > ----- Original Message ----- > From: "Paul Vixie" > To: > Sent: Tuesday, June 16, 2009 3:21 PM > Subject: Re: [dnsext] EDNS Page Option to handle large responses > > > >> From: "George Barwood" > >> Date: Tue, 16 Jun 2009 06:11:02 +0100 > >> ... > >> EDNS is a layering violation in any case, ... > > > > please explain further? > > Ok, from RFC 2671 > << > 4.5. The sender's UDP payload size (which OPT stores in the RR CLASS > field) is the number of octets of the largest UDP payload that can > be reassembled and delivered in the sender's network stack. Note > that path MTU, with or without fragmentation, may be smaller than > this. > > 4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP > reassembly buffer. Choosing 1280 on an Ethernet connected > requestor would be reasonable. The consequence of choosing too > large a value may be an ICMP message from an intermediate > gateway, or even a silent drop of the response message. You ususally get a ICMP from a intermediate when you set, or the OS sets for you, DF. I know of no nameserver that sets DF on its UDP traffic. We and I presume others try to ensure that it is turned off if the OS defaults to turning it on. The only OS were we don't have that control and need it is Solaris and IPv4 UDP traffic. There may be some router out there which can't support link layer MTU sized packets but they are extremely rare beasts. I know of no router that can't fragment a packet that they can fully receive. You loose if you choose a size that you can't reassemble. Most boxes can re-assemble the packets we are talking about and if you can't (think simple UDP stack in a embedded box) we shouldn't be preventing DNSSEC being used by preventing fallback to EDNS@512. Such boxes should be rare and the impact minimal. > 4.5.2. Both requestors and responders are advised to take account of the > path's discovered MTU (if already known) when considering message > sizes.>> > We are programming a distributed database, and suddenly we are > faced with network/transport layer complications. We have always looked at the underlying layers. This is not new. > Of course in DNS, because it uses UDP, there is considerable > mixing of the various layers. The DNS uses UDP when UDP's characteristics best fit the query profile. It uses TCP when the answer falls out of what UDP can reasonably handle. > But I don't want to get into theoretical arguments about > software/network design. > > We all know that for historical reasons DNS is a bit of a mess. > > What's needed is to understand what exists, how it is insecure, > and how it may practically be made secure and reliable. > > George > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 16 23:17:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5839F3A6DDF; Tue, 16 Jun 2009 23:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=-0.230, 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 fsEV1WEzgbNO; Tue, 16 Jun 2009 23:17:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 42DEB3A67F3; Tue, 16 Jun 2009 23:17:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGoOQ-000JBg-5h for namedroppers-data0@psg.com; Wed, 17 Jun 2009 06:13:06 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGoOD-000JAp-QC for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 06:12:59 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id BB00EE602F; Wed, 17 Jun 2009 06:12:52 +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 n5H6CnM6041238; Wed, 17 Jun 2009 16:12:50 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906170612.n5H6CnM6041238@drugs.dv.isc.org> To: "George Barwood" Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] EDNS Page Option to handle large responses In-reply-to: Your message of "Wed, 17 Jun 2009 06:06:52 +0100." Date: Wed, 17 Jun 2009 16:12:49 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , "George Barwood" writes: > > ----- Original Message ----- > From: "Mark Andrews" > To: "George Barwood" > Cc: "Michael Graff" ; > Sent: Wednesday, June 17, 2009 12:22 AM > Subject: Re: [dnsext] EDNS Page Option to handle large responses > > > > > > In message <02A2F6D0BF4D4DF9A277E1B9604F869D@localhost>, "George Barwood" write > > s: > >> > >> ----- Original Message ----- > >> From: "Michael Graff" > >> To: "George Barwood" > >> Cc: "Mark Andrews" ; > >> Sent: Tuesday, June 16, 2009 4:10 PM > >> Subject: Re: [dnsext] EDNS Page Option to handle large responses > >> > >> > >> > George Barwood wrote: > >> > > >> >> All Zone administrators still need to be aware that oversize responses > >> >> are vulnerable to Dos attack ( by fragment and then the TCP fallback ). > >> > > >> > How are servers today not vulnerable to a DDoS over TCP? That is, what > >> > does a large response size actually change for this risk? > >> > >> The vulnerability of TCP has not changed, what has changed is the risk of needing to use it. > >> Ordinary DNS (excluding zone transfers) never needs to fall back to TCP in normal use. > > > > There have always been responses that have needed TCP. TCP is a > > normal part of the DNS and you have to go to extraordinary lengths > > to stop fallback to TCP occuring. > > Err.. no you don't. You just don't enable EDNS, and have a 512 byte response buffer. > I have operated a resolver in this way that doesn't fall back to TCP, and have not > found something that does not resolve in many months of use. The priming query > and some referrals may have truncated additional sections, but that doesn't matter. Well you are lucky then or you use a recursive nameserver which violates the DNS standards by chopping up the answer section. EDNS, by itself, actually reduces the probability that you will have to fallback to TCP, it doesn't prevent it. DNSSEC increases the probability that you will fallback to TCP over EDNS alone. Plain DNS and DNSSEC with a 4069 byte EDNS clean path should have similar levels of TCP fallback. You will get more TCP fallback with DNSSEC and EDNS@1200 and more fallback still with EDNS@512. > > The roots have had to fallback to TCP return referrals over plain > > DNS on occasions. > > > > What we are arguing over is the amount of TCP fallback. > > Right, which is why I said > > "Ordinary DNS (excluding zone transfers) never needs to fall back to TCP in normal use." Ordinary DNS responses do fallback to TCP. You will find that your stub resolvers and you recursive resolver will do this automatically. Anyone who says differently really does not know what happens in the real world. This is the response to a ordinary query. Note EDNS was not used and it fell back to using TCP. ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.3.6-P1 <<>> dnskey se ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58614 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;se. IN DNSKEY ;; ANSWER SECTION: se. 3590 IN DNSKEY 257 3 5 AwEAAdKc1sGsbv5jjeJ141IxNSTdR+nbtFn+JKQpvFZETaY5iMutoyWH a+jCp0TBBAzB2trGHzdi7E55FFzbeG0r+G6SJbJ4DXYSpiiELPiu0i+j Pp3C3kNwiqpPpQHWaYDS9MTQMu/QZHR/sFPbUnsK30fuQbKKkKgnADms 0aXalYUuCgDyVMjdxRLz5yzLoaSO9m5ii5cI0dQNCjexvj9M4ec6woi6 +N8v1pOmQAQ9at5Fd8A6tAxZI8tdlEUnXYgNwb8eVZEWsgXtBhoyAru7 Tzw+F6ToYq6hmKhfsT+fIhFXsYso7L4nYUqTnM4VOZgNhcTv+qVQkHfO OeJKUkNB8Qc= se. 3590 IN DNSKEY 257 3 5 AwEAAeeGE5unuosN3c8tBcj1/q4TQEwzfNY0GK6kxMVZ1wcTkypSExLC BPMS0wWkrA1n7t5hcM86VD94L8oEd9jnHdjxreguOZYEBWkckajU0tBW wEPMoEwepknpB14la1wy3xR95PMt9zWceiqaYOLEujFAqe6F3tQ14lP6 FdFL9wyCflV06K1ww+gQxYRDo6h+Wejguvpeg33KRzFtlwvbF3AapH2G XCi4Ok2+PO2ckzfKoikIe9ZOXfrCbG9ml2iQrRNSM4q3zGhuly4NrF/t 9s9jakbWzd4PM1Q551XIEphRGyqcbA2JTU3/mcUVKfgrH7nxaPz5DoUB 7TKYyQgsTlc= se. 3590 IN DNSKEY 256 3 5 AwEAAa03g6eUym7QeFGEt0wx88nUcQmqnRRoUos95ICScmAgXimeiIhA pAOTWUrrybMyCOVgeFH8oovLoR8UR3YmScloECOU/EZQ4gLXGtL74HlO X8hw0HhlkOXNfSlxWZBTOOQn2Rf9yS3xWZ+ciLTqgj9SFxKr4n0AT6sy rWYFt4jJ se. 3590 IN DNSKEY 256 3 5 AwEAAcZN0OVaokJAtEiVGan/g3J3gOeYx7BCLTX1RuaWPHmPKROR7nfU a2Hc7Glpdtofk/uk5Aeiq9BKAAavke7Abr35cPXxOIdxdX65K4se1Iqe YpX+oW66xsn87WV89t1yPS67/nqFP5tcHnRnqA3lXGDlcfkjEsMQwY/M flQSVIkl se. 3590 IN DNSKEY 256 3 5 AwEAAc9B2MqxtXW/bQUYBV5zHf1z8e8MRSVWleDlQ3XZaOMlki4g4qdX hJ2rHN69ZzmvMj2DjTvLd8lMTN54NiHntofBIg0ZJ9pi0pcDemeeVQ7B h7T1OYzaM2rnId7xfSaoXBdX+6tMhkB/3CXM/cgqgar33emkhzdPUDdS 8FYNBGuL ;; Query time: 6 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jun 17 15:44:28 2009 ;; MSG SIZE rcvd: 1016 > > When it > > will occur and how often. If you are sitting behind a firewall > > that only allow 512 byte packets though and have not configured the > > nameserver to send 512 byte packets the fallback path is extreemly > > slow and no one who has a choice will want to continue to operate > > in that state. Go configure your firewall to only allow through > > 512 byte UDP/DNS packets and see for yourself. > > Mark > > > >> George > >> > >> > - --Michael > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 00:34:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8893A6816; Wed, 17 Jun 2009 00:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=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 BC+1dkGyfIHQ; Wed, 17 Jun 2009 00:34:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DE3813A6881; Wed, 17 Jun 2009 00:34:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGpbX-0003BO-35 for namedroppers-data0@psg.com; Wed, 17 Jun 2009 07:30:43 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGpbK-00036X-69 for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 07:30:36 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 3C55AE606E; Wed, 17 Jun 2009 07:30:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5H7UQ9X042005; Wed, 17 Jun 2009 17:30:26 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906170730.n5H7UQ9X042005@drugs.dv.isc.org> To: "George Barwood" Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] EDNS Page Option to handle large responses In-reply-to: Your message of "Wed, 17 Jun 2009 08:07:04 +0100." Date: Wed, 17 Jun 2009 17:30:26 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <41999.1245223797.1@drugs.dv.isc.org> In message , "George Barwood" write s: > By "Ordinary" I mean pre-DNSSEC. DNSSEC is the change. > > "The vulnerability of TCP has not changed, what has changed is the risk of needing to use it." > "Ordinary DNS (excluding zone transfers) never needs to fall back to TCP in normal use." Repeating something that is patently incorrect doesn't make it correct. The fact that you have not experienced TCP fallback occuring doesn't mean that it doesn't happen. I've seen lots of cases where adminstrators have thought they could get away with not offering DNS over TCP just to have it backfire. Microsoft did it at one point. See attached. Note there are no DNSSEC records involved and no EDNS either. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Content-ID: <41999.1245223797.2@drugs.dv.isc.org> To: msnhst@microsoft.com From: Mark.Andrews@nominum.com Subject: Broken firewall. Date: Tue, 01 May 2001 01:54:33 +1000 Sender: marka@nominum.com Can you please either make your answers fit in a UDP response or allow DNS/TCP through the firewall. At the moment your servers are telling the client to retry using TCP but you are not allowing the TCP connection to be established. Mark ; <<>> DiG 8.3 <<>> -x +ignore ptr @DNS4.CP.MSFT.NET ; (1 server found) ;; res options: init igntc recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43996 ;; flags: qr aa tc rd ra; QUERY: 1, ANSWER: 19, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; 126.177.68.207.in-addr.arpa, type = PTR, class = IN ;; ANSWER SECTION: 126.177.68.207.in-addr.arpa. 1H IN PTR c.compaq.net. 126.177.68.207.in-addr.arpa. 1H IN PTR c.fr.msn.ca. 126.177.68.207.in-addr.arpa. 1H IN PTR c.ktmsn.co.kr. 126.177.68.207.in-addr.arpa. 1H IN PTR c.latam.msn.com. 126.177.68.207.in-addr.arpa. 1H IN PTR c.msn.ca. 126.177.68.207.in-addr.arpa. 1H IN PTR c.msn.co.in. 126.177.68.207.in-addr.arpa. 1H IN PTR c.msn.co.jp. 126.177.68.207.in-addr.arpa. 1H IN PTR c.msn.co.kr. 126.177.68.207.in-addr.arpa. 1H IN PTR c.msn.co.nz. 126.177.68.207.in-addr.arpa. 1H IN PTR c.msn.com. 126.177.68.207.in-addr.arpa. 1H IN PTR c.msn.com.br. 126.177.68.207.in-addr.arpa. 1H IN PTR c.msn.com.hk. 126.177.68.207.in-addr.arpa. 1H IN PTR c.msn.com.mx. 126.177.68.207.in-addr.arpa. 1H IN PTR c.msn.com.my. 126.177.68.207.in-addr.arpa. 1H IN PTR c.msn.com.sg. 126.177.68.207.in-addr.arpa. 1H IN PTR c.msn.com.tw. 126.177.68.207.in-addr.arpa. 1H IN PTR c.msnbc.com. 126.177.68.207.in-addr.arpa. 1H IN PTR c.msretech.com. 126.177.68.207.in-addr.arpa. 1H IN PTR c.t1msn.com.mx. ;; Total query time: 313 msec ;; FROM: drugs.dv.isc.org to SERVER: DNS4.CP.MSFT.NET 207.46.138.11 ;; WHEN: Tue May 1 01:49:35 2001 ;; MSG SIZE sent: 45 rcvd: 504 drugs# tcpdump -n -p -s 1500 host DNS4.CP.MSFT.NET and port 53 tcpdump: listening on ep0 01:45:41.451316 130.155.191.236.2003 > 207.46.138.11.53: S 1043405316:1043405316(0) win 16384 (DF) 01:45:44.444614 130.155.191.236.2003 > 207.46.138.11.53: S 1043405316:1043405316(0) win 16384 (DF) 01:45:47.444653 130.155.191.236.2003 > 207.46.138.11.53: S 1043405316:1043405316(0) win 16384 (DF) 01:45:50.444697 130.155.191.236.2003 > 207.46.138.11.53: S 1043405316:1043405316(0) win 16384 (DF) 01:45:53.444747 130.155.191.236.2003 > 207.46.138.11.53: S 1043405316:1043405316(0) win 16384 (DF) 01:45:56.444795 130.155.191.236.2003 > 207.46.138.11.53: S 1043405316:1043405316(0) win 16384 (DF) 01:46:02.444884 130.155.191.236.2003 > 207.46.138.11.53: S 1043405316:1043405316(0) win 16384 (DF) -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com ------- =_aaaaaaaaaa0-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 03:39:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1556228C12C; Wed, 17 Jun 2009 03:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.528 X-Spam-Level: X-Spam-Status: No, score=-4.528 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAbOlo+WyNZC; Wed, 17 Jun 2009 03:39:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF7AB3A6975; Wed, 17 Jun 2009 03:39:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGsSP-0002iu-LM for namedroppers-data0@psg.com; Wed, 17 Jun 2009 10:33:29 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGsSD-0002hv-AK for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 10:33:23 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5HAVntj020765; Wed, 17 Jun 2009 10:31:49 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5HAVgb6020764; Wed, 17 Jun 2009 10:31:42 GMT Date: Wed, 17 Jun 2009 10:31:42 +0000 From: bmanning@vacation.karoshi.com To: Joe Abley Cc: Peter Koch , IETF DNSEXT WG Subject: Re: [dnsext] TCP pushback Message-ID: <20090617103142.GA20622@vacation.karoshi.com.> References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jun 16, 2009 at 08:11:50AM -0400, Joe Abley wrote: > > On 15-Jun-2009, at 17:11, Peter Koch wrote: > > >Seconded, either way the dnssec-bis-updates document is the right > >place > >to make this statement. It's hard to unilaterally standardize the > >reaction to a non-compliant query, anyway. > > It sounds like you are wondering about how a recommendation such as > the one Olafur proposed could be deployed. > > Are we mainly looking for a general solution to a potential general > threat (i.e. give implementers and hence authority-only server > operators an option if TCP query rates start to cause pain)? > > Or is this a more tactical measure designed principally for use by > operators of infrastructure zones (the root, TLDs, etc)? > I'm ok with the idea that a rise in TCP transactions will occur ... what I am not comfortable with is the idea that it might be the case that the percentage of TCP traffic shifts dramatically... and that this shift can be directly correlated to the existance of non-compliant edge software. i am sorely tempted to pull out my majik DPI filtering box and drop all DNS requests w/ DO=1 and buffsize lt. 1220 this option seems like the only sane response by authority servers who wish to deploy standards compliant software and zones. Is there a valid reason to not encourage this behaviour by all authoritative servers? granted, we don't have very many datapoints yet, but the ones we do have are captivating. perhaps Matt is right - there is nothing to worry about here - move along. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 06:05:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6626C3A6B6C; Wed, 17 Jun 2009 06:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 wC808wbeF-7D; Wed, 17 Jun 2009 06:05:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C5CAD3A6982; Wed, 17 Jun 2009 06:05:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGukZ-000NFg-Dw for namedroppers-data0@psg.com; Wed, 17 Jun 2009 13:00:23 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGukL-000NEP-5l for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 13:00:15 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 3A39FE606F; Wed, 17 Jun 2009 13:00:08 +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 n5HD05jq043482; Wed, 17 Jun 2009 23:00:05 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906171300.n5HD05jq043482@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com Cc: IETF DNSEXT WG From: Mark Andrews Subject: Re: [dnsext] TCP pushback In-reply-to: Your message of "Wed, 17 Jun 2009 10:31:42 GMT." <20090617103142.GA20622@vacation.karoshi.com.> Date: Wed, 17 Jun 2009 23:00:05 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <20090617103142.GA20622@vacation.karoshi.com.>, bmanning@vacation.ka roshi.com writes: > On Tue, Jun 16, 2009 at 08:11:50AM -0400, Joe Abley wrote: > > > > On 15-Jun-2009, at 17:11, Peter Koch wrote: > > > > >Seconded, either way the dnssec-bis-updates document is the right > > >place > > >to make this statement. It's hard to unilaterally standardize the > > >reaction to a non-compliant query, anyway. > > > > It sounds like you are wondering about how a recommendation such as > > the one Olafur proposed could be deployed. > > > > Are we mainly looking for a general solution to a potential general > > threat (i.e. give implementers and hence authority-only server > > operators an option if TCP query rates start to cause pain)? > > > > Or is this a more tactical measure designed principally for use by > > operators of infrastructure zones (the root, TLDs, etc)? > > I'm ok with the idea that a rise in TCP transactions > will occur ... what I am not comfortable with is the idea > that it might be the case that the percentage of TCP > traffic shifts dramatically... and that this shift can > be directly correlated to the existance of non-compliant > edge software. Well if you have figures Bill, publish them. All I've heard so far is conjecture. I've asked for figures from those that should be able supply them but there has been a deafening silence. All I've heard is "There may be a problem". No one as far as I can tell has looked at the existing traffic to workout what percentage of EDNS capable clients actually fall back to or have been configured to send EDNS queries at 512 vs those that ask with a bigger size. Is it 0.01%, 0.1%, 1%, 10%, 50% or 90%? > i am sorely tempted to pull out my majik DPI filtering > box and drop all DNS requests w/ DO=1 and buffsize lt. 1220 > > this option seems like the only sane response by authority > servers who wish to deploy standards compliant software and > zones. Is there a valid reason to not encourage this > behaviour by all authoritative servers? > > granted, we don't have very many datapoints yet, but the ones > we do have are captivating. perhaps Matt is right - there is > nothing to worry about here - move along. > > --bill > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 06:41:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4508B28C26A; Wed, 17 Jun 2009 06:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.103 X-Spam-Level: X-Spam-Status: No, score=-5.103 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 OYnKYFdaUj2V; Wed, 17 Jun 2009 06:41:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 56F3E28C281; Wed, 17 Jun 2009 06:41:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGvJk-0002dO-7I for namedroppers-data0@psg.com; Wed, 17 Jun 2009 13:36:44 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGvJY-0002Xe-VS for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 13:36:38 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5HDaRDS029127; Wed, 17 Jun 2009 06:36:27 -0700 (PDT) Cc: Nicholas Weaver , bmanning@vacation.karoshi.com, IETF DNSEXT WG Message-Id: From: Nicholas Weaver To: Mark Andrews In-Reply-To: <200906171300.n5HD05jq043482@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] TCP pushback Date: Wed, 17 Jun 2009 06:36:27 -0700 References: <200906171300.n5HD05jq043482@drugs.dv.isc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 17, 2009, at 6:00 AM, Mark Andrews wrote: > > Well if you have figures Bill, publish them. All I've heard > so far is conjecture. I've asked for figures from those > that should be able supply them but there has been a deafening > silence. > > All I've heard is "There may be a problem". No one as far > as I can tell has looked at the existing traffic to workout > what percentage of EDNS capable clients actually fall back > to or have been configured to send EDNS queries at 512 vs > those that ask with a bigger size. > > Is it 0.01%, 0.1%, 1%, 10%, 50% or 90%? Here's the problem: There are two possible reasons why an EDNS buffer of >1500B might be a problem. The first is a middlebox which can't handle UDP fragmentation (including one parsing DNS). The second is a middlebox which pareses DNS and can't handle EDNS or DNS packets >512B. Correct me if I'm wrong, but Bind's fallback assumes the latter, correct? If 4096b fails, it drops to 512B. What market share is Bind of those resolvers supporting DNSSEC and EDNS? Are there any resolvers which assume that it could be case one, and first drop the buffer size to ~1400B and only if that fails, to 512B? Absent the resolver actively probing to determine cause, a resolver which doesn't assume case 2 is going to be problematic, so I would actually hope that if there is a single-step downgrade of EDNS buffer size, it drops to 512B. I apologize for not thinking of the difference myself, the next version of netalyzr will have two separate tests, one for 1400B and one for 1800B, to distinguish the two cases. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 07:38:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C887E28C271; Wed, 17 Jun 2009 07:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1CEJ33kzzxl; Wed, 17 Jun 2009 07:38:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D735428C26A; Wed, 17 Jun 2009 07:38:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGwDk-000CLM-B8 for namedroppers-data0@psg.com; Wed, 17 Jun 2009 14:34:36 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGwDZ-000CH6-5h for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 14:34:30 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5HEYOpY037886 for ; Wed, 17 Jun 2009 10:34:24 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n5HEYO9Y037885 for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 10:34:24 -0400 (EDT) (envelope-from namedroppers) Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGaJ0-000Nwo-82 for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 15:10:40 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 6B56A327A5D; Tue, 16 Jun 2009 15:10:33 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id C98A8327A59; Tue, 16 Jun 2009 15:10:32 +0000 (UTC) Message-ID: <4A37B5E8.2020309@isc.org> Date: Tue, 16 Jun 2009 10:10:32 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: George Barwood CC: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses References: <200906160646.n5G6k4DQ015500@drugs.dv.isc.org> <57895D72CEEF4452836C35361419B311@localhost> In-Reply-To: <57895D72CEEF4452836C35361419B311@localhost> X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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. ] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 George Barwood wrote: > All Zone administrators still need to be aware that oversize responses > are vulnerable to Dos attack ( by fragment and then the TCP fallback ). How are servers today not vulnerable to a DDoS over TCP? That is, what does a large response size actually change for this risk? - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko3tegACgkQ+NNi0s9NRJ1gegCfdCgCrV++fQUK3vv5ZS0NZYlS +kQAoKWeWNBCZ7m5rWQbjarvISlrSMGp =E+An -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 07:38:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC93228C26A; Wed, 17 Jun 2009 07:38:11 -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 8xGUuw26rwJr; Wed, 17 Jun 2009 07:38:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC8793A685E; Wed, 17 Jun 2009 07:38:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGwCQ-000C49-6y for namedroppers-data0@psg.com; Wed, 17 Jun 2009 14:33:14 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGwCF-000C2X-5X for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 14:33:08 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5HEX1D4037852 for ; Wed, 17 Jun 2009 10:33:01 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n5HEX1WM037851 for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 10:33:01 -0400 (EDT) (envelope-from namedroppers) Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGaMP-000OQs-4F for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 15:14:13 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 7B939327A5D; Tue, 16 Jun 2009 15:14:04 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id D3640327A3B; Tue, 16 Jun 2009 15:14:03 +0000 (UTC) Message-ID: <4A37B6BB.9060309@isc.org> Date: Tue, 16 Jun 2009 10:14:03 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: George Barwood CC: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <2952105F69714941AA49EE6CA6EC1F02@localhost> <30237F48-D593-4061-AC04-C59ED336897B@cisco.com> <534C2D6D7C184AFE9BE886E9FDAE33DD@localhost> In-Reply-To: <534C2D6D7C184AFE9BE886E9FDAE33DD@localhost> X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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. ] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 George Barwood wrote: > Mark Andrews has argued that if client and server software is modified > to avoid fragmentation, and administrators take care to stay within certain > limits, the existing specification allows secure operation. While that may > be true, IMO security should not depend on how well educated administrators > are, or the software being written in a very particular way. Actually, well educated administrators is one major security step forward, and software being written in a very particular way is another. :) Those are pretty much required for any security plan to work meaningfully. After all, if your admin write down passwords on post-it notes and stick them to windows, what's the point? - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko3troACgkQ+NNi0s9NRJ09agCcDvr76JSIaAeFi/yJ1QcO2EwL ++QAoI8QIJ64rXI1yoLvErXqP80EFGMe =nDpH -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 07:39:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491483A68DF; Wed, 17 Jun 2009 07:39:08 -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 O2GzK7kStmpa; Wed, 17 Jun 2009 07:39:08 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 850DE3A6B07; Wed, 17 Jun 2009 07:39:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGwC2-000C0P-AH for namedroppers-data0@psg.com; Wed, 17 Jun 2009 14:32:50 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGwBp-000By3-1r for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 14:32:44 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5HEWY2t037832 for ; Wed, 17 Jun 2009 10:32:34 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n5HEWY2Y037831 for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 10:32:34 -0400 (EDT) (envelope-from namedroppers) Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGaJ0-000Nwo-82 for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 15:10:40 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 6B56A327A5D; Tue, 16 Jun 2009 15:10:33 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id C98A8327A59; Tue, 16 Jun 2009 15:10:32 +0000 (UTC) Message-ID: <4A37B5E8.2020309@isc.org> Date: Tue, 16 Jun 2009 10:10:32 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: George Barwood CC: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses References: <200906160646.n5G6k4DQ015500@drugs.dv.isc.org> <57895D72CEEF4452836C35361419B311@localhost> In-Reply-To: <57895D72CEEF4452836C35361419B311@localhost> X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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. ] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 George Barwood wrote: > All Zone administrators still need to be aware that oversize responses > are vulnerable to Dos attack ( by fragment and then the TCP fallback ). How are servers today not vulnerable to a DDoS over TCP? That is, what does a large response size actually change for this risk? - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko3tegACgkQ+NNi0s9NRJ1gegCfdCgCrV++fQUK3vv5ZS0NZYlS +kQAoKWeWNBCZ7m5rWQbjarvISlrSMGp =E+An -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 07:39:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C8983A68F1; Wed, 17 Jun 2009 07:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSGHEBumJA5f; Wed, 17 Jun 2009 07:39:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 206F53A685E; Wed, 17 Jun 2009 07:38:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGwCp-000CAo-84 for namedroppers-data0@psg.com; Wed, 17 Jun 2009 14:33:39 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGwCd-000C79-L2 for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 14:33:33 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5HEXQuS037868 for ; Wed, 17 Jun 2009 10:33:26 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n5HEXQwG037867 for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 10:33:26 -0400 (EDT) (envelope-from namedroppers) Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGbnI-000A2f-C8 for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 16:46:02 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id A0241327A77; Tue, 16 Jun 2009 16:45:55 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id BE6E7327A59; Tue, 16 Jun 2009 16:45:54 +0000 (UTC) Message-ID: <4A37CC42.6060901@isc.org> Date: Tue, 16 Jun 2009 11:45:54 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nicholas Weaver CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> <80022C3C-A52E-40C9-AA86-68B8E010FD67@icsi.berkeley.edu> <4A37C388.2080702@isc.org> <05AA9768-3D35-4223-81BF-08D63A9AE4B4@ICSI.Berkeley.EDU> In-Reply-To: <05AA9768-3D35-4223-81BF-08D63A9AE4B4@ICSI.Berkeley.EDU> X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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. ] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicholas Weaver wrote: > > On Jun 16, 2009, at 9:08 AM, Michael Graff wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Nicholas Weaver wrote: >> >>> We don't have final numbers (heck, we're still collecting data, let >>> alone analyzing it), but the number of resolvers which can't handle an >>> 1800B DNS response even though they advertise EDNS support is shockingly >>> large, as is the number of end hosts which can't directly request an >>> 1800B DNS response. >> >> Careful there. What specifically cannot handle it? The resolver >> itself? Or some device between it and the authority? > > > The test in question: .. > It does not validate EDNS requested size, (but that is captured in > another test), so it may exceed the advertised EDNS capacity of the > server for this particular test. So if someone advertises a 1000 byte packet size you still blast them with 1800, and are surprised they cannot handle it? I was more worried about your comments about the "resolvers cannot handle" which I found to be inaccurate. Your test as stated means you are intentionally flooding them with more data and ignoring the EDNS advertised size, unless I misread what you said. Also, saying that the "resolver cannot handle" implies the resolver code is broken, when I suspect it is often times a firewall external to the resolving software. That is, "a resolver does not receive fragmented packets" is perhaps accurate, but "a resolver cannot handle" is probably not. I'm not picking on you, just wanting to make clear where the problem is, and if your tools can do that awesome. I like what you've done so far, and am glad that my home connection as rated as close to perfect as I can get it! - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko3zEIACgkQ+NNi0s9NRJ1ihQCfQpBOk8G/0kLsenhSRMDlAd1Z FM0AoIVjYgkCpXBYQCPjZPYHOb1I0+Xp =k9XY -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 07:39:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A85523A6ADE; Wed, 17 Jun 2009 07:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=3.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EQoHfcw9iSz; Wed, 17 Jun 2009 07:39:45 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id E4EBC3A6A7A; Wed, 17 Jun 2009 07:39:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGwCd-000C7F-IZ for namedroppers-data0@psg.com; Wed, 17 Jun 2009 14:33:27 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGwCS-000C5x-Im for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 14:33:22 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5HEXFvs037858 for ; Wed, 17 Jun 2009 10:33:15 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n5HEXFOR037857 for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 10:33:15 -0400 (EDT) (envelope-from namedroppers) Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGbDG-0005Lp-Ji for namedroppers@ops.ietf.org; Tue, 16 Jun 2009 16:08:50 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id CA2BB327A5D; Tue, 16 Jun 2009 16:08:41 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id 0A42C327A3B; Tue, 16 Jun 2009 16:08:40 +0000 (UTC) Message-ID: <4A37C388.2080702@isc.org> Date: Tue, 16 Jun 2009 11:08:40 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nicholas Weaver CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> <80022C3C-A52E-40C9-AA86-68B8E010FD67@icsi.berkeley.edu> In-Reply-To: <80022C3C-A52E-40C9-AA86-68B8E010FD67@icsi.berkeley.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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. ] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicholas Weaver wrote: > We don't have final numbers (heck, we're still collecting data, let > alone analyzing it), but the number of resolvers which can't handle an > 1800B DNS response even though they advertise EDNS support is shockingly > large, as is the number of end hosts which can't directly request an > 1800B DNS response. Careful there. What specifically cannot handle it? The resolver itself? Or some device between it and the authority? - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko3w4gACgkQ+NNi0s9NRJ1QGgCgkEKvSQY9M1kxizAtz3ieCrUq NcoAnRVDdZHYwQ/fwoOMVfuXUd2AttGn =A4xa -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 08:24:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD13F28C2B0; Wed, 17 Jun 2009 08:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.527 X-Spam-Level: X-Spam-Status: No, score=-4.527 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGiLmfEnTyZv; Wed, 17 Jun 2009 08:24:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9139D28C2AF; Wed, 17 Jun 2009 08:24:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGwvU-000JmE-Fv for namedroppers-data0@psg.com; Wed, 17 Jun 2009 15:19:48 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGwvG-000Jik-7e for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 15:19:42 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5HFHOtj022971; Wed, 17 Jun 2009 15:17:24 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5HFHJIj022969; Wed, 17 Jun 2009 15:17:19 GMT Date: Wed, 17 Jun 2009 15:17:19 +0000 From: bmanning@vacation.karoshi.com To: Michael Graff Cc: Nicholas Weaver , namedroppers@ops.ietf.org, bmanning@vacation.karoshi.com Subject: Re: [dnsext] EDNS Page Option to handle large responses Message-ID: <20090617151719.GA22787@vacation.karoshi.com.> References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> <80022C3C-A52E-40C9-AA86-68B8E010FD67@icsi.berkeley.edu> <4A37C388.2080702@isc.org> <05AA9768-3D35-4223-81BF-08D63A9AE4B4@ICSI.Berkeley.EDU> <4A37CC42.6060901@isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A37CC42.6060901@isc.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jun 16, 2009 at 11:45:54AM -0500, Michael Graff wrote: > [ Moderators note: Post was moderated, either because it was posted by > a non-subscriber, or because it was over 20K. > With the massive amount of spam, it is easy to miss and therefore > delete relevant posts by non-subscribers. > Please fix your subscription addresses. ] > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Nicholas Weaver wrote: > > > > On Jun 16, 2009, at 9:08 AM, Michael Graff wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Nicholas Weaver wrote: > >> > >>> We don't have final numbers (heck, we're still collecting data, let > >>> alone analyzing it), but the number of resolvers which can't handle an > >>> 1800B DNS response even though they advertise EDNS support is shockingly > >>> large, as is the number of end hosts which can't directly request an > >>> 1800B DNS response. > >> > >> Careful there. What specifically cannot handle it? The resolver > >> itself? Or some device between it and the authority? > > > > > > The test in question: > .. > > It does not validate EDNS requested size, (but that is captured in > > another test), so it may exceed the advertised EDNS capacity of the > > server for this particular test. > > So if someone advertises a 1000 byte packet size you still blast them > with 1800, and are surprised they cannot handle it? > > I was more worried about your comments about the "resolvers cannot > handle" which I found to be inaccurate. Your test as stated means you > are intentionally flooding them with more data and ignoring the EDNS > advertised size, unless I misread what you said. > > Also, saying that the "resolver cannot handle" implies the resolver code > is broken, when I suspect it is often times a firewall external to the > resolving software. That is, "a resolver does not receive fragmented > packets" is perhaps accurate, but "a resolver cannot handle" is probably > not. so - a question there abt the resolver behaviour. once it enters the fall back mode, does it do incremental fall back e.g. 4096, 2048, 1400, 512 or does it make one huge leap, e.g. 4096 - 512 directly? and under what condititions does it leave fall-back and retry with "normal" buffsize? --bill > > I'm not picking on you, just wanting to make clear where the problem is, > and if your tools can do that awesome. I like what you've done so far, > and am glad that my home connection as rated as close to perfect as I > can get it! > > - --Michael > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAko3zEIACgkQ+NNi0s9NRJ1ihQCfQpBOk8G/0kLsenhSRMDlAd1Z > FM0AoIVjYgkCpXBYQCPjZPYHOb1I0+Xp > =k9XY > -----END PGP SIGNATURE----- > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 08:50:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882493A6C42; Wed, 17 Jun 2009 08:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.48 X-Spam-Level: X-Spam-Status: No, score=-7.48 tagged_above=-999 required=5 tests=[AWL=-1.352, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 0CBohG0K5kq5; Wed, 17 Jun 2009 08:50:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 99DE33A6AE5; Wed, 17 Jun 2009 08:50:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGxIl-000N7e-0e for namedroppers-data0@psg.com; Wed, 17 Jun 2009 15:43:51 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGxIU-000N3j-5i for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 15:43:44 +0000 X-Files: PGP.sig : 186 X-IronPort-AV: E=Sophos;i="4.42,236,1243814400"; d="sig'?scan'208";a="43037989" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Jun 2009 15:43:32 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5HFhWlN019770; Wed, 17 Jun 2009 17:43:32 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5HFhWB2002927; Wed, 17 Jun 2009 15:43:32 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jun 2009 17:43:32 +0200 Received: from 79.138.202.192.bredband.tre.se ([10.61.110.118]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jun 2009 17:43:31 +0200 Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: <681AD016-AB27-4493-BA56-1664B750822B@cisco.com> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Michael Graff In-Reply-To: <4A37CC42.6060901@isc.org> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-9-658235160" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS Page Option to handle large responses Date: Wed, 17 Jun 2009 17:43:27 +0200 References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> <80022C3C-A52E-40C9-AA86-68B8E010FD67@icsi.berkeley.edu> <4A37C388.2080702@isc.org> <05AA9768-3D35-4223-81BF-08D63A9AE4B4@ICSI.Berkeley.EDU> <4A37CC42.6060901@isc.org> X-Pgp-Agent: GPGMail d55 (v55, Leopard) X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 17 Jun 2009 15:43:31.0423 (UTC) FILETIME=[5DAD1EF0:01C9EF62] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1743; t=1245253412; x=1246117412; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20

|Subject:=20Re=3A=20[dnsext]=20EDNS=20Page=20Option=20to=20 handle=20large=20responses |Sender:=20; bh=lEINoW4Xc2TKlcpZagDZBSJ/tqeBzC1ww6Y0bT0wVFo=; b=GqC1f6IoONSIeLAOU6NfNaX58TnVU6UmcPimpvddQioyDk5bToA+gPL3uo VYuZMjuQ6g+kfhaYzMDWBvOgOWTMI1YUHfR/risaVbH5xN4Cf61queDDYBnp LLlP0XaDDA; Authentication-Results: ams-dkim-2; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-9-658235160 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 16 jun 2009, at 18.45, Michael Graff wrote: > So if someone advertises a 1000 byte packet size you still blast them > with 1800, and are surprised they cannot handle it? I want us to be careful with words here. EDNS0 is not advertising packet size, but IP buffer reassembly size. I still do not understand what people are worried about, but can guess a few alternatives: 1. ICMPv6 packet-too-big is not generated, or filtered or something so that the sending host will not fragment the packets correctly 2. People do not think fragmented packets are handled correctly so UDP payload size have to be less than MTU size all the time If you are worried about (1), then set MTU to 1280 in your DNS server, and it will fragment the packets. If you are worried about (2), then announce 1280 in EDNS0 size. What are we talking about? I hope we are not designing to as broken networks as (2), but I can understand (1) because many tunnel endpoints might not (today) do the right thing with ICMPv6, or ICMP is not handled correctly in firewalls etc. Patrik --Apple-Mail-9-658235160 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) iD4DBQFKOQ8fvHlR2X0luNwRAngWAJ9Hp6P/nVTWuiMmg+8A7MppHSqBRACWMbx9 5FnC5QUKAniQcEBwlFtSmw== =tLaQ -----END PGP SIGNATURE----- --Apple-Mail-9-658235160-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 09:40:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3323A6E98; Wed, 17 Jun 2009 09:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 C7FmTRduYZsN; Wed, 17 Jun 2009 09:40:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 12E1E3A6C38; Wed, 17 Jun 2009 09:40:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGy76-0004lQ-Fx for namedroppers-data0@psg.com; Wed, 17 Jun 2009 16:35:52 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MGy6u-0004kK-AY for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 16:35:45 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id B6634A5F0E; Wed, 17 Jun 2009 16:35:39 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Nicholas Weaver cc: Mark Andrews , bmanning@vacation.karoshi.com, IETF DNSEXT WG Subject: Re: [dnsext] TCP pushback In-Reply-To: Your message of "Wed, 17 Jun 2009 06:36:27 MST." References: <200906171300.n5HD05jq043482@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 17 Jun 2009 16:35:39 +0000 Message-ID: <43724.1245256539@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Nicholas Weaver > Date: Wed, 17 Jun 2009 06:36:27 -0700 > ... > There are two possible reasons why an EDNS buffer of >1500B might be a > problem. > > The first is a middlebox which can't handle UDP fragmentation (including > one parsing DNS). > > The second is a middlebox which pareses DNS and can't handle EDNS or DNS > packets >512B. for completeness, many middleboxes object to QR=0 && ARCOUNT!=0 regardless of packet size. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From machadoo@ahrana.gov.br Wed Jun 17 11:12:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68723A6EA5 for ; Wed, 17 Jun 2009 11:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.06 X-Spam-Level: X-Spam-Status: No, score=-14.06 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_IMAGE_RATIO_04=0.172, 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_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_GREY=0.25, 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 fmSoLmA1ufLk for ; Wed, 17 Jun 2009 11:12:15 -0700 (PDT) Received: from advanced-connect.net (unknown [190.199.115.167]) by core3.amsl.com (Postfix) with SMTP id 935F53A681C for ; Wed, 17 Jun 2009 11:12:12 -0700 (PDT) To: dnsext-archive@ietf.org Subject: Two Stays = One Free Weekend Night. No Limits. Register Now. From: dnsext-archive@ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090617181213.935F53A681C@core3.amsl.com> Date: Wed, 17 Jun 2009 11:12:12 -0700 (PDT)
Not seeing images? Click here.
Adventures Await
Find what most inspires you in the world's most beautiful locations. Whether it's exploring chic boutiques and high-end department stores in exciting cities or uncovering new perspectives in relaxing resort locales, when you stay with Le Méridien, the best the world has to offer will be at your fingertips.

Make time for a chic adventure!!! late checkout.
book now >

Rates do not include taxes, gratuities or any additional charges that may apply.
For complete terms and conditions, please click here: Terms & Conditions.

To ensure you receive your Starwood Hotels & Resorts emails, please add
StarwoodHotelsResorts@starwood.delivery.net to your address book. Find out how.

Starwood Hotels and Resorts Le Meridien Four Points by Sheraton Westin The Luxury Collection aloft Sheraton element by Westin St. Regis W Hotels Starwood Preferred Guest
thelobby.com. An inside look at travel, culture and leisure. moments by Starwood Preferred Guest. Bid Starpoints® for Extraordinary Experiences.

© 2009 Star Hotels & Pfaiz Company, Inc.
1111 Westchester Ave, White Plains, NY 14913

You are subscribed as dnsext-archive@ietf.org

Tell us if you would like your email sent to a different address.

See our Privacy Statement or call 1-004-993-9020 from the U.S. & Canada or +353-21-8801663 in all
other countries to learn more about our data collection and usage practices.

Review the Starwood Preferred Guest program Terms and Conditions.

If you would prefer to opt out of future promotional emails from Starwood Hotels & Resorts, click here. Please do not reply directly to this system-generated email. It may take up to 10 business days to make the requested change. During that time, there is a slight chance that you may receive a promotional email from us.




From doggedlyy@qd-delixi.com Wed Jun 17 13:09:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E22153A6A6B; Wed, 17 Jun 2009 13:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_START_LOSE=1.493, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SUBJECT_DIET=1.466, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHKwb8GwC86D; Wed, 17 Jun 2009 13:09:06 -0700 (PDT) Received: from 189.27.96.245.dynamic.adsl.gvt.net.br (201.22.179.246.dynamic.adsl.gvt.net.br [201.22.179.246]) by core3.amsl.com (Postfix) with ESMTP id 7DB8428C113; Wed, 17 Jun 2009 13:08:53 -0700 (PDT) Message-ID: <000d01c9ef87$71175df0$6400a8c0@doggedlyy> From: emu-request@ietf.org To: Subject: Lose weight Keep it off Acai Berry. Date: Wed, 17 Jun 2009 17:08:55 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9EF87.71175DF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9EF87.71175DF0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Enjoy your new body , Get Acai Now.=20 Acai Berry will help you change your life.   Get inside =A0 =A0 Thank You!=20 best regards Sven=20 Ham ------=_NextPart_000_0007_01C9EF87.71175DF0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Enjoy your new body , Get Acai Now.
Acai Berry will help you change your life.<= /DIV>
 
Get inside
=A0
=A0
Thank You!
best regards Sven=20 Ham
------=_NextPart_000_0007_01C9EF87.71175DF0-- From owner-namedroppers@ops.ietf.org Wed Jun 17 14:49:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5863A6843; Wed, 17 Jun 2009 14:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.416 X-Spam-Level: X-Spam-Status: No, score=-4.416 tagged_above=-999 required=5 tests=[AWL=0.021, 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 62Vg-cZ3mVrc; Wed, 17 Jun 2009 14:49:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 659783A683D; Wed, 17 Jun 2009 14:49:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH2sX-000NJB-D8 for namedroppers-data0@psg.com; Wed, 17 Jun 2009 21:41:09 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH2sM-000NI1-DC for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 21:41:03 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 2F822644BD0; Wed, 17 Jun 2009 14:40:57 -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 euMjssAHwDXX; Wed, 17 Jun 2009 14:40:55 -0700 (PDT) Received: from wlan39-215.mdr.icann.org (wlan39-215.mdr.icann.org [192.0.39.215]) by virtualized.org (Postfix) with ESMTP id C494F644BC1; Wed, 17 Jun 2009 14:40:55 -0700 (PDT) Cc: IETF DNSEXT WG Message-Id: <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> From: David Conrad To: Paul Vixie In-Reply-To: <84444.1245180816@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] New rules for DO bit Date: Wed, 17 Jun 2009 14:40:55 -0700 References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 16, 2009, at 12:33 PM, Paul Vixie wrote: > the query isn't broken. In the strictest sense of RFC 4035, I guess I'd reluctantly have to agree. Section 4.1 states: "4.1. EDNS Support A security-aware resolver MUST include an EDNS ([RFC2671]) OPT pseudo- RR with the DO ([RFC3225]) bit set when sending queries. A security-aware resolver MUST support a message size of at least 1220 octets, SHOULD support a message size of 4000 octets, and MUST use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR to advertise the message size that it is willing to accept. ..." One can read this as saying that while the security-aware resolver MUST support 1220 bytes, it doesn't have to advertise that fact. Since it MUST advertise a message size, it can, in fact, advertise anything it wants, including 512 bytes. Of course, the whole point of the 1220 byte minimum was to try to reduce the number of queries that result in responses with TC set, so advertising a buffer size that will increase the number of responses with TC set seems counter-intuitive to me. > the authors of the rfc in question have told me that DO means dnssec > would > not cause the initiator to dump core, not that dnssec records are > desired. To clarify, when I wrote 3225, I was aware of two name server implementations (one of which was relatively common) that had issues with the DNSSEC-related RRs so it was a factor. However, if you read 3225, you'll note the rationale section leads with concerns about fallback to TCP, not core dumping. That was intentional. As numerous people pointed out, if your resolver core dumps based on input it gets from the network, it deserves to die. In any event, preliminary results obtained while studying the impact of scaling up the root zone size (due to DNSSEC, IPv6, and new TLDs) on the "L" root server indicates the combination of DO=1 and a buffer size of 512 results in a small percentage increase in the number of TCP session initiations. While the increase is well within the capacity of "L" to withstand, I will admit some nervousness. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 15:39:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176853A6A14; Wed, 17 Jun 2009 15:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-0.135, 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 6wYxoT0B0ntY; Wed, 17 Jun 2009 15:39:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C8F8D3A6946; Wed, 17 Jun 2009 15:39:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH3jZ-0004fw-Nt for namedroppers-data0@psg.com; Wed, 17 Jun 2009 22:35:57 +0000 Received: from [209.86.89.69] (helo=elasmtp-mealy.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH3jK-0004dF-8u for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 22:35:51 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=F54YEzjmBN22Bfd8fBJUPTCKERVamoPnsUF48xL0F27u/wEdHHQ7HJk9uG1JVvsM; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.103.168] (helo=ix.netcom.com) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MH3jE-0005D8-Ub; Wed, 17 Jun 2009 18:35:37 -0400 Message-ID: <4A396FA3.E0145F92@ix.netcom.com> Date: Wed, 17 Jun 2009 15:35:16 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Joe Abley , Peter Koch , IETF DNSEXT WG Subject: Re: [dnsext] TCP pushback References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <20090617103142.GA20622@vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688fd696ea7925db8673eb742095ad45c91350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.103.168 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Bill and all, Non compliant edge software meaning what exactly? Definition? bmanning@vacation.karoshi.com wrote: > On Tue, Jun 16, 2009 at 08:11:50AM -0400, Joe Abley wrote: > > > > On 15-Jun-2009, at 17:11, Peter Koch wrote: > > > > >Seconded, either way the dnssec-bis-updates document is the right > > >place > > >to make this statement. It's hard to unilaterally standardize the > > >reaction to a non-compliant query, anyway. > > > > It sounds like you are wondering about how a recommendation such as > > the one Olafur proposed could be deployed. > > > > Are we mainly looking for a general solution to a potential general > > threat (i.e. give implementers and hence authority-only server > > operators an option if TCP query rates start to cause pain)? > > > > Or is this a more tactical measure designed principally for use by > > operators of infrastructure zones (the root, TLDs, etc)? > > > > I'm ok with the idea that a rise in TCP transactions > will occur ... what I am not comfortable with is the idea > that it might be the case that the percentage of TCP > traffic shifts dramatically... and that this shift can > be directly correlated to the existance of non-compliant > edge software. > > i am sorely tempted to pull out my majik DPI filtering > box and drop all DNS requests w/ DO=1 and buffsize lt. 1220 > > this option seems like the only sane response by authority > servers who wish to deploy standards compliant software and > zones. Is there a valid reason to not encourage this > behaviour by all authoritative servers? > > granted, we don't have very many datapoints yet, but the ones > we do have are captivating. perhaps Matt is right - there is > nothing to worry about here - move along. > > --bill > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 15:47:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22BA3A6C85; Wed, 17 Jun 2009 15:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.525 X-Spam-Level: X-Spam-Status: No, score=-4.525 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-fm97JItxiI; Wed, 17 Jun 2009 15:47:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A97F73A6BDF; Wed, 17 Jun 2009 15:47:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH3rL-0005vD-9t for namedroppers-data0@psg.com; Wed, 17 Jun 2009 22:43:59 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH3r0-0005qE-AN for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 22:43:53 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5HMfXtj026235; Wed, 17 Jun 2009 22:41:33 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5HMfXMa026234; Wed, 17 Jun 2009 22:41:33 GMT Date: Wed, 17 Jun 2009 22:41:33 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Cc: Paul Vixie , IETF DNSEXT WG Subject: Re: [dnsext] New rules for DO bit Message-ID: <20090617224133.GA25580@vacation.karoshi.com.> References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 17, 2009 at 02:40:55PM -0700, David Conrad wrote: > On Jun 16, 2009, at 12:33 PM, Paul Vixie wrote: > >the query isn't broken. > > In the strictest sense of RFC 4035, I guess I'd reluctantly have to > agree. Section 4.1 states: > > "4.1. EDNS Support > A security-aware resolver MUST include an EDNS ([RFC2671]) OPT pseudo- > RR with the DO ([RFC3225]) bit set when sending queries. > A security-aware resolver MUST support a message size of at least 1220 > octets, SHOULD support a message size of 4000 octets, and MUST use the > "sender's UDP payload size" field in the EDNS OPT pseudo-RR to > advertise the message size that it is willing to accept. ..." > > One can read this as saying that while the security-aware resolver > MUST support 1220 bytes, it doesn't have to advertise that fact. > Since it MUST advertise a message size, it can, in fact, advertise > anything it wants, including 512 bytes. and, turning the stick around... a server that sees a DO=1 and an advertized message size of less than the MUST of 1220 octets is perfectly capable of interpreting the situation (MUST/MUST) and seeing (MUST-ok/MUST-fail) as a failure or hostile event... and refuse service. one might argue that if buffsize is throttled to lt 1220 octets, that a security aware resolver should reluctently crawl back to a non-secure state and not set DO=1 - since the infrastructure can't support the increased demand. > > Of course, the whole point of the 1220 byte minimum was to try to > reduce the number of queries that result in responses with TC set, so > advertising a buffer size that will increase the number of responses > with TC set seems counter-intuitive to me. > > >the authors of the rfc in question have told me that DO means dnssec > >would > >not cause the initiator to dump core, not that dnssec records are > >desired. > > To clarify, when I wrote 3225, I was aware of two name server > implementations (one of which was relatively common) that had issues > with the DNSSEC-related RRs so it was a factor. However, if you read > 3225, you'll note the rationale section leads with concerns about > fallback to TCP, not core dumping. That was intentional. As numerous > people pointed out, if your resolver core dumps based on input it gets > from the network, it deserves to die. > > In any event, preliminary results obtained while studying the impact > of scaling up the root zone size (due to DNSSEC, IPv6, and new TLDs) > on the "L" root server indicates the combination of DO=1 and a buffer > size of 512 results in a small percentage increase in the number of > TCP session initiations. While the increase is well within the > capacity of "L" to withstand, I will admit some nervousness. > > Regards, > -drc > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 16:26:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301013A689D; Wed, 17 Jun 2009 16:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 tKe6tniQ6c+F; Wed, 17 Jun 2009 16:26:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 79B323A67BD; Wed, 17 Jun 2009 16:26:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH4SI-000BMa-Qb for namedroppers-data0@psg.com; Wed, 17 Jun 2009 23:22:10 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH4S7-000BLj-3G for namedroppers@ops.ietf.org; Wed, 17 Jun 2009 23:22:04 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 4CC29E602F; Wed, 17 Jun 2009 23:21:58 +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 n5HNLs8u053861; Thu, 18 Jun 2009 09:21:55 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906172321.n5HNLs8u053861@drugs.dv.isc.org> To: Nicholas Weaver Cc: Mark Andrews , bmanning@vacation.karoshi.com, IETF DNSEXT WG From: Mark Andrews Subject: Re: [dnsext] TCP pushback In-reply-to: Your message of "Wed, 17 Jun 2009 06:36:27 MST." Date: Thu, 18 Jun 2009 09:21:54 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Nicholas W eaver writes: > > On Jun 17, 2009, at 6:00 AM, Mark Andrews wrote: > > > > Well if you have figures Bill, publish them. All I've heard > > so far is conjecture. I've asked for figures from those > > that should be able supply them but there has been a deafening > > silence. > > > > All I've heard is "There may be a problem". No one as far > > as I can tell has looked at the existing traffic to workout > > what percentage of EDNS capable clients actually fall back > > to or have been configured to send EDNS queries at 512 vs > > those that ask with a bigger size. > > > > Is it 0.01%, 0.1%, 1%, 10%, 50% or 90%? > > Here's the problem: > > There are two possible reasons why an EDNS buffer of >1500B might be a > problem. > > The first is a middlebox which can't handle UDP fragmentation > (including one parsing DNS). > > The second is a middlebox which pareses DNS and can't handle EDNS or > DNS packets >512B. > > Correct me if I'm wrong, but Bind's fallback assumes the latter, > correct? If 4096b fails, it drops to 512B. What market share is Bind > of those resolvers supporting DNSSEC and EDNS? > > Are there any resolvers which assume that it could be case one, and > first drop the buffer size to ~1400B and only if that fails, to 512B? There is no real benefit in doing that. There are very few answers that actually result in fragmentation. Turn on a packet dump an watch. If the EDNS@4096 fails then EDNS@1200 will almost certainly also fail or result in TC being set especially if you don't add the NS RRset to the DNSKEY response. Recent versions of BIND set minimal-response for DNSKEY responses (DNSSKEY and RRSIG only only record). > Absent the resolver actively probing to determine cause, a resolver > which doesn't assume case 2 is going to be problematic, so I would > actually hope that if there is a single-step downgrade of EDNS buffer > size, it drops to 512B. > > > > I apologize for not thinking of the difference myself, the next > version of netalyzr will have two separate tests, one for 1400B and > one for 1800B, to distinguish the two cases. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 18:04:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20A6D3A69E3; Wed, 17 Jun 2009 18:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=-0.108, 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 vZwCQRboFIWV; Wed, 17 Jun 2009 18:04:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 56A7E28C0F4; Wed, 17 Jun 2009 18:03:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH5xs-000PA7-VN for namedroppers-data0@psg.com; Thu, 18 Jun 2009 00:58:52 +0000 Received: from [209.86.89.68] (helo=elasmtp-masked.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH5xf-000P9C-Pf for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 00:58:47 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=gspSVDk54o/EEgSOYdNiFl7p77PHjYzRdaUNwsVvAM/2gf5JMy636tSjS25y1Nhr; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.97.115] (helo=ix.netcom.com) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MH5xb-0008QE-6W; Wed, 17 Jun 2009 20:58:35 -0400 Message-ID: <4A399138.BE124CF2@ix.netcom.com> Date: Wed, 17 Jun 2009 17:58:33 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: George Barwood CC: Nicholas Weaver , Mark Andrews , bmanning@vacation.karoshi.com, IETF DNSEXT WG Subject: Re: [dnsext] TCP pushback References: <200906172321.n5HNLs8u053861@drugs.dv.isc.org> <6F67F25D205E46C8AE4CD531E62F52D1@localhost> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688d05aeb22cbe1dd379bb3208a85613d73350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.97.115 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: George and all, Nicely summed up. Yep, these are about it... George Barwood wrote: > So trying to summarize, seems to me there are 2 sensible strategies for resolvers: > > (1) Try EDNS@1400 , fall back to TCP on truncation. > > Advantage: stops IP fragment spoofing. > > (2) Try EDNS@4000, fall back to TCP on truncation. > > Advantage: fall back to TCP very unlikely. May still drop some glue ( se needs 4444 ). > > (1) Should just about work without TCP fallback, provided servers do not send NS rrset on > DNSKEY queries, and manage keys carefully. Fingers crossed. > > George > > [snip]¶‹§²æìr¸›zǧu©ž²Æ zÚ'jg®Šiz»+z«ž²Ú)²'­~ŠàÂ+a¶°¢·nžË›±Êâmè§jȧ‚W¥Šwš²Ø^™ë,j­{[¡Üš­Èb½èm¶Ÿÿ¢›"z×è®åŠËlþv¦yÚ覗«s/== Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 18:15:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8AD3A6EA7; Wed, 17 Jun 2009 18:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.418 X-Spam-Level: X-Spam-Status: No, score=-4.418 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Ve28zaSqUl0J; Wed, 17 Jun 2009 18:15:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AEBFF3A6DB3; Wed, 17 Jun 2009 18:15:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH6BM-00018A-Bn for namedroppers-data0@psg.com; Thu, 18 Jun 2009 01:12:48 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH6BA-000170-Ge for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 01:12:42 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 587B3645950; Wed, 17 Jun 2009 18:12:36 -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 g49DeS6uRB3V; Wed, 17 Jun 2009 18:12:35 -0700 (PDT) Received: from wlan39-215.mdr.icann.org (wlan39-215.mdr.icann.org [192.0.39.215]) by virtualized.org (Postfix) with ESMTP id C7A81645941; Wed, 17 Jun 2009 18:12:34 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: <912D35C2-6000-4835-9F29-C4AB8871F370@virtualized.org> From: David Conrad To: Matt Larson In-Reply-To: <20090616211201.GD9023@dul1mcmlarson-l1.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS Page Option to handle large responses Date: Wed, 17 Jun 2009 18:12:33 -0700 References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> <80022C3C-A52E-40C9-AA86-68B8E010FD67@icsi.berkeley.edu> <20090616211201.GD9023@dul1mcmlarson-l1.vcorp.ad.vrsn.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 16, 2009, at 2:12 PM, Matt Larson wrote: > I therefore maintain that if there were big problems, we would have > heard about them by now. We (or at least I) have been surprised twice now, the DO=1, buffer size=512 thing and the recent TCP session spike after the signing of .ORG. Both of those were not fatal, but I dislike surprises when it comes to critical Internet infrastructure. > This makes me feel better about the root, > too: every day that goes by with more TLDs signed and no significant > problems makes me that less worried about significant damage when the > root is signed. This topic is probably better addressed in DNSOP, but I will say that I continue to have concerns. The scope of the root zone is such that I am (perhaps overly) conservative when it comes to changes to that infrastructure. The fact that we have seen no significant damage as a result of signing some TLDs implying we will see no significant damage when we sign the root presupposes that the root is similar to those TLDs in all the ways that matter. I tend to agree that the lack of issues in signed TLDs is somewhat reassuring, but when you're dealing with infrastructure upon which national economies depend, I'd think we'd want to be sure rather than reassured. I think it would be ... sub-optimal to sign the root, find out some non-trivial proportion of the Internet has issues, and as a result have to unsign the root. (other bits about motherhood and apple pie deleted) Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 18:54:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618D83A6EDE; Wed, 17 Jun 2009 18:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 V34F1KyqkoC7; Wed, 17 Jun 2009 18:54:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 32E4D3A6A83; Wed, 17 Jun 2009 18:54:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH6jX-00064v-JA for namedroppers-data0@psg.com; Thu, 18 Jun 2009 01:48:07 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH6jH-00063h-9c for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 01:48:01 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 2E785E6071; Thu, 18 Jun 2009 01:47:50 +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 n5I1lk2n056608; Thu, 18 Jun 2009 11:47:47 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906180147.n5I1lk2n056608@drugs.dv.isc.org> To: David Conrad Cc: Matt Larson , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] EDNS Page Option to handle large responses In-reply-to: Your message of "Wed, 17 Jun 2009 18:12:33 MST." <912D35C2-6000-4835-9F29-C4AB8871F370@virtualized.org> Date: Thu, 18 Jun 2009 11:47:46 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <912D35C2-6000-4835-9F29-C4AB8871F370@virtualized.org>, David Conrad writes: > On Jun 16, 2009, at 2:12 PM, Matt Larson wrote: > > I therefore maintain that if there were big problems, we would have > > heard about them by now. > > We (or at least I) have been surprised twice now, the DO=1, buffer > size=512 thing and the recent TCP session spike after the signing > of .ORG. Both of those were not fatal, but I dislike surprises when > it comes to critical Internet infrastructure. A jump in TCP traffic should always have been expected. A look a the EDNS query sizes even if you ignore those < 1024 would have shown that there would be a jump in TCP traffic. http://www.nanog.org/meetings/nanog46/presentations/Wednesday/wessels_light_N46.pdf has relevant data to this debate. ORG's TCP traffic levels are much larger than they need to be as the had a ttl of zero on DNSKEY reponses when this data was sampled. > > This makes me feel better about the root, > > too: every day that goes by with more TLDs signed and no significant > > problems makes me that less worried about significant damage when the > > root is signed. > > This topic is probably better addressed in DNSOP, but I will say that > I continue to have concerns. The scope of the root zone is such that I > am (perhaps overly) conservative when it comes to changes to that > infrastructure. The fact that we have seen no significant damage as a > result of signing some TLDs implying we will see no significant damage > when we sign the root presupposes that the root is similar to those > TLDs in all the ways that matter. I tend to agree that the lack of > issues in signed TLDs is somewhat reassuring, but when you're dealing > with infrastructure upon which national economies depend, I'd think > we'd want to be sure rather than reassured. I think it would be ... > sub-optimal to sign the root, find out some non-trivial proportion of > the Internet has issues, and as a result have to unsign the root. > > (other bits about motherhood and apple pie deleted) > > Regards, > -drc > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 17 20:26:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097513A6A5A; Wed, 17 Jun 2009 20:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.42 X-Spam-Level: X-Spam-Status: No, score=-4.42 tagged_above=-999 required=5 tests=[AWL=0.017, 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 qNzZ1ml9BHlQ; Wed, 17 Jun 2009 20:26:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 299B93A6A3A; Wed, 17 Jun 2009 20:26:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH8A8-000IXL-Ch for namedroppers-data0@psg.com; Thu, 18 Jun 2009 03:19:40 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MH89v-000IRW-Qp for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 03:19:33 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 97175645FF2; Wed, 17 Jun 2009 20:19: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 w2rsE9YWmCzX; Wed, 17 Jun 2009 20:19:26 -0700 (PDT) Received: from wlan39-215.mdr.icann.org (wlan39-215.mdr.icann.org [192.0.39.215]) by virtualized.org (Postfix) with ESMTP id 01B2F645FDF; Wed, 17 Jun 2009 20:19:25 -0700 (PDT) Cc: IETF DNSEXT WG Message-Id: From: David Conrad To: Mark Andrews In-Reply-To: <200906180147.n5I1lk2n056608@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS Page Option to handle large responses Date: Wed, 17 Jun 2009 20:19:25 -0700 References: <200906180147.n5I1lk2n056608@drugs.dv.isc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark, On Jun 17, 2009, at 6:47 PM, Mark Andrews wrote: > A jump in TCP traffic should always have been expected. Yes, however a 600 fold increase is, at the very least, a bit surprising. As I said, the issue isn't that stuff broke, rather that the unexpected happened. The Internet isn't a toy anymore, it is critical infrastructure. In my view, when mucking about with critical infrastructure, unexpected things are very bad. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From flowers@rocksrus.com Wed Jun 17 21:45:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF093A6EF1; Wed, 17 Jun 2009 21:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.798 X-Spam-Level: X-Spam-Status: No, score=-17.798 tagged_above=-999 required=5 tests=[BAYES_80=2, DATE_IN_PAST_03_06=0.044, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, INVALID_DATE=1.245, IP_NOT_FRIENDLY=0.334, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, 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 8a9X+W1Bry08; Wed, 17 Jun 2009 21:45:47 -0700 (PDT) Received: from cpe-69-203-70-16.nyc.res.rr.com (cpe-69-203-70-16.nyc.res.rr.com [69.203.70.16]) by core3.amsl.com (Postfix) with SMTP id EDE133A6EFF; Wed, 17 Jun 2009 21:45:42 -0700 (PDT) Date: Thu, 18 Jun 2009 00:45:59 -0500; From: "Percy Pham" To: "Tom Marcum" Subject: ready for your cartier?; Message-ID: Content-Type: text/plain; Content-Transfer-Encoding: 7Bit; Amazing watches and such huge choice http://oaahikea.cn From owner-namedroppers@ops.ietf.org Thu Jun 18 00:29:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F38B23A6A71; Thu, 18 Jun 2009 00:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR3Dmk98jjhv; Thu, 18 Jun 2009 00:29:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BBE273A69CB; Thu, 18 Jun 2009 00:29:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHBxa-0000Ir-TH for namedroppers-data0@psg.com; Thu, 18 Jun 2009 07:22:58 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHBxF-0000Gz-CG for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 07:22:53 +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 1MHByw-0000Ly-MX; Thu, 18 Jun 2009 09:24:22 +0200 Received: from fweimer by bfk.de with local id 1MHBx4-0001Ph-Le; Thu, 18 Jun 2009 09:22:26 +0200 To: "George Barwood" Cc: "Nicholas Weaver" , "Mark Andrews" , , "IETF DNSEXT WG" Subject: Re: [dnsext] TCP pushback References: <200906172321.n5HNLs8u053861@drugs.dv.isc.org> <6F67F25D205E46C8AE4CD531E62F52D1@localhost> From: Florian Weimer Date: Thu, 18 Jun 2009 09:22:26 +0200 In-Reply-To: <6F67F25D205E46C8AE4CD531E62F52D1@localhost> (George Barwood's message of "Thu\, 18 Jun 2009 01\:19\:36 +0100") Message-ID: <824oueqa4t.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: * George Barwood: > (1) Try EDNS@1400 , fall back to TCP on truncation. > > Advantage: stops IP fragment spoofing. No, it doesn't. There's no minimum MTU for IPv4. --=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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 00:31:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 675C528C133; Thu, 18 Jun 2009 00:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.568 X-Spam-Level: X-Spam-Status: No, score=-4.568 tagged_above=-999 required=5 tests=[AWL=-1.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em+V7j-gLVaz; Thu, 18 Jun 2009 00:31:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA45228C141; Thu, 18 Jun 2009 00:31:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHC0O-0000jR-BP for namedroppers-data0@psg.com; Thu, 18 Jun 2009 07:25:52 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHC0C-0000iX-J6; Thu, 18 Jun 2009 07:25:46 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=GEbwymPvyGq9fSU63ym2LA5YqCK+dglafz1z/z/pWEnqrojJD6K7asbo EbGYd5zJzrCKS/VoTI+30d/MJFN6d2VkZ7CDctOj74c6b/NRUOLINNoeC /Y9HyZOrm8O4iXP; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1245309940; x=1276845940; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20New=20rules=20for=20DO=20bit|Date:=20Thu,=2018=20Ju n=202009=2008:25:32=20+0100|Message-ID:=20|To:=20David=20Conrad=20|Cc:=20IET F=20DNSEXT=20WG=20,=0D=0A=09ow ner-namedroppers@ops.ietf.org,=0D=0A=09Paul=20Vixie=20|MIME-Version:=201.0|In-Reply-To:=20<6F2A3EEF -9004-4810-A7DE-3568136D4F25@virtualized.org>|References: =20<200906141835.n5EIZ0dD020925@stora.ogud.com>=20<87iqiy 5ywv.fsf@mid.deneb.enyo.de>=20<200906150119.n5F1JE6b09521 6@stora.ogud.com>=20<4A3619FA.5090404@nlnetlabs.nl>=20<20 090615211157.GD9397@x27.adm.denic.de>=20<3B043A63-0A2D-47 3D-B153-D78B2F1ACE68@hopcount.ca>=20<200906161440.n5GEegf x023035@stora.ogud.com>=20=20<87ocsohxz6.fsf@mid.deneb.en yo.de>=20=20<84444.1245180816@nsa.vix.com>=20<6F2A3EEF-90 04-4810-A7DE-3568136D4F25@virtualized.org>; bh=BNDtALm7d4tVmOxLoPn7c4tJN0i8Z5SPCQH6ozBL85A=; b=kTb+6gA0p6LaSimy6Q7Z2WUNClyeP0CJggUwMyIqi6SWKP/+mDUenQ2K ymi8qdLoVG6bMzmELoRneWXBrQ4hAVVb6XkkAOgL00bRxyXSMWPtBqMa0 O+Bhbnp+9Q2kD8J; X-IronPort-AV: E=Sophos;i="4.42,242,1243810800"; d="scan'208";a="14921234" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 18 Jun 2009 08:25:34 +0100 In-Reply-To: <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> To: David Conrad Cc: IETF DNSEXT WG , owner-namedroppers@ops.ietf.org, Paul Vixie Subject: Re: [dnsext] New rules for DO bit MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 18 Jun 2009 08:25:32 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 18/06/2009 08:25:37 AM, Serialize complete at 18/06/2009 08:25:37 AM Content-Type: multipart/alternative; boundary="=_alternative 0028CA3E802575D9_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 0028CA3E802575D9_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable > In the strictest sense of RFC 4035, I guess I'd reluctantly have to=20 > agree. Section 4.1 states: >=20 > "4.1. EDNS Support > A security-aware resolver MUST include an EDNS ([RFC2671]) OPT pseudo-=20 > RR with the DO ([RFC3225]) bit set when sending queries. > A security-aware resolver MUST support a message size of at least 1220=20 > octets, SHOULD support a message size of 4000 octets, and MUST use the=20 > "sender's UDP payload size" field in the EDNS OPT pseudo-RR to=20 > advertise the message size that it is willing to accept. ..." >=20 > One can read this as saying that while the security-aware resolver=20 > MUST support 1220 bytes, it doesn't have to advertise that fact.=20 > Since it MUST advertise a message size, it can, in fact, advertise=20 > anything it wants, including 512 bytes. It seems very clear to me: 1. MUST include EDNS0, with DO=3D1 2. MUST support >=3D 1220 (SHOULD support 4000) 3. MUST say so I'm struggling to parse the =A74.1 text in any way that would support an=20 alternate conclusion. The only way to misinterpret this is if the phrases "MUST support a=20 message size of ..." and "the message size that it is willing to accept"=20 are taken to mean different things. That's quite a twisting of the=20 language, and clearly not what the authors intended. Ray --=_alternative 0028CA3E802575D9_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
> In the strictest sense of RFC 4035, I guess I'd reluctantly have to  
> agree.  Section 4.1 states:
>
> "4.1. EDNS Support
> A security-aware resolver MUST include an EDNS ([RFC2671]) OPT pseudo-
> RR with the DO ([RFC3225]) bit set when sending queries.
> A security-aware resolver MUST support a message size of at least 1220  
> octets, SHOULD support a message size of 4000 octets, and MUST use the  
> "sender's UDP payload size" field in the EDNS OPT pseudo-RR to  
> advertise the message size that it is willing to accept. ..."
>
> One can read this as saying that while the security-aware resolver  
> MUST support 1220 bytes, it doesn't have to advertise that fact.  
> Since it MUST advertise a message size, it can, in fact, advertise  
> anything it wants, including 512 bytes.
It seems very clear to me:

1.  MUST include EDNS0, with DO=3D1
2.  MUST support >=3D 1220 (SHOULD support 4= 000)
3.  MUST say so

I'm struggling to parse the =A74.1 text in any way t= hat would support an alternate conclusion.

The only way to misinterpret this is if the phrases "MUST support a message size of ..." and "the message size that it is willing to accept" are taken to mean different things.  That's quite a twisting of the language, and clearly not what the authors intended.

Ray

--=_alternative 0028CA3E802575D9_=-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 00:36:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56E9A3A6BD1; Thu, 18 Jun 2009 00:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.477 X-Spam-Level: X-Spam-Status: No, score=-4.477 tagged_above=-999 required=5 tests=[AWL=-1.179, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVtHvYflZ1fS; Thu, 18 Jun 2009 00:36:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA9833A6A38; Thu, 18 Jun 2009 00:36:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHC8A-0001sq-5p for namedroppers-data0@psg.com; Thu, 18 Jun 2009 07:33:54 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHC7x-0001rp-O4 for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 07:33:48 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=4yTB9hZpCm41HSyHyrGu9KdwI9V3DW1zS49q2bRoMJ4J7l4vLy1843NC KffdZDfd+w9pcYrvfp3AWOOPFyr33LzGSiMsinxNC8h5UizRJZOqMbPWK a2MdsUElb0tVOa5; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1245310421; x=1276846421; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20TCP=20pushback|Date:=20Thu,=2018=20Jun=202009=2008: 33:34=20+0100|Message-ID:=20|To:=20Mark =20Andrews=20|Cc:=20IETF=20DNSEXT=20WG=20< namedroppers@ops.ietf.org>|MIME-Version:=201.0 |In-Reply-To:=20<200906172321.n5HNLs8u053861@drugs.dv.isc .org>|References:=20Your=20message=20of=20"Wed,=2017=20Ju n=202009=2006:36:27=20MST."=20=20=20=20=20=20=20=20=20=20 =20=20=20=20<200906172321.n5HNLs8u053861@drugs.dv.isc.org>; bh=wU3yNBnKzrH2eLay/LhoWI2sSJN+u6eqkZIRdTWyG5A=; b=F9qkKKnDhYh7nVxUfXqRh/zsqbokIMDSnVQHp4/stVtv959lh0WhxdDY D/LDzII+mBP9iGkHlNmQfBKkHmZjMLN3ZGvjAcVq76nIixcySQQqlKUcH rgVO7TXOSRHyF5p; X-IronPort-AV: E=Sophos;i="4.42,242,1243810800"; d="scan'208";a="14921384" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 18 Jun 2009 08:33:37 +0100 In-Reply-To: <200906172321.n5HNLs8u053861@drugs.dv.isc.org> References: Your message of "Wed, 17 Jun 2009 06:36:27 MST." <200906172321.n5HNLs8u053861@drugs.dv.isc.org> To: Mark Andrews Cc: IETF DNSEXT WG Subject: Re: [dnsext] TCP pushback MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 18 Jun 2009 08:33:34 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 18/06/2009 08:33:39 AM, Serialize complete at 18/06/2009 08:33:39 AM Content-Type: multipart/alternative; boundary="=_alternative 0029867F802575D9_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 0029867F802575D9_= Content-Type: text/plain; charset="US-ASCII" > > Are there any resolvers which assume that it could be case one, and > > first drop the buffer size to ~1400B and only if that fails, to 512B? > > There is no real benefit in doing that. There are very few > answers that actually result in fragmentation. Turn on a > packet dump an watch. If the EDNS@4096 fails then EDNS@1200 > will almost certainly also fail or result in TC being set > especially if you don't add the NS RRset to the DNSKEY > response. Recent versions of BIND set minimal-response for > DNSKEY responses (DNSSKEY and RRSIG only only record). I can't agree. There's very clearly a number of large zones already sending signed packets in the 512 - ~1400 range. It's simply not true to say that failure with EDNS@4096 makes failure with EDNS@1200 (or 1400) certain. I've seen plenty of middleboxes that'll fail with the former, but work quite happily with the latter. However I concede that my experience with this is with SOHO CPE (and therefore most likely affecting stub -> recursor). Ray --=_alternative 0029867F802575D9_= Content-Type: text/html; charset="US-ASCII"
> > Are there any resolvers which assume that it could be case one, and  
> > first drop the buffer size to ~1400B and only if that fails, to 512B?
>
>    There is no real benefit in doing that.  There are very few
>    answers that actually result in fragmentation.  Turn on a
>    packet dump an watch.  If the EDNS@4096 fails then EDNS@1200
>    will almost certainly also fail or result in TC being set
>    especially if you don't add the NS RRset to the DNSKEY
>    response.  Recent versions of BIND set minimal-response for
>    DNSKEY responses (DNSSKEY and RRSIG only only record).
I can't agree.

There's very clearly a number of large zones already sending signed packets in the 512 - ~1400 range.

It's simply not true to say that failure with EDNS@4096 makes failure with EDNS@1200 (or 1400) certain.  I've seen plenty of middleboxes that'll fail with the former, but work quite happily with the latter.

However I concede that my experience with this is with SOHO CPE (and therefore most likely affecting stub -> recursor).

Ray
--=_alternative 0029867F802575D9_=-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 04:04:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31DA3A698D; Thu, 18 Jun 2009 04:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D29DV3VTcRO; Thu, 18 Jun 2009 04:04:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A3C513A68A8; Thu, 18 Jun 2009 04:04:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHFK1-0005ES-S3 for namedroppers-data0@psg.com; Thu, 18 Jun 2009 10:58:21 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHFJq-0005DM-Qf for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 10:58:16 +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 1MHFLb-00012c-7N; Thu, 18 Jun 2009 12:59:59 +0200 Received: from fweimer by bfk.de with local id 1MHFJi-00066T-KE; Thu, 18 Jun 2009 12:58:02 +0200 To: David Conrad Cc: Matt Larson , namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses References: <56EBB938-6161-4979-877A-68A16FF6640C@cisco.com> <57324.1245161996@nsa.vix.com> <80022C3C-A52E-40C9-AA86-68B8E010FD67@icsi.berkeley.edu> <20090616211201.GD9023@dul1mcmlarson-l1.vcorp.ad.vrsn.com> <912D35C2-6000-4835-9F29-C4AB8871F370@virtualized.org> From: Florian Weimer Date: Thu, 18 Jun 2009 12:58:02 +0200 In-Reply-To: <912D35C2-6000-4835-9F29-C4AB8871F370@virtualized.org> (David Conrad's message of "Wed\, 17 Jun 2009 18\:12\:33 -0700") Message-ID: <82hbydn70l.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: * David Conrad: > This topic is probably better addressed in DNSOP, but I will say that > I continue to have concerns. The scope of the root zone is such that I > am (perhaps overly) conservative when it comes to changes to that > infrastructure. The signed root can reside on different IP addresses (and names), so that recursors can opt in gradually. The operator only has to install another hints file when the trust anchor is configured. This has been attempted before with DO, but perhaps this time, it's possible to do it right. No other zone has this option. It might not be politically feasible for the root, either---I don't know. --=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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From r7yacqaaaaaatxyvrw@boing.topica.com Thu Jun 18 05:10:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6836A28C31F; Thu, 18 Jun 2009 05:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.138 X-Spam-Level: X-Spam-Status: No, score=-16.138 tagged_above=-999 required=5 tests=[BAYES_60=1, DATE_IN_PAST_03_06=0.044, 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, INVALID_DATE=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Exz1Txf+HP8A; Thu, 18 Jun 2009 05:10:06 -0700 (PDT) Received: from 72-60-104-43.pools.spcsdns.net (72-60-104-43.pools.spcsdns.net [72.60.104.43]) by core3.amsl.com (Postfix) with SMTP id E924628C319; Thu, 18 Jun 2009 05:10:00 -0700 (PDT) Date: Thu, 18 Jun 2009 08:10:17 -0500; From: "Esperanza Tran" To: "Juliet Thacker" Subject: ready for your breitling?; Message-ID: Content-Type: text/plain; Content-Transfer-Encoding: 7Bit; Amazing watches and such huge choice http://odlncrea.cn From owner-namedroppers@ops.ietf.org Thu Jun 18 05:11:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A47B28C331; Thu, 18 Jun 2009 05:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=-0.232, 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 K-BFkYhjbD3U; Thu, 18 Jun 2009 05:11:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 82D0028C319; Thu, 18 Jun 2009 05:11:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHGNx-000GTh-If for namedroppers-data0@psg.com; Thu, 18 Jun 2009 12:06:29 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHGNl-000GOO-SX for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 12:06:23 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id C4DDDE602F; Thu, 18 Jun 2009 12:06:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5IC6C4b002440; Thu, 18 Jun 2009 22:06:13 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906181206.n5IC6C4b002440@drugs.dv.isc.org> To: Ray.Bellis@nominet.org.uk Cc: Mark Andrews , IETF DNSEXT WG From: Mark Andrews Subject: Re: [dnsext] TCP pushback In-reply-to: Your message of "Thu, 18 Jun 2009 08:33:34 +0100." Date: Thu, 18 Jun 2009 22:06:12 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Ray.Bellis@nominet.org.uk writes: > > > Are there any resolvers which assume that it could be case one, and > > > first drop the buffer size to ~1400B and only if that fails, to 512B? > > > > There is no real benefit in doing that. There are very few > > answers that actually result in fragmentation. Turn on a > > packet dump an watch. If the EDNS@4096 fails then EDNS@1200 > > will almost certainly also fail or result in TC being set > > especially if you don't add the NS RRset to the DNSKEY > > response. Recent versions of BIND set minimal-response for > > DNSKEY responses (DNSSKEY and RRSIG only only record). > > I can't agree. > > There's very clearly a number of large zones already sending signed > packets in the 512 - ~1400 range. Yes and they all get through without fragmentation with a EDNS UDP size of 4096. > It's simply not true to say that failure with EDNS@4096 makes failure with > EDNS@1200 (or 1400) certain. I've seen plenty of middleboxes that'll fail > with the former, but work quite happily with the latter. They work because they got a answer back not because of the size of the answer. For DNSKEY SE it make not a bit of difference if I set the bufsize to 512 or 1400. I still need to fallback to TCP to get the answer if I can't get fragmented packets through. ; <<>> DiG 9.6.1 <<>> dnskey se +dnssec +bufsize=1400 +ignore ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30556 ;; flags: qr tc rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;se. IN DNSKEY ;; ANSWER SECTION: se. 2354 IN DNSKEY 256 3 5 AwEAAc9B2MqxtXW/bQUYBV5zHf1z8e8MRSVWleDlQ3XZaOMlki4g4qdX hJ2rHN69ZzmvMj2DjTvLd8lMTN54NiHntofBIg0ZJ9pi0pcDemeeVQ7B h7T1OYzaM2rnId7xfSaoXBdX+6tMhkB/3CXM/cgqgar33emkhzdPUDdS 8FYNBGuL se. 2354 IN DNSKEY 257 3 5 AwEAAdKc1sGsbv5jjeJ141IxNSTdR+nbtFn+JKQpvFZETaY5iMutoyWH a+jCp0TBBAzB2trGHzdi7E55FFzbeG0r+G6SJbJ4DXYSpiiELPiu0i+j Pp3C3kNwiqpPpQHWaYDS9MTQMu/QZHR/sFPbUnsK30fuQbKKkKgnADms 0aXalYUuCgDyVMjdxRLz5yzLoaSO9m5ii5cI0dQNCjexvj9M4ec6woi6 +N8v1pOmQAQ9at5Fd8A6tAxZI8tdlEUnXYgNwb8eVZEWsgXtBhoyAru7 Tzw+F6ToYq6hmKhfsT+fIhFXsYso7L4nYUqTnM4VOZgNhcTv+qVQkHfO OeJKUkNB8Qc= se. 2354 IN DNSKEY 257 3 5 AwEAAeeGE5unuosN3c8tBcj1/q4TQEwzfNY0GK6kxMVZ1wcTkypSExLC BPMS0wWkrA1n7t5hcM86VD94L8oEd9jnHdjxreguOZYEBWkckajU0tBW wEPMoEwepknpB14la1wy3xR95PMt9zWceiqaYOLEujFAqe6F3tQ14lP6 FdFL9wyCflV06K1ww+gQxYRDo6h+Wejguvpeg33KRzFtlwvbF3AapH2G XCi4Ok2+PO2ckzfKoikIe9ZOXfrCbG9ml2iQrRNSM4q3zGhuly4NrF/t 9s9jakbWzd4PM1Q551XIEphRGyqcbA2JTU3/mcUVKfgrH7nxaPz5DoUB 7TKYyQgsTlc= se. 2354 IN DNSKEY 256 3 5 AwEAAa03g6eUym7QeFGEt0wx88nUcQmqnRRoUos95ICScmAgXimeiIhA pAOTWUrrybMyCOVgeFH8oovLoR8UR3YmScloECOU/EZQ4gLXGtL74HlO X8hw0HhlkOXNfSlxWZBTOOQn2Rf9yS3xWZ+ciLTqgj9SFxKr4n0AT6sy rWYFt4jJ se. 2354 IN DNSKEY 256 3 5 AwEAAcZN0OVaokJAtEiVGan/g3J3gOeYx7BCLTX1RuaWPHmPKROR7nfU a2Hc7Glpdtofk/uk5Aeiq9BKAAavke7Abr35cPXxOIdxdX65K4se1Iqe YpX+oW66xsn87WV89t1yPS67/nqFP5tcHnRnqA3lXGDlcfkjEsMQwY/M flQSVIkl ;; Query time: 9 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jun 18 21:41:04 2009 ;; MSG SIZE rcvd: 1027 Yes there will be examples where truncating the additional section will allow the answer to just squeeze in. I'm just saying there isn't much benefit in doing it. Mark > However I concede that my experience with this is with SOHO CPE (and > therefore most likely affecting stub -> recursor). > > Ray -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 05:15:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86CF83A6A70; Thu, 18 Jun 2009 05:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 I-lyGo4PG9U8; Thu, 18 Jun 2009 05:15:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A81293A685A; Thu, 18 Jun 2009 05:15:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHGTd-000HOI-7z for namedroppers-data0@psg.com; Thu, 18 Jun 2009 12:12:21 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHGTR-000HN1-4F for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 12:12:15 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 68790E606F; Thu, 18 Jun 2009 12:12:08 +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 n5ICC6lX002565; Thu, 18 Jun 2009 22:12:06 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906181212.n5ICC6lX002565@drugs.dv.isc.org> To: David Conrad Cc: Mark Andrews , IETF DNSEXT WG From: Mark Andrews Subject: Re: [dnsext] EDNS Page Option to handle large responses In-reply-to: Your message of "Wed, 17 Jun 2009 20:19:25 MST." Date: Thu, 18 Jun 2009 22:12:06 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , David Conrad writes: > Mark, > > On Jun 17, 2009, at 6:47 PM, Mark Andrews wrote: > > A jump in TCP traffic should always have been expected. > > Yes, however a 600 fold increase is, at the very least, a bit > surprising. With a little tuning it will come down a lot. > As I said, the issue isn't that stuff broke, rather that the > unexpected happened. The Internet isn't a toy anymore, it is critical > infrastructure. In my view, when mucking about with critical > infrastructure, unexpected things are very bad. > > Regards, > -drc -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 07:09:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9756928C11A; Thu, 18 Jun 2009 07:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKrk6AX+AO4D; Thu, 18 Jun 2009 07:09:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B47E3A68A4; Thu, 18 Jun 2009 07:09:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHIDF-000AV0-5W for namedroppers-data0@psg.com; Thu, 18 Jun 2009 14:03:33 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHID3-000AOQ-1s; Thu, 18 Jun 2009 14:03:26 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=pjwxsmrlDSIMk1Rg1PsWrqj7tJVeIcSGffPqUFCskm7tN0s1dXrMWdF+ S4XiJMxWa/X6WOvYlqIIX9r8t3apsRG2S9EX1VyeV9VCAUbic5LDOmy7P cQj4Zh5ae1IpdK9; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1245333801; x=1276869801; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20TCP=20pushback|Date:=20Thu,=2018=20Jun=202009=2015: 03:11=20+0100|Message-ID:=20|To:=20Mark =20Andrews=20|Cc:=20IETF=20DNSEXT=20WG=20< namedroppers@ops.ietf.org>,=0D=0A=09owner-namedroppers@op s.ietf.org|MIME-Version:=201.0|In-Reply-To:=20<2009061812 06.n5IC6C4b002440@drugs.dv.isc.org>|References:=20Your=20 message=20of=20"Thu,=2018=20Jun=202009=2008:33:34=20+0100 ."=20=20=20=20=20=20=20=20=20=20=20=20=20=20<200906181206.n5IC6C4b002440@drugs.dv.isc.org>; bh=g4WiDNrKGT9PtPGAQly8yUJ4k1I/q7YrrPV128h8aRE=; b=ZzyZo+AJsnv7cYSlebHiQWCFd8W+SaFcFtjdP8HpePIZDG5WMckEW1PY olb6M5RDuVS24FHsIFSt+zVnygryTwK5f37YpqeRP+qe9QEauGxnckfbK Q2kwx604RBxhFUn; X-IronPort-AV: E=Sophos;i="4.42,245,1243810800"; d="scan'208";a="10913869" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 18 Jun 2009 15:03:15 +0100 In-Reply-To: <200906181206.n5IC6C4b002440@drugs.dv.isc.org> References: Your message of "Thu, 18 Jun 2009 08:33:34 +0100." <200906181206.n5IC6C4b002440@drugs.dv.isc.org> To: Mark Andrews Cc: IETF DNSEXT WG , owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] TCP pushback MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 18 Jun 2009 15:03:11 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 18/06/2009 03:03:18 PM, Serialize complete at 18/06/2009 03:03:18 PM Content-Type: multipart/alternative; boundary="=_alternative 004D321F802575D9_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 004D321F802575D9_= Content-Type: text/plain; charset="US-ASCII" > > There's very clearly a number of large zones already sending signed > > packets in the 512 - ~1400 range. > > Yes and they all get through without fragmentation with a > EDNS UDP size of 4096. > > > It's simply not true to say that failure with EDNS@4096 makes failure with > > EDNS@1200 (or 1400) certain. I've seen plenty of middleboxes that'll fail > > with the former, but work quite happily with the latter. > > They work because they got a answer back not because of the > size of the answer. That's not the point If an initial >1472 byte response is completely lost because of fragmentation, then as I understand it the recursor will drop down to EDNS0/512 for subsequent queries (forever?) even if those queries might have succeeded at something between 512 and 1472 bytes. Currently those subsequent EDNS0/512 queries will result in TC=1, and retry over TCP. If the recursor had retried at EDNS0/1440 that wouldn't happen. Ray --=_alternative 004D321F802575D9_= Content-Type: text/html; charset="US-ASCII"
> > There's very clearly a number of large zones already sending signed
> > packets in the 512 - ~1400 range.
>
>    Yes and they all get through without fragmentation with a
>    EDNS UDP size of 4096.
>
> > It's simply not true to say that failure with EDNS@4096 makes failure with
> > EDNS@1200 (or 1400) certain.  I've seen plenty of middleboxes that'll fail
> > with the former, but work quite happily with the latter.
>
>    They work because they got a answer back not because of the
>    size of the answer.
That's not the point

If an initial >1472 byte response is completely lost because of fragmentation, then as I understand it the recursor will drop down to EDNS0/512 for subsequent queries (forever?) even if those queries might have succeeded at something between 512 and 1472 bytes.

Currently those subsequent EDNS0/512 queries will result in TC=1, and retry over TCP.  If the recursor had retried at EDNS0/1440 that wouldn't happen.

Ray



--=_alternative 004D321F802575D9_=-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 08:15:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96CC528C149; Thu, 18 Jun 2009 08:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.641 X-Spam-Level: X-Spam-Status: No, score=-0.641 tagged_above=-999 required=5 tests=[AWL=-1.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y18A4iqocVKl; Thu, 18 Jun 2009 08:15:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE49E28C157; Thu, 18 Jun 2009 08:15:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHJGV-000LGj-Un for namedroppers-data0@psg.com; Thu, 18 Jun 2009 15:10:59 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHJGA-000LF2-26 for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 15:10:46 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D79922FE9573 for ; Thu, 18 Jun 2009 15:10:36 +0000 (UTC) Date: Thu, 18 Jun 2009 11:10:35 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] New rules for DO bit Message-ID: <20090618151034.GG3542@shinkuro.com> References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [no hat] On Wed, Jun 17, 2009 at 02:40:55PM -0700, David Conrad wrote: > One can read this as saying that while the security-aware resolver MUST > support 1220 bytes, it doesn't have to advertise that fact. Since it > MUST advertise a message size, it can, in fact, advertise anything it > wants, including 512 bytes. If that is true, then what it really means is that the advertisement of the message size is unrelated to the actual message size the resolver actually can support. This strikes me as at the very least a strained reading of the RFCs. Perhaps the IETF needs a truth in advertising BCP, but I'd hate to think we had that many protocol lawyers around. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 08:24:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDEFB28C159; Thu, 18 Jun 2009 08:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMEWZFh1M8GD; Thu, 18 Jun 2009 08:24:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E63028C354; Thu, 18 Jun 2009 08:23:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHJO4-000MOi-Qx for namedroppers-data0@psg.com; Thu, 18 Jun 2009 15:18:48 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHJNr-000MNc-Uc for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 15:18:43 +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 1MHJPh-000711-79; Thu, 18 Jun 2009 17:20:29 +0200 Received: from fweimer by bfk.de with local id 1MHJNn-0004TE-Oz; Thu, 18 Jun 2009 17:18:31 +0200 To: David Conrad Cc: Mark Andrews , IETF DNSEXT WG Subject: Re: [dnsext] EDNS Page Option to handle large responses References: <200906180147.n5I1lk2n056608@drugs.dv.isc.org> From: Florian Weimer Date: Thu, 18 Jun 2009 17:18:31 +0200 In-Reply-To: (David Conrad's message of "Wed\, 17 Jun 2009 20\:19\:25 -0700") Message-ID: <82bpolin94.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: * David Conrad: > Mark, > > On Jun 17, 2009, at 6:47 PM, Mark Andrews wrote: >> A jump in TCP traffic should always have been expected. > > Yes, however a 600 fold increase is, at the very least, a bit > surprising. Uh-oh. Has it decreased after the DNSKEY TTL fix? --=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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From requitesyf@mobilepanda.com Thu Jun 18 08:25:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9459128C3C0; Thu, 18 Jun 2009 08:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.243 X-Spam-Level: X-Spam-Status: No, score=-7.243 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HELO_EQ_CHARTER=2.175, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_CHARTER=1.295, HOST_EQ_DHCP=1.295, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_ALC=1.405, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEb1SfOBAyWs; Thu, 18 Jun 2009 08:25:53 -0700 (PDT) Received: from 71-9-16-191.dhcp.reno.nv.charter.com (71-9-16-191.dhcp.reno.nv.charter.com [71.9.16.191]) by core3.amsl.com (Postfix) with ESMTP id 84CD628C3BF; Thu, 18 Jun 2009 08:25:53 -0700 (PDT) Message-ID: <000d01c9f029$13b2cc60$6400a8c0@requitesyf> From: ediint-archive@ietf.org To: Subject: Improve your digestive system with Acai Diet. Date: Thu, 18 Jun 2009 08:25:57 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F029.13B2CC60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F029.13B2CC60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lose Weight without the effort it takes=20 Start your new slimmer life with Acai Flush.   Press this button =A0 =A0 Thank You!=20 best regards Julia=20 Story ------=_NextPart_000_0007_01C9F029.13B2CC60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Lose Weight without the effort it takes
Start your new slimmer life with Acai Flush.
 
Press this button
=A0
=A0
Thank You!
best regards Julia=20 Story
------=_NextPart_000_0007_01C9F029.13B2CC60-- From owner-namedroppers@ops.ietf.org Thu Jun 18 08:51:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99C9F28C40B; Thu, 18 Jun 2009 08:51:27 -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 ZCa6iKtd95-r; Thu, 18 Jun 2009 08:51:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C8B328C0E3; Thu, 18 Jun 2009 08:51:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHJq7-0000tF-U3 for namedroppers-data0@psg.com; Thu, 18 Jun 2009 15:47:47 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHJpm-0000hY-IA for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 15:47:41 +0000 Received: from [10.31.201.162] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5IFl5NQ008750; Thu, 18 Jun 2009 11:47:05 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090618151034.GG3542@shinkuro.com> References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> <20090618151034.GG3542@shinkuro.com> Date: Thu, 18 Jun 2009 11:46:48 -0400 To: Andrew Sullivan From: Edward Lewis Subject: [dnsext] Does RFC 3226 require DO=1 ==> bufsize over 1219? was Re: [dnsext] New rules for DO bit Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 11:10 -0400 6/18/09, Andrew Sullivan wrote: >[no hat] > >On Wed, Jun 17, 2009 at 02:40:55PM -0700, David Conrad wrote: > >> One can read this as saying that while the security-aware resolver MUST >> support 1220 bytes, it doesn't have to advertise that fact. Since it >> MUST advertise a message size, it can, in fact, advertise anything it >> wants, including 512 bytes. > >If that is true, then what it really means is that the advertisement >of the message size is unrelated to the actual message size the >resolver actually can support. This strikes me as at the very least a >strained reading of the RFCs. Perhaps the IETF needs a truth in >advertising BCP, but I'd hate to think we had that many protocol >lawyers around. Given my experience with implementers who don't pay attention to the IETF's daily soap opera, I support David's statement above. When you read the RFCs "cold" and try to write code you find the RFCs are pretty poorly done and neglectfully maintained. (As one case in point, the RFC 1996 for NOTIFY, section 3.7 describes a feature that was silently deprecated 10 years ago - no one bothered to update the Proposed Standard document.) I've adopted an personal informal rule - if the RFC is more than 5 years old and BIND doesn't do it in the current version, consider the feature deprecated. So in this case, I'd expect to see DO=1 and bufsize under 1220. As far as RFC 3226, I recall a few years ago arguing that it didn't apply to IPv6 because it referenced A6 and not AAAA. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 09:02:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE5228C439; Thu, 18 Jun 2009 09:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.987 X-Spam-Level: X-Spam-Status: No, score=-0.987 tagged_above=-999 required=5 tests=[AWL=-0.492, 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 15C4oGFKGicX; Thu, 18 Jun 2009 09:02:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 593A728C422; Thu, 18 Jun 2009 09:02:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHK0d-0002Yx-U3 for namedroppers-data0@psg.com; Thu, 18 Jun 2009 15:58:39 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHK0T-0002WJ-0d for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 15:58:34 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5IFwKdZ008898; Thu, 18 Jun 2009 11:58:20 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200906181558.n5IFwKdZ008898@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 18 Jun 2009 11:58:11 -0400 To: Florian Weimer , David Conrad From: Olafur Gudmundsson Subject: Re: [dnsext] EDNS Page Option to handle large responses Cc: Mark Andrews , IETF DNSEXT WG In-Reply-To: <82bpolin94.fsf@mid.bfk.de> References: <200906180147.n5I1lk2n056608@drugs.dv.isc.org> <82bpolin94.fsf@mid.bfk.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 11:18 18/06/2009, Florian Weimer wrote: >* David Conrad: > > > Mark, > > > > On Jun 17, 2009, at 6:47 PM, Mark Andrews wrote: > >> A jump in TCP traffic should always have been expected. > > > > Yes, however a 600 fold increase is, at the very least, a bit > > surprising. > >Uh-oh. Has it decreased after the DNSKEY TTL fix? Will not help a lot, There are more negative answers than retries by validators to get DNSKEY RRset. Minimum negative answer is 999 bytes. (qname = 3.org) I.e. all the 512 and DO=1 queries for bad name will get truncated answer. The only TLD where min buff size of 12xx will not help is .gov their minimum negative answer is almost 1500 bytes. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 09:04:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D547728C43C; Thu, 18 Jun 2009 09:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[AWL=-0.053, 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 IvbNuQUCv2EF; Thu, 18 Jun 2009 09:04:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EBA2828C439; Thu, 18 Jun 2009 09:04:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHK3g-0002zT-2q for namedroppers-data0@psg.com; Thu, 18 Jun 2009 16:01:48 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHK3V-0002wF-8B for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 16:01:42 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5IG1PsC027849; Thu, 18 Jun 2009 09:01:25 -0700 (PDT) Cc: Nicholas Weaver , David Conrad , Mark Andrews , IETF DNSEXT WG Message-Id: From: Nicholas Weaver To: Florian Weimer In-Reply-To: <82bpolin94.fsf@mid.bfk.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS Page Option to handle large responses Date: Thu, 18 Jun 2009 09:01:25 -0700 References: <200906180147.n5I1lk2n056608@drugs.dv.isc.org> <82bpolin94.fsf@mid.bfk.de> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 18, 2009, at 8:18 AM, Florian Weimer wrote: > * David Conrad: > >> Mark, >> >> On Jun 17, 2009, at 6:47 PM, Mark Andrews wrote: >>> A jump in TCP traffic should always have been expected. >> >> Yes, however a 600 fold increase is, at the very least, a bit >> surprising. > > Uh-oh. Has it decreased after the DNSKEY TTL fix? The other thing: this could be done not as a flag day, but roulette: Start with 1% of the responses which request DNSSEC getting the signed response. Ramp this up. This would allow understanding what the impact is going to be, without having an oh-crap moment. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 09:12:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206BA28C165; Thu, 18 Jun 2009 09:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRbLpxbX2jkl; Thu, 18 Jun 2009 09:12:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C81A28C41B; Thu, 18 Jun 2009 09:12:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHK9r-0003pk-I4 for namedroppers-data0@psg.com; Thu, 18 Jun 2009 16:08:11 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHK9P-0003mj-PZ for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 16:07: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 1MHKBD-0006ES-2m; Thu, 18 Jun 2009 18:09:35 +0200 Received: from fweimer by bfk.de with local id 1MHK9J-0004Q3-GQ; Thu, 18 Jun 2009 18:07:37 +0200 To: Nicholas Weaver Cc: David Conrad , Mark Andrews , IETF DNSEXT WG Subject: Re: [dnsext] EDNS Page Option to handle large responses References: <200906180147.n5I1lk2n056608@drugs.dv.isc.org> <82bpolin94.fsf@mid.bfk.de> From: Florian Weimer Date: Thu, 18 Jun 2009 18:07:37 +0200 In-Reply-To: (Nicholas Weaver's message of "Thu\, 18 Jun 2009 09\:01\:25 -0700") Message-ID: <82zlc5h6eu.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: * Nicholas Weaver: > Start with 1% of the responses which request DNSSEC getting the signed > response. Ramp this up. This would allow understanding what the > impact is going to be, without having an oh-crap moment. I don't think it's possible anymore to publish inconsistently signed production zones without ill effects. Deliberately returning inconsistent data certainly doesn't help with debugging. (Perhaps you actually wanted to send this in reply to <82hbydn70l.fsf@mid.bfk.de>?) --=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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 09:15:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44EF528C436; Thu, 18 Jun 2009 09:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-hv6sVRHyn5; Thu, 18 Jun 2009 09:15:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 581D428C429; Thu, 18 Jun 2009 09:15:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHKDL-0004Pt-OZ for namedroppers-data0@psg.com; Thu, 18 Jun 2009 16:11:47 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHKDA-0004P3-VQ for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 16:11:42 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id DA7242FE9573 for ; Thu, 18 Jun 2009 16:11:35 +0000 (UTC) Date: Thu, 18 Jun 2009 12:11:33 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] Re: Does RFC 3226 require DO=1 ==> bufsize over 1219? was Re: [dnsext] New rules for DO bit Message-ID: <20090618161133.GK3542@shinkuro.com> References: <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> <20090618151034.GG3542@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: On Thu, Jun 18, 2009 at 11:46:48AM -0400, Edward Lewis wrote: >> If that is true, then what it really means is that the advertisement >> of the message size is unrelated to the actual message size the >> resolver actually can support. This strikes me as at the very least a >> strained reading of the RFCs. Perhaps the IETF needs a truth in >> advertising BCP, but I'd hate to think we had that many protocol >> lawyers around. > > Given my experience with implementers who don't pay attention to the > IETF's daily soap opera, I support David's statement above. When you > read the RFCs "cold" and try to write code you find the RFCs are pretty > poorly done and neglectfully maintained. [no hat] While I think you can find lots of examples to illustrat that position, this one strikes me as a particularly poor one. Only someone who had already made up his or her mind to do what they wanted would imagine that "advertising your message size" means anything other than "advertise the message size you can accept". What possible purpose would an advertisement for some other size serve? Now, you might argue that in this case it serves your best guess of what the _deployed_ settings of your system actually can handle (since those deployed settings include the network gear in front of the resolver). But in that case, what you're saying is that you do not, as deployed, support a message size larger than 512. In which case, you're telling the truth in some sense, and it happens that as deployed, you're not in a position to do what DNSSEC needs over UDP. Of course, if it's true that almost all existing networks fall into this category, then it means that DNSSEC is just not deployable over UDP, and we're out of luck. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 09:20:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BB2A3A659B; Thu, 18 Jun 2009 09:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-0.051, 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 TJaYoEj5XWHv; Thu, 18 Jun 2009 09:20:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 411AB28C44B; Thu, 18 Jun 2009 09:20:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHKJ9-0005I4-OX for namedroppers-data0@psg.com; Thu, 18 Jun 2009 16:17:47 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHKIy-0005Gi-3N for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 16:17:42 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5IGHTOa000464; Thu, 18 Jun 2009 09:17:29 -0700 (PDT) Cc: Nicholas Weaver , David Conrad , Mark Andrews , IETF DNSEXT WG Message-Id: From: Nicholas Weaver To: Florian Weimer In-Reply-To: <82zlc5h6eu.fsf@mid.bfk.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS Page Option to handle large responses Date: Thu, 18 Jun 2009 09:17:29 -0700 References: <200906180147.n5I1lk2n056608@drugs.dv.isc.org> <82bpolin94.fsf@mid.bfk.de> <82zlc5h6eu.fsf@mid.bfk.de> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 18, 2009, at 9:07 AM, Florian Weimer wrote: > * Nicholas Weaver: > >> Start with 1% of the responses which request DNSSEC getting the =20 >> signed >> response. Ramp this up. This would allow understanding what the >> impact is going to be, without having an oh-crap moment. > > I don't think it's possible anymore to publish inconsistently signed > production zones without ill effects. Deliberately returning > inconsistent data certainly doesn't help with debugging. It could be deterministic based on IP. The thing is, a lot of resolvers request DNSSEC information without =20 USING it, and once the root is signed, it will still be a while before =20= the resolvers actually are able to use this information. Thus randomization is probably better than a flag day: you test how =20 the resolvers are going to behave in a ramp-up fashion that can be =20 rolled back, and you take advantage of the observation that >1/2 the =20 recursive resolvers are asking for DNSSEC records, but on the initial =20= rollout, most will be unable to use it anyway. > > (Perhaps you actually wanted to send this in reply to > <82hbydn70l.fsf@mid.bfk.de>?) > > --=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 > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 09:24:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A7F28C471; Thu, 18 Jun 2009 09:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[AWL=-0.961, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dehu7lfi7t9F; Thu, 18 Jun 2009 09:24:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C7AB63A659B; Thu, 18 Jun 2009 09:23:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHKMl-0005tE-0w for namedroppers-data0@psg.com; Thu, 18 Jun 2009 16:21:31 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHKMZ-0005pV-Uv for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 16:21:25 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8B18B2FE9573 for ; Thu, 18 Jun 2009 16:21:18 +0000 (UTC) Date: Thu, 18 Jun 2009 12:21:15 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] On RFC maintenance and reference implementations (was: Does RFC 3226. . .) Message-ID: <20090618162115.GL3542@crankycanuck.ca> References: <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> <20090618151034.GG3542@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: [Co-chair hat on] On Thu, Jun 18, 2009 at 11:46:48AM -0400, Edward Lewis wrote: > (As one case in point, the RFC 1996 for NOTIFY, section 3.7 describes a > feature that was silently deprecated 10 years ago - no one bothered to > update the Proposed Standard document.) > > I've adopted an personal informal rule - if the RFC is more than 5 years > old and BIND doesn't do it in the current version, consider the feature > deprecated. So in this case, I'd expect to see DO=1 and bufsize under > 1220. As far as RFC 3226, I recall a few years ago arguing that it > didn't apply to IPv6 because it referenced A6 and not AAAA. Speaking only for myself, but in my role as chair, I am both depressed and alarmed by the above two paragraphs. If we have "silently deprecated" a feature, it'd be awful nice to see someone write up the maintenance draft. I don't note that such a draft is floating around, but maybe I'm missing it. But I'm more concerned about the second paragraph. If the answer, even for DNS experts with long experience, to "How should this work?" is "What does BIND do?", then it seems to me we're wasting everyone's time and energy here. We can just let ISC do what it wants, and everyone else can follow that. This is particularly troubling in the current case, since the present dispute is in fact partly about behaviour in BIND. If a significant portion of the DNS community has a silent rule that one implementation is actually _the_ reference implementation, we're doing a huge disservice to the Internet community generally by pretending otherwise. I sort of find this hard to believe, and I rather hope it's false, but actually knowing would be better than hope. I am therefore curious to know whether others have the same informal rule as Ed. Feel free to send me mail off-list if you don't feel comfortable saying so on-list. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 09:24:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42FF128C477; Thu, 18 Jun 2009 09:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiaNitXI0jbF; Thu, 18 Jun 2009 09:24:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 340F528C473; Thu, 18 Jun 2009 09:24:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHKNK-0005x4-CX for namedroppers-data0@psg.com; Thu, 18 Jun 2009 16:22:06 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHKN9-0005vh-Df for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 16:22:00 +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 1MHKOz-0008Id-6b; Thu, 18 Jun 2009 18:23:49 +0200 Received: from fweimer by bfk.de with local id 1MHKN4-0005m6-4B; Thu, 18 Jun 2009 18:21:50 +0200 To: Nicholas Weaver Cc: David Conrad , Mark Andrews , IETF DNSEXT WG Subject: Re: [dnsext] EDNS Page Option to handle large responses References: <200906180147.n5I1lk2n056608@drugs.dv.isc.org> <82bpolin94.fsf@mid.bfk.de> <82zlc5h6eu.fsf@mid.bfk.de> From: Florian Weimer Date: Thu, 18 Jun 2009 18:21:50 +0200 In-Reply-To: (Nicholas Weaver's message of "Thu\, 18 Jun 2009 09\:17\:29 -0700") Message-ID: <82prd1h5r5.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: * Nicholas Weaver: >> I don't think it's possible anymore to publish inconsistently signed >> production zones without ill effects. Deliberately returning >> inconsistent data certainly doesn't help with debugging. > > It could be deterministic based on IP. Currently it's not necessary that you flush your cache if your egress IP address changes. 8-/ > The thing is, a lot of resolvers request DNSSEC information without > USING it, and once the root is signed, it will still be a while before > the resolvers actually are able to use this information. There's a better solution for that, see my other message: use distinct hints (with distinct names and addresses for the root servers). This only works for the root, of course. Something like DLVNS could work for others (and DLVNS would also be handy for implementing Leyen-type DNS policies). --=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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 09:45:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B4E3A6CEF; Thu, 18 Jun 2009 09:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osKSi2gI70dj; Thu, 18 Jun 2009 09:45:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E69B28C389; Thu, 18 Jun 2009 09:44:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHKfO-0007r1-RC for namedroppers-data0@psg.com; Thu, 18 Jun 2009 16:40:46 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHKf8-0007pQ-3e for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 16:40:41 +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 1MHKgq-0001qH-Rd; Thu, 18 Jun 2009 18:42:16 +0200 Received: from fweimer by bfk.de with local id 1MHKex-0000iH-5d; Thu, 18 Jun 2009 18:40:19 +0200 To: Olafur Gudmundsson Cc: David Conrad , Mark Andrews , IETF DNSEXT WG Subject: Re: [dnsext] EDNS Page Option to handle large responses References: <200906180147.n5I1lk2n056608@drugs.dv.isc.org> <82bpolin94.fsf@mid.bfk.de> <200906181558.n5IFwKdZ008898@stora.ogud.com> From: Florian Weimer Date: Thu, 18 Jun 2009 18:40:19 +0200 In-Reply-To: <200906181558.n5IFwKdZ008898@stora.ogud.com> (Olafur Gudmundsson's message of "Thu\, 18 Jun 2009 11\:58\:11 -0400") Message-ID: <82ljnph4wc.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: * Olafur Gudmundsson: > At 11:18 18/06/2009, Florian Weimer wrote: >>* David Conrad: >> >> > Mark, >> > >> > On Jun 17, 2009, at 6:47 PM, Mark Andrews wrote: >> >> A jump in TCP traffic should always have been expected. >> > >> > Yes, however a 600 fold increase is, at the very least, a bit >> > surprising. >> >>Uh-oh. Has it decreased after the DNSKEY TTL fix? > > Will not help a lot, There are more negative answers than retries by > validators to get DNSKEY RRset. > Minimum negative answer is 999 bytes. (qname =3D 3.org) > I.e. all the 512 and DO=3D1 queries for bad name will get truncated answe= r. If the answer size is < 1200 bytes, I don't expect the DO=3D1/bufsize=3D512 fallback to trigger 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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 09:48:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9CCF28C38E; Thu, 18 Jun 2009 09:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58jga-o4KzS6; Thu, 18 Jun 2009 09:48:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 17A333A6C3B; Thu, 18 Jun 2009 09:47:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHKjz-0008Ie-O7 for namedroppers-data0@psg.com; Thu, 18 Jun 2009 16:45:31 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHKjo-0008H2-39 for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 16:45:25 +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 1MHKlb-0002Fl-Rs; Thu, 18 Jun 2009 18:47:11 +0200 Received: from fweimer by bfk.de with local id 1MHKji-0003gl-6W; Thu, 18 Jun 2009 18:45:14 +0200 To: Mark Andrews Cc: David Conrad , Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 References: <200906090027.n590Qxuv064919@drugs.dv.isc.org> From: Florian Weimer Date: Thu, 18 Jun 2009 18:45:14 +0200 In-Reply-To: <200906090027.n590Qxuv064919@drugs.dv.isc.org> (Mark Andrews's message of "Tue\, 09 Jun 2009 10\:26\:59 +1000") Message-ID: <82k539h4o5.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: * Mark Andrews: >> Last time I checked, the roots (except one) did not perform PMTUD, so >> fragmentation is not under their control. Many DNS servers send the >> final fragment first anyway. This is not very likely to change. > > I beg to differ. 8 of the roots are performing PMTU discovery over IPv4/= UDP. > Whether the operators are aware of this or not is another matter. This c= an > usually be disabled at the the application layer. AFAICT, it can't. You might not send out PMTUD probe messages, but this doesn't prevent the stack from processing unsolicited answers and applying the result to the packets you send. > 09:57:54.387361 198.41.0.4.53 > 211.30.172.21.64982: 24664*- 1/13/11 SOA= (497) (DF) You also need to check if the ICMP "fragmentation needed but DF bit set" message is processed by the 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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 10:09:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DCF73A680E; Thu, 18 Jun 2009 10:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.524 X-Spam-Level: X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdVKEFyMLHmd; Thu, 18 Jun 2009 10:09:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B0193A6B1E; Thu, 18 Jun 2009 10:08:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHL1F-0009uT-UY for namedroppers-data0@psg.com; Thu, 18 Jun 2009 17:03:21 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHL0v-0009rn-0r for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 17:03:13 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5IH20tj001771; Thu, 18 Jun 2009 17:02:00 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5IH20wW001770; Thu, 18 Jun 2009 17:02:00 GMT Date: Thu, 18 Jun 2009 17:02:00 +0000 From: bmanning@vacation.karoshi.com To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Does RFC 3226 require DO=1 ==> bufsize over 1219? was Re: [dnsext] New rules for DO bit Message-ID: <20090618170200.GA1559@vacation.karoshi.com.> References: <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> <20090618151034.GG3542@shinkuro.com> <20090618161133.GK3542@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090618161133.GK3542@shinkuro.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 18, 2009 at 12:11:33PM -0400, Andrew Sullivan wrote: > On Thu, Jun 18, 2009 at 11:46:48AM -0400, Edward Lewis wrote: > > >> If that is true, then what it really means is that the advertisement > >> of the message size is unrelated to the actual message size the > >> resolver actually can support. This strikes me as at the very least a > >> strained reading of the RFCs. Perhaps the IETF needs a truth in > >> advertising BCP, but I'd hate to think we had that many protocol > >> lawyers around. > > > > Given my experience with implementers who don't pay attention to the > > IETF's daily soap opera, I support David's statement above. When you > > read the RFCs "cold" and try to write code you find the RFCs are pretty > > poorly done and neglectfully maintained. > > [no hat] > While I think you can find lots of examples to illustrat that > position, this one strikes me as a particularly poor one. Only > someone who had already made up his or her mind to do what they wanted > would imagine that "advertising your message size" means anything > other than "advertise the message size you can accept". What possible > purpose would an advertisement for some other size serve? > > Now, you might argue that in this case it serves your best guess of > what the _deployed_ settings of your system actually can handle (since > those deployed settings include the network gear in front of the > resolver). But in that case, what you're saying is that you do not, > as deployed, support a message size larger than 512. In which case, > you're telling the truth in some sense, and it happens that as > deployed, you're not in a position to do what DNSSEC needs over UDP. > Of course, if it's true that almost all existing networks fall into > this category, then it means that DNSSEC is just not deployable over > UDP, and we're out of luck. you've just lept to a conclusion. DNSSEC is deployable over UDP. DNSSEC is not feasable if some helpful box/app between the validator and authority server decides to arbitrarily throttle the infrastructure capaibility. i'm kind of interested in the second stage event, when the pushback to TCP occurs and then the very helpful box/app inthe middle decides that NO, port 53 over TCP is not supported either. the problem is the cruft in between the validator and authoritive server. not UDP. the 512 limiter is in some respects like a bandwidth limiter. what kinds of hoops would we have had to jump through if there was general kowtowing to the fact that it was too expensive to upgrade core links from 64Kbit. or that 64K Ram was a hard limit. we have put buffer size negotiation in endsystems and are finding that others have placed rate/service limiters inbetween these endsystems. the proper pressure here is to affect changes in those rate/service limiters to allow the DNSSEC capability to be expressed/used. -- bill > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 10:11:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9D133A680E; Thu, 18 Jun 2009 10:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.523 X-Spam-Level: X-Spam-Status: No, score=-4.523 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aloK9jRopLu4; Thu, 18 Jun 2009 10:11:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF15E3A686A; Thu, 18 Jun 2009 10:11:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHL5m-000AR8-Eg for namedroppers-data0@psg.com; Thu, 18 Jun 2009 17:08:02 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHL5Y-000ANx-9u for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 17:07:54 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5IH6ltj001818; Thu, 18 Jun 2009 17:06:47 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5IH6lQF001817; Thu, 18 Jun 2009 17:06:47 GMT Date: Thu, 18 Jun 2009 17:06:47 +0000 From: bmanning@vacation.karoshi.com To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] On RFC maintenance and reference implementations (was: Does RFC 3226. . .) Message-ID: <20090618170647.GB1559@vacation.karoshi.com.> References: <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> <20090618151034.GG3542@shinkuro.com> <20090618162115.GL3542@crankycanuck.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090618162115.GL3542@crankycanuck.ca> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: BIND has been touted as -the- DNS reference implementation. which might have been true at one time, but is patently no longer the case; e.g. no A6 support anymore, non-spec DLV, non compliance with RFC 3226... the list is long and growing. --bill On Thu, Jun 18, 2009 at 12:21:15PM -0400, Andrew Sullivan wrote: > [Co-chair hat on] > > On Thu, Jun 18, 2009 at 11:46:48AM -0400, Edward Lewis wrote: > > > (As one case in point, the RFC 1996 for NOTIFY, section 3.7 describes a > > feature that was silently deprecated 10 years ago - no one bothered to > > update the Proposed Standard document.) > > > > I've adopted an personal informal rule - if the RFC is more than 5 years > > old and BIND doesn't do it in the current version, consider the feature > > deprecated. So in this case, I'd expect to see DO=1 and bufsize under > > 1220. As far as RFC 3226, I recall a few years ago arguing that it > > didn't apply to IPv6 because it referenced A6 and not AAAA. > > Speaking only for myself, but in my role as chair, I am both depressed > and alarmed by the above two paragraphs. > > If we have "silently deprecated" a feature, it'd be awful nice to see > someone write up the maintenance draft. I don't note that such a > draft is floating around, but maybe I'm missing it. > > But I'm more concerned about the second paragraph. If the answer, > even for DNS experts with long experience, to "How should this work?" > is "What does BIND do?", then it seems to me we're wasting everyone's > time and energy here. We can just let ISC do what it wants, and > everyone else can follow that. > > This is particularly troubling in the current case, since the present > dispute is in fact partly about behaviour in BIND. > > If a significant portion of the DNS community has a silent rule that > one implementation is actually _the_ reference implementation, we're > doing a huge disservice to the Internet community generally by > pretending otherwise. I sort of find this hard to believe, and I > rather hope it's false, but actually knowing would be better than > hope. > > I am therefore curious to know whether others have the same informal > rule as Ed. Feel free to send me mail off-list if you don't feel > comfortable saying so on-list. > > Best regards, > > Andrew > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 10:58:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8790928C446; Thu, 18 Jun 2009 10:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5r+MVmg3G0tm; Thu, 18 Jun 2009 10:58:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8C35B28C3F6; Thu, 18 Jun 2009 10:58:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHLoJ-000Esl-TD for namedroppers-data0@psg.com; Thu, 18 Jun 2009 17:54:03 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHLo4-000Er1-7g for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 17:53:58 +0000 Received: from [10.31.201.162] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5IHrgnI010544; Thu, 18 Jun 2009 13:53:42 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090618170647.GB1559@vacation.karoshi.com.> References: <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> <20090618151034.GG3542@shinkuro.com> <20090618162115.GL3542@crankycanuck.ca> <20090618170647.GB1559@vacation.karoshi.com.> Date: Thu, 18 Jun 2009 13:53:36 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] On RFC maintenance and reference implementations (was: Does RFC 3226. . .) Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ISC has staunchly denied being a reference implementation. ISC has never claimed BIND to be a role model. (Heck, it combines authority and recursion in one code base.) Innuendo that they are "no longer" a reference implementation is an unfair slight. BTW, A6 has been deprecated (perhaps not documented ;) ) - it and bitstring labels were very, very bad ideas upon further review. Cool ideas maybe, but not sustainable in core infrastructural elements. At 17:06 +0000 6/18/09, bmanning@vacation.karoshi.com wrote: > BIND has been touted as -the- DNS reference implementation. > > which might have been true at one time, but is patently no longer > the case; e.g. no A6 support anymore, non-spec DLV, non compliance > with RFC 3226... the list is long and growing. > >--bill > > >On Thu, Jun 18, 2009 at 12:21:15PM -0400, Andrew Sullivan wrote: >> [Co-chair hat on] >> >> On Thu, Jun 18, 2009 at 11:46:48AM -0400, Edward Lewis wrote: >> >> > (As one case in point, the RFC 1996 for NOTIFY, section 3.7 describes a >> > feature that was silently deprecated 10 years ago - no one bothered to >> > update the Proposed Standard document.) >> > >> > I've adopted an personal informal rule - if the RFC is more than 5 years >> > old and BIND doesn't do it in the current version, consider the feature >> > deprecated. So in this case, I'd expect to see DO=1 and bufsize under >> > 1220. As far as RFC 3226, I recall a few years ago arguing that it >> > didn't apply to IPv6 because it referenced A6 and not AAAA. >> >> Speaking only for myself, but in my role as chair, I am both depressed >> and alarmed by the above two paragraphs. >> >> If we have "silently deprecated" a feature, it'd be awful nice to see >> someone write up the maintenance draft. I don't note that such a >> draft is floating around, but maybe I'm missing it. >> >> But I'm more concerned about the second paragraph. If the answer, >> even for DNS experts with long experience, to "How should this work?" >> is "What does BIND do?", then it seems to me we're wasting everyone's >> time and energy here. We can just let ISC do what it wants, and >> everyone else can follow that. >> >> This is particularly troubling in the current case, since the present >> dispute is in fact partly about behaviour in BIND. >> >> If a significant portion of the DNS community has a silent rule that >> one implementation is actually _the_ reference implementation, we're >> doing a huge disservice to the Internet community generally by >> pretending otherwise. I sort of find this hard to believe, and I >> rather hope it's false, but actually knowing would be better than >> hope. >> >> I am therefore curious to know whether others have the same informal >> rule as Ed. Feel free to send me mail off-list if you don't feel >> comfortable saying so on-list. >> >> Best regards, >> >> Andrew >> >> -- >> Andrew Sullivan >> ajs@shinkuro.com >> Shinkuro, Inc. >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From sydnkoht@Intinet.com Thu Jun 18 11:15:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0244C28C39C for ; Thu, 18 Jun 2009 11:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.953 X-Spam-Level: X-Spam-Status: No, score=-6.953 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_IMAGE_ONLY_28=1.561, 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_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_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 zmUCh33CFfFw for ; Thu, 18 Jun 2009 11:15:47 -0700 (PDT) Received: from dsl85-238-89-186.pool.tvnet.hu (dsl85-238-89-186.pool.tvnet.hu [85.238.89.186]) by core3.amsl.com (Postfix) with ESMTP id 36C3028C158 for ; Thu, 18 Jun 2009 11:15:45 -0700 (PDT) From: To: dnsext-archive@lists.ietf.org Subject: For: dnsext-archive@lists.ietf.org Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Message-Id: <20090618181546.36C3028C158@core3.amsl.com> Date: Thu, 18 Jun 2009 11:15:45 -0700 (PDT) oekqva
Sign up for newsletters and offers from not.

If you can't read this message from akuxu , then Click Here.
You are receiving this e-mail because you subscribed to eulq Featured Offers. oworii respects your privacy. Please read our online Privacy Statement.

If you would prefer to no longer receive this Featured Offer Newsletter, please click the “Unsubscribe” link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in iek Featured Offers. This shall not constitute an offer by jqrupj. vex shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice. To set your contact preferences for other yparyt communications, see the communications preferences section of the tam Privacy Statement.

©2009 opu | Unsubscribe | More Newsletters | Privacy

jgi Corporation, qvymo Way, usimup
From owner-namedroppers@ops.ietf.org Thu Jun 18 11:21:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7453E28C447; Thu, 18 Jun 2009 11:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.076 X-Spam-Level: X-Spam-Status: No, score=-3.076 tagged_above=-999 required=5 tests=[AWL=1.361, 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 M7OTXzPIiBEg; Thu, 18 Jun 2009 11:21:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 40B583A6A1C; Thu, 18 Jun 2009 11:21:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHMAz-000H88-I9 for namedroppers-data0@psg.com; Thu, 18 Jun 2009 18:17:29 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHMAl-000H6j-LO for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 18:17:24 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id BD493327A78; Thu, 18 Jun 2009 18:17:14 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id 3181D327A72; Thu, 18 Jun 2009 18:17:14 +0000 (UTC) Message-ID: <4A3A84A9.7020909@isc.org> Date: Thu, 18 Jun 2009 13:17:13 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] On RFC maintenance and reference implementations References: <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> <20090618151034.GG3542@shinkuro.com> <20090618162115.GL3542@crankycanuck.ca> <20090618170647.GB1559@vacation.karoshi.com.> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Edward Lewis wrote: > BTW, A6 has been deprecated (perhaps not documented ;) ) - it and > bitstring labels were very, very bad ideas upon further review. Cool > ideas maybe, but not sustainable in core infrastructural elements. And just to add humor into the mix: DLV is an informational RFC, and uses vendor-reserved numbering space. The title of RFC 3226 is "DNSSEC and IPv6 A6 aware server/resolver message size requirements" and since BIND 9 is no longer A6 aware, well we can ignore it, right? I mean, in order to be strict in how ISC reads RFCs and IETF maintains them? It sounds like perhaps the RFCs need some cleanup, nothing more. A reality check, if you will. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko6hKkACgkQ+NNi0s9NRJ0RJQCgmflZd1seb3kTr3o/HgLSpF2E AfkAnijzxQzlwdBU4Ja8BwUJizUvtL2X =eVk4 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From syokun@NEXUSTEK.COM Thu Jun 18 11:32:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7DA3A6ABF for ; Thu, 18 Jun 2009 11:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.953 X-Spam-Level: X-Spam-Status: No, score=-6.953 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_IMAGE_ONLY_28=1.561, 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_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_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 8amMHQ7y07oT for ; Thu, 18 Jun 2009 11:32:33 -0700 (PDT) Received: from dsl85-238-89-186.pool.tvnet.hu (dsl85-238-89-186.pool.tvnet.hu [85.238.89.186]) by core3.amsl.com (Postfix) with ESMTP id 0D43C3A6A1C for ; Thu, 18 Jun 2009 11:32:32 -0700 (PDT) From: To: dnsext-archive@lists.ietf.org Subject: For: dnsext-archive@lists.ietf.org Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Message-Id: <20090618183233.0D43C3A6A1C@core3.amsl.com> Date: Thu, 18 Jun 2009 11:32:32 -0700 (PDT) jax
Sign up for newsletters and offers from jxa.

If you can't read this message from yxurus , then Click Here.
You are receiving this e-mail because you subscribed to eixutu Featured Offers. ycqkon respects your privacy. Please read our online Privacy Statement.

If you would prefer to no longer receive this Featured Offer Newsletter, please click the “Unsubscribe” link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in imi Featured Offers. This shall not constitute an offer by rqna. sum shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice. To set your contact preferences for other qfqkix communications, see the communications preferences section of the nelony Privacy Statement.

©2009 omekic | Unsubscribe | More Newsletters | Privacy

ili Corporation, yhjhe Way, qgqh
From owner-namedroppers@ops.ietf.org Thu Jun 18 11:50:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6663A69ED; Thu, 18 Jun 2009 11:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[AWL=-0.281, 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 0OD7VTZIjWXA; Thu, 18 Jun 2009 11:50:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 173D43A69AE; Thu, 18 Jun 2009 11:50:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHMdi-000JOH-Uo for namedroppers-data0@psg.com; Thu, 18 Jun 2009 18:47:10 +0000 Received: from [209.85.219.207] (helo=mail-ew0-f207.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHMdX-000JN7-Tr for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 18:47:05 +0000 Received: by ewy3 with SMTP id 3so1627308ewy.41 for ; Thu, 18 Jun 2009 11:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=r6YWZjgt3AUKMbZZAMxwxYGtm34NnDVkX7Hs+7Cj7mU=; b=hODXK7BGR7PIB0DKb5qyhHcQpEeM94ehYuJ8A2xIXqtVW/XuAJI2WRIEySB79p5NGr E3dCCFbEYiuA88HnNPtS3UWh/63SPzugmrlRD60E7HysrCGqU729enQweHI6JmJwNE1t Chje7TF9FshTcv4tBfSrBqDVfxOq8ZaCDXRf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=aPxGG02NYwkUxp1VzeMv2NcdTC/eSXjNhHuBidUTugK4F9MVDXoQWQp55vdxXmQEcW sLzVy8E7XBNH1b/UP/eVhJ0EjhCT1k4Mnus8vAKDqvsjVitQo5arBLm6+nS7Xq4w857u tpz9iSj7GcC4R0nAArHdKo9Kj0McSg6grI14w= MIME-Version: 1.0 Received: by 10.211.194.9 with SMTP id w9mr4854134ebp.19.1245350818189; Thu, 18 Jun 2009 11:46:58 -0700 (PDT) In-Reply-To: <20090618162115.GL3542@crankycanuck.ca> References: <200906150119.n5F1JE6b095216@stora.ogud.com> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> <20090618151034.GG3542@shinkuro.com> <20090618162115.GL3542@crankycanuck.ca> From: bert hubert Date: Thu, 18 Jun 2009 20:46:38 +0200 Message-ID: <3efd34cc0906181146w2206cc6awe6cac163afbfaa7@mail.gmail.com> Subject: Re: [dnsext] On RFC maintenance and reference implementations (was: Does RFC 3226. . .) 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: On Thu, Jun 18, 2009 at 6:21 PM, Andrew Sullivan wrote: > On Thu, Jun 18, 2009 at 11:46:48AM -0400, Edward Lewis wrote: >> I've adopted an personal informal rule - if the RFC is more than 5 years >> old and BIND doesn't do it in the current version, consider the feature >> deprecated. =A0So in this case, I'd expect to see DO=3D1 and bufsize und= er >> 1220. [...] > I am therefore curious to know whether others have the same informal > rule as Ed. =A0Feel free to send me mail off-list if you don't feel > comfortable saying so on-list. I'd go even further than Ed. If any DNS feature is not in constant use, or if neither Windows or BIND relies on it, it does not work and it will not work. In fact, sending packets that deviate even slightly from the norm has been known to crash many CPE/SOHO routers (case in point, not doing label compression on the first answer). Quite a lot of what happens on the 'soap opera known as DNSEXT' has very little relation to reality. In general, try to be as close to BIND (perhaps even version 8) as possible, and your stuff will work. Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 12:04:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB8D3A6A8A; Thu, 18 Jun 2009 12:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.422 X-Spam-Level: X-Spam-Status: No, score=-4.422 tagged_above=-999 required=5 tests=[AWL=0.015, 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 2aavAUIovN0T; Thu, 18 Jun 2009 12:04:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 71D413A68BD; Thu, 18 Jun 2009 12:04:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHMqX-000KZw-4m for namedroppers-data0@psg.com; Thu, 18 Jun 2009 19:00:25 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHMqM-000KYM-7r for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 19:00:19 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id E8847649527; Thu, 18 Jun 2009 12:00:13 -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 7EeDwA72jXVt; Thu, 18 Jun 2009 12:00:11 -0700 (PDT) Received: from wlan39-215.mdr.icann.org (wlan39-215.mdr.icann.org [192.0.39.215]) by virtualized.org (Postfix) with ESMTP id 3323F64950C; Thu, 18 Jun 2009 12:00:11 -0700 (PDT) Cc: IETF DNSEXT WG Message-Id: <800B7E23-7BA7-4BB2-8BD9-A43CFF289E1E@virtualized.org> From: David Conrad To: Ray.Bellis@nominet.org.uk In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] New rules for DO bit Date: Thu, 18 Jun 2009 12:00:10 -0700 References: <200906141835.n5EIZ0dD020925@stora.ogud.com> <87iqiy5ywv.fsf@mid.deneb.enyo.de> <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ray, On Jun 18, 2009, at 12:25 AM, Ray.Bellis@nominet.org.uk wrote: > > In the strictest sense of RFC 4035, I guess I'd reluctantly have to > > agree. > ... > > One can read this as saying that while the security-aware resolver > > MUST support 1220 bytes, it doesn't have to advertise that fact. > > It seems very clear to me: > > 1. MUST include EDNS0, with DO=3D1 > 2. MUST support >=3D 1220 (SHOULD support 4000) > 3. MUST say so That would be my reading as well (assuming DNSSEC-related RRs are =20 desired). > I'm struggling to parse the =A74.1 text in any way that would support =20= > an alternate conclusion. As I mentioned, I can see the argument that there is ambiguity. Note that I'm not saying I agree with the argument, rather I agree the =20= argument can be made if you take the words of 4035 and ignore their =20 intent. > The only way to misinterpret this is if the phrases "MUST support a =20= > message size of ..." and "the message size that it is willing to =20 > accept" are taken to mean different things. That's quite a twisting =20= > of the language, and clearly not what the authors intended. As I discovered with 3225, what the author intended and how it is =20 interpreted are not necessarily directly related... :-/ Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 12:04:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E149A3A6A8A; Thu, 18 Jun 2009 12:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.423 X-Spam-Level: X-Spam-Status: No, score=-4.423 tagged_above=-999 required=5 tests=[AWL=0.014, 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 EbbQigFj5JmT; Thu, 18 Jun 2009 12:04:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 136163A68BD; Thu, 18 Jun 2009 12:04:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHMrP-000KfV-Nh for namedroppers-data0@psg.com; Thu, 18 Jun 2009 19:01:19 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHMrF-000Kem-1a for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 19:01:14 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id C95E6649557; Thu, 18 Jun 2009 12:01:08 -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 FgduqhDM7V-8; Thu, 18 Jun 2009 12:01:06 -0700 (PDT) Received: from wlan39-215.mdr.icann.org (wlan39-215.mdr.icann.org [192.0.39.215]) by virtualized.org (Postfix) with ESMTP id C3359649548; Thu, 18 Jun 2009 12:01:06 -0700 (PDT) Cc: IETF DNSEXT WG Message-Id: From: David Conrad To: Mark Andrews In-Reply-To: <200906181212.n5ICC6lX002565@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS Page Option to handle large responses Date: Thu, 18 Jun 2009 12:01:06 -0700 References: <200906181212.n5ICC6lX002565@drugs.dv.isc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Mark, On Jun 18, 2009, at 5:12 AM, Mark Andrews wrote: > In message , > David Conrad > writes: >> On Jun 17, 2009, at 6:47 PM, Mark Andrews wrote: >>> A jump in TCP traffic should always have been expected. >> Yes, however a 600 fold increase is, at the very least, a bit >> surprising. > With a little tuning it will come down a lot. No doubt. That isn't the point. To reiterate: >> As I said, the issue isn't that stuff broke, rather that the >> unexpected happened. The Internet isn't a toy anymore, it is >> critical >> infrastructure. In my view, when mucking about with critical >> infrastructure, unexpected things are very bad. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 12:20:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D17228C2E0; Thu, 18 Jun 2009 12:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.425 X-Spam-Level: X-Spam-Status: No, score=-4.425 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsX1O9T1-53y; Thu, 18 Jun 2009 12:20:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA1EA3A68CE; Thu, 18 Jun 2009 12:20:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHN6q-000Lpw-0R for namedroppers-data0@psg.com; Thu, 18 Jun 2009 19:17:16 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHN6e-000Loq-Md for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 19:17:10 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 6C179649645; Thu, 18 Jun 2009 12:17:04 -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 s+8uroIVTAm2; Thu, 18 Jun 2009 12:17:03 -0700 (PDT) Received: from wlan39-215.mdr.icann.org (wlan39-215.mdr.icann.org [192.0.39.215]) by virtualized.org (Postfix) with ESMTP id D9EDD649636; Thu, 18 Jun 2009 12:17:02 -0700 (PDT) Cc: IETF DNSEXT WG Message-Id: <29BD9706-F7A1-44F6-86B2-3912F221FE97@virtualized.org> From: David Conrad To: Florian Weimer In-Reply-To: <82prd1h5r5.fsf@mid.bfk.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS Page Option to handle large responses Date: Thu, 18 Jun 2009 12:17:02 -0700 References: <200906180147.n5I1lk2n056608@drugs.dv.isc.org> <82bpolin94.fsf@mid.bfk.de> <82zlc5h6eu.fsf@mid.bfk.de> <82prd1h5r5.fsf@mid.bfk.de> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 18, 2009, at 9:21 AM, Florian Weimer wrote: >> The thing is, a lot of resolvers request DNSSEC information without >> USING it, Yep, around 5000 queries per second with DO=1 or about 60% at "L" currently (up from 40% a few months back). >> and once the root is signed, it will still be a while before >> the resolvers actually are able to use this information. This might actually be a positive. If we have to revert back to unsigned because of the unexpected, anyone who had actually configured the root trust anchor will all of a sudden get validation failures. > There's a better solution for that, see my other message: use distinct > hints (with distinct names and addresses for the root servers). +1 Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 12:20:33 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E423B28C385; Thu, 18 Jun 2009 12:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.303 X-Spam-Level: X-Spam-Status: No, score=-3.303 tagged_above=-999 required=5 tests=[AWL=1.134, 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 YdP1ObDDp+w1; Thu, 18 Jun 2009 12:20:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A3CA93A68CE; Thu, 18 Jun 2009 12:20:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHN76-000LrS-Eg for namedroppers-data0@psg.com; Thu, 18 Jun 2009 19:17:32 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHN6u-000LqA-DZ for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 19:17:26 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id A4C7A327A78; Thu, 18 Jun 2009 19:17:19 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id D66AB327A72; Thu, 18 Jun 2009 19:17:18 +0000 (UTC) Message-ID: <4A3A92BE.6090402@isc.org> Date: Thu, 18 Jun 2009 14:17:18 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dean Anderson CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dean Anderson wrote: >> The worst possible attack are otherwise valid queries. The worst >> possible transport is TCP due to the high cost of maintaining a TCP >> endpoint on a server. One is cheap, 50,000 are not. > > Ah. Well, scalability is always hard. That doesn't make it a DDoS > attack. 50,000 UDP queries per second is hard, too. In fact, just about > about as hard as 50,000 TCP queries. Very true. however, a DDoS using TCP would use significantly more resources on the auth server than a UDP attack would. UDP is more or less "fire and forget." TCP requires buffers in the kernel and state tracking in the kernel. For a stateless protocol like DNS, it is scary to start relying on state stored somewhere. > Simulation is unnecessary as the math is simple: TCP takes 5 packets to > setup and shutdown a connection. UDP takes 2. If you count packets, sure. If you consider kernel state, firewall/load balancing filtering state that must be maintained, etc. it gets quite complicated quite fast, and every situation will be slightly different. It's not about packets to me. Packets, even 3x as many, is well understood. It's about load on the server infrastructure itself that worries me. You can only add so many machines before it's clear something is not sanely scalable. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko6kr4ACgkQ+NNi0s9NRJ2z7gCZATRGzWXptBgw5NeFXYjPtnZC pR0AoKw/3qOD7ryRAtYeb8hY36KTZ8Ag =cEhp -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 12:22:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F256928C15C; Thu, 18 Jun 2009 12:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.425 X-Spam-Level: X-Spam-Status: No, score=-4.425 tagged_above=-999 required=5 tests=[AWL=0.012, 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 ltzDafeLYGt7; Thu, 18 Jun 2009 12:22:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1EB683A68CE; Thu, 18 Jun 2009 12:22:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHN9Y-000M4j-Rj for namedroppers-data0@psg.com; Thu, 18 Jun 2009 19:20:04 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHN9O-000M3Q-3S for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 19:19:59 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id C6E896496D7; Thu, 18 Jun 2009 12:19:53 -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 IV3jJt+II0n2; Thu, 18 Jun 2009 12:19:52 -0700 (PDT) Received: from wlan39-215.mdr.icann.org (wlan39-215.mdr.icann.org [192.0.39.215]) by virtualized.org (Postfix) with ESMTP id A4DB46496C5; Thu, 18 Jun 2009 12:19:52 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: <6C7CB111-9763-40FD-99AD-B7AF7ABB089F@virtualized.org> From: David Conrad To: Andrew Sullivan In-Reply-To: <20090618161133.GK3542@shinkuro.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Re: Does RFC 3226 require DO=1 ==> bufsize over 1219? was Re: [dnsext] New rules for DO bit Date: Thu, 18 Jun 2009 12:19:52 -0700 References: <200906150119.n5F1JE6b095216@stora.ogud.com> <4A3619FA.5090404@nlnetlabs.nl> <20090615211157.GD9397@x27.adm.denic.de> <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> <20090618151034.GG3542@shinkuro.com> <20090618161133.GK3542@shinkuro.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Andrew, On Jun 18, 2009, at 9:11 AM, Andrew Sullivan wrote: > Only > someone who had already made up his or her mind to do what they wanted > would imagine that "advertising your message size" means anything > other than "advertise the message size you can accept". What possible > purpose would an advertisement for some other size serve? Well, BIND advertises a number other than what it can accept. Mark can explain why it does so. Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 12:40:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2EC63A6B88; Thu, 18 Jun 2009 12:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.522 X-Spam-Level: X-Spam-Status: No, score=-4.522 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hbl49VZuY515; Thu, 18 Jun 2009 12:40:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A535D3A6F2C; Thu, 18 Jun 2009 12:40:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHNPj-000NZV-27 for namedroppers-data0@psg.com; Thu, 18 Jun 2009 19:36:47 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHNPX-000NYC-R5 for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 19:36:41 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5IJZXtj003007; Thu, 18 Jun 2009 19:35:33 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5IJZXVY003006; Thu, 18 Jun 2009 19:35:33 GMT Date: Thu, 18 Jun 2009 19:35:33 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] On RFC maintenance and reference implementations (was: Does RFC 3226. . .) Message-ID: <20090618193533.GA2125@vacation.karoshi.com.> References: <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> <20090618151034.GG3542@shinkuro.com> <20090618162115.GL3542@crankycanuck.ca> <20090618170647.GB1559@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: On Thu, Jun 18, 2009 at 01:53:36PM -0400, Edward Lewis wrote: > ISC has staunchly denied being a reference implementation. ISC has > never claimed BIND to be a role model. (Heck, it combines authority > and recursion in one code base.) Innuendo that they are "no longer" > a reference implementation is an unfair slight. my memories here diverge from yours. > BTW, A6 has been deprecated (perhaps not documented ;) ) - it and > bitstring labels were very, very bad ideas upon further review. Cool > ideas maybe, but not sustainable in core infrastructural elements. bitstrings were formally depricated. A6 is still experimental. ISC decided unilaterally to remove the code - although they retain code for other experimental or depricated labels/codepoints. > > At 17:06 +0000 6/18/09, bmanning@vacation.karoshi.com wrote: > > BIND has been touted as -the- DNS reference implementation. > > > > which might have been true at one time, but is patently no longer > > the case; e.g. no A6 support anymore, non-spec DLV, non compliance > > with RFC 3226... the list is long and growing. > > > >--bill > > > > > >On Thu, Jun 18, 2009 at 12:21:15PM -0400, Andrew Sullivan wrote: > >> [Co-chair hat on] > >> > >> On Thu, Jun 18, 2009 at 11:46:48AM -0400, Edward Lewis wrote: > >> > >> > (As one case in point, the RFC 1996 for NOTIFY, section 3.7 describes a > >> > feature that was silently deprecated 10 years ago - no one bothered to > >> > update the Proposed Standard document.) > >> > > >> > I've adopted an personal informal rule - if the RFC is more than 5 > >> years > >> > old and BIND doesn't do it in the current version, consider the feature > >> > deprecated. So in this case, I'd expect to see DO=1 and bufsize under > >> > 1220. As far as RFC 3226, I recall a few years ago arguing that it > >> > didn't apply to IPv6 because it referenced A6 and not AAAA. > >> > >> Speaking only for myself, but in my role as chair, I am both depressed > >> and alarmed by the above two paragraphs. > >> > >> If we have "silently deprecated" a feature, it'd be awful nice to see > >> someone write up the maintenance draft. I don't note that such a > >> draft is floating around, but maybe I'm missing it. > >> > >> But I'm more concerned about the second paragraph. If the answer, > >> even for DNS experts with long experience, to "How should this work?" > >> is "What does BIND do?", then it seems to me we're wasting everyone's > >> time and energy here. We can just let ISC do what it wants, and > >> everyone else can follow that. > >> > >> This is particularly troubling in the current case, since the present > >> dispute is in fact partly about behaviour in BIND. > >> > >> If a significant portion of the DNS community has a silent rule that > >> one implementation is actually _the_ reference implementation, we're > >> doing a huge disservice to the Internet community generally by > >> pretending otherwise. I sort of find this hard to believe, and I > >> rather hope it's false, but actually knowing would be better than > >> hope. > >> > >> I am therefore curious to know whether others have the same informal > >> rule as Ed. Feel free to send me mail off-list if you don't feel > >> comfortable saying so on-list. > >> > >> Best regards, > >> > >> Andrew > >> > >> -- > >> Andrew Sullivan > >> ajs@shinkuro.com > >> Shinkuro, Inc. > >> > >> -- > >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >> the word 'unsubscribe' in a single line as the message text body. > >> archive: > > > >-- > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > As with IPv6, the problem with the deployment of frictionless surfaces is > that they're not getting traction. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 12:54:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76B773A6981; Thu, 18 Jun 2009 12:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv3O6ydtOopG; Thu, 18 Jun 2009 12:54:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 965E63A65A5; Thu, 18 Jun 2009 12:54:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHNcw-000Ofb-I9 for namedroppers-data0@psg.com; Thu, 18 Jun 2009 19:50:26 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHNcl-000Odz-CL for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 19:50:21 +0000 Received: from [10.31.201.162] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5IJo8v5011998; Thu, 18 Jun 2009 15:50:08 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090618193533.GA2125@vacation.karoshi.com.> References: <3B043A63-0A2D-473D-B153-D78B2F1ACE68@hopcount.ca> <200906161440.n5GEegfx023035@stora.ogud.com> <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> <20090618151034.GG3542@shinkuro.com> <20090618162115.GL3542@crankycanuck.ca> <20090618170647.GB1559@vacation.karoshi.com.> <20090618193533.GA2125@vacation.karoshi.com.> Date: Thu, 18 Jun 2009 15:49:59 -0400 To: bmanning@vacation.karoshi.com From: Edward Lewis Subject: Re: [dnsext] On RFC maintenance and reference implementations (was: Does RFC 3226. . .) Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 19:35 +0000 6/18/09, bmanning@vacation.karoshi.com wrote: > bitstrings were formally depricated. A6 is still experimental. > ISC decided unilaterally to remove the code - although they retain > code for other experimental or depricated labels/codepoints. Experimental or not, A6 is and was a bad idea. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 13:00:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C953A67A1; Thu, 18 Jun 2009 13:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.026 X-Spam-Level: X-Spam-Status: No, score=-0.026 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hToVdqjwNPHO; Thu, 18 Jun 2009 13:00:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AFA283A65A5; Thu, 18 Jun 2009 13:00:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHNio-000PEz-L8 for namedroppers-data0@psg.com; Thu, 18 Jun 2009 19:56:30 +0000 Received: from [209.85.210.185] (helo=mail-yx0-f185.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHNiZ-000PBE-UP for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 19:56:24 +0000 Received: by yxe15 with SMTP id 15so1564707yxe.5 for ; Thu, 18 Jun 2009 12:55:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.63.11 with SMTP id l11mr1422987aga.8.1245354894845; Thu, 18 Jun 2009 12:54:54 -0700 (PDT) In-Reply-To: <4A3A92BE.6090402@isc.org> References: <4A3A92BE.6090402@isc.org> Date: Thu, 18 Jun 2009 12:54:54 -0700 Message-ID: Subject: Re: [dnsext] EDNS Page Option to handle large responses From: Matthew Dempsky To: Michael Graff Cc: Dean Anderson , 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: On Thu, Jun 18, 2009 at 12:17 PM, Michael Graff wrote: > UDP is more or less "fire and forget." =A0TCP requires buffers in the > kernel and state tracking in the kernel. =A0For a stateless protocol like > DNS, it is scary to start relying on state stored somewhere. For a protocol like DNS, couldn't we eliminate all state on the server? If the server uses TCP syn-cookies, there's no state to keep between the server's SYN-ACK response and the client's subsequent ACK; if the client only sends one DNS query per TCP session and includes that query in its initial ACK packet, then the server can immediately start answering the query, writing the response the same as it would for UDP. I'm not sure what to do about the FIN/ACK handshakes, but I suspect that can be handled somehow, and worst case I don't think sending RSTs would have any negative consequences here. Servers could continue supporting some finite number of stateful TCP connections like they do now to handle old client behavior. I'm pretty sure this would require new functionality in the server's TCP stack and probably the DNS server. For clients to benefit from this, they would also have to make sure to pack the query into the ACK packet (I thought I read that Linux's TCP stack already supports this, but I can't find anything on it right now). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 13:15:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04F93A68CB; Thu, 18 Jun 2009 13:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.972, 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 prKlk4CGEEoY; Thu, 18 Jun 2009 13:15:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7428E3A6853; Thu, 18 Jun 2009 13:15:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHNuP-0000Nq-Nl for namedroppers-data0@psg.com; Thu, 18 Jun 2009 20:08:29 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHNuE-0000MU-JY for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 20:08:24 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id D0344327A78; Thu, 18 Jun 2009 20:08:17 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id EE8A8327A72; Thu, 18 Jun 2009 20:08:16 +0000 (UTC) Message-ID: <4A3A9EB0.1030801@isc.org> Date: Thu, 18 Jun 2009 15:08:16 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Matthew Dempsky CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses References: <4A3A92BE.6090402@isc.org> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Dempsky wrote: > For a protocol like DNS, couldn't we eliminate all state on the > server? If the server uses TCP syn-cookies, there's no state to keep > between the server's SYN-ACK response and the client's subsequent ACK; > if the client only sends one DNS query per TCP session and includes > that query in its initial ACK packet, then the server can immediately > start answering the query, writing the response the same as it would > for UDP. I'm not sure what to do about the FIN/ACK handshakes, but I > suspect that can be handled somehow, and worst case I don't think > sending RSTs would have any negative consequences here. Servers could > continue supporting some finite number of stateful TCP connections > like they do now to handle old client behavior. Are you proposing that we tweak TCP in order to serve DNS data? :) Until you get an ACK from the remote end, you have to hold data in a local buffer. That is the sort of state I mean when I say "state." We might be able to make that state very, very small by limiting the socket buffer space to 4k or so, but this is getting pretty tricky and, worse, I suspect every OS will still have vastly different overhead. Even in the best situation, TCP is higher overhead when talking to a large number of endpoints than UDP, and solutions which require a lot of state to be retained in the kernel scare me. SCTP seems workable if it can be used in an unreliable mode. It will still require some in-kernel state per endpoint, but that state seems easy to spec for in terms of memory/descriptor limits. Not that any of this is easy; part of the problem is we're trying to work around a IP datagram issue by using IP datagrams and all the tricks we've added to IP in the last 15 years. At the end of the day, it's not that much different than what Bittorrent users did to work around filtering based on content, that is to hide the content in various ways. > I'm pretty sure this would require new functionality in the server's > TCP stack and probably the DNS server. For clients to benefit from > this, they would also have to make sure to pack the query into the ACK > packet (I thought I read that Linux's TCP stack already supports this, > but I can't find anything on it right now). HTTP got away with this sort of thing, and it has been useful for other protocols as well. Handling the HTTP headers in the kernel was a major boost to avoid one additional kernel/userland crossing, as was "don't bother me until you receive X bytes," for instance. However, I'm not certain beyond that mechanism how far we could push for TCP stack changes even on the limited number of platforms authority servers run on. I personally don't think that is a path to follow. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko6nrAACgkQ+NNi0s9NRJ1SFgCfYSGjRx4oiEUO25NlaqmdvHxH xeQAn0PN6qDtsU+jjvpIwo/ynfnmOyfD =t0M2 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 13:32:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04E93A6A4D; Thu, 18 Jun 2009 13:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.018 X-Spam-Level: X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzniPx2H3P6B; Thu, 18 Jun 2009 13:32:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D0FE63A6923; Thu, 18 Jun 2009 13:32:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHOEM-0001tS-01 for namedroppers-data0@psg.com; Thu, 18 Jun 2009 20:29:06 +0000 Received: from [209.85.217.220] (helo=mail-gx0-f220.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHOEA-0001s2-PU for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 20:29:00 +0000 Received: by gxk20 with SMTP id 20so2312392gxk.17 for ; Thu, 18 Jun 2009 13:28:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.117.13 with SMTP id p13mr1449688agc.26.1245356933063; Thu, 18 Jun 2009 13:28:53 -0700 (PDT) In-Reply-To: References: <4A3A92BE.6090402@isc.org> <4A3A9EB0.1030801@isc.org> Date: Thu, 18 Jun 2009 13:28:53 -0700 Message-ID: Subject: [dnsext] EDNS Page Option to handle large responses From: Matthew Dempsky To: 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: [Resending because IETF's mailing list software likes to intermittently reject mail from gmail's servers.] On Thu, Jun 18, 2009 at 1:08 PM, Michael Graff wrote: > Are you proposing that we tweak TCP in order to serve DNS data? =A0:) Does setting DF=3D1 when sending UDP packets count as "tweaking" UDP? (I'm interpreting "tweak TCP" to mean alter the TCP protocol, but perhaps you just mean alter DNS's usage of it.) I'm just pointing out it's possible to serve DNS over TCP without requiring the server to keep any more state than it would for serving DNS over UDP and without requiring any TCP protocol changes. > Until you get an ACK from the remote end, you have to hold data in a > local buffer. Only if you want to resend the query at the TCP level. =A0The kernel could throw away that state and close the session if it's pressed for memory, and then the client can repeat its query. You won't have any more guarantee of getting a response than you would with UDP, but the response is more likely to reach the client than a fragmented UDP response, and each TCP segment will include entropy from the source port and sequence numbers, so blind attackers will not be able to spoof parts of large responses. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 13:34:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876DA3A69D1; Thu, 18 Jun 2009 13:34:10 -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=0.850, 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 jHWcj+e1SaKZ; Thu, 18 Jun 2009 13:34:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 708C828C155; Thu, 18 Jun 2009 13:34:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHOGk-00025R-Eh for namedroppers-data0@psg.com; Thu, 18 Jun 2009 20:31:34 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHOGZ-00024N-BO for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 20:31:28 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id A5EAF327A78; Thu, 18 Jun 2009 20:31:22 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id D0169327A72; Thu, 18 Jun 2009 20:31:21 +0000 (UTC) Message-ID: <4A3AA419.8000606@isc.org> Date: Thu, 18 Jun 2009 15:31:21 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Matthew Dempsky CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses References: <4A3A92BE.6090402@isc.org> <4A3A9EB0.1030801@isc.org> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Dempsky wrote: > I'm just pointing out it's possible to serve DNS over TCP without > requiring the server to keep any more state than it would for serving > DNS over UDP and without requiring any TCP protocol changes. I don't agree. When you send data with TCP, you must await the remote end's ACK of it before discarding it from your send buffer. That's state, and I don't see how it can be avoided with TCP. It's a fundamental property of TCP, and not doing that would mean it's not TCP anymore. >> Until you get an ACK from the remote end, you have to hold data in a >> local buffer. > > Only if you want to resend the query at the TCP level. The kernel > could throw away that state and close the session if it's pressed for > memory, and then the client can repeat its query. Not if it is still called TCP. What you are proposing sounds a lot like SCTP with unreliable transmission though. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko6pBkACgkQ+NNi0s9NRJ3tQACeIvAsZrlr3OI2UzrKaSA5hGKm EdAAnR5DKKSyWYPzUszSXQITL6p+QcD3 =VyTT -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 13:56:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D723B3A6BD0; Thu, 18 Jun 2009 13:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.097 X-Spam-Level: X-Spam-Status: No, score=-5.097 tagged_above=-999 required=5 tests=[AWL=-0.049, 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 ReIRdAZz0IBX; Thu, 18 Jun 2009 13:56:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC9E13A6A50; Thu, 18 Jun 2009 13:56:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHObD-0003cO-4f for namedroppers-data0@psg.com; Thu, 18 Jun 2009 20:52:43 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHOaw-0003bB-8X for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 20:52:36 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5IKqJdI011982; Thu, 18 Jun 2009 13:52:19 -0700 (PDT) Cc: Nicholas Weaver , Matthew Dempsky , namedroppers@ops.ietf.org Message-Id: <7518EC66-7707-454F-ADA7-30F98856DA56@icsi.berkeley.edu> From: Nicholas Weaver To: Michael Graff In-Reply-To: <4A3AA419.8000606@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS Page Option to handle large responses Date: Thu, 18 Jun 2009 13:52:19 -0700 References: <4A3A92BE.6090402@isc.org> <4A3A9EB0.1030801@isc.org> <4A3AA419.8000606@isc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 18, 2009, at 1:31 PM, Michael Graff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Matthew Dempsky wrote: > >> I'm just pointing out it's possible to serve DNS over TCP without >> requiring the server to keep any more state than it would for serving >> DNS over UDP and without requiring any TCP protocol changes. > > I don't agree. When you send data with TCP, you must await the remote > end's ACK of it before discarding it from your send buffer. That's > state, and I don't see how it can be avoided with TCP. It's a > fundamental property of TCP, and not doing that would mean it's not > TCP > anymore. For DNS if you are willing to do it in the kernel, probably not, because you can play SYN-cookie like games, and your response has the ACK, so if the response is dropped, the sender will retransmit the query. > >>> Until you get an ACK from the remote end, you have to hold data in a >>> local buffer. >> >> Only if you want to resend the query at the TCP level. The kernel >> could throw away that state and close the session if it's pressed for >> memory, and then the client can repeat its query. > > Not if it is still called TCP. What you are proposing sounds a lot > like > SCTP with unreliable transmission though. > > - --Michael > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAko6pBkACgkQ+NNi0s9NRJ3tQACeIvAsZrlr3OI2UzrKaSA5hGKm > EdAAnR5DKKSyWYPzUszSXQITL6p+QcD3 > =VyTT > -----END PGP SIGNATURE----- > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org > with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 14:08:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4DB93A6A7F; Thu, 18 Jun 2009 14:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.681 X-Spam-Level: X-Spam-Status: No, score=-3.681 tagged_above=-999 required=5 tests=[AWL=0.756, 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 2+MAq25gNil0; Thu, 18 Jun 2009 14:08:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ABB543A6A50; Thu, 18 Jun 2009 14:08:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHOnE-0004Ur-Hi for namedroppers-data0@psg.com; Thu, 18 Jun 2009 21:05:08 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHOn0-0004TI-PQ for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 21:05:03 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id EDF23327A78; Thu, 18 Jun 2009 21:04:53 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id DE7BE327A72; Thu, 18 Jun 2009 21:04:52 +0000 (UTC) Message-ID: <4A3AABF4.9030802@isc.org> Date: Thu, 18 Jun 2009 16:04:52 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nicholas Weaver CC: Matthew Dempsky , namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses References: <4A3A92BE.6090402@isc.org> <4A3A9EB0.1030801@isc.org> <4A3AA419.8000606@isc.org> <7518EC66-7707-454F-ADA7-30F98856DA56@icsi.berkeley.edu> In-Reply-To: <7518EC66-7707-454F-ADA7-30F98856DA56@icsi.berkeley.edu> X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicholas Weaver wrote: > For DNS if you are willing to do it in the kernel, probably not, because > you can play SYN-cookie like games, and your response has the ACK, so if > the response is dropped, the sender will retransmit the query. You can optimize the connection phase, and perhaps even the disconnect. You could even say that a buffer on a client is not a big deal (although on recursive servers, I'd disagree there too) or just a matter of scaling. You cannot do away with in-kernel retransmit buffers on any general purpose OS like NetBSD, FreeBSD, SunOS, etc. They are part of TCP, and while you can make them very small, you must have them. Making them smaller than the data you are sending as a response is also less than useful. Getting rid of them on the sender or receiver means you're just pushing remembering that up to the application, or making something that is not TCP. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko6q/QACgkQ+NNi0s9NRJ0W9QCgl4ibnq3GWeTTnQInvcoYJDU8 J0IAnjuWd5bZaax+7QorXPalty6fQDFd =b9Q9 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 14:14:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7063A6A50; Thu, 18 Jun 2009 14:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.757 X-Spam-Level: X-Spam-Status: No, score=-3.757 tagged_above=-999 required=5 tests=[AWL=0.680, 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 nL9SJviEY-50; Thu, 18 Jun 2009 14:14:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 403083A6C10; Thu, 18 Jun 2009 14:14:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHOse-0004x8-MA for namedroppers-data0@psg.com; Thu, 18 Jun 2009 21:10:44 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHOsQ-0004vl-9W for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 21:10:38 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id B033F327A78 for ; Thu, 18 Jun 2009 21:10:29 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id 4316D327A72 for ; Thu, 18 Jun 2009 21:10:29 +0000 (UTC) Message-ID: <4A3AAD45.9010609@isc.org> Date: Thu, 18 Jun 2009 16:10:29 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dean Anderson wrote: > Once one abandons the socket/filedescriptor/kernel implementation of > TCP, there is no need to worry about state. ... Other than the retransmit buffers. TCP data is sequenced, and you can't just drop data on the floor mid stream in the case a packet needs to be retransmitted. Doing a raw socket means that the application needs to implement TCP, which would still need to have at hand, or be able to recreate, the data for retransmit. I just don't see this happening. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko6rUQACgkQ+NNi0s9NRJ3mlQCbBuf8BvgH6d1NDjoq6bZbuXQ4 A54AoLRsSc01f7VyoVEBbY0uFgEQLn0z =sWDi -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 14:22:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7E63A6BFE; Thu, 18 Jun 2009 14:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.095 X-Spam-Level: X-Spam-Status: No, score=-5.095 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 BQ5KBf73M+GT; Thu, 18 Jun 2009 14:22:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B08D53A67E2; Thu, 18 Jun 2009 14:22:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHP0d-0005ak-1P for namedroppers-data0@psg.com; Thu, 18 Jun 2009 21:18:59 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHP0R-0005Zn-W6 for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 21:18:53 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5ILIhnK016205; Thu, 18 Jun 2009 14:18:44 -0700 (PDT) Cc: Nicholas Weaver , Matthew Dempsky , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Michael Graff In-Reply-To: <4A3AABF4.9030802@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS Page Option to handle large responses Date: Thu, 18 Jun 2009 14:18:43 -0700 References: <4A3A92BE.6090402@isc.org> <4A3A9EB0.1030801@isc.org> <4A3AA419.8000606@isc.org> <7518EC66-7707-454F-ADA7-30F98856DA56@icsi.berkeley.edu> <4A3AABF4.9030802@isc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 18, 2009, at 2:04 PM, Michael Graff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Nicholas Weaver wrote: >> For DNS if you are willing to do it in the kernel, probably not, >> because >> you can play SYN-cookie like games, and your response has the ACK, >> so if >> the response is dropped, the sender will retransmit the query. > > You can optimize the connection phase, and perhaps even the > disconnect. > You could even say that a buffer on a client is not a big deal > (although > on recursive servers, I'd disagree there too) or just a matter of > scaling. > > You cannot do away with in-kernel retransmit buffers on any general > purpose OS like NetBSD, FreeBSD, SunOS, etc. They are part of TCP, > and > while you can make them very small, you must have them. Making them > smaller than the data you are sending as a response is also less than > useful. > > Getting rid of them on the sender or receiver means you're just > pushing > remembering that up to the application, or making something that is > not TCP. I disagree: For DNS (and DNS ONLY) you can do user-level TCP without needing a retransmit buffer, and as long as you have only a single query and for a particular IP/txid/port you respond deterministically: You can use a syn-cookie type game so you don't need state for the ACK for the SYN-ACK. For the response, you generate the response but don't increment the ACK field to ACK the request until the final packet, and for the final packet you send a FIN immediately (half-close the connection). Thus: Dpacket1, dpacket2, dpacket3, all do not ACK the query FIN, which ACKs the query Thus ANY packet loss will cause the sender to retransmit the query packet, which allows the server to regenerate what Dpacket, Dpacket2, dpacket3, FIN should be. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 14:29:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776D13A6BD0; Thu, 18 Jun 2009 14:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.819 X-Spam-Level: X-Spam-Status: No, score=-3.819 tagged_above=-999 required=5 tests=[AWL=0.618, 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 uzD8yXLW2uQ0; Thu, 18 Jun 2009 14:29:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 214283A6CAE; Thu, 18 Jun 2009 14:28:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHP7R-00067o-Uq for namedroppers-data0@psg.com; Thu, 18 Jun 2009 21:26:01 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHP78-00066L-Lh for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 21:25:56 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id DE024327A78; Thu, 18 Jun 2009 21:25:41 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id 48B28327A72; Thu, 18 Jun 2009 21:25:40 +0000 (UTC) Message-ID: <4A3AB0D3.1090904@isc.org> Date: Thu, 18 Jun 2009 16:25:39 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Nicholas Weaver CC: Matthew Dempsky , namedroppers@ops.ietf.org Subject: Re: [dnsext] EDNS Page Option to handle large responses References: <4A3A92BE.6090402@isc.org> <4A3A9EB0.1030801@isc.org> <4A3AA419.8000606@isc.org> <7518EC66-7707-454F-ADA7-30F98856DA56@icsi.berkeley.edu> <4A3AABF4.9030802@isc.org> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicholas Weaver wrote: > For the response, you generate the response but don't increment the ACK > field to ACK the request until the final packet, and for the final > packet you send a FIN immediately (half-close the connection). If the packet were delayed, and you then transmit different data as a response, what happens? And if the client then gets two different versions of the data, what happens? I don't think tweaking TCP as a common practice in order to fix this is a good, solid, scalable way forward. TCP is what TCP is, and while changing it for some cases might be a good idea, I don't think this is one of them. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko6sNMACgkQ+NNi0s9NRJ2aLQCeLv6WTQHE73hocEUscM8WrRfV qpgAnAqPDJXKmCvNQll6dWyK2CpmeC4z =ELYr -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 14:32:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53393A6BAE; Thu, 18 Jun 2009 14:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.094 X-Spam-Level: X-Spam-Status: No, score=-5.094 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 sooYNXA6E1li; Thu, 18 Jun 2009 14:32:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A59EE3A67E1; Thu, 18 Jun 2009 14:32:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHPAx-0006Q4-J2 for namedroppers-data0@psg.com; Thu, 18 Jun 2009 21:29:39 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHPAm-0006P0-Q1 for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 21:29:34 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5ILTOcm017795; Thu, 18 Jun 2009 14:29:24 -0700 (PDT) Cc: Nicholas Weaver , Matthew Dempsky , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Michael Graff In-Reply-To: <4A3AB0D3.1090904@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] EDNS Page Option to handle large responses Date: Thu, 18 Jun 2009 14:29:24 -0700 References: <4A3A92BE.6090402@isc.org> <4A3A9EB0.1030801@isc.org> <4A3AA419.8000606@isc.org> <7518EC66-7707-454F-ADA7-30F98856DA56@icsi.berkeley.edu> <4A3AABF4.9030802@isc.org> <4A3AB0D3.1090904@isc.org> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 18, 2009, at 2:25 PM, Michael Graff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Nicholas Weaver wrote: >> For the response, you generate the response but don't increment the >> ACK >> field to ACK the request until the final packet, and for the final >> packet you send a FIN immediately (half-close the connection). > > If the packet were delayed, and you then transmit different data as a > response, what happens? And if the client then gets two different > versions of the data, what happens? Clients usually happily accept the first one and go from there. AFter all, packet injection attacks work on WiFi quite well. :) And who says that it has to be two different versions of the data: you can be deterministic for a particular IP/Port/ID three-tuple. I don't necessarily think its a good idea, but it IS clear that, if actually desired, you could do "Stateless TCP" for DNS. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 16:17:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08683A6C60; Thu, 18 Jun 2009 16:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 jvOZ4k1rMTIh; Thu, 18 Jun 2009 16:17:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC3053A6B8F; Thu, 18 Jun 2009 16:17:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHQmx-000CzO-EF for namedroppers-data0@psg.com; Thu, 18 Jun 2009 23:12:59 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHQml-000Cyg-Vo for namedroppers@ops.ietf.org; Thu, 18 Jun 2009 23:12:53 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 1C05DE602F; Thu, 18 Jun 2009 23:12:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5INCeSp013641; Fri, 19 Jun 2009 09:12:43 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906182312.n5INCeSp013641@drugs.dv.isc.org> To: David Conrad Cc: Andrew Sullivan , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Re: Does RFC 3226 require DO=1 ==> bufsize over 1219? was Re: [dnsext] New rules for DO bit In-reply-to: Your message of "Thu, 18 Jun 2009 12:19:52 MST." <6C7CB111-9763-40FD-99AD-B7AF7ABB089F@virtualized.org> Date: Fri, 19 Jun 2009 09:12:40 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <6C7CB111-9763-40FD-99AD-B7AF7ABB089F@virtualized.org>, David Conrad writes: > Andrew, > > On Jun 18, 2009, at 9:11 AM, Andrew Sullivan wrote: > > Only > > someone who had already made up his or her mind to do what they wanted > > would imagine that "advertising your message size" means anything > > other than "advertise the message size you can accept". What possible > > purpose would an advertisement for some other size serve? > > Well, BIND advertises a number other than what it can accept. Mark > can explain why it does so. > > Regards, > -drc BIND advertises EDNS@4096. It then advertises EDNS@512 if it doesn't get a answer from several queries for this lookup to multiple servers. It then advertises plain DNS. The size of the first lookup can be adjusted in named.conf but the defaul value is 4096. It is clear looking at the data that the vast majority of queries made with EDNS@4096 the responses get through. It is only the exceptions that don't. There are two levels of exception: 1. Fragmented responses get dropped (firewalls, SOHO proxies). To continue with this one could retry at 1024 (to allow for the smaller link sizes) but that will almost always result in a response with TC set. 2. There is a firewall which won't let through UDP/DNS > 512. Retrying at 512 is needed for this case. Again this will almost always result in TC being set. Falling back to 512 allows both of these to work. Falling back to 512 doesn't significantly change the number of TCP connections that will be made by the level 1 exceptions. Changing named to fallback to 1024 won't significantly change the number of TCP connection made. For type 1 exceptions. Working from behind a type 2 exception is very hard as all the lookups into secure zones are slooowwww. People complain about how slow they are and fix the problem. Mark > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 17:08:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942F228C0F5; Thu, 18 Jun 2009 17:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 1o2pmcvnfcIR; Thu, 18 Jun 2009 17:08:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E3B83A67D7; Thu, 18 Jun 2009 17:08:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHRaq-000GZT-29 for namedroppers-data0@psg.com; Fri, 19 Jun 2009 00:04:32 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHRae-000GYV-0v for namedroppers@ops.ietf.org; Fri, 19 Jun 2009 00:04:25 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 05BC5E6070; Fri, 19 Jun 2009 00:04:18 +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 n5J04CrQ014717; Fri, 19 Jun 2009 10:04:14 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906190004.n5J04CrQ014717@drugs.dv.isc.org> To: Ray.Bellis@nominet.org.uk Cc: IETF DNSEXT WG From: Mark Andrews Subject: Re: [dnsext] TCP pushback In-reply-to: Your message of "Thu, 18 Jun 2009 15:03:11 +0100." Date: Fri, 19 Jun 2009 10:04:12 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Ray.Bellis@nominet.org.uk writes: > > > There's very clearly a number of large zones already sending signed > > > packets in the 512 - ~1400 range. > > > > Yes and they all get through without fragmentation with a > > EDNS UDP size of 4096. > > > > > It's simply not true to say that failure with EDNS@4096 makes failure > with > > > EDNS@1200 (or 1400) certain. I've seen plenty of middleboxes that'll > fail > > > with the former, but work quite happily with the latter. > > > > They work because they got a answer back not because of the > > size of the answer. > > That's not the point > > If an initial >1472 byte response is completely lost because of > fragmentation, then as I understand it the recursor will drop down to > EDNS0/512 for subsequent queries (forever?) even if those queries might > have succeeded at something between 512 and 1472 bytes. Just for that particular query. If the answer fragemented then the chance that it will work without TC at 1024 (which is the only realistic alternate fallback step) is miniscule. > Currently those subsequent EDNS0/512 queries will result in TC=1, and > retry over TCP. If the recursor had retried at EDNS0/1440 that wouldn't > happen. No. It almost certainly would have happened. Run named with edns-udp-size set to 1024 behind a firewall which drops fragments then run it with edns-udp-size at the default. The number of TCP connections being made will be less with the defaults. If you tune named to use the maximimal edns-udp-size without local fragmentation (1460 for IPv4) then you will have less TCP connections that the default. But percentage wise the number of TCP connections in all three senarios is still low and of similar magnitudes. Mark > Ray -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 17:51:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340B73A6A43; Thu, 18 Jun 2009 17:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 10XOwLyIF-vQ; Thu, 18 Jun 2009 17:51:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 09F0F3A6A36; Thu, 18 Jun 2009 17:51:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHSAk-000Jj2-Qt for namedroppers-data0@psg.com; Fri, 19 Jun 2009 00:41:38 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHSAZ-000Jhx-DC for namedroppers@ops.ietf.org; Fri, 19 Jun 2009 00:41:33 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 4F168E606F; Fri, 19 Jun 2009 00:41:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5J0fLX9015682; Fri, 19 Jun 2009 10:41:23 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906190041.n5J0fLX9015682@drugs.dv.isc.org> To: Florian Weimer Cc: Mark Andrews , David Conrad , Olafur Gudmundsson , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Enforcing correct behavior: EDNS0 OK bit set, buffer < 1024 In-reply-to: Your message of "Thu, 18 Jun 2009 18:45:14 +0200." <82k539h4o5.fsf@mid.bfk.de> Date: Fri, 19 Jun 2009 10:41:21 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <82k539h4o5.fsf@mid.bfk.de>, Florian Weimer writes: > * Mark Andrews: > > >> Last time I checked, the roots (except one) did not perform PMTUD, so > >> fragmentation is not under their control. Many DNS servers send the > >> final fragment first anyway. This is not very likely to change. > > > > I beg to differ. 8 of the roots are performing PMTU discovery over IPv4/= > UDP. > > Whether the operators are aware of this or not is another matter. This c= > an > > usually be disabled at the the application layer. > > AFAICT, it can't. You might not send out PMTUD probe messages, but > this doesn't prevent the stack from processing unsolicited answers and > applying the result to the packets you send. "actively performing PMTU discovery over IPv4" then if you want to be picky. > > 09:57:54.387361 198.41.0.4.53 > 211.30.172.21.64982: 24664*- 1/13/11 SOA= > (497) (DF) > > You also need to check if the ICMP "fragmentation needed but DF bit > set" message is processed by the server. Given the OS chooses to set DS and not the application it is reasonable to assume it does process the messages. Mark > --=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 > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 20:32:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D22C3A6A37; Thu, 18 Jun 2009 20:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.522 X-Spam-Level: X-Spam-Status: No, score=-4.522 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u22n8SSpM2t2; Thu, 18 Jun 2009 20:32:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3D6353A69F6; Thu, 18 Jun 2009 20:32:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHUjr-0004zX-Fv for namedroppers-data0@psg.com; Fri, 19 Jun 2009 03:26:03 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHUjd-0004yB-Px for namedroppers@ops.ietf.org; Fri, 19 Jun 2009 03:25:57 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5J3NhA9003255; Fri, 19 Jun 2009 03:23:43 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5J3NbjV003254; Fri, 19 Jun 2009 03:23:37 GMT Date: Fri, 19 Jun 2009 03:23:37 +0000 From: bmanning@vacation.karoshi.com To: Mark Andrews Cc: David Conrad , Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Does RFC 3226 require DO=1 ==> bufsize over 1219? was Re: [dnsext] New rules for DO bit Message-ID: <20090619032337.GB3142@vacation.karoshi.com.> References: <6C7CB111-9763-40FD-99AD-B7AF7ABB089F@virtualized.org> <200906182312.n5INCeSp013641@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906182312.n5INCeSp013641@drugs.dv.isc.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 19, 2009 at 09:12:40AM +1000, Mark Andrews wrote: > > In message <6C7CB111-9763-40FD-99AD-B7AF7ABB089F@virtualized.org>, David Conrad > writes: > > Andrew, > > > > On Jun 18, 2009, at 9:11 AM, Andrew Sullivan wrote: > > > Only > > > someone who had already made up his or her mind to do what they wanted > > > would imagine that "advertising your message size" means anything > > > other than "advertise the message size you can accept". What possible > > > purpose would an advertisement for some other size serve? > > > > Well, BIND advertises a number other than what it can accept. Mark > > can explain why it does so. > > > > Regards, > > -drc > > BIND advertises EDNS@4096. It then advertises EDNS@512 if > it doesn't get a answer from several queries for this lookup > to multiple servers. It then advertises plain DNS. > > The size of the first lookup can be adjusted in named.conf > but the defaul value is 4096. wonderful! can we then tweek the code to then advertise EDNS1400, then plain DNS, no EDNS and buffsize 512? > > It is clear looking at the data that the vast majority of > queries made with EDNS@4096 the responses get through. It > is only the exceptions that don't. > > There are two levels of exception: > 1. Fragmented responses get dropped (firewalls, SOHO > proxies). To continue with this one could retry at 1024 > (to allow for the smaller link sizes) but that will almost > always result in a response with TC set. > > 2. There is a firewall which won't let through UDP/DNS > > 512. Retrying at 512 is needed for this case. Again this > will almost always result in TC being set. > > Falling back to 512 allows both of these to work. Falling > back to 512 doesn't significantly change the number of TCP > connections that will be made by the level 1 exceptions. > > Changing named to fallback to 1024 won't significantly > change the number of TCP connection made. For type 1 > exceptions. > > Working from behind a type 2 exception is very hard as all > the lookups into secure zones are slooowwww. People complain > about how slow they are and fix the problem. > > Mark > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 21:14:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22053A680C; Thu, 18 Jun 2009 21:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf1GbZS1mOyO; Thu, 18 Jun 2009 21:14:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 43D1A3A677C; Thu, 18 Jun 2009 21:14:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHVR1-0007vH-Ho for namedroppers-data0@psg.com; Fri, 19 Jun 2009 04:10:39 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHVQm-0007uN-7H for namedroppers@ops.ietf.org; Fri, 19 Jun 2009 04:10:33 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id A3880E6072; Fri, 19 Jun 2009 04:10:17 +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 n5J4ADTF018186; Fri, 19 Jun 2009 14:10:13 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906190410.n5J4ADTF018186@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com Cc: Mark Andrews , David Conrad , Andrew Sullivan , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Re: Does RFC 3226 require DO=1 ==> bufsize over 1219? was Re: [dnsext] New rules for DO bit In-reply-to: Your message of "Fri, 19 Jun 2009 03:23:37 GMT." <20090619032337.GB3142@vacation.karoshi.com.> Date: Fri, 19 Jun 2009 14:10:13 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <20090619032337.GB3142@vacation.karoshi.com.>, bmanning@vacation.kar oshi.com writes: > On Fri, Jun 19, 2009 at 09:12:40AM +1000, Mark Andrews wrote: > > > > In message <6C7CB111-9763-40FD-99AD-B7AF7ABB089F@virtualized.org>, David Co > nrad > > writes: > > > Andrew, > > > > > > On Jun 18, 2009, at 9:11 AM, Andrew Sullivan wrote: > > > > Only > > > > someone who had already made up his or her mind to do what they wanted > > > > would imagine that "advertising your message size" means anything > > > > other than "advertise the message size you can accept". What possible > > > > purpose would an advertisement for some other size serve? > > > > > > Well, BIND advertises a number other than what it can accept. Mark > > > can explain why it does so. > > > > > > Regards, > > > -drc > > > > BIND advertises EDNS@4096. It then advertises EDNS@512 if > > it doesn't get a answer from several queries for this lookup > > to multiple servers. It then advertises plain DNS. > > > > The size of the first lookup can be adjusted in named.conf > > but the defaul value is 4096. > > wonderful! can we then tweek the code to then advertise > EDNS1400, then plain DNS, no EDNS and buffsize 512? Other than to deliberately break DNSSEC working through a 512 firewall is there any benefit? I don't see any evidence that changing the number will significantly affect the low amount of TCP traffic. > > It is clear looking at the data that the vast majority of > > queries made with EDNS@4096 the responses get through. It > > is only the exceptions that don't. > > > > There are two levels of exception: > > 1. Fragmented responses get dropped (firewalls, SOHO > > proxies). To continue with this one could retry at 1024 > > (to allow for the smaller link sizes) but that will almost > > always result in a response with TC set. > > > > 2. There is a firewall which won't let through UDP/DNS > > > 512. Retrying at 512 is needed for this case. Again this > > will almost always result in TC being set. > > > > Falling back to 512 allows both of these to work. Falling > > back to 512 doesn't significantly change the number of TCP > > connections that will be made by the level 1 exceptions. > > > > Changing named to fallback to 1024 won't significantly > > change the number of TCP connection made. For type 1 > > exceptions. > > > > Working from behind a type 2 exception is very hard as all > > the lookups into secure zones are slooowwww. People complain > > about how slow they are and fix the problem. > > > > Mark > > > > > -- > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > > the word 'unsubscribe' in a single line as the message text body. > > > archive: > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 23:42:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8CF3A6B31; Thu, 18 Jun 2009 23:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.366 X-Spam-Level: X-Spam-Status: No, score=-4.366 tagged_above=-999 required=5 tests=[AWL=-1.068, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlP-O7u8EYL0; Thu, 18 Jun 2009 23:42:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FC6B3A6B8F; Thu, 18 Jun 2009 23:42:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHXhw-000HxL-Iv for namedroppers-data0@psg.com; Fri, 19 Jun 2009 06:36:16 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHXhe-000Hvy-Bt; Fri, 19 Jun 2009 06:36:10 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=NCa6A/w/sR/YSYI2BLExHjRO8ZKKgjtY8XbuOdQf6jrjRIgaKjYui9ys YU6jYzKv64XW/Biqp1XmFxd8TMdaR9DzXE/amwJmZohhi3OLm/C8Se1Pf kKNh4e3BQsZCWQ+; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1245393358; x=1276929358; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20TCP=20pushback|Date:=20Fri,=2019=20Jun=202009=2007: 35:47=20+0100|Message-ID:=20|To:=20Mark =20Andrews=20|Cc:=20IETF=20DNSEXT=20WG=20< namedroppers@ops.ietf.org>,=0D=0A=09owner-namedroppers@op s.ietf.org|MIME-Version:=201.0|In-Reply-To:=20<2009061900 04.n5J04CrQ014717@drugs.dv.isc.org>|References:=20Your=20 message=20of=20"Thu,=2018=20Jun=202009=2015:03:11=20+0100 ."=20=20=20=20=20=20=20=20=20=20=20=20=20=20<200906190004.n5J04CrQ014717@drugs.dv.isc.org>; bh=BJ/RAHa9Rd2R0ouxlE3AqdjIgq9jFwbBQ/LgBTEF3k0=; b=jxmu+qKcc805dYhXouGlbJl/3nzQylRP+L2zlALRzTZZTtbGCcz+kCeh aLo19j7O4w9BOSgvX2+dnMFyyGpUrXFXd82x4iDupwC5AL2zpU/Iu+i16 a0iyz64tEUz+y43; X-IronPort-AV: E=Sophos;i="4.42,250,1243810800"; d="scan'208";a="10927727" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 19 Jun 2009 07:35:51 +0100 In-Reply-To: <200906190004.n5J04CrQ014717@drugs.dv.isc.org> References: Your message of "Thu, 18 Jun 2009 15:03:11 +0100." <200906190004.n5J04CrQ014717@drugs.dv.isc.org> To: Mark Andrews Cc: IETF DNSEXT WG , owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] TCP pushback MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 19 Jun 2009 07:35:47 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 19/06/2009 07:35:55 AM, Serialize complete at 19/06/2009 07:35:55 AM Content-Type: multipart/alternative; boundary="=_alternative 00243C45802575DA_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 00243C45802575DA_= Content-Type: text/plain; charset="US-ASCII" > > If an initial >1472 byte response is completely lost because of > > fragmentation, then as I understand it the recursor will drop down to > > EDNS0/512 for subsequent queries (forever?) even if those queries might > > have succeeded at something between 512 and 1472 bytes. > > Just for that particular query. Mark, Can you please clarify this - the EDNS failback algorithm is retried for every query, and the results not cached on a per-dest-IP basis? Ray --=_alternative 00243C45802575DA_= Content-Type: text/html; charset="US-ASCII"
> > If an initial >1472 byte response is completely lost because of
> > fragmentation, then as I understand it the recursor will drop down to
> > EDNS0/512 for subsequent queries (forever?) even if those queries might
> > have succeeded at something between 512 and 1472 bytes.
>
> Just for that particular query.
Mark,

Can you please clarify this - the EDNS failback algorithm is retried for every query, and the results not cached on a per-dest-IP basis?

Ray
--=_alternative 00243C45802575DA_=-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 18 23:59:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9198C3A68E0; Thu, 18 Jun 2009 23:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 AMv0eyme+Lsy; Thu, 18 Jun 2009 23:59:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B956C3A6812; Thu, 18 Jun 2009 23:59:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHY0N-000JAs-Np for namedroppers-data0@psg.com; Fri, 19 Jun 2009 06:55:19 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHY0C-000J9s-KJ for namedroppers@ops.ietf.org; Fri, 19 Jun 2009 06:55:13 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id EC2D6E6070 for ; Fri, 19 Jun 2009 06:55:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5J6t5GI019401 for ; Fri, 19 Jun 2009 16:55:05 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906190655.n5J6t5GI019401@drugs.dv.isc.org> To: IETF DNSEXT WG From: Mark Andrews Subject: Re: [dnsext] TCP pushback In-reply-to: Your message of "Fri, 19 Jun 2009 07:35:47 +0100." Date: Fri, 19 Jun 2009 16:55:05 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Ray.Bellis@nominet.org.uk writes: > > > If an initial >1472 byte response is completely lost because of > > > fragmentation, then as I understand it the recursor will drop down to > > > EDNS0/512 for subsequent queries (forever?) even if those queries > might > > > have succeeded at something between 512 and 1472 bytes. > > > > Just for that particular query. > > Mark, > > Can you please clarify this - the EDNS failback algorithm is retried for > every query, and the results not cached on a per-dest-IP basis? It's retried for every query. We want to give the EDNS@4096 query a chance to succeed before we fallback. Mark > Ray -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From taspcecd_1950@CATALANAOCCI.ES Thu Jun 18 23:59:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531D53A68E0 for ; Thu, 18 Jun 2009 23:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.851 X-Spam-Level: X-Spam-Status: No, score=-2.851 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CZ=0.445, HELO_EQ_DSL=1.129, HOST_EQ_CZ=0.904, HTML_IMAGE_ONLY_28=1.561, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_UNI=0.591, 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 kDh8EPIQaUWk for ; Thu, 18 Jun 2009 23:59:21 -0700 (PDT) Received: from adsl-static-212-90-231-121.praha.tiscali.cz (adsl-static-212-90-231-121.praha.tiscali.cz [212.90.231.121]) by core3.amsl.com (Postfix) with ESMTP id E16F03A67AF for ; Thu, 18 Jun 2009 23:59:19 -0700 (PDT) From: To: dnsext-archive@ietf.org Subject: For: dnsext-archive@ietf.org Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Message-Id: <20090619065920.E16F03A67AF@core3.amsl.com> Date: Thu, 18 Jun 2009 23:59:19 -0700 (PDT) sqcar
Sign up for newsletters and offers from gqlqz.

If you can't read this message from iyysax , then Click Here.
You are receiving this e-mail because you subscribed to bokqvi Featured Offers. gqz respects your privacy. Please read our online Privacy Statement.

If you would prefer to no longer receive this Featured Offer Newsletter, please click the “Unsubscribe” link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in wumene Featured Offers. This shall not constitute an offer by jja. lura shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice. To set your contact preferences for other zucye communications, see the communications preferences section of the palus Privacy Statement.

©2009 idus | Unsubscribe | More Newsletters | Privacy

evuma Corporation, qige Way, jsuhq
From bobbie-zenkokum@lysam-consulting.com Fri Jun 19 01:14:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB803A6960 for ; Fri, 19 Jun 2009 01:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.815 X-Spam-Level: X-Spam-Status: No, score=-5.815 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MINDSPRING=0.45, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MINDSPRING=2.2, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_28=1.561, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_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 g8zFCMaNe0Bt for ; Fri, 19 Jun 2009 01:14:32 -0700 (PDT) Received: from user-0c93pla.cable.mindspring.com (user-0c93pla.cable.mindspring.com [24.145.230.170]) by core3.amsl.com (Postfix) with ESMTP id 66B2F3A659C for ; Fri, 19 Jun 2009 01:14:32 -0700 (PDT) From: To: dnsext-archive@lists.ietf.org Subject: For: dnsext-archive@lists.ietf.org Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Message-Id: <20090619081432.66B2F3A659C@core3.amsl.com> Date: Fri, 19 Jun 2009 01:14:32 -0700 (PDT) iqzu
Sign up for newsletters and offers from jka.

If you can't read this message from qifora , then Click Here.
You are receiving this e-mail because you subscribed to qpu Featured Offers. jfj respects your privacy. Please read our online Privacy Statement.

If you would prefer to no longer receive this Featured Offer Newsletter, please click the “Unsubscribe” link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in teciur Featured Offers. This shall not constitute an offer by epjnyp. jdo shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice. To set your contact preferences for other awil communications, see the communications preferences section of the uijqm Privacy Statement.

©2009 ezquvy | Unsubscribe | More Newsletters | Privacy

djoqfe Corporation, omjiek Way, lowep
From owner-namedroppers@ops.ietf.org Fri Jun 19 03:45:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862713A6AB1; Fri, 19 Jun 2009 03:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.521 X-Spam-Level: X-Spam-Status: No, score=-4.521 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUvKgNBBTlWJ; Fri, 19 Jun 2009 03:45:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 846393A6A26; Fri, 19 Jun 2009 03:45:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHbUj-0009lf-GF for namedroppers-data0@psg.com; Fri, 19 Jun 2009 10:38:53 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHbUX-0009kU-E6 for namedroppers@ops.ietf.org; Fri, 19 Jun 2009 10:38:47 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5JAbdA9006431; Fri, 19 Jun 2009 10:37:39 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5JAbY1k006430; Fri, 19 Jun 2009 10:37:35 GMT Date: Fri, 19 Jun 2009 10:37:34 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: [dnsext] On RFC maintenance and reference implementations (was: Does RFC 3226. . .) Message-ID: <20090619103734.GA6378@vacation.karoshi.com.> References: <87ocsohxz6.fsf@mid.deneb.enyo.de> <84444.1245180816@nsa.vix.com> <6F2A3EEF-9004-4810-A7DE-3568136D4F25@virtualized.org> <20090618151034.GG3542@shinkuro.com> <20090618162115.GL3542@crankycanuck.ca> <20090618170647.GB1559@vacation.karoshi.com.> <20090618193533.GA2125@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: On Thu, Jun 18, 2009 at 03:49:59PM -0400, Edward Lewis wrote: > At 19:35 +0000 6/18/09, bmanning@vacation.karoshi.com wrote: > > > bitstrings were formally depricated. A6 is still experimental. > > ISC decided unilaterally to remove the code - although they retain > > code for other experimental or depricated labels/codepoints. > > Experimental or not, A6 is and was a bad idea. lots o bad ideas out there... take ARP for example. and some really good ones... like A6! --bill > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > As with IPv6, the problem with the deployment of frictionless surfaces is > that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 19 03:55:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD5E3A6A81; Fri, 19 Jun 2009 03:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.52 X-Spam-Level: X-Spam-Status: No, score=-4.52 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+vU+-7SBSyf; Fri, 19 Jun 2009 03:55:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E4713A6A05; Fri, 19 Jun 2009 03:55:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHbho-000BBR-7h for namedroppers-data0@psg.com; Fri, 19 Jun 2009 10:52:24 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHbhd-000BAB-70 for namedroppers@ops.ietf.org; Fri, 19 Jun 2009 10:52:18 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5JAo6A9006515; Fri, 19 Jun 2009 10:50:06 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5JAo0Z9006514; Fri, 19 Jun 2009 10:50:00 GMT Date: Fri, 19 Jun 2009 10:50:00 +0000 From: bmanning@vacation.karoshi.com To: Mark Andrews Cc: bmanning@vacation.karoshi.com, David Conrad , Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Does RFC 3226 require DO=1 ==> bufsize over 1219? was Re: [dnsext] New rules for DO bit Message-ID: <20090619105000.GC6378@vacation.karoshi.com.> References: <20090619032337.GB3142@vacation.karoshi.com.> <200906190410.n5J4ADTF018186@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906190410.n5J4ADTF018186@drugs.dv.isc.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 19, 2009 at 02:10:13PM +1000, Mark Andrews wrote: > > In message <20090619032337.GB3142@vacation.karoshi.com.>, bmanning@vacation.kar > oshi.com writes: > > On Fri, Jun 19, 2009 at 09:12:40AM +1000, Mark Andrews wrote: > > > > > > In message <6C7CB111-9763-40FD-99AD-B7AF7ABB089F@virtualized.org>, David Co > > nrad > > > writes: > > > > Andrew, > > > > > > > > On Jun 18, 2009, at 9:11 AM, Andrew Sullivan wrote: > > > > > Only > > > > > someone who had already made up his or her mind to do what they wanted > > > > > would imagine that "advertising your message size" means anything > > > > > other than "advertise the message size you can accept". What possible > > > > > purpose would an advertisement for some other size serve? > > > > > > > > Well, BIND advertises a number other than what it can accept. Mark > > > > can explain why it does so. > > > > > > > > Regards, > > > > -drc > > > > > > BIND advertises EDNS@4096. It then advertises EDNS@512 if > > > it doesn't get a answer from several queries for this lookup > > > to multiple servers. It then advertises plain DNS. > > > > > > The size of the first lookup can be adjusted in named.conf > > > but the defaul value is 4096. > > > > wonderful! can we then tweek the code to then advertise > > EDNS1400, then plain DNS, no EDNS and buffsize 512? > > Other than to deliberately break DNSSEC working through a > 512 firewall is there any benefit? I don't see any evidence > that changing the number will significantly affect the low > amount of TCP traffic. I can take that as a yes then? --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 19 07:14:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D473A6BBF; Fri, 19 Jun 2009 07:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 DSUr3ayrW-ra; Fri, 19 Jun 2009 07:14:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB05F3A692D; Fri, 19 Jun 2009 07:14:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHem4-00028A-Ux for namedroppers-data0@psg.com; Fri, 19 Jun 2009 14:09:00 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHelt-00026t-SN for namedroppers@ops.ietf.org; Fri, 19 Jun 2009 14:08:55 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 4C6D0A6292; Fri, 19 Jun 2009 14:08:49 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Mark Andrews cc: IETF DNSEXT WG Subject: Re: [dnsext] TCP pushback In-Reply-To: Your message of "Fri, 19 Jun 2009 16:55:05 +1000." <200906190655.n5J6t5GI019401@drugs.dv.isc.org> References: <200906190655.n5J6t5GI019401@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 19 Jun 2009 14:08:49 +0000 Message-ID: <54694.1245420529@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > To: IETF DNSEXT WG > From: Mark Andrews > > > Can you please clarify this - the EDNS failback algorithm is retried for > > every query, and the results not cached on a per-dest-IP basis? > > It's retried for every query. We want to give the EDNS@4096 > query a chance to succeed before we fallback. please send new fallback text for RFC2671bis. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 19 08:34:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53BDA3A6A44; Fri, 19 Jun 2009 08:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.092 X-Spam-Level: X-Spam-Status: No, score=-5.092 tagged_above=-999 required=5 tests=[AWL=-0.044, 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 ue4J1Mt5Lawo; Fri, 19 Jun 2009 08:34:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A5D53A6828; Fri, 19 Jun 2009 08:34:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHg2L-0009IL-RU for namedroppers-data0@psg.com; Fri, 19 Jun 2009 15:29:53 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHg2A-0009HB-MC for namedroppers@ops.ietf.org; Fri, 19 Jun 2009 15:29:48 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5JFTOYZ016846; Fri, 19 Jun 2009 08:29:41 -0700 (PDT) Message-Id: <28DE3730-CD87-4269-A706-A0058D51DB23@icsi.berkeley.edu> From: Nicholas Weaver To: IETF DNSEXT WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] Why the cause of drops matter... Date: Fri, 19 Jun 2009 08:29:24 -0700 Cc: Nicholas Weaver X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Netalyzr now (finally, sorry for not thinking of this earlier) distinguishes why a large EDNS-enabled response to an EDNS request fails: whether it is due to fragmentation not being reassembled (assuming the de-facto MTU of ~1500B) or due to a middlebox thinking DNS should be 512B. This is accomplished by having a lookup for edns_large return an ~1800B response, and edns_medium return a ~1400B response. I do NOT have statistically significant numbers for this yet. This matters: If the problem is mostly fragmentation, DNSSEC signing authorities who don't want TCP fallback would benefit greatly from making sure responses <1500B, but its OK for them to be >512B. If the resolver maintains state about how an authority responds to EDNS, it SHOULD first fallback to 1400B, so that it can successfully get responses, and only if 1400B fails, fallback to 512B. This is to enable the resolver to learn if the issue is fragmentation or if the issue is 512B, and act appropriately. If the resolver does NOT maintain state about how an authority responds to EDNS, it doesn't matter if the fallback is to 512B. The condition will only occur if the response was greater than the MTU for the network, so a fallback to 1400B will probably not succeed. Thus since Bind does not maintain state about the authority, dropping to 512B is perfectly fine. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 19 08:54:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48FD13A659B; Fri, 19 Jun 2009 08:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.307 X-Spam-Level: X-Spam-Status: No, score=-4.307 tagged_above=-999 required=5 tests=[AWL=-1.009, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AB9sCVMiWAo; Fri, 19 Jun 2009 08:54:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 445923A69CC; Fri, 19 Jun 2009 08:53:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHgLq-000BBG-UO for namedroppers-data0@psg.com; Fri, 19 Jun 2009 15:50:02 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHgLa-000B8r-TN; Fri, 19 Jun 2009 15:49:56 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=WDrS4Ddj3JarxQVdnM+R0MAvpf8R/C2GsrDhsd7EhoaKN2EDFlNyDLfV st9ZDZnIW/yzyCcex1GwCU+9q9lMKn6kBWg7zQA0Rts/eFKsRYHYDp10H Y55HE7uVBZQOIt5; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1245426586; x=1276962586; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20TCP=20pushback|Date:=20Fri,=2019=20Jun=202009=2016: 47:36=20+0100|Message-ID:=20|To:=20Mark =20Andrews=20|Cc:=20IETF=20DNSEXT=20WG=20< namedroppers@ops.ietf.org>,=0D=0A=09owner-namedroppers@op s.ietf.org|MIME-Version:=201.0|In-Reply-To:=20<2009061906 55.n5J6t5GI019401@drugs.dv.isc.org>|References:=20Your=20 message=20of=20"Fri,=2019=20Jun=202009=2007:35:47=20+0100 ."=20=20=20=20=20=20=20=20=20=20=20=20=20=20<200906190655.n5J6t5GI019401@drugs.dv.isc.org>; bh=ZAciiDZzZFeiqTJmMu4kZsW3APR1kZkcf75yM4i7bIA=; b=YWETUG557diaE+a/AMvJeiuyoa0f+SQkO/loK0/4tqEk4BqxF7oZOihf Al9ejVnizoSnQK9R8V8zuSt+Lch2WxedPrlQTuP6vUeMQnJZQQdpmlOPi WIvw/nOWtWRlf6w; X-IronPort-AV: E=Sophos;i="4.42,254,1243810800"; d="scan'208";a="14961743" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 19 Jun 2009 16:49:40 +0100 In-Reply-To: <200906190655.n5J6t5GI019401@drugs.dv.isc.org> References: Your message of "Fri, 19 Jun 2009 07:35:47 +0100." <200906190655.n5J6t5GI019401@drugs.dv.isc.org> To: Mark Andrews Cc: IETF DNSEXT WG , owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] TCP pushback MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 19 Jun 2009 16:47:36 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 19/06/2009 04:49:43 PM, Serialize complete at 19/06/2009 04:49:43 PM Content-Type: multipart/alternative; boundary="=_alternative 0056C134802575DA_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 0056C134802575DA_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable > It's retried for every query. We want to give the EDNS@4096 > query a chance to succeed before we fallback. RFC 2671 (=A75.3) certainly envisioned that resolvers might cache the EDNS0= =20 capabilities of other servers. In such a case then probing @1280 or @1460 should certainly be of some=20 benefit, per the scenario I suggested in my previous e-mail. I'm slightly surprised that BIND apparently does not do any such caching.=20 I can see why in BIND's case you currently argue that EDNS0 fallback to=20 something higher than 512 is unnecessary, notwithstanding that in the DO=3D= 1=20 case falling back to 512 bytes is clearly contrary to RFC 3226. Ray --=_alternative 0056C134802575DA_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
>    It's retried for every query.  We want to give the EDNS@4096
>    query a chance to succeed before we fallback.
RFC 2671 (=A75.3) certainly envisioned that resolvers might cache the EDNS0 capabilities of other servers.

In such a case then probing @1280 or @1460 should certainly be of some benefit, per the scenario I suggested in my previous e-mail.

I'm slightly surprised that BIND apparently does not do any such caching.  I can see why in BIND's case you currently argue that EDNS0 fallback to something higher than 512 is unnecessary, notwithsta= nding that in the DO=3D1 case falling back to 512 bytes is clearly contrary to RFC 3226.

Ray
--=_alternative 0056C134802575DA_=-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 19 08:55:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01FE3A69C2; Fri, 19 Jun 2009 08:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.254 X-Spam-Level: X-Spam-Status: No, score=-4.254 tagged_above=-999 required=5 tests=[AWL=-0.956, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyt6Iw9cWtXS; Fri, 19 Jun 2009 08:55:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B70903A659B; Fri, 19 Jun 2009 08:55:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHgPM-000Bf6-HT for namedroppers-data0@psg.com; Fri, 19 Jun 2009 15:53:40 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHgPA-000BdO-5y; Fri, 19 Jun 2009 15:53:34 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=0Sqye/B6cyM0tW41sr8MNjsESuT6LMpU0GvgSa4u+qZEks0jsvnFnR+I KTQtDvTj8iIqqZyy0SH7cWxQ1ArCPo2yrty6o6H5mARfFRdsj5yqyi0kH gJPa44ZQenejNSn; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1245426808; x=1276962808; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20Why=20the=20cause=20of=20drops=20matter...|Date:=20 Fri,=2019=20Jun=202009=2016:53:18=20+0100|Message-ID:=20< OF19C3A27F.0FCF6B85-ON802575DA.00571A74-802575DA.00574736 @nominet.org.uk>|To:=20Nicholas=20Weaver=20|Cc:=20IETF=20DNSEXT=20WG=20,=0D=0A=09Nicholas=20Weaver=20,=0D=0A=09owner-namedroppers@ops.ietf.org |MIME-Version:=201.0|In-Reply-To:=20<28DE3730-CD87-4269-A 706-A0058D51DB23@icsi.berkeley.edu>|References:=20<28DE37 30-CD87-4269-A706-A0058D51DB23@icsi.berkeley.edu>; bh=WSpZwl0/i+XFlwgp1QZcAOrNx54bfxGMe3EMC5myQDY=; b=4pLbRYhFJ4fuI8GYtLNCF7uMOGQUuXT239MmarJ2QTuL3svvNcO9J5Qm g+GvwJGhiD5ncfZ2oEP/pAQWUspOAh7fna27WtFGtFmuQ/lCZrUaMqm+H 5pN/tjky+dQjIGG; X-IronPort-AV: E=Sophos;i="4.42,254,1243810800"; d="scan'208";a="14961829" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 19 Jun 2009 16:53:22 +0100 In-Reply-To: <28DE3730-CD87-4269-A706-A0058D51DB23@icsi.berkeley.edu> References: <28DE3730-CD87-4269-A706-A0058D51DB23@icsi.berkeley.edu> To: Nicholas Weaver Cc: IETF DNSEXT WG , Nicholas Weaver , owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] Why the cause of drops matter... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 19 Jun 2009 16:53:18 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 19/06/2009 04:53:26 PM, Serialize complete at 19/06/2009 04:53:26 PM Content-Type: multipart/alternative; boundary="=_alternative 00574734802575DA_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 00574734802575DA_= Content-Type: text/plain; charset="US-ASCII" > If the problem is mostly fragmentation, DNSSEC signing authorities > who don't want TCP fallback would benefit greatly from making sure > responses <1500B, but its OK for them to be >512B. > > If the resolver maintains state about how an authority responds to > EDNS, it SHOULD first fallback to 1400B, so that it can successfully > get responses, and only if 1400B fails, fallback to 512B. This is to > enable the resolver to learn if the issue is fragmentation or if the > issue is 512B, and act appropriately. > > If the resolver does NOT maintain state about how an authority > responds to EDNS, it doesn't matter if the fallback is to 512B. The > condition will only occur if the response was greater than the MTU for > the network, so a fallback to 1400B will probably not succeed. > > Thus since Bind does not maintain state about the authority, dropping > to 512B is perfectly fine. That's my conclusion too. [ unless DO=1 ;-) ] Ray --=_alternative 00574734802575DA_= Content-Type: text/html; charset="US-ASCII"
>    If the problem is mostly fragmentation, DNSSEC signing authorities  
> who don't want TCP fallback would benefit greatly from making sure  
> responses <1500B, but its OK for them to be >512B.
>
>    If the resolver maintains state about how an authority responds to  
> EDNS, it SHOULD first fallback to 1400B, so that it can successfully  
> get responses, and only if 1400B fails, fallback to 512B.  This is to  
> enable the resolver to learn if the issue is fragmentation or if the  
> issue is 512B, and act appropriately.
>
>    If the resolver does NOT maintain state about how an authority  
> responds to EDNS, it doesn't matter if the fallback is to 512B.  The  
> condition will only occur if the response was greater than the MTU for  
> the network, so a fallback to 1400B will probably not succeed.
>
>    Thus since Bind does not maintain state about the authority, dropping  
> to 512B is perfectly fine.
That's my conclusion too.  [ unless DO=1 ;-) ]

Ray
--=_alternative 00574734802575DA_=-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From reasonsd8@michaelhohl.com Fri Jun 19 09:19:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26F6D3A69B1; Fri, 19 Jun 2009 09:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.7 X-Spam-Level: X-Spam-Status: No, score=-11.7 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=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_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, SARE_SUB_WEIGHTLOSS=0.689, STOX_REPLY_TYPE=0.001, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySSBY+OZ0u9i; Fri, 19 Jun 2009 09:19:05 -0700 (PDT) Received: from 189-18-160-19.dsl.telesp.net.br (189-18-160-19.dsl.telesp.net.br [189.18.160.19]) by core3.amsl.com (Postfix) with ESMTP id 52A6E3A6A46; Fri, 19 Jun 2009 09:18:49 -0700 (PDT) Date: Fri, 19 Jun 2009 13:18:43 -0300 From: directory-request@ietf.org Subject: Have the Best weightloss product shipped to your door To: Message-ID: <000d01c9f0f9$9d7d0930$6400a8c0@reasonsd8> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Get Thin Easily with Acai Berry Acai Berry is your ticket to a new life. Knock here http://irmqoiue.cn From owner-namedroppers@ops.ietf.org Fri Jun 19 09:27:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF2B3A6ACF; Fri, 19 Jun 2009 09:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.045 X-Spam-Level: **** X-Spam-Status: No, score=4.045 tagged_above=-999 required=5 tests=[AWL=1.943, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, 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 O+lv75bj4E37; Fri, 19 Jun 2009 09:27:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9551D3A699C; Fri, 19 Jun 2009 09:27:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHgrV-000EbK-DD for namedroppers-data0@psg.com; Fri, 19 Jun 2009 16:22:45 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHgrF-000EZr-0Z; Fri, 19 Jun 2009 16:22:39 +0000 Received: from [172.23.170.137] (helo=anti-virus01-08) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1MHgr4-0000hP-Pz; Fri, 19 Jun 2009 17:22:18 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MHgr4-0000U5-19; Fri, 19 Jun 2009 17:22:18 +0100 Message-ID: <619814E5557D4791819744EB9DDAC3E3@localhost> From: "George Barwood" To: "Mark Andrews" , Cc: "IETF DNSEXT WG" , References: Your message of "Fri, 19 Jun 2009 07:35:47 +0100." <200906190655.n5J6t5GI019401@drugs.dv.isc.org> Subject: Re: [dnsext] TCP pushback Date: Fri, 19 Jun 2009 17:22:17 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06C8_01C9F102.7E8231A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_06C8_01C9F102.7E8231A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Isn't the other situation in which dropping, or starting, at 1400 may be = of benefit is where=20 the server tailors's response to fit? Glue (which may be signed) can always be dropped, and also the NS rrset = might be=20 omitted ( when not requested ). Just because the @4000 response got fragmented and lost, because it was = over 1500,=20 doesn't mean an @1400 response will also be over 1500 and fragmented and = lost. If problems are noted/expected, I think a good strategy may be to start = at 1400,=20 and "fall back" to 4000 on truncation.=20 ----- Original Message -----=20 From: Ray.Bellis@nominet.org.uk=20 To: Mark Andrews=20 Cc: IETF DNSEXT WG ; owner-namedroppers@ops.ietf.org=20 Sent: Friday, June 19, 2009 4:47 PM Subject: Re: [dnsext] TCP pushback > It's retried for every query. We want to give the EDNS@4096 > query a chance to succeed before we fallback. RFC 2671 (=A75.3) certainly envisioned that resolvers might cache the = EDNS0 capabilities of other servers.=20 In such a case then probing @1280 or @1460 should certainly be of some = benefit, per the scenario I suggested in my previous e-mail.=20 I'm slightly surprised that BIND apparently does not do any such = caching. I can see why in BIND's case you currently argue that EDNS0 = fallback to something higher than 512 is unnecessary, notwithstanding = that in the DO=3D1 case falling back to 512 bytes is clearly contrary to = RFC 3226.=20 Ray=20 ------=_NextPart_000_06C8_01C9F102.7E8231A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Isn't the other situation in which = dropping, or=20 starting, at 1400 may be of benefit is where=20
the server tailors's response to = fit?
 
Glue (which may be signed) can always = be dropped,=20 and also the NS rrset might be =
omitted ( when not requested = ).
 
Just because the @4000 response got = fragmented and=20 lost, because it was over 1500, =
doesn't mean an=20 @1400 response will also be over 1500 and fragmented and = lost.
 
If problems are noted/expected, I think = a good=20 strategy may be to start at 1400,
and "fall back" to 4000 on truncation.=20
 
----- Original Message -----=20
From: Ray.Bellis@nominet.org.uk =
Cc: IETF DNSEXT WG ; owner-namedroppers@ops.ie= tf.org=20
Sent: Friday, June 19, 2009 4:47 PM
Subject: Re: [dnsext] TCP pushback


>    It's retried for = every=20 query.  We want to give the EDNS@4096
>    query a = chance to=20 succeed before we fallback.

RFC = 2671 (=A75.3)=20 certainly envisioned that resolvers might cache the EDNS0 capabilities = of other=20 servers.

In such a case then = probing @1280=20 or @1460 should certainly be of some benefit, per the scenario I = suggested in my=20 previous e-mail.

I'm slightly = surprised=20 that BIND apparently does not do any such caching.  I can see why = in BIND's=20 case you currently argue that EDNS0 fallback to something higher than = 512 is=20 unnecessary, notwithstanding that in the DO=3D1 case falling back to 512 = bytes is=20 clearly contrary to RFC 3226.

Ray
------=_NextPart_000_06C8_01C9F102.7E8231A0-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 19 09:54:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4FEB3A6A75; Fri, 19 Jun 2009 09:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.091 X-Spam-Level: X-Spam-Status: No, score=-5.091 tagged_above=-999 required=5 tests=[AWL=-0.043, 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 x9Od5yeXOjcj; Fri, 19 Jun 2009 09:54:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C7CC93A699C; Fri, 19 Jun 2009 09:54:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHhID-000HN5-BP for namedroppers-data0@psg.com; Fri, 19 Jun 2009 16:50:21 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHhI1-000HLD-Nx; Fri, 19 Jun 2009 16:50:15 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5JGo6CD027070; Fri, 19 Jun 2009 09:50:06 -0700 (PDT) Cc: Nicholas Weaver , IETF DNSEXT WG , owner-namedroppers@ops.ietf.org Message-Id: <51721920-364E-412C-8D82-D793C5E5ACE2@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Ray.Bellis@nominet.org.uk In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Why the cause of drops matter... Date: Fri, 19 Jun 2009 09:50:05 -0700 References: <28DE3730-CD87-4269-A706-A0058D51DB23@icsi.berkeley.edu> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 19, 2009, at 8:53 AM, Ray.Bellis@nominet.org.uk wrote: > > > If the problem is mostly fragmentation, DNSSEC signing > authorities > > who don't want TCP fallback would benefit greatly from making sure > > responses <1500B, but its OK for them to be >512B. > > > > If the resolver maintains state about how an authority responds > to > > EDNS, it SHOULD first fallback to 1400B, so that it can successfully > > get responses, and only if 1400B fails, fallback to 512B. This is > to > > enable the resolver to learn if the issue is fragmentation or if the > > issue is 512B, and act appropriately. > > > > If the resolver does NOT maintain state about how an authority > > responds to EDNS, it doesn't matter if the fallback is to 512B. The > > condition will only occur if the response was greater than the MTU > for > > the network, so a fallback to 1400B will probably not succeed. > > > > Thus since Bind does not maintain state about the authority, > dropping > > to 512B is perfectly fine. > > That's my conclusion too. [ unless DO=1 ;-) ] I'll argue that for DO=1, its still fine. It will have to fall back to TCP because the result will be truncated, but it will have to fallback to TCP anyway. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 19 09:55:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54AC3A699C; Fri, 19 Jun 2009 09:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.49 X-Spam-Level: X-Spam-Status: No, score=-4.49 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=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 3eNTII8HWeCJ; Fri, 19 Jun 2009 09:55:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC5433A6812; Fri, 19 Jun 2009 09:55:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHhKo-000Hcx-Ed for namedroppers-data0@psg.com; Fri, 19 Jun 2009 16:53:02 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHhKd-000Hbu-FY; Fri, 19 Jun 2009 16:52:56 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5JGqi8C027388; Fri, 19 Jun 2009 09:52:44 -0700 (PDT) From: Nicholas Weaver To: "George Barwood" In-Reply-To: <619814E5557D4791819744EB9DDAC3E3@localhost> Subject: Re: [dnsext] TCP pushback X-Priority: 3 References: Your message of "Fri, 19 Jun 2009 07:35:47 +0100." <200906190655.n5J6t5GI019401@drugs.dv.isc.org> <619814E5557D4791819744EB9DDAC3E3@localhost> Message-Id: <95273273-4D6E-404C-9EA3-C56BCDA805B0@icsi.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 19 Jun 2009 09:52:44 -0700 Cc: Nicholas Weaver , "Mark Andrews" , , "IETF DNSEXT WG" , X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 19, 2009, at 9:22 AM, George Barwood wrote: > Isn't the other situation in which dropping, or starting, at 1400 > may be of benefit is where > the server tailors's response to fit? > > Glue (which may be signed) can always be dropped, and also the NS > rrset might be > omitted ( when not requested ). > > Just because the @4000 response got fragmented and lost, because it > was over 1500, > doesn't mean an @1400 response will also be over 1500 and fragmented > and lost. > > If problems are noted/expected, I think a good strategy may be to > start at 1400, > and "fall back" to 4000 on truncation. I'd argue that that is backwards. MOST resolvers do not have b0rken middleboxes in the path. A non-trivial number do. You shouldn't b0rk the clean-path resolvers for the benefit of the broken-path resolver. Rather, the broken-path resolvers ONLY should have the fallback position, and all resolvers should first assume clean, then b0rken, when appropriate. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From fatherlessh4@mancinomats.com Fri Jun 19 09:59:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01C963A6837; Fri, 19 Jun 2009 09:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -42.263 X-Spam-Level: X-Spam-Status: No, score=-42.263 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, 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 CGZPL0ZQ0x4H; Fri, 19 Jun 2009 09:59:08 -0700 (PDT) Received: from host250.190-139-101.telecom.net.ar (host250.190-139-101.telecom.net.ar [190.139.101.250]) by core3.amsl.com (Postfix) with ESMTP id E41C93A6B54; Fri, 19 Jun 2009 09:58:52 -0700 (PDT) Date: Fri, 19 Jun 2009 13:58:34 -0300 From: ediint-archive@ietf.org Subject: Acai Berry , Love your new body. To: Message-ID: <000d01c9f0ff$2e893340$6400a8c0@fatherlessh4> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Losing weight has never been easier. Acai allows for quick weight loss. Visit us here http://iomneiue.cn From faminesh4@mmorpgforum.com Fri Jun 19 17:23:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335923A6B3A; Fri, 19 Jun 2009 17:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.542 X-Spam-Level: X-Spam-Status: No, score=-11.542 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=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_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, STOX_REPLY_TYPE=0.001, SUBJECT_DIET=1.466, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29IhziPTBARV; Fri, 19 Jun 2009 17:23:14 -0700 (PDT) Received: from 189-47-7-180.dsl.telesp.net.br (189-47-7-180.dsl.telesp.net.br [189.47.7.180]) by core3.amsl.com (Postfix) with ESMTP id D76C13A687C; Fri, 19 Jun 2009 17:23:13 -0700 (PDT) Date: Fri, 19 Jun 2009 21:23:24 -0300 From: aaa-archive@lists.ietf.org Subject: Acai Berry , lose unwanted weight fast. To: Message-ID: <000d01c9f13d$53195d00$6400a8c0@faminesh4> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Get your free Trial of Acai Slim today! Your best choice http://ogihyrea.cn best regards Roxane Mcintyre From constrainedc60@psy.com.hk Fri Jun 19 17:26:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4C23A6B20; Fri, 19 Jun 2009 17:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.138 X-Spam-Level: X-Spam-Status: No, score=-19.138 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=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, FS_START_LOSE=1.493, HELO_DYNAMIC_IPADDR2=4.395, 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, STOX_REPLY_TYPE=0.001, SUBJECT_DIET=1.466, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwtbCVM5C8nk; Fri, 19 Jun 2009 17:26:21 -0700 (PDT) Received: from 88-138-56-141.adslgp.cegetel.net (88-138-56-141.adslgp.cegetel.net [88.138.56.141]) by core3.amsl.com (Postfix) with ESMTP id 3A8D23A687C; Fri, 19 Jun 2009 17:26:20 -0700 (PDT) Date: Sat, 20 Jun 2009 02:25:36 +0100 From: action@ietf.org Subject: Lose Weight without moving a muscle To: Message-ID: <000d01c9f13d$a1da30e0$6400a8c0@constrainedc60> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Get Acai Flush working for you , Start your free trial today! Rush to come http://ogihyrea.cn best regards Destany Vela From fabrice.lacroix@caissedesdepots.fr Fri Jun 19 20:17:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9D33A6B21; Fri, 19 Jun 2009 20:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.594 X-Spam-Level: X-Spam-Status: No, score=-9.594 tagged_above=-999 required=5 tests=[BAYES_80=2, DATE_IN_PAST_03_06=0.044, FH_HELO_EQ_CHARTER=2.175, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_CHARTER=1.295, HOST_EQ_DHCP=1.295, INVALID_DATE=1.245, J_CHICKENPOX_32=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SzLbG2yAnhi; Fri, 19 Jun 2009 20:17:09 -0700 (PDT) Received: from 68-184-98-225.dhcp.dgls.ga.charter.com (68-184-98-225.dhcp.dgls.ga.charter.com [68.184.98.225]) by core3.amsl.com (Postfix) with SMTP id 26D2D3A67B2; Fri, 19 Jun 2009 20:17:04 -0700 (PDT) Date: Fri, 19 Jun 2009 23:17:21 -0500; From: "Clay Oconnell" To: "Rachael Herring" Subject: just show your cartier watch; Message-ID: Content-Type: text/plain; Content-Transfer-Encoding: 7Bit; Exclusive rep1ca watches collection http://isctupue.cn From desiccatesrw@netztech.ch Fri Jun 19 20:17:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C69E3A6C01; Fri, 19 Jun 2009 20:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.528 X-Spam-Level: X-Spam-Status: No, score=-23.528 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, GB_OPRAH=2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HS_INDEX_PARAM=0.001, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SUB_WEIGHTLOSS=0.689, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bV6lHCjXRe9O; Fri, 19 Jun 2009 20:17:35 -0700 (PDT) Received: from cpe-173-095-140-046.nc.res.rr.com (cpe-173-095-140-046.nc.res.rr.com [173.95.140.46]) by core3.amsl.com (Postfix) with ESMTP id 5519F3A6BB4; Fri, 19 Jun 2009 20:17:34 -0700 (PDT) Date: Fri, 19 Jun 2009 23:16:34 -0500 Message-Id: <28TN1FW03.663DVGV6KQX0792@173.95.140.46> From: dnsext-archive@lists.ietf.org To: dnsext-archive@lists.ietf.org Subject: Have the Best weightloss product shipped to your door Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Having trouble viewing this email? View it online.
If you wish to discontinue these mailings, please unsubscribe now.
Web Version | Ensure Delivery | Email Preferences | Sign Up | Contact Us

WEEKLY SELECT
   It works for Oprah and is endorsed by Rachel Ray.
Haste to click
This email was sent to dnsext-archive@lists.ietf.org

Should you wish to modify your subscriptions or discontinue future mailings of this newsletter, please edit your email preferences.

To read more about our email policy, please view Privacy Policy.

Copyright ¿ 2009 rssxvrwau International. All rights reserved.
 
From perley@flcore.com Sat Jun 20 04:07:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A0AD3A69F0; Sat, 20 Jun 2009 04:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.73 X-Spam-Level: X-Spam-Status: No, score=-33.73 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_BROADBND=1.118, HOST_EQ_RU=0.875, INVALID_DATE=1.245, J_CHICKENPOX_33=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kmm1sEGWJCZe; Sat, 20 Jun 2009 04:07:01 -0700 (PDT) Received: from a95-110-15-133.broadband.bashtel.ru (a95-110-15-133.broadband.bashtel.ru [95.110.15.133]) by core3.amsl.com (Postfix) with SMTP id 1D0AC3A6809; Sat, 20 Jun 2009 04:06:52 -0700 (PDT) Date: Sat, 20 Jun 2009 07:07:15 -0500; From: "Neil Ferris" To: "Rosanna Larkin" Subject: IWC rep watch for you; Message-ID: Content-Type: text/plain; Content-Transfer-Encoding: 7Bit; Huge choice of Rep1ica watches http://ihjjatue.cn From weaningw1411@pratikauditores.com.br Sat Jun 20 16:39:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2043A6A53; Sat, 20 Jun 2009 16:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.506 X-Spam-Level: X-Spam-Status: No, score=-4.506 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=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_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sO8-iHwIia69; Sat, 20 Jun 2009 16:39:40 -0700 (PDT) Received: from 201-11-109-95.fnsce701.dsl.brasiltelecom.net.br (201-11-109-95.fnsce701.dsl.brasiltelecom.net.br [201.11.109.95]) by core3.amsl.com (Postfix) with ESMTP id 75C723A67F3; Sat, 20 Jun 2009 16:39:39 -0700 (PDT) Date: Sat, 20 Jun 2009 20:37:34 -0300 From: dnsext-archive@lists.ietf.org Subject: Fast and effective , Try Acai Berry. To: Message-ID: <000d01c9f200$167a5ed0$6400a8c0@weaningw1411> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal The Red Carpet diet is out ! Acai Flush is hollywoods biggest seceret. Click right now http://oluadoea.cn best regards Vinnie Kirk From weaningw1411@pratikauditores.com.br Sat Jun 20 16:39:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2043A6A53; Sat, 20 Jun 2009 16:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.506 X-Spam-Level: X-Spam-Status: No, score=-4.506 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=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_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sO8-iHwIia69; Sat, 20 Jun 2009 16:39:40 -0700 (PDT) Received: from 201-11-109-95.fnsce701.dsl.brasiltelecom.net.br (201-11-109-95.fnsce701.dsl.brasiltelecom.net.br [201.11.109.95]) by core3.amsl.com (Postfix) with ESMTP id 75C723A67F3; Sat, 20 Jun 2009 16:39:39 -0700 (PDT) Date: Sat, 20 Jun 2009 20:37:34 -0300 From: dnsext-archive@lists.ietf.org Subject: Fast and effective , Try Acai Berry. To: Message-ID: <000d01c9f200$167a5ed0$6400a8c0@weaningw1411> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal The Red Carpet diet is out ! Acai Flush is hollywoods biggest seceret. Click right now http://oluadoea.cn best regards Vinnie Kirk From owner-namedroppers@ops.ietf.org Sun Jun 21 18:21:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5512E3A6864; Sun, 21 Jun 2009 18:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_14=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 lMXFp0bZQtJp; Sun, 21 Jun 2009 18:21:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B7833A6931; Sun, 21 Jun 2009 18:21:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MIY6W-0004Xm-4J for namedroppers-data0@psg.com; Mon, 22 Jun 2009 01:13:48 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MIY6L-0004Wb-14 for namedroppers@ops.ietf.org; Mon, 22 Jun 2009 01:13:42 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id B19FFE6071; Mon, 22 Jun 2009 01:13:35 +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 n5M1DQZh058491; Mon, 22 Jun 2009 11:13:27 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906220113.n5M1DQZh058491@drugs.dv.isc.org> To: Florian Weimer Cc: Nicholas Weaver , "George Barwood" , "Mark Andrews" , Ray.Bellis@nominet.org.uk, "IETF DNSEXT WG" From: Mark Andrews Subject: Re: [dnsext] TCP pushback In-reply-to: Your message of "Sat, 20 Jun 2009 11:48:24 +0200." <87ws77ck2f.fsf@mid.deneb.enyo.de> Date: Mon, 22 Jun 2009 11:13:26 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <87ws77ck2f.fsf@mid.deneb.enyo.de>, Florian Weimer writes: > * Nicholas Weaver: > > > I'd argue that that is backwards. MOST resolvers do not have b0rken > > middleboxes in the path. A non-trivial number do. > > If the middlebox (or misconfiguration) is on the server side, *all* > clients potentially suffer from such brokenness. > > Please don't assume this is exclusively a client-side issue. Indeed. Named has max-udp-size to help with exactly such a problem. However most end user sites have the capacity to handle the resulting TCP traffic. Those that don't will take corrective steps. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 21 18:47:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 083FC28C190; Sun, 21 Jun 2009 18:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.265 X-Spam-Level: X-Spam-Status: No, score=-0.265 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=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 8PrY10YWEcvN; Sun, 21 Jun 2009 18:47:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 362EC28C189; Sun, 21 Jun 2009 18:47:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MIYZg-00079C-W5 for namedroppers-data0@psg.com; Mon, 22 Jun 2009 01:43:57 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MIYZV-00078P-Qu for namedroppers@ops.ietf.org; Mon, 22 Jun 2009 01:43:51 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5M1hiiu008970 for ; Sun, 21 Jun 2009 21:43:44 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n5M1hiDM008969 for namedroppers@ops.ietf.org; Sun, 21 Jun 2009 21:43:44 -0400 (EDT) (envelope-from namedroppers) Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MHxBc-000Jl6-GC; Sat, 20 Jun 2009 09:48:41 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MHxBR-00036b-0E; Sat, 20 Jun 2009 11:48:25 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1MHxBQ-0003er-GL; Sat, 20 Jun 2009 11:48:24 +0200 From: Florian Weimer To: Nicholas Weaver Cc: "George Barwood" , "Mark Andrews" , , "IETF DNSEXT WG" , Subject: Re: [dnsext] TCP pushback References: <200906190655.n5J6t5GI019401@drugs.dv.isc.org> <619814E5557D4791819744EB9DDAC3E3@localhost> <95273273-4D6E-404C-9EA3-C56BCDA805B0@icsi.berkeley.edu> Date: Sat, 20 Jun 2009 11:48:24 +0200 In-Reply-To: <95273273-4D6E-404C-9EA3-C56BCDA805B0@icsi.berkeley.edu> (Nicholas Weaver's message of "Fri, 19 Jun 2009 09:52:44 -0700") Message-ID: <87ws77ck2f.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Nicholas Weaver: > I'd argue that that is backwards. MOST resolvers do not have b0rken > middleboxes in the path. A non-trivial number do. If the middlebox (or misconfiguration) is on the server side, *all* clients potentially suffer from such brokenness. Please don't assume this is exclusively a client-side issue. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From evangelinayd@ta-shi.com Sun Jun 21 21:37:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D063A6A9D for ; Sun, 21 Jun 2009 21:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.923 X-Spam-Level: X-Spam-Status: No, score=-27.923 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BLUEYON=1.4, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 mxd6XqgWeqlj for ; Sun, 21 Jun 2009 21:37:20 -0700 (PDT) Received: from 92-238-180-82.cable.ubr08.jarr.blueyonder.co.uk (92-238-180-82.cable.ubr08.jarr.blueyonder.co.uk [92.238.180.82]) by core3.amsl.com (Postfix) with ESMTP id E94DF3A6A33 for ; Sun, 21 Jun 2009 21:37:19 -0700 (PDT) Date: Mon, 22 Jun 2009 05:37:17 +0000 Message-Id: <426WO9647.I0LI2H4QT0425@92.238.180.82.ta-shi.com> From: f@ietf.org To: f@ietf.org Subject: Best Acai Berry Offers For Free Click NOw Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
Get your trial of Acai Slim Today.
Get Healthy and stay healthy its easy WIth Acai Berry.
 
 
 
Thank You!
best regards Thomas Day
From quirkierxfc@t2mr3.com Sun Jun 21 21:37:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6793A6A33; Sun, 21 Jun 2009 21:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.913 X-Spam-Level: X-Spam-Status: No, score=-21.913 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=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, FS_WEIGHT_LOSS=2.134, GB_OPRAH=2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BLUEYON=1.4, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 h2LxqtV2qw-S; Sun, 21 Jun 2009 21:37:31 -0700 (PDT) Received: from 92-238-180-82.cable.ubr08.jarr.blueyonder.co.uk (92-238-180-82.cable.ubr08.jarr.blueyonder.co.uk [92.238.180.82]) by core3.amsl.com (Postfix) with ESMTP id D70713A6C75; Sun, 21 Jun 2009 21:37:30 -0700 (PDT) Message-ID: <000d01c9f2f3$292d7730$6400a8c0@quirkierxfc> From: dnsext-archive@ietf.org To: Subject: Oprah Weight loss soloution , Learn about Acai Berry. Date: Mon, 22 Jun 2009 05:37:33 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F2F3.292D7730" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F2F3.292D7730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rich in antioxidants , Acai Berry is your answer to unwanted weight. Get your Free trial today!   Come at the moment =A0 =A0 Thank You!=20 best regards Piper=20 Easley ------=_NextPart_000_0007_01C9F2F3.292D7730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Rich in antioxidants , Acai Berry is your answer to unwanted weigh= t.
Get your Free trial today!
 
Come at the moment
=A0
=A0
Thank You!
best regards Piper=20 Easley
------=_NextPart_000_0007_01C9F2F3.292D7730-- From fecframe-bounces@ietf.org Sun Jun 21 21:37:33 2009 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF6B3A6A9D for ; Sun, 21 Jun 2009 21:37:33 -0700 (PDT) Subject: The results of your email commands From: fecframe-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0061668433==" Message-ID: Date: Sun, 21 Jun 2009 21:37:32 -0700 Precedence: bulk X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of FEC Framework X-List-Administrivia: yes Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org --===============0061668433== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Unprocessed: Get your Free trial today!   Come at the moment =A0 =A0 Thank You!=20 best regards Piper=20 Easley - Done. --===============0061668433== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: fecframe-request@core3.amsl.com Delivered-To: fecframe-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6793A6A33; Sun, 21 Jun 2009 21:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.913 X-Spam-Level: X-Spam-Status: No, score=-21.913 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=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, FS_WEIGHT_LOSS=2.134, GB_OPRAH=2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BLUEYON=1.4, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 h2LxqtV2qw-S; Sun, 21 Jun 2009 21:37:31 -0700 (PDT) Received: from 92-238-180-82.cable.ubr08.jarr.blueyonder.co.uk (92-238-180-82.cable.ubr08.jarr.blueyonder.co.uk [92.238.180.82]) by core3.amsl.com (Postfix) with ESMTP id D70713A6C75; Sun, 21 Jun 2009 21:37:30 -0700 (PDT) Message-ID: <000d01c9f2f3$292d7730$6400a8c0@quirkierxfc> From: dnsext-archive@ietf.org To: Subject: Oprah Weight loss soloution , Learn about Acai Berry. Date: Mon, 22 Jun 2009 05:37:33 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F2F3.292D7730" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F2F3.292D7730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rich in antioxidants , Acai Berry is your answer to unwanted weight. Get your Free trial today!   Come at the moment =A0 =A0 Thank You!=20 best regards Piper=20 Easley ------=_NextPart_000_0007_01C9F2F3.292D7730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Rich in antioxidants , Acai Berry is your answer to unwanted weigh= t.
Get your Free trial today!
 
Come at the moment
=A0
=A0
Thank You!
best regards Piper=20 Easley
------=_NextPart_000_0007_01C9F2F3.292D7730-- --===============0061668433==-- From owner-namedroppers@ops.ietf.org Mon Jun 22 07:26:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BDCB3A6C61; Mon, 22 Jun 2009 07:26: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 Hz75B2lPlVW6; Mon, 22 Jun 2009 07:26:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 12CC53A67F2; Mon, 22 Jun 2009 07:26:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MIkMN-0000Hr-H1 for namedroppers-data0@psg.com; Mon, 22 Jun 2009 14:18:59 +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.69 (FreeBSD)) (envelope-from ) id 1MIkMC-0000Gg-DM for namedroppers@ops.ietf.org; Mon, 22 Jun 2009 14:18:54 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n5MEIkTF008333; Mon, 22 Jun 2009 16:18:46 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200906221418.n5MEIkTF008333@givry.fdupont.fr> From: Francis Dupont To: "George Barwood" cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Danger of coming unstuck In-reply-to: Your message of Mon, 22 Jun 2009 13:52:37 BST. Date: Mon, 22 Jun 2009 16:18:46 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: Possible fixes: (1) Set the reply as truncated => this is what the standard recommends (2) Discard some non-authoritative NS records, so a mixture of NS records and glue can be sent. => if this means a partial RRset this is not (yet) allowed (3) Respond to explicit requests for an A record, where the non-authoritative value is held as glue, with a non-authoritative answer. => IMHO this doesn't fit in the authoritative vs caching servers model. And of course you can't send the query to an authoratative server if you don't know an address of one of them (:-). (4) Similar to (3), but place the result in the additional section ( not to be discarded ). => same than (3) (2) might also be a solution to the BIND @512 question. Thanks Francis.Dupont@fdupont.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 22 11:50:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7B23A69B3; Mon, 22 Jun 2009 11:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=-1.030, BAYES_00=-2.599, FAKE_REPLY_C=2.012, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZjoD--JdqrF; Mon, 22 Jun 2009 11:50:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 45F623A680C; Mon, 22 Jun 2009 11:50:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MIoSu-000N5D-K5 for namedroppers-data0@psg.com; Mon, 22 Jun 2009 18:42:00 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MIoSh-000N3F-Nw for namedroppers@ops.ietf.org; Mon, 22 Jun 2009 18:41:54 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5MIelA9011245 for ; Mon, 22 Jun 2009 18:40:47 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5MIeh0u011242 for namedroppers@ops.ietf.org; Mon, 22 Jun 2009 18:40:43 GMT Date: Mon, 22 Jun 2009 18:40:43 +0000 From: bmanning@vacation.karoshi.com To: namedroppers@ops.ietf.org Subject: Re: [dnsext] TCP pushback Message-ID: <20090622184043.GA11202@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: since this thread took on religious overtones... True life TCP confessions: "Forgive me father, for I have SYN'd. It's been 230 ms since my last retransmission..." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 22 13:41:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F8A3A6B89; Mon, 22 Jun 2009 13:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[AWL=-0.965, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCzpwUqhIcTs; Mon, 22 Jun 2009 13:41:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9037D3A6B95; Mon, 22 Jun 2009 13:41:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MIqE6-0006ic-Ph for namedroppers-data0@psg.com; Mon, 22 Jun 2009 20:34:50 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MIqDu-0006gn-Gv for namedroppers@ops.ietf.org; Mon, 22 Jun 2009 20:34:44 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BCC402FE9661 for ; Mon, 22 Jun 2009 20:34:36 +0000 (UTC) Date: Mon, 22 Jun 2009 16:34:34 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] DNS Extensions Working Group meeting at IETF 75 Message-ID: <20090622203434.GP1117@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: Dear colleagues, As was announced in http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00961.html, we requested a meeting for Stockholm. The draft meeting schedule is now available, and our slot is currently on Wednesday, 29 July from 13:00-15:00 local time. Here is the list of current conflicts: morg lisp netmod avt rtgwg pkix tsvarea The current planned topics for the agenda are GOST Algorithm document Forgery Resilience work (or not) New charter ENDS0 Option hurdle, go to template like for RR types If you have additional items you would like to see scheduled, please speak up at your earliest opportunity. Best regards, Andrew (for the Chairs) -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 23 06:29:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA6028C32F; Tue, 23 Jun 2009 06:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRNAkkn9znfU; Tue, 23 Jun 2009 06:29:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7BB0228C2EA; Tue, 23 Jun 2009 06:29:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJ5wu-0001aa-Nx for namedroppers-data0@psg.com; Tue, 23 Jun 2009 13:22:08 +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.69 (FreeBSD)) (envelope-from ) id 1MJ5wi-0001ZN-Pv for namedroppers@ops.ietf.org; Tue, 23 Jun 2009 13:22:02 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n5NDLrtK014017; Tue, 23 Jun 2009 15:21:53 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200906231321.n5NDLrtK014017@givry.fdupont.fr> From: Francis Dupont To: "George Barwood" cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Danger of coming unstuck In-reply-to: Your message of Mon, 22 Jun 2009 17:30:51 BST. Date: Tue, 23 Jun 2009 15:21:53 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: > Possible fixes: > > (1) Set the reply as truncated > > => this is what the standard recommends Umm.. I don't think so. => note the glue here is a required glue (NS RRs are "below"). IMHO the issue is a conflict between required glue and required DNSSEC (with the 1220 enforced size for DO this should be less common). AFAIK glue that doesn't fit is always discarded silently ( without setting TC bit ). => yes but it is not true for the whole required glue. Of course it is easy to find cases where the glue is not required but is necessary (so your problem needs a solution anyway). Certainly my example seems to show this is also what happens in practice. I'm not aware of any provision that makes the last bit of glue special. Please give me RFC and section... => there is a notion of required glue in RFC 1035. > (2) Discard some non-authoritative NS records, so a mixture of NS > records and glue can be sent. > > => if this means a partial RRset this is not (yet) allowed Yes. I don't see much harm sending partial RRsets where they are not authoritative though. But that could be wrong. => you have to explain how partial RRsets make sense with DNSSEC too. > (3) Respond to explicit requests for an A record, where the > non-authoritative value is held as glue, with a non-authoritative > answer. > > => IMHO this doesn't fit in the authoritative vs caching servers model. > And of course you can't send the query to an authoritative server if > you don't know an address of one of them (:-). => to summary: either the answering server is an authoritative server (and BTW the NS RRset in the referral is authoritative too), or it is a caching/recursive server (and the reponse is non-authoritative and matches the query, i.e., has a NS RRset only if the query type is NS). Umm.. don't understand you here. I'm saying the parent authoritative server responds to a request for a "necessary" glue A record with the value. => necessary or required? the second one is defined, the first one is more useful but there is no easy criterion to recognize it. Currently servers always give the same referral (for a given child zone), regardless of the question ( at least this seems the most common response - not sure if the standard is explicit here ). => the standard defines what is a referral. Francis.Dupont@fdupont.fr PS: in conclusion if the DNSSEC stuff doesn't fit in the referral the TC flag should be set, if the required glue doesn't fit in the referral the TC flag should be set, if the server is caching/recursive the response is not a referral and the TC will be set if there is no enough space. The remaining case is for necessary but not required glue in a referral. Note your example is not in this case. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From caucasoidsq4@teradian.com Tue Jun 23 06:54:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471263A6A2C for ; Tue, 23 Jun 2009 06:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.021 X-Spam-Level: X-Spam-Status: No, score=-33.021 tagged_above=-999 required=5 tests=[BAYES_60=1, DIET_1=0.083, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_WEIGHT_LOSS=2.134, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HS_INDEX_PARAM=0.001, 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_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 Vn6QAnuDJTQX for ; Tue, 23 Jun 2009 06:54:07 -0700 (PDT) Received: from 205.4.219.87.dynamic.jazztel.es (205.4.219.87.dynamic.jazztel.es [87.219.4.205]) by core3.amsl.com (Postfix) with ESMTP id 4BB813A6A0B for ; Tue, 23 Jun 2009 06:53:38 -0700 (PDT) Date: Tue, 23 Jun 2009 15:53:54 +0100 Message-Id: From: f@ietf.org To: f@ietf.org Subject: Free trial of hollywoods weight loss secret Acai Berry. Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0
flush harmful toxins and loose weight for free
Get this miracly Berry working for you today.
 
 
 
Thank You!
best regards Jimmie Cornett
From terrestriale52@mdadams.com Tue Jun 23 07:00:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72A528C35E; Tue, 23 Jun 2009 07:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.005 X-Spam-Level: X-Spam-Status: No, score=-11.005 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_SEX_HOSTDDDD=10.357, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_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 PrBvpFNTY4rG; Tue, 23 Jun 2009 07:00:39 -0700 (PDT) Received: from 205.4.219.87.dynamic.jazztel.es (205.4.219.87.dynamic.jazztel.es [87.219.4.205]) by core3.amsl.com (Postfix) with ESMTP id 4DA4328C361; Tue, 23 Jun 2009 07:00:35 -0700 (PDT) Message-ID: <000d01c9f40a$e5776ff0$6400a8c0@terrestriale52> From: dnsext-archive@ietf.org To: Subject: Discover the magical powers of the Acai Fruit. Date: Tue, 23 Jun 2009 15:59:59 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F40A.E5776FF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F40A.E5776FF0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Discover Acai Berry numerous weight loss and health benefits.=20 Acai will get you those slim and sexy abs you dream of.   Break into this site =A0 =A0 Thank You!=20 best regards Montgomer=20 Brantley ------=_NextPart_000_0007_01C9F40A.E5776FF0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Discover Acai Berry numerous weight loss and health benefits.
Acai will get you those slim and sexy abs you dream of.
 
Break into this site
=A0
=A0
Thank You!
best regards Montgomer=20 Brantley
------=_NextPart_000_0007_01C9F40A.E5776FF0-- From fecframe-bounces@ietf.org Tue Jun 23 07:00:41 2009 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 451A028C357 for ; Tue, 23 Jun 2009 07:00:41 -0700 (PDT) Subject: The results of your email commands From: fecframe-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0251363303==" Message-ID: Date: Tue, 23 Jun 2009 07:00:40 -0700 Precedence: bulk X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of FEC Framework X-List-Administrivia: yes Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org --===============0251363303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Unprocessed: Acai will get you those slim and sexy abs you dream of.   Break into this site =A0 =A0 Thank You!=20 best regards Montgomer=20 Brantley - Done. --===============0251363303== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: fecframe-request@core3.amsl.com Delivered-To: fecframe-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72A528C35E; Tue, 23 Jun 2009 07:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.005 X-Spam-Level: X-Spam-Status: No, score=-11.005 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_SEX_HOSTDDDD=10.357, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_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 PrBvpFNTY4rG; Tue, 23 Jun 2009 07:00:39 -0700 (PDT) Received: from 205.4.219.87.dynamic.jazztel.es (205.4.219.87.dynamic.jazztel.es [87.219.4.205]) by core3.amsl.com (Postfix) with ESMTP id 4DA4328C361; Tue, 23 Jun 2009 07:00:35 -0700 (PDT) Message-ID: <000d01c9f40a$e5776ff0$6400a8c0@terrestriale52> From: dnsext-archive@ietf.org To: Subject: Discover the magical powers of the Acai Fruit. Date: Tue, 23 Jun 2009 15:59:59 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F40A.E5776FF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F40A.E5776FF0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Discover Acai Berry numerous weight loss and health benefits.=20 Acai will get you those slim and sexy abs you dream of.   Break into this site =A0 =A0 Thank You!=20 best regards Montgomer=20 Brantley ------=_NextPart_000_0007_01C9F40A.E5776FF0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Discover Acai Berry numerous weight loss and health benefits.
Acai will get you those slim and sexy abs you dream of.
 
Break into this site
=A0
=A0
Thank You!
best regards Montgomer=20 Brantley
------=_NextPart_000_0007_01C9F40A.E5776FF0-- --===============0251363303==-- From owner-namedroppers@ops.ietf.org Tue Jun 23 07:39:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4545C3A6D1D; Tue, 23 Jun 2009 07:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waybO76SIVw7; Tue, 23 Jun 2009 07:39:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF6713A6BE1; Tue, 23 Jun 2009 07:39:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJ74H-0009F8-3u for namedroppers-data0@psg.com; Tue, 23 Jun 2009 14:33:49 +0000 Received: from [65.201.175.9] (helo=cliffie.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJ745-0009Db-Ls for namedroppers@ops.ietf.org; Tue, 23 Jun 2009 14:33:43 +0000 Received: from monsoon.verisignlabs.com (scooter.bo.labs.vrsn.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id E36B013673F for ; Tue, 23 Jun 2009 10:33:36 -0400 (EDT) Received: from dul1mcmlarson-l1.labs.vrsn.com (dul1mcmlarson-l1.labs.vrsn.com [10.131.244.205]) by monsoon.verisignlabs.com (Postfix) with ESMTP id 58C612422F0 for ; Tue, 23 Jun 2009 10:33:35 -0400 (EDT) Date: Tue, 23 Jun 2009 10:33:36 -0400 From: Matt Larson To: Namedroppers Mailing List Subject: [dnsext] Nested trust anchors (again) Message-ID: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: There's a thread on the DNS-OARC dns-operations list that is really a protocol issue, so I'm bringing it up here. The subject is, once again, how a validator should behave in the presence of multiple trust anchors. BIND prefers the closest trust anchor to the QNAME, while the latest version of the dnssec-bis-updates draft calls for trying all trust anchors until one succeeds. The draft also calls for a configurable option to enable favoring the closest trust anchor to the QNAME. Please see: http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-08#section-= 4.8 This text was based on a namedroppers thread from early September 2008 entitled "Proposed addition to dnssec-bis-updates: Nested Trust Anchors". By my (and the dnssec-bis-editors') reckoning, "try all trust anchors" was overwhelmingly the preferred option. (I just re-read the entire thread.) Now, of course, dnssec-bis-updates isn't final, but last September's discussion looks pretty clear to me. Since we are apparently still discussing this topic, I wanted to point out the nested trust anchor text in dnssec-bis-updates so there are no surprises at last call. It would sure be nice to see BIND change its default behavior to "try all trust anchors" and make "trust the closest trust anchor" a configurable option. Matt ----- Forwarded message from Mark Andrews ----- =46rom: Mark Andrews Subject: Re: [dns-operations] .Org DNSSEC key management policy feedback To: Roy Arends Cc: dns-operations@mail.dns-oarc.net Date: Tue, 23 Jun 2009 12:18:14 +1000 In message , Roy Arends write= s: > On Jun 23, 2009, at 9:39 AM, Mark Andrews wrote: >=20 > > > > In message <1D337EA2-A581-47CE-98AA-E95754465293@dnss.ec>, Roy =20 > > Arends writes: > >> On Jun 23, 2009, at 3:11 AM, Andrew Sullivan wrote: > >> > >>> On Sun, Jun 21, 2009 at 03:24:20PM +0000, bmanning@vacation.karoshi.c= om > >>> wrote: > >>>> On Sun, Jun 21, 2009 at 07:50:47AM -0700, David Conrad wrote: > >>> > >>>>> Yes, but until the root is signed, people will still need to =20 > >>>>> update > >>>>> their trust anchors to reflect all the islands of trust, including > >>>>> the > >>>>> TLDs, they want to validated. > >>> > >>>> even then, they might want to keep the .ORG key > >>> > >>> I'm rather hoping not. Given the way BIND prefers the "closest" > >>> configured trust anchor, I think it will make things less reliable. > >>> Suppose people decide to keep their existing .org key, and then the > >>> root is signed, and the key-keepers think, "Good," and stop checking > >>> for updates. On the next .org key-roll, all of .org instantly goes > >>> dark for those people with the stale key. > >> > >> That still hasn't been fixed? It seems wrong and very annoying. In = =20 > >> my > >> end user experience, it violates the principle of least astonishment. > > > > Actually it doesn't. If you configure a trust-anchor for > > your own company you don't want anything overriding it. > > Having that overridden would be POLA violation. > > > > Having things break because you stopped managing/tracking > > them is not a POLA violation. >=20 > That is a niche kind of market. It would be nice if this behavior =20 > would be configurable, but should not be the default. You seem to be =20 > under the impression that this behavior is standardized in some =20 > protocol specification, and thus should be the default. It is the default for BIND. It has been for 10 years now. Changing the default policy in BIND would be POLA violation. =20 > >> I remember the main counter argument was that folks might want to > >> configure the .ORG key for everything in and under .ORG, and not =20 > >> trust > >> the root key for .ORG, but do trust the root key for everything else. > >> Doesn't fly. There might be simple dependencies from domains under =20 > >> ORG > >> on something not ORG. See for instance http://www.links.org/?p=3D635 on > >> "who pwns the internet". > > > > For . and ORG I agree. For ORG and ISC.ORG I disagree. > > For wattle.id.au (when it is signed) and andrews.wattlet.id.au > > I disagree. There are couple of hundred zones where your > > policy makes sense. There are millions where named's default > > policy will make sense. >=20 > Imagine I have configured a key for au and for net.au. The latter key =20 > is not updated. Whoops, there goes id.au. If you stuff up key management things go wrong. > > Your policy model make sense if you *start* doing DNSSEC > > during the bottom up development phase. >=20 > That is, imho, the phase we're getting into. And I'm writing code that will still be in use 10 years down the track. You want a default policy that will be out of date in 7 months for ORG. ORG will be in top-down by the end of the year. COM a little longer but not much. =20 > > If you start in > > the top down phase it doesn't and top down is the long term > > status. >=20 > By that time, this policy should be configurable, and eventually, the =20 > default can be changed on behalf on market demand. People need "trust the closest trust anchor only" policy now. People will never need "use any possible trust anchor" policy. It might be nice to have but it will never be a needed policy. Mark =20 > Kind regards, >=20 > Roy --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations ----- End forwarded message ----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 23 07:43:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93E93A6D21; Tue, 23 Jun 2009 07:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 1P0npI9c17g1; Tue, 23 Jun 2009 07:43:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F1D5C3A6BE1; Tue, 23 Jun 2009 07:43:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJ733-00097C-3c for namedroppers-data0@psg.com; Tue, 23 Jun 2009 14:32:33 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJ72r-00095t-V0 for namedroppers@ops.ietf.org; Tue, 23 Jun 2009 14:32:27 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 20A43E606E; Tue, 23 Jun 2009 14:32:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5NEWI8p086555; Wed, 24 Jun 2009 00:32:18 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906231432.n5NEWI8p086555@drugs.dv.isc.org> To: Francis Dupont Cc: "George Barwood" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Danger of coming unstuck In-reply-to: Your message of "Tue, 23 Jun 2009 15:21:53 +0200." <200906231321.n5NDLrtK014017@givry.fdupont.fr> Date: Wed, 24 Jun 2009 00:32:18 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <200906231321.n5NDLrtK014017@givry.fdupont.fr>, Francis Dupont write s: > PS: in conclusion if the DNSSEC stuff doesn't fit in the referral the TC > flag should be set, if the required glue doesn't fit in the referral the > TC flag should be set, if the server is caching/recursive the response > is not a referral and the TC will be set if there is no enough space. For the record named already does this. 1804. [bug] Ensure that if we are queried for glue that it fits in the additional section or TC is set to tell the client to retry using TCP. [RT #10114] BIND 9.2.6, 9.3.2, 9.4.0 Note: this does not help for the case of sibling glue. An argument could be made that you should never drop glue (manditory or sibling) and TC should be set if you need to for a referral. Glue is much more complicated than RFC 1034 would lead you to believe. RFC 1034 is clearly wrong when it says the only required glue is that which is below the delegation. Mark manditory: glue from beneath the delegation sibling: glue from beneath a sibling delegation -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 23 08:19:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4339B28C2FC; Tue, 23 Jun 2009 08:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id et6e8xtmK3jP; Tue, 23 Jun 2009 08:19:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5255F28C341; Tue, 23 Jun 2009 08:18:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJ7iO-000DY9-Tm for namedroppers-data0@psg.com; Tue, 23 Jun 2009 15:15:16 +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.69 (FreeBSD)) (envelope-from ) id 1MJ7i0-000DUK-Uv for namedroppers@ops.ietf.org; Tue, 23 Jun 2009 15:15:03 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n5NFEovQ014545; Tue, 23 Jun 2009 17:14:50 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200906231514.n5NFEovQ014545@givry.fdupont.fr> From: Francis Dupont To: "George Barwood" cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Danger of coming unstuck In-reply-to: Your message of Tue, 23 Jun 2009 15:03:28 BST. Date: Tue, 23 Jun 2009 17:14:50 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: Well I have tried my best to find what the spec says, I could not find anything very explicit, but there is this: http://tools.ietf.org/html/rfc4035#section-3.1.4 Including these DS, NSEC, and RRSIG RRs increases the size of referral messages and may cause some or all glue RRs to be omitted. If space does not permit inclusion of the DS or NSEC RRset and associated RRSIG RRs, the name server MUST set the TC bit (see Section 3.1.1). Here there is a fairly clear implication that glue RRs are omitted, without setting the TC bit, and this seems to be universal practice. => I agree but this applies only to not required glue RRs, so the issue is for necessary but not required glue RRs (i.e., which may be omitted (== not required) but are necessary to reach name servers). So this seems to be an unpleasant trap, and it's seems quite likely someone can fall into it one day. A child zone can be cut off from some resolvers, with no warning, when it's parent does a rollover that tips a referral over the limit. => if I disagree about the details I agree there is a real problem. IMHO the simplest solution is to set the TC bit but we have to be sure it is not a frequent case first... Regards Francis.Dupont@fdupont.fr -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 23 10:15:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E12D3A6949; Tue, 23 Jun 2009 10:15:35 -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 Mz1NOXnalLoq; Tue, 23 Jun 2009 10:15:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 598F53A6AE5; Tue, 23 Jun 2009 10:15:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJ9VR-000Msu-AH for namedroppers-data0@psg.com; Tue, 23 Jun 2009 17:10:01 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJ9VE-000MrL-O1 for namedroppers@ops.ietf.org; Tue, 23 Jun 2009 17:09:54 +0000 Received: from [10.31.200.183] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5NH9gGl031148; Tue, 23 Jun 2009 13:09:43 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> Date: Tue, 23 Jun 2009 13:04:37 -0400 To: Namedroppers Mailing List From: Edward Lewis Subject: Re: [dnsext] Nested trust anchors (again) Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 10:33 -0400 6/23/09, Matt Larson wrote: >This text was based on a namedroppers thread from early September 2008 >entitled "Proposed addition to dnssec-bis-updates: Nested Trust >Anchors". By my (and the dnssec-bis-editors') reckoning, "try all >trust anchors" was overwhelmingly the preferred option. (I just >re-read the entire thread.) I haven't re-read the thread but for the sake of robustness, trying any possible way to validate data is a good thing. OTOH, an implementation should make sure that the user is aware if they have nested trust anchors, in an effort to limit stale anchors inviting attacks using past private keys gone public. >Now, of course, dnssec-bis-updates isn't final, but last September's >discussion looks pretty clear to me. Since we are apparently still >discussing this topic, I wanted to point out the nested trust anchor >text in dnssec-bis-updates so there are no surprises at last call. > >It would sure be nice to see BIND change its default behavior to "try >all trust anchors" and make "trust the closest trust anchor" a >configurable option. With the caveat that this WG isn't the right vehicle to bring about change in a specific implementation, and trying to generalize my recommendation: A validator should try all possible trust anchors and try all possible signature chains to find one that "works." At this point the answer should be considered valid. Recall that the bar in DNSSEC isn't the accuracy of the data but the accuracy of the delivery of the data. A trusted anchor module should make every attempt to limit the presence of stale data hanging around. This is weasel-ly worded because I don't have a clear mechanism for this in my own head. Perhaps this means 5011 support or something like root zone hints priming. (Yadda, yadda, yadda...) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From emotionally1@litominas.com.br Tue Jun 23 11:12:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4357D28C3F1; Tue, 23 Jun 2009 11:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -53.907 X-Spam-Level: X-Spam-Status: No, score=-53.907 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, GB_OPRAH=2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_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 UxW6D1JkYiEW; Tue, 23 Jun 2009 11:12:23 -0700 (PDT) Received: from pool-173-76-209-148.bstnma.fios.verizon.net (pool-173-76-209-148.bstnma.fios.verizon.net [173.76.209.148]) by core3.amsl.com (Postfix) with ESMTP id 37A9E28C3E3; Tue, 23 Jun 2009 11:12:21 -0700 (PDT) Message-ID: <000d01c9f42e$1d6ee690$6400a8c0@emotionally1> From: dnsext-archive@lists.ietf.org To: Subject: Exceptionnaly sweet and totally advanced formula will have you looking great. Date: Tue, 23 Jun 2009 14:12:05 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F42E.1D6EE690" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F42E.1D6EE690 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Oprah Is an Acai Berry Success story.   We are waiting =A0 Get The power of Acai working for you. =20 =A0 Visit here =A0 =A0 best ragards England ------=_NextPart_000_0007_01C9F42E.1D6EE690 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Oprah Is an Acai Berry Success story.
 
We are waiting
=A0
Get The power of Acai working for you. <= /FONT>
=A0
=A0
=A0
best ragards England
------=_NextPart_000_0007_01C9F42E.1D6EE690-- From mudw50@secsup.com Tue Jun 23 12:21:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A66A3A6EDD; Tue, 23 Jun 2009 12:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.764 X-Spam-Level: X-Spam-Status: No, score=-32.764 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, 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, FS_START_LOSE=1.493, HELO_DYNAMIC_IPADDR2=4.395, HS_INDEX_PARAM=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, SUBJECT_DIET=1.466, TVD_RCVD_IP=1.931, 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 ZZFzdFXzo-Cu; Tue, 23 Jun 2009 12:21:01 -0700 (PDT) Received: from 201-212-52-201.cab.prima.net.ar (201-212-52-201.cab.prima.net.ar [201.212.52.201]) by core3.amsl.com (Postfix) with ESMTP id 2B2FA3A6EB5; Tue, 23 Jun 2009 12:20:49 -0700 (PDT) Received: from 201.212.52.201 by mail.ops-netman.net; Tue, 23 Jun 2009 16:20:57 -0300 Date: Tue, 23 Jun 2009 16:20:57 -0300 From: dnsext-archive@lists.ietf.org Subject: Lose weight fast with the world's #1 acai berry Free Trial To: Message-ID: <000d01c9f437$bc6739b0$6400a8c0@mudw50> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-2; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Your Health is what counts. Haste to come http://www.metrejaksel.in/?rgmeemumyd best regards Dewayne Hanna From mexicalit@polyloop.net Tue Jun 23 12:22:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A223A6ED6; Tue, 23 Jun 2009 12:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.092 X-Spam-Level: X-Spam-Status: No, score=-20.092 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_CHARTER=2.175, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_CHARTER=1.295, HOST_EQ_DHCP=1.295, HS_INDEX_PARAM=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001, TVD_RCVD_IP=1.931, 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 ls2DxozEwGqb; Tue, 23 Jun 2009 12:22:07 -0700 (PDT) Received: from 66-191-229-62.dhcp.kgpt.tn.charter.com (66-191-229-62.dhcp.kgpt.tn.charter.com [66.191.229.62]) by core3.amsl.com (Postfix) with ESMTP id 151163A6EB5; Tue, 23 Jun 2009 12:22:06 -0700 (PDT) Received: from 66.191.229.62 by mail.polyloop.net; Tue, 23 Jun 2009 15:22:04 -0500 Date: Tue, 23 Jun 2009 15:22:04 -0500 From: disman-bounces@ietf.org Subject: Discover the magical powers of the Acai Fruit. To: Message-ID: <000d01c9f437$e43dbe00$6400a8c0@mexicalit> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal FIght cancer daily , by just adding Acai Berry to your diet. One click is enough http://www.metrejaksel.in/?rgmeemumyd best regards Lee Hendrickson From unattributedg29@safeboats.com Tue Jun 23 17:40:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15C128C407; Tue, 23 Jun 2009 17:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -51.772 X-Spam-Level: X-Spam-Status: No, score=-51.772 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=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, FS_WEIGHT_LOSS=2.134, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 z0YKtkaCoMMb; Tue, 23 Jun 2009 17:40:43 -0700 (PDT) Received: from 187-25-48-166.3g.claro.net.br (187-25-48-166.3g.claro.net.br [187.25.48.166]) by core3.amsl.com (Postfix) with ESMTP id 68F073A69F1; Tue, 23 Jun 2009 17:40:37 -0700 (PDT) Message-ID: <000d01c9f464$693c8290$6400a8c0@unattributedg29> From: dnsext-archive@lists.ietf.org To: Subject: Discover Acai Berry numerous weight loss and health benefits. Date: Tue, 23 Jun 2009 20:40:45 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F464.693C8290" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F464.693C8290 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 Unable to view this=20 newsletter? =20 =20   =20 =20 =20 =20 =20 =20 Burn fat quick with Acai Berry. =20 =20 =20 Just one move to visit =20 Copyright 2009=20 Emgj Visit us at our site =20 =20 Member=20 Profile=A0 Privacy=A0 Subscribe=A0 Unsubscribe =A0 ------=_NextPart_000_0007_01C9F464.693C8290 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Unable to view this=20 newsletter?
 
<= /TR>
Burn fat quick with Acai Berry.

Just one move t= o visit
Copyright = 2009=20 Emgj Visit us at our site
Member=20 Profile=A0 Privacy=A0 = Subscribe=A0= Unsubscribe=
=A0
------=_NextPart_000_0007_01C9F464.693C8290-- From futonsd3@sanatorio9dejuliosa.com.ar Tue Jun 23 21:52:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA8028C338; Tue, 23 Jun 2009 21:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.029 X-Spam-Level: X-Spam-Status: No, score=-54.029 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=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, FS_START_LOSE=1.493, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_DIET=1.466, URIBL_SBL=20, URI_NOVOWEL=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPg00SlBmNSM; Tue, 23 Jun 2009 21:52:47 -0700 (PDT) Received: from c-98-215-240-144.hsd1.il.comcast.net (c-98-215-240-144.hsd1.il.comcast.net [98.215.240.144]) by core3.amsl.com (Postfix) with ESMTP id 7CE4E3A6901; Tue, 23 Jun 2009 21:52:46 -0700 (PDT) Message-ID: <000d01c9f487$976068d0$6400a8c0@futonsd3> From: dnsext-archive@lists.ietf.org To: Subject: Lose weight without starving yourself Acai Berry, get your trial Now. Date: Tue, 23 Jun 2009 23:52:35 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F487.976068D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F487.976068D0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 =20 Unable to view this=20 newsletter? =20 =20   =20 =20 =20 =20 =20 =20 Losing weight is easy with Acai Berry. =20 =20 =20 Click doubtless =20 Copyright 2009=20 Eeke Visit us at our site =20 =20 Member=20 Profile=A0 Privacy=A0 Subscribe=A0 Unsubscribe =A0 ------=_NextPart_000_0007_01C9F487.976068D0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Unable to view this=20 newsletter?
 
Losing weight is easy with Acai Berry.
Click doubtle= ss
Copyright = 2009=20 Eeke Visit us at our site
Member=20 Profile=A0 Privacy=A0 = Subscribe=A0= Unsubscribe=
=A0
------=_NextPart_000_0007_01C9F487.976068D0-- From owner-namedroppers@ops.ietf.org Tue Jun 23 23:17:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D263A6859; Tue, 23 Jun 2009 23:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 jaH7KhEpHqV7; Tue, 23 Jun 2009 23:17:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 96E1028C440; Tue, 23 Jun 2009 23:17:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJLjb-000Lo4-Pd for namedroppers-data0@psg.com; Wed, 24 Jun 2009 06:13:27 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJLjQ-000LnH-EI for namedroppers@ops.ietf.org; Wed, 24 Jun 2009 06:13:21 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 0362BE6097; Wed, 24 Jun 2009 06:13:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5O6D9ro099793; Wed, 24 Jun 2009 16:13:11 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906240613.n5O6D9ro099793@drugs.dv.isc.org> To: "George Barwood" Cc: "Francis Dupont" , "Mark Andrews" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Danger of coming unstuck In-reply-to: Your message of "Wed, 24 Jun 2009 06:10:26 +0100." <83C433523C814BD994275B1650CB75AA@localhost> Date: Wed, 24 Jun 2009 16:13:09 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <83C433523C814BD994275B1650CB75AA@localhost>, "George Barwood" write s: > ----- Original Message ----- > From: "Mark Andrews" > To: "Francis Dupont" > Cc: "George Barwood" ; > Sent: Tuesday, June 23, 2009 3:32 PM > Subject: Re: [dnsext] Danger of coming unstuck > > > > For the record named already does this. > > > > 1804. [bug] Ensure that if we are queried for glue that it fits > > in the additional section or TC is set to tell the > > client to retry using TCP. [RT #10114] > > > > BIND 9.2.6, 9.3.2, 9.4.0 > > Thanks for this, that helps considerably. > > There still seem to be conflicting requirements here though. > > For example, for the non-DNSSEC query > > dig net @a.root-servers.net Which isn't a realist query. Add another label and you start loosing addresses. dig lkkasdh.net @a.root-servers.net > we do not want to set TC ( the response with all required/necessary glue included does not fit in 512 bytes ). > [ Note: RFC 1034 uses necessary, RFC 1035 uses required, I assume no distinction was intended ] > > So the question arises, how much glue is enough? How many name servers are enough? The requirement is not to get a resolution deadlock. The only way to ensure that is to return all the potential glue (addresses for names under the delegating zone). > I don't think the standard needs to be 100% prescriptive here, > but it ought to indicate the pitfalls. Since falling back to TCP > is undesirable and quite likely to fail in practice, TCP works in practice. There are only rare failures. > I think reasonable efforts should be made to avoid this where > possible, both on the resolver and server side. Which basically has been done. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 23 23:56:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4FC28C45F; Tue, 23 Jun 2009 23:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.975 X-Spam-Level: **** X-Spam-Status: No, score=4.975 tagged_above=-999 required=5 tests=[AWL=1.080, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwzD7-2GL0A4; Tue, 23 Jun 2009 23:56:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3126C28C440; Tue, 23 Jun 2009 23:56:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJMLx-000OkV-Fp for namedroppers-data0@psg.com; Wed, 24 Jun 2009 06:53:05 +0000 Received: from [195.188.213.6] (helo=smtp-out3.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJMLm-000OjL-7y for namedroppers@ops.ietf.org; Wed, 24 Jun 2009 06:52:59 +0000 Received: from [172.23.170.142] (helo=anti-virus02-09) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1MJMLi-0005cg-If; Wed, 24 Jun 2009 07:52:50 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1MJMLi-000516-14; Wed, 24 Jun 2009 07:52:50 +0100 Message-ID: From: "George Barwood" To: "Mark Andrews" Cc: "Francis Dupont" , "Mark Andrews" , References: <200906240613.n5O6D9ro099793@drugs.dv.isc.org> Subject: Re: [dnsext] Danger of coming unstuck Date: Wed, 24 Jun 2009 07:52:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmsgQW5kcmV3cyIgPG1h cmthQGlzYy5vcmc+DQpUbzogIkdlb3JnZSBCYXJ3b29kIiA8Z2VvcmdlLmJhcndvb2RAYmx1ZXlv bmRlci5jby51az4NCkNjOiAiRnJhbmNpcyBEdXBvbnQiIDxGcmFuY2lzLkR1cG9udEBmZHVwb250 LmZyPjsgIk1hcmsgQW5kcmV3cyIgPG1hcmthQGlzYy5vcmc+OyA8bmFtZWRyb3BwZXJzQG9wcy5p ZXRmLm9yZz4NClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyNCwgMjAwOSA3OjEzIEFNDQpTdWJqZWN0 OiBSZTogW2Ruc2V4dF0gRGFuZ2VyIG9mIGNvbWluZyB1bnN0dWNrIA0KDQoNCj4gDQo+IEluIG1l c3NhZ2UgPDgzQzQzMzUyM0M4MTRCRDk5NDI3NUIxNjUwQ0I3NUFBQGxvY2FsaG9zdD4sICJHZW9y Z2UgQmFyd29vZCIgd3JpdGUNCj4gczoNCj4+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQo+PiBGcm9tOiAiTWFyayBBbmRyZXdzIiA8bWFya2FAaXNjLm9yZz4NCj4+IFRvOiAiRnJhbmNp cyBEdXBvbnQiIDxGcmFuY2lzLkR1cG9udEBmZHVwb250LmZyPg0KPj4gQ2M6ICJHZW9yZ2UgQmFy d29vZCIgPGdlb3JnZS5iYXJ3b29kQGJsdWV5b25kZXIuY28udWs+OyA8bmFtZWRyb3BwZXJzQG9w cy5pZXRmLm9yZz4NCj4+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMjMsIDIwMDkgMzozMiBQTQ0KPj4g U3ViamVjdDogUmU6IFtkbnNleHRdIERhbmdlciBvZiBjb21pbmcgdW5zdHVjayANCj4+IA0KPj4g DQo+PiA+IEZvciB0aGUgcmVjb3JkIG5hbWVkIGFscmVhZHkgZG9lcyB0aGlzLg0KPj4gPiANCj4+ ID4gMTgwNC4gICBbYnVnXSAgICAgICAgICAgRW5zdXJlIHRoYXQgaWYgd2UgYXJlIHF1ZXJpZWQg Zm9yIGdsdWUgdGhhdCBpdCBmaXRzDQo+PiA+ICAgICAgICAgICAgICAgICAgICAgICAgaW4gdGhl IGFkZGl0aW9uYWwgc2VjdGlvbiBvciBUQyBpcyBzZXQgdG8gdGVsbCB0aGUNCj4+ID4gICAgICAg ICAgICAgICAgICAgICAgICBjbGllbnQgdG8gcmV0cnkgdXNpbmcgVENQLiBbUlQgIzEwMTE0XQ0K Pj4gPiANCj4+ID4gQklORCA5LjIuNiwgOS4zLjIsIDkuNC4wDQo+PiANCj4+IFRoYW5rcyBmb3Ig dGhpcywgdGhhdCBoZWxwcyBjb25zaWRlcmFibHkuDQo+PiANCj4+IFRoZXJlIHN0aWxsIHNlZW0g dG8gYmUgY29uZmxpY3RpbmcgcmVxdWlyZW1lbnRzIGhlcmUgdGhvdWdoLg0KPj4gDQo+PiBGb3Ig ZXhhbXBsZSwgZm9yIHRoZSBub24tRE5TU0VDIHF1ZXJ5DQo+PiANCj4+IGRpZyBuZXQgQGEucm9v dC1zZXJ2ZXJzLm5ldA0KPiANCj4gV2hpY2ggaXNuJ3QgYSByZWFsaXN0IHF1ZXJ5LiAgQWRkIGFu b3RoZXIgbGFiZWwgYW5kIHlvdQ0KPiBzdGFydCBsb29zaW5nIGFkZHJlc3Nlcy4NCg0KSWYgeW91 IHVzZSArZWRucz0wLCB5b3UgY2FuIHNlZSB0aGF0IGFkZHJlc3NlcyBoYXZlIGFscmVhZHkgYmVl biBsb3N0Lg0KVGhhdCdzIHRoZSBwb2ludCBvZiB0aGUgZXhhbXBsZSByZWFsbHkgKCBmdWxsIHJl c3BvbnNlIHNpemUgaXMgNTE3IGJ5dGVzICkuDQoNCkFsc28gSSB0aGluayBpdCBpcyByZWFsaXN0 aWMsIGEgZ29vZCByZXNvbHZlciB3aWxsIEkgc3VnZ2VzdCBrZWVwIHRoZSBxdWVzdGlvbiBzaG9y dCBmb3IgVExEcy4NClRoYXQgaGVscHMuDQoNCj4gZGlnIGxra2FzZGgubmV0IEBhLnJvb3Qtc2Vy dmVycy5uZXQNCj4gDQo+PiB3ZSBkbyBub3Qgd2FudCB0byBzZXQgVEMgKCB0aGUgcmVzcG9uc2Ug d2l0aCBhbGwgcmVxdWlyZWQvbmVjZXNzYXJ5IGdsdWUgaW5jbHVkZWQgZG9lcyBub3QgZml0IGlu IDUxMiBieXRlcyApLg0KPj4gWyBOb3RlOiBSRkMgMTAzNCB1c2VzIG5lY2Vzc2FyeSwgUkZDIDEw MzUgdXNlcyByZXF1aXJlZCwgSSBhc3N1bWUgbm8gZGlzdGluY3Rpb24gd2FzIGludGVuZGVkIF0N Cj4+IA0KPj4gU28gdGhlIHF1ZXN0aW9uIGFyaXNlcywgaG93IG11Y2ggZ2x1ZSBpcyBlbm91Z2g/ IEhvdyBtYW55IG5hbWUgc2VydmVycyBhcmUgZW5vdWdoPw0KPiANCj4gVGhlIHJlcXVpcmVtZW50 IGlzIG5vdCB0byBnZXQgYSByZXNvbHV0aW9uIGRlYWRsb2NrLiAgVGhlDQo+IG9ubHkgd2F5IHRv IGVuc3VyZSB0aGF0IGlzIHRvIHJldHVybiBhbGwgdGhlIHBvdGVudGlhbCBnbHVlDQo+IChhZGRy ZXNzZXMgZm9yIG5hbWVzIHVuZGVyIHRoZSBkZWxlZ2F0aW5nIHpvbmUpLg0KDQpIbW0uLi4gd2Vs bCBJIG5lZWQgdG8gdGhpbmsgYWJvdXQgdGhhdCwgYnV0IEknbSBub3QgY29udmluY2VkLg0KRm9y IGV4YW1wbGUgSSBzdXNwZWN0IHJldHVybmluZyBhIHJhbmRvbSBzdWJzZXQgb2YgNCBnbHVlIHJl Y29yZHMgaXMgZ29vZCBlbm91Z2gsDQphbmQgcHJlZmVyYWJsZSB0byBUQ1AgZmFsbGJhY2tzLiBC dXQgdGhpcyBuZWVkcyB0aG91Z2h0Lg0KIA0KPj4gSSBkb24ndCB0aGluayB0aGUgc3RhbmRhcmQg bmVlZHMgdG8gYmUgMTAwJSBwcmVzY3JpcHRpdmUgaGVyZSwNCj4+IGJ1dCBpdCBvdWdodCB0byBp bmRpY2F0ZSB0aGUgcGl0ZmFsbHMuICBTaW5jZSBmYWxsaW5nIGJhY2sgdG8gVENQDQo+PiBpcyB1 bmRlc2lyYWJsZSBhbmQgcXVpdGUgbGlrZWx5IHRvIGZhaWwgaW4gcHJhY3RpY2UsDQo+IA0KPiBU Q1Agd29ya3MgaW4gcHJhY3RpY2UuICBUaGVyZSBhcmUgb25seSByYXJlIGZhaWx1cmVzLg0KDQpN YXliZSBpZiB5b3UgYXJlIGluIHRoZSBVU0Egd2l0aCBnb29kIGNvbm5lY3Rpb25zLg0KSSBmcmVx dWVudGx5IGNhbm5vdCBnZXQgYSBUQ1AgY29ubmVjdGlvbiB0byAub3JnIHNlcnZlcnMsIGZvciBl eGFtcGxlLg0KSSBndWVzcyBVRFAoLzUzPykgcGFja2V0cyB0ZW5kIHRvIGdldCBwcmlvcml0aXpl ZCBieSBuZXR3b3JrcyAoIG5vdCBteSBleHBlcnRpc2UgdGhvdWdoICkuDQogDQo+PiBJIHRoaW5r IHJlYXNvbmFibGUgZWZmb3J0cyBzaG91bGQgYmUgbWFkZSB0byBhdm9pZCB0aGlzIHdoZXJlDQo+ PiBwb3NzaWJsZSwgYm90aCBvbiB0aGUgcmVzb2x2ZXIgYW5kIHNlcnZlciBzaWRlLg0KPiANCj4g V2hpY2ggYmFzaWNhbGx5IGhhcyBiZWVuIGRvbmUuDQoNCk1heWJlLCBidXQgSSB0aGluayBmdXJ0 aGVyIHRob3VnaHQsIGVzcGVjaWFsbHkgaW4gbGlnaHQgb2YgQklORCBANTEyLCBtYXkgYmUgd29y dGh3aGlsZS4NCg0KPiBNYXJrDQo+IC0tIA0KPiBNYXJrIEFuZHJld3MsIElTQw0KPiAxIFNleW1v dXIgU3QuLCBEdW5kYXMgVmFsbGV5LCBOU1cgMjExNywgQXVzdHJhbGlhDQo+IFBIT05FOiArNjEg MiA5ODcxIDQ3NDIgICAgICAgICAgICAgICAgIElOVEVSTkVUOiBtYXJrYUBpc2Mub3JnDQo+ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 24 01:41:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F98C3A6A87; Wed, 24 Jun 2009 01:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 XWbcGkHTAw7H; Wed, 24 Jun 2009 01:41:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 919DB28C360; Wed, 24 Jun 2009 01:41:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJNyC-0006L2-Gk for namedroppers-data0@psg.com; Wed, 24 Jun 2009 08:36:40 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJNy1-0006K4-0j for namedroppers@ops.ietf.org; Wed, 24 Jun 2009 08:36:34 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 7EB49E607B; Wed, 24 Jun 2009 08:36:27 +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 n5O8aMAW000739; Wed, 24 Jun 2009 18:36:24 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906240836.n5O8aMAW000739@drugs.dv.isc.org> To: "George Barwood" Cc: "Mark Andrews" , "Francis Dupont" , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Danger of coming unstuck In-reply-to: Your message of "Wed, 24 Jun 2009 07:52:43 +0100." Date: Wed, 24 Jun 2009 18:36:22 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , "George Barwood" write s: > > ----- Original Message ----- > From: "Mark Andrews" > To: "George Barwood" > Cc: "Francis Dupont" ; "Mark Andrews" ; > Sent: Wednesday, June 24, 2009 7:13 AM > Subject: Re: [dnsext] Danger of coming unstuck > > > > > > In message <83C433523C814BD994275B1650CB75AA@localhost>, "George Barwood" write > > s: > >> ----- Original Message ----- > >> From: "Mark Andrews" > >> To: "Francis Dupont" > >> Cc: "George Barwood" ; > >> Sent: Tuesday, June 23, 2009 3:32 PM > >> Subject: Re: [dnsext] Danger of coming unstuck > >> > >> > >> > For the record named already does this. > >> > > >> > 1804. [bug] Ensure that if we are queried for glue that it fits > >> > in the additional section or TC is set to tell the > >> > client to retry using TCP. [RT #10114] > >> > > >> > BIND 9.2.6, 9.3.2, 9.4.0 > >> > >> Thanks for this, that helps considerably. > >> > >> There still seem to be conflicting requirements here though. > >> > >> For example, for the non-DNSSEC query > >> > >> dig net @a.root-servers.net > > > > Which isn't a realist query. Add another label and you > > start loosing addresses. > > If you use +edns=0, you can see that addresses have already been lost. > That's the point of the example really ( full response size is 517 bytes ). > > Also I think it is realistic, a good resolver will I suggest keep the > question short for TLDs. > That helps. > > > dig lkkasdh.net @a.root-servers.net > > > >> we do not want to set TC ( the response with all required/necessary glue included does not fit in 512 bytes ). > >> [ Note: RFC 1034 uses necessary, RFC 1035 uses required, I assume no distinction was intended ] > >> > >> So the question arises, how much glue is enough? How many name servers are enough? > > > > The requirement is not to get a resolution deadlock. The > > only way to ensure that is to return all the potential glue > > (addresses for names under the delegating zone). > > Hmm... well I need to think about that, but I'm not convinced. > For example I suspect returning a random subset of 4 glue records is > good enough, and preferable to TCP fallbacks. But this needs thought. > > >> I don't think the standard needs to be 100% prescriptive here, > >> but it ought to indicate the pitfalls. Since falling back to TCP > >> is undesirable and quite likely to fail in practice, > > > > TCP works in practice. There are only rare failures. > > Maybe if you are in the USA with good connections. I'm not in the US. > I frequently cannot get a TCP connection to .org servers, for example. > I guess UDP(/53?) packets tend to get prioritized by networks > (not my expertise though ). I would suggest that you look at your own network. It's not the general case. > >> I think reasonable efforts should be made to avoid this where > >> possible, both on the resolver and server side. > > > > Which basically has been done. > > Maybe, but I think further thought, especially in light of BIND @512, > may be worthwhile. Plain DNS is the exception not the rule these days. EDNS@512 is the exception not the rule. Mark > > Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 24 01:54:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91CC83A6ABD; Wed, 24 Jun 2009 01:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DdKEw-Hn9yY; Wed, 24 Jun 2009 01:54:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 43AC13A69CB; Wed, 24 Jun 2009 01:54:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJOBx-0007PF-I4 for namedroppers-data0@psg.com; Wed, 24 Jun 2009 08:50:53 +0000 Received: from [195.1.209.33] (helo=bizet.nethelp.no) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJOBl-0007Nz-Sp for namedroppers@ops.ietf.org; Wed, 24 Jun 2009 08:50:47 +0000 Received: (qmail 62320 invoked from network); 24 Jun 2009 08:50:37 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 24 Jun 2009 08:50:37 -0000 Date: Wed, 24 Jun 2009 10:50:37 +0200 (CEST) Message-Id: <20090624.105037.74726950.sthaug@nethelp.no> To: george.barwood@blueyonder.co.uk Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Danger of coming unstuck From: sthaug@nethelp.no In-Reply-To: References: <200906240613.n5O6D9ro099793@drugs.dv.isc.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > I frequently cannot get a TCP connection to .org servers, for example. > I guess UDP(/53?) packets tend to get prioritized by networks ( not my expertise though ). "Tend to get prioritized by networks"? Hardly. In most networks UDP packets are treated just like any other IP packets - i.e. best effort. Steinar Haug, Nethelp consulting, sthaug@nethelp.no -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 24 08:09:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA653A6A37; Wed, 24 Jun 2009 08:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 BjfKkQGK4Ido; Wed, 24 Jun 2009 08:09:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FD4A3A68A0; Wed, 24 Jun 2009 08:09:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJU0n-000Ahs-7U for namedroppers-data0@psg.com; Wed, 24 Jun 2009 15:03:45 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJU0a-000AhN-Cy for namedroppers@ops.ietf.org; Wed, 24 Jun 2009 15:03:38 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0B4A8A6CC2; Wed, 24 Jun 2009 15:03:32 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: sthaug@nethelp.no cc: george.barwood@blueyonder.co.uk, namedroppers@ops.ietf.org Subject: Re: [dnsext] Danger of coming unstuck In-Reply-To: Your message of "Wed, 24 Jun 2009 10:50:37 +0200." <20090624.105037.74726950.sthaug@nethelp.no> References: <200906240613.n5O6D9ro099793@drugs.dv.isc.org> <20090624.105037.74726950.sthaug@nethelp.no> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 24 Jun 2009 15:03:32 +0000 Message-ID: <5941.1245855812@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Wed, 24 Jun 2009 10:50:37 +0200 (CEST) > From: sthaug@nethelp.no > > "Tend to get prioritized by networks"? Hardly. In most networks UDP > packets are treated just like any other IP packets - i.e. best effort. i wish that were the case. udp/53 gets rampantly monetized by middleboxes to a degree far beyond that of any other kind of IP packet. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 24 08:09:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA693A6403; Wed, 24 Jun 2009 08:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 t1Vmt9pO3ihc; Wed, 24 Jun 2009 08:09:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 208AD3A68E4; Wed, 24 Jun 2009 08:09:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJTzV-000Acb-D6 for namedroppers-data0@psg.com; Wed, 24 Jun 2009 15:02: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.69 (FreeBSD)) (envelope-from ) id 1MJTz9-000AbA-O7 for namedroppers@ops.ietf.org; Wed, 24 Jun 2009 15:02:10 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 51E6AA6CBC for ; Wed, 24 Jun 2009 15:02:03 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Danger of coming unstuck In-Reply-To: Your message of "Wed, 24 Jun 2009 18:36:22 +1000." <200906240836.n5O8aMAW000739@drugs.dv.isc.org> References: <200906240836.n5O8aMAW000739@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Wed, 24 Jun 2009 15:02:03 +0000 Message-ID: <5893.1245855723@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Mark Andrews > Date: Wed, 24 Jun 2009 18:36:22 +1000 > > Plain DNS is the exception not the rule these days. EDNS@512 > is the exception not the rule. can we do some measurement and analysis, to prove (or not) that assertion? for example, ISC SIE sees ~50Mbit/sec of DNS response traffic now. can we extract out the EDNS information from a few hours of data to find out what is actually working? or if that's too narrow, can someone write a perl or awk script and post it here so that a lot of folks can all run tcpdump on busy recursive nameservers and extract out the information needed? duane wessels of OARC, i'm looking at *you*. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From apheliaxvp07@lastminute.com.hk Wed Jun 24 08:56:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EA313A6C5B; Wed, 24 Jun 2009 08:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.074 X-Spam-Level: X-Spam-Status: No, score=-75.074 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=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_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08g1qLaCRUIP; Wed, 24 Jun 2009 08:56:57 -0700 (PDT) Received: from r190-64-144-139.dialup.adsl.anteldata.net.uy (r190-64-144-139.dialup.adsl.anteldata.net.uy [190.64.144.139]) by core3.amsl.com (Postfix) with ESMTP id 820363A6F9F; Wed, 24 Jun 2009 08:56:55 -0700 (PDT) Message-ID: <000d01c9f4e4$4e377d30$6400a8c0@apheliaxvp07> From: diffserv-interest@ietf.org To: Subject: Losing weight is an amazing feeling. Date: Wed, 24 Jun 2009 12:56:15 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F4E4.4E377D30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F4E4.4E377D30 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Improve your digestive system with Acai Berry.   Click immediately =A0 Losing weight has never been easier. =A0 Just press the button =A0 =A0 best ragards Harris ------=_NextPart_000_0007_01C9F4E4.4E377D30 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Improve your digestive system with Acai B= erry.
 
=A0
Losing weight has never been easier.
=A0
=A0
=A0
best ragards Harris
------=_NextPart_000_0007_01C9F4E4.4E377D30-- From remitd@tie.com.br Wed Jun 24 09:25:33 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 982B83A6FB0; Wed, 24 Jun 2009 09:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.829 X-Spam-Level: X-Spam-Status: No, score=-75.829 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-3PlDqxuNRU; Wed, 24 Jun 2009 09:25:32 -0700 (PDT) Received: from pool-71-250-67-153.nwrknj.east.verizon.net (pool-71-250-67-153.nwrknj.east.verizon.net [71.250.67.153]) by core3.amsl.com (Postfix) with ESMTP id 52F2C3A6813; Wed, 24 Jun 2009 09:25:32 -0700 (PDT) Message-ID: <000d01c9f4e8$48d999a0$6400a8c0@remitd> From: emu-request@ietf.org To: Subject: Acai berry will allow you to lose your undesired wieght. Date: Wed, 24 Jun 2009 12:24:44 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F4E8.48D999A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F4E8.48D999A0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Get your healthy lifetyle now.   We welcome you here =A0 energize , shed pounds rapidly with Acai Berry.=20 =A0 Enter here =A0 =A0 best ragards Stafford ------=_NextPart_000_0007_01C9F4E8.48D999A0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Get your healthy lifetyle now.
 
We welcome you here
=A0
energize , shed pounds rapidly with Acai = Berry.
=A0
=A0
=A0
best ragards Stafford
<= /HTML> ------=_NextPart_000_0007_01C9F4E8.48D999A0-- From morsel16@totallywebbed.com Wed Jun 24 11:40:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1963E28C4EE; Wed, 24 Jun 2009 11:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.248 X-Spam-Level: X-Spam-Status: No, score=-78.248 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FS_START_LOSE=1.493, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFpMQUSuRyeG; Wed, 24 Jun 2009 11:40:06 -0700 (PDT) Received: from cpc3-colc5-0-0-cust59.colc.cable.ntl.com (cpc3-colc5-0-0-cust59.colc.cable.ntl.com [82.31.204.60]) by core3.amsl.com (Postfix) with ESMTP id DEF0128C4D8; Wed, 24 Jun 2009 11:40:05 -0700 (PDT) Message-ID: <000d01c9f4fa$b35d3040$6400a8c0@morsel16> From: dnsext-archive@lists.ietf.org To: Subject: Lose wieght without starvation , Try Acai Berry. Date: Wed, 24 Jun 2009 19:36:34 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F4FA.B35D3040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F4FA.B35D3040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Effective Way To Help Aid in Weight Loss - Our Top Choice Burn fat quick with Acai Berry.   Quickly click =A0 =A0 Thank You!=20 best regards Bennett=20 Warner ------=_NextPart_000_0007_01C9F4FA.B35D3040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Effective Way To Help Aid in Weight Loss - Our Top Choice
Burn fat quick with Acai Berry.
 
Quickly click
=A0
=A0
Thank You!
best regards Bennett=20 Warner
------=_NextPart_000_0007_01C9F4FA.B35D3040-- From owner-namedroppers@ops.ietf.org Wed Jun 24 16:19:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BC593A6889; Wed, 24 Jun 2009 16:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 4W6Z9YKiUgCN; Wed, 24 Jun 2009 16:19:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 32A853A6D83; Wed, 24 Jun 2009 16:18:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJbdC-000Kec-4G for namedroppers-data0@psg.com; Wed, 24 Jun 2009 23:11:54 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJbcz-000KdK-Nn for namedroppers@ops.ietf.org; Wed, 24 Jun 2009 23:11:48 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id D8FC1E607B; Wed, 24 Jun 2009 23:11:40 +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 n5ONBane012297; Thu, 25 Jun 2009 09:11:36 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906242311.n5ONBane012297@drugs.dv.isc.org> To: Paul Vixie Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Danger of coming unstuck In-reply-to: Your message of "Wed, 24 Jun 2009 15:02:03 GMT." <5893.1245855723@nsa.vix.com> Date: Thu, 25 Jun 2009 09:11:35 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <5893.1245855723@nsa.vix.com>, Paul Vixie writes: > > From: Mark Andrews > > Date: Wed, 24 Jun 2009 18:36:22 +1000 > > > > Plain DNS is the exception not the rule these days. EDNS@512 > > is the exception not the rule. > > can we do some measurement and analysis, to prove (or not) that assertion? Well for iterative traffic it is. Recursive traffic is still mostly plain DNS but recursive traffic doesn't need additional data. Adding "options edns0" to resolv.conf works for the latter but it is not the default. Mark > for example, ISC SIE sees ~50Mbit/sec of DNS response traffic now. can we > extract out the EDNS information from a few hours of data to find out what > is actually working? or if that's too narrow, can someone write a perl or > awk script and post it here so that a lot of folks can all run tcpdump on > busy recursive nameservers and extract out the information needed? duane > wessels of OARC, i'm looking at *you*. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 24 19:29:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1C328C16F; Wed, 24 Jun 2009 19:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 UHqAB4Lmvqxt; Wed, 24 Jun 2009 19:29:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 598B428C150; Wed, 24 Jun 2009 19:29:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJecc-00073R-2u for namedroppers-data0@psg.com; Thu, 25 Jun 2009 02:23:30 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJecP-00072W-4O for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 02:23:23 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 33791A6D87; Thu, 25 Jun 2009 02:23:16 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Mark Andrews cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Danger of coming unstuck In-Reply-To: Your message of "Thu, 25 Jun 2009 09:11:35 +1000." <200906242311.n5ONBane012297@drugs.dv.isc.org> References: <200906242311.n5ONBane012297@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 25 Jun 2009 02:23:16 +0000 Message-ID: <35962.1245896596@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Mark Andrews > Date: Thu, 25 Jun 2009 09:11:35 +1000 > > > > Plain DNS is the exception not the rule these days. EDNS@512 is > > > the exception not the rule. > > > > can we do some measurement and analysis, to prove (or not) that > > assertion? > > Well for iterative traffic it is. i repeat: show me. > Recursive traffic is still mostly plain DNS but recursive > traffic doesn't need additional data. > > Adding "options edns0" to resolv.conf works for the latter > but it is not the default. where are the reproduceable test results that underlay these assertions? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 24 20:24:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092473A6818; Wed, 24 Jun 2009 20:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 KgAriKtUx8MY; Wed, 24 Jun 2009 20:24:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6DDD23A67F1; Wed, 24 Jun 2009 20:24:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJfV7-000Ap8-S0 for namedroppers-data0@psg.com; Thu, 25 Jun 2009 03:19:49 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJfUw-000AoK-QV for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 03:19:44 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 386D3E601C; Thu, 25 Jun 2009 03:19:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5P3JSLw015341; Thu, 25 Jun 2009 13:19:28 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906250319.n5P3JSLw015341@drugs.dv.isc.org> To: Paul Vixie Cc: Mark Andrews , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Danger of coming unstuck In-reply-to: Your message of "Thu, 25 Jun 2009 02:23:16 GMT." <35962.1245896596@nsa.vix.com> Date: Thu, 25 Jun 2009 13:19:28 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <35962.1245896596@nsa.vix.com>, Paul Vixie writes: > > From: Mark Andrews > > Date: Thu, 25 Jun 2009 09:11:35 +1000 > > > > > > Plain DNS is the exception not the rule these days. EDNS@512 i > s > > > > the exception not the rule. > > > > > > can we do some measurement and analysis, to prove (or not) that > > > assertion? > > > > Well for iterative traffic it is. > > i repeat: show me. We have ~70% EDNS capable iterative clients (see the recent ORG analsyis). We have > 70% EDNS capable auth servers. Both of these figures are growing. This give a successful EDNS transaction > 50% of the time as it requires both ends to support EDNS. EDNS@512 only capable < 1% (again from recent ORG analsyis). > > Recursive traffic is still mostly plain DNS but recursive > > traffic doesn't need additional data. > > > > Adding "options edns0" to resolv.conf works for the latter > > but it is not the default. > > where are the reproduceable test results that underlay these assertions? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 24 23:19:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651703A6B44; Wed, 24 Jun 2009 23:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuegIuzIOJje; Wed, 24 Jun 2009 23:19:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 95B273A6827; Wed, 24 Jun 2009 23:18:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJiCd-000M6Q-UQ for namedroppers-data0@psg.com; Thu, 25 Jun 2009 06:12:55 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJiCQ-000M5L-UK; Thu, 25 Jun 2009 06:12:49 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=W0RR8LTfvdSnaoSln42+UrBxn0NnvCw66HSdvqkfEsfSAYQsZ0hW+vcW J2HK9K/YovIOost3j94dv7t7HtMWyoYMemTNqRJPURotEqawyX4jNj+Ny aIAmXSp0rxXhJB7; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1245910362; x=1277446362; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20Danger=20of=20coming=20unstuck|Date:=20Thu,=2025=20 Jun=202009=2007:12:34=20+0100|Message-ID:=20|To:=20Mark=20Andrews=20|Cc:=20namedro ppers@ops.ietf.org,=0D=0A=09owner-namedroppers@ops.ietf.o rg,=0D=0A=09Paul=20Vixie=20|MIME-Version: =201.0|In-Reply-To:=20<200906250319.n5P3JSLw015341@drugs. dv.isc.org>|References:=20Your=20message=20of=20"Thu,=202 5=20Jun=202009=2002:23:16=20GMT."=20=20=20=20=20=20=20=20 =20=20=20=20=20<35962.1245896596@nsa.vix.com>=20<20090625 0319.n5P3JSLw015341@drugs.dv.isc.org>; bh=PD+4QB7yzh3/g5uszSftn7zI0lRqmhljolyefGIsJhI=; b=jmxSmhAr/JXFkUL5qLBXjT6LjDyrV7nOSOiWX7gkMPczo0hqOLaMYBPk zcxme2QzMmxc5elP+0exWSqyChx4jyUJavWXytqjuV0obYyPDNBgdYXJT aDjfPh8WTOOeX37; X-IronPort-AV: E=Sophos;i="4.42,288,1243810800"; d="scan'208";a="15112934" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 25 Jun 2009 07:12:35 +0100 In-Reply-To: <200906250319.n5P3JSLw015341@drugs.dv.isc.org> References: Your message of "Thu, 25 Jun 2009 02:23:16 GMT." <35962.1245896596@nsa.vix.com> <200906250319.n5P3JSLw015341@drugs.dv.isc.org> To: Mark Andrews Cc: namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org, Paul Vixie Subject: Re: [dnsext] Danger of coming unstuck MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 25 Jun 2009 07:12:34 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 25/06/2009 07:12:40 AM, Serialize complete at 25/06/2009 07:12:40 AM Content-Type: multipart/alternative; boundary="=_alternative 00221BD5802575E0_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 00221BD5802575E0_= Content-Type: text/plain; charset="US-ASCII" > EDNS@512 only capable < 1% (again from recent ORG analsyis). I don't believe that analysis shows that they're _only_ capable of EDNS@512, they might still be perfectly capable of EDNS@1460 Ray --=_alternative 00221BD5802575E0_= Content-Type: text/html; charset="US-ASCII"
>    EDNS@512 only capable < 1% (again from recent ORG analsyis).
I don't believe that analysis shows that they're _only_ capable of EDNS@512, they might still be perfectly capable of EDNS@1460

Ray
--=_alternative 00221BD5802575E0_=-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 24 23:24:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F05F3A6836; Wed, 24 Jun 2009 23:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 WxRP2-kHszcw; Wed, 24 Jun 2009 23:24:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A893128C115; Wed, 24 Jun 2009 23:24:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJiK0-000MfW-TS for namedroppers-data0@psg.com; Thu, 25 Jun 2009 06:20:32 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJiJp-000MeZ-H1 for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 06:20:26 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id A9141E607B; Thu, 25 Jun 2009 06:20:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5P6KHpt017833; Thu, 25 Jun 2009 16:20:18 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906250620.n5P6KHpt017833@drugs.dv.isc.org> To: Ray.Bellis@nominet.org.uk Cc: Mark Andrews , namedroppers@ops.ietf.org, Paul Vixie From: Mark Andrews Subject: Re: [dnsext] Danger of coming unstuck In-reply-to: Your message of "Thu, 25 Jun 2009 07:12:34 +0100." Date: Thu, 25 Jun 2009 16:20:17 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Ray.Bellis@nominet.org.uk writes: > > EDNS@512 only capable < 1% (again from recent ORG analsyis). > > I don't believe that analysis shows that they're _only_ capable of > EDNS@512, they might still be perfectly capable of EDNS@1460 The roots don't emit EDNS answers that would be dropped due to fragmentation. EDNS@512 at the root < 1%. Some of that is from nameservers that don't see any replies. Some of that is from nameservers where all EDNS answers are filtered. For ORG some of the EDNS@512 will be due to fragmented responses not getting through but again that is < 1%. Whatever the case 1% is a over estimate. > Ray -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 00:16:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6473A6A06; Thu, 25 Jun 2009 00:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXPRC6wyEvaC; Thu, 25 Jun 2009 00:16:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 774143A6934; Thu, 25 Jun 2009 00:16:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJj7F-0000tQ-N6 for namedroppers-data0@psg.com; Thu, 25 Jun 2009 07:11:25 +0000 Received: from [195.1.209.33] (helo=bizet.nethelp.no) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJj74-0000sU-FT for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 07:11:20 +0000 Received: (qmail 33479 invoked from network); 25 Jun 2009 07:11:11 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 25 Jun 2009 07:11:11 -0000 Date: Thu, 25 Jun 2009 09:11:11 +0200 (CEST) Message-Id: <20090625.091111.74722494.sthaug@nethelp.no> To: vixie@isc.org Cc: george.barwood@blueyonder.co.uk, namedroppers@ops.ietf.org Subject: Re: [dnsext] Danger of coming unstuck From: sthaug@nethelp.no In-Reply-To: <5941.1245855812@nsa.vix.com> References: <20090624.105037.74726950.sthaug@nethelp.no> <5941.1245855812@nsa.vix.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > "Tend to get prioritized by networks"? Hardly. In most networks UDP > > packets are treated just like any other IP packets - i.e. best effort. > > i wish that were the case. udp/53 gets rampantly monetized by middleboxes > to a degree far beyond that of any other kind of IP packet. That may well be the case - however, as far as I know the big transit providers (e.g. Global Crossing, Level3 etc) don't do anything special with DNS traffic. I know the ISP I work for doesn't... Steinar Haug, Nethelp consulting, sthaug@nethelp.no -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 00:17:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D153A69AA; Thu, 25 Jun 2009 00:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdzNUGSMB0xj; Thu, 25 Jun 2009 00:17:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF7AC3A67DA; Thu, 25 Jun 2009 00:16:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJj9p-000146-2v for namedroppers-data0@psg.com; Thu, 25 Jun 2009 07:14:05 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJj9d-000132-EA for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 07:13:59 +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 1MJjBy-0006bG-5S; Thu, 25 Jun 2009 09:16:18 +0200 Received: by bfk.de with local id 1MJj9a-0000d6-90; Thu, 25 Jun 2009 09:13:50 +0200 To: Mark Andrews Cc: Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org, Paul Vixie Subject: Re: [dnsext] Danger of coming unstuck References: <200906250620.n5P6KHpt017833@drugs.dv.isc.org> From: Florian Weimer Date: Thu, 25 Jun 2009 09:13:50 +0200 In-Reply-To: <200906250620.n5P6KHpt017833@drugs.dv.isc.org> (Mark Andrews's message of "Thu\, 25 Jun 2009 16\:20\:17 +1000") Message-ID: <82eit8zsy9.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: * Mark Andrews: > The roots don't emit EDNS answers that would be dropped due to > fragmentation. They actually do (you posted DF=3D1 examples yourself), but this lack of conformance is irrelevant because anyone who can't receive such packets will only have reduced connectivity (even if they get DNS from someone else), so they will fix whatever is causing this. --=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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 00:47:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672903A6D29; Thu, 25 Jun 2009 00:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMX1WZGAf+pn; Thu, 25 Jun 2009 00:47:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 930AC3A69D7; Thu, 25 Jun 2009 00:47:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJjcp-0002yK-Of for namedroppers-data0@psg.com; Thu, 25 Jun 2009 07:44:03 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJjce-0002wh-52 for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 07:43: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 1MJjex-00014c-PD; Thu, 25 Jun 2009 09:46:15 +0200 Received: by bfk.de with local id 1MJjcZ-00023o-Od; Thu, 25 Jun 2009 09:43:47 +0200 To: Mark Andrews Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] Danger of coming unstuck References: <200906250319.n5P3JSLw015341@drugs.dv.isc.org> From: Florian Weimer Date: Thu, 25 Jun 2009 09:43:47 +0200 In-Reply-To: <200906250319.n5P3JSLw015341@drugs.dv.isc.org> (Mark Andrews's message of "Thu\, 25 Jun 2009 13\:19\:28 +1000") Message-ID: <823a9ozrkc.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: * Mark Andrews: > We have ~70% EDNS capable iterative clients (see the recent > ORG analsyis). I still don't think the ORG numbers are representative due to the way ORG is currently served. --=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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 05:04:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6A028C149; Thu, 25 Jun 2009 05:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[AWL=-0.727, 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 n3YIRjoAfl-E; Thu, 25 Jun 2009 05:04:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1F3033A6DA7; Thu, 25 Jun 2009 05:04:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJnbN-000Lej-4v for namedroppers-data0@psg.com; Thu, 25 Jun 2009 11:58:49 +0000 Received: from [209.85.219.227] (helo=mail-ew0-f227.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJnb8-000Ld7-N2 for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 11:58:42 +0000 Received: by ewy27 with SMTP id 27so1596816ewy.41 for ; Thu, 25 Jun 2009 04:58:32 -0700 (PDT) Received: by 10.216.72.83 with SMTP id s61mr740013wed.79.1245931112156; Thu, 25 Jun 2009 04:58:32 -0700 (PDT) Received: from ?192.168.1.3? ([62.30.111.115]) by mx.google.com with ESMTPS id p37sm979263gvf.12.2009.06.25.04.58.30 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Jun 2009 04:58:31 -0700 (PDT) Message-Id: <2F9189CD-58A8-46B1-88C7-AC4D4BA2127F@sabahattin-gucukoglu.com> From: Sabahattin Gucukoglu To: namedroppers@ops.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] Glue Caching Misbehaviours Date: Thu, 25 Jun 2009 12:58:29 +0100 X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Seems a bit pointless rewriting my problem statement and the followups, so here's the IETF general discussion: http://www.mail-archive.com/ietf@ietf.org/msg42037.html It affects all implementations to date because everybody makes the same mistake, that of imagining that glue is usable as persistent, cachable answers. Please discuss. :-) Cheers, Sabahattin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 05:13:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C15E3A6DA7; Thu, 25 Jun 2009 05:13:40 -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 ZVqDo-XAch4E; Thu, 25 Jun 2009 05:13:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C45523A6B27; Thu, 25 Jun 2009 05:13:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJnlL-000N42-B3 for namedroppers-data0@psg.com; Thu, 25 Jun 2009 12:09:07 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJnl5-000N00-Ut for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 12: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.3/8.14.3) with ESMTP id n5PC8ggr080447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jun 2009 14:08:45 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A4368CA.3090203@nlnetlabs.nl> Date: Thu, 25 Jun 2009 14:08:42 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Edward Lewis CC: Namedroppers Mailing List Subject: Re: [dnsext] Nested trust anchors (again) References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 25 Jun 2009 14:08:45 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 06/23/2009 07:04 PM, Edward Lewis wrote: > At 10:33 -0400 6/23/09, Matt Larson wrote: > >> This text was based on a namedroppers thread from early September 2008 >> entitled "Proposed addition to dnssec-bis-updates: Nested Trust >> Anchors". By my (and the dnssec-bis-editors') reckoning, "try all >> trust anchors" was overwhelmingly the preferred option. (I just >> re-read the entire thread.) I oppose the 'try all anchors'. Current bind choice to apply the closest is the most sensible one, because a higher trust anchor is not particularly more trusted. Probably less trusted, since it has a broader scope. If a user enters a trust anchor, it decides it wants to trust *that* anchor. Like in any configuration, the narrower the scope, the more relevant the information. I want the text in dnssec-bis-updates to be changed to say it should try the closest set of trust anchors. Best is to remove the text, it is all about configuration which is probably not really important once the 'many islands' DNSSEC turns into a root signed DNSSEC. What I saw was a lot of people chiming into, like Ed's below, 'trying more is more robust'. However, it is less secure. The point is to have trust in the anchor. Trying more is also unlikely to work, since the operator added this lower (non-working) anchor, the global-root-chain of trust is unlikely to work, or if it works, be trusted. Mostly people responded with 'but if the root is signed and the operators forgets his configured trust anchor ...'. Well the operator of course has automated trust-anchor tracking on that anchor, so it should be no problem. And every trust anchor without proper update mechanisms is going to be outofdate anyway. Going to the root only creates a security problem in this space, and does not solve anything. So, I want to reiterate my position that I think this creates a surprise in configuration. And a security related one at that. > I haven't re-read the thread but for the sake of robustness, trying any > possible way to validate data is a good thing. OTOH, an implementation > should make sure that the user is aware if they have nested trust > anchors, in an effort to limit stale anchors inviting attacks using past > private keys gone public. > >> Now, of course, dnssec-bis-updates isn't final, but last September's >> discussion looks pretty clear to me. Since we are apparently still >> discussing this topic, I wanted to point out the nested trust anchor >> text in dnssec-bis-updates so there are no surprises at last call. >> >> It would sure be nice to see BIND change its default behavior to "try >> all trust anchors" and make "trust the closest trust anchor" a >> configurable option. No, it should not. Plans are to have the root signed. Once that is done this is most likely the higher trust anchor. If a user configures a lower trust anchor, most likely this is when the user wants something specific for (his own company, or his own country, his own military, ...). And that user does not trust 'he who holds the root key'. Of course, users probably won't be configuring trust anchors, except the root, anyway. Unless it is an entirely local matter, in which case trying the global roots won't help. > With the caveat that this WG isn't the right vehicle to bring about > change in a specific implementation, and trying to generalize my > recommendation: > > A validator should try all possible trust anchors and try all possible > signature chains to find one that "works." At this point the answer > should be considered valid. Recall that the bar in DNSSEC isn't the > accuracy of the data but the accuracy of the delivery of the data. > > A trusted anchor module should make every attempt to limit the presence > of stale data hanging around. This is weasel-ly worded because I don't > have a clear mechanism for this in my own head. Perhaps this means 5011 > support or something like root zone hints priming. (Yadda, yadda, > yadda...) Please explain to me again why this is needed and should be in dnssec-updates? Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpDaMkACgkQkDLqNwOhpPjm8wCgirGs95VDbHvXCMOS9vGIegCH 4TMAoIFyzFz5knFIy9SZ/rwL+ViGkOZz =E87S -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 05:42:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB343A6F15; Thu, 25 Jun 2009 05:42:18 -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 W4rRU5u1Cerr; Thu, 25 Jun 2009 05:42:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7207E3A6B27; Thu, 25 Jun 2009 05:42:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJoE7-00011I-D1 for namedroppers-data0@psg.com; Thu, 25 Jun 2009 12:38:51 +0000 Received: from [2001:470:1f12:420::2] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJoDv-0000yw-PD for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 12:38:45 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 3D54574004; Thu, 25 Jun 2009 14:38:37 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id 7A7AF157884; Thu, 25 Jun 2009 14:30:13 +0200 (CEST) Date: Thu, 25 Jun 2009 14:30:13 +0200 From: Stephane Bortzmeyer To: Matt Larson Cc: Namedroppers Mailing List Subject: [dnsext] Re: Nested trust anchors (again) Message-ID: <20090625123013.GA20593@laperouse.bortzmeyer.org> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 8.10 (intrepid) User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Jun 23, 2009 at 10:33:36AM -0400, Matt Larson wrote a message of 149 lines which said: > the latest version of the dnssec-bis-updates draft calls for trying > all trust anchors until one succeeds. The draft also calls for a > configurable option to enable favoring the closest trust anchor to > the QNAME. Without discussing of the ideal default option, I would like the draft to mention other possible policies as well. I can see at least four, and IMHO, there is an use case for each of them: * ANY trust-anchor which works (the current default policy in dnssec-bis-updates) * ALL the trust-anchors must work (highly secure, for the truly paranoids) * The CLOSEST trust-anchor must work (if I configure a local trust-anchor, it is because I know what I do) * The HIGHEST trust-anchor must work (the root trust anchor will probably be less stale than local ones). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 05:54:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A40F3A6B04; Thu, 25 Jun 2009 05:54:43 -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 ewpNysJHxYlc; Thu, 25 Jun 2009 05:54:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B39B28C180; Thu, 25 Jun 2009 05:54:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJoPq-000275-I1 for namedroppers-data0@psg.com; Thu, 25 Jun 2009 12:50:58 +0000 Received: from [2001:470:1f12:420::2] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJoPd-00025c-8B for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 12:50:52 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 5739674003; Thu, 25 Jun 2009 14:50:39 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id 70203157884; Thu, 25 Jun 2009 14:50:23 +0200 (CEST) Date: Thu, 25 Jun 2009 14:50:23 +0200 From: Stephane Bortzmeyer To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: [dnsext] Re: Danger of coming unstuck Message-ID: <20090625125023.GB20593@laperouse.bortzmeyer.org> References: <200906240836.n5O8aMAW000739@drugs.dv.isc.org> <5893.1245855723@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5893.1245855723@nsa.vix.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 8.10 (intrepid) User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 24, 2009 at 03:02:03PM +0000, Paul Vixie wrote a message of 18 lines which said: > can we do some measurement and analysis, to prove (or not) that > assertion? On a .FR authoritative name server: 50.3 % of the requests are EDNS0. (TODO: same metric but only for big clients, those with many requests.) Sizes are: edns0_size | percentage ------------+------------ 4096 | 95.86 4000 | .00 2944 | .00 2048 | 2.78 1500 | .00 1472 | .00 1460 | .25 1452 | .00 1400 | .01 1352 | .00 1300 | .00 1280 | .27 1252 | .00 1200 | .03 1024 | .01 800 | .00 730 | .00 512 | .79 > can someone write a perl or awk script and post it here Perl? Real Men do not use Perl! SELECT DISTINCT edns0_size, count(id) AS number FROM Recent_packets WHERE query GROUP BY edns0_size ORDER BY edns0_size DESC; -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 05:59:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17323A6DD2; Thu, 25 Jun 2009 05:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[AWL=-0.675, 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 Z109TfYfIev5; Thu, 25 Jun 2009 05:59:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E03128C19D; Thu, 25 Jun 2009 05:59:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJoUc-0002Zi-5O for namedroppers-data0@psg.com; Thu, 25 Jun 2009 12:55:54 +0000 Received: from [209.85.219.227] (helo=mail-ew0-f227.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJoUB-0002WY-AN for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 12:55:35 +0000 Received: by ewy27 with SMTP id 27so1647974ewy.41 for ; Thu, 25 Jun 2009 05:55:25 -0700 (PDT) Received: by 10.216.30.195 with SMTP id k45mr735353wea.197.1245934525258; Thu, 25 Jun 2009 05:55:25 -0700 (PDT) Received: from ?192.168.1.3? (62-30-111-115.cable.ubr07.dals.blueyonder.co.uk [62.30.111.115]) by mx.google.com with ESMTPS id f13sm1801065gvd.8.2009.06.25.05.55.23 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Jun 2009 05:55:24 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: <04840579-9922-4435-9C2E-0E2A0B98501A@sabahattin-gucukoglu.com> From: Sabahattin Gucukoglu To: Nicholas Weaver In-Reply-To: <0C56E994-CE14-4811-B3FB-DC2B78E78AAC@icsi.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Glue Caching Misbehaviours Date: Thu, 25 Jun 2009 13:55:22 +0100 References: <2F9189CD-58A8-46B1-88C7-AC4D4BA2127F@sabahattin-gucukoglu.com> <0C56E994-CE14-4811-B3FB-DC2B78E78AAC@icsi.berkeley.edu> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 25 Jun 2009, at 13:34, Nicholas Weaver wrote: > On Jun 25, 2009, at 4:58 AM, Sabahattin Gucukoglu wrote: >> Seems a bit pointless rewriting my problem statement and the >> followups, so here's the IETF general discussion: >> http://www.mail-archive.com/ietf@ietf.org/msg42037.html >> >> It affects all implementations to date because everybody makes the >> same mistake, that of imagining that glue is usable as persistent, >> cachable answers. >> >> Please discuss. :-) > > This is not necessarily the case for all resolvers. EG, unbound > does not, and the ones used by Comcast do not, for example. I imagine less common ones have a good chance of doing the right thing, I haven't yet studied unbound though. All of the ones I tested certainly do exactly the same caching. > This is actually something I specifically check for in Netalyzr ( http://netalyzr.icsi.berkeley.edu/ > ), is how DNS resolvers handle glue records, including nameserver > glue records. > > I regret that Java is inaccessible to me. > Bind, for example, will only accept and return such interior glue > records for the nameserver addresses only, but not an arbitrary > ADDITIONAL record. Good for security. But the problem of what happens when the nameserver whose address is being cached has reasons for having shorter TTLs than parent supplies, or of what happens when a changeover of delegation occurs in time for parent data to be cached but not for destructive changes to the original nameserver (as often happens when you stop using a registrar's nameservers). All of this sort of nonsense goes away when we stop making assumptions about additional data from parent zones, as we should from the start. Cheers, Sabahattin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 06:39:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE5503A6B0C; Thu, 25 Jun 2009 06:39:15 -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 TDqt9htkicNO; Thu, 25 Jun 2009 06:39:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C072C28C1AA; Thu, 25 Jun 2009 06:39:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJp66-0005RS-PE for namedroppers-data0@psg.com; Thu, 25 Jun 2009 13:34:38 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJp5v-0005QY-0D for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 13:34:32 +0000 Received: from [0.0.0.0] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5PDYLad058742; Thu, 25 Jun 2009 09:34:22 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A4368CA.3090203@nlnetlabs.nl> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <4A4368CA.3090203@nlnetlabs.nl> Date: Thu, 25 Jun 2009 09:33:30 -0400 To: Namedroppers Mailing List From: Edward Lewis Subject: Re: [dnsext] Nested trust anchors (again) Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: >> A trusted anchor module should make every attempt to limit the presence >> of stale data hanging around. This is weasel-ly worded because I don't >> have a clear mechanism for this in my own head. Perhaps this means 5011 >> support or something like root zone hints priming. (Yadda, yadda, >> yadda...) At 14:08 +0200 6/25/09, W.C.A. Wijngaards wrote: >Please explain to me again why this is needed and should be in >dnssec-updates? This is an open-ended question. I'll ramble on for Wouter to see is this lays any ideas. Perhaps it is too wide ranging for general consumption. The issue begins with understanding the difference between a distributed system that has a "closed population" and an "open population." In the former, the entire system can stay into the territory of closely coupled fairly easily. In the latter, loose coupling is what can be achieved. This lies in the fact that in a closed system it is possible to know you have polled all participants and are able to delineate a sequence of events, something important when scheduling access to a critical resource. In an open system the problem becomes undecidable because you can never know what the real sequence of events is. (Einstein's Special Theory of Relativity actually applies to this.) With the Internet, particularly the DNS protocol within it, being an open system, the coupling of the system will be loose. The consequence of trying to tighten up the system will merely cause cracks in the system near where you tighten it. How does this theoretical hand waving play here? There are too many actors involved to ever attain coherent (and unanimous) consensus on what is "trust." In truth there is no "bad guys" just "guys with different goals that you and their goals are not compatible with yours." Not everyone in the DNS wants the same security, they all do want security - for their interests. If we try to establish a "one true secure system" will will be in a morass, like the issue of trying to sign the root now. The reason the DNS (system) has become the monster it is lies in it's laid back nature regarding coordination in managing the pieces. If you think it is bad that the delegation points are so "weak" in the sense that we have glue issues, what you are missing is that the loose coupling there is how the system was able to scale beyond the borders of the IETF. The DNS architecture's success is a result of it embracing the nature of an open population distributed system. DNSSEC could have reversed that embrace but in doing so would have killed off DNSSEC. The next factor is that the addition of security to any existing system innately injures the stability and availability of the system to some extent. False positives, as it sometimes called. This concept was described to me as "imagine a state machine" describing a system. There are states which are "safe" and states that are vulnerable. There is a third set of states which are "at risk." At risk states are those in which some transitions out land in safe states and some transitions out land in vulnerable states. The goal of a security system is to prevent the system from winding up in the vulnerable states, but this usually means that at risk states are also prevented. The "false positive" here is a path from a safe to "at risk" to safe that is blocked (unnecessarily). Like a homeowner who's locked out of their own house. In DNSSEC, if you tighten the search for a trust anchor you will be cutting off at risk states. You will be denying (DNS response) data that could be good, the consequence is a support call. Harking back to the closed vs. open population, the bad part of a support call is not simply that it costs money to the handler, it's that the support call will go to the wrong entity. It will likely go to the ISP or IT department, the folks least likely to be able to correct the problem (assuming they understand DNSSEC) - at best. The final factor in trying all possible means is the operational rule that data statically stored anywhere is going to lead to problems eventually. Again, harking back to issue one, operators live in a open population environment. It is not possible to reliably do something "static" and have it go away on cue. I have seen static configurations go away - usually during an audit. But by and large, static data gets forgotten. Worse yet - forgotten in a way that means it is impossible to locate or remember that it is present. I don't know if Olafur recalls this, but at UMD he did a study of traffic on the department's Ethernet cable network. They observed a pattern of traffic that was causing low layer issues but it came from an unidentified source. Eventually someone found the device and unplugged it and the issue went away. One day the pattern returned - for some reason the location of the box had been forgotten by the network monitoring staff although it was known by - possibly a janitor who put the plug back in to the wall. Things like that happen. I picked that example because it is the earliest one I know personally. (My job these days is to remember all of the places "static" data and ideas went.) In the 80's it was equipment on a wire. Nowadays it is items in a configuration/start up script. Unless you are a Unix-like system admin, the amount of configuration data out there is just too dang much to track. The summary of this is, DNSSEC's trust model is going to be one that has flexibility to adapt to the demands of a diverse and open population. By the nature of being a security system, DNSSEC is crimping the actions of the base system, and to remain useful to the original system, has to try hard "to get the mail through." Finally, most configured trust anchors will be stale at any given time. PS - It's essential we try all ways to get the data through. It would be a "really good idea" if any validator that has to fall back to another anchor makes this action known to somebody who can take an action on that. Come to think of this, it's a lot like the debate over EDNS0 fallbacks. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 06:45:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F1C23A6CAB; Thu, 25 Jun 2009 06:45:03 -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 SfVLAeghNxx6; Thu, 25 Jun 2009 06:45:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7835B3A6BE5; Thu, 25 Jun 2009 06:45:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJpDc-00063I-D1 for namedroppers-data0@psg.com; Thu, 25 Jun 2009 13:42:24 +0000 Received: from [2001:470:1f12:420::2] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJpDQ-000626-1M for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 13:42:18 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 49F74959DE; Thu, 25 Jun 2009 15:42:10 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id D2F50157884; Thu, 25 Jun 2009 15:41:57 +0200 (CEST) Date: Thu, 25 Jun 2009 15:41:57 +0200 From: Stephane Bortzmeyer To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: [dnsext] Re: Danger of coming unstuck Message-ID: <20090625134157.GA25547@laperouse.bortzmeyer.org> References: <200906240836.n5O8aMAW000739@drugs.dv.isc.org> <5893.1245855723@nsa.vix.com> <20090625125023.GB20593@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090625125023.GB20593@laperouse.bortzmeyer.org> X-Transport: UUCP rules X-Operating-System: Ubuntu 8.10 (intrepid) User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 25, 2009 at 02:50:23PM +0200, Stephane Bortzmeyer wrote a message of 47 lines which said: > 50.3 % of the requests are EDNS0. (TODO: same metric but only for big > clients, those with many requests.) I've set an arbitrary limit at 1000 queries received in two days. DNS clients above this limit ("big resolvers", 6.0 % of the total number of clients) are EDNS0 at 59.5 %. So, there is hope, big clients are a bit better. Also, in the same spirit, 28.9 % of the clients send at least one EDNS0 packet. So we have a few big clients which are often EDNS0 and a lot of small clients which are often not EDNS0 (namedroppers subscribers playing with dig?) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 07:04:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1A33A682B; Thu, 25 Jun 2009 07:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.706 X-Spam-Level: X-Spam-Status: No, score=-0.706 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9GdVKDw92YV; Thu, 25 Jun 2009 07:04:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 109C43A6A72; Thu, 25 Jun 2009 07:04:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJpVR-0007WO-Ml for namedroppers-data0@psg.com; Thu, 25 Jun 2009 14:00:49 +0000 Received: from [209.85.219.227] (helo=mail-ew0-f227.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJpVF-0007VZ-8m for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 14:00:43 +0000 Received: by ewy27 with SMTP id 27so1717805ewy.41 for ; Thu, 25 Jun 2009 07:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=rBjaPnWImNIlFCdO9E32+TFbN26UoDasGDPHtsfWlJI=; b=jnrrh88usMhrD0mfMtyTrmGkh2MnrZXEFZe7TqzmfGK3JzRwOwIjSGOsYEhNK+6tKx iOYbITvndTcMzzZkSwyfBQfJcnpyxJ9CzEcDFqtogHU3T3FOJyvVIsc16OLNRsSalXYu DAy/e7xVjlNFiyx808jqln73aOKdI1+35e088= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=VXfF+3YvVXyVUagL3JX+sdhDxsnbABpB/iMZpcwBFaXrTGTQmCa+kzN7h+DngDbHUe VIt6QkcDaOAwmipHl+T0+38aBTNmkOmBHJ+Q6dzk0fZApyorzXGNneNoddaKNH8u4chi bfVNFdO2hjex96YoivISKrH5cBS8XkV6UB0Cs= MIME-Version: 1.0 Received: by 10.210.113.19 with SMTP id l19mr2902351ebc.4.1245938436190; Thu, 25 Jun 2009 07:00:36 -0700 (PDT) In-Reply-To: <20090625134157.GA25547@laperouse.bortzmeyer.org> References: <200906240836.n5O8aMAW000739@drugs.dv.isc.org> <5893.1245855723@nsa.vix.com> <20090625125023.GB20593@laperouse.bortzmeyer.org> <20090625134157.GA25547@laperouse.bortzmeyer.org> From: bert hubert Date: Thu, 25 Jun 2009 16:00:16 +0200 Message-ID: <3efd34cc0906250700y1dbf6d22n3169d7d533f89ec6@mail.gmail.com> Subject: Re: [dnsext] Re: Danger of coming unstuck To: Stephane Bortzmeyer Cc: Paul Vixie , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 25, 2009 at 3:41 PM, Stephane Bortzmeyer wrote: > Also, in the same spirit, 28.9 % of the clients send at least one > EDNS0 packet. So we have a few big clients which are often EDNS0 and a > lot of small clients which are often not EDNS0 (namedroppers > subscribers playing with dig?) Or you are seeing clients that fall back to non-EDNS0 on a timeout, and stay that way? I can't imagine bigger resolvers hiding behind NAT, so each client you see is probably exactly that, a single server. Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 07:09:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97AE3A6960; Thu, 25 Jun 2009 07:09:57 -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 g4v5JUXp1oCq; Thu, 25 Jun 2009 07:09:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B146B3A682E; Thu, 25 Jun 2009 07:09:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJpbP-0007vH-9Z for namedroppers-data0@psg.com; Thu, 25 Jun 2009 14:06:59 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJpbC-0007uO-VH for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 14:06:53 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n5PE6fqx091287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jun 2009 16:06:41 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A438471.40304@nlnetlabs.nl> Date: Thu, 25 Jun 2009 16:06:41 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Edward Lewis CC: Namedroppers Mailing List Subject: Re: [dnsext] Nested trust anchors (again) References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <4A4368CA.3090203@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 25 Jun 2009 16:06:41 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/25/2009 03:33 PM, Edward Lewis wrote: > The summary of this is, DNSSEC's trust model is going to be one that has > flexibility to adapt to the demands of a diverse and open population. > By the nature of being a security system, DNSSEC is crimping the actions > of the base system, and to remain useful to the original system, has to > try hard "to get the mail through." Finally, most configured trust > anchors will be stale at any given time. Thanks, I agree with the theory. So, I change my position, agree with dnssec-updates, and am now thinking about options for trust anchors - what Stephane is talking about. > PS - It's essential we try all ways to get the data through. It would > be a "really good idea" if any validator that has to fall back to > another anchor makes this action known to somebody who can take an > action on that. Yes some warning, since the operator supplied the static data, its fine to inform him about it. Its not like trying to tell operators about every lame server on the internet :-) > Come to think of this, it's a lot like the debate over EDNS0 fallbacks. And nail in the coffin for all those TCP, PING, 0x20 and also my own forgery resilience options, in that they should really support all fallbacks to make it work. But they cannot provide their security to all the domains, as they are too loosely coupled to be amenable. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpDhHEACgkQkDLqNwOhpPiW+QCfX2ctzBPArIuvszPbv8HoNcdv +ocAoLIqdgkylhRd91X9Y3Hy4b4CdSkN =s9CJ -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 07:19:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18ABE28C1AB; Thu, 25 Jun 2009 07:19:28 -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 vAm-R-Bm-SMU; Thu, 25 Jun 2009 07:19:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A80663A682B; Thu, 25 Jun 2009 07:19:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJpkL-0008bb-Ef for namedroppers-data0@psg.com; Thu, 25 Jun 2009 14:16:13 +0000 Received: from [2001:470:1f12:420::2] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJpk9-0008aR-SG for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 14:16:07 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 46138959F9; Thu, 25 Jun 2009 16:15:59 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id 18ADE157884; Thu, 25 Jun 2009 16:12:05 +0200 (CEST) Date: Thu, 25 Jun 2009 16:12:05 +0200 From: Stephane Bortzmeyer To: bert hubert Cc: namedroppers@ops.ietf.org Subject: [dnsext] Re: Danger of coming unstuck Message-ID: <20090625141204.GA28599@laperouse.bortzmeyer.org> References: <200906240836.n5O8aMAW000739@drugs.dv.isc.org> <5893.1245855723@nsa.vix.com> <20090625125023.GB20593@laperouse.bortzmeyer.org> <20090625134157.GA25547@laperouse.bortzmeyer.org> <3efd34cc0906250700y1dbf6d22n3169d7d533f89ec6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3efd34cc0906250700y1dbf6d22n3169d7d533f89ec6@mail.gmail.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 8.10 (intrepid) User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 25, 2009 at 04:00:16PM +0200, bert hubert wrote a message of 13 lines which said: > > a lot of small clients which are often not EDNS0 (namedroppers > > subscribers playing with dig?) > > Or you are seeing clients that fall back to non-EDNS0 on a timeout, Unfortunately, there is no User-Agent string in DNS requests so it will be hard to say :-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 07:26:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7FD728C13A; Thu, 25 Jun 2009 07:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_73=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 ofkOn9aSxbFm; Thu, 25 Jun 2009 07:26:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C730428C0FD; Thu, 25 Jun 2009 07:26:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJprr-0009BL-AY for namedroppers-data0@psg.com; Thu, 25 Jun 2009 14:23:59 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJprg-00099x-6a for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 14:23:53 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5PEMqfB096091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jun 2009 07:22:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A4368CA.3090203@nlnetlabs.nl> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <4A4368CA.3090203@nlnetlabs.nl> Date: Thu, 25 Jun 2009 07:22:02 -0700 To: "W.C.A. Wijngaards" From: Paul Hoffman Subject: Re: [dnsext] Nested trust anchors (again) Cc: Namedroppers Mailing List Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 2:08 PM +0200 6/25/09, W.C.A. Wijngaards wrote: >I oppose the 'try all anchors'. Please pardon me for being blunt, but this is not about what *you* want in your system, it is about what would be best for the Internet as a whole. You might want "try closest", and the current document says that should be available. The assumption that you (and BIND) make is that someone has carefully thought out the effects of each individual trust anchor in the root pile. That is clearly a wrong assumption when considering the Internet as a whole. The example that generated this discussion is still relevant. In time order: - Trust anchor for example.sub is added - Later, trust anchor for example is added - The maintainer for example.sub rolls the key and does the right thing with its parent - You and BIND see example.sub go bogus because you didn't remove the "closer" trust anchor You might want that to happen based on a policy that says you will always calculate the relationships between every trust anchor. Some of us don't want that to be the default on the Internet because we believe that DNS admins will not be so careful, and the effect is that zones go bogus *even though the resolver has the right information*. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 07:59:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271243A6AA0; Thu, 25 Jun 2009 07:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 UzGY3Wb1TwjU; Thu, 25 Jun 2009 07:59:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E2A213A6A07; Thu, 25 Jun 2009 07:59:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJqLf-000BPn-5m for namedroppers-data0@psg.com; Thu, 25 Jun 2009 14:54:47 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJqLS-000BP7-0T for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 14:54:41 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id DC5AAE608C; Thu, 25 Jun 2009 14:54:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5PEsRWe023320; Fri, 26 Jun 2009 00:54:29 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906251454.n5PEsRWe023320@drugs.dv.isc.org> To: Florian Weimer Cc: Mark Andrews , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org, Paul Vixie From: Mark Andrews Subject: Re: [dnsext] Danger of coming unstuck In-reply-to: Your message of "Thu, 25 Jun 2009 09:13:50 +0200." <82eit8zsy9.fsf@mid.bfk.de> Date: Fri, 26 Jun 2009 00:54:27 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <82eit8zsy9.fsf@mid.bfk.de>, Florian Weimer writes: > * Mark Andrews: > > > The roots don't emit EDNS answers that would be dropped due to > > fragmentation. > > They actually do (you posted DF=3D1 examples yourself), but this lack of > conformance is irrelevant because anyone who can't receive such > packets will only have reduced connectivity (even if they get DNS from > someone else), so they will fix whatever is causing this. And the answers the roots produce don't get big enough to trigger fragmentation on current links. This assumes that someone hasn't configured a link to use a dramatically smaller mtu than standard. > --=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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 08:02:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75FB83A6A2E; Thu, 25 Jun 2009 08:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 ildHJSFkzXTf; Thu, 25 Jun 2009 08:02:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 57D8B28C1AB; Thu, 25 Jun 2009 08:02:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJqQT-000Ble-4G for namedroppers-data0@psg.com; Thu, 25 Jun 2009 14:59:45 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJqQG-000BkX-UN for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 14:59:38 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 42806E6072; Thu, 25 Jun 2009 14:59:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5PExTFs023425; Fri, 26 Jun 2009 00:59:30 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906251459.n5PExTFs023425@drugs.dv.isc.org> To: Florian Weimer Cc: Mark Andrews , Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Danger of coming unstuck In-reply-to: Your message of "Thu, 25 Jun 2009 09:43:47 +0200." <823a9ozrkc.fsf@mid.bfk.de> Date: Fri, 26 Jun 2009 00:59:29 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <823a9ozrkc.fsf@mid.bfk.de>, Florian Weimer writes: > * Mark Andrews: > > > We have ~70% EDNS capable iterative clients (see the recent > > ORG analsyis). > > I still don't think the ORG numbers are representative due to the way > ORG is currently served. The root servers also show this. I suspect that if you sample any EDNS capable TLD you will get similar traffic distributions. If you sample a TLD which doesn't use EDNS capable servers you will see more plain DNS than EDNS as the EDNS clients fallback to plain DNS. > --=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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 08:02:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34223A6A2E; Thu, 25 Jun 2009 08:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 9PBvI5lR0lgX; Thu, 25 Jun 2009 08:02:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F34F53A68C8; Thu, 25 Jun 2009 08:02:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJqQu-000BoC-63 for namedroppers-data0@psg.com; Thu, 25 Jun 2009 15:00:12 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJqQj-000BnB-83 for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 15:00:06 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id E2C7DA6DD7; Thu, 25 Jun 2009 14:59:59 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Mark Andrews cc: Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: [dnsext] Danger of coming unstuck In-Reply-To: Your message of "Thu, 25 Jun 2009 16:20:17 +1000." <200906250620.n5P6KHpt017833@drugs.dv.isc.org> References: <200906250620.n5P6KHpt017833@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 25 Jun 2009 14:59:59 +0000 Message-ID: <69511.1245941999@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Mark Andrews > Date: Thu, 25 Jun 2009 16:20:17 +1000 > Sender: owner-namedroppers@ops.ietf.org > > The roots don't emit EDNS answers that would be dropped due to > fragmentation. EDNS@512 at the root < 1%. Some of that is from > nameservers that don't see any replies. Some of that is from > nameservers where all EDNS answers are filtered. > > For ORG some of the EDNS@512 will be due to fragmented responses > not getting through but again that is < 1%. > > Whatever the case 1% is a over estimate. again i say, i'd like to see references to reproduceable results on this. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 08:05:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D54553A6982; Thu, 25 Jun 2009 08:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 ZU5IA8S1eepO; Thu, 25 Jun 2009 08:05:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F10BC3A6862; Thu, 25 Jun 2009 08:05:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJqTo-000C5W-EG for namedroppers-data0@psg.com; Thu, 25 Jun 2009 15:03:12 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJqTd-000C4T-Ie for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 15:03:06 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 43531A6E9F; Thu, 25 Jun 2009 15:03:01 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Florian Weimer cc: Mark Andrews , namedroppers@ops.ietf.org Subject: Re: [dnsext] Danger of coming unstuck In-Reply-To: Your message of "Thu, 25 Jun 2009 09:43:47 +0200." <823a9ozrkc.fsf@mid.bfk.de> References: <200906250319.n5P3JSLw015341@drugs.dv.isc.org> <823a9ozrkc.fsf@mid.bfk.de> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 25 Jun 2009 15:03:01 +0000 Message-ID: <69796.1245942181@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Florian Weimer > Date: Thu, 25 Jun 2009 09:43:47 +0200 > > > We have ~70% EDNS capable iterative clients (see the recent > > ORG analsyis). > > I still don't think the ORG numbers are representative due to the way > ORG is currently served. florian, perhaps you can do a 24-hour study of ISC SIE's data and tell us all what you find? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 08:06:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5483A6A07; Thu, 25 Jun 2009 08:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7cVWXMoAqSB; Thu, 25 Jun 2009 08:06:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C8B073A6862; Thu, 25 Jun 2009 08:06:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJqTO-000C2J-Jn for namedroppers-data0@psg.com; Thu, 25 Jun 2009 15:02:46 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJqTD-000C1T-4q for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 15:02:40 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BB6F92FE9661 for ; Thu, 25 Jun 2009 15:02:33 +0000 (UTC) Date: Thu, 25 Jun 2009 11:02:31 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Glue Caching Misbehaviours Message-ID: <20090625150231.GD375@shinkuro.com> References: <2F9189CD-58A8-46B1-88C7-AC4D4BA2127F@sabahattin-gucukoglu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2F9189CD-58A8-46B1-88C7-AC4D4BA2127F@sabahattin-gucukoglu.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 25, 2009 at 12:58:29PM +0100, Sabahattin Gucukoglu wrote: > Seems a bit pointless rewriting my problem statement and the followups, > so here's the IETF general discussion: > http://www.mail-archive.com/ietf@ietf.org/msg42037.html […] > Please discuss. :-) Well, before we start discussing, you could read http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-01.txt and see whether you think that draft needs to be adopted by the WG, or whether that material is at least a topic that the WG needs to undertake. I will point out that saying, "You should do this work," will be less warmly received than, "We should do this work, and I am willing to help." A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 08:09:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45AC28C1A4; Thu, 25 Jun 2009 08:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhIyInavCKqd; Thu, 25 Jun 2009 08:09:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF6D628C147; Thu, 25 Jun 2009 08:09:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJqX4-000CRb-Sw for namedroppers-data0@psg.com; Thu, 25 Jun 2009 15:06:34 +0000 Received: from [65.201.175.9] (helo=cliffie.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJqWt-000CQ3-HP for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 15:06:28 +0000 Received: from monsoon.verisignlabs.com (scooter.bo.labs.vrsn.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id 7C4A413670C for ; Thu, 25 Jun 2009 11:06:22 -0400 (EDT) Received: from dul1mcmlarson-l1.labs.vrsn.com (dul1mcmlarson-l1.labs.vrsn.com [10.131.244.205]) by monsoon.verisignlabs.com (Postfix) with ESMTP id B4CB3242145 for ; Thu, 25 Jun 2009 11:06:20 -0400 (EDT) Date: Thu, 25 Jun 2009 11:06:22 -0400 From: Matt Larson To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Danger of coming unstuck Message-ID: <20090625150622.GZ1164@dul1mcmlarson-l1.labs.vrsn.com> References: <200906250620.n5P6KHpt017833@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906250620.n5P6KHpt017833@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, 25 Jun 2009, Mark Andrews wrote: > The roots don't emit EDNS answers that would be dropped due to > fragmentation. All of the roots? Source, please. > EDNS@512 at the root < 1%. All of the roots? F root? Something else? Source, please. > For ORG some of the EDNS@512 will be due to fragmented responses > not getting through but again that is < 1%. Do you have direct data from .org? Source, please. > Whatever the case 1% is a over estimate. You have not shown data to back up this claim. Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 08:26:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E19033A689E; Thu, 25 Jun 2009 08:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFEECJb9DKjD; Thu, 25 Jun 2009 08:26:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4761A3A6862; Thu, 25 Jun 2009 08:26:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJqmj-000Dux-B4 for namedroppers-data0@psg.com; Thu, 25 Jun 2009 15:22:45 +0000 Received: from [65.201.175.9] (helo=cliffie.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJqmQ-000DtY-II for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 15:22:32 +0000 Received: from monsoon.verisignlabs.com (scooter.bo.labs.vrsn.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id B9BA913670C for ; Thu, 25 Jun 2009 11:22:25 -0400 (EDT) Received: from dul1mcmlarson-l1.labs.vrsn.com (dul1mcmlarson-l1.labs.vrsn.com [10.131.244.205]) by monsoon.verisignlabs.com (Postfix) with ESMTP id F1D8A242145 for ; Thu, 25 Jun 2009 11:22:23 -0400 (EDT) Date: Thu, 25 Jun 2009 11:22:25 -0400 From: Matt Larson To: namedroppers@ops.ietf.org Subject: Real data (was Re: [dnsext] Danger of coming unstuck) Message-ID: <20090625152225.GA1164@dul1mcmlarson-l1.labs.vrsn.com> References: <823a9ozrkc.fsf@mid.bfk.de> <200906251459.n5PExTFs023425@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906251459.n5PExTFs023425@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, 26 Jun 2009, Mark Andrews wrote: > In message <823a9ozrkc.fsf@mid.bfk.de>, Florian Weimer writes: > > * Mark Andrews: > > > > > We have ~70% EDNS capable iterative clients (see the recent > > > ORG analsyis). > > > > I still don't think the ORG numbers are representative due to the way > > ORG is currently served. > > The root servers also show this. I suspect that if you sample any > EDNS capable TLD you will get similar traffic distributions. Not so. See slide 22 of https://www.dns-oarc.net/files/workshop-2008/larson.pdf: from 24 hours of traffic to the .com/.net name servers in September 2008, only 28.48% of queriers were EDNS0 capable. Even if we assume that many of those were bots and re-calculate the figure based on the number of queriers that sent at least ten queries in that 24-hour interval (the threshold for our analysis), the percentage is only 50% EDNS0 capable. Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 08:28:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 561A63A6AA0; Thu, 25 Jun 2009 08:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 N4Yil3vJCI3G; Thu, 25 Jun 2009 08:28:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AACA63A6B0C; Thu, 25 Jun 2009 08:28:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJqol-000E5P-IU for namedroppers-data0@psg.com; Thu, 25 Jun 2009 15:24: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.69 (FreeBSD)) (envelope-from ) id 1MJqoZ-000E3o-Pu for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 15:24:45 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 8334AA6E9E for ; Thu, 25 Jun 2009 15:24:39 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Namedroppers Mailing List Subject: Re: [dnsext] Re: Nested trust anchors (again) In-Reply-To: Your message of "Thu, 25 Jun 2009 14:30:13 +0200." <20090625123013.GA20593@laperouse.bortzmeyer.org> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <20090625123013.GA20593@laperouse.bortzmeyer.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 25 Jun 2009 15:24:39 +0000 Message-ID: <70741.1245943479@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Thu, 25 Jun 2009 14:30:13 +0200 > From: Stephane Bortzmeyer > > Without discussing of the ideal default option, I would like the draft > to mention other possible policies as well. I can see at least four, > and IMHO, there is an use case for each of them: > > * ANY trust-anchor which works (the current default policy in > dnssec-bis-updates) > > * ALL the trust-anchors must work (highly secure, for the truly > paranoids) > > * The CLOSEST trust-anchor must work (if I configure a local > trust-anchor, it is because I know what I do) > > * The HIGHEST trust-anchor must work (the root trust anchor will > probably be less stale than local ones). +1. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 09:03:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51223A6DF2; Thu, 25 Jun 2009 09:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-1.393, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, MANGLED_YOUR=2.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 u1iSKth+clJl; Thu, 25 Jun 2009 09:03:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B24E3A6D9B; Thu, 25 Jun 2009 09:03:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJrIW-000GVy-3C for namedroppers-data0@psg.com; Thu, 25 Jun 2009 15:55:36 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJrIF-000GUz-KP for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 15:55:29 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id A0B01E606E; Thu, 25 Jun 2009 15:55:18 +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 n5PFt9W7026826; Fri, 26 Jun 2009 01:55:15 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906251555.n5PFt9W7026826@drugs.dv.isc.org> To: Paul Hoffman Cc: "W.C.A. Wijngaards" , Namedroppers Mailing List From: Mark Andrews Subject: Re: [dnsext] Nested trust anchors (again) In-reply-to: Your message of "Thu, 25 Jun 2009 07:22:02 MST." Date: Fri, 26 Jun 2009 01:55:09 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Paul Hoffman writes: > At 2:08 PM +0200 6/25/09, W.C.A. Wijngaards wrote: > >I oppose the 'try all anchors'. > > Please pardon me for being blunt, but this is not about what *you* want in yo > ur system, it is about what would be best for the Internet as a whole. You mi > ght want "try closest", and the current document says that should be availabl > e. > > The assumption that you (and BIND) make is that someone has carefully thought > out the effects of each individual trust anchor in the root pile. That is cl > early a wrong assumption when considering the Internet as a whole. The exampl > e that generated this discussion is still relevant. In time order: > > - Trust anchor for example.sub is added > - Later, trust anchor for example is added > - The maintainer for example.sub rolls the key and does the right thing with > its parent > - You and BIND see example.sub go bogus because you didn't remove the "closer > " trust anchor Which is why you don't add trust anchors willy nilly. You add trust anchors for zones that publish trust anchors not every zone that is signed. That way key rollover takes into account validators that have the trust anchor configured. Note the above senario is the result of the current bottom up deployement growth. Once the root is signed we will see more and more top down deployment where you don't need all the extra trust anchors. One really should mimimise the numbers of trust achors you have. > You might want that to happen based on a policy that says you will always cal > culate the relationships between every trust anchor. Some of us don't want th > at to be the default on the Internet because we believe that DNS admins will > not be so careful, and the effect is that zones go bogus *even though the res > olver has the right information*. And you haven't thought out the other senarios where jumping over trust anchors is bad. There are lots of configurations where jumping over a trust anchor is a waste of time. You want to make a mis-managed trust anchor not be a problem. You want to force implementations that made decisions 10 years ago to change default policy for no good reason. Decisions that are as valid today as they were then. There are configurations where you want trust paths from higher up to fail because it they succeed there would have been a information leak. Mark > --Paul Hoffman, Director > --VPN Consortium > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 09:18:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C504F3A6DC7; Thu, 25 Jun 2009 09:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 XDh+deV+a+rN; Thu, 25 Jun 2009 09:18:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E01803A6B0C; Thu, 25 Jun 2009 09:18:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJrab-000Ht2-Qx for namedroppers-data0@psg.com; Thu, 25 Jun 2009 16:14:17 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJraO-000Hrz-Vz for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 16:14:10 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 3562FE607B; Thu, 25 Jun 2009 16:14:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5PGE0ns027138; Fri, 26 Jun 2009 02:14:00 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906251614.n5PGE0ns027138@drugs.dv.isc.org> To: Matt Larson Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Danger of coming unstuck In-reply-to: Your message of "Thu, 25 Jun 2009 11:06:22 -0400." <20090625150622.GZ1164@dul1mcmlarson-l1.labs.vrsn.com> Date: Fri, 26 Jun 2009 02:14:00 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <20090625150622.GZ1164@dul1mcmlarson-l1.labs.vrsn.com>, Matt Larson writes: > On Thu, 25 Jun 2009, Mark Andrews wrote: > > The roots don't emit EDNS answers that would be dropped due to > > fragmentation. > > All of the roots? Source, please. It's quite easy to calculate maximum referral sizes to all the TLDs. None of these is likely to trigger fragmentation today. > > EDNS@512 at the root < 1%. > > All of the roots? F root? Something else? Source, please. L and F based on the ORG traffic ananlyis pdf from the turning on of DNSSEC presented at the last NANOG meeting. > > For ORG some of the EDNS@512 will be due to fragmented responses > > not getting through but again that is < 1%. > > Do you have direct data from .org? Source, please. > > Whatever the case 1% is a over estimate. > > You have not shown data to back up this claim. > > Matt -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 13:09:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF473A69B3; Thu, 25 Jun 2009 13:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.522 X-Spam-Level: X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[AWL=-0.922, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcBNay+-dvoy; Thu, 25 Jun 2009 13:09:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 567CC28C1CF; Thu, 25 Jun 2009 13:08:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJvAE-000Cwv-TR for namedroppers-data0@psg.com; Thu, 25 Jun 2009 20:03:18 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJvA0-000Cse-Dz for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 20:03:10 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1DC5D2FE9661 for ; Thu, 25 Jun 2009 20:02:48 +0000 (UTC) Date: Thu, 25 Jun 2009 16:02:46 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Nested trust anchors (again) Message-ID: <20090625200246.GK375@shinkuro.com> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <4A4368CA.3090203@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A4368CA.3090203@nlnetlabs.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 25, 2009 at 02:08:42PM +0200, W.C.A. Wijngaards wrote: > closest is the most sensible one, because a higher trust anchor is not > particularly more trusted. Probably less trusted, since it has a > broader scope. As one of the co-chairs, I'd like to hear from working group participants feedback on the following questions: 1. Do you think that the DNSSECbis RFCs, including NSEC3, include either implicitly or explicitly a notion of "degrees of trust" of different keys? 1. a. If so, please indicate the text that you think supports this view. 1. b. If not, suggest why this departure from other security protocols is a plausible interpretation. (If you're one of the editors of the docs, saying, "Because we thought it was a good idea, and if we wanted degrees of trust we'd have included it explicitly," counts.) 2. Do you think that the DNSSECbis RFCs _should_ include that notion? If so, why, and if not, why not? Thanks, Andrew (not speaking for Olafur). -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 13:09:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24E83A6AD8; Thu, 25 Jun 2009 13:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 661aRHK6OTZN; Thu, 25 Jun 2009 13:09:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D35C128C1D1; Thu, 25 Jun 2009 13:08:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJvBL-000D3M-0i for namedroppers-data0@psg.com; Thu, 25 Jun 2009 20:04:27 +0000 Received: from [131.111.8.131] (helo=ppsw-1.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJvB5-000D1w-Ub for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 20:04:20 +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]:56169) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:cet1) id 1MJvB2-0000vG-5b (Exim 4.70) (return-path ); Thu, 25 Jun 2009 21:04:08 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1MJvB2-0000CO-NC (Exim 4.67) (return-path ); Thu, 25 Jun 2009 21:04:08 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 25 Jun 2009 21:04:08 +0100 Date: 25 Jun 2009 21:04:08 +0100 From: Chris Thompson To: Stephane Bortzmeyer Cc: Namedroppers Mailing List Reply-To: cet1@cam.ac.uk Subject: Re: [dnsext] Re: Nested trust anchors (again) Message-ID: In-Reply-To: <20090625123013.GA20593@laperouse.bortzmeyer.org> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <20090625123013.GA20593@laperouse.bortzmeyer.org> X-Mailer: Prayer v1.3.1 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 25 2009, Stephane Bortzmeyer wrote: >Without discussing of the ideal default option, I would like the draft >to mention other possible policies as well. I can see at least four, >and IMHO, there is an use case for each of them: > >* ANY trust-anchor which works (the current default policy in >dnssec-bis-updates) > >* ALL the trust-anchors must work (highly secure, for the truly >paranoids) > >* The CLOSEST trust-anchor must work (if I configure a local >trust-anchor, it is because I know what I do) > >* The HIGHEST trust-anchor must work (the root trust anchor will >probably be less stale than local ones). I am not sure that I understand exactly what these mean, in the context of securely signed insecure delegations. Suppose HIGHEST is configured and there is a trust anchor for the root, and that (say) the delegation from the root to uk is signed, but that from uk to ac.uk is not. Is a trust anchor for cam.ac.uk to be ignored in this context, and cam.ac.uk to treated as unsigned regardless? -- 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. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 13:22:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C163A67E1; Thu, 25 Jun 2009 13:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPVdrVUa8SJJ; Thu, 25 Jun 2009 13:22:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7341E3A67A3; Thu, 25 Jun 2009 13:22:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJvOq-000ENA-Fw for namedroppers-data0@psg.com; Thu, 25 Jun 2009 20:18:24 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJvOZ-000EL4-Js for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 20:18:18 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 73A152FE9664 for ; Thu, 25 Jun 2009 20:17:51 +0000 (UTC) Date: Thu, 25 Jun 2009 16:17:47 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Nested trust anchors (again) Message-ID: <20090625201739.GL375@shinkuro.com> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <20090625123013.GA20593@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090625123013.GA20593@laperouse.bortzmeyer.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [no hat] On Thu, Jun 25, 2009 at 02:30:13PM +0200, Stephane Bortzmeyer wrote: > * ALL the trust-anchors must work (highly secure, for the truly > paranoids) Does this mean, "All the trust anchors I have must work," or, "The set of my trust anchors and the set of the name server trust anchors must be equivalent"? I guess it's obvious that the latter does not allow adding keys without an outage. Neither policy would allow an emergency roll without an outage, I think. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 13:29:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3563A68A4; Thu, 25 Jun 2009 13:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.491 X-Spam-Level: X-Spam-Status: No, score=-4.491 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1bDDy4YqXqw; Thu, 25 Jun 2009 13:29:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4359A3A6817; Thu, 25 Jun 2009 13:29:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJvWF-000F36-BS for namedroppers-data0@psg.com; Thu, 25 Jun 2009 20:26:03 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJvW0-000F01-UK for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 20:25:55 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5PKOmA9012894; Thu, 25 Jun 2009 20:24:48 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5PKOmvu012893; Thu, 25 Jun 2009 20:24:48 GMT Date: Thu, 25 Jun 2009 20:24:48 +0000 From: bmanning@vacation.karoshi.com To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Nested trust anchors (again) Message-ID: <20090625202448.GA12847@vacation.karoshi.com.> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <4A4368CA.3090203@nlnetlabs.nl> <20090625200246.GK375@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090625200246.GK375@shinkuro.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: trust is binary trustworthy is not. the first test is ... is this blob trustworthy? the criteria for determining trustworthiness can be many and varied... (local policy). once the trustworthiness has been established, then the simple binary switch kicks in - yes/no. thats been my working model for, oh years and years. --bill On Thu, Jun 25, 2009 at 04:02:46PM -0400, Andrew Sullivan wrote: > On Thu, Jun 25, 2009 at 02:08:42PM +0200, W.C.A. Wijngaards wrote: > > > closest is the most sensible one, because a higher trust anchor is not > > particularly more trusted. Probably less trusted, since it has a > > broader scope. > > As one of the co-chairs, I'd like to hear from working group > participants feedback on the following questions: > > 1. Do you think that the DNSSECbis RFCs, including NSEC3, include > either implicitly or explicitly a notion of "degrees of trust" of > different keys? > > 1. a. If so, please indicate the text that you think supports this > view. > > 1. b. If not, suggest why this departure from other security > protocols is a plausible interpretation. (If you're one of the > editors of the docs, saying, "Because we thought it was a good > idea, and if we wanted degrees of trust we'd have included it > explicitly," counts.) > > 2. Do you think that the DNSSECbis RFCs _should_ include that notion? > If so, why, and if not, why not? > > Thanks, > > Andrew (not speaking for Olafur). > > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 14:40:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37053A6878; Thu, 25 Jun 2009 14:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.663 X-Spam-Level: X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=-0.169, 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 GMtfeCegkcGJ; Thu, 25 Jun 2009 14:40:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D44A63A6807; Thu, 25 Jun 2009 14:40:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJwbI-000KR2-CX for namedroppers-data0@psg.com; Thu, 25 Jun 2009 21:35:20 +0000 Received: from [209.85.219.227] (helo=mail-ew0-f227.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJwb3-000KPi-VU for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 21:35:12 +0000 Received: by ewy27 with SMTP id 27so2192651ewy.41 for ; Thu, 25 Jun 2009 14:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=kZlkU0vUPB/MXAS7cUnagFi9IkdqizOVCw4FfA+sLwI=; b=TMt3Yr0FgqfGiiQ9hdfvYAkaczGxnrQUJe/hOcMJKLrTAyXWEDx1CFOSzckXCOC4jM 6l8qjUSN+FVkEZ8l+as2WGlTl1Nvn2THTWHxAoA1N01lYjcs1aEdjvG3InaH6u8WR7LV nid/TqX0Up5aQ8QkvpB7kNBU3/I5loYN4gQic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Los43Gh2PxQCycY40SmYJN7B2DwfoC9UkgpUXuepYXPrA6miDWQ7YOnsRPQaFsEL+5 KKVJ/ZXLEpURfhIQde0YK9pJby5475jEPglkI/KzaSv9G8Z+Pf0AzPwSUhwCJ6pElR+S nBhIZ4kTSqtxjCAgM+e+Nwtn/EAJkkeuThP2M= MIME-Version: 1.0 Received: by 10.210.126.18 with SMTP id y18mr3356118ebc.79.1245965704092; Thu, 25 Jun 2009 14:35:04 -0700 (PDT) In-Reply-To: <20090625152225.GA1164@dul1mcmlarson-l1.labs.vrsn.com> References: <823a9ozrkc.fsf@mid.bfk.de> <200906251459.n5PExTFs023425@drugs.dv.isc.org> <20090625152225.GA1164@dul1mcmlarson-l1.labs.vrsn.com> From: bert hubert Date: Thu, 25 Jun 2009 23:34:44 +0200 Message-ID: <3efd34cc0906251434s38548735gb31b1bbf7c9f89b7@mail.gmail.com> Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) To: Matt Larson 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: On Thu, Jun 25, 2009 at 5:22 PM, Matt Larson wrote: > Not so. =A0See slide 22 of > https://www.dns-oarc.net/files/workshop-2008/larson.pdf: from 24 hours > of traffic to the .com/.net name servers in September 2008, only > 28.48% of queriers were EDNS0 capable. =A0Even if we assume that many of > those were bots and re-calculate the figure based on the number of > queriers that sent at least ten queries in that 24-hour interval (the > threshold for our analysis), the percentage is only 50% EDNS0 capable. So what resolver is not EDNS0 capable, except for the PowerDNS Recursor <3.= 1.8? Because I don't believe 50% of your queries come from me.. Nominum CNS perhaps? Or Windows? Or Cisco? I know this is not standards work, but as long as we don't know, any estimates we make are bound to point us in the wrong direction. Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 14:44:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 023A83A695F; Thu, 25 Jun 2009 14:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 tagged_above=-999 required=5 tests=[AWL=-0.090, 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 4DswsgypUqwt; Thu, 25 Jun 2009 14:44:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 966353A6A02; Thu, 25 Jun 2009 14:44:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJwha-000Kyj-PT for namedroppers-data0@psg.com; Thu, 25 Jun 2009 21:41:50 +0000 Received: from [209.86.89.70] (helo=elasmtp-banded.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJwhC-000Kuf-PP for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 21:41:36 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=FJgMW8SdLju7+achbDmiu83J5+a4KImf+AxroYUbTgc5E4VC9774xNYwtJkhwZkY; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.99.167] (helo=ix.netcom.com) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MJwh9-0008FV-RB; Thu, 25 Jun 2009 17:41:24 -0400 Message-ID: <4A43EEF6.31CCAE55@ix.netcom.com> Date: Thu, 25 Jun 2009 14:41:10 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] Nested trust anchors (again) References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <4A4368CA.3090203@nlnetlabs.nl> <20090625200246.GK375@shinkuro.com> <20090625202448.GA12847@vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068855f8ffabf964a7c1ac33f10266a3a740350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.99.167 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Bill and all, Yes mine also! But you know of course that local policies very greatly and as such problems of both trust and trustworthiness ensue and than fester. bmanning@vacation.karoshi.com wrote: > trust is binary > trustworthy is not. > > the first test is ... is this blob trustworthy? the criteria > for determining trustworthiness can be many and varied... (local policy). > once the trustworthiness has been established, then the simple binary > switch kicks in - yes/no. > > thats been my working model for, oh years and years. > > --bill > > On Thu, Jun 25, 2009 at 04:02:46PM -0400, Andrew Sullivan wrote: > > On Thu, Jun 25, 2009 at 02:08:42PM +0200, W.C.A. Wijngaards wrote: > > > > > closest is the most sensible one, because a higher trust anchor is not > > > particularly more trusted. Probably less trusted, since it has a > > > broader scope. > > > > As one of the co-chairs, I'd like to hear from working group > > participants feedback on the following questions: > > > > 1. Do you think that the DNSSECbis RFCs, including NSEC3, include > > either implicitly or explicitly a notion of "degrees of trust" of > > different keys? > > > > 1. a. If so, please indicate the text that you think supports this > > view. > > > > 1. b. If not, suggest why this departure from other security > > protocols is a plausible interpretation. (If you're one of the > > editors of the docs, saying, "Because we thought it was a good > > idea, and if we wanted degrees of trust we'd have included it > > explicitly," counts.) > > > > 2. Do you think that the DNSSECbis RFCs _should_ include that notion? > > If so, why, and if not, why not? > > > > Thanks, > > > > Andrew (not speaking for Olafur). > > > > > > -- > > Andrew Sullivan > > ajs@shinkuro.com > > Shinkuro, Inc. > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 15:18:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196B33A6840; Thu, 25 Jun 2009 15:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20fhfB1JkOkO; Thu, 25 Jun 2009 15:18:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 164A23A6976; Thu, 25 Jun 2009 15:18:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJxCG-000NYp-Uw for namedroppers-data0@psg.com; Thu, 25 Jun 2009 22:13:32 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJxC4-000NWP-SC for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 22:13:26 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7CF7A2FE9661 for ; Thu, 25 Jun 2009 22:13:02 +0000 (UTC) Date: Thu, 25 Jun 2009 18:13:00 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Nested trust anchors (again) Message-ID: <20090625221300.GA831@shinkuro.com> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <4A4368CA.3090203@nlnetlabs.nl> <20090625200246.GK375@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090625200246.GK375@shinkuro.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, On Thu, Jun 25, 2009 at 04:02:46PM -0400, Andrew Sullivan wrote: > 1. Do you think that the DNSSECbis RFCs, including NSEC3, include > either implicitly or explicitly a notion of "degrees of trust" of > different keys? > 1. b. If not, suggest why this departure from other security > protocols is a plausible interpretation. (If you're one of the > editors of the docs, saying, "Because we thought it was a good > idea, and if we wanted degrees of trust we'd have included it > explicitly," counts.) More than one person has pointed out to me now that there do not seem to be any _protocols_ that have this notion of fractional trust. There may be implementations. I therefore cheerfully revise this question. 1.b. IF not, suggest why you think it it does not include that notion even though many people seem to believe that fractional trust is a good thing. Someone also argued to me (off list) that the issue we really have here is not "fractional trust", but "layered trust". This seems like a possibly important distinction, but in the interests of brevity feel free to read "trust layers" where "degrees of trust" is and see if it changes your opinion. Best regards, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 15:26:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF2F3A6811; Thu, 25 Jun 2009 15:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uXYzvpajh-k; Thu, 25 Jun 2009 15:26:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B7143A6840; Thu, 25 Jun 2009 15:26:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJxLV-000OGg-JV for namedroppers-data0@psg.com; Thu, 25 Jun 2009 22:23:05 +0000 Received: from [209.85.217.218] (helo=mail-gx0-f218.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJxLE-000ODb-5D for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 22:22:56 +0000 Received: by gxk18 with SMTP id 18so3182281gxk.11 for ; Thu, 25 Jun 2009 15:22:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.56.17 with SMTP id e17mr1870604aga.10.1245968551825; Thu, 25 Jun 2009 15:22:31 -0700 (PDT) In-Reply-To: <3efd34cc0906251434s38548735gb31b1bbf7c9f89b7@mail.gmail.com> References: <823a9ozrkc.fsf@mid.bfk.de> <200906251459.n5PExTFs023425@drugs.dv.isc.org> <20090625152225.GA1164@dul1mcmlarson-l1.labs.vrsn.com> <3efd34cc0906251434s38548735gb31b1bbf7c9f89b7@mail.gmail.com> Date: Thu, 25 Jun 2009 15:22:31 -0700 Message-ID: Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) From: Matthew Dempsky To: bert hubert Cc: Matt Larson , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 25, 2009 at 2:34 PM, bert hubert wrote: > So what resolver is not EDNS0 capable, except for the PowerDNS Recursor <3.1.8? dnscache does not use EDNS0. I also just made OpenDNS's caches forward a few queries to my personal name server, and none of the queries used EDNS0. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 16:04:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 530D73A6807; Thu, 25 Jun 2009 16:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.112 X-Spam-Level: X-Spam-Status: No, score=-5.112 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 kJOXerth2kNH; Thu, 25 Jun 2009 16:04:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6D093A68C3; Thu, 25 Jun 2009 16:03:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJxuf-0000wo-Eh for namedroppers-data0@psg.com; Thu, 25 Jun 2009 22:59:25 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJxuU-0000wH-8z for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 22:59:19 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5PMx5KQ021381; Thu, 25 Jun 2009 15:59:06 -0700 (PDT) Cc: Nicholas Weaver , bert hubert , Matt Larson , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) Date: Thu, 25 Jun 2009 15:59:05 -0700 References: <823a9ozrkc.fsf@mid.bfk.de> <200906251459.n5PExTFs023425@drugs.dv.isc.org> <20090625152225.GA1164@dul1mcmlarson-l1.labs.vrsn.com> <3efd34cc0906251434s38548735gb31b1bbf7c9f89b7@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 25, 2009, at 3:22 PM, Matthew Dempsky wrote: > On Thu, Jun 25, 2009 at 2:34 PM, bert hubert > wrote: >> So what resolver is not EDNS0 capable, except for the PowerDNS >> Recursor <3.1.8? > > dnscache does not use EDNS0. > > I also just made OpenDNS's caches forward a few queries to my personal > name server, and none of the queries used EDNS0. Likewise, the Comcast DNS resolvers don't use EDNS0. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 16:05:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E333A68BB; Thu, 25 Jun 2009 16:05: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 nFkoa+zIvZj5; Thu, 25 Jun 2009 16:05:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 98BDB3A6824; Thu, 25 Jun 2009 16:05:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJxyR-0001H3-PP for namedroppers-data0@psg.com; Thu, 25 Jun 2009 23:03:19 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJxyG-0001FQ-5a for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 23:03:14 +0000 Received: from [10.49.158.175] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 7D776C2DA3; Fri, 26 Jun 2009 00:02:51 +0100 (BST) Date: Fri, 26 Jun 2009 00:02:55 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bert hubert , Matt Larson cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) Message-ID: In-Reply-To: <3efd34cc0906251434s38548735gb31b1bbf7c9f89b7@mail.gmail.com> References: <823a9ozrkc.fsf@mid.bfk.de> <200906251459.n5PExTFs023425@drugs.dv.isc.org> <20090625152225.GA1164@dul1mcmlarson-l1.labs.vrsn.com> <3efd34cc0906251434s38548735gb31b1bbf7c9f89b7@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 25 June 2009 23:34:44 +0200 bert hubert wrote: > So what resolver is not EDNS0 capable, except for the PowerDNS Recursor > <3.1.8? > > Because I don't believe 50% of your queries come from me.. > > Nominum CNS perhaps? Or Windows? Or Cisco? Guessing here, but $middlebox may contribute to this percentage. -- Alex Bligh -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 16:10:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECDA83A6A02; Thu, 25 Jun 2009 16:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[AWL=-0.140, 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 DbrXncqc2C0E; Thu, 25 Jun 2009 16:10:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A25863A68A8; Thu, 25 Jun 2009 16:10:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJy1s-0001Zm-Hn for namedroppers-data0@psg.com; Thu, 25 Jun 2009 23:06:52 +0000 Received: from [209.85.219.227] (helo=mail-ew0-f227.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJy1h-0001Y9-9j for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 23:06:46 +0000 Received: by ewy27 with SMTP id 27so2257941ewy.41 for ; Thu, 25 Jun 2009 16:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=/vXtpmCE2ZsM6hbYTPmLSkq4VUFOEQmnFDEgszs67Fw=; b=pQ9IC2GeQ4ecAFFc2DhjegiIubc6Rb/1uCeTKtZTzYTHKlGD2eb6fXOIbn0zxUhMPt 4wuQV8JtKoU/IdHaj70EKGlvKRBDWTmGMIxZ5C0C11Ve0CjA5237Um6XSzFX5XfWWc/V 9ELLtfeYqrkjGkkD751JFn83EqLkFNGPKFDTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=C07mxbyUZ0p/ZyjboyjSjZQcX3sFwYDghBQKeWqBbx4BdQncdJRmTIOjuiuhLdPcBc 73wxpECjXbwcrB6qs8+5bV/+pAdX2GmSsk4pLxo5SsZJpDwYEFw2wHN+4yxwJyc3ul2N M5o2XQybJLxtunXMETOc2S8zhHxbucSU3DyRs= MIME-Version: 1.0 Received: by 10.210.127.10 with SMTP id z10mr2794826ebc.46.1245971200095; Thu, 25 Jun 2009 16:06:40 -0700 (PDT) In-Reply-To: References: <823a9ozrkc.fsf@mid.bfk.de> <200906251459.n5PExTFs023425@drugs.dv.isc.org> <20090625152225.GA1164@dul1mcmlarson-l1.labs.vrsn.com> <3efd34cc0906251434s38548735gb31b1bbf7c9f89b7@mail.gmail.com> From: bert hubert Date: Fri, 26 Jun 2009 01:06:20 +0200 Message-ID: <3efd34cc0906251606l3c7684b9n36f4bdca64c742ad@mail.gmail.com> Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) To: Alex Bligh Cc: Matt Larson , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 26, 2009 at 1:02 AM, Alex Bligh wrote: >> So what resolver is not EDNS0 capable, except for the PowerDNS Recursor >> <3.1.8? >> >> Because I don't believe 50% of your queries come from me.. >> >> Nominum CNS perhaps? Or Windows? Or Cisco? > > Guessing here, but $middlebox may contribute to this percentage. I've always wondered - what are these famed "middleboxes"? Any large resolver will not be hiding behind a firewall that interferes, nor will it be hosted on a network with a captive portal. Stubs generally don't talk to GTLD servers either. So what does sit in between? Bert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 16:11:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326233A68A8; Thu, 25 Jun 2009 16:11:10 -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 Lz1Pb2lFYAsh; Thu, 25 Jun 2009 16:11:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 511923A68A4; Thu, 25 Jun 2009 16:11:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJy34-0001fd-7z for namedroppers-data0@psg.com; Thu, 25 Jun 2009 23:08:06 +0000 Received: from [2001:470:1f04:392::2] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJy2q-0001dv-EY for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 23:08:00 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5PN7nVY030356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jun 2009 16:07:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090625200246.GK375@shinkuro.com> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <4A4368CA.3090203@nlnetlabs.nl> <20090625200246.GK375@shinkuro.com> Date: Thu, 25 Jun 2009 16:07:48 -0700 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] Nested trust anchors (again) Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 4:02 PM -0400 6/25/09, Andrew Sullivan wrote: >1. Do you think that the DNSSECbis RFCs, including NSEC3, include >either implicitly or explicitly a notion of "degrees of trust" of >different keys? No. > 1.b. IF not, suggest why you think it it does not include that > notion even though many people seem to believe that fractional > trust is a good thing. It's fine that many people seem to think that: however, that does not mean we should promote it by including it in a base document. The documents should allow trust models that include fractional trust, layered trust, and something-that-we-invented-ourselves trust, but should only explicitly talk about the simplest and most common form of trust, full trust. --Paul Hoffman, Director --VPN Consortium -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 16:42:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060A83A68D8; Thu, 25 Jun 2009 16:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.491 X-Spam-Level: X-Spam-Status: No, score=-4.491 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmhObxz4LGOv; Thu, 25 Jun 2009 16:42:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E93D3A67A3; Thu, 25 Jun 2009 16:42:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJyXK-0005SJ-DC for namedroppers-data0@psg.com; Thu, 25 Jun 2009 23:39:22 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJyWz-0005Qt-7K for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 23:39:08 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5PNbvA9014192; Thu, 25 Jun 2009 23:37:57 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5PNbvCf014191; Thu, 25 Jun 2009 23:37:57 GMT Date: Thu, 25 Jun 2009 23:37:56 +0000 From: bmanning@vacation.karoshi.com To: bert hubert Cc: namedroppers@ops.ietf.org Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) Message-ID: <20090625233756.GA14000@vacation.karoshi.com.> References: <823a9ozrkc.fsf@mid.bfk.de> <200906251459.n5PExTFs023425@drugs.dv.isc.org> <20090625152225.GA1164@dul1mcmlarson-l1.labs.vrsn.com> <3efd34cc0906251434s38548735gb31b1bbf7c9f89b7@mail.gmail.com> <3efd34cc0906251606l3c7684b9n36f4bdca64c742ad@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3efd34cc0906251606l3c7684b9n36f4bdca64c742ad@mail.gmail.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: oh the list is long and distinguished. http://www.icann.org/en/committees/security/ssac-documents.htm look at SAC035 --bill On Fri, Jun 26, 2009 at 01:06:20AM +0200, bert hubert wrote: > On Fri, Jun 26, 2009 at 1:02 AM, Alex Bligh wrote: > >> So what resolver is not EDNS0 capable, except for the PowerDNS Recursor > >> <3.1.8? > >> > >> Because I don't believe 50% of your queries come from me.. > >> > >> Nominum CNS perhaps? Or Windows? Or Cisco? > > > > Guessing here, but $middlebox may contribute to this percentage. > > I've always wondered - what are these famed "middleboxes"? Any large > resolver will not be hiding behind a firewall that interferes, nor > will it be hosted on a network with a captive portal. > > Stubs generally don't talk to GTLD servers either. > > So what does sit in between? > > Bert > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 16:54:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769CF3A68FF; Thu, 25 Jun 2009 16:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 E2dJyWDRqnKj; Thu, 25 Jun 2009 16:54:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8BE153A68C3; Thu, 25 Jun 2009 16:54:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJyig-0006mA-8P for namedroppers-data0@psg.com; Thu, 25 Jun 2009 23:51:06 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJyhF-0006ac-Sh for namedroppers@ops.ietf.org; Thu, 25 Jun 2009 23:50:18 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5PNnBX7027526; Thu, 25 Jun 2009 16:49:11 -0700 (PDT) Cc: Nicholas Weaver , Alex Bligh , Matt Larson , namedroppers@ops.ietf.org Message-Id: <3722FEFB-F4BC-4F1A-989A-C4C4BEE1C629@icsi.berkeley.edu> From: Nicholas Weaver To: bert hubert In-Reply-To: <3efd34cc0906251606l3c7684b9n36f4bdca64c742ad@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) Date: Thu, 25 Jun 2009 16:49:10 -0700 References: <823a9ozrkc.fsf@mid.bfk.de> <200906251459.n5PExTFs023425@drugs.dv.isc.org> <20090625152225.GA1164@dul1mcmlarson-l1.labs.vrsn.com> <3efd34cc0906251434s38548735gb31b1bbf7c9f89b7@mail.gmail.com> <3efd34cc0906251606l3c7684b9n36f4bdca64c742ad@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 25, 2009, at 4:06 PM, bert hubert wrote: > On Fri, Jun 26, 2009 at 1:02 AM, Alex Bligh wrote: >>> So what resolver is not EDNS0 capable, except for the PowerDNS >>> Recursor >>> <3.1.8? >>> >>> Because I don't believe 50% of your queries come from me.. >>> >>> Nominum CNS perhaps? Or Windows? Or Cisco? >> >> Guessing here, but $middlebox may contribute to this percentage. > > I've always wondered - what are these famed "middleboxes"? A lot of firewalls have DNS modules, as do a lot of NATs, and a lot of these may have bugs. A common one, for example, is assuming that DNS packets don't fragment. > Any large > resolver will not be hiding behind a firewall that interferes, nor > will it be hosted on a network with a captive portal. I agree with the latter, but NOT the former. I'm working on a releasable writeup, but it is shocking the # of resolvers which advertise EDNS0 but can't receive a >1800B EDNS-enabled response. However, the experience on the probing from the end user's connection to our server suggests that middleboxes might easily assume that DNS is <512B, or that DNS packets don't fragment, but it is the rare rare such box that assumes that EDNS0 is invalid and drops it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 17:24:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59303A67E2; Thu, 25 Jun 2009 17:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.829 X-Spam-Level: * X-Spam-Status: No, score=1.829 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RCVD_IN_NJABL_PROXY=1.643, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbSerHkV4d7Z; Thu, 25 Jun 2009 17:24:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A01B03A689B; Thu, 25 Jun 2009 17:23:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJz9W-0009ej-FY for namedroppers-data0@psg.com; Fri, 26 Jun 2009 00:18:50 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJz9K-0009cl-NJ for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 00:18:44 +0000 Received: (qmail 81327 invoked from network); 26 Jun 2009 01:55:33 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 26 Jun 2009 01:55:33 -0000 Message-ID: <4A4413A1.90002@necom830.hpcl.titech.ac.jp> Date: Fri, 26 Jun 2009 09:17:37 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Sabahattin Gucukoglu CC: Nicholas Weaver , namedroppers@ops.ietf.org Subject: Re: [dnsext] Glue Caching Misbehaviours References: <2F9189CD-58A8-46B1-88C7-AC4D4BA2127F@sabahattin-gucukoglu.com> <0C56E994-CE14-4811-B3FB-DC2B78E78AAC@icsi.berkeley.edu> <04840579-9922-4435-9C2E-0E2A0B98501A@sabahattin-gucukoglu.com> In-Reply-To: <04840579-9922-4435-9C2E-0E2A0B98501A@sabahattin-gucukoglu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Sabahattin Gucukoglu wrote: > All of this sort of nonsense goes away when we stop making assumptions > about additional data from parent zones, as we should from the start. A difference between glue and other additonal data is that, unlike other additional data, which can be queried separately, glue is necessary for further queries beyond a refferal. Glue in a refferal answer to a query may be cached, as long as the cache is used only for glue of a cached refferal answer to a query identical to the original query. Or, the entire refferal should not be cached. Half hearted caching of NS without glue will make the glued NS unusable. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 17:24:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669663A67E2; Thu, 25 Jun 2009 17:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uH20fjJb912Z; Thu, 25 Jun 2009 17:24:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A0FB43A69C3; Thu, 25 Jun 2009 17:23:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJzBc-0009oT-Ro for namedroppers-data0@psg.com; Fri, 26 Jun 2009 00:21:00 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MJzBR-0009ne-GD for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 00:20:55 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 486BDE6070; Fri, 26 Jun 2009 00:20:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5Q0KeL1031846; Fri, 26 Jun 2009 10:20:41 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906260020.n5Q0KeL1031846@drugs.dv.isc.org> To: Nicholas Weaver Cc: bert hubert , Alex Bligh , Matt Larson , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) In-reply-to: Your message of "Thu, 25 Jun 2009 16:49:10 MST." <3722FEFB-F4BC-4F1A-989A-C4C4BEE1C629@icsi.berkeley.edu> Date: Fri, 26 Jun 2009 10:20:40 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <3722FEFB-F4BC-4F1A-989A-C4C4BEE1C629@icsi.berkeley.edu>, Nicholas W eaver writes: > > On Jun 25, 2009, at 4:06 PM, bert hubert wrote: > > > On Fri, Jun 26, 2009 at 1:02 AM, Alex Bligh wrote: > >>> So what resolver is not EDNS0 capable, except for the PowerDNS > >>> Recursor > >>> <3.1.8? > >>> > >>> Because I don't believe 50% of your queries come from me.. > >>> > >>> Nominum CNS perhaps? Or Windows? Or Cisco? > >> > >> Guessing here, but $middlebox may contribute to this percentage. > > > > I've always wondered - what are these famed "middleboxes"? > > A lot of firewalls have DNS modules, as do a lot of NATs, and a lot of > these may have bugs. A common one, for example, is assuming that DNS > packets don't fragment. > > > Any large > > resolver will not be hiding behind a firewall that interferes, nor > > will it be hosted on a network with a captive portal. > > I agree with the latter, but NOT the former. I'm working on a > releasable writeup, but it is shocking the # of resolvers which > advertise EDNS0 but can't receive a >1800B EDNS-enabled response. > > However, the experience on the probing from the end user's connection > to our server suggests that middleboxes might easily assume that DNS > is <512B, or that DNS packets don't fragment, but it is the rare rare > such box that assumes that EDNS0 is invalid and drops it. And iterative resolvers work around such breakages because they are a fact of life on the Internet that just has to be dealt with. No authoritative server operator should fear turning on EDNS anymore though some do. "but the lookups work with this other nameserver" is enough to get the problem addressed in most cases. These boxes fall into "it would be nice to get them all fixed but it is not critical that it be done" category. They don't cause the recovery strategies to be triggered often enough to be a worry. Vendors should be made aware of the faults so the next generation of the box doesn't have the same fault. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 19:03:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4903A6A6F; Thu, 25 Jun 2009 19:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.491 X-Spam-Level: X-Spam-Status: No, score=-4.491 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2geQTfrFmio0; Thu, 25 Jun 2009 19:03:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 07FC83A687C; Thu, 25 Jun 2009 19:03:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK0ho-000HBS-Lb for namedroppers-data0@psg.com; Fri, 26 Jun 2009 01:58:20 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK0hZ-000H90-3k for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 01:58: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 n5Q1v4A9014994; Fri, 26 Jun 2009 01:57:04 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5Q1v4vQ014993; Fri, 26 Jun 2009 01:57:04 GMT Date: Fri, 26 Jun 2009 01:57:04 +0000 From: bmanning@vacation.karoshi.com To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Nested trust anchors (again) Message-ID: <20090626015704.GB14770@vacation.karoshi.com.> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <4A4368CA.3090203@nlnetlabs.nl> <20090625200246.GK375@shinkuro.com> <20090625221300.GA831@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090625221300.GA831@shinkuro.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 25, 2009 at 06:13:00PM -0400, Andrew Sullivan wrote: > Dear colleagues, > > On Thu, Jun 25, 2009 at 04:02:46PM -0400, Andrew Sullivan wrote: > > > 1. Do you think that the DNSSECbis RFCs, including NSEC3, include > > either implicitly or explicitly a notion of "degrees of trust" of > > different keys? > > > 1. b. If not, suggest why this departure from other security > > protocols is a plausible interpretation. (If you're one of the > > editors of the docs, saying, "Because we thought it was a good > > idea, and if we wanted degrees of trust we'd have included it > > explicitly," counts.) > > More than one person has pointed out to me now that there do not seem > to be any _protocols_ that have this notion of fractional trust. > There may be implementations. I therefore cheerfully revise this > question. then perhaps your are listening to the wrong sorts of people.. Bradley R. Smith and J.J. Garcia-Luna-Aceves have worked for years on "mulit-policy" models - although primarily for routing systems. From Brads web page... "The goal of my PhD work was to enhance the Internet's current distributed, hop-by-hop routing architecture to support a default multi-policy forwarding model as compared with the traditional default single-policy forwarding model. The concrete implication of this change in assumptions is that the dramatic jump in expected policy-route request rates makes the costs of on-demand, string-style policy-based routing unacceptable. " I hijacked some of his ideas earlier this decade in work on the "DISCOVER" opcode, which was rejected by this WG. that said, you are likely correct that no current IETF maintained protocol supports anything other than "on-demand, string-style, policy". > > 1.b. IF not, suggest why you think it it does not include that > notion even though many people seem to believe that fractional > trust is a good thing. > > Someone also argued to me (off list) that the issue we really have > here is not "fractional trust", but "layered trust". This seems like > a possibly important distinction, but in the interests of brevity feel > free to read "trust layers" where "degrees of trust" is and see if it > changes your opinion. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 23:44:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D7113A699F; Thu, 25 Jun 2009 23:44:37 -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 kj-eIqDoRQ+p; Thu, 25 Jun 2009 23:44:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B1CA3A699D; Thu, 25 Jun 2009 23:44:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK55R-000CSV-4K for namedroppers-data0@psg.com; Fri, 26 Jun 2009 06:39:01 +0000 Received: from [2001:470:1f12:420::2] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK555-000CQh-VQ for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 06:38:47 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 4570274004; Fri, 26 Jun 2009 08:38:37 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id 27593157884; Fri, 26 Jun 2009 08:32:08 +0200 (CEST) Date: Fri, 26 Jun 2009 08:32:08 +0200 From: Stephane Bortzmeyer To: Chris Thompson Cc: Namedroppers Mailing List Subject: [dnsext] Re: Nested trust anchors (again) Message-ID: <20090626063208.GA25713@laperouse.bortzmeyer.org> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <20090625123013.GA20593@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 8.10 (intrepid) User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 25, 2009 at 09:04:08PM +0100, Chris Thompson wrote a message of 29 lines which said: > I am not sure that I understand exactly what these mean, Well, if I have time, I will rewrite it in proper I-D style. > Suppose HIGHEST is configured and there is a trust anchor for the > root, and that (say) the delegation from the root to uk is signed, > but that from uk to ac.uk is not. Is a trust anchor for cam.ac.uk to > be ignored in this context, and cam.ac.uk to treated as unsigned > regardless? Not at all. All four policies I listed are in the case where more than one key (one trust anchor) can be used for validation (for starting a chain of trust). In the case you mention, the root key cannot be used (because it stops at ac.uk). So, in your example, only one key is usable (cam.ac.uk) and this discussion does not apply. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 25 23:44:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8440E3A699F; Thu, 25 Jun 2009 23:44: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 Vo37ytmLafcs; Thu, 25 Jun 2009 23:44:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A34C83A699D; Thu, 25 Jun 2009 23:44:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK55J-000CS4-I0 for namedroppers-data0@psg.com; Fri, 26 Jun 2009 06:38:53 +0000 Received: from [2001:470:1f12:420::2] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK555-000CQi-VQ for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 06:38:47 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 2578B74003; Fri, 26 Jun 2009 08:38:37 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id 14E81157884; Fri, 26 Jun 2009 08:36:39 +0200 (CEST) Date: Fri, 26 Jun 2009 08:36:39 +0200 From: Stephane Bortzmeyer To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: [dnsext] Re: Nested trust anchors (again) Message-ID: <20090626063639.GB25713@laperouse.bortzmeyer.org> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <20090625123013.GA20593@laperouse.bortzmeyer.org> <20090625201739.GL375@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090625201739.GL375@shinkuro.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 8.10 (intrepid) User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Jun 25, 2009 at 04:17:47PM -0400, Andrew Sullivan wrote a message of 23 lines which said: > Does this mean, "All the trust anchors I have must work," or, "The > set of my trust anchors and the set of the name server trust anchors > must be equivalent"? I don't understand the second. What is "the set of the name server trust anchors"? The DNSKEY found in the DNS and verified through DS? If so, I would not call them trust anchors. > Neither policy would allow an emergency roll without an outage, I > think. I did not suggest it to be the default policy. It just seemed to me that some people may find it useful. My idea was to write something like "These policies may [lowercase] be useful for some users so a validating resolver MAY [RFC2119] allow them to be enabled via a configuration option." And we could add warnings such as yours. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 01:06:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF5943A6849; Fri, 26 Jun 2009 01:06: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=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxB+SVnddPpD; Fri, 26 Jun 2009 01:06:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 22B4F3A683A; Fri, 26 Jun 2009 01:06:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK6L8-000IDZ-3r for namedroppers-data0@psg.com; Fri, 26 Jun 2009 07:59:18 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK6Kx-000IBv-8f for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 07:59:12 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 516E1C2DA3; Fri, 26 Jun 2009 08:59:05 +0100 (BST) Date: Fri, 26 Jun 2009 08:58:17 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bert hubert cc: Matt Larson , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) Message-ID: In-Reply-To: <3efd34cc0906251606l3c7684b9n36f4bdca64c742ad@mail.gmail.com> References: <823a9ozrkc.fsf@mid.bfk.de> <200906251459.n5PExTFs023425@drugs.dv.isc.org> <20090625152225.GA1164@dul1mcmlarson-l1.labs.vrsn.com> <3efd34cc0906251434s38548735gb31b1bbf7c9f89b7@mail.gmail.com> <3efd34cc0906251606l3c7684b9n36f4bdca64c742ad@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 26 June 2009 01:06:20 +0200 bert hubert wrote: > On Fri, Jun 26, 2009 at 1:02 AM, Alex Bligh wrote: >>> So what resolver is not EDNS0 capable, except for the PowerDNS Recursor >>> <3.1.8? >>> >>> Because I don't believe 50% of your queries come from me.. >>> >>> Nominum CNS perhaps? Or Windows? Or Cisco? >> >> Guessing here, but $middlebox may contribute to this percentage. > > I've always wondered - what are these famed "middleboxes"? Perhaps I haven't been following the thread, but I hadn't thought that figure was just from large resolvers. I was referring to some of the middleboxen written by those who should have read draft-ietf-dnsext-dnsproxy first, i.e. either filtering queries, or acting as a broken forwarder. I would guess this is mainly consumer/SME CPE, but the world is not short of broken firewalls for larger organisations either. -- Alex Bligh -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 01:27:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AAC73A684C; Fri, 26 Jun 2009 01:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlsqZz3v3wpt; Fri, 26 Jun 2009 01:27:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 050BF3A6849; Fri, 26 Jun 2009 01:27:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK6hv-000Jpb-EF for namedroppers-data0@psg.com; Fri, 26 Jun 2009 08:22:51 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK6hZ-000Jny-A2 for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 08:22:44 +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 1MK6jx-0000Vc-RY; Fri, 26 Jun 2009 10:24:57 +0200 Received: by bfk.de with local id 1MK6hV-0008Sc-26; Fri, 26 Jun 2009 10:22:25 +0200 To: Mark Andrews Cc: Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org, Paul Vixie Subject: Re: [dnsext] Danger of coming unstuck References: <200906251454.n5PEsRWe023320@drugs.dv.isc.org> From: Florian Weimer Date: Fri, 26 Jun 2009 10:22:25 +0200 In-Reply-To: <200906251454.n5PEsRWe023320@drugs.dv.isc.org> (Mark Andrews's message of "Fri\, 26 Jun 2009 00\:54\:27 +1000") Message-ID: <82y6rfl7zy.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: * Mark Andrews: > And the answers the roots produce don't get big enough to trigger > fragmentation on current links. The last time I saw a fragmented response from a root server was less then a year ago. *shrug* --=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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 01:37:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645713A687F; Fri, 26 Jun 2009 01:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[AWL=-1.275, 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 wrhR+3PXr8CM; Fri, 26 Jun 2009 01:37:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 894463A67A4; Fri, 26 Jun 2009 01:37:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK6sd-000KaY-On for namedroppers-data0@psg.com; Fri, 26 Jun 2009 08:33:55 +0000 Received: from [85.17.178.138] (helo=rotring.dds.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK6sO-000KZd-L8 for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 08:33:50 +0000 Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 0AAED272D72; Fri, 26 Jun 2009 10:33:40 +0200 (CEST) Received: from [192.168.254.8] (unknown [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 ESMTP id 4FDBE272CBA; Fri, 26 Jun 2009 10:33:34 +0200 (CEST) Message-ID: <4A4487DD.302@nlnetlabs.nl> Date: Fri, 26 Jun 2009 10:33:33 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Stephane Bortzmeyer CC: Chris Thompson , Namedroppers Mailing List Subject: Re: [dnsext] Re: Nested trust anchors (again) References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <20090625123013.GA20593@laperouse.bortzmeyer.org> <20090626063208.GA25713@laperouse.bortzmeyer.org> In-Reply-To: <20090626063208.GA25713@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9508/Fri Jun 26 07:17:57 2009 on rotring X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hi Stephane, Chris, >> Suppose HIGHEST is configured and there is a trust anchor for the >> root, and that (say) the delegation from the root to uk is signed, >> but that from uk to ac.uk is not. Is a trust anchor for cam.ac.uk to >> be ignored in this context, and cam.ac.uk to treated as unsigned >> regardless? > > Not at all. All four policies I listed are in the case where more than > one key (one trust anchor) can be used for validation (for starting a > chain of trust). In the case you mention, the root key cannot be used > (because it stops at ac.uk). So, in your example, only one key is > usable (cam.ac.uk) and this discussion does not apply. I think this needs text in dnssec-bis-updates. You try all keys, but they have to provide a chain of trust that passes the closest trustanchor (in a secure state). This to prevent downgrade. So, this does full trust for all anchors, but the rule makes sure that the anchor actually covers the domain of interest with security. And the original closest trust-anchor, if not used because it is stale, becomes a statement that the trust anchor domain name must be signed. Best regards, Wouter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 01:40:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F1B3A684C; Fri, 26 Jun 2009 01:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=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 MtcAt8AxeLke; Fri, 26 Jun 2009 01:40:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5558B3A67A4; Fri, 26 Jun 2009 01:40:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK6vy-000Kok-33 for namedroppers-data0@psg.com; Fri, 26 Jun 2009 08:37:22 +0000 Received: from [94.198.152.69] (helo=arn1-kamx.sidn.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK6vi-000Kmy-L7 for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 08:37:16 +0000 Received: from sidn.nl ([192.168.2.12]) by arn1-kamx.sidn.nl with ESMTP id n5Q8b4a4024557 for ; Fri, 26 Jun 2009 10:37:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [dnsext] Re: Nested trust anchors (again) Date: Fri, 26 Jun 2009 10:38:56 +0200 Message-ID: <850A39016FA57A4887C0AA3C8085F949DD3DEF@KAEVS1.SIDN.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] Re: Nested trust anchors (again) Thread-Index: Acn1lJXbt/CJ5DhARJiX2ugpfR4f6gAnVR0g References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <20090625123013.GA20593@laperouse.bortzmeyer.org> From: "Antoin Verschuren" To: "Namedroppers Mailing List" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I have an extra argument in favor of the ANY should work policy, and = that it's unwise to use the ALL or CLOSEST policy in default validators. I would actually want to expand the ANY policy. DNS is not static. Chains of trusts change. With the ALL or CLOSEST policy, you don't support these changes, and = validation will fail during certain transactions that do happen in the = real world. These changes are completely legitimate. As explained in a message to the IETF DNSOPS mailinglist on RFC4641bis, = there is an operational difficulty to maintain trust when a delegation = changes at a parent because of caching. I want to expand the ANY policy by mandating that in case a chain of = trust fails because a cached DNSKEY record cannot validate a newly = received response for which the DNSKEY record should be validated = against, that the validator MUST seek a new chain of trust by querying = the parent to see if the delegation (NS and DS) and therefore chain of = trust has changed before returning a failure. If the delegation has changed, the cached DNSKEY record MUST be = discarded and deleted from the cache. I don't know if resolver or validation behavior like this can be = mandated in dnssec-bis-updates or any other document, but if we can, we = will certainly make life easier for dns-operators without introducing = too insecure operational practices or abandoning the chain of trust = model in DNSSEC. It will also keep the core value of DNS in that it works, instead of "it = only works when it is static and does not change". Or have I missed something, and is this already mandated ? Thinking more deeply, I think ANY should be a default policy, with the = extra behavior as described. HIGHEST can be a wise policy, also with the suggested extra behaviour, = if systems are maintained well when root trust anchors change. (are they = ?) I don't see any real world deployment for ALL or CLOSEST other than = paranoid monitoring purposes to inform that chains of trust have changed = (legitimately) or on private networks for zones that are not officially = delegated. So there are use cases for that, but not for a resolver on = the real Internet that is supposed to work when resolving a name the = same as without DNSSEC. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl = http://www.sidn.nl/ > -----Original Message----- > From: owner-namedroppers@ops.ietf.org [mailto:owner- > namedroppers@ops.ietf.org] On Behalf Of Stephane Bortzmeyer > Sent: Thursday, June 25, 2009 2:30 PM > To: Matt Larson > Cc: Namedroppers Mailing List > Subject: [dnsext] Re: Nested trust anchors (again) >=20 > On Tue, Jun 23, 2009 at 10:33:36AM -0400, > Matt Larson wrote > a message of 149 lines which said: >=20 > > the latest version of the dnssec-bis-updates draft calls for trying > > all trust anchors until one succeeds. The draft also calls for a > > configurable option to enable favoring the closest trust anchor to > > the QNAME. >=20 > Without discussing of the ideal default option, I would like the draft > to mention other possible policies as well. I can see at least four, > and IMHO, there is an use case for each of them: >=20 > * ANY trust-anchor which works (the current default policy in > dnssec-bis-updates) >=20 > * ALL the trust-anchors must work (highly secure, for the truly > paranoids) >=20 > * The CLOSEST trust-anchor must work (if I configure a local > trust-anchor, it is because I know what I do) >=20 > * The HIGHEST trust-anchor must work (the root trust anchor will > probably be less stale than local ones). >=20 >=20 >=20 > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org = with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 02:11:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 142AE3A68ED; Fri, 26 Jun 2009 02:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuphCWiM2Wbj; Fri, 26 Jun 2009 02:11:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3CF5D3A67A4; Fri, 26 Jun 2009 02:11:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK7NT-000Mzz-En for namedroppers-data0@psg.com; Fri, 26 Jun 2009 09:05:47 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK7NI-000Mz7-DF for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 09:05:41 +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 1MK7Ph-0004lo-BA; Fri, 26 Jun 2009 11:08:05 +0200 Received: by bfk.de with local id 1MK7NE-0002Hl-Jx; Fri, 26 Jun 2009 11:05:32 +0200 To: "Antoin Verschuren" Cc: "Namedroppers Mailing List" Subject: Re: [dnsext] Re: Nested trust anchors (again) References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <20090625123013.GA20593@laperouse.bortzmeyer.org> <850A39016FA57A4887C0AA3C8085F949DD3DEF@KAEVS1.SIDN.local> From: Florian Weimer Date: Fri, 26 Jun 2009 11:05:32 +0200 In-Reply-To: <850A39016FA57A4887C0AA3C8085F949DD3DEF@KAEVS1.SIDN.local> (Antoin Verschuren's message of "Fri\, 26 Jun 2009 10\:38\:56 +0200") Message-ID: <82ocsbl603.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: * Antoin Verschuren: > DNS is not static. > Chains of trusts change. Uhm, since the chain is tied to the name, how is this possible? --=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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 02:30:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0923A68A5; Fri, 26 Jun 2009 02:30:06 -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=[AWL=0.000, 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 YupU18Jk2udW; Fri, 26 Jun 2009 02:30:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8E5703A689F; Fri, 26 Jun 2009 02:30:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK7iB-000Obg-0v for namedroppers-data0@psg.com; Fri, 26 Jun 2009 09:27:11 +0000 Received: from [2001:470:1f12:420::2] (helo=mail.bortzmeyer.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK7i0-000OaT-0K for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 09:27:05 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id BA88774001; Fri, 26 Jun 2009 11:26:56 +0200 (CEST) Received: by horcrux (Postfix, from userid 1000) id 5B97A157884; Fri, 26 Jun 2009 11:26:40 +0200 (CEST) Date: Fri, 26 Jun 2009 11:26:40 +0200 From: Stephane Bortzmeyer To: Florian Weimer Cc: Antoin Verschuren , Namedroppers Mailing List Subject: [dnsext] Re: Nested trust anchors (again) Message-ID: <20090626092640.GA18268@laperouse.bortzmeyer.org> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <20090625123013.GA20593@laperouse.bortzmeyer.org> <850A39016FA57A4887C0AA3C8085F949DD3DEF@KAEVS1.SIDN.local> <82ocsbl603.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82ocsbl603.fsf@mid.bfk.de> X-Transport: UUCP rules X-Operating-System: Ubuntu 8.10 (intrepid) User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 26, 2009 at 11:05:32AM +0200, Florian Weimer wrote a message of 17 lines which said: > > Chains of trusts change. > > Uhm, since the chain is tied to the name, how is this possible? I believe Antoin referred to scenarios like (for a validation of www.weimer.example): 1) * The root is signed and my resolver has a trust anchor for it * .example is not signed * weimer.example is signed and my resolver has a trust anchor for it 2) .example gets signed and the root publishes a DS Then, a new chain of trust appeared, which was not there before. Remember that the manager of the root announced a signature in 2009 and the manager of .com a signature in 2011-2012, so this scenario will be very common. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 02:48:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418413A67E6; Fri, 26 Jun 2009 02:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.261 X-Spam-Level: X-Spam-Status: No, score=-4.261 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UnWeFMeX3sy; Fri, 26 Jun 2009 02:48:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 276C93A6784; Fri, 26 Jun 2009 02:48:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK7yx-0000BM-V1 for namedroppers-data0@psg.com; Fri, 26 Jun 2009 09:44:31 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK7yk-00009U-H3; Fri, 26 Jun 2009 09:44:25 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=iAUmkbSRey/eGF5pP2BRm7hg1XMFeQcxtMxhN7A91SBTyWykxV7lp9pK rrSC8QnQtjzRHuTBLJnaiPPMrjDwCgQSYy/jgENN90OVS6oXvEq6R3BZ6 /jtbtdNAnetF3b3; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1246009458; x=1277545458; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20Real =20data=20(was=20Re:=20[dnsext]=20Danger=20of=20coming=20 unstuck)|Date:=20Fri,=2026=20Jun=202009=2010:43:07=20+010 0|Message-ID:=20|To:=20bmanning@vacation .karoshi.com|Cc:=20namedroppers@ops.ietf.org,=0D=0A=09own er-namedroppers@ops.ietf.org|MIME-Version:=201.0 |In-Reply-To:=20<20090625233756.GA14000@vacation.karoshi. com.>|References:=20<823a9ozrkc.fsf@mid.bfk.de>=20<200906 251459.n5PExTFs023425@drugs.dv.isc.org>=20<20090625152225 .GA1164@dul1mcmlarson-l1.labs.vrsn.com>=20<3efd34cc090625 1434s38548735gb31b1bbf7c9f89b7@mail.gmail.com>=20=20<3efd34cc0906251606l3c7 684b9n36f4bdca64c742ad@mail.gmail.com>=20<20090625233756. GA14000@vacation.karoshi.com.>; bh=ezl83qUWFiinDJwXw3F6r7x/5XYHzecYYEb9kh12nYg=; b=ppfmqiAM93LuGF9Qr6TjZHu6LehGR45CjT9o0T30diK8SnVsGVLXOGbG 1F6FDbjHbptiYo/6MHDw9gOAUTQqAkBllmCMGo+LYwWJZw49oCayp5r7u PYkpaSsFAMzwDsM; X-IronPort-AV: E=Sophos;i="4.42,295,1243810800"; d="scan'208";a="15146374" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 26 Jun 2009 10:43:13 +0100 In-Reply-To: <20090625233756.GA14000@vacation.karoshi.com.> References: <823a9ozrkc.fsf@mid.bfk.de> <200906251459.n5PExTFs023425@drugs.dv.isc.org> <20090625152225.GA1164@dul1mcmlarson-l1.labs.vrsn.com> <3efd34cc0906251434s38548735gb31b1bbf7c9f89b7@mail.gmail.com> <3efd34cc0906251606l3c7684b9n36f4bdca64c742ad@mail.gmail.com> <20090625233756.GA14000@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com Cc: namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 26 Jun 2009 10:43:07 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 26/06/2009 10:43:16 AM, Serialize complete at 26/06/2009 10:43:16 AM Content-Type: multipart/alternative; boundary="=_alternative 003562D8802575E1_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 003562D8802575E1_= Content-Type: text/plain; charset="US-ASCII" > oh the list is long and distinguished. > > http://www.icann.org/en/committees/security/ssac-documents.htm > look at SAC035 Much as I appreciate the citation, I don't believe it's relevant. The middleboxes that we tested were consumer level devices, where recursive queries from stubs were addressed directly to the DNS proxies sat therein and then forwarded to "real" recursive servers upstream. I'm not aware of any specific problem with higher-grade firewalls interfering with the subsequent queries sent between the recursive resolvers and authoritative servers. Ray --=_alternative 003562D8802575E1_= Content-Type: text/html; charset="US-ASCII"
> oh the list is long and distinguished.
>
> http://www.icann.org/en/committees/security/ssac-documents.htm
> look at SAC035
Much as I appreciate the citation, I don't believe it's relevant.

The middleboxes that we tested were consumer level devices, where recursive queries from stubs were addressed directly to the DNS proxies sat therein and then forwarded to "real" recursive servers upstream.

I'm not aware of any specific problem with higher-grade firewalls interfering with the subsequent queries sent between the recursive resolvers and authoritative servers.

Ray
--=_alternative 003562D8802575E1_=-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 03:11:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9C83A68A5; Fri, 26 Jun 2009 03:11:31 -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 1gV7qwLo0S-2; Fri, 26 Jun 2009 03:11:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8A4713A6855; Fri, 26 Jun 2009 03:11:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK8Kv-0003KQ-F5 for namedroppers-data0@psg.com; Fri, 26 Jun 2009 10:07:13 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK8Kj-0003IE-FP; Fri, 26 Jun 2009 10:07:07 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 9067FC2DA3; Fri, 26 Jun 2009 11:06:58 +0100 (BST) Date: Fri, 26 Jun 2009 11:06:10 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ray.Bellis@nominet.org.uk, bmanning@vacation.karoshi.com cc: namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) Message-ID: <6DEF4FE2680060703ED2D6C3@Ximines.local> In-Reply-To: References: <823a9ozrkc.fsf@mid.bfk.de> <200906251459.n5PExTFs023425@drugs.dv.isc.org> <20090625152225.GA1164@dul1mcmlarson-l1.labs.vrsn.com> <3efd34cc0906251434s38548735gb31b1bbf7c9f89b7@mail.gmail.com> <3efd34cc0906251606l3c7684b9n36f4bdca64c742ad@mail.gmail.com> <20090625233756.GA14000@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: --On 26 June 2009 10:43:07 +0100 Ray.Bellis@nominet.org.uk wrote: > I'm not aware of any specific problem with higher-grade firewalls > interfering with the subsequent queries sent between the recursive > resolvers and authoritative servers. Sometimes the issue is with the configuration rather than the device. The following is a snippet from a PIX config. policy-map type inspect dns preset_dns_map parameters message-length maximum 512 A google search for "message-length maximum 512" suggests this is not uncommon, and indeed appears to be splashed over a number of cisco.com example configs. -- Alex Bligh -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 03:19:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77433A6855; Fri, 26 Jun 2009 03:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYIdz1o3DC3s; Fri, 26 Jun 2009 03:19:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E88A3A69FF; Fri, 26 Jun 2009 03:18:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK8Th-0004RT-Pv for namedroppers-data0@psg.com; Fri, 26 Jun 2009 10:16:17 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK8TS-0004Om-Ip; Fri, 26 Jun 2009 10:16:12 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=Mddq82TiXqtlA9HFAbmCK9e4YC0RE4tlg+wfo8ZG6q+yvF43PtTo2VzA enQpDT/AM7Vkv9jowYIBiT8YMULrV1Sh+AiN4ALMvDq7b0Dq0ReSGRFUq 7r0W3elyK9rhnmJ; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1246011362; x=1277547362; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20Real =20data=20(was=20Re:=20[dnsext]=20Danger=20of=20coming=20 unstuck)|Date:=20Fri,=2026=20Jun=202009=2011:15:59=20+010 0|Message-ID:=20|To:=20Alex=20Bligh=20|Cc:=20bmanning@vacation.karoshi.com,=0D =0A=09namedroppers@ops.ietf.org,=0D=0A=09owner-namedroppe rs@ops.ietf.org|MIME-Version:=201.0|In-Reply-To:=20<6DEF4 FE2680060703ED2D6C3@Ximines.local>|References:=20<823a9oz rkc.fsf@mid.bfk.de>=20<200906251459.n5PExTFs023425@drugs. dv.isc.org>=20<20090625152225.GA1164@dul1mcmlarson-l1.lab s.vrsn.com>=20<3efd34cc0906251434s38548735gb31b1bbf7c9f89 b7@mail.gmail.com>=20=20<3efd34cc0906251606l3c7684b9n36f4bdca64c742ad@mail. gmail.com>=20<20090625233756.GA14000@vacation.karoshi.com .>=20=20<6DEF4FE2680060703ED2D6C3@Ximine s.local>; bh=NOUKRkJKg3bHyRUTtUVPF9XyGCdcoEDVTEdhPp4w/80=; b=TS7DGSNL1cR5rV8Vci1w2Cw8mO5RAkC0VwCi/E1Vi0G9YwTIVPrUIpvy WarD/9oIo3iIHkf5DJifMpB5cG0b+PWHmLKWt+sOpEGwDDP/OtCyp9W30 ZpyjaLzaPMZARKF; X-IronPort-AV: E=Sophos;i="4.42,296,1243810800"; d="scan'208";a="15147540" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 26 Jun 2009 11:16:00 +0100 In-Reply-To: <6DEF4FE2680060703ED2D6C3@Ximines.local> References: <823a9ozrkc.fsf@mid.bfk.de> <200906251459.n5PExTFs023425@drugs.dv.isc.org> <20090625152225.GA1164@dul1mcmlarson-l1.labs.vrsn.com> <3efd34cc0906251434s38548735gb31b1bbf7c9f89b7@mail.gmail.com> <3efd34cc0906251606l3c7684b9n36f4bdca64c742ad@mail.gmail.com> <20090625233756.GA14000@vacation.karoshi.com.> <6DEF4FE2680060703ED2D6C3@Ximines.local> To: Alex Bligh Cc: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 26 Jun 2009 11:15:59 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 26/06/2009 11:16:00 AM, Serialize complete at 26/06/2009 11:16:00 AM Content-Type: multipart/alternative; boundary="=_alternative 003864FF802575E1_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 003864FF802575E1_= Content-Type: text/plain; charset="US-ASCII" > Sometimes the issue is with the configuration rather than the > device. The following is a snippet from a PIX config. > > policy-map type inspect dns preset_dns_map > parameters > message-length maximum 512 > > A google search for "message-length maximum 512" suggests this > is not uncommon, and indeed appears to be splashed over a number > of cisco.com example configs. ah yes, I've heard of that one, but never seen it in person. Ray --=_alternative 003864FF802575E1_= Content-Type: text/html; charset="US-ASCII"
> Sometimes the issue is with the configuration rather than the
> device. The following is a snippet from a PIX config.
>
> policy-map type inspect dns preset_dns_map
>  parameters
>   message-length maximum 512
>
> A google search for "message-length maximum 512" suggests this
> is not uncommon, and indeed appears to be splashed over a number
> of cisco.com example configs.
ah yes, I've heard of that one, but never seen it in person.

Ray
--=_alternative 003864FF802575E1_=-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 04:21:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE8D3A6A9E; Fri, 26 Jun 2009 04:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=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 FX10ORUu-GRf; Fri, 26 Jun 2009 04:21:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A817C3A69AB; Fri, 26 Jun 2009 04:21:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK9Ok-000BA5-02 for namedroppers-data0@psg.com; Fri, 26 Jun 2009 11:15:14 +0000 Received: from [94.198.152.69] (helo=arn1-kamx.sidn.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MK9OQ-000B8W-Aw for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 11:15:08 +0000 Received: from sidn.nl ([192.168.2.12]) by arn1-kamx.sidn.nl with ESMTP id n5QBEp7M028569 for ; Fri, 26 Jun 2009 13:14:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: [dnsext] RE: Nested trust anchors (again) Date: Fri, 26 Jun 2009 13:16:43 +0200 Message-ID: <850A39016FA57A4887C0AA3C8085F949DD3E03@KAEVS1.SIDN.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nested trust anchors (again) Thread-Index: Acn2QIUomu0jfqYxRbWo13dkJES0XgAAwPiA References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <20090625123013.GA20593@laperouse.bortzmeyer.org> <850A39016FA57A4887C0AA3C8085F949DD3DEF@KAEVS1.SIDN.local> <82ocsbl603.fsf@mid.bfk.de> <20090626092640.GA18268@laperouse.bortzmeyer.org> From: "Antoin Verschuren" To: "Namedroppers Mailing List" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Stephane came up with another example of why DNS is not static, but I = was also thinking: The chain initially follows the delegation path when the trust anchor is = above the name queried. When the delegation path changes, the chain of trust priming changes = too. (the trust anchor doesn't) Current caching behavior makes it possible to cache an authoritative = entry in the current chain of trust (DNSKEY) depending on the current = delegation path. When the delegation path changes, the chain of trust changes too, and = this cached entry might not be in the path anymore. So, root is signed, I have it's trust anchor in my resolver. antoin.example. is delegated to ns1.example. with DS1, everything is = signed. I cache DNSKEY1, or may even set it up as a trust anchor. At point x in time, the delegation for antoin.example. changes to = ns2.example. with DS2 (new zone operator, new KSK, no rollover, new = chain of trust) DNSKEY1 is still in my cache, and I may have it as trust anchor, = validation will fail until DNSKEY1 expires and/or I remove that trust = anchor, and the resolver fetches DNSKEY2 in the new chain of trust. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl = http://www.sidn.nl/ > -----Original Message----- > From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] > Sent: Friday, June 26, 2009 11:27 AM > To: Florian Weimer > Cc: Antoin Verschuren; Namedroppers Mailing List > Subject: Re: Nested trust anchors (again) >=20 > On Fri, Jun 26, 2009 at 11:05:32AM +0200, > Florian Weimer wrote > a message of 17 lines which said: >=20 > > > Chains of trusts change. > > > > Uhm, since the chain is tied to the name, how is this possible? >=20 > I believe Antoin referred to scenarios like (for a validation of > www.weimer.example): >=20 > 1) * The root is signed and my resolver has a trust anchor for it > * .example is not signed > * weimer.example is signed and my resolver has a trust anchor for > it >=20 > 2) .example gets signed and the root publishes a DS >=20 > Then, a new chain of trust appeared, which was not there before. >=20 > Remember that the manager of the root announced a signature in 2009 > and the manager of .com a signature in 2011-2012, so this scenario > will be very common. >=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 06:51:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5713A6B6B; Fri, 26 Jun 2009 06:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.461 X-Spam-Level: X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0RW4mo52pvH; Fri, 26 Jun 2009 06:51:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E85F33A6B4D; Fri, 26 Jun 2009 06:51:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKBkv-000Mp7-Dh for namedroppers-data0@psg.com; Fri, 26 Jun 2009 13:46:17 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKBkk-000Mnx-6p for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 13:46:11 +0000 Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 743B02FE9664; Fri, 26 Jun 2009 13:46:04 +0000 (UTC) Date: Fri, 26 Jun 2009 09:46:02 -0400 From: Andrew Sullivan To: Stephane Bortzmeyer Cc: namedroppers@ops.ietf.org Subject: [dnsext] Re: Nested trust anchors (again) Message-ID: <20090626134602.GB481@shinkuro.com> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <20090625123013.GA20593@laperouse.bortzmeyer.org> <20090625201739.GL375@shinkuro.com> <20090626063639.GB25713@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090626063639.GB25713@laperouse.bortzmeyer.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Jun 26, 2009 at 08:36:39AM +0200, Stephane Bortzmeyer wrote: > On Thu, Jun 25, 2009 at 04:17:47PM -0400, > Andrew Sullivan wrote > a message of 23 lines which said: > > > Does this mean, "All the trust anchors I have must work," or, "The > > set of my trust anchors and the set of the name server trust anchors > > must be equivalent"? > > I don't understand the second. What is "the set of the name server > trust anchors"? The DNSKEY found in the DNS and verified through DS? > If so, I would not call them trust anchors. Yes, sorry for the imprecise language (which is painfully ironic given I was trying to clarify, but there you go). I just meant that there are two ways to read that option. One is that you have a bunch of keys locally configured as trust anchors, and every one of them must be available in the target zone. The other is that all _and only_ those keys you have locally configured as TAs must be available as keys in the target zone. (They don't need to be verified through DS from the parent at all, of course, and you might have the DNSKEY record locally instead of the DS, depending on how your implementation works. But they have to correspond to your locally-configured keys.) I think you mean "all must be there" and not "all and only those must be there", but I wanted to be sure we have this right. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 06:56:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068513A68DA; Fri, 26 Jun 2009 06:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 sE7uOBUkCxdl; Fri, 26 Jun 2009 06:56:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 79FFB3A684F; Fri, 26 Jun 2009 06:56:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKBs1-000NSB-Jb for namedroppers-data0@psg.com; Fri, 26 Jun 2009 13:53:37 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKBrp-000NR4-QZ for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 13:53:31 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 56D57E6071; Fri, 26 Jun 2009 13:53:22 +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 n5QDr0SX038071; Fri, 26 Jun 2009 23:53:14 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906261353.n5QDr0SX038071@drugs.dv.isc.org> To: "Antoin Verschuren" Cc: "Namedroppers Mailing List" From: Mark Andrews Subject: Re: [dnsext] RE: Nested trust anchors (again) In-reply-to: Your message of "Fri, 26 Jun 2009 13:16:43 +0200." <850A39016FA57A4887C0AA3C8085F949DD3E03@KAEVS1.SIDN.local> Date: Fri, 26 Jun 2009 23:53:00 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <850A39016FA57A4887C0AA3C8085F949DD3E03@KAEVS1.SIDN.local>, "Antoin Verschuren" writes: > Stephane came up with another example of why DNS is not static, but I = > was also thinking: > > The chain initially follows the delegation path when the trust anchor is = > above the name queried. > When the delegation path changes, the chain of trust priming changes = > too. (the trust anchor doesn't) > > Current caching behavior makes it possible to cache an authoritative = > entry in the current chain of trust (DNSKEY) depending on the current = > delegation path. > When the delegation path changes, the chain of trust changes too, and = > this cached entry might not be in the path anymore. > > So, root is signed, I have it's trust anchor in my resolver. > > antoin.example. is delegated to ns1.example. with DS1, everything is = > signed. > I cache DNSKEY1, or may even set it up as a trust anchor. > > At point x in time, the delegation for antoin.example. changes to = > ns2.example. with DS2 (new zone operator, new KSK, no rollover, new = > chain of trust) > DNSKEY1 is still in my cache, and I may have it as trust anchor, = > validation will fail until DNSKEY1 expires and/or I remove that trust = > anchor, and the resolver fetches DNSKEY2 in the new chain of trust. So someone stuffed the key management on the authoritative side or it was an unauthorised change. There is no way of knowing which from the validator's perspective. Do you risk accepting potentially bad data or do you stop accepting answers for the namespace? Note there isn't a "correct" answer to this question. Mark > Antoin Verschuren > > Technical Policy Advisor SIDN > Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands > > P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 > mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl = > http://www.sidn.nl/ > > > > > -----Original Message----- > > From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] > > Sent: Friday, June 26, 2009 11:27 AM > > To: Florian Weimer > > Cc: Antoin Verschuren; Namedroppers Mailing List > > Subject: Re: Nested trust anchors (again) > >=20 > > On Fri, Jun 26, 2009 at 11:05:32AM +0200, > > Florian Weimer wrote > > a message of 17 lines which said: > >=20 > > > > Chains of trusts change. > > > > > > Uhm, since the chain is tied to the name, how is this possible? > >=20 > > I believe Antoin referred to scenarios like (for a validation of > > www.weimer.example): > >=20 > > 1) * The root is signed and my resolver has a trust anchor for it > > * .example is not signed > > * weimer.example is signed and my resolver has a trust anchor for > > it > >=20 > > 2) .example gets signed and the root publishes a DS > >=20 > > Then, a new chain of trust appeared, which was not there before. > >=20 > > Remember that the manager of the root announced a signature in 2009 > > and the manager of .com a signature in 2011-2012, so this scenario > > will be very common. > >=20 > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 07:13:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136983A6B54; Fri, 26 Jun 2009 07:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 j83NJJc-oX4R; Fri, 26 Jun 2009 07:13:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 346053A684F; Fri, 26 Jun 2009 07:13:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKC7I-000OsT-GK for namedroppers-data0@psg.com; Fri, 26 Jun 2009 14:09:24 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKC77-000OqK-EA for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 14:09:18 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 8D92FE601C; Fri, 26 Jun 2009 14:09:12 +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 n5QE98p3041823; Sat, 27 Jun 2009 00:09:08 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906261409.n5QE98p3041823@drugs.dv.isc.org> To: Stephane Bortzmeyer Cc: Florian Weimer , Antoin Verschuren , Namedroppers Mailing List From: Mark Andrews Subject: Re: [dnsext] Re: Nested trust anchors (again) In-reply-to: Your message of "Fri, 26 Jun 2009 11:26:40 +0200." <20090626092640.GA18268@laperouse.bortzmeyer.org> Date: Sat, 27 Jun 2009 00:09:08 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <20090626092640.GA18268@laperouse.bortzmeyer.org>, Stephane Bortzmey er writes: > On Fri, Jun 26, 2009 at 11:05:32AM +0200, > Florian Weimer wrote > a message of 17 lines which said: > > > > Chains of trusts change. > > > > Uhm, since the chain is tied to the name, how is this possible? > > I believe Antoin referred to scenarios like (for a validation of > www.weimer.example): > > 1) * The root is signed and my resolver has a trust anchor for it > * .example is not signed > * weimer.example is signed and my resolver has a trust anchor for > it > > 2) .example gets signed and the root publishes a DS > > Then, a new chain of trust appeared, which was not there before. > > Remember that the manager of the root announced a signature in 2009 > and the manager of .com a signature in 2011-2012, so this scenario > will be very common. And there is still not a secure path from the root to weimer.example as there is no DS for weimer.example. Even when the DS RRset for weimer.example is added there is not a problem. Presumably weimer.example published keys for use in trust anchors and should manage them accordingly or published then in a DLV only in which case they shouldn't be in a configation file or published them by both methods which requires that you meet the management constraints of both methods of publishing. If you just scrapped keys to add to you configuration then you get what you deserve when the zone operator fails to take you into account. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 07:25:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330EB3A6882; Fri, 26 Jun 2009 07:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uxv4OdqYCUfN; Fri, 26 Jun 2009 07:25:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E48173A6AD3; Fri, 26 Jun 2009 07:24:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKCHy-000Puu-My for namedroppers-data0@psg.com; Fri, 26 Jun 2009 14:20:26 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKCHj-000PtU-47; Fri, 26 Jun 2009 14:20:20 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 45B6FE601C; Fri, 26 Jun 2009 14:20:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5QEK6G7041937; Sat, 27 Jun 2009 00:20:07 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906261420.n5QEK6G7041937@drugs.dv.isc.org> To: Alex Bligh Cc: Ray.Bellis@nominet.org.uk, bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) In-reply-to: Your message of "Fri, 26 Jun 2009 11:06:10 +0100." <6DEF4FE2680060703ED2D6C3@Ximines.local> Date: Sat, 27 Jun 2009 00:20:05 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <6DEF4FE2680060703ED2D6C3@Ximines.local>, Alex Bligh writes: > > > I'm not aware of any specific problem with higher-grade firewalls > > interfering with the subsequent queries sent between the recursive > > resolvers and authoritative servers. > > Sometimes the issue is with the configuration rather than the > device. The following is a snippet from a PIX config. > > policy-map type inspect dns preset_dns_map > parameters > message-length maximum 512 > > A google search for "message-length maximum 512" suggests this > is not uncommon, and indeed appears to be splashed over a number > of cisco.com example configs. And you will also see people saying to raise this to 4096. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 07:42:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7911028C126; Fri, 26 Jun 2009 07:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=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 7+R7hhM50ptp; Fri, 26 Jun 2009 07:42:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5227528C122; Fri, 26 Jun 2009 07:42:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKCa9-0001a4-AK for namedroppers-data0@psg.com; Fri, 26 Jun 2009 14:39:13 +0000 Received: from [94.198.152.69] (helo=arn1-kamx.sidn.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKCZu-0001Yi-D3 for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 14:39:07 +0000 Received: from sidn.nl ([192.168.2.12]) by arn1-kamx.sidn.nl with ESMTP id n5QEcuTG002447 for ; Fri, 26 Jun 2009 16:38:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [dnsext] RE: Nested trust anchors (again) Date: Fri, 26 Jun 2009 16:40:48 +0200 Message-ID: <850A39016FA57A4887C0AA3C8085F949DD3E11@KAEVS1.SIDN.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] RE: Nested trust anchors (again) Thread-Index: Acn2ZcBQQiVLSO5xTOae9B1doz3c5gABHDEA References: <200906261353.n5QDr0SX038071@drugs.dv.isc.org> From: "Antoin Verschuren" To: Cc: "Namedroppers Mailing List" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > -----Original Message----- > From: marka@isc.org [mailto:marka@isc.org] > Subject: Re: [dnsext] RE: Nested trust anchors (again) >=20 >=20 > So someone stuffed the key management on the authoritative > side or it was an unauthorised change. There is no way of > knowing which from the validator's perspective. The change is authorized. By the parent. You rely on your parent for the initial delegation and setting up the = trust path anyway. If you don't have a parent, or a parent is not involved in your trust = path, I agree. But I'm talking a parent in your trust path. The trust anchor does not change. The trust path has changed. Only the validator doesn't know about it yet because of caching leaf = data. > Do you risk accepting potentially bad data or do you stop > accepting answers for the namespace? Note there isn't a > "correct" answer to this question. You can get the good data by re-walking the trust path from the trust = anchor down. That's what I'm saying. Caches may store keys from the leaf which may not be in the path = anymore. That's what I call bad data, and should not stop the DNS from working. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl = http://www.sidn.nl/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 08:01:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C97A3A6BA1; Fri, 26 Jun 2009 08:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 niysYuodF1AS; Fri, 26 Jun 2009 08:01:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 120F13A67DF; Fri, 26 Jun 2009 08:01:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKCpG-00030R-B5 for namedroppers-data0@psg.com; Fri, 26 Jun 2009 14:54:50 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKCp4-0002zG-LV for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 14:54:44 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id B0DFAE6071; Fri, 26 Jun 2009 14:54:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5QEsZYN042658; Sat, 27 Jun 2009 00:54:35 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906261454.n5QEsZYN042658@drugs.dv.isc.org> To: "Antoin Verschuren" Cc: marka@isc.org, "Namedroppers Mailing List" From: Mark Andrews Subject: Re: [dnsext] RE: Nested trust anchors (again) In-reply-to: Your message of "Fri, 26 Jun 2009 16:40:48 +0200." <850A39016FA57A4887C0AA3C8085F949DD3E11@KAEVS1.SIDN.local> Date: Sat, 27 Jun 2009 00:54:35 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <850A39016FA57A4887C0AA3C8085F949DD3E11@KAEVS1.SIDN.local>, "Antoin Verschuren" writes: > > -----Original Message----- > > From: marka@isc.org [mailto:marka@isc.org] > > Subject: Re: [dnsext] RE: Nested trust anchors (again) > >=20 > >=20 > > So someone stuffed the key management on the authoritative > > side or it was an unauthorised change. There is no way of > > knowing which from the validator's perspective. > > The change is authorized. > By the parent. There have been cases where parents have been conned. > You rely on your parent for the initial delegation and setting up the = > trust path anyway. > If you don't have a parent, or a parent is not involved in your trust = > path, I agree. > But I'm talking a parent in your trust path. > The trust anchor does not change. > The trust path has changed. > Only the validator doesn't know about it yet because of caching leaf = > data. > > > Do you risk accepting potentially bad data or do you stop > > accepting answers for the namespace? Note there isn't a > > "correct" answer to this question. > > You can get the good data by re-walking the trust path from the trust = > anchor down. > That's what I'm saying. > Caches may store keys from the leaf which may not be in the path = > anymore. > That's what I call bad data, and should not stop the DNS from working. Zones that are transferred from one set of servers to another today stop working due to cached data. If care is taken this doesn't happen. The same thing applies to with DNSSEC. DNSSEC is not a magic bullet. It won't fix mis-management of delegations and changes to delegations. It is highlighting the current management problems in these areas and if it results in changes then that is a good thing. Mark > Antoin Verschuren > > Technical Policy Advisor SIDN > Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands > > P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 > mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl = > http://www.sidn.nl/ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 08:17:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC953A68D4; Fri, 26 Jun 2009 08:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, J_CHICKENPOX_37=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 J7ybUQ8zGgDW; Fri, 26 Jun 2009 08:17:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 951473A677D; Fri, 26 Jun 2009 08:17:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKD79-0004aD-VK for namedroppers-data0@psg.com; Fri, 26 Jun 2009 15:13: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.69 (FreeBSD)) (envelope-from ) id 1MKD6u-0004Yl-7Q for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 15:13:13 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id D9E8AA707F for ; Fri, 26 Jun 2009 15:13:03 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Namedroppers Mailing List Subject: Re: [dnsext] Re: Nested trust anchors (again) In-Reply-To: Your message of "Fri, 26 Jun 2009 11:26:40 +0200." <20090626092640.GA18268@laperouse.bortzmeyer.org> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <20090625123013.GA20593@laperouse.bortzmeyer.org> <850A39016FA57A4887C0AA3C8085F949DD3DEF@KAEVS1.SIDN.local> <82ocsbl603.fsf@mid.bfk.de> <20090626092640.GA18268@laperouse.bortzmeyer.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 26 Jun 2009 15:13:03 +0000 Message-ID: <30107.1246029183@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: dns distributes autonomy. each zone depends on its ancestor zones for its existence (NS RRs and possible in-zone glue) but not for its content. to decide between ANY or ALL or ANY+CLOSEST or CLOSEST, i recommend posing the question "are my zone's trust anchors subject to my autonomy?" if i've imported a key for ietf.org and it's working, and then .org gets signed but doesn't yet have a key for ietf.org or worse still .org decides that ietf.org should have to pay USD 1M/year for DS RR placement and so publishes a deliberately bad key for ietf.org, then should my validator stop accepting the key i imported? it all depends on what we mean by zone autonomy. to me this is a strong argument against ALL. or if ietf.org deletes a DNSKEY after a key compromise, but the .org people are all down at the pub for a long weekend and somehow can't won't reflect this change by deleting the DS RR associated with that DNSKEY, then there is no way for any validator operator to manually set a trust anchor for ietf.org and avoid spoofed data signed with the compromised key. to me this is a strong argument against ANY. DLV's design faced similar decisions. in the end we decided on strong zone autonomy such that a DLV RRset at ietf.org.dlv.isc.org would still be functional even after root and org are signed, or even after org.dlv.isc.org has a DLV RRset. this made a few TLD holders unhappy who felt that it was uniquely up to the TLD whether dnssec worked or not for their subdomains. i realize that "maximize autonomy" is not a universally held principle but it's what guided the DLV design and i havn't grown at all unhappy about it. i would prefer CLOSEST because i believe that the implementation should not have to second guess its own configuration -- that is, if a validator has a trust anchor configured then it should assume that the operator knows it is there and wants it to be the final arbiter of security at/below the anchor. however, i can live with ANY+CLOSEST because it's fairly simple and it allows local autonomy in the revocation case without creating really long dependency chains where absolutely everything (everywhere) has to be right all the time. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 08:29:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 316E83A6AE0; Fri, 26 Jun 2009 08:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 0US7e+2WWbzD; Fri, 26 Jun 2009 08:29:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 92C623A69C2; Fri, 26 Jun 2009 08:28:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKDHw-0005Rm-FD for namedroppers-data0@psg.com; Fri, 26 Jun 2009 15:24: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.69 (FreeBSD)) (envelope-from ) id 1MKDHl-0005R5-EE for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 15:24:22 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 287BBA7088 for ; Fri, 26 Jun 2009 15:24:17 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) In-Reply-To: Your message of "Fri, 26 Jun 2009 11:15:59 +0100." References: <823a9ozrkc.fsf@mid.bfk.de> <200906251459.n5PExTFs023425@drugs.dv.isc.org> <20090625152225.GA1164@dul1mcmlarson-l1.labs.vrsn.com> <3efd34cc0906251434s38548735gb31b1bbf7c9f89b7@mail.gmail.com> <3efd34cc0906251606l3c7684b9n36f4bdca64c742ad@mail.gmail.com> <20090625233756.GA14000@vacation.karoshi.com.> <6DEF4FE2680060703ED2D6C3@Ximines.local> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 26 Jun 2009 15:24:17 +0000 Message-ID: <30700.1246029857@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Ray.Bellis@nominet.org.uk > Date: Fri, 26 Jun 2009 11:15:59 +0100 > ... > > message-length maximum 512 > ... > ah yes, I've heard of that one, but never seen it in person. i don't have real data on how frequent that is compared to other reasons why edns often fails, but subjectively now, it's not my worst nightmare. my worst nightmare is a stateless firewall that does not reassemble ip datagrams before applying pass/drop rules, and does not remember to pass following fragments if it passed the initial fragment. to ip, udp is just payload, and so the transport headers including source-port and dest-port are only present in the first ip fragment. if you use ipfw and you have a rule like this: add pass udp from any 53 to any add pass udp from any to any 53 then you also need a rule like this: add pass udp from any to any frag note that i am still fixing this in various outlying freebsd firewalls, a decade after RFC 2671 was published. i can only imagine how many other firewalls never bothered allowing frags since udp/53 always fit into a VAX physmem page (512 bytes) back in the day, and fragmentation just did not happen. i suppose that if firewalls and nat and proxies had been first class citizens of the ip architecture rather than bolt-ons that annoyed purists, then rules like "if you're going to refuse forwarding for some ip datagrams, then you should perform ip reassembly before deciding whether to do so, so that your firewall operates on datagrams, not on packets" would be in force. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 08:30:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D333A6AE0; Fri, 26 Jun 2009 08:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es+y8x9W1iEj; Fri, 26 Jun 2009 08:30:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 47BC83A6922; Fri, 26 Jun 2009 08:30:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKDLO-0005iZ-O6 for namedroppers-data0@psg.com; Fri, 26 Jun 2009 15:28:02 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKDLD-0005hX-6X for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 15:27:56 +0000 Received: from [10.31.200.183] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5QFRk8q010725; Fri, 26 Jun 2009 11:27:46 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090625200246.GK375@shinkuro.com> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <4A4368CA.3090203@nlnetlabs.nl> <20090625200246.GK375@shinkuro.com> Date: Fri, 26 Jun 2009 11:27:44 -0400 To: Andrew Sullivan From: Edward Lewis Subject: Re: [dnsext] Nested trust anchors (again) Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 16:02 -0400 6/25/09, Andrew Sullivan wrote: >1. Do you think that the DNSSECbis RFCs, including NSEC3, include >either implicitly or explicitly a notion of "degrees of trust" of >different keys? > > 1. a. If so, please indicate the text that you think supports this > view. > > 1. b. If not, suggest why this departure from other security > protocols is a plausible interpretation. (If you're one of the > editors of the docs, saying, "Because we thought it was a good > idea, and if we wanted degrees of trust we'd have included it > explicitly," counts.) In RFC 2065 (aka DNSSEC I) and maybe RFC 2535 (aka DNSSEC II) we toyed with the notion of key strength as a field in a KEY RR. We thought maybe you could mark a key to be stronger if it was the off-line signer of some data in a zone and use another key that was weaker as the signer of dynamic updates. There were a few missing links, like, a relying party cannot distinguish between what is signed off-line and what was dynamically added. The kicker was ... if there was a vulnerability exercised to add a KEY RR to the set the addition could as easily be a "strong" key as much as a "weaker" key. If it was possible to add any key then making a distinction between strong and weak was useless. Ergo, all keys are created equal (and none are "more" equal than others). Key strength is not in RFC 403[345] (DNSSEC III). >2. Do you think that the DNSSECbis RFCs _should_ include that notion? >If so, why, and if not, why not? No because it failed before. In my opinion, no requirements have changed such that the reasons it failed back then have gone away. At 20:24 +0000 6/25/09, bmanning@vacation.karoshi.com wrote: > trust is binary > trustworthy is not. > > the first test is ... is this blob trustworthy? the criteria > for determining trustworthiness can be many and varied... (local policy). Review RFC 2181, section 5.4.1. On another note: Somewhere I got the notion that there's a comparison to X.509 to be made. In an architecture, an X.509 certificate and a DNSKEY RR play the same role - both associate ancillary data with a public key. But the "competition" stops right there. There are a lot more fields in X.509, these are used to relate the policy regarding the key, limitations on its use, the liability, etc. X.509 is also backed by a Certification Processes Statement (CPS, I think that's the expansion), a form document that contains details ad nausem about the "meaning" of a successful validation resulting from the key in the certificate. That's all "just too much" to lay upon a DNS administrator. The functional requirements governing DNSSEC is a small subset of the functional requirements on X.509, resulting in the difference in implementations and, to answer the question that started this, why (DNS)KEY RR's don't have the same notions as trust as other systems like X.509. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 08:42:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0CF28C12A; Fri, 26 Jun 2009 08:42:47 -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 lSyXj3x-MllF; Fri, 26 Jun 2009 08:42:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 361A428C0EF; Fri, 26 Jun 2009 08:42:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKDVK-0006cF-HB for namedroppers-data0@psg.com; Fri, 26 Jun 2009 15:38:18 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKDV9-0006ah-Cu for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 15:38:12 +0000 Received: from [10.31.200.183] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5QFbwZ3010797; Fri, 26 Jun 2009 11:38:00 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <82ocsbl603.fsf@mid.bfk.de> References: <20090623143336.GE20291@dul1mcmlarson-l1.labs.vrsn.com> <20090625123013.GA20593@laperouse.bortzmeyer.org> <850A39016FA57A4887C0AA3C8085F949DD3DEF@KAEVS1.SIDN.local> <82ocsbl603.fsf@mid.bfk.de> Date: Fri, 26 Jun 2009 11:34:39 -0400 To: Florian Weimer From: Edward Lewis Subject: Re: [dnsext] Re: Nested trust anchors (again) Cc: "Antoin Verschuren" , "Namedroppers Mailing List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 11:05 +0200 6/26/09, Florian Weimer wrote: >* Antoin Verschuren: > >> DNS is not static. >> Chains of trusts change. > >Uhm, since the chain is tied to the name, how is this possible? Redelegation - in the sense that a zone cut may be removed but the names in the erstwhile child zone are "promoted" to the parent somewhere in the chain. Key effectivitiy periods are not synchronous. UDP is not reliable. Etc. The chain is not exactly tied to the name. Remember that zones may be multi-label deep and there are empty non-terminals. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 10:25:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C704628C0EF; Fri, 26 Jun 2009 10:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.491 X-Spam-Level: X-Spam-Status: No, score=-4.491 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8IdIkdk04W3; Fri, 26 Jun 2009 10:25:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E260728C0EC; Fri, 26 Jun 2009 10:25:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKF5u-000FAP-OQ for namedroppers-data0@psg.com; Fri, 26 Jun 2009 17:20:10 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKF5g-000F9H-HE; Fri, 26 Jun 2009 17:20:04 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5QHH9A9021908; Fri, 26 Jun 2009 17:17:09 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5QHGU5C021898; Fri, 26 Jun 2009 17:16:30 GMT Date: Fri, 26 Jun 2009 17:16:25 +0000 From: bmanning@vacation.karoshi.com To: Mark Andrews Cc: Alex Bligh , Ray.Bellis@nominet.org.uk, bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) Message-ID: <20090626171625.GA21700@vacation.karoshi.com.> References: <6DEF4FE2680060703ED2D6C3@Ximines.local> <200906261420.n5QEK6G7041937@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906261420.n5QEK6G7041937@drugs.dv.isc.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Jun 27, 2009 at 12:20:05AM +1000, Mark Andrews wrote: > > In message <6DEF4FE2680060703ED2D6C3@Ximines.local>, Alex Bligh writes: > > > > > I'm not aware of any specific problem with higher-grade firewalls > > > interfering with the subsequent queries sent between the recursive > > > resolvers and authoritative servers. > > > > Sometimes the issue is with the configuration rather than the > > device. The following is a snippet from a PIX config. > > > > policy-map type inspect dns preset_dns_map > > parameters > > message-length maximum 512 > > > > A google search for "message-length maximum 512" suggests this > > is not uncommon, and indeed appears to be splashed over a number > > of cisco.com example configs. > > And you will also see people saying to raise this to 4096. > > Mark > is there any good reason not to? if, of course, they want to follow the protocol... --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 10:44:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 999243A6B07; Fri, 26 Jun 2009 10:44:49 -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 nyNCgjYjYRYj; Fri, 26 Jun 2009 10:44:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BEF203A6861; Fri, 26 Jun 2009 10:44:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKFQx-000Gmy-Ts for namedroppers-data0@psg.com; Fri, 26 Jun 2009 17:41:55 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKFQm-000GmD-3q; Fri, 26 Jun 2009 17:41:49 +0000 Received: from [192.168.100.15] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 8C220C2DA3; Fri, 26 Jun 2009 18:41:41 +0100 (BST) Date: Fri, 26 Jun 2009 18:40:51 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bmanning@vacation.karoshi.com, Mark Andrews cc: Ray.Bellis@nominet.org.uk, bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) Message-ID: <563EACD0B64DA52B0FC17C2F@Ximines.local> In-Reply-To: <20090626171625.GA21700@vacation.karoshi.com.> References: <6DEF4FE2680060703ED2D6C3@Ximines.local> <200906261420.n5QEK6G7041937@drugs.dv.isc.org> <20090626171625.GA21700@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: --On 26 June 2009 17:16:25 +0000 bmanning@vacation.karoshi.com wrote: >> > Sometimes the issue is with the configuration rather than the >> > device. The following is a snippet from a PIX config. >> > >> > policy-map type inspect dns preset_dns_map >> > parameters >> > message-length maximum 512 >> > >> > A google search for "message-length maximum 512" suggests this >> > is not uncommon, and indeed appears to be splashed over a number >> > of cisco.com example configs. >> >> And you will also see people saying to raise this to 4096. >> >> Mark >> > > is there any good reason not to? if, of course, they > want to follow the protocol... Allegedly the 512 byte limit (which was at one point the default setting and for all I know may still be) was introduced to mitigate reflection DDOS attacks. I'm not trying to pick on Cisco here, just point out that the idea there will be no interfering middleboxen in front of corporate connections is probably wrong. -- Alex Bligh -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 12:41:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD583A6C40; Fri, 26 Jun 2009 12:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 3WJdTmGG3HSX; Fri, 26 Jun 2009 12:41:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A310C3A6C3C; Fri, 26 Jun 2009 12:41:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKHED-000PY4-BE for namedroppers-data0@psg.com; Fri, 26 Jun 2009 19:36:53 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKHE1-000PWd-C7 for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 19:36:46 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0EE86A70D5 for ; Fri, 26 Jun 2009 19:36:40 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) In-Reply-To: Your message of "Fri, 26 Jun 2009 18:40:51 +0100." <563EACD0B64DA52B0FC17C2F@Ximines.local> References: <6DEF4FE2680060703ED2D6C3@Ximines.local> <200906261420.n5QEK6G7041937@drugs.dv.isc.org> <20090626171625.GA21700@vacation.karoshi.com.> <563EACD0B64DA52B0FC17C2F@Ximines.local> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 26 Jun 2009 19:36:40 +0000 Message-ID: <41105.1246045000@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Fri, 26 Jun 2009 18:40:51 +0100 > From: Alex Bligh > > I'm not trying to pick on Cisco here, just point out that the idea there > will be no interfering middleboxen in front of corporate connections is > probably wrong. no doubt every single operator or implementor or businessman who sees udp/53 as the right shim layer to jam in their extra functionality has a reason, but the end effect is to make any changes to the protocol extremely expensive, and i still think it'll drive us toward dns-over-https as a way to drive a stake through this middleism once and finally. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 15:55:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C861928C1C9; Fri, 26 Jun 2009 15:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 E-lulQaD18k9; Fri, 26 Jun 2009 15:55:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9100E3A6879; Fri, 26 Jun 2009 15:55:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKKFR-000DBm-70 for namedroppers-data0@psg.com; Fri, 26 Jun 2009 22:50:21 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKKFF-000DA4-48 for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 22:50:14 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 2812EE601C; Fri, 26 Jun 2009 22:50:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5QMo4J8048639; Sat, 27 Jun 2009 08:50:04 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906262250.n5QMo4J8048639@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com Cc: Mark Andrews , Alex Bligh , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) In-reply-to: Your message of "Fri, 26 Jun 2009 17:16:25 GMT." <20090626171625.GA21700@vacation.karoshi.com.> Date: Sat, 27 Jun 2009 08:50:04 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <20090626171625.GA21700@vacation.karoshi.com.>, bmanning@vacation.ka roshi.com writes: > On Sat, Jun 27, 2009 at 12:20:05AM +1000, Mark Andrews wrote: > > > > In message <6DEF4FE2680060703ED2D6C3@Ximines.local>, Alex Bligh writes: > > > > > > > I'm not aware of any specific problem with higher-grade firewalls > > > > interfering with the subsequent queries sent between the recursive > > > > resolvers and authoritative servers. > > > > > > Sometimes the issue is with the configuration rather than the > > > device. The following is a snippet from a PIX config. > > > > > > policy-map type inspect dns preset_dns_map > > > parameters > > > message-length maximum 512 > > > > > > A google search for "message-length maximum 512" suggests this > > > is not uncommon, and indeed appears to be splashed over a number > > > of cisco.com example configs. > > > > And you will also see people saying to raise this to 4096. > > > > Mark > > > > is there any good reason not to? if, of course, they > want to follow the protocol... The protocol was extended 10 years ago give or take a couple of months. These firewalls were written well after the extension was published. Firewall designers need to understand the protocols they are playing with. It was not like there were not active examples around when these were designed. The designers just didn't do their home work. Network Working Group P. Vixie Request for Comments: 2671 ISC Category: Standards Track August 1999 If they want to live by RFC1034 then they should examine the queries and return FORMERR on them for having garbage in the additional section. This would have made extending the DNS predicable. Alternatively they should examine the queries and set the allowed response size based on the EDNS options in the query. There is no need for a one size solution. And for the record there have been larger than 512 bytes responses over UDP between co-operating machines as long as I've been involved with DNS and thats over 20 years now. EDNS just provided a standards based mechanism for doing so. We had code to catch and handle responses from such servers years before EDNS was dreamed of. Mark > > --bill > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 16:08:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A0F28C1DC; Fri, 26 Jun 2009 16:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 Mjz1km6PWImt; Fri, 26 Jun 2009 16:08:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7F1DE28C1D9; Fri, 26 Jun 2009 16:08:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKKPA-000Ef0-DP for namedroppers-data0@psg.com; Fri, 26 Jun 2009 23:00:24 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKKLh-000DrZ-4a for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 22:58:33 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 4BF03E606E; Fri, 26 Jun 2009 22:56:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5QMuiAY048752; Sat, 27 Jun 2009 08:56:45 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906262256.n5QMuiAY048752@drugs.dv.isc.org> To: Edward Lewis Cc: Andrew Sullivan , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] Nested trust anchors (again) In-reply-to: Your message of "Fri, 26 Jun 2009 11:27:44 -0400." Date: Sat, 27 Jun 2009 08:56:44 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The DNSSEC RFCs describes how you validate a trust relationship from a given trust-anchor to a set of data and how you configure zones for this to happen. The do not however tell you how you choose which trust anchors you are going to use for which names. Trust anchors refer to keys but are not keys themselves. The rules for keys do not apply. Try any key does not mean try any trust anchor. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 16:11:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E20AA3A6A4C; Fri, 26 Jun 2009 16:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.491 X-Spam-Level: X-Spam-Status: No, score=-4.491 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55l0cUL90v2g; Fri, 26 Jun 2009 16:11:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C7B513A67D4; Fri, 26 Jun 2009 16:11:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKKRI-000F72-Ae for namedroppers-data0@psg.com; Fri, 26 Jun 2009 23:02:36 +0000 Received: from [198.32.6.68] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKKNa-000EHk-KA for namedroppers@ops.ietf.org; Fri, 26 Jun 2009 23:00:52 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n5QMuKA9024178; Fri, 26 Jun 2009 22:56:20 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n5QMuF4Z024177; Fri, 26 Jun 2009 22:56:15 GMT Date: Fri, 26 Jun 2009 22:56:15 +0000 From: bmanning@vacation.karoshi.com To: Mark Andrews Cc: bmanning@vacation.karoshi.com, Alex Bligh , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) Message-ID: <20090626225615.GA24147@vacation.karoshi.com.> References: <20090626171625.GA21700@vacation.karoshi.com.> <200906262250.n5QMo4J8048639@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906262250.n5QMo4J8048639@drugs.dv.isc.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Sat, Jun 27, 2009 at 08:50:04AM +1000, Mark Andrews wrote: > > In message <20090626171625.GA21700@vacation.karoshi.com.>, bmanning@vacation.ka > roshi.com writes: > > On Sat, Jun 27, 2009 at 12:20:05AM +1000, Mark Andrews wrote: > > > > > > In message <6DEF4FE2680060703ED2D6C3@Ximines.local>, Alex Bligh writes: > > > > > > > > > I'm not aware of any specific problem with higher-grade firewalls > > > > > interfering with the subsequent queries sent between the recursive > > > > > resolvers and authoritative servers. > > > > > > > > Sometimes the issue is with the configuration rather than the > > > > device. The following is a snippet from a PIX config. > > > > > > > > policy-map type inspect dns preset_dns_map > > > > parameters > > > > message-length maximum 512 > > > > > > > > A google search for "message-length maximum 512" suggests this > > > > is not uncommon, and indeed appears to be splashed over a number > > > > of cisco.com example configs. > > > > > > And you will also see people saying to raise this to 4096. > > > > > > Mark > > > > > > > is there any good reason not to? if, of course, they > > want to follow the protocol... > > The protocol was extended 10 years ago give or take a couple of > months. These firewalls were written well after the extension was > published. Firewall designers need to understand the protocols > they are playing with. It was not like there were not active > examples around when these were designed. The designers just didn't > do their home work. so there is no good reason to not change the default configuration to comply with the RFC. and this advice should be applicable to all designers/developers... to follow the RFCs? --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 18:16:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BE543A6939; Fri, 26 Jun 2009 18:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[AWL=-0.928, 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 z6LisKq7Vqic; Fri, 26 Jun 2009 18:16:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 227F53A69F1; Fri, 26 Jun 2009 18:16:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKMON-0001Kt-Nj for namedroppers-data0@psg.com; Sat, 27 Jun 2009 01:07:43 +0000 Received: from [209.85.216.171] (helo=mail-px0-f171.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKMNy-0001Id-46 for namedroppers@ops.ietf.org; Sat, 27 Jun 2009 01:07:26 +0000 Received: by pxi1 with SMTP id 1so2048574pxi.5 for ; Fri, 26 Jun 2009 18:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=GNILIxCiLBkOlVgL8XgDB3N7kZN2uDdCoSBRFbOhuLE=; b=x3v90PSypbBE3lAUM6BFJgFctTBCFAd1co1KNLXZkZW7KjYpeozokbowIbCbHgjOEt OWvSWjGNS/TUZU5vjsCGkhJQj1rjpL/t8UcpgWc0jrp1CB4PQU5+4c57IfeBIM0Rv7/Y wUSgvGLg+89MMfAbmj5jK0CGCxnKi/EF5rmAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=r3Sl3i4ssJeYiHyK0lPOz3gT8Y8+x+pe8UK95ChheQWWmnz+uDHLwQDsw+/0aA6Pt+ CGgeeJNFIiY51babJPlhuinjo43aUSrNh8RRCjT+3mb8IoPy3sPyrayyB2wh7pUiau2T RNYrnoJ200xp4kN4nOI7Hi0LIi5pFS4dHqkXs= Received: by 10.114.159.6 with SMTP id h6mr6890486wae.19.1246064837863; Fri, 26 Jun 2009 18:07:17 -0700 (PDT) Received: from SJC-Office-NAT-219.mail-abuse.org (SJC-Office-NAT-219.mail-abuse.org [168.61.10.219]) by mx.google.com with ESMTPS id l38sm6963819waf.26.2009.06.26.18.07.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 26 Jun 2009 18:07:16 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: <805D136E-D44C-4A4E-B73E-00C31CB4BEDC@gmail.com> From: Doug Otis To: Paul Vixie In-Reply-To: <41105.1246045000@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) Date: Fri, 26 Jun 2009 18:07:13 -0700 References: <6DEF4FE2680060703ED2D6C3@Ximines.local> <200906261420.n5QEK6G7041937@drugs.dv.isc.org> <20090626171625.GA21700@vacation.karoshi.com.> <563EACD0B64DA52B0FC17C2F@Ximines.local> <41105.1246045000@nsa.vix.com> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 26, 2009, at 12:36 PM, Paul Vixie wrote: >> Date: Fri, 26 Jun 2009 18:40:51 +0100 >> From: Alex Bligh >> >> I'm not trying to pick on Cisco here, just point out that the idea >> there will be no interfering middleboxen in front of corporate >> connections is probably wrong. > > no doubt every single operator or implementor or businessman who > sees udp/53 as the right shim layer to jam in their extra > functionality has a reason, but the end effect is to make any > changes to the protocol extremely expensive, and i still think it'll > drive us toward dns-over-https as a way to drive a stake through > this middleism once and finally. Does that mean DNSSEC will not be thwarting middleboxen that change DNS responses? HTTPS on a large scale is also fairly expensive compared to DNS. TCP connections not in the ESTABLISHED state are normally not controllable by applications, and TCP related kernel restrictions against applications are often not aimed at assuring its availability. TCP's band-aided vulnerabilities and clumsy buffer processing is not really well suited for DNS. Reliance upon TCP when under attack will likely necessitate significantly greater resources and specialized defenses. Many resource related vulnerabilities or DDoS concerns could be better addressed using a different transport. Having an available alternative might represent a valuable refuge during times of attack. Instantiating an alternative may also prove to offer valuable insurance. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 26 23:53:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE043A6CCF; Fri, 26 Jun 2009 23:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=-0.701, 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 918-tkKJgaa8; Fri, 26 Jun 2009 23:53:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4CACE3A687E; Fri, 26 Jun 2009 23:53:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKRjX-000Nxd-RU for namedroppers-data0@psg.com; Sat, 27 Jun 2009 06:49:55 +0000 Received: from [209.85.219.227] (helo=mail-ew0-f227.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKRjF-000Nvm-HT for namedroppers@ops.ietf.org; Sat, 27 Jun 2009 06:49:49 +0000 Received: by ewy27 with SMTP id 27so3422011ewy.41 for ; Fri, 26 Jun 2009 23:49:34 -0700 (PDT) Received: by 10.216.0.79 with SMTP id 57mr1442702wea.48.1246085374539; Fri, 26 Jun 2009 23:49:34 -0700 (PDT) Received: from ?192.168.1.3? (62-30-111-115.cable.ubr07.dals.blueyonder.co.uk [62.30.111.115]) by mx.google.com with ESMTPS id i6sm10363222gve.7.2009.06.26.23.49.33 (version=SSLv3 cipher=RC4-MD5); Fri, 26 Jun 2009 23:49:33 -0700 (PDT) Message-Id: <58014C1D-E09B-41CC-B7FA-C3F5A65549AF@sabahattin-gucukoglu.com> From: Sabahattin Gucukoglu To: ietf-honest@lists.iadl.org, namedroppers-honest@lists.iadl.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: [dnsext] ops.ietf.org Blacklisting Complications Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 27 Jun 2009 07:41:10 +0100 X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ops.ietf.org is hosted at psg.com, which uses blacklists from the MAPS. I take no position on either MAPS or the external hosting, but I object to the use of RBLs for filtering IETF traffic. This seems to go against the IESG spam policy statement, which makes it quite clear that participants should not be disrupted (although not necessarily to the extent that it forbids RBL use). http://www.ietf.org/IESG/STATEMENTS/spam-control-policy.html My mail to ops.ietf.org itself isn't filtered, but my mail to psg.com is. I am using a Google smarthost with Google Apps. I do not consider myself a spammer and don't reflect my neighbours reputations, good or bad, upon myself, in order the better to assist the agenda of RBL operators. I don't know what Google's reputation is, but I am using their service because I find it reliable. There is simply no reason to block the legitimate traffic. But psg.com processes mailing list requests for ops.ietf.org, and every time I want to send mail to ops.ietf.org I have to carefully rewrite it. If nothing else, I want people to be aware of the situation. I would, of course, like ops.ietf.org to fall under proper IETF administration guidelines. Cheers, Sabahattin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 27 00:10:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F0F3A68A2; Sat, 27 Jun 2009 00:10:16 -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 5tzEm8T98FOL; Sat, 27 Jun 2009 00:10:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81DE93A687E; Sat, 27 Jun 2009 00:10:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKRzx-000PrM-0j for namedroppers-data0@psg.com; Sat, 27 Jun 2009 07:06:53 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKRzi-000PqA-BF for namedroppers@ops.ietf.org; Sat, 27 Jun 2009 07:06:45 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 4900CE606E for ; Sat, 27 Jun 2009 07:06:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n5R76Y03051521 for ; Sat, 27 Jun 2009 17:06:34 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200906270706.n5R76Y03051521@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) In-reply-to: Your message of "Sat, 27 Jun 2009 07:20:03 +0100." <2BEF3C0F30F143D18E720A3E36001E1D@localhost> Date: Sat, 27 Jun 2009 17:06:34 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <2BEF3C0F30F143D18E720A3E36001E1D@localhost>, "George Barwood" write s: > > ----- Original Message ----- > From: "Mark Andrews" > To: > Cc: "Mark Andrews" ; "Alex Bligh" ; ; > Sent: Friday, June 26, 2009 11:50 PM > Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) > > > > > > In message <20090626171625.GA21700@vacation.karoshi.com.>, bmanning@vacation.ka > > roshi.com writes: > >> On Sat, Jun 27, 2009 at 12:20:05AM +1000, Mark Andrews wrote: > >> > > >> > In message <6DEF4FE2680060703ED2D6C3@Ximines.local>, Alex Bligh writes: > >> > > > >> > > > I'm not aware of any specific problem with higher-grade firewalls > >> > > > interfering with the subsequent queries sent between the recursive > >> > > > resolvers and authoritative servers. > >> > > > >> > > Sometimes the issue is with the configuration rather than the > >> > > device. The following is a snippet from a PIX config. > >> > > > >> > > policy-map type inspect dns preset_dns_map > >> > > parameters > >> > > message-length maximum 512 > >> > > > >> > > A google search for "message-length maximum 512" suggests this > >> > > is not uncommon, and indeed appears to be splashed over a number > >> > > of cisco.com example configs. > >> > > >> > And you will also see people saying to raise this to 4096. > >> > > >> > Mark > >> > > >> > >> is there any good reason not to? if, of course, they > >> want to follow the protocol... > > > > The protocol was extended 10 years ago give or take a couple of > > months. These firewalls were written well after the extension was > > published. Firewall designers need to understand the protocols > > they are playing with. It was not like there were not active > > examples around when these were designed. The designers just didn't > > do their home work. > > Isn't it the firewall configuration, rather than the firewall designer? It's the designers that added "message-length maximum " to the firewall's syntax. > Regardless, system administrators did follow the existing standard, > and I think it is rather the fault of RFC 2671 for breaking an existing > standard. RFC 2671 allows the two parties involved to negotiate the use of additional features. This is common to lots of protocols. It is also all that should be reqired. > I suggest an extension mechanism that allows for DNSSEC messages to be > conveyed through the existing deployed transport ( 512 byte UDP packets ) > should have been defined, and this can still be done, along the lines of my > "EDNS Page Option to handle large responses", > http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01278.html Multiple messages were thought about and rejected. We still need the MORE bit for TCP at some point. > The goal should be to allow DNSSEC to be deployed without reconfiguring > firewalls or anything other than the DNS software. Sorry, firewalls should not be a reason to not do something. That's the tail wagging the dog. 10 years should have been enough for firewall vendor to fix their products especially when we complained to most of the over 5 years ago about their in action. It's the firewalls role to adapt to changes in the protocols. > > Network Working Group P. Vixie > > Request for Comments: 2671 ISC > > Category: Standards Track August 1999 > > > > If they want to live by RFC1034 then they should examine the queries > > and return FORMERR on them for having garbage in the additional > > section. This would have made extending the DNS predicable. > > No, there is nothing in RFC1034 or RFC 1035 that specifies that > an OPT record should cause a FORMERR. In any communications > standard there may be reserved areas in the packet format that are > not defined, and may be used at some future point to extend the protocol. FORMERR is the error code to be returned when you don't understand the query. That is the point of the error code. > These can be header bits, code points ( e.g. RR TYPE codes ), > or correctly formatted records where the meaning is not defined. > > The proper way to process reserved areas is to ignore them. > Unfortunately many implementations get this wrong, so it would have > been better if the original standard had been more explicit on this principle. There are lots of things RFC 103[345] should have done better however it was reasonable for the time. The additional section was not a reserved area in queries. > > Alternatively they should examine the queries and set the allowed > > response size based on the EDNS options in the query. There is no > > need for a one size solution. > > > > And for the record there have been larger than 512 bytes responses > > over UDP between co-operating machines as long as I've been involved > > with DNS and thats over 20 years now. EDNS just provided a standards > > based mechanism for doing so. We had code to catch and handle > > responses from such servers years before EDNS was dreamed of. > > > > Mark > > > >> > >> --bill > >> > >> -- > >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >> the word 'unsubscribe' in a single line as the message text body. > >> archive: > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 27 01:04:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F0B3A6A7E; Sat, 27 Jun 2009 01:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irnodrYmqdmF; Sat, 27 Jun 2009 01:04:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E20723A69B6; Sat, 27 Jun 2009 01:04:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKSqy-0003kx-Nw for namedroppers-data0@psg.com; Sat, 27 Jun 2009 08:01:40 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKSql-0003js-Kw for namedroppers@ops.ietf.org; Sat, 27 Jun 2009 08:01:33 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id EE76EA71B4; Sat, 27 Jun 2009 08:01:26 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Doug Otis cc: namedroppers@ops.ietf.org Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) In-Reply-To: Your message of "Fri, 26 Jun 2009 18:07:13 MST." <805D136E-D44C-4A4E-B73E-00C31CB4BEDC@gmail.com> References: <6DEF4FE2680060703ED2D6C3@Ximines.local> <200906261420.n5QEK6G7041937@drugs.dv.isc.org> <20090626171625.GA21700@vacation.karoshi.com.> <563EACD0B64DA52B0FC17C2F@Ximines.local> <41105.1246045000@nsa.vix.com> <805D136E-D44C-4A4E-B73E-00C31CB4BEDC@gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sat, 27 Jun 2009 08:01:26 +0000 Message-ID: <75293.1246089686@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: Doug Otis > Date: Fri, 26 Jun 2009 18:07:13 -0700 > > ..., and i still think it'll drive us toward dns-over-https as a way to > > drive a stake through this middleism once and finally. > > Does that mean DNSSEC will not be thwarting middleboxen that change DNS > responses? no it doesn't mean that. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 27 09:50:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8147D3A69A4; Sat, 27 Jun 2009 09:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.046 X-Spam-Level: X-Spam-Status: No, score=0.046 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MspGDKRIN96p; Sat, 27 Jun 2009 09:50:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 03DAE3A68A0; Sat, 27 Jun 2009 09:50:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKaxo-000JK7-Tt for namedroppers-data0@psg.com; Sat, 27 Jun 2009 16:41:16 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKaxd-000JIH-LB for namedroppers@ops.ietf.org; Sat, 27 Jun 2009 16:41:11 +0000 Received: from [192.168.1.102] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5RGexYs022871; Sat, 27 Jun 2009 12:41:00 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200906262256.n5QMuiAY048752@drugs.dv.isc.org> References: <200906262256.n5QMuiAY048752@drugs.dv.isc.org> Date: Sat, 27 Jun 2009 12:40:53 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] Nested trust anchors (again) Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: >Try any key does not mean try any trust anchor. When I spent a lot of time analyzing the words in RFC 1034, section 4.3.2, leading towards the wildcard update document RFC 45something-or-other, a wise sage, Rob Austein, scolded me when I took the words "too literally," saying that the text in RFCs are not specifications, not a strawman of instructions, not a flowchart in text, not even pseudocode but simply an engineering description of the approach to solving the "problem." DNSSEC has always maintained that local policy rules. While the RFCs contain detailed information on the ways in which bits are manipulated to sign and validate data, the information on what a positive or negative outcome of a crypto-step is left to local interpretation. The chief concern of the IETF, and that is conveyed via the RFCs, is interoperability and not overall "performance." I.e., what is specified is what is needed to make elements inter-relate and not all they need to do. Back when I wrote an early validating application in 1998 I made some design choices. I realized then one could write a ruggedized resolver that tried to get an answer in the face of a forged reply or one could write a lightweight resolver that would give up at the moment any irregularity was encountered. Both approaches met the "requirements" of the RFC, both would interoperate, but one served it's user better, i.e., was of higher quality in my estimation. When it comes to statements like "try any key does not mean try any trust anchor" I have to say I agree but at the same time, I wouldn't accept code that meets such a low bar of quality for my own use. E.g., I don't buy the cheapest legal tires for my car because I don't like to skid in a light rain - even though that is accepted legally. Whether "try any key does not mean try any trust anchor" is not a point over which consensus matters to me, it's useless breadth to get to consensus as this is a matter of quality and not interoperability. The question is up to implementers, do they want to produce code that gets the job done or just merely meets the minimum acceptable needs and interoperates? The question is, is an implementor trying hard to interpret the RFCs for to make code writing easy or trying to determine what is the best approach to solving a real world problem? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 27 10:49:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7882F28C213; Sat, 27 Jun 2009 10:49:11 -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.921, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 Z4aGZl6ig2rp; Sat, 27 Jun 2009 10:49:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 228CA28C163; Sat, 27 Jun 2009 10:49:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKbwj-000Nut-9N for namedroppers-data0@psg.com; Sat, 27 Jun 2009 17:44:13 +0000 Received: from [76.96.62.56] (helo=QMTA06.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MKbwX-000Nsv-Ss for namedroppers@ops.ietf.org; Sat, 27 Jun 2009 17:44:07 +0000 Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA06.westchester.pa.mail.comcast.net with comcast id 94Gv1c00616LCl0565k2rd; Sat, 27 Jun 2009 17:44:02 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.201]) by OMTA06.westchester.pa.mail.comcast.net with comcast id 95k11c0074LCBKY3S5k1Qe; Sat, 27 Jun 2009 17:44:02 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 27 Jun 2009 13:43:59 -0400 To: Mark Andrews ,Edward Lewis From: Michael StJohns Subject: Re: [dnsext] Nested trust anchors (again) Cc: Andrew Sullivan ,namedroppers@ops.ietf.org In-Reply-To: <200906262256.n5QMuiAY048752@drugs.dv.isc.org> References: <200906262256.n5QMuiAY048752@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_176360187==.ALT" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: --=====================_176360187==.ALT Content-Type: text/plain; charset="us-ascii" At 06:56 PM 6/26/2009, Mark Andrews wrote: >Trust anchors refer to keys but >are not keys themselves. The rules for keys do not apply. Could you explain your reasoning for BOTH of the above statements please? (e.g. which rules don't apply and why?) 4033 is clear that the trust anchor is "A configured DNSKEY RR or a DS RR hash of a DNSKEY RR". The first form is obviously a key. The second form is a key reference that is just shorthand for the key given the way DNSSEC is defined. From WIKI - (Yeah, I know -but this is close to the definitions I've seen for PKI trust anchors and others including in the X509 standard) "In cryptography, a Trust Anchor is an authoritative entity represented via a public key and associated data." From X509 "trust anchor: A trust anchor is a set of the following information in addition to the public key: algorithm identifier, public key parameters (if applicable), distinguished name of the holder of the associated private key (i.e., the subject CA) and optionally a validity period. The trust anchor may be provided in the form of a self-signed certificate. A trust anchor is trusted by a certificate using system and used for validating certificates in certification paths. " All of these say - a trust anchor is a public key with associated data (trust point name, algorithms, conditions etc). Why do you disagree? Mike --=====================_176360187==.ALT Content-Type: text/html; charset="us-ascii" At 06:56 PM 6/26/2009, Mark Andrews wrote:
Trust anchors refer to keys but
are not keys themselves.  The rules for keys do not apply.

Could you explain your reasoning for BOTH of the above statements please? (e.g. which rules don't apply and why?)

4033 is clear that the trust anchor is "A configured DNSKEY RR or a DS RR hash of a DNSKEY RR".  The first form is obviously a key.  The second form is a key reference that is just shorthand for the key given the way DNSSEC is defined.

From WIKI - (Yeah, I know -but this is close to the definitions I've seen for PKI trust anchors and others including in the X509 standard) "In cryptography, a Trust Anchor is an authoritative entity represented via a public key and associated data."

From X509 "trust anchor: A trust anchor is a set of the following information in addition to the public key: algorithm identifier, public key parameters (if applicable), distinguished name of the holder of the associated private key (i.e., the subject CA) and optionally a validity period. The trust anchor may be provided in the form of a self-signed certificate. A trust anchor is trusted by a certificate using system and used for validating certificates in certification paths. "

All of these say - a trust anchor is a public key with associated data (trust point name, algorithms, conditions etc).

Why do you disagree?

Mike
--=====================_176360187==.ALT-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From firmamentsfe030@serbianhost.com Sat Jun 27 10:56:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C31A28C111; Sat, 27 Jun 2009 10:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -64.214 X-Spam-Level: X-Spam-Status: No, score=-64.214 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_WEIGHT_LOSS=2.134, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_NUMERIC_HELO=2.067, 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 xz8Dp8wvMKH0; Sat, 27 Jun 2009 10:56:33 -0700 (PDT) Received: from 201.22.83.153.dynamic.adsl.gvt.net.br (201.22.83.153.dynamic.adsl.gvt.net.br [201.22.83.153]) by core3.amsl.com (Postfix) with ESMTP id 4145428C213; Sat, 27 Jun 2009 10:56:33 -0700 (PDT) Message-ID: <000d01c9f750$a63bc8b0$6400a8c0@firmamentsfe030> From: dnsext-archive@ietf.org To: Subject: Amazing weight loss now you can get it FREE Date: Sat, 27 Jun 2009 14:56:51 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F750.A63BC8B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F750.A63BC8B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Acai Berry , Lose wieght feel great.=20 Feel great with Acai Flush.   Bash this site =20 =20 Thank You!=20 best regards Lurline=20 Broussard ------=_NextPart_000_0007_01C9F750.A63BC8B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Acai Berry , Lose wieght feel great.
Feel great with Acai Flush.
 
Bash this site
Thank You!
best regards Lurline=20 Broussard
------=_NextPart_000_0007_01C9F750.A63BC8B0-- From fecframe-bounces@ietf.org Sat Jun 27 10:56:35 2009 Return-Path: X-Original-To: dnsext-archive@ietf.org Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9733428C215 for ; Sat, 27 Jun 2009 10:56:35 -0700 (PDT) Subject: The results of your email commands From: fecframe-bounces@ietf.org To: dnsext-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1807837141==" Message-ID: Date: Sat, 27 Jun 2009 10:56:34 -0700 Precedence: bulk X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of FEC Framework X-List-Administrivia: yes Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org --===============1807837141== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Unprocessed: Feel great with Acai Flush.   Bash this site =20 =20 Thank You!=20 best regards Lurline=20 Broussard - Done. --===============1807837141== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: fecframe-request@core3.amsl.com Delivered-To: fecframe-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C31A28C111; Sat, 27 Jun 2009 10:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -64.214 X-Spam-Level: X-Spam-Status: No, score=-64.214 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_WEIGHT_LOSS=2.134, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_NUMERIC_HELO=2.067, 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 xz8Dp8wvMKH0; Sat, 27 Jun 2009 10:56:33 -0700 (PDT) Received: from 201.22.83.153.dynamic.adsl.gvt.net.br (201.22.83.153.dynamic.adsl.gvt.net.br [201.22.83.153]) by core3.amsl.com (Postfix) with ESMTP id 4145428C213; Sat, 27 Jun 2009 10:56:33 -0700 (PDT) Message-ID: <000d01c9f750$a63bc8b0$6400a8c0@firmamentsfe030> From: dnsext-archive@ietf.org To: Subject: Amazing weight loss now you can get it FREE Date: Sat, 27 Jun 2009 14:56:51 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F750.A63BC8B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F750.A63BC8B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Acai Berry , Lose wieght feel great.=20 Feel great with Acai Flush.   Bash this site =20 =20 Thank You!=20 best regards Lurline=20 Broussard ------=_NextPart_000_0007_01C9F750.A63BC8B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Acai Berry , Lose wieght feel great.
Feel great with Acai Flush.
 
Bash this site
Thank You!
best regards Lurline=20 Broussard
------=_NextPart_000_0007_01C9F750.A63BC8B0-- --===============1807837141==-- From cartl747@lastminute.com.hk Sat Jun 27 10:56:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88D528C217 for ; Sat, 27 Jun 2009 10:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.035 X-Spam-Level: X-Spam-Status: No, score=-65.035 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_NUMERIC_HELO=2.067, 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 T3lKPKkEcudH for ; Sat, 27 Jun 2009 10:56:35 -0700 (PDT) Received: from 201.22.83.153.dynamic.adsl.gvt.net.br (201.22.83.153.dynamic.adsl.gvt.net.br [201.22.83.153]) by core3.amsl.com (Postfix) with ESMTP id 9714128C111 for ; Sat, 27 Jun 2009 10:56:34 -0700 (PDT) Message-ID: <000d01c9f750$a6d45f30$6400a8c0@cartl747> From: f@ietf.org To: Subject: Get Thin Easily with Acai Berry Date: Sat, 27 Jun 2009 14:56:52 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F750.A6D45F30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F750.A6D45F30 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Acai Berry is amazingly smooth and suprisingly tasty, Get your free trial.=20 Acai berry will change your life.   A chance to visit =20 =20 Thank You!=20 best regards Louise=20 Bunch ------=_NextPart_000_0007_01C9F750.A6D45F30 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Acai Berry is amazingly smooth and suprisingly tasty, Get your fre= e trial.
Acai berry will change your life.
 
A chance to visit
Thank You!
best regards Louise=20 Bunch
------=_NextPart_000_0007_01C9F750.A6D45F30-- From owner-namedroppers@ops.ietf.org Sun Jun 28 16:32:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D2F3A68BB; Sun, 28 Jun 2009 16:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=-1.650, 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 e0n2gXyDJwpf; Sun, 28 Jun 2009 16:32:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CEF0E3A6824; Sun, 28 Jun 2009 16:32:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ML3k0-000GyB-G2 for namedroppers-data0@psg.com; Sun, 28 Jun 2009 23:24:56 +0000 Received: from [131.111.8.130] (helo=ppsw-0.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ML3jl-000Gx5-AZ for namedroppers@ops.ietf.org; Sun, 28 Jun 2009 23:24:50 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:53180) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1ML3jg-0003Me-2c (Exim 4.70) (return-path ); Mon, 29 Jun 2009 00:24:36 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1ML3jg-0005Sn-Pi (Exim 4.67) (return-path ); Mon, 29 Jun 2009 00:24:36 +0100 Date: Mon, 29 Jun 2009 00:24:36 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Mark Andrews cc: bmanning@vacation.karoshi.com, Alex Bligh , Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) In-Reply-To: <200906262250.n5QMo4J8048639@drugs.dv.isc.org> Message-ID: References: <200906262250.n5QMo4J8048639@drugs.dv.isc.org> 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: On Sat, 27 Jun 2009, Mark Andrews wrote: > > > > > Sometimes the issue is with the configuration rather than the > > > > device. The following is a snippet from a PIX config. > > The protocol was extended 10 years ago give or take a couple of > months. These firewalls were written well after the extension was > published. PIXes are much older than that. They are notorious for screwing up many higher-level protocols. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 28 23:08:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2536D3A6C8C; Sun, 28 Jun 2009 23:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-g6MOIIBMRK; Sun, 28 Jun 2009 23:08:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3BA593A6A43; Sun, 28 Jun 2009 23:08:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ML9uu-000Lku-7V for namedroppers-data0@psg.com; Mon, 29 Jun 2009 06:00:36 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ML9uj-000Lk6-20 for namedroppers@ops.ietf.org; Mon, 29 Jun 2009 06:00:30 +0000 Received: from [10.49.158.175] (shed [217.147.82.63]) by mail.avalus.com (Postfix) with ESMTPA id 7DF7FC2DA3; Mon, 29 Jun 2009 07:00:19 +0100 (BST) Date: Mon, 29 Jun 2009 07:00:29 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Tony Finch , Mark Andrews cc: bmanning@vacation.karoshi.com, Ray.Bellis@nominet.org.uk, namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) Message-ID: <6B107B92F5436C52AA79B4FE@nimrod.local> In-Reply-To: References: <200906262250.n5QMo4J8048639@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --On 29 June 2009 00:24:36 +0100 Tony Finch wrote: >> > > > Sometimes the issue is with the configuration rather than the >> > > > device. The following is a snippet from a PIX config. >> >> The protocol was extended 10 years ago give or take a couple of >> months. These firewalls were written well after the extension was >> published. > > PIXes are much older than that. They are notorious for screwing up many > higher-level protocols. Indeed, but that particular bit of CLI (and it being a default) is far more recent, and is in (e.g.) ASA 5500 / 5510 / 5520. -- Alex Bligh -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 29 03:36:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C853A67E6; Mon, 29 Jun 2009 03:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=0.198, 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 EzwbgyysaOmB; Mon, 29 Jun 2009 03:36:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7F3EA3A6889; Mon, 29 Jun 2009 03:36:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLE8C-000Ijf-96 for namedroppers-data0@psg.com; Mon, 29 Jun 2009 10:30:36 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLE80-000Iik-6y for namedroppers@ops.ietf.org; Mon, 29 Jun 2009 10:30:29 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 79D453A67E6; Mon, 29 Jun 2009 03:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-rfc2672bis-dname-16.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090629103002.79D453A67E6@core3.amsl.com> Date: Mon, 29 Jun 2009 03:30:02 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Update to DNAME Redirection in the DNS Author(s) : S. Rose, W. Wijngaards Filename : draft-ietf-dnsext-rfc2672bis-dname-16.txt Pages : 17 Date : 2009-06-29 The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2672bis-dname-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-29032631.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 29 03:37:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C2B3A6D47; Mon, 29 Jun 2009 03:37:40 -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 SkDXP8xYcSOY; Mon, 29 Jun 2009 03:37:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 538C03A6C92; Mon, 29 Jun 2009 03:37:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLE9d-000IsF-Nj for namedroppers-data0@psg.com; Mon, 29 Jun 2009 10:32:05 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLE9Q-000Iq3-Gd for namedroppers@ops.ietf.org; Mon, 29 Jun 2009 10:31: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.3/8.14.3) with ESMTP id n5TAVmDP008077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Jun 2009 12:31:48 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4A489814.3070903@nlnetlabs.nl> Date: Mon, 29 Jun 2009 12:31:48 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: "namedroppers@ops.ietf.org" Subject: [dnsext] updated dname update draft (-16) X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 29 Jun 2009 12:31:48 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Scott and I have updated the draft from the last WGLC. The UD bit text has been removed, based on the little discussion on namedroppers. I think as it stands the only behaviour change is now the text that warns against picking DNAMEs out of the cache, for fear of 'Kaminsky'. Best regards, On behalf of the editors, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpImBQACgkQkDLqNwOhpPgdYgCeNMSPZ8pUDbcumNoFrBwH8U8W xYgAnjiPmqkgkQzJQ1mT143skEpZvo1D =YiNV -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From interpretnkg@lists.drogon.net Mon Jun 29 05:39:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F89A28C264; Mon, 29 Jun 2009 05:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.714 X-Spam-Level: X-Spam-Status: No, score=-28.714 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, FS_START_LOSE=1.493, GB_OPRAH=2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SUBJECT_DIET=1.466, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bBH2tQPfxiu; Mon, 29 Jun 2009 05:39:54 -0700 (PDT) Received: from host161-181-static.80-94-b.business.telecomitalia.it (host161-181-static.80-94-b.business.telecomitalia.it [94.80.181.161]) by core3.amsl.com (Postfix) with ESMTP id E253028C265; Mon, 29 Jun 2009 05:39:53 -0700 (PDT) Message-ID: <000d01c9f8b6$bef344c0$6400a8c0@interpretnkg> From: dix-request@ietf.org To: Subject: Lose Weight without the effort it takes Date: Mon, 29 Jun 2009 14:40:12 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F8B6.BEF344C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F8B6.BEF344C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Acai Berry supplement has helped me lose 30 pounds Oprah Is an Acai Berry Success story.   Click everyone =20 =20 Thank You!=20 best regards Abdiel=20 Milligan ------=_NextPart_000_0007_01C9F8B6.BEF344C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Acai Berry supplement has helped me lose 30 pounds=
 
Click everyone
Thank You!
best regards Abdiel=20 Milligan
------=_NextPart_000_0007_01C9F8B6.BEF344C0-- From assortingin170@larkfield.com.au Mon Jun 29 06:02:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49CDC28C1F9; Mon, 29 Jun 2009 06:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.373 X-Spam-Level: X-Spam-Status: No, score=-33.373 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=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, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UH73sr267unx; Mon, 29 Jun 2009 06:02:40 -0700 (PDT) Received: from ppp-94-64-67-48.home.otenet.gr (ppp-94-64-67-48.home.otenet.gr [94.64.67.48]) by core3.amsl.com (Postfix) with ESMTP id C127828C261; Mon, 29 Jun 2009 06:02:38 -0700 (PDT) Message-ID: <000d01c9f8b9$ebebb0e0$6400a8c0@assortingin170> From: dnsext-archive@lists.ietf.org To: Subject: total physicak renewal with the acai berry, try it free today Date: Mon, 29 Jun 2009 16:02:56 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F8B9.EBEBB0E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F8B9.EBEBB0E0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Discover Acai Berry numerous weight loss and health benefits.=20 Acai Berry will help you lose fat safely and effeciently.   Press this button =20 =20 Thank You!=20 best regards Rey=20 Rankin ------=_NextPart_000_0007_01C9F8B9.EBEBB0E0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Discover Acai Berry numerous weight loss and health benefits.
Acai Berry will help you lose fat safely and effeciently.
 
Press this button
Thank You!
best regards Rey=20 Rankin
------=_NextPart_000_0007_01C9F8B9.EBEBB0E0-- From thumpsr@minton.com.tw Mon Jun 29 10:30:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7787A3A6A75; Mon, 29 Jun 2009 10:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.803 X-Spam-Level: X-Spam-Status: No, score=-76.803 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=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, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_ALC=1.405, SARE_SUB_IMPROVE=0.641, SARE_UNI=0.591, 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 7+uCsCRPj5-g; Mon, 29 Jun 2009 10:30:42 -0700 (PDT) Received: from 187-27-208-147.3g.claro.net.br (187-27-224-196.3g.claro.net.br [187.27.224.196]) by core3.amsl.com (Postfix) with ESMTP id 4771A3A6A36; Mon, 29 Jun 2009 10:30:15 -0700 (PDT) Message-ID: <000d01c9f8df$44673620$6400a8c0@thumpsr> From: dnsext-archive@lists.ietf.org To: Subject: Improve your health with Acain Berry. Date: Mon, 29 Jun 2009 14:30:16 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F8DF.44673620" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F8DF.44673620 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 Email=20 not displaying correctly? View=20 it in your browser. =20 =20 =20 =20 =20 =20 =A0 Official=20 Daily newsletter =20 This is a reality when just by adding the great tasting acai be= rry to your diet. Lose weight without stress , Acai Berry. =A0=A0=A0=A0=A0Come and click =20 =20 You=20 are subscribed as :dnsext-archive@lists.ietf.org. Username:=20 dnsext-archive Unsubscribe=20 from this list. Manage=20 your subscriptions. View=20 the newsletter=20 archives. ¿=20 Copyright 2008 luuods. All rights reserved. ------=_NextPart_000_0007_01C9F8DF.44673620 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
Email=20 not displaying correctly? View=20 it in your browser.
=A0 Official=20 Daily newsletter

This is a reality when just by adding = the great tasting acai berry to your diet.

Lose weight without stress , Acai Berr= y.

=A0=A0=A0=A0=A0Come and click

 You=20 are subscribed as :dnsext-archive@lists.ietf.org. Username:=20 dnsext-archive Unsubscribe=20 from this list.

Manage=20 your subscriptions.

View=20 the newsletter=20 archives.

¿=20 Copyright 2008 luuods. All rights reserved.
Oprah Is an Acai Berry Success story.
------=_NextPart_000_0007_01C9F8DF.44673620-- From owner-namedroppers@ops.ietf.org Mon Jun 29 10:44:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62D63A6956; Mon, 29 Jun 2009 10:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[AWL=-0.061, 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 wTXg98CrV6a3; Mon, 29 Jun 2009 10:44:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 23B4C3A6A67; Mon, 29 Jun 2009 10:43:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLKnu-000CmH-HI for namedroppers-data0@psg.com; Mon, 29 Jun 2009 17:38:06 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLKne-000CkO-Ud for namedroppers@ops.ietf.org; Mon, 29 Jun 2009 17:37:57 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5THbn7k006327; Mon, 29 Jun 2009 10:37:49 -0700 (PDT) Message-Id: From: Nicholas Weaver To: IETF DNSEXT WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: [dnsext] Response to request for real data... Date: Mon, 29 Jun 2009 10:37:49 -0700 Cc: Nicholas Weaver , Netalyzr Development X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: A preliminary analysis of EDNS behavior This represents some preliminary analysis from Netalyzr (http://netalyzr.icsi.berkeley.edu ) with how EDNS is used and supportable by both end-user connections and by recursive resolvers. To date, over 40,000 distinct IPs have run Netalyzr to completion. Please note that there is bias in terms of the users who have run Netalyzr, arising from how users learn about our site and what leads them to decide to run the tests. In particular, we already know that an unusually high fraction of IPs are from Comcast (~4900) due to an initial slashdot article which mentioned Netalyzr in the context of assessing Comcast, and a large number are from t-dialin.net (~1500, tied for third in popularity) due to German-language coverage. Another likely bias is the popularity of OpenDNS: over 11% of Netalyzr's users appear to use OpenDNS as their recursive resolver. Likewise, there are double-counting issues when viewing data by resolver, and packet loss and timeouts may cause some figures to read high or low, adding noise to the results. Additionally, Netalyzr's test suite with regard to EDNS has not been static: the tests to determine the root cause of large-payload EDNS failures was a recent addition. Thus, for some of these tests there are far fewer data points available. Description of the tests Netalyzr works by having a Java applet on the user's computer conduct tests with servers we control. In particular, the node providing the applet hosts a DNS server, and this DNS server code is also running as the authority for .netalyzr.icsi.berkeley.edu. The DNS server is a custom Python implementation, and produces both standard and deliberately nonstandard responses for various queries. To determine if a user's resolver is EDNS or DNSSEC capable, the addresses has_edns.{x}.netalyzr.icsi.berkeley.edu and wants_dnssec... are queried by the Java applet. These return "true" if the condition is true, and false otherwise. (True is encoded by returning the IP of the back-end node the user is connected to, false uses a different IP address.) The EDNS0 OPT record, if present, is returned unchanged in the response. To determine the user's resolver's identity, the applet queries for server.{x}, which returns the IP address that our DNS authority received the query from. Note that this may cause a single resolver to be associated with multiple identities (creating double-counting) if that resolver generates requests through multiple IP addresses. To determine the user's resolver's EDNS MTU, the query edns_mtu... encodes the EDNS MTU in the two lower octets of the returned A record. This test is only run if the resolver indicates support for EDNS, and can only be captured if the user trusts the applet. To determine if the user's resolver can receive a large EDNS response, the applet queries for edns_large.{x}. This returns the true IP, but has a large number of CNAMES in the additional field, which is sufficient to pad the packet to ~1800B. This response is fragmented by the server when it is sent, as this is greater than the Ethernet MTU. Since the CNAMES are effectively garbage, we expect that most recursive resolvers will not return these as part of the final answer. This test is only run if the resolver indicates support for EDNS. To determine if the user's resolver can receive a medium sized EDNS response, the applet queries for edns_medium.{x}. This returns the true IP, but has a large number of CNAMES in the additional field, which is sufficient to pad the packet to ~1400B. This response is NOT fragmented by the server when it is sent, as this is less than the Ethernet MTU. It may be fragmented in the network later. This test is only run if the resolver indicates support for EDNS. To prevent ordering and history issues, the first tests are for EDNS and DO support, then EDNS MTU, then for medium-sized EDNS responses and then large EDNS responses. Thus, resolvers that maintain state in determining EDNS0 MTU and having a malfunctioning middlebox should, at least for the first run, not use a smaller than default EDNS0 MTU. Finally, the applet does a direct UDP-based DNS request (it tries 5 times until successful) directly to our server to query for edns_large, edns_medium, and edns_small (an EDNS-present response of ~300B), to check for the direct behavior of any DNS-aware middleboxes. These tests do not validate the response as correct, but other tests check for DNS-modifying middleboxes. EDNS and DNSSEC support If we view based on user IP address, 49% (19968 out of 40476) IP addresses use a recursive resolver that used EDNS0 in requests to our authority. 46% (18634 out of 40476) have DO enabled, indicating they wish to receive DNSSEC records. Please note a known bias: Comcast's resolvers, although they support EDNS0 when tested manually, do not appear to use it by default in most requests to our authority. As this represents 12% of all IP addresses which have run Netalyzr, this is a potentially significant undercount. Thus, the actual fraction of users behind an EDNS0 and/or DNSSEC using resolver may be somewhat higher. If we instead view based on observed resolver IP, this check covers 10852 recursive resolvers external addresses. Of these, 65% (7074 out of 10852) have EDNS0 enabled and a MTU > 1200B, with 58% (6286 out of 10852) having DO set as well. Please note a known bias: If a recursive resolver uses multiple IP addresses to generate queries, we will count it multiple times. For example, this counting method counts OpenDNS as at least 33 separate resolvers. EDNS failures and their probable causes If we view based on IP, 18458 IPs both have a resolver which advertises EDNS support and where we captured an advertised EDNS MTU greater than 1900B. Of these, only 87% (16050 out of 18458) successfully received the EDNS-large response. The more sophisticated version, which checks both large and medium, has far fewer data points. Of these, 87% (1946 out of 2232) were able to receive the large EDNS response, while 97.2% (2170 out of 2232) were able to receive the medium sized EDNS response. Likewise, if we view based on resolver, 86% (1284 out of 1489) were able to receive the large response and 96% (1431 out of 1489) were able to receive the medium response. Systems which can't handle large EDNS responses but can handle the medium sized responses are likely due to a middlebox which either can't handle DNS fragments, fragmented UDP traffic, or which assumes that DNS responses have to be smaller than ~1500B. Systems that can't handle the large and medium EDNS responses are likely due to middleboxes which can't handle DNS responses > 512B. If the middlebox couldn't handle EDNS, the edns-present query would have failed. The situation is similar for the end user's connection. On a query directly to our server from the applet, bypassing the recursive resolver, the EDNS large request is successful 86% of the time (3635 out of 4211), the medium is successful 95% of the time (4019 out of 4211), and the small is successful 99% of the time (4179 out of 4211). This suggests that for the end user there is a significant problem with middleboxes. Many middleboxes either can't NAT UDP fragments or do not reassemble fragmented DNS traffic before analysis, but a significant number simply assume that DNS packets are smaller than 1400B. We did not test the ability for middleboxes to parse DNSSEC responses or unknown RRTypes. This could also be a concern with DNSSEC deployments. Conclusions The natural conclusion is there are significant numbers of "DNS aware" middleboxes in the paths for both recursive resolvers and end-users that are incorrect: they fail to properly pass large DNS responses. Of the failures, the most common failure is that they don't reassemble fragments before processing DNS traffic, (or have some other failure which prevents > 1500B DNS responses from being processed), with an inability to handle > 512B responses a second concern. Among other things, this suggests that DNSSEC-using authorities that wish to minimize EDNS failures and/or TCP fallback attempt to, whenever possible, ensure that responses fit within the ethernet MTU. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From hulledhh19@telamericamedia.com Mon Jun 29 11:59:38 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729BF28C2C7; Mon, 29 Jun 2009 11:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.313 X-Spam-Level: X-Spam-Status: No, score=-26.313 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=2.75, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, SUBJECT_DIET=1.466, 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 YHLldtErSLlW; Mon, 29 Jun 2009 11:59:37 -0700 (PDT) Received: from host185-193-dynamic.40-79-r.retail.telecomitalia.it (host185-193-dynamic.40-79-r.retail.telecomitalia.it [79.40.193.185]) by core3.amsl.com (Postfix) with ESMTP id 5D59628C2C4; Mon, 29 Jun 2009 11:59:37 -0700 (PDT) Message-ID: <000d01c9f8eb$98bf80e0$6400a8c0@hulledhh19> From: dnsext-archive@lists.ietf.org To: Subject: Always wanted to lose weight click here for your best solutions now Date: Mon, 29 Jun 2009 20:58:32 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F8EB.98BF80E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F8EB.98BF80E0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 If you are having trouble=20 viewing this email, see=20 it on the=20 Web. =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Unsubscribe=20 | Change=20 Email Address | Update=20 Email Preferences | Privacy=20 Policy Highly nutricious Acai Berry available now! g= et your trial now.=20 =A0 Welcoming you Copyright C 2009=20 Myyibohioiqkrs=20 International,=20 Inc. =A0 ------=_NextPart_000_0007_01C9F8EB.98BF80E0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
If you are having t= rouble=20 viewing this email, see=20 it on the=20 Web.
= Unsu= bscribe=20 | Chan= ge=20 Email Address | Upda= te=20 Email Preferences | Priv= acy=20 Policy


 Highly nutricious Acai Berry avail= able now! get your trial now.
= =A0
= Welc= oming you


Copyright C 2009=20
Myyibohioiqkrs=20 International,=20 Inc.
=A0
------=_NextPart_000_0007_01C9F8EB.98BF80E0-- From tunad@matsuper.com Mon Jun 29 12:00:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808F828C2CE; Mon, 29 Jun 2009 12:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.331 X-Spam-Level: X-Spam-Status: No, score=-19.331 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_VERIZON_POOL=1.495, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQ8f05pk7MfH; Mon, 29 Jun 2009 12:00:57 -0700 (PDT) Received: from pool-71-109-170-55.lsanca.dsl-w.verizon.net (pool-71-109-170-55.lsanca.dsl-w.verizon.net [71.109.170.55]) by core3.amsl.com (Postfix) with ESMTP id 1F1A828C2C7; Mon, 29 Jun 2009 12:00:40 -0700 (PDT) Message-ID: <000d01c9f8eb$c4105ee0$6400a8c0@tunad> From: disman-bounces@ietf.org To: Subject: Look better in a bathing suit this summer get your free trial now Date: Mon, 29 Jun 2009 11:59:44 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F8EB.C4105EE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F8EB.C4105EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 If you are having trouble=20 viewing this email, see=20 it on the=20 Web. =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Unsubscribe=20 | Change=20 Email Address | Update=20 Email Preferences | Privacy=20 Policy weight and cleansing their bodies faster than= most other products on the market =A0 Enter without the key Copyright C 2009=20 Ltqkmxyoaepplk=20 International,=20 Inc. =A0 ------=_NextPart_000_0007_01C9F8EB.C4105EE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you are having t= rouble=20 viewing this email, see=20 it on the=20 Web.
= Unsu= bscribe=20 | Chan= ge=20 Email Address | Upda= te=20 Email Preferences | Priv= acy=20 Policy


 weight and cleansing their bodies = faster than most other products on the market=
= =A0
= Ente= r without the key


Copyright C 2009=20
Ltqkmxyoaepplk=20 International,=20 Inc.
=A0
------=_NextPart_000_0007_01C9F8EB.C4105EE0-- From sprintingdn80@joescrib.com Mon Jun 29 16:11:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAEE53A6BEE; Mon, 29 Jun 2009 16:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -64.621 X-Spam-Level: X-Spam-Status: No, score=-64.621 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=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, FS_START_LOSE=1.493, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, 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 F2mvTWmd6bbb; Mon, 29 Jun 2009 16:11:02 -0700 (PDT) Received: from 201-42-210-207.dsl.telesp.net.br (201-42-210-207.dsl.telesp.net.br [201.42.210.207]) by core3.amsl.com (Postfix) with ESMTP id 973573A6AAE; Mon, 29 Jun 2009 16:11:01 -0700 (PDT) Message-ID: <000d01c9f90e$caa466c0$6400a8c0@sprintingdn80> From: aaa-archive@lists.ietf.org To: Subject: Lose wieght without starvation , Try Acai Berry. Date: Mon, 29 Jun 2009 20:10:28 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F90E.CAA466C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F90E.CAA466C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If you experience difficulty viewing=20 this message, you can view it in your browser. =20 =20 =20 eNews June=20 2009 =20 =20 =20 =20 =20 Get your Acai Flush trial now!Hit the button here =20   =20 =20 =20 Update your details | Unsubscribe or edit=20 optionsPlease forward this eNewsletter to a=20 friends ------=_NextPart_000_0007_01C9F90E.CAA466C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

If you experience difficulty view= ing=20 this message, you can view it in y= our browser.

eNews J= une=20 2009


<= FONT size=3D4>Get your Acai Flush trial now!=

Hit the button h= ere
  Update your details | Unsubscribe or edit=20 options
Please forward this eNewsletter to a=20 friends

 ------=_NextPart_000_0007_01C9F90E.CAA466C0-- From owner-namedroppers@ops.ietf.org Tue Jun 30 07:09:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45193A6B48; Tue, 30 Jun 2009 07:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.705 X-Spam-Level: ** X-Spam-Status: No, score=2.705 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, 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 7RWVB3LHUIBQ; Tue, 30 Jun 2009 07:09:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5AC413A69CD; Tue, 30 Jun 2009 07:09:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLdtY-000F63-Ar for namedroppers-data0@psg.com; Tue, 30 Jun 2009 14:01:12 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLdsF-000ExZ-KM for namedroppers@ops.ietf.org; Tue, 30 Jun 2009 14:00:16 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n5UDxncc060149 for ; Tue, 30 Jun 2009 09:59:49 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n5UDxnZ4060148 for namedroppers@ops.ietf.org; Tue, 30 Jun 2009 09:59:49 -0400 (EDT) (envelope-from namedroppers) Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLPSa-000FA0-Gc for namedroppers@ops.ietf.org; Mon, 29 Jun 2009 22:36:30 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTPA id 7AD2F33C37; Mon, 29 Jun 2009 15:36:23 -0700 (PDT) Date: Mon, 29 Jun 2009 15:36:23 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Sabahattin Gucukoglu Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Glue Caching Misbehaviours In-Reply-To: <2F9189CD-58A8-46B1-88C7-AC4D4BA2127F@sabahattin-gucukoglu.com> References: <2F9189CD-58A8-46B1-88C7-AC4D4BA2127F@sabahattin-gucukoglu.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [ 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. ] At Thu, 25 Jun 2009 12:58:29 +0100, Sabahattin Gucukoglu wrote: > Seems a bit pointless rewriting my problem statement and the > followups, so here's the IETF general discussion: > http://www.mail-archive.com/ietf@ietf.org/msg42037.html : The problem is this: the authoritative servers for a domain can : easily never be consulted for DNS data if the resource being looked up : happens to be available at the parent zone. That is, : bigbox.example.net's address and the RR's TTL can never be as : specified by the zone master unless he or she has control over the : parent zone's delegation to example.net if bigbox.example.net happens : to be serving for example.net. (Registries give you address control, : of course, but often they fix on large TTLs.) Can you be more specific? That is, could you provide an existent name that causes the problem you stated, rather than the imaginary "bigbox.example.net"? Please also be more specific about "if the resource being looked up happens to be available at the parent zone". Do you mean, for example, something like this? - A recursive server tries to resolve AAAA for "bigbox.example.net", and sends a query to a .net server. - A .net server returns a referral like this: example.net. NS bigbox.example.net. (in the authority section) bigbox.example.net. AAAA 2001:db8::1234 (in the additional section) - The recursive server simply caches the AAAA RR in the additional section, and returns that record to the client without following the delegation further. (I know the answer is no, btw, because BIND9 doesn't behave this way) --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 30 08:22:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3BFC28C403; Tue, 30 Jun 2009 08:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 aILrheiVPmTi; Tue, 30 Jun 2009 08:22:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AFA0428C402; Tue, 30 Jun 2009 08:22:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLf5s-000MDW-1U for namedroppers-data0@psg.com; Tue, 30 Jun 2009 15:18:00 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLf5e-000MBf-9N for namedroppers@ops.ietf.org; Tue, 30 Jun 2009 15:17:54 +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 1MLf8L-0005pJ-28; Tue, 30 Jun 2009 17:20:33 +0200 Received: by bfk.de with local id 1MLf5Z-0000Hx-8q; Tue, 30 Jun 2009 15:17:41 +0000 To: JINMEI Tatuya / =?utf-8?B?56We5piO6YGU5ZOJ?= Cc: Sabahattin Gucukoglu , namedroppers@ops.ietf.org Subject: Re: [dnsext] Glue Caching Misbehaviours References: <2F9189CD-58A8-46B1-88C7-AC4D4BA2127F@sabahattin-gucukoglu.com> From: Florian Weimer Date: Tue, 30 Jun 2009 15:17:41 +0000 In-Reply-To: ("JINMEI Tatuya / =?utf-8?B?56We5piO6YGU5ZOJIidz?= message of "Mon\, 29 Jun 2009 15\:36\:23 -0700") Message-ID: <82k52t699m.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89: > : The problem is this: the authoritative servers for a domain can > : easily never be consulted for DNS data if the resource being looked up > : happens to be available at the parent zone. That is, > : bigbox.example.net's address and the RR's TTL can never be as > : specified by the zone master unless he or she has control over the > : parent zone's delegation to example.net if bigbox.example.net happens > : to be serving for example.net. (Registries give you address control, > : of course, but often they fix on large TTLs.)=20 > > Can you be more specific? That is, could you provide an existent name > that causes the problem you stated, rather than the imaginary > "bigbox.example.net"? Try NS1.MSFT.NET. > (I know the answer is no, btw, because BIND9 doesn't behave this way) Eh, BIND 9.5 considers some non-authorative answers as authoritative, like the one from Verisign's servers for NS1.MSFT.NET. Last time I looked at the code, there was some logic to pull an AA bit out of thin air. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=C3=9Fe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 30 08:25:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98FDE28C3F9; Tue, 30 Jun 2009 08:25:06 -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=0.009, 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 w9P6JnMjlwR2; Tue, 30 Jun 2009 08:25:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1825428C20A; Tue, 30 Jun 2009 08:25:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLf9Z-000MXu-Cz for namedroppers-data0@psg.com; Tue, 30 Jun 2009 15:21:49 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLf9J-000MWZ-N0 for namedroppers@ops.ietf.org; Tue, 30 Jun 2009 15:21:43 +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 1MLfBr-0006Fw-V0; Tue, 30 Jun 2009 17:24:11 +0200 Received: by bfk.de with local id 1MLf96-0002Zx-6W; Tue, 30 Jun 2009 15:21:20 +0000 To: Masataka Ohta Cc: Sabahattin Gucukoglu , Nicholas Weaver , namedroppers@ops.ietf.org Subject: Re: [dnsext] Glue Caching Misbehaviours References: <2F9189CD-58A8-46B1-88C7-AC4D4BA2127F@sabahattin-gucukoglu.com> <0C56E994-CE14-4811-B3FB-DC2B78E78AAC@icsi.berkeley.edu> <04840579-9922-4435-9C2E-0E2A0B98501A@sabahattin-gucukoglu.com> <4A4413A1.90002@necom830.hpcl.titech.ac.jp> From: Florian Weimer Date: Tue, 30 Jun 2009 15:21:20 +0000 In-Reply-To: <4A4413A1.90002@necom830.hpcl.titech.ac.jp> (Masataka Ohta's message of "Fri\, 26 Jun 2009 09\:17\:37 +0900") Message-ID: <82fxdh693j.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: * Masataka Ohta: > Glue in a refferal answer to a query may be cached, as long as > the cache is used only for glue of a cached refferal answer to > a query identical to the original query. And all downstream resolvers also follow this rule and don't use the data in any other way. Not returning it to clients at all (but using it to locate name servers in the subtree given by the referral) might be more advisable. --=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 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 30 09:30:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADA53A6C36; Tue, 30 Jun 2009 09:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.107 X-Spam-Level: X-Spam-Status: No, score=-5.107 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 Pk9t+8EWbkf9; Tue, 30 Jun 2009 09:30:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 878D03A6924; Tue, 30 Jun 2009 09:30:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLg8A-00039j-B3 for namedroppers-data0@psg.com; Tue, 30 Jun 2009 16:24:26 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLg7s-00038b-9H for namedroppers@ops.ietf.org; Tue, 30 Jun 2009 16:24:20 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n5UGNtVI007234; Tue, 30 Jun 2009 09:23:55 -0700 (PDT) Cc: Nicholas Weaver , =?UTF-8?Q?JINMEI_Tatuya_/_=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?= , Sabahattin Gucukoglu , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Florian Weimer In-Reply-To: <82k52t699m.fsf@mid.bfk.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [dnsext] Glue Caching Misbehaviours Date: Tue, 30 Jun 2009 09:23:55 -0700 References: <2F9189CD-58A8-46B1-88C7-AC4D4BA2127F@sabahattin-gucukoglu.com> <82k52t699m.fsf@mid.bfk.de> X-Mailer: Apple Mail (2.935.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jun 30, 2009, at 8:17 AM, Florian Weimer wrote: > > >> (I know the answer is no, btw, because BIND9 doesn't behave this way) > > Eh, BIND 9.5 considers some non-authorative answers as authoritative, > like the one from Verisign's servers for NS1.MSFT.NET. Last time I > looked at the code, there was some logic to pull an AA bit out of thin > air. You can test for yourself if you are curious. The only authority for .netalyzr.icsi.berkeley.edu is roland.icir.org. (Yes, its only one nameserver. But if Roland is down, our front end is down and netalyzr is down...) But it does return alternate ones in the additional/auth field depending on query. One such query: glue_ns_internal.{garbage}. {node}.netalyzr.icsi.berkeley.edu returns the address of the node and also returns the node's IP as an authoritative nameserver with the name return_false.internal.{garbage}.{node}... However, return_false.{anything}.netalyzr... returns the "false IP" (192.150.186.14. The weird choice of addresses is to allow the testing to work within the Java same origin policy: unless the user trusts the address, Java returns either the address of the server or a security exception when a name is looked up, giving us a boolean test). Bind's particular behavior seems to be "internal": If the A record is anywhere within the hieriarchy. So a query for www.microsoft.com would have a .com authority return the glue records for ns{1-5}.msft.net, which bind will use but will not return the A records in response to queries to ns{1-5}.msft.net.... However, a query for www.msft.net will have .net return the glue records for ns{1-5}.msft.net, which bind WILL return for subsequent direct A record queries for those names, with the TTLs as provided by the .net authority, NOT what .msft.net's authorities provide. The nameserver behavior itself: ; <<>> DiG 9.5.1-P1-RedHat-9.5.1-1.P1.fc10 <<>> +norecurse glue_ns_internal.n1.netalyzr.icsi.berkeley.edu @roland.icir.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35428 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;glue_ns_internal.n1.netalyzr.icsi.berkeley.edu. IN A ;; ANSWER SECTION: glue_ns_internal.n1.netalyzr.icsi.berkeley.edu. 100 IN A 67.202.37.63 ;; AUTHORITY SECTION: n1.netalyzr.icsi.berkeley.edu. 100 IN NS roland.icir.org. n1.netalyzr.icsi.berkeley.edu. 100 IN NS return_false.internal.n1.netalyzr.icsi.berkeley.edu. ;; ADDITIONAL SECTION: roland.icir.org. 100 IN A 192.150.187.31 return_false.internal.n1.netalyzr.icsi.berkeley.edu. 100 IN A 67.202.37.63 ; <<>> DiG 9.5.1-P1-RedHat-9.5.1-1.P1.fc10 <<>> +norecurse return_false.internal.n1.netalyzr.icsi.berkeley.edu @roland.icir.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18084 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;return_false.internal.n1.netalyzr.icsi.berkeley.edu. IN A ;; ANSWER SECTION: return_false.internal.n1.netalyzr.icsi.berkeley.edu. 1 IN A 192.150.186.14 ;; AUTHORITY SECTION: internal.n1.netalyzr.icsi.berkeley.edu. 100 IN NS roland.icir.org. ;; ADDITIONAL SECTION: roland.icir.org. 100 IN A 192.150.187.31 But if you run through a Bind instance rather than direct to the authority. (I forget what version we use here at ICSI, but the recursive resolver is some flavor of Bind): ; <<>> DiG 9.5.1-P1-RedHat-9.5.1-1.P1.fc10 <<>> glue_ns_internal.n1.netalyzr.icsi.berkeley.edu @192.150.186.8 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35160 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;glue_ns_internal.n1.netalyzr.icsi.berkeley.edu. IN A ;; ANSWER SECTION: glue_ns_internal.n1.netalyzr.icsi.berkeley.edu. 100 IN A 67.202.37.63 ;; AUTHORITY SECTION: n1.netalyzr.icsi.berkeley.edu. 100 IN NS return_false.internal.n1.netalyzr.icsi.berkeley.edu. n1.netalyzr.icsi.berkeley.edu. 100 IN NS roland.icir.org. ;; ADDITIONAL SECTION: roland.icir.org. 3600 IN A 192.150.187.31 return_false.internal.n1.netalyzr.icsi.berkeley.edu. 100 IN A 67.202.37.63 ; <<>> DiG 9.5.1-P1-RedHat-9.5.1-1.P1.fc10 <<>> return_false.internal.n1.netalyzr.icsi.berkeley.edu @192.150.186.8 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62754 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; QUESTION SECTION: ;return_false.internal.n1.netalyzr.icsi.berkeley.edu. IN A ;; ANSWER SECTION: return_false.internal.n1.netalyzr.icsi.berkeley.edu. 88 IN A 67.202.37.63 ;; AUTHORITY SECTION: n1.netalyzr.icsi.berkeley.edu. 88 IN NS roland.icir.org. n1.netalyzr.icsi.berkeley.edu. 88 IN NS return_false.internal.n1.netalyzr.icsi.berkeley.edu. ;; ADDITIONAL SECTION: roland.icir.org. 3600 IN A 192.150.187.31 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 30 10:00:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E12093A6E2F; Tue, 30 Jun 2009 10:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.4 X-Spam-Level: X-Spam-Status: No, score=-99.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSnc66ki5vsN; Tue, 30 Jun 2009 10:00:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CE50A3A6C5B; Tue, 30 Jun 2009 10:00:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLgcs-0006uH-T3 for namedroppers-data0@psg.com; Tue, 30 Jun 2009 16:56:10 +0000 Received: from [2001:4f8:3:36::162] (helo=mon.jinmei.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLgcd-0006qz-Tp for namedroppers@ops.ietf.org; Tue, 30 Jun 2009 16:56:04 +0000 Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTPA id 914D833C37; Tue, 30 Jun 2009 09:55:55 -0700 (PDT) Date: Tue, 30 Jun 2009 09:55:52 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Florian Weimer Cc: Sabahattin Gucukoglu , namedroppers@ops.ietf.org Subject: Re: [dnsext] Glue Caching Misbehaviours In-Reply-To: <82k52t699m.fsf@mid.bfk.de> References: <2F9189CD-58A8-46B1-88C7-AC4D4BA2127F@sabahattin-gucukoglu.com> <82k52t699m.fsf@mid.bfk.de> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At Tue, 30 Jun 2009 15:17:41 +0000, Florian Weimer wrote: > > : The problem is this: the authoritative servers for a domain can > > : easily never be consulted for DNS data if the resource being looked up > > : happens to be available at the parent zone. That is, > > : bigbox.example.net's address and the RR's TTL can never be as > > : specified by the zone master unless he or she has control over the > > : parent zone's delegation to example.net if bigbox.example.net happens > > : to be serving for example.net. (Registries give you address control, > > : of course, but often they fix on large TTLs.) > > > > Can you be more specific? That is, could you provide an existent name > > that causes the problem you stated, rather than the imaginary > > "bigbox.example.net"? > > Try NS1.MSFT.NET. I know this problem. My first guess when I saw the message was something like this, but it is nothing to do with the additional section (at least from BIND9's point of view as a recursive server) as the original problem description claimed: http://www.mail-archive.com/ietf@ietf.org/msg42037.html : As far as I can tell, every public recursive server I can reach, : dnscache and BIND9, and one Microsoft cache and one of whatever : OpenDNS uses, all do the wrong thing (TM) and never look up true data : from authoritative name servers. They hang on to additional section ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ : data from the delegating name server and pass this on as truth, the I don't know about other 'they', but in the case of BIND9 recursive server resolving NS1.MSFT.NET, it hangs on to the *answer section* of a non-authoritative response, not the additional section. I didn't know whether the original question was confused or meant something else, and that's why I requested a precise problem description with a checkable example. > > (I know the answer is no, btw, because BIND9 doesn't behave this way) > > Eh, BIND 9.5 considers some non-authorative answers as authoritative, > like the one from Verisign's servers for NS1.MSFT.NET. Last time I > looked at the code, there was some logic to pull an AA bit out of thin > air. I know, but it's not the behavior in this context (if we interpret it most precisely) as I explained above. Regarding the 'hanging on to non-authoritative answer section' issue, we'll fix the behavior. Future versions of BIND9 recursive resolver will follow the delegation from .net to msft.net ignoring the answer section returned from the .net server. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 30 10:27:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333E63A6EA9; Tue, 30 Jun 2009 10:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.947 X-Spam-Level: * X-Spam-Status: No, score=1.947 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RCVD_IN_NJABL_PROXY=1.643, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjLUoNzjVnAM; Tue, 30 Jun 2009 10:27:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E7173A6E9F; Tue, 30 Jun 2009 10:27:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLh3o-000AVx-Dy for namedroppers-data0@psg.com; Tue, 30 Jun 2009 17:24:00 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLh3d-000AUC-3P for namedroppers@ops.ietf.org; Tue, 30 Jun 2009 17:23:54 +0000 Received: (qmail 30574 invoked from network); 30 Jun 2009 19:02:14 -0000 Received: from softbank219001188006.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.6) by necom830.hpcl.titech.ac.jp with SMTP; 30 Jun 2009 19:02:14 -0000 Message-ID: <4A4A49F0.6050305@necom830.hpcl.titech.ac.jp> Date: Wed, 01 Jul 2009 02:22:56 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Florian Weimer CC: Sabahattin Gucukoglu , Nicholas Weaver , namedroppers@ops.ietf.org Subject: Re: [dnsext] Glue Caching Misbehaviours References: <2F9189CD-58A8-46B1-88C7-AC4D4BA2127F@sabahattin-gucukoglu.com> <0C56E994-CE14-4811-B3FB-DC2B78E78AAC@icsi.berkeley.edu> <04840579-9922-4435-9C2E-0E2A0B98501A@sabahattin-gucukoglu.com> <4A4413A1.90002@necom830.hpcl.titech.ac.jp> <82fxdh693j.fsf@mid.bfk.de> In-Reply-To: <82fxdh693j.fsf@mid.bfk.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Florian Weimer wrote: >>Glue in a refferal answer to a query may be cached, as long as >>the cache is used only for glue of a cached refferal answer to >>a query identical to the original query. > And all downstream resolvers also follow this rule and don't use the > data in any other way. It is merely required that all upstream resolvers of you and all upstream name servers of your peer follow the rule, which is no more difficult than deploying DNSSEC between you and your peer. The resulting security is better than that of DNSSEC. > Not returning it to clients at all (but using > it to locate name servers in the subtree given by the referral) might > be more advisable. Maybe, though it may increase load on root servers. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 30 12:20:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 907233A6BE6; Tue, 30 Jun 2009 12:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 A2sM52Dylx2H; Tue, 30 Jun 2009 12:20:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 980DC3A6B83; Tue, 30 Jun 2009 12:20:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLimU-000PGP-Aq for namedroppers-data0@psg.com; Tue, 30 Jun 2009 19:14:14 +0000 Received: from [204.152.186.148] (helo=hankinsfamily.info) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MLimE-000PEG-Qq for namedroppers@ops.ietf.org; Tue, 30 Jun 2009 19:14:08 +0000 Received: from hcf.isc.org (dhcp-186.sql1.isc.org [204.152.187.186]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id n5UJEMPK003846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Jun 2009 12:14:22 -0700 Received: by hcf.isc.org (Postfix, from userid 10200) id 121975735B; Tue, 30 Jun 2009 12:15:10 -0700 (PDT) Date: Tue, 30 Jun 2009 12:15:10 -0700 From: "David W. Hankins" To: namedroppers@ops.ietf.org Subject: [dnsext] Re: ops.ietf.org Blacklisting Complications Message-ID: <20090630191510.GA3283@isc.org> References: <58014C1D-E09B-41CC-B7FA-C3F5A65549AF@sabahattin-gucukoglu.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <58014C1D-E09B-41CC-B7FA-C3F5A65549AF@sabahattin-gucukoglu.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 27, 2009 at 07:41:10AM +0100, Sabahattin Gucukoglu wrote: > ops.ietf.org is hosted at psg.com, which uses blacklists from the MAPS. MAPS RBL does not exist anymore. You may instead have meant TrendMicro's ERS ("Email Reputation Service")? smtp.googlemail.com is frequently listed on Trend's QIL database, which is a highly fluctuating, short-duration list (part of the 'ERS Advanced' product line, if I'm not mistaken). So at least one option is to wait awhile until the listing expires. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --zhXaljGHf11kAtnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpKZD4ACgkQcXeLeWu2vmrgxACgtp1ayWScjKQx58u4l9Z/uVHT 5ucAoLjJUtElErZxECnfEzvSJ7rJyR5o =FltX -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From chastenedi457@samperi.com Tue Jun 30 13:37:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A689C3A6A24; Tue, 30 Jun 2009 13:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.103 X-Spam-Level: X-Spam-Status: No, score=-75.103 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DIET_1=0.083, DOS_OE_TO_MX=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_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_MESSAGE=0.001, 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_ALC=1.405, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibEVyoIWgWd4; Tue, 30 Jun 2009 13:37:46 -0700 (PDT) Received: from cpe-76-188-106-22.neo.res.rr.com (cpe-76-188-106-22.neo.res.rr.com [76.188.106.22]) by core3.amsl.com (Postfix) with ESMTP id B96063A6962; Tue, 30 Jun 2009 13:37:43 -0700 (PDT) Message-ID: <000d01c9f9c2$78819660$6400a8c0@chastenedi457> From: dnsext-archive@lists.ietf.org To: Subject: Improve your blood curculation , Try Acai Berry. Date: Tue, 30 Jun 2009 16:36:39 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F9C2.78819660" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F9C2.78819660 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable FLush out your bodies toxins and start feeling great with Acai Berry.   Acai Berry Stimulates your Mind.=20   tired Of feeling Down lose weight for free               &nb= sp;      =20 Click at the moment     best regards Tasia=20 Hurst ------=_NextPart_000_0007_01C9F9C2.78819660 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
FLush out your bodies toxins and start feel= ing great with Acai Berry.
 
Acai Berry Stimulates your Mind.
 
tired Of feeling Down lose weight fo= r free
 
          &n= bsp;        =20 Click at the moment
 
 
best regards Tasia=20 Hurst
------=_NextPart_000_0007_01C9F9C2.78819660-- From ossifyingcs5@netztech.ch Tue Jun 30 14:16:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CB9B28C440; Tue, 30 Jun 2009 14:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=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_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, SARE_URI_REPLICA=1.634, TVD_RCVD_IP=1.931, 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 0CxkzcYRyGba; Tue, 30 Jun 2009 14:16:08 -0700 (PDT) Received: from 62-3-21-190.adsl.terra.cl (62-3-21-190.adsl.terra.cl [190.21.3.62]) by core3.amsl.com (Postfix) with ESMTP id 6077E28C43E; Tue, 30 Jun 2009 14:16:07 -0700 (PDT) Message-ID: <000d01c9f9c8$0153bbd0$6400a8c0@ossifyingcs5> From: dnsext-archive@lists.ietf.org To: Subject: Best Selling Luxury Bags and wallets Date: Tue, 30 Jun 2009 17:16:16 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C9F9C8.0153BBD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9F9C8.0153BBD0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable   Present... Best Selling Luxury Bags and wallets Black Casual Loafer=20 Classic White Monogram Gucci Logo=20 Armani Sneakers Push the button =A0 =A0 =A0 ------=_NextPart_000_0007_01C9F9C8.0153BBD0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
3D""  Present...
Best Selling Luxury Bags and wallets=
=A0
=A0
=A0
------=_NextPart_000_0007_01C9F9C8.0153BBD0--